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
