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

On Thu, Aug 21, 2008 at 10:10:33AM +1000, Neil Brown wrote:

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

quoted

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

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?

Yes, due to limitations of the PS/2 protocol itself among other
things. I am sure Vojtech will correct me but I believe he made
/dev/input/mice as a stop-gap measure until X is ready... well, it was
8 some years ago ;(

I must confess a certain sympathy for that position, but it does make
solving my current problem harder - which dampens my enthusiasm :-)

Yeah, I can understand that.

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.

All these solutions require changes to userspace/drivers. I feel that
this time is better spent on the X itself rather on various drivers
re-implementing the same thing and stumbling over the same problems.

 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.

It probaibly was a mistake to make touchscreens go through
/dev/input/mice. Again, the adea was to allow limitied use until
proper driver is installed.

 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.

Maybe openmoko could just patch mousedev to ignore touchscreens for
now, until X is fixed?

-- 
Dmitry