Questions regarding libevdev

[Peter Hutterer]

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
> >>
> >