On Fri, 25 Sep 2015 16:14:25 +0900 ______ <sj76.p...@samsung.com> wrote:
> Dear all, > > Let me share a patch for extending wayland protocol for helping a wayland > client to identify which events are coming from which physical > keyboard/pointer device. > > I__d like to discuss with you guys about this patch. : ) > > In this patch, I added __name__ event both for wl_pointer and for > wl_keyboard. Hi, this just does not work, because a wl_pointer and wl_keyboard are abstract devices, and can be backed by several physical or virtual (nested compositors) input devices. Naming wl_seats would give you the equivalent. There is already a wl_seat.name event. Adding name events to wl_pointer and wl_keyboard does not provide any new information. > Under wayland protocol applied this patch, a wayland compositor will send > the name event when a wayland client add a listener for wl_pointer or > wl_keyboard. > > Then, the client can store the name of the keyboard or pointer and will use > it when it is required. > > > > Usually in desktop environment, we don__t need to care the source device > name of events. Yes, clients must not care about what physical devices are backing a wl_pointer or a wl_keyboard. Each can be backed by several devices, and there is no way to tell which device caused which event. > In vehicle, mobile and TV environment, there will be many input devices and > will be many special requirements for them. > > > > For instance, in TV, __1__ key in an usual keyboard will be used as a > character __1__ and will be sent to the focus surface/window. > > By the way __1__ key in remote control for TV will be used as a action key > and will be sent to channel managing process which doesn__t have any focus > surface/window. I think you can solve all this without extending the protocol. First, put the keyboard device and the remote control device behind different wl_seat globals. (This means that the compositor will advertise two wl_seat globals with wl_registry.global events.) Then, for the wl_seat matching the keyboard device, you can use a normal keymap. For the other wl_seat, the wl_keyboard would use a different keymap that describes the remote control. This way, clients will get a different keysym whether the user presses '1' on the keyboard or the remote control. As for controlling the input focus for key events, using separate wl_seats offers more flexibility: your compositor can choose to keep the remote control's wl_seat always focused to your channel manager client. This would cause all events from the remote control to always go the channel manager and never to anything else. These combined with the wl_seat name, you have several ways to differentiate between the physical input devices: - by wl_seat name - by keysym - by wl_keyboard focus Which one(s) you should pick depends on your use case. All the methods rely on putting the different physical devices on different wl_seat globals. Would this be sufficient for you? Thanks, pq
pgpxAAJyndhXj.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
