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 > a way to turn it off I guess. 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
