Bug 814095 - Combination of the specific keys produce capitalization on the virt-manager, virt-viewer, vncviewer.
Combination of the specific keys produce capitalization on the virt-manager, ...
Status: ASSIGNED
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: xkeyboard-config (Show other bugs)
6.0
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Peter Hutterer
Desktop QE
: OtherQA
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-19 04:45 EDT by rh-inst
Modified: 2017-09-14 07:46 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Reproduced Caps Lock issue (523.22 KB, image/png)
2012-04-26 06:28 EDT, Lijun Li
no flags Details
Reproduced Caps Lock issue in Japanese via changing system-config-keyboard (78.07 KB, image/png)
2012-04-26 23:17 EDT, Lijun Li
no flags Details
the full libvirt xml config (50.00 KB, application/x-tar)
2012-07-03 20:32 EDT, rh-inst
no flags Details
a kickstart file to setup a guest which shows this behavior (10.00 KB, application/x-tar)
2012-07-03 20:33 EDT, rh-inst
no flags Details

  None (edit)
Description rh-inst 2012-04-19 04:45:18 EDT
Description of problem:
Combination of the specific keys switch capital letter to small letter and vice versa, while typing fast on the virt-manager. 

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

How reproducible:
Almost 100% with the right timing of the typing. 

Steps to Reproduce:
1. Login to desktop (Any user can be used.)
2. Access to virt-manager and create virtual server with RHEL 6.0 (need GUI)
3. Login to virtual server (Any user can be used.)
4. Open the terminal.
5. Type [q][shift][1] in a very short time (within 1 second)
  
Actual results:
When the timing matches, the combination of the keys switch capital letter to small letter and vice versa.

Expected results:
The combination of the keys should not produce the capitalization. 

