input: mt: Document the MT event slot protocol (rev2)
in [Kernel]
|
Prev: [GIT PULL v2 0/5] perf tools fixes and improvements
Next: [RESEND -v2][PATCH 3/3] mem-hotplug: fix potential race while building zonelist for new populated zone
From: Dmitry Torokhov on 24 May 2010 13:30 On Monday 24 May 2010 10:06:15 am Ping Cheng wrote: > On Mon, May 24, 2010 at 8:59 AM, Dmitry Torokhov > > <dmitry.torokhov(a)gmail.com> wrote: > > On Sun, May 23, 2010 at 11:07:27PM -0700, Ping Cheng wrote: > >> On Sun, May 23, 2010 at 9:58 PM, Peter Hutterer > >> > >> <peter.hutterer(a)who-t.net> wrote: > >> >> > And yes, you could add it once we find it's an issue, but by then > >> >> > someone has already spent time to work around this. And when you > >> >> > then start sending slot events all the time, you admit that > >> >> > writing the workaround was just a time waster :) > >> >> > >> >> Work around what, exactly? > >> > > >> > I was referring to having a protocol where processes has to ignore > >> > contacts already down until they've been there when a contact was > >> > pressed (and your comment that if this becomes an issue it could be > >> > added lateron). Now, the ignoring part needs to be written (this is > >> > the "workaround" referred to above). if you're planning to add it > >> > later, we need to cater for that part as well then, having two > >> > implementations depending on the kernel versions. > >> > > >> > but this is just for clarification, it's a moot point anyway given > >> > that button events have the same behaviour. > >> > >> This topic is outside of the _MT_ protocol discussion. > >> > >> However, it is indeed an issue with all filtered input events, both > >> for MT and regular ones. > >> > >> I think we need to add an ioctl to enable user land driver/client to > >> signal the kernel driver to send all events without filtering, just > >> once. Hot-plugged devices and X driver starts after user has contacted > >> with the device are two examples that the client would miss filtered > >> events. > >> > >> Dmitry, do you think it is a valid suggestion? > > > > What about using EVIOCGKEY/EVIOCGSW/EVIOCGABS? > > Those EVIOCs only give us the static values (max/min/supported keys, > etc.). We need their dynamic input data here, the actual x, y, > button, pressure, etc. Am I missing something about those EVIOs? > Yes you are ;) Supported events are reported via EVIOCGBIT, EVIOCGKEY and EVIOCGSW will return current state of keys/switches. As far as EVIOCGABS goes, it also returns, besides min/max/etc, last reported _values_ of the ABS_* events. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ping Cheng on 24 May 2010 13:40 On Mon, May 24, 2010 at 10:21 AM, Dmitry Torokhov <dmitry.torokhov(a)gmail.com> wrote: > On Monday 24 May 2010 10:06:15 am Ping Cheng wrote: >> >> This topic is outside of the _MT_ protocol discussion. >> >> >> >> However, it is indeed an issue with all filtered input events, both >> >> for MT and regular ones. >> >> >> >> I think we need to add an ioctl to enable user land driver/client to >> >> signal the kernel driver to send all events without filtering, just >> >> once. Hot-plugged devices and X driver starts after user has contacted >> >> with the device are two examples that the client would miss filtered >> >> events. >> >> >> >> Dmitry, do you think it is a valid suggestion? >> > >> > What about using EVIOCGKEY/EVIOCGSW/EVIOCGABS? >> >> Those EVIOCs only give us the static values (max/min/supported keys, >> etc.). �We need their dynamic input data here, the actual x, y, >> button, pressure, etc. Am I missing something about those EVIOs? >> > > Yes you are ;) Supported events are reported via EVIOCGBIT, EVIOCGKEY and > EVIOCGSW will return current state of keys/switches. As far as EVIOCGABS > goes, it also returns, besides min/max/etc, last reported _values_ of the > ABS_* events. Oh, My God! I should have listened to Mark Twain :). Ping -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Henrik Rydberg on 24 May 2010 13:50 Dmitry Torokhov wrote: [...] >>>> I think we need to add an ioctl to enable user land driver/client to >>>> signal the kernel driver to send all events without filtering, just >>>> once. Hot-plugged devices and X driver starts after user has contacted >>>> with the device are two examples that the client would miss filtered >>>> events. >>>> >>>> Dmitry, do you think it is a valid suggestion? >>> What about using EVIOCGKEY/EVIOCGSW/EVIOCGABS? >> Those EVIOCs only give us the static values (max/min/supported keys, >> etc.). We need their dynamic input data here, the actual x, y, >> button, pressure, etc. Am I missing something about those EVIOs? >> > > Yes you are ;) Supported events are reported via EVIOCGBIT, EVIOCGKEY and > EVIOCGSW will return current state of keys/switches. As far as EVIOCGABS > goes, it also returns, besides min/max/etc, last reported _values_ of the > ABS_* events. > Ping is not alone. :-) But it does not work for MT events -- yet. Henrik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dmitry Torokhov on 24 May 2010 14:10 On Mon, May 24, 2010 at 07:48:00PM +0200, Henrik Rydberg wrote: > Dmitry Torokhov wrote: > [...] > >>>> I think we need to add an ioctl to enable user land driver/client to > >>>> signal the kernel driver to send all events without filtering, just > >>>> once. Hot-plugged devices and X driver starts after user has contacted > >>>> with the device are two examples that the client would miss filtered > >>>> events. > >>>> > >>>> Dmitry, do you think it is a valid suggestion? > >>> What about using EVIOCGKEY/EVIOCGSW/EVIOCGABS? > >> Those EVIOCs only give us the static values (max/min/supported keys, > >> etc.). We need their dynamic input data here, the actual x, y, > >> button, pressure, etc. Am I missing something about those EVIOs? > >> > > > > Yes you are ;) Supported events are reported via EVIOCGBIT, EVIOCGKEY and > > EVIOCGSW will return current state of keys/switches. As far as EVIOCGABS > > goes, it also returns, besides min/max/etc, last reported _values_ of the > > ABS_* events. > > > > Ping is not alone. :-) > > But it does not work for MT events -- yet. > Yes, this is true. I think the most interesting is the switch data, since they may not change at all. The rest is transient and should refresh "fairly quickly". -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Henrik Rydberg on 24 May 2010 15:20
Dmitry Torokhov wrote: > On Mon, May 24, 2010 at 07:48:00PM +0200, Henrik Rydberg wrote: >> Dmitry Torokhov wrote: >> [...] >>>>>> I think we need to add an ioctl to enable user land driver/client to >>>>>> signal the kernel driver to send all events without filtering, just >>>>>> once. Hot-plugged devices and X driver starts after user has contacted >>>>>> with the device are two examples that the client would miss filtered >>>>>> events. >>>>>> >>>>>> Dmitry, do you think it is a valid suggestion? >>>>> What about using EVIOCGKEY/EVIOCGSW/EVIOCGABS? >>>> Those EVIOCs only give us the static values (max/min/supported keys, >>>> etc.). We need their dynamic input data here, the actual x, y, >>>> button, pressure, etc. Am I missing something about those EVIOs? >>>> >>> Yes you are ;) Supported events are reported via EVIOCGBIT, EVIOCGKEY and >>> EVIOCGSW will return current state of keys/switches. As far as EVIOCGABS >>> goes, it also returns, besides min/max/etc, last reported _values_ of the >>> ABS_* events. >>> >> Ping is not alone. :-) >> >> But it does not work for MT events -- yet. >> > > Yes, this is true. > > I think the most interesting is the switch data, since they may not change > at all. The rest is transient and should refresh "fairly quickly". > Still, if one allows EVIOCSABS(ABS_MT_SLOT) to set a slot state in evdev instead of modifying the input_dev, one could extract all ABS_MT events in sequence via EVIOCGABS. Henrik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |