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

Reply via email to