On Fri, Jan 06, 2012 at 09:14:34PM +0100, Henrik Rydberg wrote: > On Fri, Jan 06, 2012 at 12:02:40PM -0800, Dmitry Torokhov wrote: > > On Fri, Jan 06, 2012 at 08:48:15PM +0100, Henrik Rydberg wrote: > > > > > Ok, maybe not to so easy after all, which probably answers my own > > > > > question. Looks like a EVIOCGMTSLOT, taking both slot and event code > > > > > as argument, would be the cleaner route to take. Another ioctl, how do we > > > > > feel about that? > > > > > > > > What's the problem with userspace locking? > > > > > > The idea was to get by without it. > > > > > > Regarding ioctls, it does not seem realizable due to ioctl number > > > exhaustion. > > > > I am prettu sure we cabn spare 1 ioctl number. We just need to pass slot > > number not as part of ioctl number but in data instead. Like > > EVIOCGKEYCODE works. > > Right, thanks. Perhaps we could even pass it as result data - > returning all mt data in one go? With the purpose being to capture the > full MT state, it ought to be both simpler and faster. Yes, if caller passes buffer size and buffer address we can return all data in one go. We just need to make _really sure_ we are using 32/64 bit safe interface. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
