Hi,<br><br>On Thursday, November 13, 2014, Daniel Stone <<a href="mailto:daniel@fooishbar.org">daniel@fooishbar.org</a>> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 13 November 2014 07:35, Pekka Paalanen <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','ppaalanen@gmail.com');" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Wed, 12 Nov 2014 12:06:16 -0800<br>
Bill Spitzak <<a href="javascript:_e(%7B%7D,'cvml','spitzak@gmail.com');" target="_blank">spitzak@gmail.com</a>> wrote:<br>
> The important point is that in both your and my case the client that has<br>
> just received focus sees the 'd' as being held down. The 'd' is on in<br>
> the key-down array attached to the focus-in event!!!!<br>
<br>
</span>Correct. Apparently X apps interpret a "key already down" the same way<br>
as a "key goes down" event. That is not a Wayland issue at all.</blockquote><div><br></div><div>No, X _apps_ don't - XWayland does.</div></div></div></div></blockquote><div><br></div><div>To be clear: X11 has this as well. FocusIn + KeymapNotify events are equivalent to wl_keyboard::enter with a fully-populated key list.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> IMHO they should not be different, therefore this patch is wrong. There<br>
> are two possible solutions:<br>
><br>
> 1. Revert it. The actual bug is that a client that already has focus<br>
> before a "compositor shortcut" will not get any changes to the keymap.<br>
> Add something to fix this instead. I recommend a redundant focus-in event.<br>
><br>
> 2. Always send a blank key-down array in the focus-in event, since it is<br>
> possible that any key held down was the "shortcut" that caused the<br>
> focus-in event.<br>
<br>
</span>No, we are not going to break the Wayland core protocol. Also, I do not<br>
see a problem with the current behaviour.<br>
<br>
We are not going to screw up Wayland just so that X apps in Xwayland<br>
would work "better" for some cornercases.<br>
<br>
Instead, we fixed Weston to act consistently, which corrected the<br>
original problem.<br></blockquote><div><br></div><div>I think the fix makes Weston act _less_ consistently, especially when you consider how it behaves when it's nested. If Weston nested under Wayland behaves differently to DRM, that's proof that our model is broken.</div></div></div></div></blockquote><div><br></div><div>And the consistency argument is backed up by different consumers. wl_keyboard::enter gives you the list of currently-pressed keys, to be used for bookkeeping and _not_ for actions.</div><div><br></div><div>If we enter from a VT switch, we'll send Ctrl+Alt+Fx to the clients in the enter event when they get the focus. If it was a compositor key binding, with this patch, we won't send the key that immediately triggered the binding, but we will send the other keys.</div><div><br></div><div>I'm struggling to see a case where this makes sense, especially if you take it as a given that the current XWayland behaviour (which this patch tries to work around) as broken and in need of fixing.</div><br><div>wl_keyboard::enter sends the list of currently-depressed keys to the client. If we make it a partial list, depending on context, we make it useless. We'll send releases for keys the client never knew were down - which is _exactly_ the problem this event is trying to prevent.</div><div><br></div><div>If we're making it an arbitrary list depending on whether it was a compositor hotkey, or depending on how you're nested, the event becomes useless as a guarantee and we might as well just drop it completely.</div><div><br></div><div>Cheers,</div><div>Daniel</div>