Hi, On 29 September 2015 at 19:07, Bill Spitzak <[email protected]> wrote: > On Mon, Sep 28, 2015 at 11:28 AM, Derek Foreman <[email protected]> > wrote: >> I'm not sure I follow - are you saying we need a "special buttons" focus >> for multimedia keys? (backlight keys? do we need a backlight focus >> too, or?) > > I thought the assumption was that if a key does a global action, it is the > compositor's job to know that key is special and either do the action > itself, or deliver an event to a particular client. That does sound like a > possible different focus for every assignable key. So yes, that is what I am > saying. > > I see no reason why this same mechanism cannot be used to deliver buttons > from the remote to correct clients. There is no need for a different "seat". > I was also proposing that the seat already has two focus and it seems like > reusing the pointer focus as the remote focus would solve the proposed > problem.
There's only one focus; grabs temporarily change this focus, or routes event delivery other than what the focus would imply. > Abusing the seat mechanism this way is not a good idea. The client wants to > know what input devices are grouped together. Imagine if shift on the > keyboard could modify one or the remove buttons. If the remote is it's own > seat then the client has no way to know which seat's modifiers should > actually have an effect on the remote, as the seats are how they are grouped > together. > > It sounded to me like the original problem, as stated, requires exactly two > foci. One for the keyboard and one for the remote. I suggested reusing the > pointer focus for the remote focus, rather than adding another type of > focus, or some hack with an extra seat, to Wayland. So they would be separate wl_keyboard objects, or ... ? This wouldn't help anything, because then _someone_ still has to merge the modifier state from two disparate wl_keyboard interfaces. >> If you run, say: >> WAYLAND_DEBUG=1 weston-terminal >> >> you can quite readily confirm that the window with pointer focus is >> given modifier state from the keyboard in the same seat. > > It looks like wl_keyboard::modifiers events are sent to both the keyboard > and mouse focus. That is not clear from the protocol documentation. It is a > little annoying that a client has to create a wl_keyboard object to get > these, though. wl_keyboard::modifiers is meaningless without the keymap, so it makes sense that you need to get the wl_keyboard. Cheers, Daniel _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
