Re: [PATCH] Expose input device usages to userspace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tuesday 14 March 2006 06:26, Dmitry Torokhov wrote:
> On Monday 13 March 2006 16:02, Arjan van de Ven wrote:
> > On Mon, 2006-03-13 at 21:54 +0100, Elias Naur wrote:
> > > Hi,
> > >
> > > I believe that the current event input interface is missing some kind
> > > of information about the general kind of input device (Mouse, Keyboard,
> > > Joystick etc.) so I added a simple ioctl to do just that. The relevant
> > > line in include/linux/input.h is:
> > >
> > > #define EVIOCGUSAGE(len)    _IOC(_IOC_READ, 'E', 0x1c, len)         /*
> > > get all usages */
> > >
> > > It returns a bit set with the device usages. Current usages are:
> > >
> > > #define USAGE_MOUSE         0x00
> > > #define USAGE_JOYSTICK      0x01
> > > #define USAGE_GAMEPAD       0x02
> > > #define USAGE_KEYBOARD      0x03
> >
> > I'm not sure that this is a good idea in general.
> > However when you do it, at least make it a bitmap; things can be both a
> > mouse and a keyboard for example.
>
> No, I don't think this is needed at all - users should be interested in
> what capabilities a particular device has, not what type it was assigned
> by soneone.

I see your point that an application should not rely too much on device 
usages. However, the main reason I want device usages is to help applications 
and users identify and (visually) represent devices. For example, games could 
show an appropriate icon graphic representing each active device. The event 
interface already has a few other ioctls for this kind of information:

 - The name (EVIOCGNAME).
 - The ID (EVIOCGID). IMHO, device usages are more useful than the "bustype" 
field of struct input_id.
 - The physical location (EVIOCGPHYS).

And speaking of capabilities, the event interface already exposes "types 
assigned by someone" to each device component (ABS_X, KEY_ESC, BTN_TRIGGER 
etc.). If no vendor assigned types should be exposed, only the raw capability 
(a type (abs axis, rel axis, key) and a struct input_absinfo for absolute 
axes) needed to interpret component values would be needed.

 - elias
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux