[PATCH] export NumLock/CapsLock/ScrollLock event through addon-input.c

[Sam Lin]

Dear Sirs,

The patch is applied to hald/linux/addons/addon-input.c -- an addon
instead of HAL core.

The whole idea of addon-input is a daemon monitoring input device
(keyboard) and expose events through
HAL DBus interface org.freedesktop.Hal.Device Condition signal for
global event trigger

The patch is nothing but adding more events to get exposed in addition
to existing events
(ex. "volume-up", "brightness-up", "wlan" ...)

The philosophy is exactly same as existing design.
What I can't understand is why this is layer violation if existing
design is not.

The addon is designed exactly for this purpose isn't it ?

p.s The design is also for non-X system

Best regards,
Sam


Daniel Stone 提到:
> On Wed, Nov 28, 2007 at 11:42:25AM +0800, ext itrs lin wrote:
>   
>> The code does same thing as existing code and why this is a layer violation
>> and existing one is not ?
>>     
>
> Which existing code?
>
>   
>> It just get LED status change instead of setting it and this make OSD design
>> clean and clear without polling LED status and make unnecessary Xlib
>> dependency .
>>     
>
> If you want a framebuffer-based on-screen display, then good luck to
> you, I guess.  You mentioned systray though, and that's a huge layering
> violation.
>
> Put it this way.  On the Nokia tablets (so I assume your tablets are
> somewhat similar), the user presses a key, which wakes up the keyboard
> controller, which fires an interrupt; we query the status over the SPI
> bus to get the key information, this comes through the Linux kernel
> event interface, and then to the X server, which delivers it through to
> clients.  HAL is involved in device discovery.
>
> Note how the clients in this case only ever interact with the X server.
> This means that all kinds of assumptions can be and are made, including
> clients faking keypresses, etc.
>
> I just don't see why you'd want to violate this (and ignore years of
> precedent) by going directly to HAL and ignoring the thing which already
> handles all your input.  But, in the OSD case, you're already ignoring
> the thing which does all your rendering and scribbling on the
> framebuffer anyway, so it probably makes sense, given that.
>
> Cheers,
> Daniel
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/hal/attachments/20071129/4c81b975/attachment.html