option to specify the video, please do not forced the slow qxl

[mckaygerhard]

noted that this GUI force to use only video modes with vnc or xql those are pretty SLOW to make virtual machines for games or developt GUI tools

this comand line is always added and assumed:

-qmp \
unix:/<path>/<vmname>/qmp.sock,server,nowait -vga qxl -spice port=5900,disable-ticketing=on,addr=127.0.0.1 

request:

PLEASE PROVIDE OPTION TO DISABLE FORCE XQL VIDEO OR ALSO DISABLE REMOTE MANAGEMENT APART OF THE SPECIFICATION OF #173 COS XQL VIDEO IS PRETTY SLOWWW respect virtio (linux) or cirrus (others) video ,modules

[mckaygerhard]

In order of best compatibilty to most improvement as https://venenux.github.io/alpine-wiki/#/documents/alpine-newbie-qemu-virtualization#display-video-and-device-recommendations before many test:

1. -device cirrus-vga,vgamem_mb=16 the most compatible with older and modern systems, this has only most common features and enables the needs of vgabios, uefivga, VGA output and any OS supported, allows max 16Mgs video and is the best choice compatibility wise, pretty much any guest should be able to bring up a working display on this device; on default use 4Mgs of video, it not gets full hd but is close to 1024p if use 16 megs, The best option for older systems emulation and full emulation compatibility
2. -device virtio-vga,max_outputs=2 the most compatible with modern and up to date systems, has no dedicated video memory (except VGA compat.), if supports vgabios, uefivga, VGA output, gest os will need special module that is since 3.2 into linux; it gets full HD on it defaults, has (optional) hardware-assisted opengl acceleration which in turn needs opengl support enabled if -display xxx,gl=on is enabled in the qemu display (sdl/gtk), recommended for both modern or older systems with support of opengl but will require KVM support on host machine.
3. -device ramfb very simple display device; sets a framebuffer stored in guest memory; does not have vga, support vgabios and uefivga; the firmware initializes it and allows to use it as boot display (grub boot menu, efifb, ...) without needing complex legacy VGA emulation. Only recommended for SOC devices like older ARM boars emulation
4. -device bochs-display the simple linear framebuffer, with modesetting, does not have vga, supports vgabios, supports uefivga, and is linux focused; firmware will setup a linear framebuffer as GOP anyway and never use any legacy VGA features, so this device is best option for UEFI related; also this is best option for server virtualized implementation. This is the default in qemu if you dont specify any vga device!
5. -device xql-vga mostly dated, it feature is multihead support to a second display to remote connection, mostly for crap operating systems; if supports vgabios, uefivga, VGA output and any guest OS will support it; featured 2D acceleration so is mostly great for remote connection, but relies on a special client, offloading 2D acceleration to the spice client mostly virt-viewer; its best option for modern and older combinations.
6. -device virtio-gpu,max_outputs=2 the most featured with modern and up to date systems, has no dedicated video memory, it lack of VGA layer, only has uefivga, will reduce the attack surface (no VGA emulation) and reduce the memory footprint by 8 MB (no pci memory bar for VGA compatibility); that is since 4.0 into linux; it gets full HD on it defaults, has (optional) hardware-assisted opengl acceleration which in turn needs opengl support enabled if -display xxx,gl=on is enabled in the qemu display (sdl/gtk) gpu data will be stored in main memory instead. This option is the best for linux or mac modern system and modern platform desktop emulation but will require of KVM on host machine.

[0x501D]

Currently supported display types are: Adding new ones there is not a problem.

[mckaygerhard]

after many test i noted that based on the buch of qemu machine types.. ther are a lot of combinatios forced.. by example @0x501D take note of:

• best for any UEFI as test for sure to display any is the -device bochs-display in combination with vga/std/cirrus display of gtk/sdl output.. it makes sense cos if you forced KVM of amd64 and you are under ARM6 this will segfault (what happpened to me also)
• best for 2008 or older when you used i386 is the cirrus vga that will ofer mas of 16 megs of gram .. in this way the opengl -display xxx,gl=on will not be supported..
• best for arm older 32bit devices are the ramfb only if you dont plan to deploy a desktop .. (those devices are suppose to be super limited so desktop display are not option here) so in this way the opengl -display xxx,gl=on will not be supported.. no matter if you have KVM will not make sense.. inclusive if both host and guess are same arch
• best for AMD64 are virtio ONLY if host is also AMD64 copatible arch and up to date GPU, but is the host does not have a valid opengl 3.0 gpu capable device the KVM will be unnable to perform so good so this is a special filter to do..

[mckaygerhard]

i forgotten, virtio wil need KVM that not always is available as i posted in #178 if you are under aarch64 and wants to emulated amd64 you got segfault in your nemu ui cos kvm is forced and not available due incompatible archs.. in same way happened if you requested arm6 32bit and are under i386