Re: qemu-system-x86_64: warning: Unknown X11 keycode mapping ''.
On Tue, Mar 03, 2020 at 02:12:04PM +0100, Thorsten Glaser wrote: > On Tue, 3 Mar 2020, Daniel P. Berrangé wrote: > > > AFAICT, this is not the case. On both my Fedora & Debian installs, > > x11vnc is just a binary that attaches to an existing X11 server > > Huh, weird. Perhaps this changed over the years and distro releases. > > > $ ls -al /usr/bin/vncserver > > $ realpath $(which vncserver) > /usr/bin/tightvncserver > > This does surprise me, because I also have x11vnc installed and > vaguely remember using it in standalone server mode for a while. > > But, yes, tightvncserver 1:1.3.9-9.1 is also installed, so I’m > apparently using that. Thanks, that gives me something to try to reproduce the problem now. 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 :|
Re: qemu-system-x86_64: warning: Unknown X11 keycode mapping ''.
On Tue, 3 Mar 2020, Daniel P. Berrangé wrote: > AFAICT, this is not the case. On both my Fedora & Debian installs, > x11vnc is just a binary that attaches to an existing X11 server Huh, weird. Perhaps this changed over the years and distro releases. > $ ls -al /usr/bin/vncserver $ realpath $(which vncserver) /usr/bin/tightvncserver This does surprise me, because I also have x11vnc installed and vaguely remember using it in standalone server mode for a while. But, yes, tightvncserver 1:1.3.9-9.1 is also installed, so I’m apparently using that. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Re: qemu-system-x86_64: warning: Unknown X11 keycode mapping ''.
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 0x101, > 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 :|
Re: qemu-system-x86_64: warning: Unknown X11 keycode mapping ''.
On Mon, Mar 02, 2020 at 01:43:12PM +0100, Thorsten Glaser wrote: > On Mon, 2 Mar 2020, Daniel P. Berrangé wrote: > > > "x11vnc" suggests you had a regular X11 desktop session, and are > > exporting it via VNC ? > > No, x11vnc is a standalone VNC server. AFAICT, this is not the case. On both my Fedora & Debian installs, x11vnc is just a binary that attaches to an existing X11 server and exports it - it doesn't provide an X11 itself, like tigervnc or tightvnc do. > > Can you tell me a bit more detail about how you launch this all. > > Sure: > > $ vncserver -geometry 1000x768 -name nowm :2 > $ (export DISPLAY=:2; exec >.xsession-errors; exec 2>&1; > icewm-session &) Can you tell me output of $ ls -al /usr/bin/vncserver On Debian this is normally a symlink to alternatives. If so, also tell me what this reports: $ ls -al /etc/alternatives/vncserver 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 :|
Re: qemu-system-x86_64: warning: Unknown X11 keycode mapping ''.
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 0x101, 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 I’ve also done a,s,d: KeyPress event, serial 35, synthetic NO, window 0x101, root 0x25, subw 0x0, time 2624183753, (244,533), root:(250,560), state 0x0, keycode 38 (keysym 0x61, a), same_screen YES, XLookupString gives 1 bytes: (61) "a" XmbLookupString gives 1 bytes: (61) "a" XFilterEvent returns: False KeyPress event, serial 35, synthetic NO, window 0x101, root 0x25, subw 0x0, time 2624184249, (244,533), root:(250,560), state 0x0, keycode 56 (keysym 0x73, s), same_screen YES, XLookupString gives 1 bytes: (73) "s" XmbLookupString gives 1 bytes: (73) "s" XFilterEvent returns: False KeyPress event, serial 35, synthetic NO, window 0x101, root 0x25, subw 0x0, time 2624184641, (244,533), root:(250,560), state 0x0, keycode 41 (keysym 0x64, d), same_screen YES, XLookupString gives 1 bytes: (64) "d" XmbLookupString gives 1 bytes: (64) "d" XFilterEvent returns: False I’ve tried looking at the sources for x11vnc-0.9.16 and tightvnc-1.3.9 but could not, within a quarter hour at least (got to go…), find out where those codes are mapped anyway other than a reference to XKeysymToKeycode (from libX11 probably). > For that matter, if you have time to help, it would be interesting to > see what it reports for a random selection of other keys too. For > example: > > @ KeyPress event, serial 35, synthetic NO, window 0x101, root 0x25, subw 0x0, time 2624747092, (82,98), root:(88,125), state 0x0, keycode 10 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 35, synthetic NO, window 0x101, root 0x25, subw 0x0, time 2624747284, (82,98), root:(88,125), state 0x1, keycode 19 (keysym 0x40, at), same_screen YES, XLookupString gives 1 bytes: (40) "@" XmbLookupString gives 1 bytes: (40) "@" XFilterEvent returns: False > # KeyPress event, serial 35, synthetic NO, window 0x101, root 0x25, subw 0x0, time 2624748276, (82,98), root:(88,125), state 0x0, keycode 10 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 35, synthetic NO, window 0x101, root 0x25, subw 0x0, time 2624748772, (82,98), root:(88,125), state 0x1, keycode 20 (keysym 0x23, numbersign), same_screen YES, XLookupString gives 1 bytes: (23) "#" XmbLookupString gives 1 bytes: (23) "#" XFilterEvent returns: False > $ KeyPress event, serial 35, synthetic NO, window 0x101, root 0x25, subw 0x0, time 2624749620, (82,98), root:(88,125), state 0x0, keycode 10 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 35, synthetic NO, window 0x101, root 0x25, subw 0x0, time 2624750028, (82,98), root:(88,125), state 0x1, keycode 21 (keysym 0x24, dollar), same_screen YES, XLookupString gives 1 bytes: (24) "$" XmbLookupString gives 1 bytes: (24) "$" XFilterEvent returns: False > ` This one is tricky because on my host keyboard layout ` is on the Escape key while the key left to 1 has Esc (except when shifted, so ~ is Shift plus the key left from 1). This is the physical Escape key, giving `: KeyPress event, serial 35, synthetic NO, window 0x101, root 0x25, subw 0x0, time 2624751028, (82,98), root:(88,125), state 0x0, keycode 33 (keysym 0x60, grave),
Re: qemu-system-x86_64: warning: Unknown X11 keycode mapping ''.
On Mon, Mar 02, 2020 at 01:43:12PM +0100, Thorsten Glaser wrote: > On Mon, 2 Mar 2020, Daniel P. Berrangé wrote: > > > "x11vnc" suggests you had a regular X11 desktop session, and are > > exporting it via VNC ? > > No, x11vnc is a standalone VNC server. > > > Can you tell me a bit more detail about how you launch this all. > > Sure: > > $ vncserver -geometry 1000x768 -name nowm :2 > $ (export DISPLAY=:2; exec >.xsession-errors; exec 2>&1; > icewm-session &) > > (I could run icewm-session from ~/.vnc/xstartup but this way it > inherits some more desirable environment variables.) > > My ~/.vnc/xstartup looks like: > > #!/bin/sh > > xrdb $HOME/.Xresources > xsetroot -solid grey > uxterm & > > > ...this suggests your running a VNC server, with embedded X11 server > > Yes, indeed. > > > > - xprop -root > > > > ...there's no _XKB_RULES_NAMES(STRING) property listed, which is the key > > thing we'd expect to see for a modern X server. eg > > > > _XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us", "", "" > > > > is what most X servers on Linux will report. Or 'kbd' instead of 'evdev' is fine too > > This is not a good assumption to make. For example, I’m also using > xmodmap instead of xkb for my keyboard layout under the main X.org > desktop. (It does carry the xkb information because Debian starts > it that way, but I replace it with xmodmap right in .xsessioinrc.) That shouldn't be a problem, as its a different level in the stack 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 The 2nd point here doesn't matter for QEMU. We're dealing with the first point in QEMU, taking the hardware keycode and trying to undo the X11 mangling that was performed. This mangling is different depending on whether the X11 server is using 'evdev' or 'kbd' as its input driver. So the key thing to understand is what values your X11 server is using for the hardware keycodes. > > Can you also say what QEMU version ? > > qemu-system-x86 1:4.2-3 > > > So either your QEMU is fairly old, or you are using a keycode mapping > > that QEMU has no understanding of (we support evdev, or the classic > > xfree86 'kbd' mapping). > > The latter is the Xmodmap one? If so, then okay. > > > It would be highly unusual not to use one of > > those two, but none the less, that appears to be the case here ? > > I must admit not knowing all that much about the VNC servers. > I used to use tightvnc, but that had issues with… somewhat I > don’t remember, so I now use tightvnc’s client but X11vnc as > standalone server. There’s also tigervnc, but that works even > worse for me. Ok, that's useful info to know. > 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. 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. I'm strongly suspecting your X11 server will report something different from either evdev or kbd driver hardware codes. For that matter, if you have time to help, it would be interesting to see what it reports for a random selection of other keys too. For example: @ # $ ` - + 1 2 3 a s d q w e , . / 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 :|
Re: qemu-system-x86_64: warning: Unknown X11 keycode mapping ''.
On Mon, 2 Mar 2020, Daniel P. Berrangé wrote: > "x11vnc" suggests you had a regular X11 desktop session, and are > exporting it via VNC ? No, x11vnc is a standalone VNC server. > Can you tell me a bit more detail about how you launch this all. Sure: $ vncserver -geometry 1000x768 -name nowm :2 $ (export DISPLAY=:2; exec >.xsession-errors; exec 2>&1; icewm-session &) (I could run icewm-session from ~/.vnc/xstartup but this way it inherits some more desirable environment variables.) My ~/.vnc/xstartup looks like: #!/bin/sh xrdb $HOME/.Xresources xsetroot -solid grey uxterm & > ...this suggests your running a VNC server, with embedded X11 server Yes, indeed. > > - xprop -root > > ...there's no _XKB_RULES_NAMES(STRING) property listed, which is the key > thing we'd expect to see for a modern X server. eg > > _XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us", "", "" > > is what most X servers on Linux will report. This is not a good assumption to make. For example, I’m also using xmodmap instead of xkb for my keyboard layout under the main X.org desktop. (It does carry the xkb information because Debian starts it that way, but I replace it with xmodmap right in .xsessioinrc.) > Can you also say what QEMU version ? qemu-system-x86 1:4.2-3 > So either your QEMU is fairly old, or you are using a keycode mapping > that QEMU has no understanding of (we support evdev, or the classic > xfree86 'kbd' mapping). The latter is the Xmodmap one? If so, then okay. > It would be highly unusual not to use one of > those two, but none the less, that appears to be the case here ? I must admit not knowing all that much about the VNC servers. I used to use tightvnc, but that had issues with… somewhat I don’t remember, so I now use tightvnc’s client but X11vnc as standalone server. There’s also tigervnc, but that works even worse for me. I also tested this in an RDP session with xrdp and xorgxrdp, but things work thereunder just fine. (No surprise, xorgxrdp just provides keyboard, mouse and video modules to an other‐ wise distro-standard X.org server, so the whole xkb first, xmodmap later, dance also applies there, although it doesn’t use evdev keycodes but the earlier PC standard ones from XFree86® and pre-evdev X.org.) But if I can do anything to help debugging this, sure. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Re: qemu-system-x86_64: warning: Unknown X11 keycode mapping ''.
On Mon, Mar 02, 2020 at 12:04:46AM +0100, Thorsten Glaser wrote: > I got this while running qemu under VNC, and was told to report it. > > including the following information: > > - Operating system > Debian GNU/Linux sid/x32 > - X11 Server > x11vnc 0.9.16-3 Can you tell me a bit more detail about how you launch this all. "x11vnc" suggests you had a regular X11 desktop session, and are exporting it via VNC ? But later... > - xdpyinfo > name of display::2 > version number:11.0 > vendor string:AT Laboratories Cambridge ...this suggests your running a VNC server, with embedded X11 server > - xprop -root ...there's no _XKB_RULES_NAMES(STRING) property listed, which is the key thing we'd expect to see for a modern X server. eg _XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us", "", "" is what most X servers on Linux will report. Can you also say what QEMU version ? QEMU since 2.12.0 or later has a second way to detect the keymap, by querying the scancode mapping for certain keys. So either your QEMU is fairly old, or you are using a keycode mapping that QEMU has no understanding of (we support evdev, or the classic xfree86 'kbd' mapping). It would be highly unusual not to use one of those two, but none the less, that appears to be the case here ? 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 :|
qemu-system-x86_64: warning: Unknown X11 keycode mapping ''.
I got this while running qemu under VNC, and was told to report it. including the following information: - Operating system Debian GNU/Linux sid/x32 - X11 Server x11vnc 0.9.16-3 - xprop -root _NET_ACTIVE_WINDOW(WINDOW): window id # 0x1400010 _NET_CLIENT_LIST(WINDOW): window id # 0x400010, 0x10b, 0x1400010 _NET_CLIENT_LIST_STACKING(WINDOW): window id # 0x10b, 0x1400010, 0x400010 _WIN_CLIENT_LIST(CARDINAL) = 16777227, 20971536, 4194320 ICEWM_GUI_EVENT(ICEWM_GUI_EVENT) = 0xf _WIN_DESKTOP_BUTTON_PROXY(CARDINAL) = 12583282 _WIN_WORKAREA(CARDINAL) = 0, 0, 1000, 743 _NET_WORKAREA(CARDINAL) = 0, 0, 1000, 743, 0, 0, 1000, 743, 0, 0, 1000, 743, 0, 0, 1000, 743 _NET_CURRENT_DESKTOP(CARDINAL) = 0 _WIN_WORKSPACE(CARDINAL) = 0 _NET_SHOWING_DESKTOP(CARDINAL) = 0 _NET_DESKTOP_VIEWPORT(CARDINAL) = 0, 0, 0, 0, 0, 0, 0, 0 _NET_DESKTOP_GEOMETRY(CARDINAL) = 1000, 768 _NET_NUMBER_OF_DESKTOPS(CARDINAL) = 4 _WIN_WORKSPACE_COUNT(CARDINAL) = 4 _NET_DESKTOP_NAMES(UTF8_STRING) = " 1 ", " 2 ", " 3 ", " 4 " _WIN_WORKSPACE_NAMES(STRING) = " 1 ", " 2 ", " 3 ", " 4 " WM_ICON_SIZE(WM_ICON_SIZE): minimum icon size: 32 by 32 maximum icon size: 32 by 32 incremental size change: 1 by 1 _NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0xc00014 _NET_SUPPORTED(ATOM) = _NET_ACTIVE_WINDOW, _NET_CLIENT_LIST, _NET_CLIENT_LIST_STACKING, _NET_CLOSE_WINDOW, _NET_CURRENT_DESKTOP, _NET_DESKTOP_GEOMETRY, _NET_DESKTOP_LAYOUT, _NET_DESKTOP_NAMES, _NET_DESKTOP_VIEWPORT, _NET_FRAME_EXTENTS, _NET_MOVERESIZE_WINDOW, _NET_NUMBER_OF_DESKTOPS, _NET_REQUEST_FRAME_EXTENTS, _NET_RESTACK_WINDOW, _NET_SHOWING_DESKTOP, _NET_STARTUP_ID, _NET_SUPPORTED, _NET_SUPPORTING_WM_CHECK, _NET_SYSTEM_TRAY_MESSAGE_DATA, _NET_SYSTEM_TRAY_OPCODE, _NET_SYSTEM_TRAY_ORIENTATION, _NET_SYSTEM_TRAY_VISUAL, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_STICK, _NET_WM_ALLOWED_ACTIONS, _NET_WM_DESKTOP, _NET_WM_FULLSCREEN_MONITORS, _NET_WM_HANDLED_ICONS, _NET_WM_ICON_NAME, _NET_WM_ICON, _NET_WM_MOVERESIZE, _NET_WM_NAME, _NET_WM_PID, _NET_WM_PING, _NET_WM_STATE, _NET_WM_STATE_ABOVE, _NET_WM_STATE_BELOW, _NET_WM_STATE_DEMANDS_ATTENTION, _NET_WM_STATE_FOCUSED, _NET_WM_STATE_FULLSCREEN, _NET_WM_STATE_HIDDEN, _NET_WM_STATE_MAXIMIZED_HORZ, _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MODAL, _NET_WM_STATE_SHADED, _NET_WM_STATE_SKIP_PAGER, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_STICKY, _NET_WM_STRUT, _NET_WM_STRUT_PARTIAL, _NET_WM_USER_TIME, _NET_WM_USER_TIME_WINDOW, _NET_WM_VISIBLE_ICON_NAME, _NET_WM_VISIBLE_NAME, _NET_WM_WINDOW_OPACITY, _NET_WM_WINDOW_TYPE, _NET_WM_WINDOW_TYPE_COMBO, _NET_WM_WINDOW_TYPE_DESKTOP, _NET_WM_WINDOW_TYPE_DIALOG, _NET_WM_WINDOW_TYPE_DND, _NET_WM_WINDOW_TYPE_DOCK, _NET_WM_WINDOW_TYPE_DROPDOWN_MENU, _NET_WM_WINDOW_TYPE_MENU, _NET_WM_WINDOW_TYPE_NORMAL, _NET_WM_WINDOW_TYPE_NOTIFICATION, _NET_WM_WINDOW_TYPE_POPUP_MENU, _NET_WM_WINDOW_TYPE_SPLASH, _NET_WM_WINDOW_TYPE_TOOLBAR, _NET_WM_WINDOW_TYPE_TOOLTIP, _NET_WM_WINDOW_TYPE_UTILITY, _NET_WORKAREA _WIN_AREA(CARDINAL) = 0, 0 _WIN_AREA_COUNT(CARDINAL) = 1, 1 _WIN_SUPPORTING_WM_CHECK(CARDINAL) = 12582932 _WIN_PROTOCOLS(ATOM) = _WIN_AREA, _WIN_AREA_COUNT, _WIN_CLIENT_LIST, _WIN_DESKTOP_BUTTON_PROXY, _WIN_HINTS, _WIN_ICONS, _WIN_LAYER, _WIN_PROTOCOLS, _WIN_STATE, _WIN_SUPPORTING_WM_CHECK, _ICEWM_TRAY, _WIN_WORKAREA, _WIN_WORKSPACE, _WIN_WORKSPACE_COUNT, _WIN_WORKSPACE_NAMES _XROOTCOLOR_PIXEL(CARDINAL) = 8256 _XROOTPMAP_ID(PIXMAP): pixmap id # 0x0 _ICEWMBG_PID_S0(CARDINAL) = 4749 RESOURCE_MANAGER(STRING) = "*VT100*translations:\t#override \\n Shift~CtrlInsert:insert-selection(PRIMARY) \\n Shift CtrlInsert:insert-selection(CLIPBOARD) \\n ~Shift~Ctrl:insert-selection(PRIMARY) \\n Shift~Ctrl:insert-selection(CLIPBOARD) \\n ~Shift:select-end(PRIMARY) \\n Shift:select-end(CLIPBOARD)
qemu-system-x86_64: warning: Unknown X11 keycode mapping ''
This error occurs when using any version of vncviewer on any platform and connecting to Debian 10 Buster. The operating system is: Linux Debian 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) a86_64 GNU/Linux The X11 Server is: xfce4 The contents of xprop -root are in the attached xprop-root_contents file. The contents of xdpyinfo are in the attached xdpyinfo_contents file The issue is that key mappings will only work from the command line of a terminal when vncviewer is attached to the host tightvnc server. However, if a recent version of qemu-system-x86_64 is started using UEFI, no keystrokes are passed on to the UEFI Shell or any menu choice. The guest just ignores any and all keyboard input. I hope you can fix this issue as it limits the ability to use QEMU from the vncviewer. Thos problem does not happen when running qemu from the host terminal window. Thank you, Oliver Bailey xprop-root_contents Description: Binary data xdpyinfo_contents Description: Binary data
