lkml.org 
[lkml]   [2008]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [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:
    > > 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.

    >
    > > 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



    \
     
     \ /
      Last update: 2008-08-21 02:13    [W:3.213 / U:0.324 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site