diff mbox

fix '/' and '|' on russian keymap

Message ID 20101001181428.GA18421@blackpad.lan.raisama.net
State New
Headers show

Commit Message

Eduardo Habkost Oct. 1, 2010, 6:14 p.m. UTC
Patch from Oleg L. Sadov.

Removes broken 'slash' and 'bar' definitions (that were duplicated) from
the 'ru' keymap.

I can't test it myself, but the the fix was reported to be working, at:
https://bugzilla.redhat.com/show_bug.cgi?id=580637

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
 pc-bios/keymaps/ru |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

Comments

Eduardo Habkost Oct. 6, 2010, 7:56 p.m. UTC | #1
Anybody using a russian keyboard layout who can test this change and
confirm it works as expected?

There's no need to rebuild qemu to test it. Just changing the keymap
file on /us/share/qemu to remove the last two lines (shown below) should
be enough.


On Fri, Oct 01, 2010 at 03:14:28PM -0300, Eduardo Habkost wrote:
> Patch from Oleg L. Sadov.
> 
> Removes broken 'slash' and 'bar' definitions (that were duplicated) from
> the 'ru' keymap.
> 
> I can't test it myself, but the the fix was reported to be working, at:
> https://bugzilla.redhat.com/show_bug.cgi?id=580637
> 
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> ---
>  pc-bios/keymaps/ru |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/pc-bios/keymaps/ru b/pc-bios/keymaps/ru
> index b3e7d24..70a68f4 100644
> --- a/pc-bios/keymaps/ru
> +++ b/pc-bios/keymaps/ru
> @@ -105,5 +105,3 @@ Cyrillic_yu 0x34 altgr
>  Cyrillic_YU 0x34 shift altgr
>  slash 0x35
>  question 0x35 shift
> -slash 0x56 altgr
> -bar 0x56 shift altgr
> -- 
> 1.7.2.1
>
Michael Tokarev Oct. 7, 2010, 4:38 a.m. UTC | #2
06.10.2010 23:56, Eduardo Habkost wrote:
> 
> Anybody using a russian keyboard layout who can test this change and
> confirm it works as expected?

I can perform such a testing - in theory.  But in practice, I was never
able to figure out this -k $lang stuff, -- neither in qemu nor in other
apps like rdesktop and the like.

What I usually do is to explicitly set en-us keyboard for applications
that are "too smart" and tries to guess "right" keyboard from env.
variables such as $LANG.

The reason is that after specifying "ru" keyboard, I can't use latin
chars anymore, and can type only using cyrillic.  Since cyrillic
layout does not have any latin char, imagine how to type, say, a
path name (even "C:" drive in windows).

All modern OSes nowadays have a way to switch between keyboard layouts
dynamically - this is done internally in the operating system.  So,
basically, I've no idea what this -k $foo stuff is used for to start
with ;)

Care to explain please?  Oleg?  :)

Thanks!

/mjt
Michael Tokarev Oct. 7, 2010, 4:47 a.m. UTC | #3
06.10.2010 23:56, Eduardo Habkost wrote:
> 
> Anybody using a russian keyboard layout who can test this change and
> confirm it works as expected?

Um, regardless of my previous email, the change is indeed correct and
needed, or else the slash/question key (the one that's usually on the
left from the right shift, above the windows key) produces backslash
and vertical bar instead.  So I can confirm it's the right change.

(But I still don't know what's the reason of all these keymaps ;)

/mjt
Oleg Sadov Oct. 18, 2010, 5:30 p.m. UTC | #4
Sorry for delay with answer -- vacations time without e-mail account
access.

07/10/2010 08:38 +0400, Michael Tokarev wrote:
> 06.10.2010 23:56, Eduardo Habkost wrote:
> > 
> > Anybody using a russian keyboard layout who can test this change and
> > confirm it works as expected?
> 
> I can perform such a testing - in theory.  But in practice, I was never
> able to figure out this -k $lang stuff, -- neither in qemu nor in other
> apps like rdesktop and the like.
> 
> What I usually do is to explicitly set en-us keyboard for applications
> that are "too smart" and tries to guess "right" keyboard from env.
> variables such as $LANG.
>
> The reason is that after specifying "ru" keyboard, I can't use latin
> chars anymore, and can type only using cyrillic.  Since cyrillic
> layout does not have any latin char, imagine how to type, say, a
> path name (even "C:" drive in windows).
>
> All modern OSes nowadays have a way to switch between keyboard layouts
> dynamically - this is done internally in the operating system.  So,
> basically, I've no idea what this -k $foo stuff is used for to start
> with ;)
>
> Care to explain please?  Oleg?  :)

