On Fri, Aug 17, 2018 at 11:16:29AM -0400, Phillip Susi wrote: > On 8/17/2018 11:05 AM, Daniel P. Berrangé wrote: > > Reading again, this is a bit odd. On most keyboards, holding down shift > > key generally would NOT change the scan code that is reported (there are a > > Right; a real keyboard won't change the scan code, but it seems that > European keyboards have this extra key that can also produce a |, so > when qemu gets the key code for |, it has to pick one scan code or the > other to translate the | into, and it picks the wrong one.
There have been fixes for that one, specifically recent qemu will look at modifier state in addition to the keysym when looking up the keycode, because some keymaps can generate the same keysym with different key combinations, and most of the time they have different modifier state. In this specific case the us kbd key generates '|' with shift while the 105th key of i18n kbds generates '|' with altgr, so it should actually improve things. So, try upgrade qemu. > Looking at the code it looks like qemu has its own qcode set and > translates between that and all of these other sets. I'm guessing > either input-keymap-linux-to-qcode.c or input-keymap-x11-to-qcode.c is > where the error is, but these do not exist so I guess they must be auto > generated somehow by the build process? No. It's ui/keymaps.c. Keymaps are in pc-bios/keymaps/, generated by qemu-keymap.c. HTH, Gerd