Re: [RFC][PATCH] POSKeyboard driver for exclusive keyboard access

[Niels de Vos]

Hello Dmitry,

Dmitry Torokhov wrote:
> Hi Niels,
> 
> On Fri, Aug 22, 2008 at 06:17:28PM +0200, Niels de Vos wrote:
>> This new driver makes it possible for middleware like JavaPOS to use
>> a POSKeyboard (connected to PS/2) with exclusive access. This is
>> required by the UnifiedPOS Specification which is available from
>> http://www.nrf-arts.org/UnifiedPOS. Any middleware using this driver
>> should implement the full exception-handling in user-space. Therefor
>> it is possible to use specific POS-extensions of POSKeyboards, without
>> abusing other keyboard-drivers.
>>
>> Opening /dev/poskeyboard will route all scancodes to this device. The
>> scancodes will not be processes by the input-subsystem anymore. Reading
>> /dev/poskeyboard results in receiving the scancodes as raw data for
>> further processing by the reader. Sending commands to the hardware can
>> be done by writing to /dev/poskeyboard.
>>
>> If the driver is loaded and /dev/poskeyboard is not opened, all
>> scancodes are given to the input-subsystem. This allows 'normal' use of
>> the keyboard.
>>
>> Making the driver active involves some commands like the following:
>>    echo -n serio1 > /sys/bus/serio/drivers/atkbd/unbind
>>    echo -n serio1 > /sys/bus/serio/drivers/poskbd/bind
>>
> 
> It seems you have just reimplemented serio_raw driver, therefore NAK.
> Right now serio_raw is limited to untranslated ports but adding
> SERIO_I8042XL signature should be easy.

Okay, thanks for pointing this out, I'll look into using serio_raw
instead. If a patch is needed I'll send you one.


>> Open questions:
>> - How to achieve the same with USB-HID complaint keyboards?
> 
> Thsi is probably is the candidate for legitimate use of EVIOCGRAB.
> Just grab device for exclusive access and do your processing, probably
> looking at MSC_SCAN (or KEY_*, depends on how hardware-sepcific this
> thing is). This approach shoudl work equally well for HID, PS/2,
> serial or any other kind of keyboard/input device actually. You can
> also re-inject the keystrokes you are not interested in back into
> input core via uinput.

Great. I already saw input_dev->grab but never really understood what
it would do or how it could be used. Tried it with a small test and
should be sufficient for the UnifiedPOS requirements.


>> - Does serio_unregister_port() a kfree() on the port?
> 
> Eventually, after the last user drops off.

Okay, so the driver allocates it, but never needs to do a kfree() on
it, because the serio-layer takes care of it.

Thanks for the infos,
Niels

Attachment: signature.asc
Description: OpenPGP digital signature