<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=Big5" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> 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 提到: <blockquote cite="mid:20071128124655.GP15556@intune.research.nokia.com" type="cite"> <pre wrap="">On Wed, Nov 28, 2007 at 11:42:25AM +0800, ext itrs lin wrote: </pre> <blockquote type="cite"> <pre wrap="">The code does same thing as existing code and why this is a layer violation and existing one is not ? </pre> </blockquote> <pre wrap=""> Which existing code? </pre> <blockquote type="cite"> <pre wrap="">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 . </pre> </blockquote> <pre wrap=""> 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 </pre> </blockquote> </body> </html>