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?

Hi,
The version of the virt-manager is 0.8.4-8.el6 noarch
and using 109 Japanese keyboard.(In reply to comment #2)

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

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.

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

Created attachment 580423 [details]
Reproduced Caps Lock issue

Additional info:
Tested in ja_JP locale.

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?

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

Created attachment 580624 [details]
Reproduced Caps Lock issue in Japanese via changing system-config-keyboard

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.

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?

Created attachment 596118 [details]
the full libvirt xml config

Created attachment 596119 [details]
a kickstart file to setup a guest which shows this behavior

Added the requested files. Please check them.

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?

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.

Thanks for the bug link.  That doesn't answer the questions from Comment 18 though -> NEEDINFO again.

(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?

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.

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

(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

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

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

  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.

gdm and GNOME are using their own keyboard settings and handling.

Assigning to gdm.

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

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

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.

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

Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/