I don't understand reasons for such locale-default keyboard settings for
qemu too, but may be it's useful for someone...

> Thanks!
> 
> /mjt

Regards!
--Oleg
Anthony Liguori Oct. 18, 2010, 6:59 p.m. UTC | #5
On 10/18/2010 12:30 PM, Oleg Sadov wrote:
> I don't understand reasons for such locale-default keyboard settings for
> qemu too, but may be it's useful for someone...
>    

-k only exists to deal with crappy VNC clients.

If you use a good VNC client (like vinagre or virt-viewer) then you 
don't have to use -k.

Regards,

Anthony Liguori

>> Thanks!
>>
>> /mjt
>>      
> Regards!
> --Oleg
>
>
>
Daniel P. Berrangé Oct. 19, 2010, 9:32 a.m. UTC | #6
On Mon, Oct 18, 2010 at 01:59:15PM -0500, Anthony Liguori wrote:
> On 10/18/2010 12:30 PM, Oleg Sadov wrote:
> >I don't understand reasons for such locale-default keyboard settings for
> >qemu too, but may be it's useful for someone...
> >   
> 
> -k only exists to deal with crappy VNC clients.
> 
> If you use a good VNC client (like vinagre or virt-viewer) then you 
> don't have to use -k.

Indeed you must *NOT* use -k then, because that disables the extension
that vinagre/virt-viewer rely on for sane keyboard handling.

Regards,
Daniel
Oleg Sadov Oct. 19, 2010, 2:16 p.m. UTC | #7
19/10/2010 10:32 +0100, Daniel P. Berrange wrote:
> On Mon, Oct 18, 2010 at 01:59:15PM -0500, Anthony Liguori wrote:
> > On 10/18/2010 12:30 PM, Oleg Sadov wrote:
> > >I don't understand reasons for such locale-default keyboard settings for
> > >qemu too, but may be it's useful for someone...
> > >   
> > 
> > -k only exists to deal with crappy VNC clients.
> > 
> > If you use a good VNC client (like vinagre or virt-viewer) then you 
> > don't have to use -k.
> 
> Indeed you must *NOT* use -k then, because that disables the extension
> that vinagre/virt-viewer rely on for sane keyboard handling.

I don't use '-k' option directly -- in my RHEL-based system it's
automagically appended to qemu-kvm by libvirt. KVM XML-description,
created by standard virt-manager GUI-interface (package
virt-manager-0.6.1-12.el5.x86_64), has a 'keymap' attribute of
'graphics' tag, despite that configurator don't have any controls for
'keymap' setting.

As I understand, 'default_keymap' function from util.py (package
python-virtinst-0.400.3-9.el5.noarch) got information
from /etc/sysconfig/keyboard, then keymap searched in 'keytable'
dictionary from keytable.py and automatically placed to 'keymap'
attribute of 'graphics' tag in virtual-machine XML-description.

In our system we have a russian keyboard settings => we've got a XML
description like this:

 <graphics type='vnc' port='-1' autoport='yes' keymap='ru'/>

and, as a consequence, qemu-kvm running with '-k ru' option.

> Regards,
> Daniel

Sincerely,
--Oleg
diff mbox

Patch

diff --git a/pc-bios/keymaps/ru b/pc-bios/keymaps/ru
index b3e7d24..70a68f4 100644
--- a/pc-bios/keymaps/ru
+++ b/pc-bios/keymaps/ru
@@ -105,5 +105,3 @@  Cyrillic_yu 0x34 altgr
 Cyrillic_YU 0x34 shift altgr
 slash 0x35
 question 0x35 shift
-slash 0x56 altgr
-bar 0x56 shift altgr