<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Frediano,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 25, 2019 at 9:38 AM Frediano Ziglio <<a href="mailto:fziglio@redhat.com">fziglio@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> [...]<br><br>
I agree on the patch however to me it looks partial.<br>
<br>
When the server send the modifiers the client check its state<br>
and still does the sync.<br>
In my configuration my client does not change the caps lock state<br>
as the caps is used for other purposes. The caps in my case get<br>
ignored or it bounce back depending on how long I press the caps.<br>
<br></blockquote><div><br></div><div>So if I understand correctly, you have configured the [CAPSLock] key to something else than CAPS lock (using an xkb option, maybe compose:caps or something), so pressing [CAPSLock] on your host would not switch CAPS Lock ON on your host.</div><div><br></div><div>Yet the guest may not have that option set, so when CAPSLock key press is received by the guest, it switches CAPS lock on the guest, so the guest and host status differ.</div><div><br></div>That would be a harder case to solve I think, because of the way sync works in spice-server (<a href="https://gitlab.freedesktop.org/spice/spice/merge_requests/3">https://gitlab.freedesktop.org/spice/spice/merge_requests/3</a>) as a toggle state, it's much harder to get the expected state reliably (also because in the opposite case, i.e. the guess has changed the default CAPS lock xkb option, simulating a [CAPSLock] key press as spice-server does may not enable CAPS Lock in the guest either).<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Cheers,</div><div class="gmail_quote">Olivier<br></div></div></div>