On Thu, Oct 27, 2016 at 01:39:30PM -0700, Deepa Dinamani wrote:

quoted

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.

oh, right. I thought this was in the path for uinput_write(). sorry about
that.

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.

I can say I've never done the read from the uinput device, never even
occured to me. quick skim of the code looks like this only matters for
force_feedback stuff. can't really comment on that too much.

Cheers,
   Peter