RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1337576 - Avoid loosing sync and inserting invalid keystrokes for modifiers syncronizations
Summary: Avoid loosing sync and inserting invalid keystrokes for modifiers syncronizat...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: spice-gtk
Version: 7.2
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: Default Assignee for SPICE Bugs
QA Contact: SPICE QE bug list
URL:
Whiteboard:
Depends On:
Blocks: 1311804
TreeView+ depends on / blocked
 
Reported: 2016-05-19 14:06 UTC by Frediano Ziglio
Modified: 2016-11-11 17:49 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-11 17:49:31 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Frediano Ziglio 2016-05-19 14:06:10 UTC 
Description of problem:
Caps locks is a strange key/concept. The concept of Caps lock and how to turn on/off can be quite different between guest and client. This, as client try to sync the modifiers causing even continue virtual keystrokes.


Version-Release number of selected component (if applicable):
Any


How reproducible:
Always in specific (many) conditions.
Use a English client on a Japanese guest and try to use Caps lock key.
Try setting modifier differently (for instance disabling caps lock on guest).


Steps to Reproduce:
Just as an instance
1. use a English client for virt-viewer (Linux for instance);
2. open a Japanese guest (Linux) with Eisu toggle key working;
3. press Caps lock key on client.
Try also to disable caps lock on either systems or remap to different key.

Actual results:
Key not working or continuously toggling.
This for Japanese users can cause impossibility to use some input methods.


Expected results:
Guest should work as you typed the keys on a physical machine.


Additional info:
We are following different paths from better knowledges of the guest settings (using the guest agent) to synchronize only on specific events (like focus in/out) and in different directions.
Comment 2 Andrei Stepanov 2016-06-03 12:40:40 UTC 
Running on guest:

$ xev -event keyboard

shows that turning off CapsLock produces next events:


KeyPress event, serial 36, synthetic NO, window 0x2200001,
    root 0x276, subw 0x0, time 333796219, (77,68), root:(84,154),
    state 0x2, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x2200001,
    root 0x276, subw 0x0, time 333796299, (77,68), root:(84,154),
    state 0x2, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x2200001,
    root 0x276, subw 0x0, time 333796299, (77,68), root:(84,154),
    state 0x0, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x2200001,
    root 0x276, subw 0x0, time 333796299, (77,68), root:(84,154),
    state 0x2, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x2200001,
    root 0x276, subw 0x0, time 333796300, (77,68), root:(84,154),
    state 0x2, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x2200001,
    root 0x276, subw 0x0, time 333796300, (77,68), root:(84,154),
    state 0x2, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False


Guest thinks that CapsLock was pressed 3 times instead one.
Comment 3 Andrei Stepanov 2016-06-03 13:00:20 UTC 
[root@localhost ~]# xinput test 7
key press   38 <------ press a
key release 38 
akey press   66 <------- capslock On
key release 66 
key press   38 <------- press a
key release 38 
Akey press   66 <-------- capslock Off
key release 66 
key press   66 
key release 66 
key press   66 
key release 66
Comment 4 Frediano Ziglio 2016-11-11 17:49:31 UTC 
Current release implements some workaround that works on most cases.
Note You need to log in before you can comment on or make changes to this bug.