Questions regarding libevdev

[Nayan Deshmukh]

Thanks for the information Peter!!

I'll send out a patch which adds a note to the documentation.

On Thu, Mar 21, 2019, 8:38 AM Peter Hutterer <peter.hutterer at who-t.net
wrote:

> On Thu, Mar 21, 2019 at 09:42:11AM +1100, Callum Oz wrote:
> > (Sending this email again, since I wasn't on the mailing list and I think
> > it was blocked the first time).
> >
> > Peter,
> >
> > We don't have a requirement to "set" the field more than 16 bits, it's
> just
> > a quirk that we noticed.
> > If I understand correctly the `int` type is larger than 16 bits.
>
> That's not guaranteed, technically it could be 2 or 4 bytes though I don't
> know which architectures it would be 2 bytes on, certainly none I had to
> worry about over the last 10 years. That's one of the reasons I started
> using stdint everywhere, but that enlightenment only came after the
> libevdev
> API was set in stone.
>
> > My C isn't the best, but this example should demonstrate why I'm
> confused:
> >
> > ```c
> > #include <stdio.h>
> >
> > int main() {
> >    int x = 70000;
> >    printf("x: %d", x); // Not truncated to 16 bits
> >
> >    short y = 70000;
> >    printf("y: %d", y); // This IS truncated
> >
> >   return 0;
> > }
> > ```
> >
> > Whereas using the `short` type would accurately display the value as 16
> > bits.
> >
> > We're writing bindings for libevdev to Rust, and wanted to get the types
> > right.
> > In our tests we noticed that although the API's return type is `int`,
> it's
> > being
> > treated as something smaller and is getting truncated to 16 bits.
>
> yeah, it's a bug with the API but unfortunately we cannot change this
> without breaking the ABI. And that's a no-go. The values are guaranteed to
> be a short though, simply by how libevdev wraps the kernel. So you can
> write
> the rust bindings to take a uint16 instead and you'll be safe and have a
> better API at the same time.
>
> I'll happily merge a libevdev patch that documents this for the affected
> functions :)
>
> I'm assuming you're already aware of https://github.com/ndesh26/evdev-rs
> given that Nayan is on the CC list but let me leave the link here anyway :)
>
> Cheers,
>    Peter
>
> PS: thanks for reaching out. talking to the library maintainers/authors is
> always the best option and better than taking documentation/code at face
> value.
>
> > On Thu, Mar 21, 2019 at 9:39 AM Callum Oz <acheronfail at gmail.com> wrote:
> >
> > > Peter,
> > >
> > > We don't have a requirement to "set" the field more than 16 bits, it's
> > > just a quirk that we noticed.
> > > If I understand correctly the `int` type is larger than 16 bits.
> > >
> > > My C isn't the best, but this example should demonstrate why I'm
> confused:
> > >
> > > ```c
> > > #include <stdio.h>
> > >
> > > int main() {
> > >    int x = 70000;
> > >    printf("x: %d", x); // Not truncated to 16 bits
> > >
> > >    short y = 70000;
> > >    printf("y: %d", y); // This IS truncated
> > >
> > >   return 0;
> > > }
> > > ```
> > >
> > > Whereas using the `short` type would accurately display the value as 16
> > > bits.
> > >
> > > We're writing bindings for libevdev to Rust, and wanted to get the
> types
> > > right.
> > > In our tests we noticed that although the API's return type is `int`,
> it's
> > > being
> > > treated as something smaller and is getting truncated to 16 bits.
> > >
> > > Regards,
> > > Cal
> > >
> > > On Thu, Mar 21, 2019 at 9:24 AM Peter Hutterer <
> peter.hutterer at who-t.net>
> > > wrote:
> > >
> > >> On Thu, Mar 21, 2019 at 12:14:25AM +0900, Nayan Deshmukh wrote:
> > >> > Hello,
> > >> >
> > >> > We have encountered a quirky behavior of libevdev and wanted to make
> > >> > sure that it is known and intentional quirk.
> > >> >
> > >> > Whenever I set the version for a device through
> > >> > `libevdev_set_id_version`, the value set is truncated at 65,535
> which
> > >> > is the max value of unsigned short. Any thoughts on this?
> > >>
> > >> the id_version sets/gets the struct input_id's version field, from
> > >> linux/input.h. That's a uint16 so we mirror the kernel API here.
> > >> The same applies to the other libevdev_set_id_* fields, those are 16
> bit
> > >> only too.
> > >>
> > >> Many drivers don't really use that version field at all, so it's
> largely
> > >> ignored by userspace anyway. Out of interest - what do you need it be
> > >> bigger
> > >> than 16 bits for?
> > >>
> > >> Cheers,
> > >>    Peter
> > >>
> > >
>