|
Bugzilla – Full Text Bug Listing |
| Summary: | YaST2 Black windows under Wayland | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Andrei Borzenkov <arvidjaar> |
| Component: | YaST2 | Assignee: | E-mail List <yast2-maintainers> |
| Status: | RESOLVED INVALID | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | arvidjaar, fvogt, schubi |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | KDE Wayland session | ||
Please check if other non-KDE Qt5 programs (e.g. QDirStat) show the same behaviour. (In reply to Stefan Hundhammer from comment #1) > Please check if other non-KDE Qt5 programs (e.g. QDirStat) show the same > behaviour. yes, please :-) I tested QDirStat both under KDE (Wayland and Full Wayland) and GNOME. In KDE it looks OK. In GNOME I get black screen (except window decorations) for a short time immediately after program start which is then repainted; further actions in QDirStat look OK. I also tested behavior when running QEMU under X11 backend (GDK_BACKEND=x11) and I still see the same effects when starting YaST2 in guest Wayland. It seems like you have virgl enabled ("gl=core"/"gl=on"). In my experience that's a source of frequent graphical glitches, including black window parts. Do you still see this issue without virgl?
(In reply to Fabian Vogt from comment #4) > Do you still see this issue without virgl? No. But interface feels a bit lagging. I built virglrenderer from GIT and no more observe this issue with YaST2. Thank you! |
Created attachment 843473 [details] KDE Wayland session Host - Ubuntu 20.04 GNOME Wayland session. QEMU 5.1.0 compiled from source. Guests - two VM with Tumbleweed, GNOME (Wayland session) and KDE (both Wayland and Full Wayland). In all cases starting YasT2 in guest results in black window, completely or partially. Depending on other activity parts of window may be repainted, but it looks rather random. QEMU command line: "${QEMU_BIN}" \ -nodefaults \ -machine q35,accel=kvm \ -cpu host \ -m 1G \ -device virtio-scsi-pci \ -drive file=$HOME/vm/tw/hd0.raw,if=none,id=hd0,discard=on,format=raw -device virtio-blk,drive=hd0,id=hd0 \ -netdev user,id=uplink -device virtio-net-pci,netdev=uplink \ -netdev user,id=avahi -device virtio-net-pci,netdev=avahi,mac=de:ad:be:ef:01:01 \ -virtfs local,path=$HOME,security_model=none,mount_tag=home \ -drive file=$HOME/vm/tw/test.raw,if=none,id=hd1,discard=on,format=raw -device virtio-blk,drive=hd1,id=hd1 \ -drive file=$HOME/vm/tw/test2.raw,if=none,id=hd2,discard=on,format=raw -device virtio-blk,drive=hd2,id=hd2 \ -name Tumbleweed \ -vga virtio -display gtk,gl=core,zoom-to-fit=off \ -monitor unix:path="$QEMU_MONITOR_SOCKET",server=on,wait=off \ -usb -device usb-ccid -device ccid-card-emulated,backend=certificates,db=sql:vm/tw/sc,cert1=id-cert,cert2=signing-cert,cert3=encryption-cert \ & and "${QEMU_BIN}" \ -nodefaults \ -machine q35,accel=kvm,vmport=off \ -cpu host \ -m 2G \ -drive if=pflash,format=raw,unit=0,file=$HOME/vm/${VM}/ovmf-x86_64-ms-4m-code.bin,readonly=on \ -drive if=pflash,format=raw,unit=1,file=$HOME/vm/${VM}/ovmf-x86_64-ms-4m-vars.bin \ -device virtio-scsi-pci \ -drive file=$HOME/vm/${VM}/hd0.raw,if=none,id=hd0,discard=on,format=raw -device virtio-blk,drive=hd0,id=hd0 \ -netdev user,id=uplink -device virtio-net-pci,netdev=uplink \ -virtfs local,path=$HOME,security_model=none,mount_tag=home \ -name Tumbleweed-UEFI \ -vga virtio -display gtk,gl=on,zoom-to-fit=off \ -device virtio-tablet \ -monitor unix:path="$QEMU_MONITOR_SOCKET",server=on,wait=off \ -boot menu=on \ & Attached screenshot how it looks like. So far everything else I used in these two VMs worked, YaST is the only serious exception.