Additional info:
The same problem occurs with virt-viewer and vncviewer. Different combination such as [a][shift][1] also produce the problem. The timing of pressing [shift] might be the key point to produce this problem.
Comment 2 yuping zhang 2012-04-20 05:06:01 EDT
Hi,
What's virt-manager version?
#rpm q virt-manager
I can not reproduce this issue.Is there anything which I should pay attention to?
Comment 3 rh-inst 2012-04-23 05:26:33 EDT
Hi,
The version of the virt-manager is 0.8.4-8.el6 noarch
and using 109 Japanese keyboard.(In reply to comment #2)
Comment 4 Cole Robinson 2012-04-25 12:46:07 EDT
If virt-manager, virt-viewer, and vncviewer are all giving the same issue, probably something on the host or qemu VNC handling. Reassigning to qemu
Comment 5 Gerd Hoffmann 2012-04-26 02:59:47 EDT
There have been a number of fixes.  Original report says "RHEL 6.0".  Can you re-test with 6.2 or 6.3-beta please?  Most likely the issue is fixed already.
Comment 6 Lijun Li 2012-04-26 06:19:00 EDT
I can reproduce it, seems it's a big issue for the virtual machine user.

Reproduced Steps:
1. Check the host machine rhel & virtual machine manager version
[testqa@localhost ~]$ cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.1 (Santiago)
[testqa@localhost ~]$ rpm -q virt-manager
virt-manager-0.8.6-4.el6.noarch

2. Create a new virtual machine (I installed latest RHEL6.3 build in the virtual machine) and Login to it.

3. Open the terminal.

4. Run command system-config-keyboard and select Japanese(日本) to change the keyboard to Japanese.

5. Back to the terminal, type [a][shift][1] or [q][shift][1] in a short time.

6. As you can see after above steps the input letter is switched in to Captials and can not switch back to the normal any more otherwise you type [shift] and than type the other letter at the same time to input the lowercase string. Please see the attached screenshot FYI.

Thanks,
Robert
Comment 7 Lijun Li 2012-04-26 06:28:43 EDT
Created attachment 580423 [details]
Reproduced Caps Lock issue
Comment 8 Lijun Li 2012-04-26 06:29:36 EDT
Additional info:
Tested in ja_JP locale.
Comment 9 Gerd Hoffmann 2012-04-26 08:15:53 EDT
Re #6:  Please use RHEL 6.3 on the host too to reproduce.

Is a Japanese keyboard inside the guest required to reproduce this or can you trigger this with us keyboard too?
Comment 10 Lijun Li 2012-04-26 23:13:22 EDT
(In reply to comment #9)
> Re #6:  Please use RHEL 6.3 on the host too to reproduce.
> 
> Is a Japanese keyboard inside the guest required to reproduce this or can you
> trigger this with us keyboard too?

Actually, I don't have a Japanese keyboard (hardware), my keyboard is English keboard, I just changed the keyboared settings to Japanese in the virtual machine via system-config-keyboard and reproduced this issue, it's easy to reproduce this issue after changing the keyboard to Japanese via system-config-keyboard: just type [1][q][shift] and type other keys at the same time in a very short time, then it switch in to Captials , type [Caps Lock] button, it don't work, and can not input the lowercase letters any more,  

I verified it with English keyboard via changing system-config-keyboard in the same way but can not reproduce this issue, so I think it's the Japanese keyboard issue.

Please refer to the attached screenshot.
Comment 11 Lijun Li 2012-04-26 23:17:48 EDT
Created attachment 580624 [details]
Reproduced Caps Lock issue in Japanese via changing system-config-keyboard
Comment 12 Lijun Li 2012-04-26 23:25:25 EDT
Additional info:
After changing back to English keyboard via system-config-keybaord, type [Caps Lock] key, it works fine and then can input the lowercase letter as normally.
Comment 14 Gerd Hoffmann 2012-07-03 06:03:05 EDT
Doesn't reproduce locally, seems it needs more than just a japanese keyboard config to trigger.  Japanese input methods being active maybe?

Any chance I can get the full libvirt xml config and a kickstart file to setup a guest which shows this behavior?
Comment 15 rh-inst 2012-07-03 20:32:34 EDT
Created attachment 596118 [details]
the full libvirt xml config
Comment 16 rh-inst 2012-07-03 20:33:29 EDT
Created attachment 596119 [details]
a kickstart file to setup a guest which shows this behavior
Comment 17 rh-inst 2012-07-03 20:35:39 EDT
Added the requested files. Please check them.
Comment 18 Gerd Hoffmann 2012-07-06 05:32:56 EDT
Hmm, still doesn't reproduce (RHEL-6.3 for both host and guest).

I noticed that CapsLock has no effect in the guest (with japanese kbd configured).  Is this normal behavior for a japanese keyboard?

I've seen you have "keymap='ja'" for vnc in the guest xml.
Does the behavior change if you remove this?
Comment 19 juzhang 2012-08-01 05:21:36 EDT
FYI, seems the following bug cover this issue.
https://bugzilla.redhat.com/show_bug.cgi?id=841120
Bug 841120 - [FJ6.3 Bug]: [REG] Several symbols pressed with the shift key are not shown on a KVM guest as expected.
Comment 20 Gerd Hoffmann 2012-08-06 02:58:51 EDT
Thanks for the bug link.  That doesn't answer the questions from Comment 18 though -> NEEDINFO again.
Comment 21 juzhang 2012-08-06 03:35:13 EDT
(In reply to comment #20)
> Thanks for the bug link.  That doesn't answer the questions from Comment 18
> though -> NEEDINFO again.
Sorry to can not reslove your question,  kvm qe can not  get a Jap keyboard in China, so, submit a needifo to reporter.

Hi, Reporter

Would you please have a try according to comment18?
Comment 22 Markus Armbruster 2012-08-06 03:57:35 EDT
Juzhang, comment#18 asks for a test without keymap=ja in guest configuration.  It doesn't ask for a test with a Japanese hardware keyboard.  Please try this test for us with whatever keyboard was used in the previous tests.
Comment 23 Qunfang Zhang 2012-08-06 06:14:18 EDT
(In reply to comment #22)
> Juzhang, comment#18 asks for a test without keymap=ja in guest
> configuration.  It doesn't ask for a test with a Japanese hardware keyboard.
> Please try this test for us with whatever keyboard was used in the previous
> tests.

Hi, Markus
I can reproduce this issue both with and without 'keymap=jp' with an English hardware keyboard with the steps in comment 6.
But in my test it always output lower cases instead of capitals even I press "Caps Lock" on.

Select "Japanese" in system-config-keyboard:
(1) with 'keymap=ja': Reproduced.
(2) wiouth 'keymap=ja': Reproduced.

Select "U.S. English" in system-config-keyboard:
(1) with 'keymap=ja': Not reproduce
(2) wiouth 'keymap=ja': Not reproduce

Both my host and guest are rhel6.3.
Comment 24 Qunfang Zhang 2012-08-06 22:37:47 EDT
(In reply to comment #23)
> (In reply to comment #22)
> > Juzhang, comment#18 asks for a test without keymap=ja in guest
> > configuration.  It doesn't ask for a test with a Japanese hardware keyboard.
> > Please try this test for us with whatever keyboard was used in the previous
> > tests.
> 
> Hi, Markus
> I can reproduce this issue both with and without 'keymap=jp' with an English
> hardware keyboard with the steps in comment 6.
> But in my test it always output lower cases instead of capitals even I press
> "Caps Lock" on.
> 
> Select "Japanese" in system-config-keyboard:
> (1) with 'keymap=ja': Reproduced.
> (2) wiouth 'keymap=ja': Reproduced.
> 
> Select "U.S. English" in system-config-keyboard:
> (1) with 'keymap=ja': Not reproduce
> (2) wiouth 'keymap=ja': Not reproduce
> 
> Both my host and guest are rhel6.3.

Update steps and results here to make it more clear:
Steps:
1. Boot a rhel6.3 guest (I import an existing image in virt-manager) on a rhel6.3 host and Login to guest.
1.1 with "keymap=ja" in xml.
1.2 without "keymap=ja" in xml.

3. Open the terminal.

4. Run command system-config-keyboard and select "Japanese" to change the keyboard to Japanese.

5. Back to the terminal, type [a][shift][1] or [q][shift][1] in a short time.

6. After repeat a few times of step 5, press some keys like "aaa".

7. Press "Caps Lock" to switch to upper-case letter. And press some keys like "aaa" again.

Result:
Step 6 : output in terminal : aaa
Step 7 : output in terminal : aaa (Should be "AAA" actually as "Caps Lock" is on)

If I switch to "U.S.English" in system-config-keyboard, and re-test. All work as expected.
Step 6: output in terminal : aaa
Step 7: output in terminal : AAA
Comment 25 Gerd Hoffmann 2012-08-07 02:54:59 EDT
  Hi,

> 7. Press "Caps Lock" to switch to upper-case letter. And press some keys
> like "aaa" again.
> 
> Result:
> Step 6 : output in terminal : aaa
> Step 7 : output in terminal : aaa (Should be "AAA" actually as "Caps Lock"
> is on)

Noticed that too (see question #1 in comment #18 which is still unanswered).

I don't need to do anything special for that, CapsLock has simply no effect at all, so I'm wondering whenever japanese keyboards supposed to work that way or whenever (physical) japanese keyboards have a CapsLock key in the first place.

qemu has some heuristics to figure the guests idea of capslock state, which could simply be confused by this, thats why I'm asking ...
Comment 26 rh-inst 2012-08-07 03:56:23 EDT
(In reply to comment #18)
> Hmm, still doesn't reproduce (RHEL-6.3 for both host and guest).
> 
> I noticed that CapsLock has no effect in the guest (with japanese kbd
> configured).  Is this normal behavior for a japanese keyboard?
> 
> I've seen you have "keymap='ja'" for vnc in the guest xml.
> Does the behavior change if you remove this?

Sorry for the late reply.
The answer to #1 is that having no effect of CapsLock is not normal behavior for a japanese keyboard. It should work both on physical machine and virtual machine. However when the problem occur with the key combination like [a][shift][1] or [q][shift][1], CapsLock has no effect on virtual machine.
Comment 27 Gerd Hoffmann 2012-08-08 07:26:43 EDT
  Hi,

> The answer to #1 is that having no effect of CapsLock is not normal behavior
> for a japanese keyboard. It should work both on physical machine and virtual
> machine.

Well, it doesn't work for me:

(1) Install machine, pick japanese keyboard when anaconda asks you.
(2) Reboot into gdm.
(3) On the login screen pick 'other'.
(4) Type letters.  See lowercase letters show up.
(5) Hit CapsLock.  Keyboard's capslock led does *NOT* change.
(6) Type letters again.  See them still show up in lowercase
    *NOT* uppercase as they should.

But after fiddeling with the keyboard settings for a while CapsLock starts working:

(7) Login
(8) Right-klick on the top panel, pick 'add to panel',
    pick 'keyboard indicator'.
(9) Go to system -> preferences -> keyboard -> Layouts
(10) Add more keyboard layouts (/me used english and german).
(11) Use the keyboard indicator to switch keyboard layouts back and forth.
(12) Notice CapsLock works properly now when the japanese keyboard layout
     is active.

I see this behavior on both virtual and physical machines.  I doubt this is virtualization related.  Reassigning to system-config-keyboard for further investigation.
Comment 28 Thomas Woerner 2012-09-03 04:01:57 EDT
gdm and GNOME are using their own keyboard settings and handling.

Assigning to gdm.
Comment 29 Tomas Pelka 2013-06-04 08:56:15 EDT
I can't reproduce either, can we push this as OtherQA? Of course in case we get commitment from reporter that he will be able to retest with fixed packages.

Thanks
Tom
Comment 30 Ray Strode [halfline] 2013-06-05 11:33:07 EDT
(In reply to Tomas Pelka from comment #29)
> I can't reproduce either, can we push this as OtherQA? Of course in case we
> get commitment from reporter that he will be able to retest with fixed
> packages.

This can easily be reproduced by:

1) Do a fresh install
2) yum install xterm
3) boot into runlevel 3 or run telinit 3 to switch to runlevel 3
3) create ~/.xinitrc
#!/bin/sh
xterm
5) type startx
6) in the xterm window run 

setxkbmap jp

7) type some characters, notice they're lower case
8) hit the caps lock key
9) type some characters, notice they're still lower case
10) hit caps lock key
11) run

