Re: evdev types

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

On Mon, 15 Apr 2002 22:14, Vojtech Pavlik wrote:
> On Mon, Apr 15, 2002 at 08:41:33PM +1000, Brad Hards wrote:
> > On Mon, 15 Apr 2002 17:40, Vojtech Pavlik wrote:
> > > Yes, if this is cleaner. I have much bigger worries about the size of
> > > 'long' in EVIOCGBIT and /proc/bus/input/devices output on archs that
> > > support mixed 32/64-bit binaries (SPARC, PPC, x86-64).
> >
> > Oh. Ugly.
>
> Yeah. setbit() et al work on longs, and longs are OK in an API which
> isn't on a mixed 32/64-bit arch. But since the 32/64 bit stuff happens,
> it gets pretty ugly.
OK, I have looked at it some more, and it is scaring me quite a bit :)

The approximate plan is to return a 32 bit quantity (uint32_t or __u32, 
depending on whether Greg convinces me or not).

I am not sure I really understand what EVIOCGBIT is doing. It looks like it 
returns a 2-d bitfield array, where one dimension is the event type, and the 
other dimension is a index of possible options within that event type. The 
"zeroth" option is whether that event type is supported at all by the device.

The result can be constrained by arguments so
ioctl(fd, EVIOCGBIT[EV_KEY,EV_KEY], result[0])
will only return the options for keys, as a bitfield array.

Is this all basically true?

What is EV_RST?

Is the limit on KEY_MAX (in evtest.c) showing that there will probably always 
be more KEY options that RELative or ABSolute options?

Brad