<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 28, 2015 at 11:28 AM, Derek Foreman <span dir="ltr"><<a href="mailto:derekf@osg.samsung.com" target="_blank">derekf@osg.samsung.com</a>></span> wrote:<br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not sure I follow - are you saying we need a "special buttons" focus<br>
for multimedia keys?  (backlight keys?  do we need a backlight focus<br>
too, or?)<br></blockquote><div><br></div><div>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.<br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you run, say:<br>
WAYLAND_DEBUG=1 weston-terminal<br>
<br>
you can quite readily confirm that the window with pointer focus is<br>
given modifier state from the keyboard in the same seat.<br></blockquote><div><br></div><div>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.<br><br></div></div></div></div>