Re: [PATCH/RFC] Resolve 2 year old issue with different demands on EVIOCGRAB

On Monday August 18, dmitry.torokhov@gmail.com wrote:

On Mon, Aug 18, 2008 at 10:51:33AM +1000, Neil Brown wrote:

quoted

 But the X server still needs to know a little bit about /dev/tty to
 make sure that control-C doesn't get delivered the wrong way.  That's
 awkward.

Does it need to do anything besides switching VC into the raw mode?

Probably not, no.

quoted

 It also negates much of the power of the input layer (easy hot-plug).
 I don't much like that approach.

I think this is the only sensible approach though. X needs to have
native hotplug capabilities anyway because of all these new mice that
have bazillion of buttons on them that PS/2 emulation simply can not
support. And once you have hotplug support in X and don't rely on
myultiplexors anymore you can remove bunch of things, like grabbing
devices in one fashion or another and you can even keep the devices
open while switching to the text mode - no need to close and reopen
them all the time.

So your position is that for anything non-trivial, the clever stuff in
the input layer like multiplexing and simulating PS2 mice is not
sufficiently powerful and not worth fixing, and it should all be left
to userspace.  Correct?
I must confess a certain sympathy for that position, but it does make
solving my current problem harder - which dampens my enthusiasm :-)

So:  The X server need to support hotplug of input devices. 
Apparently there is code out there (for nearly 2 years) but it doesn't
seem to be in a release yet.
Quoting http://wiki.x.org/wiki/XInputHotplug

   The X.org server supports hotplugging input devices since November
   2006
   http://lists.freedesktop.org/archives/xorg/2006-October/019007.html
   (X11R7.2 will NOT have hotplug support yet).  

So both the kernel and the X server could provide the hotplug support
required, but neither are really quite usable at the moment for very
different reasons.  Sad.
Options...
 First: problem description.
   Device with a touchscreen wants:
    - touch screen events to be delivered as absolute events to X
         server.
    - Other programs to be able to monitor the touch screen to
      e.g. detect activity independently of whether an X server is in
      use or direct fbdev access is happening (e.g. Qtopia).
    - hot-plugged mice (e.g. bluetooth) should be recognised by
      X server.

 We could:
  1/ Wait for X11 XInputHotplug to be released.
  2/ Hack a little input driver for X which somehow finds 
     mouse devices and interprets them.
  3/ Use kernel's input multiplexing and:
   3a/ change EVIOCGRAB to not exclude other evdev devices
   3b/ change EVIOCGRAB to optionally not exclude other evdev devices.
   3c/ somehow convince mousedev never to listen on the touchscreen.

 Did I miss anything?

 3a is what the openmoko kernel (and presumably others) do today.  But
 it breaks backwards compatibility .
 3b is what I suggested but you don't like.
 1 does not provide a solution in a reasonable time frame
 2 is likely to be very messy and error prone

 So I'm now wondering about 3c.
 While I can understand the value of pretending that a touch-pad looks
 like a mouse, a touch-screen is a very different thing.  I don't
 think it would ever make sense for a touch screen to generate
 relative events.
 So how might we make our touchscreen appear uninteresting to
 mousedev?

 We could get it to return some other 'key' rather one of
     BTN_TOUCH BTN_TOOL_FINGER BTN_LEFT

 Maybe BTN_STYLUS.  Given that the touchpad is designed for finger
 usage it is a bit of a lie.  But it would work.

 This is really sidestepping the issue.  We really want to be able to
 say "This is a device where relative events are completely
 meaningless".  I suspect that isn't going to happen though.

 tslib doesn't seem to care much about what key is sent.  It only
 looks for BTN_TOUCH, but all it sees is when the value goes to zero
 as a "finger is removed" event.  It equally gets that from
 ABS_PRESSURE going to zero.

 So if I just arranged for the touchscreen to deliver BTN_STYLUS
 instead of BTN_TOUCH it would hide it from all the mousedev devices
 (which I think is the correct thing) and mean that the Xserver
 doesn't need to use EVIOCGRAB, so we don't need to break it in the
 kernel.

OK, I think I can go forward with that.  Thanks for listening.

NeilBrown