Re: evdev types

[Vojtech P. <vo...@su...>]

On Wed, Apr 17, 2002 at 11:58:31AM +1000, Brad Hards wrote:
> 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.

Not really a 2d bitfield, more like a bunch of 1d bitfields with uneven
lengths. You pass an argument selecting which one you want and you get
it. I think EVIOCGBIT is quite OK, because it doesn't really depend on
the data type ... it just copies a chunk of memory.

What is probably the only wrong w/ the bit arrays is the way they're
passed through by /proc and hotplug support. And that can be fixed
without any major pain, because noone is using that on 64-bit systems
yet.

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

I think that'd be

	ioctl(fd, EVIOCGBIT(EV_KEY, sizeof(my_buffer)), buffer);

> 
> Is this all basically true?
> 
> What is EV_RST?

An RESET event. It's sent to reset the device or received when the
device was reset. Currently unused, but planned for use with possible
recalibration (after changing the EVIOCGABS boundaries) of touchscreen and
joystick devices.

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

Yes. There is more different key types than joystick or mouse axis
types.

-- 
Vojtech Pavlik
SuSE Labs