On Mon, Mar 02, 2020 at 07:19:04PM +0100, Thorsten Glaser wrote: > On Mon, 2 Mar 2020, Daniel P. Berrangé wrote: > > > There's two translations happening > > > > * The scancode emitted by the kernel and/or hardware device, > > and then translated/mangled by X11 and reported as the > > hardware keycode > > > > * The keysym which is the mapping from the hardware keycode > > done by XKB and/or Xmodmap > > Yes, sure. > > > We're dealing with the first point in QEMU, taking the hardware > > keycode and trying to undo the X11 mangling that was performed. > > That’s where VNC often fails, generally, anyway… (asd often get > translated back as adf). > > > > But if I can do anything to help debugging this, sure. > > > > Can you launch 'xev' inside your VNC session and press the 'Page Up' > > button and let me know what it reports the keycode and keysym. > > Sure. > > > Specifically I'm interested in this line of text: > > > > state 0x0, keycode 112 (keysym 0xff55, Prior), same_screen YES, > > > > On evdev it reports 112 as hardware code which is 0x70 hex, while with > > 'kbd' it reports 99 which is 0x63 hex. These are the only two scenarios > > QEMU knows how to cope with. > > Then we’re somewhat out of luck: > > KeyPress event, serial 35, synthetic NO, window 0x1000001, > root 0x25, subw 0x0, time 2624181177, (244,533), root:(250,560), > state 0x0, keycode 71 (keysym 0xff55, Prior), same_screen YES, > XLookupString gives 0 bytes: > XmbLookupString gives 0 bytes: > XFilterEvent returns: False
This is all rather unfortunate, as I can't determine the well known scancode set that this matches so far. So I'll definitely have to investigate the source to understand what's going on. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
