Touchpad stylus mode
Zephaniah E. Hull
warp at aehallh.com
Wed Mar 21 18:06:09 EDT 2007
<lots of snippage>
> >This is essentially the plan we had long ago, but pretty much shelved
> >when all the touchpad stuff was being worked out. I think it's a
> >pretty
> >good solution to the X 1:1 problem, the child gets to _see_ onscreen
> >where their input will go. There'd have to be a mechanism to move the
> >"input bar" around the screen vertically of course.
>
>
> *sigh* I'm not getting through to you guys. My point is that it is
> not enough to move the input bar vertically only. It needs to be
> moved both horizontally and vertically to match up the first stylus
> event with the last finger event. Otherwise I can't see how pixel-
> perfect drawing should be possible.
>
> I guess I need to whip up a demo because it is hard to imagine - so
> can I access finger and stylus data separately right now?
Alright, from the thread I think that we need to go over the current
state of things in what we're shipping, then the current state of
X.org's git tree. And maybe on what I think we should do.
So, some terms.
Device, that's the ALPS touchpad device.
PT, PenTablet, that's the mode that covers the whole width of the
device, you use it with a stylus.
GS, GlideSensor, that's the mode that covers the middle 1/3rd of the
device, you use it with a pen.
X.org, that's the xorg server, protocol specs, etc.
evdev, the method that the Linux kernel has standardized on for
communicating input events to applications (such as X).
xf86-input-evdev, that's the X side driver that we're using.
kernel driver, that's what sits in the kernel and talks to the touchpad
device, and provides data to xf86-input-evdev.
Now, the state as I'm aware of it as we are currently shipping:
The touchpad device can do the following:
In GS mode:
Provide absolute X, Y, and Z data, with Z being pressure, for a
single finger or finger like thing touching the middle 1/3rd of
the device.
Provide GS-down and PT-down bits, letting us know what's touching
or not/touching the device at that time.
Provide left and right button up/down bits, letting us know what
buttons are being pressed.
In PT mode:
Provide absolute X and Y data, for a single stylus touching
anywhere on the device. (No Z data.)
Provide PT-down bits, letting us know what's touching/not touching
the device at that time. (No GS-down.)
Provide left and right button up/down bits, letting us know what
buttons are being pressed.
There are some other misc abilities in regards to calibration, but
those just don't apply to the discussion at the moment.
The kernel driver:
The kernel driver is responsible for a lot, it talks to the device,
makes sure that it's the right sort of touchpad, puts it in the
proper modes, and spitting out the information to X.
The kernel driver registers two input devices with evdev, one for
the PT, and one for the GS.
The PT is registered with ABS_X, ABS_Y, BTN_TOOL_PEN, BTN_TOUCH,
BTN_LEFT, and BTN_RIGHT.
The GS is registered with ABS_X, ABS_Y, ABS_Z, BTN_TOOL_FINGER,
BTN_TOUCH, BTN_LEFT, and BTN_RIGHT.
Currently the packet handling logic is roughly as follows:
GS or PT packet[0]:
If it has been more then 30msec since we last saw a data packet,
tell evdev that the PT's BTN_TOUCH and BTN_TOOL_PEN are both
false. Tell the GS's BTN_TOUCH and BTN_TOOL_FINGER are both
false as well.
GS packet:
If GS-down is true, hand the X, Y, and Z coordinate data off to
evdev.
Report BTN_LEFT and BTN_RIGHT up/down state to evdev for both
the PT and the GS.
If PT-down is true, switch to PT mode, and schedule a switch
back to GS mode 50ms in the future[1].
PT packet:
If GS-down is true, hand the X and Y coordinate data off to
evdev.
Report BTN_LEFT and BTN_RIGHT up/down state to evdev, but only
for PT.
If PT-down is true, cancel any switch back to GS mode currently
scheduled.
If PT-down is false, schedule a switch back to GS mode 50ms in
the future[2].
No coordinate conversion is done in the X driver, and everything
is reported as an absolute device.
xf86-input-evdev:
This is where some of the fun is, and much of this depends on
configuration settings at the moment.
For the GS:
Opens and grabs the evdev node for the GS.
Suppresses the BTN_TOUCH and BTN_TOOL_FINGER buttons[3].
Based on BTN_TOUCH, handles conversion from the absolute
coordinate set that the kernel driver gives us to relative
coordinates.
For the PT:
Opens and grabs the evdev node for the GS.
Suppresses the BTN_TOUCH and BTN_TOOL_PEN buttons[3].
Should be scaling the touchpad to fill the screen, isn't right
now, otherwise doesn't molest the byte stream.
Now, a few things of note to point out.
xf86-input-evdev simply doesn't _know_ when the mode switch happens,
all it knows is that it's getting data that says that something has
changed state wise, usually coordinate data, but sometimes buttons or
sense data.
xf86-input-evdev also can't trigger a mode switch, that's entirely up
to the kernel driver.
0: This is a kludge to deal with a device issue where it fails to send
a GS/PT-up packet in some causes, causing the xf86-input-evdev driver
to think that picking up the finger and putting it down elsewhere was
actually just moving it very quickly. Hopefully this will go away in
time.
1: This is to handle a race condition, if the user briefly touches the
device with a stylus, but lifts before the mode switch to PT is
completed, we will never get a packet telling us that the PT is up.
However since we should be getting a packet every 12ms or so with the
stylus down, we can simply schedule a return switch, and cancel it if
we get a PT packet.
2: This is to deal with the fact that with a stylus and a light touch
the device sometimes thinks for a packet or two that the stylus is not
in contact even when it is. We wish to avoid unneeded mode changes
because they are not instant, and so we apply a simple debounce here.
3: Yes, that's right. xf86-input-evdev gets BTN_TOUCH, and doesn't
tell X about it. Suggestions on how you want that to be represented
to the X clients would be appreciated.
In the current xorg get trees:
XInput:
XInput has been extended to allow for absolute device calibration
and area setting.
Specificly, you can get, and set, the device's min/max X and Y
settings (for scaling purposes). You can flip the sign on X and/or
Y coordinate data, you can specify a rotation in degrees, and if the
device has Z data you can specify a button threshold, so that
pressing that much or harder generates a button click.
On the area side, you can set an offset for X and/or Y, specify the
width and height the input should be stretched/squeezed to, specify
what X screen it should be on, and tell it to move the X/Y around
when another specified device moves.
Pretty much, with those two, that gives us the ability to control
the area of the touchpad however we wish to, from leaving it so that
one pixel = one unit, to stretching over the screen, to making it
smaller for more accuracy, to moving it around the screen at will.
xorg:
Now for the catch, the protocol supports all that. The fields
exist.
Absolutely nothing refers to them yet, there is no code for actually
doing any of the things specified above, which means some work to
make it happen. Not nearly as much as there would be if the XInput
changes were not there, but it's still some work.
xf86-input-evdev:
In a very similar state to xorg. And there are some other changes
in regards to input devices in the xorg git tree that will mean some
restructuring of xf86-input-evdev when I start adapting it to the
xorg git tree.
Now, that covers where things currently are.
So, inside that framework, what are your thoughts on how this should
work? And how would you change that framework if you could?
Zephaniah E. Hull.
--
1024D/E65A7801 Zephaniah E. Hull <warp at aehallh.com>
92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801
CCs of replies from mailing lists are requested.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.laptop.org/pipermail/devel/attachments/20070321/8ed907fc/attachment.sig>
More information about the Devel
mailing list