Re: Possible Interface Shortcoming with input.h/input.c

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

On Sat, Apr 06, 2002 at 04:18:32PM -0500, Thomas H Hendrick wrote:
> I've noticed while looking over the code for input.h and input.c, that there
> seems to be no method for performing control commands (ioctl's for example) from
> the user-side of things on the device-provider, only the device-handler.
> 
> The user can use ioctl on the general event device [/dev/input/eventXX]
> (evdev.o) to perform some general things, such as change the keymap and get the
> version number of the evdev driver.  However, some modules might benefit from a
> layered mechanism for ioctl to get down to the device-side of things through the
> input layer.  I don't know which, however.
> 
> In a nutshell:
> to "struct input_dev" in input.h:
> + int (*ioctl)(struct input_dev *dev, struct file* file, unsigned int cmd,
> unsigned long arg );
> 
> and export in input.c:
> + int input_dev_ioctl( struct input_dev *dev, struct file *file, unsigned int
> cmd, unsigned long arg );
> 
> This is an interface change, I realize.  Mostly this is up for discussion, and
> is not really a proposal, per se.
> 
> Now, what would this buy us?  The user could send ioctl commands to the device
> provider as well as the device-handler.  However, the question is, is there
> anything in the device provider that the user needs to access and control that
> we can't already?  The only thing that comes to mind is "Get Low-Level Driver
> Version" which is TOTALLY not worth adding interface changes for.  However, if
> anyone else can think of other device providers that could benefit from this, it
> might be a useful change.

If we'll need it, we'll add it. But this would mean that this ioctl
function (and the stuff it controls) can only be invoked from device
handlers that can handle ioctls. And that isn't good.

> At the very least, I'd like to hear people's thoughts on it.
> 
> Now, the immediate problem of loading the keymap from user space already solved,
> since the input_dev->keymap pointer points to the low-level keymap array.  We
> just need a util from user-space to spend a lot of time chewing some ioctl's.  I
> may, however, add an IOCTL symbol to evdev.c to transfer them in bulk, (or at
> least more than one key per syscall). 

You can if you wish, but the transfer time saved by that isn't probably
worth the time spent coding the new IOCTL. If you implement that, please
remove the original IOCTLs - I definitely don't want to have more than
one way of doing the same thing - it always introduces bugs and
confusion for programmers trying to write for the API.

> I can take care of the user-space util pretty easily. I'm not sure,
> however, if we can detect the keyboards in atkbd.c in order to provide
> the correct keymap for the keyboard being used automagically.

In the past, I experimented with AT-keyboard fingerprinting, which could
tell about 20 different keyboard types from each other. It's possible,
but it takes long time (a minute or so) to detect the keyboard type. And
it can never detect all keyboard types from each other, because for some
the fingerprints are identical.

Because of that, atkbd.c only detects some basic keyboard types and
stuffs that into the idproduct and idversion fields.

> input_dev->idbus = BUS_I8042;
> input_dev->idvendor = 0x0001;        /* Not useful */
> input_dev->idproduct = atkbd->set;    /* This tells us if it is extend(set 4),
> set 3 or set 2 */
> input_dev->idversion = atkbd->id;        /* This is the id reported by the port,
> and is 0xab83 for most */
> 
> You'd think the user would know what keyboard they were using, and could load it
> themselves, unless of course, their keyboard doesn't work natively /without/
> loading the keyboard.

There will always be a 'default' map - the one hardcoded in the module.
And it'll work for 99.999% of keyboards well enough for the user to type
and load a more appropriate map (with all the internet/multimedia keys
enabled) himself.

> Anyways, just some thoughts before I head to the grocery store.  ;)

-- 
Vojtech Pavlik
SuSE Labs