Bug#919057: Qemu GTK display mouse pointer visibility/position problem
Hi, > I have similar problems as the original reporter, specifically, after > upgrading to qemu 3.1 from stretch [from qemu 2.8 -- mjt], mouse pointer > is invisible in guest systems iff the pointer is grabbed, > with -display gtk and qxl is used. > When using -vga std, both linux and windows guests show a mouse pointer. > likewise, with -vga qxl and/or additional -device qxl, a mouse pointer is > shown *iff* the input isn't grabbed. > > The behaviour is perfectly repeatable here: if I press ctrl-alt-g, mouse > pointer becomes invisible, ctrl-alt-g again, pointer becomes visible > again. Why do you grab in the first place? > I have tried this with both ubuntu 17.10 and windows 10 + qxl-dod driver > (virtio 0.141 and 0.164), and the behaviour is consistent, so I think > this is a bug in the gtk+ interface of qemu when qxl is used (or when a > hardware pointer is used, as I guess -vga std does not emulate a hardware > pointer). Yes, -vga std has no hardware cursor support. qxl has two modes: "server mouse mode" where the guest/spice-server renders the cursor (effectively software cursor), and "client mouse mode" where the spice-client renders the cursor (effectively hardware cursor, typically done by setting the window cursor to the guest cursor). "client mouse mode" is used in case a absolute pointing device is present, "server mouse mode" otherwise. Likewise qemu UIs (both gtk and sdl) do not grab the pointer in case a absolute pointing device is present, otherwise they do automatically grab the pointer on mouse clicks. So typically you run either in server mouse mode with grab or client mouse mode without grab. The gtk ui has some logic to handle that, specifically it hides the cursor in some cases to avoid that you see both software and hardware cursor. When manually activating the grab you are confusing that logic ... > Googling around, I saw recommendations to use -show-cursor - I have no > clue what it does, it didn't have any effect, either. Try "-display gtk,grab-on-hover=on"? That'll activate the *keyboard* grab in case the mouse pointer is within the qemu window, so hotkeys go to the guest instead of being captured by the hosts window manager. Then you don't have to manually activate the grab via Ctrl-Alt-G (which grabs both keyboard and pointer) for that. HTH, Gerd
Bug#919057: Qemu GTK display mouse pointer visibility/position problem
Package: qemu-system Version: 1:3.1+dfsg-4 Followup-For: Bug #919057 Dear Maintainer, I have similar problems as the original reporter, specifically, after upgrading to qemu 3.1 from stretch, mouse pointer is invisible in guest systems iff the pointer is grabbed, with -display gtk and qxl is used. When using -vga std, both linux and windows guests show a mouse pointer. likewise, with -vga qxl and/or additional -device qxl, a mouse pointer is shown *iff* the input isn't grabbed. The behaviour is perfectly repeatable here: if I press ctrl-alt-g, mouse pointer becomes invisible, ctrl-alt-g again, pointer becomes visible again. Note that the mouse otherwise behaves normally, i.e. with -device usb-tablet it is where the X11 pointer is, and it is "fully usable" in the guest, if you ignore the fact that you have to work blind :) This happens regardless of -device usb-tablet. I have tried this with both ubuntu 17.10 and windows 10 + qxl-dod driver (virtio 0.141 and 0.164), and the behaviour is consistent, so I think this is a bug in the gtk+ interface of qemu when qxl is used (or when a hardware pointer is used, as I guess -vga std does not emulate a hardware pointer). Basically, it seems that the gtk+ interface simply doesn't show the hardware pointer when input is grabbed, for whatever reason. Interestingly enough, when I change the shape of the pointer under both ubuntu and windows 10 guests, the shape is reflected by qemu (as long as input isn't grabbed, orf course), so the gtk interface is able to corretcly access the hardware pointer graphics form the guest. Googling around, I saw recommendations to use -show-cursor - I have no clue what it does, it didn't have any effect, either. -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 4.18.20-041820-generic (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages qemu-system depends on: ii qemu-system-arm1:2.8+dfsg-6+deb9u5 ii qemu-system-mips 1:2.8+dfsg-6+deb9u5 ii qemu-system-misc 1:3.1+dfsg-2+b1 ii qemu-system-ppc1:2.8+dfsg-6+deb9u5 ii qemu-system-sparc 1:2.8+dfsg-6+deb9u5 ii qemu-system-x861:3.1+dfsg-2+b1 qemu-system recommends no packages. qemu-system suggests no packages. -- no debconf information
Bug#919057: Qemu GTK display mouse pointer visibility/position problem
Michael Tokarev writes: > 13.01.2019 0:46, halfdog wrote: > > Michael Tokarev writes: > [] > >> There's no need to explicitly enable gtk/sdl display, it is the > >> default if the system has all the necessary packages installed > >> and if X environment is available. > > > > I see. After upgrading the Stretch nonrequired/nonexisting? package > > qemu-system-gui was not installed on Buster, so I installed it > > manually and forced the qemu call options as sugessted in forum > > posts by people having similar issues. > > qemu-system-gui is a recommended package. Usually and by default, > apt installs recommended packages. These are not installed only if > you explicitly disable this, by adding APT::Install-Recommends=0 > to /etc/apt.conf. But this is explicitly warned against, ... > > The large amount of deps for qemu-system-gui is the exact reason > why this whole thing popped out, ... I know that and REALLY appreciate the current behaviour! "Recommends" gives normal users good default setups, that work (but might be large, slow or security risks). Disabling "Recommends" just makes me search forums once each time packages change their "package ABI", but afterwards the automated installs will do exactly the right thing, depending on headless or graphical desktop configuration. > ... > >> Do you use USB Tablet device for guest (which syncronizes host and > >> guest mouse pointer)? > > > > No, it is enabled as all USB features are disabled for security > > reasons. > > Please try it with -usb -usbdevice tablet to see whenever it fixes > your issues. I tried it. With that device the pointer is invisible with both [Grab]-[Fullscreen] and [FS]-[Grab] control sequence. > >> Does the same erratic behavour occurs with other vga variants, > >> like std? > > > > I tried "-vga std" but it seems, that this one is completely broken > > when you have a non-standard real-hardware display size and want to > > use a guest display covering the full host-hardware-display in > > fullscreen mode (no pixel-rot on a quite small "1366x768" display). > > Yes that's lovely thing, stdvga only knows about standard VGA > sizes where the key point is that amount of horizontal dots must > be dividable by 8, so each display line ends on whole byte. Thanks for that hint! I guess wasting 6 horizontal pixels would be completely OK, so running guest on "1360x768" might be another workaround. > I don't > know where this 1366 come from but it was quite often requested > size and it really does not work... I do not know why Lenovo selected that size for all the small size Thinkpads, but it is really convenient :-) > BTW, I didn't know about -vga virtio, the first time I come across > it is this your bugreport. And yes this exact thing is done differently > in virtio vga, in a way which is incompatible with old VESA/VGA > interface (in particular there's no BitBLT operations there which > are mandated by VESA standard - that's the main reason why the > horisontal size should be dividable by 8, for bitblt to work right). Ah, that was helpful to locate more information, e.g. http://qemu.11.n7.nabble.com/Can-t-see-mouse-cursor-on-VNC-viewer-td612906.html When reconfiguring the server to use Section "Device" Option "SWcursor" "True" Identifier "Card0" ... the sequence [Grab]-[Fullscreen] restores the old sdl behaviour, which seems to be the best (and even an acceptable workaround) so far. This works both with and without the "usb tablet". As automated setup creates a stripped down, hardened X config anyway, adding this option is no real burden. It would be interesting to know, why the "hardware-cursor" is not displayed by the host gtk interface - maybe the graphics card on the host requires similar "hardware-cursor" support for that? Strange that completely identical X configuration worked with sdl. BTW why I wanted to switch std -> virtio: I would hope, that the attack surface of specialized virtual hardware is smaller as it does not have to "fake" 20 years of BIOS/bus/hardware specifics, which may all contain exploitable bugs. > ... > > With "-vga std" the mouse positioning and display seems to work > > both in window and full-screen mode (as far as I can guess from > > the reproducible/stable bute quite distorted graphics output). > > So it is still distorted... Maybe not, if I try to apply your modulo(8) trick (after others). > []>> Here I don't understand. Are your mobile screen SMALLER than the > >> guest screen, so that qemu has to scale DOWN? > > > > Yes, it is smaller, when not in full-screen mode: both screens > > (real hardware and virutal screen) have exactly the same size. > > When not in full screen mode, the top/bottom part of the GTK > > window reduces the usable real-screen size about 10%, thus the > > guest screen content has to be scaled down by 10$. > > Aha. So the real problem is that the menu bar, which is actually > not useful in your configuration, occupes space. There should be >
Bug#919057: Qemu GTK display mouse pointer visibility/position problem
13.01.2019 0:46, halfdog wrote: Michael Tokarev writes: [] There's no need to explicitly enable gtk/sdl display, it is the default if the system has all the necessary packages installed and if X environment is available. I see. After upgrading the Stretch nonrequired/nonexisting? package qemu-system-gui was not installed on Buster, so I installed it manually and forced the qemu call options as sugessted in forum posts by people having similar issues. qemu-system-gui is a recommended package. Usually and by default, apt installs recommended packages. These are not installed only if you explicitly disable this, by adding APT::Install-Recommends=0 to /etc/apt.conf. But this is explicitly warned against, as you're now supposed to watch for such "missing" packages for functionality you might be missing. Forcing the options is still not needed, as were with the sdl display before buster. BTW, qemu dropped sdl1 display support completely (the one used on Debian since the beginning) with 3.0 version iirc. I guess this might be related to running quite minimalistic window manager configurations, like mine requiring just ~25MB memory compared to the multi-100MB full-blown ones. Installing the "qemu-system-gui" even triggered gtk-base library installation as thay are not needed by anything else it seems. No, not installing qemu-system-gui is only related to your apt configuration, you explicitly told it to stop installing packages which are recommended. The large amount of deps for qemu-system-gui is the exact reason why this whole thing popped out, why this package has been separated in the first place. Many people use qemu on headless machines, where no X components are installed at all. These people (rightly) complained over the years that qemu forces them to install a ton of X support. Hence once this become possible we separated whole X support into a separate package. Now with some guest 3D support too, and with other extra features people asked about but I were unable to enable due to old sdl1 display on debian which doesn't have this stuff, and due to larger set of deps for gtk display. [] Thank you for the explanation about your window manager behavour. Do you use USB Tablet device for guest (which syncronizes host and guest mouse pointer)? No, it is enabled as all USB features are disabled for security reasons. Please try it with -usb -usbdevice tablet to see whenever it fixes your issues. Does the same erratic behavour occurs with other vga variants, like std? I tried "-vga std" but it seems, that this one is completely broken when you have a non-standard real-hardware display size and want to use a guest display covering the full host-hardware-display in fullscreen mode (no pixel-rot on a quite small "1366x768" display). Yes that's lovely thing, stdvga only knows about standard VGA sizes where the key point is that amount of horizontal dots must be dividable by 8, so each display line ends on whole byte. I don't know where this 1366 come from but it was quite often requested size and it really does not work. It is a nightmare to code this size in the bios, I've no idea how real hw does that. BTW, I didn't know about -vga virtio, the first time I come across it is this your bugreport. And yes this exact thing is done differently in virtio vga, in a way which is incompatible with old VESA/VGA interface (in particular there's no BitBLT operations there which are mandated by VESA standard - that's the main reason why the horisontal size should be dividable by 8, for bitblt to work right). Note that -vga std uses a separate video bios code (coming from seabios project) - this is the code which implements all the video handling. With "-vga std" the mouse positioning and display seems to work both in window and full-screen mode (as far as I can guess from the reproducible/stable bute quite distorted graphics output). So it is still distorted... []>> Here I don't understand. Are your mobile screen SMALLER than the guest screen, so that qemu has to scale DOWN? Yes, it is smaller, when not in full-screen mode: both screens (real hardware and virutal screen) have exactly the same size. When not in full screen mode, the top/bottom part of the GTK window reduces the usable real-screen size about 10%, thus the guest screen content has to be scaled down by 10$. Aha. So the real problem is that the menu bar, which is actually not useful in your configuration, occupes space. There should be a way to turn it off I guess. Why -vga std output is distorted in full-screen mode? Because of the non-standard resolution? BTW, I have the same screen size on my laptop, 1366x768. Thanks! /mjt
Bug#919057: Qemu GTK display mouse pointer visibility/position problem
Michael Tokarev writes: > 12.01.2019 14:51, halfdog wrote: > > Package: qemu-system-gui > > Version: 1:3.1+dfsg-2 > > > > After upgrading from Debian Stretch to Buster, thus changing > > the qemu version on host, "-display gtk" has to be used instead > > of "sdl" as the later is not available with Buster any more. > > There's no need to explicitly enable gtk/sdl display, it is the > default if the system has all the necessary packages installed > and if X environment is available. I see. After upgrading the Stretch nonrequired/nonexisting? package qemu-system-gui was not installed on Buster, so I installed it manually and forced the qemu call options as sugessted in forum posts by people having similar issues. I guess this might be related to running quite minimalistic window manager configurations, like mine requiring just ~25MB memory compared to the multi-100MB full-blown ones. Installing the "qemu-system-gui" even triggered gtk-base library installation as thay are not needed by anything else it seems. > > Since that switch the mouse behaviour changed, making guest machines > > (also Debian Buster) very hard to use. I do not know the old > > Stretch behaviour with "gtk" interface as I never used it. > > I don't remember already if gtk interface has been available in > stretch, I think I tried to switch to gtk but rolled it back at > some time. In previous version of qemu as has been available in > Debian (in buster), gtk interface had a lot of issues (that's why > I had to revert back to sdl, and did that at least twice). > > Current 3.1 gtk is quite stable finally, and it is the default > upstream too. That's why, I would like to switch so that the old sdl stuff can be abandoned to save open source developers time. But therefore I have to get it working beforehand. > > Reproduce: Run a qemu instance with "-vga virtio" and "-display > > gtk". Maybe the window manager is relevant also, using fvwm2 > > with an EdgeScroll configuration on host/guest shows the problematic > > behaviour. There are no specific guest additions installed in > > the guest nor acceleration in place. > > So guest is linux too? What's "EdgeScroll"? That is a window manager behaviour, where you let's say have 9 virtual desktops (3x3) and each one can hold windows. By moving the mouse on screen (1,1) to the right edige of the desktop, the window manager will switch to screen (1,2). Also the mouse pointer placement is adjusted, e.g. assuming a 800x600 screen, visible mouse position would change e.g. (300,580) -> (310,599) -> (315,5). > Do you use USB Tablet device for guest (which syncronizes host and > guest mouse pointer)? No, it is enabled as all USB features are disabled for security reasons. > Does the same erratic behavour occurs with other vga variants, > like std? I tried "-vga std" but it seems, that this one is completely broken when you have a non-standard real-hardware display size and want to use a guest display covering the full host-hardware-display in fullscreen mode (no pixel-rot on a quite small "1366x768" display). With "-vga std" the mouse positioning and display seems to work both in window and full-screen mode (as far as I can guess from the reproducible/stable bute quite distorted graphics output). > > Following options exist for still using the mouse/vm: > > > > a) Using "Grab input" and "fullscreen", the mouse position is > > correct, but one cannot see any guest mouse pointer. Only changes > > in hilighting or menu popups (when clicking) indicate the current > > mouse position. > > > > b) Using "fullscreen" and then "grab input" does show the mouse > > pointer but mouse position near the screen edge is not submitted > > to the guest, those events seem to be consumed on host before that. > > Thus those mouse positions cannot be reached in the guest window. > > > > c) Not using fullscreen: fonts are harder to read due to scaling > > on quite small mobile display (that's why the fullscreen preference > > to avoid pixel-rot). The mouse pointer is shown and edge detection > > would work theoretically, but it usually should happen in some > > undistinguishable area where the guest-screen-background color > > changes to the same color gtk-window-background, thus it is very > > hard to hit it with the pointer. > > Here I don't understand. Are your mobile screen SMALLER than the > guest screen, so that qemu has to scale DOWN? Yes, it is smaller, when not in full-screen mode: both screens (real hardware and virutal screen) have exactly the same size. When not in full screen mode, the top/bottom part of the GTK window reduces the usable real-screen size about 10%, thus the guest screen content has to be scaled down by 10$. > ... Thanks for your great committment to Debian package quality! hd
Bug#919057: Qemu GTK display mouse pointer visibility/position problem
12.01.2019 14:51, halfdog wrote: Package: qemu-system-gui Version: 1:3.1+dfsg-2 After upgrading from Debian Stretch to Buster, thus changing the qemu version on host, "-display gtk" has to be used instead of "sdl" as the later is not available with Buster any more. There's no need to explicitly enable gtk/sdl display, it is the default if the system has all the necessary packages installed and if X environment is available. Since that switch the mouse behaviour changed, making guest machines (also Debian Buster) very hard to use. I do not know the old Stretch behaviour with "gtk" interface as I never used it. I don't remember already if gtk interface has been available in stretch, I think I tried to switch to gtk but rolled it back at some time. In previous version of qemu as has been available in Debian (in buster), gtk interface had a lot of issues (that's why I had to revert back to sdl, and did that at least twice). Current 3.1 gtk is quite stable finally, and it is the default upstream too. Reproduce: Run a qemu instance with "-vga virtio" and "-display gtk". Maybe the window manager is relevant also, using fvwm2 with an EdgeScroll configuration on host/guest shows the problematic behaviour. There are no specific guest additions installed in the guest nor acceleration in place. So guest is linux too? What's "EdgeScroll"? Do you use USB Tablet device for guest (which syncronizes host and guest mouse pointer)? Does the same erratic behavour occurs with other vga variants, like std? Following options exist for still using the mouse/vm: a) Using "Grab input" and "fullscreen", the mouse position is correct, but one cannot see any guest mouse pointer. Only changes in hilighting or menu popups (when clicking) indicate the current mouse position. b) Using "fullscreen" and then "grab input" does show the mouse pointer but mouse position near the screen edge is not submitted to the guest, those events seem to be consumed on host before that. Thus those mouse positions cannot be reached in the guest window. c) Not using fullscreen: fonts are harder to read due to scaling on quite small mobile display (that's why the fullscreen preference to avoid pixel-rot). The mouse pointer is shown and edge detection would work theoretically, but it usually should happen in some undistinguishable area where the guest-screen-background color changes to the same color gtk-window-background, thus it is very hard to hit it with the pointer. Here I don't understand. Are your mobile screen SMALLER than the guest screen, so that qemu has to scale DOWN? So essentially one can decide beween working mouse cursor display or working mouse pointer position, but you cannot have both. The current workaround is to switch between a) and b) requiring 8 multi-key strokes and one mouse gesture instead of having just to move the mouse pointer to the edge of the screen (old behaviour with sdl). Thanks, /mjt
Bug#919057: Qemu GTK display mouse pointer visibility/position problem
Package: qemu-system-gui Version: 1:3.1+dfsg-2 After upgrading from Debian Stretch to Buster, thus changing the qemu version on host, "-display gtk" has to be used instead of "sdl" as the later is not available with Buster any more. Since that switch the mouse behaviour changed, making guest machines (also Debian Buster) very hard to use. I do not know the old Stretch behaviour with "gtk" interface as I never used it. Reproduce: Run a qemu instance with "-vga virtio" and "-display gtk". Maybe the window manager is relevant also, using fvwm2 with an EdgeScroll configuration on host/guest shows the problematic behaviour. There are no specific guest additions installed in the guest nor acceleration in place. Following options exist for still using the mouse/vm: a) Using "Grab input" and "fullscreen", the mouse position is correct, but one cannot see any guest mouse pointer. Only changes in hilighting or menu popups (when clicking) indicate the current mouse position. b) Using "fullscreen" and then "grab input" does show the mouse pointer but mouse position near the screen edge is not submitted to the guest, those events seem to be consumed on host before that. Thus those mouse positions cannot be reached in the guest window. c) Not using fullscreen: fonts are harder to read due to scaling on quite small mobile display (that's why the fullscreen preference to avoid pixel-rot). The mouse pointer is shown and edge detection would work theoretically, but it usually should happen in some undistinguishable area where the guest-screen-background color changes to the same color gtk-window-background, thus it is very hard to hit it with the pointer. So essentially one can decide beween working mouse cursor display or working mouse pointer position, but you cannot have both. The current workaround is to switch between a) and b) requiring 8 multi-key strokes and one mouse gesture instead of having just to move the mouse pointer to the edge of the screen (old behaviour with sdl).
