What is the purpose of fix-EVIOCGRAB-semantics.patch ??
neilb at suse.de
Thu Aug 21 05:07:40 CEST 2008
On Wednesday August 13, neilb at suse.de wrote:
> On Wednesday August 13, mickey at openmoko.org wrote:
> > Am Mittwoch 13 August 2008 09:13:43 schrieb Neil Brown:
> > > Hi I just spent some time trying to figure out why the EVIOCGRAB ioctl
> > > wasn't behaving was I expected and I finally stumbled on to this
> > > patch, which substantially changes the behaviour of EVIOCGRAB.
> > >
> > > Would it be possible to find out what the purpose of this patch is (it
> > > unfortunately contains no documentation)?
> > See http://lkml.org/lkml/2006/8/12/64
> Thanks for the pointer! Interesting reading.
> So this is a 2 year old issue (almost to the day!) which does not
> appear to have been properly resolved yet. Sad.
> It seems that the "obvious" thing to do is to interpret the argument
> to EVIOCGRAB to select between these options.
> We cannot use 0, 1, 2 as above - despite the fact that it makes sense
> - because that would be a regression: working programs would break.
> Maybe it's best to use 0, 2, 1 and document it clearly. The chance of
> anyone using 2 already has got to be very close to zero.
> We would then need to change the drivers in the X server to use '2'
> rather than '1', and (I think) everyone would be happy.
> Below is my proposed patch which provides the functionality of
> the patch in question without causing any regressions.
> It also fixes two minor buglets in the original.
> If anyone would like to comment, I'd appreciate it. If I hear nothing
> bad I'll propose it to Dimitry Torokhov on some appropriate list.
Well, Dimitry didn't like it.
He feels that if the X server wants to treat different input devices
differently, it should simply not use the multiplexing drives
(/dev/input/mice) at all and should support hotplugging of input
devices directly (And read /dev/input/event* for everything).
I agree that hotplugging of input devices would be good and I believe
there is code to do that. But it doesn't seem to be in a release yet,
so it is no good to us. So I've had to look for a different solution,
and I think I've found one.
We could change the touchscreen driver (s3c2410_ts.c) to report
BTN_STYLUS rather than BTN_TOUCH.
This would have the effect of making it not appear like a mouse to
mousedev, so it will not be translated into events on /dev/input/mice.
(see mousedev_ids in linux/drivers/input/mousedev.c).
We then need to make sure that this doesn't break any programs (that
cannot be fixed).
- it doesn't break tslib as that can survive happily with just the
EV_PRESSURE events (it only notices BTN_TOUCH for finger-up events,
and it gets them from EV_PRESSURE as well).
- it doesn't break fso/framework, unless someone explicitly puts an
explicit 'report' request in frameworkd.conf for the magic number
for BTN_TOUCH, and that could easily be fixed.
What other programs listed on the touchscreen directly? Presumably
Qtopia does. Can anyone suggest where I'd find the touchscreen driver
for it (I don't suppose it uses tslib??).
So my proposed fix process would be:
1/identify all programs that listen on the touchscreen and make
sure they can be happy with BTN_STYLUS or ABS_PRESSURE
2/change s3c2410_ts drivers to report BTN_STYLUS rather than
3/remove tslib-input_raw-grab_events.patch from tslib
4/remove fix-EVIOCGRAB-semantics.patch from the kernel.
Does this seem acceptable?
Can anyone help with point 1??
More information about the openmoko-kernel