Re: evdev types

[Brad H. <bh...@bi...>]

On Wed, 17 Apr 2002 23:18, Vojtech Pavlik wrote:
> On Wed, Apr 17, 2002 at 09:56:05PM +1000, Brad Hards wrote:
<snip>
> > Ah, I think I have it now. For
> >
> > ioctl(a, EVIOCGBIT(b, c), d)
> >
> > a is the file descriptor for the event device you want
> >
> > b is the type of descriptor bitfield to return
> > 	0 for the type of descriptors that are used
> > 	EV_KEY for the key bitfield
> > 	EV_REL for the relative axes bitfield
> > 	EV_ABS for the absolute axes bitfield
> > 	EV_MSC for the miscellaneous bitfield (not used yet?)
> > 	EV_LED for the bright lights bitfield
> > 	EV_SND for the loud noises bitfield
> > 	EV_REP for the repeat function bitfield (not used yet?)
> > 	EV_FF for the force feedback bitfield
> >
> > c is the maximum number of bits to return
> > 	If the number of bits available is greater, then you get a warning
> > message
>
> Bytes.
Actually, it is more complex than that. The code all assumes that there is a 
long on the other end.
So my sample code for reading LED values (simplified here for shortness, let 
me know if you want it all):
<programlisting>
  uint8_t led_bitmask[LED_MAX/8 + 1];
...
  ioctl(fd, EVIOCGBIT(EV_LED, sizeof(led_bitmask)), led_bitmask)
</programlisting>

is hitting the truncation check, because I'm only providing two bytes, and it 
wants to return four (long, on ix86). Makes a mess in my syslog, and yet it 
is reasonable from an application point of view, since the led_bitmask 
doesn't really need to be an array - I could have just malloc'd it, and it is 
big enough to hold all valid bit settings.

Why use long arrays for the bitfields? Why not byte arrays? This seems like 
the easiest way to clean up your concerns with 32/64 split systems, and also 
to clean up this.


> > OK, my only question now is "how do you get the descriptor bitfield for
> > EV_RST?"
>
> There is none. There are no bits for EV_RST, it's only one event in its
> own class.
OK. This also applies to EV_REP?

Thanks again for all your help.

Brad