On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote: > I don't doubt that the use cases should be catered for, I essentially > did that same work without kernel changes for GNOME. What I doubt is > the fuzzy semantics, the fact that the device is kept opened but no > data is sent (that's not power saving), that whether users are revoked > or should be revoked isn't clear, and that the goal is basically to > work around stupid input handling when at the console. When running a > display manager, this is all avoided. > > If this were to go through, then the semantics and behaviour needs to > be better explained, power saving actually made possible, and make sure > that libinput can proxy that state to the users on the console. Or an > ioctl added to the evdev device to disable them. So, do you mean to implement this "disable" action as ioctl for particular /dev/input/event* device (instead of sysfs entry)? -- Pali Rohár pali.rohar@xxxxxxxxx -- 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
