I'm not subscribed there, so will note here: I tried the proposed
changes - the commits from https://lists.gnu.org/archive/html/qemu-
devel/2018-12/msg04819.html , backported to 3.0.0 - and that seems to
work. A test which would previously have hit this bug ran OK, without
the changes to the en-us
Discussing the problem & likely solution here:
https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04631.html
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1738283
Title:
'Less than' (<),
Indeed the bug does not exist in this exact form any more, but it seems
the stray '86' keymap entry *does* still cause problems in current qemu
in one specific case:
https://bugzilla.redhat.com/show_bug.cgi?id=1658676
basically, if using 'usb-kbd', we still get trouble when openQA (os-
autoinst)
QEMU 2.12 has now been release, so marking this one as "Fix Released".
** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1738283
Title:
FYI this seems to be fixed with qemu.git master, I didn't track down the
specific commit but there were several keymap related changes. so qemu
2.12 will be fixed
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because you are a member of qemu-
We ran into this as well, using qemu 2.11.0. We're not using the "-k
en-us" command line flag, and we're using noVNC as a client (which
supports the QEMUExtendedKeyEvent encoding)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
I found Adam's patch from Fedora Rawhide
(https://src.fedoraproject.org/rpms/qemu/c/f81be8f0261cce74799f946e99f23d57f8db7e17?branch=master)
when applied to openSUSE's 2.11.0 QEMU effective in openQA as well as
manually with vncviewer.
--
You received this bug notification because you are a
Note: I wondered if specifying a correct model for qemu-keymap to pass
to xkb would help. But it doesn't :( That is, these:
qemu-keymap -l us
qemu-keymap -l us -m pc101
qemu-keymap -l us -m pc104
qemu-keymap -l us -m pc105
all produce the same output except for the commented-out 'model' line at
Confirmed that dropping the offending keycode 86 definition out of
keymaps/en-us fixes the problem. Scratch build for Fedora Rawhide was
https://koji.fedoraproject.org/koji/taskinfo?taskID=23814932 , I'll
probably send this out as an official build so I can get os-autoinst
built without hacking up
FWIW, I think this keycode represents the key between the left shift key
and the first letter key on the fourth row, if there is one. European
keyboards have one, and on e.g. a UK keyboard it types a \ unshifted and
a | shifted - this is exactly how it looks in the en-gb keymap file:
# evdev 86
Aha. This looks like my bug!
I'm running into this in what I suspect is the same situation as Michal
Nowak: openQA. But in Fedora. openQA (well, its test runner, os-
autoinst) works by running virtual machines and interacting with them
over VNC. It seems that with qemu 2.11, typing certain
I found something interesting using showkey in the VM. This is all
assuming en-US everywhere, note. On a US keyboard, "<" is a shifted
comma (shift-,), ">" is a shifted period (shift-.), and "|" is a shifted
backslash (shift-\).
If I run showkey and try the affected characters in virt-manager,
I also confirm Michal's observation of virt-manager and tigervnc
behaving differently with the same VM: I ran a VM set up with VNC
display server in virt-manager and can type < from the virt-manager UI
fine, but if I connect to the same VM with tigervnc and try to type < ,
I get > . This is with
I note this block in pc-bios/keymaps/en-us with interest:
# evdev 86 (0x56), QKeyCode "less", number 0x56
less 0x56
greater 0x56 shift
bar 0x56 altgr
brokenbar 0x56 shift altgr
That block was added in commit a7815faffb2bd594b92aa3542d7b799cc89c5414
, which I am very suspicious was the cause of
Note, os-autoinst is its own VNC client. Most of the implementation can
be found in https://github.com/os-autoinst/os-
autoinst/blob/master/consoles/VNC.pm . The functions relevant to sending
key events are `shift_keys`, `init_x11_keymap`, `map_and_send_key`, and
`_send_key_event`.
--
You
If I start QEMU with `-k en-gb` at least '<' and '>' work, '|' doesn't
(and obviously 'Shift-2' produces '"' not '@').
My host `locale` is 'en_US.UTF-8' top to bottom.
I tried to update TigerVNC to 1.8 but no change. I run `vncviewer` with
'-Log *:stderr:100' and QEMU without '-k' option and at
Hello,
I confirm the same problem on Fedora 27 Server using Source code release
2.11.0
The problem remains no matter if I use the "-k en-us" parameter or not.
Worked fine up to 2.10.1
If the guess is Windows, then when trying to type the "<" character then
the pipe ("|") appears.
If the guess
By default virt-manager will *not* enable the '-k en-us' argument,
because that forces use of a specific keyboard layout in QEMU's VNC
server. For that to work, the VNC client keymap must exactly match the
QEMU VNC server keymap, and must also exactly match the guest OS keymap.
Instead
Well, if virt-manager is configured to run the VM with `-k en-us` I
can't enter <>| even in virt-manager. keycodemapdb?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1738283
Title:
'Less than'
Should have mention I use openSUSE Leap 42.3 with above mentioned
virtualization repo.
Removed the 0026-Fix-tigervnc-long-press-issue patch and rebuilt QEMU
but no change.
But I noticed that if I run the ISO via libvirt and connect to it via
virt-manager (virt-manager-1.4.1-4.1.noarch), the keys
Wondering if it's a SUSE-specific problem:
https://build.opensuse.org/package/view_file/Virtualization/qemu/0026
-Fix-tigervnc-long-press-issue.patch?expand=1
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
21 matches
Mail list logo