setxkbmap us

11) type some characters, notice they're lower case
12) hit caps lock key
13) type some characters, notice they're upper case.

If we look in /usr/share/X11/xkb/symbols/jp we can see this line:

key <CAPS> { [ Eisu_toggle, Caps_Lock ] };

The <CAPS> refers to the key on the keyboard that is caps lock, the stuff in the braces are what get mapped to that key.  the first entry is the unshifted mapping, and the second entry is a shifted mapping.  That means in the japanese keyboard layout, the caps lock key only does caps lock functionality if the user hits shift-capslock.  if the user just hits capslock, they get Eisu toggle functionality.

This can be confirmed by 

14) type xev
15) hit the caps lock key and notice it registers as Eisu_toggle
16) hit shift-caps lock and notice it registers as Caps_Lock.

it doesn't look like eisu toggling actually works though (though maybe that functionality is supposed to be provided by ibus, i'm not sure).  I'm going to move this to xkeyboard-config so we can get clarification on the expected behavior of unshifted caps lock when using a jp keyboard layout on an english keyboard.
Comment 31 RHEL Product and Program Management 2013-10-13 20:42:18 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.
Comment 32 rh-inst 2014-09-15 20:11:49 EDT
(In reply to RHEL Product and Program Management from comment #31)
> This request was evaluated by Red Hat Product Management for
> inclusion in the current release of Red Hat Enterprise Linux.
> Because the affected component is not scheduled to be updated
> in the current release, Red Hat is unable to address this
> request at this time.
> 
> Red Hat invites you to ask your support representative to
> propose this request, if appropriate, in the next release of
> Red Hat Enterprise Linux.

Since we no longer use the RHEL 6.0. We can close this case.
We stopped using Japanese key board for the training class.

Note You need to log in before you can comment on or make changes to this bug.