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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.laptop.org/pipermail/devel/attachments/20070321/8ed907fc/attachment-0001.bin


More information about the Devel mailing list