[Spice-devel] [spice-gtk] gtk-session: do not sync modifiers when focused

[Frediano Ziglio]

> Hi Frediano,

> On Thu, Apr 25, 2019 at 9:38 AM Frediano Ziglio < fziglio at redhat.com > wrote:

> > > [...]
> 

> > I agree on the patch however to me it looks partial.
> 

> > When the server send the modifiers the client check its state
> 
> > and still does the sync.
> 
> > In my configuration my client does not change the caps lock state
> 
> > as the caps is used for other purposes. The caps in my case get
> 
> > ignored or it bounce back depending on how long I press the caps.
> 

> 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.

Yes, sometimes I write something in Spanish which has a lot of accents and I have a Uk keyboard so I wanted some "sticky" keys. However always sticky is a problem as being a developer I want to have characters like ` and ' with one keystroke so I'm using caps lock as compose key (which is something you can do from Gnome/KDE without manually using xkb). 

But beside my not common settings the commit specifies that modifiers synchronization does not happen when client has the focus but this is false in the path where modifiers are sent to the server. 

> 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.

Looking at code and how modifiers behave I found another issue (with or without this patch). On Linux (xorg and KDE but I suppose it's xorg) the caps modifier is reset when caps lock is released while on Windows caps modifier is reset when is pressed! The code on server assume the Windows behaviour. This causes a bounce of the caps (a virtual caps lock key press/release) if client is Linux, guest is Windows and you hold the caps lock a bit more than usual! The reason is that when the caps lock is pressed Windows turn the led, send "caps lock is disabled" to client while client has still the caps lock enabled so it tries to force the caps lock. 

> That would be a harder case to solve I think, because of the way sync works
> in spice-server (
> https://gitlab.freedesktop.org/spice/spice/merge_requests/3 ) 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).

> Cheers,
> Olivier

Frediano 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20190425/c3c9cc05/attachment.html>