27 Oct
2016
27 Oct
'16
8:39 p.m.
hmm, I'm a bit confused here. This is an in-kernel bit only (passing the time through uinput events has no effect). So why do we need an ioctl here? it's an in-kernel decision only anyway and the time in the events sent to the evdev client should be dictated by what that client sets for the clock type, right?
This is for input events queued by the uinput driver for the virtual input device. This can be read through uinput_read() fops. I don't think anybody is doing a read on uinput nodes, so another option(Arnd and I considered this) could be not supporting reads on these nodes at all.
This is not related to evdev events in the kernel. Currently, this timestamp could be the same format as the evdev timestamps or not.
-Deepa