tim

make sure you run eliloconfig which copies over whatever /boot/vmlinuz link points to to the efi boot partition, and also copies over whatever /boot/initrd.gz points to to the efi boot partition. If you have manually compiled a kernel and it is not pointed to via those simlinks, you need to manually copy your kernel and initrd to /boot/efi/EFI/Slackware and update your elilo.conf file appropriately. elilo uses the uefi boot partition fat32 reading functions to read the files, so cannot handle them...

not sure why its posted in elilo discussion, you've configured ignite-ux to configure elilo to boot from a location that is not visible at boot time via tftp. For lilo over tftp the path of images and initrd should be relative to the location of the elilo-ia64.efi file on the tftp directory. in otherwords, update the elilo-ia64.conf file and make image =isolinux/vmlinuz and similarly for initrd=isolinux/initrd.img

i tested with single and double connection to qemu vm, both ok, and also two connections, one to qemu client, and one to windows client, again both ok .

i tested with single and double connection ti qemu vm, both ok, and also two connections, one to qemu client, and one to windows client, again both ok .

that seems to fix the problem. no more flickering on remoting to qemu vm from windows client. thanks.

(same problem with a qemu 7.2.0 vm)

flickering connecting to qemu vm

many thanks. regards, Tim On 04/07/2022 03:55, William Kendrick wrote: status: open --> closed Comment: Amusingly, Tux Paint itself (via its call to |png_set_IHDR()| in |do_png_save()|) saves PNGs as interlaced, so when they are loaded, the "Interlace handling..." is echoed to STDERR. Not going to change that (for now), but will close this since all of the other STDERR-spamming culprit files that ship /with/ Tux Paint have been adjusted. (See https://sourceforge.net/p/tuxpaint/tuxpaint/ci/11ca37c8b494573e7ad68a4a6fe467b8c3f7ab64/)...