On Mon, Jan 20, 2014 at 01:53:13PM -0800, Dmitry Torokhov wrote: > Hi Benjamin, > > On Fri, Jan 17, 2014 at 02:12:51PM -0500, Benjamin Tissoires wrote: > > Evemu [1] uses uinput to replay devices traces it has recorded. However, > > the way evemu uses uinput is slightly different from how uinput is > > supposed to be used. > > Evemu relies on libevdev, which creates the device node through uinput. > > It then injects events through the input device node directly (and it > > completely skips the uinput node). > > > > Currently, libevdev relies on an heuristic to guess which input node was > > created. The problem is that is heuristic is subjected to races between > > different uinput devices or even with physical devices. Having a way > > to retrieve the sysfs path allows us to find the event node without > > having to rely on this heuristic. > > I have been thinking about it and I think that providing tight coupling > between uinput and resulting event device is wrong thing to do. We do > allow sending input events through uinput interface and I think evemu > should be using it, instead of going halfway through uinput and halfway > though evdev. Replaying though uinput would actually be more correct as > it would involve the same code paths throgugh input core as with using > real devices (see input_event() vs. input_inject_event() that is used by > input handlers). this isn't just about evemu. I've got a fair number of tests that create a uinput device and then pass the device node to the next level. for example, you may want to create a synaptics touchpad through uinput and then test the xorg driver against it. I can't pass the uinput fd to the xorg driver, it only takes a device node. in fact, virtually all the interactions I have with uinput is of that form - create a device, hook something up to the device and then do stuff. it's not the writing side that I need this ioctl for, it's making sure whatever is _reading_ from it is hooked up to the right device. Cheers, Peter -- 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
