Hi ----- Original Message ----- > > > > Hi > > > > ----- Original Message ----- > > > Limit the virtual keystrokes sent to the remote machine. > > > The modifiers are synced only when the application receive or lose > > > the focus. This reduce a lot the possible virtual keystrokes sent > > > to the guest to synchronize the modifiers. > > > This affect the situations where modifiers are configured > > > differently in client and guest. > > > When the application receive the focus the synchronization is > > > attempted from client to guest while when the application lose > > > focus is attempted guest to client (basically is moved following > > > user moving). > > > > Does this mean that modifiers changes with the application in focus? That > > would be quite irritating imho, and I will likely want an option to disable > > that (actually the default). > > > > Actually the default is trying to copy the modifiers to the VM. > The change affects only VirtViewer, not the entire system. > Let's make an example. > 1- you are working on the client with an editor; > 2- caps is off; > 3- you move to VirtViewer; > 4- caps is send to VM as VirtViewer get the focus; > 5- you work on the VM; > 6- you get back to your editor; > 7- caps is synchronized back to client if does not match. > > 7 can happen only is guest is not behaving as expected as when you > press the caps client should switch the lock, send the caps to VM > which should switch too. Let me try to follow your example: in 4. you change your caps to lock, and caps-lock is sent to the guest, but the guest eventually didn't follow it and so you want to synchronize the client lock state in 6-7, when focusing out of the guest (or earlier?). Do I understand correctly? imho that's wrong, the remote display app is not your local machine. You want your keyboard lock to be your machine lock, not an application lock state. Having various lock state for different apps is confusing and annoying. > > If on 4 VM is not changing the lock and you keep sending if trying > to sync on 5 you'll have problems typing. > With normal (like English) cases 4 is what is done now, on 7 you > have nothing to do and leds are keep in sync unless the VM change > them not in response to a client key (yes, this will lead to LEDs > not synced). > It's hard to follow you, it would be easier to describe with messages/state, perhaps something like: Working sync case: 1. local:1, remote:0 2. send lock:1 (since local!=remote) 3. local:1, remote:1 4. receive lock:1 If I understand you, the non-working case loops: 1. local:1, remote:0 2. send lock:1 (since local!=remote) 3. local:1, remote:0 (somehow nothing changed?) 4. receive lock:0 (but the server notifies us) 5. goto 2 Isn't it a server bug to send the same lock if the locks didn't change? > > What I don't understand is what you improving here, saving a few key events > > sent to the guest? > > > > Yes, once per second which can make the VM unusable. > > > I don't understand the issue with the current behavior, and the change of > > behavior you propose here. Could you give an example? > > > > You press Caps, VM send back modifiers with no Caps set, you try to fix > sending another Caps, VM send back modifiers with no Caps set ... and so on. When does this happen? Can you give a reproducer? _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel