Re: tc1000 linux - the project (long)

Matthew Allum wrote:
> on Wed, Jun 25, 2003 at 06:20:11AM +0700, Samphan Raruenrom wrote:
>>Yes. And the proper way of doing write-anyway, i18n-correct
>>handwriting recognition.
> Things like xstroke arn't a million miles away from doing this
> kind of thing.

Sorry if it sound like a stupid question cause I don't
fully explore the problem yet and I don't know much about
X/GNOME programming.
But the i18n aspect make me worried a bit because current
X implementations (xstroke, xscrible, xmerlin) convert stroke
to character, then convert the character to 256 keycode, then send
the keycode to X? (right?). Then normally, applications will get
the keycode and ask X to convert the keycode to the (hopefully)
same character. Am I right?
This sounds very complicated. Isn't there any protocol
that directly send a (16-bit) character/string to the active window?
I don't think it is possible to implement, say, Chinese HWR this way?

>>And the window manager would have extension
>>that put the dialog away from the stylus like MS TPC extension.
> hmm, I havn't seen this ( I think I need to see if my tablet still
> boots XP ;-) ). Im the author of matchbox[1] so its pretty easy for me
> to hack these kind of features into that.

WOW!!!! (Sorry for this late WOW! I've been off-line for > a week)
I've guessed so from the beginning anyway. Because I saw your
archive full of matchbox tarball and also because
your name begin with 'Mat' ;-)

There's a lot of experimentation that I'm thinking and trying on my machine.
This may be a good place where we can talk about how 'linux tablet pc'
should be.

- Turn off the pointer all the time, like on PalmOS. Pen-based computing
should get rid of the pointer, which existence is to remind you of the
position of the pen. But the pen is in your hand, so having another
marker on
screen create 2 concepts of the same thing. We merge the concept when
the pen get close to the screen and split it when it goes off, again and
again. The situation gets worse when the pen's tip and the pointer are not
exactly at the same point due to calibration error. Though most of the time
such errors don't hurt due to the size of hot spots, it looks very
irritating.
Get rid of the pointer and you'll feel better. New user should get going
quicker I think.
The implementation requirement is that there must always be visual
feedback to the user all the time, w/o relying on the presence of the
pointer.

- Instant-on. That means, like on PalmOS, after a period of inactivity,
a daemon will put the machine in S1 (standby) tate. After that, the
user toggle the power switch to turn the machine on. (I don't have
an IPAQ. Is this the same thing done on IPAQ linux?)

I don't know if it is possible to enter S1 state in WinXP (how?) but
AFAIK, WinXP TPC wasn't made for instant-on. However, tc1000
can be used for that purpose in Linux cause the hardware support S1.
I've tried S1 standby in 2.4.21-ac1 kernel and it lasted 8 hours on full
battery. Full S1 support should perform better because 2.4.21-ac1
didn't even poweroff the USB or PCMCIA bus?
What's the min. requirement for standby time?
e.g. How long can an IPAQ stay standby off-charger?

>>>>I personally want to see all feature in tc1x00 get implemented
>>>>in linux and X so it is as useful as Windows XP TPC.
>>>>(which mean dynamic screen rotate and Q menu in linux)
>>>Screen rotation is there ( though it'd be better with a kdrive nv
>>>server :) - should be faster than vesa )
>>Yes. But nv doesn't accellerate in portraite mode anyway.
>>Do you know why XFree86 drivers don't support Xrandr rotaion?
> The Xfree kdrive ( aka tinyX ) servers do ( Vesa and Xfbdev ones at
> least ) . Im not sure why they do fully support XRandR and 'big' X
> servers dont.

The reason why kdrive support full Xrandr protocol should be easy.
It's because Xrandr protocol and kdrive are written by the same
person! :-) The question is why the big X servers don't? I think
I'd better ask this question in xwin.org mailling list.

> Though the problem is kdrive servers exist for most
> cards except NVidia ones.

The XFree86 nv driver don't do well on tc1000. It won't switch
back to text mode (simply blank). DPMS won't work. No multiple-screen
support. A lot of work need to be done on this free driver.

> Id hope using the Xvesa and big X nv sources it wouldn't be too hard
> to make a rotation capable kdrive nv server.

I still can't use the pen in Xvesa, actually,
I'm guessing how your patch might work... It convert /dev/ttyS0 (FPI
protocol) and
send them to Xvesa as /dev/input/mice (IMPS/2 protocol) right?

>>>I have no idea what the Q menu is.
>>It's a Compaq utility used to do everything other Notebook do using
>>buttons, like adjust screen brightness, switch screens and adjust volumn.
> Aha right.
>>I'd like to make linux support tc1000 naturally. That'd mean to support
>>as many features as possible. The Q menu is just a piece of software
>>(tc1000 doesn't do anything in hardware :-) We can have it if HP open
>>the source to us or just give us the specification.
>>Possible?
> Its sounds like something similar would be easy to write in Gtk or
> whatever. You wouldn't need the source to qemu, but just what bytes to
> push to control the screen brightness. Can you already get key events
> from the Q key ?

I know what you mean. No, it won't work that way.
The Q key is just a normal key and it'll send keycode 131 when pressed.
How it works depend on user's setting which the default in WinXP is to lauch
the Q menu app. I've just played around with linux on several notebook
models and observe that there're two kinds of them :-
1) those that have function keys to set brightness and they still work
in linux
2) those that don't have one (require utitility) or the keys stop
working in linux.

For those notebooks in class 2, there must be special support in the
kernel for them, e.g. Toshiba notebook support in kernel 2.4, and ASUS
notebook support in kernel 2.5. The author of these kernel supports have
reverse-engineered the Windows drivers of the notebooks to get the
protocol (ports/values) then write the linux driver for them.

For tc1000, if HP open the source of Q menu or open the specification
(in the form like http://www.buzzard.org.uk/toshiba/docs.html), I can
spend somespare time to write the linux support for it,
as a part of my kernel-newbies' practise.

See if there's any chance. :-)
Received on Sat Jul 05 20:22:43 2003