[weston1.5]Question about HardKey input monitor with wayland/weston

[Yang Andy]

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?

Best regards,

Andy
> Date: Sun, 11 Jan 2015 12:36:25 +0200
> From: ppaalanen at gmail.com
> To: williamyang13 at hotmail.com
> CC: wayland-devel at lists.freedesktop.org
> Subject: Re: [weston1.5]Question about HardKey input monitor with wayland/weston
> 
> On Mon, 5 Jan 2015 11:48:00 +0000
> Yang Andy <williamyang13 at hotmail.com> wrote:
> 
> > Hi Pekka
> > 
> > Thank you very much for your reply.
> > 
> > > If you're interested in that, you can
> > >dig the wayland-devel mailing list archives, or if you can't find it,
> > >someone else probably can. This discussion was about any normal app
> > >that just wants to register for a global hotkey.
> > I have searched for the related topic,but i did not find it.
> 
> Here are some pointers:
> 
> http://lists.freedesktop.org/archives/wayland-devel/2014-July/015869.html
> which is a part of a thread starting at
> http://lists.freedesktop.org/archives/wayland-devel/2014-July/015856.html
> containing some discussion.
> 
> There's some hand-waving and a youtube link in
> http://lists.freedesktop.org/archives/wayland-devel/2012-September/005603.html
> 
> Some good ideas are in
> http://lists.freedesktop.org/archives/wayland-devel/2013-December/012659.html
> 
> I didn't find what I would think as the latest comprehensive
> proposal, though.
> 
> > >In all cases, the main idea is to prevent random clients from
> > >eavesdropping input, while still letting the right client(s) get them.
> > >This is always some new protocol extension that is unrelated to
> > >wl_keyboard, wl_pointer, etc.
> 
> > Right now,my solution is to extend wl_keyboard protocol,because the
> > work volume is little.
> 
> So you are faking temporary keyboard focus changes in the
> compositor to send keyboard events? I believe that will be hard to
> make it work right and follow the guarantees we require from
> wl_keyboard events, if not impossible.
> 
> > Software architecture is HMI-->QT/EFL(wayland/client)-->westion(wl_keyboard/extention key)--evdev.
> > 
> > But i have another question.
> > 
> > In my uses case,i will composite QT-applicaiton and EFL-applicaion into one image,both of them want to get hardkey input event but only one application can get the input event who get the foucs.
> > 
> > When QT /EFL application want to get hardkey input event,it have to get the windows focus.
> > 
> > How do i switch the focus/active for specific QT or EFL application by software design?
> > 
> > Could you give some advice?
> 
> 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.
> 
> This is one of the reasons why we cannot use wl_keyboard for this.
> We need a whole new protocol extension.
> 
> 
> Thanks,
> pq
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150115/459989ff/attachment-0001.html>