On Friday, October 28, 2016 2:46:42 PM CEST Peter Hutterer wrote: > On Thu, Oct 27, 2016 at 03:24:55PM -0700, Deepa Dinamani wrote: > > On Wed, Oct 26, 2016 at 7:56 PM, Peter Hutterer > > <peter.hutterer@xxxxxxxxx> wrote: > > > On Mon, Oct 17, 2016 at 08:27:32PM -0700, Deepa Dinamani wrote: > > > general comment here - please don't name it "raw_input_event". > > > First, when you grep for input_event you want the new ones to show up too, > > > so a struct input_event_raw would be better here. That also has better > > > namespacing in general. Second though: the event isn't any more "raw" than > > > the previous we had. > > > > > > I can't think of anything better than struct input_event_v2 though. > > > > The general idea was to leave the original struct input_event as a > > common interface for userspace (as it cannot be deleted). > > So reading raw data unformatted by the userspace will have the new > > struct raw_input_event format. > > This was the reason for the "raw" in the name. > > > > struct input_event_v2 is fine too, if this is more preferred. I think input_event_v2 would be more confusing. An alternative to raw_input_event might be __kernel_input_event, which parallels things like __kernel_off_t that is also independent from the user space off_t in the same way that the user space input_event structure will get redefined in a way that is incompatible with the kernel ABI. > > >> This replaces timeval with struct input_timeval. This structure > > >> maintains time in __kernel_ulong_t or compat_ulong_t to allow > > >> for architectures to override types as in the case of x32. > > >> > > >> The change requires any userspace utilities reading or writing > > >> from event nodes to update their reading format to match > > >> raw_input_event. The changes to the popular libraries will be > > >> posted along with the kernel changes. > > >> The driver version is also updated to reflect the change in > > >> event format. > > > > > > Doesn't this break *all* of userspace then? I don't see anything to > > > negotiate the type of input event the kernel gives me. And nothing right now > > > checks for EVDEV_VERSION, so they all just assume it's a struct > > > input_event. Best case, if the available events aren't a multiple of > > > sizeof(struct input_event) userspace will bomb out, but unless that happens, > > > everyone will just happily read old-style events. > > > > > > So we need some negotiation what is acceptable. Which also needs to address > > > the race conditions we're going to get when events start coming in before > > > the client has announced that it supports the new-style events. > > > > No, this does not break any userspace right now. > > Both struct input_event and struct raw_input_event are exactly the same today. > > oh, right, the ABI is the same. I see that now, thanks. One minor difference is that the seconds in raw_input_event are 'unsigned', so even with the 'real' time domain, we can represent times from 1970 to 2106, whereas 'timeval' represents times between 1902 and 2038. Once user space has a 64-bit time_t and the conversion function in libinput that Deepa suggested, the raw_input_event is only used on the kernel ABI and the normal timestamps will work fine. > > And, hence any library that results in a call to libevdev_set_fd() > > will fail if it is not this updated driver. > > without having seen the libevdev patch - that sounds like a bad idea . there > are plenty of usecases where libevdev_set_fd() is called but timestamps in > events just don't matter. So we may need need some more negotiation between > the library user, libevdev and the kernel. I also don't see any strict dependency at all: the binary data format has not changed, and I agree we absolutely should not break running a newly built library on old kernels. We can also safely assume that any user space that is actually built for 64-bit time_t is also running on a recent enough kernel, as today's kernels do not support 64-bit time_t yet. Arnd -- 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
