Re: evdev types

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

On Mon, Apr 15, 2002 at 04:23:09PM +1000, Brad Hards wrote:

> Gday all,
> 
> In my continuing journey of documentation, I got to EVIOCGID, which returns 
> short[4]. Is there any reason why that couldn't be a 
> struct evdev_ident (or input_ident)
> {
> 	uint16_t bustype;
> 	uint16_t vendor_id;
> 	uint16_t product_id;
> 	uint16_t version;
> };

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

> Similarly, 
> struct ff_replay probably should be
> {
>         uint16_t length;           /* Duration of an effect */
>         uint16_t delay;            /* Time to wait before to start playing an 
> effect */
> };
> 
> because __u16 is inherently non-portable (refer Linux Device Drivers book, 
> Chapter 10), not to mention being even uglier than the [type]_t notation. No 
> mean feat :)
> 
> And same principle for the other ff_ structures.
> 
> The followon from this would be for the internal struct input_dev to contain a 
> struct evdev_ident (or input_ident) instead of the 
>         unsigned short idbus;
>         unsigned short idvendor;
>         unsigned short idproduct;
>         unsigned short idversion;
> 
> Any thoughts?

Feel free to submit a patch. :) I'll most likely accept it.

-- 
Vojtech Pavlik
SuSE Labs