On Thu, 15 Jan 2015 07:20:21 +0000 Yang Andy <[email protected]> wrote:
> Hi Pekka > > Thank you for your reply. > > >I think you have a fundamental problem here: global hotkeys cannot > >be in any way associated with keyboard focus. That is their whole > >point: they must work without any focus. So a design that relies > >on focus or focus switching is broken from the start.I agree with > >you opinion,so i change my software degsin as below: > > My hardkey device consist of tow category. > Category1:Radio/Mute/Navi and so on--which is hotkey > Category2:Left/Right/Down/Up/Enter--which should be accociated with > windows.. > > About hardkeys of Category1,i design new protocol extension. > About hardkeys of Category2,i extend wl_keyboard protocol. > > I think the software design of Category2 would have some risk. > My detail design as below: > 1.Add new input device whick is classified as keyboard input at the > kernel driver to weston. 2.Weston polls(read) evdev of the new input > device. 3.When weston get the evdev,send the event as the keyboard > event to the QT/EFL. > > Would you give me some advice? Hi, sorry, I have no idea what you are trying to do on a high, semantical level. I suppose radio/mute/navi key events are something you want to deliver to one specific client at all times, regardless of any focus. If yes, adding a new protocol extension to deliver exactly those as semantic events would be fine. However, I don't understand what you want with left/right/down/up/enter. What's wrong with just the standard wl_keyboard protocol, if those events need to go to the client/surface currently holding the keyboard focus? So, what does the "associated with windows" actually mean? Who should be getting these events? I don't recall you explaining what HardKey is. Knowing exactly what it is might help. Thanks, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
