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).

12.01.2019 14:51, halfdog wrote:

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 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.

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?

Here I don't understand. Are your mobile screen SMALLER than the
guest screen, so that qemu has to scale DOWN?

Thanks,

/mjt

Michael Tokarev writes:

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.

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.

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).

No, it is enabled as all USB features are disabled for security
reasons.

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).
(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

13.01.2019 0:46, halfdog wrote:
[]

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.

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.

Please try it with -usb -usbdevice tablet to see whenever it fixes
your issues.

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.

So it is still distorted...

[]>> Here I don't understand. Are your mobile screen SMALLER than the

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

Michael Tokarev writes:

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.

I tried it. With that device the pointer is invisible with both
[Grab]-[Fullscreen] and [FS]-[Grab] control sequence.

Thanks for that hint! I guess wasting 6 horizontal pixels would
be completely OK, so running guest on "1360x768" might be another
workaround.

I do not know why Lenovo selected that size for all the small size
Thinkpads, but it is really convenient :-)
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.

Maybe not, if I try to apply your modulo(8) trick (after others).

Yes. In general I want to completely get rid of pixel-rot, therefore
the fullscreen setups. Apart from that while in fullscreen mode,
it shall not be possible to click/activate anything outside the
guest display (activate a host window frame, a background menu,
send a keystroke) ... Any data transfer or interactions concearning
both guest and host have to be done via separate filter transports
that enforce strict security policies. Thus as a guest user it
should be harder to be tricked into executing/transfering control
commands to the host on error.

hd

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.

  Hi,

Why do you grab in the first place?

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 ...

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

Hello,
Good day!
This is Top LED Product Factory from in China.
We are specialize in LED Product for 10years,and capable production,promised delivery time and high level quality!
Please sent purchase detail info(as type/specifications/quantity Ect).We can provide you with the best price.

Also we have our own professional designers to meet any of your requirements.
Sincerely,
Andy

Hello,
Good day.
We are manufacturers of all kinds of LED PRODUCT in China.
If you are interested.kindly reply to know more about us and contact us for your order.
We deliver worldwide at the cheapest prices.

Also we have our own professional designers to meet any of your requirements.
Sincerely,
Andy

Hello,
How are u!
We are a manufacturer of LED Product from China, if you need to buy it,
And inform us of the item/s and quantities required, including your details and we will be more then willing to quote you.

We look forward to a wonderful relationship together and success for all concerned.
Best regards,
Andy

Hi There,
Wish you have a nice day.
Knowing you are in business of Lighting
We are Manufacturer and Exporter in all kinds of Lighting.

1. Customized is acceptable.
2. OEM service is provided.
3. High Quality and Stabled delivery is ensured.
Any interest pls reply then we quote good price.

So we want to avail ourselves of opportunity establishing business relation with you.
Best regards,
Andy