Bug 386900

Summary: KScreen picks wrong resolution in QEMU on wayland
Product: [Plasma] KScreen Reporter: Fabian Vogt <fabian>
Component: commonAssignee: Sebastian Kügler <sebas>
Status: RESOLVED FIXED    
Severity: major CC: mgraesslin
Priority: NOR    
Version First Reported In: git   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
URL: https://phabricator.kde.org/D8828
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Fabian Vogt 2017-11-14 11:37:44 UTC 
With QXL and virtio, kscreen tries to set the mode of the output to 4096x2160@60Hz, which results in a not updating screen. It's not possible to recover from this situation.

The same issue appears on X, but kscreen does not pick the resolution on startup, so it's a bit less critical.

I'm not sure where the actual bug is (kernel, QEMU, spice).
Comment 1 Fabian Vogt 2017-11-14 19:20:55 UTC 
Looks like this is a bug in QEMU, some kind of allocation failure. Probably some kind of internal buffer is too small... Anyway, this shouldn't be triggered at all automaticaly.

I can easily explain the difference to X now: It seems like libkscreen does not handle the preferred attribute on kwayland modes yet, so it always picks the one with the biggest area (+ refresh rate).

I suggest adding the current mode as preferred mode on startup - this should be the native resolution (or at least a mode that works) in most cases anyway and can easily be overwritten on the kernel cmdline.
Comment 2 Martin Flöser 2017-11-15 05:22:10 UTC 
The protocol provides a preferred flag on the mode. You might be able to verify with weston_info that KWin sets the preferred flag correctly.
Comment 3 Fabian Vogt 2017-11-15 17:16:14 UTC 
(In reply to Martin Flöser from comment #2)
> The protocol provides a preferred flag on the mode. You might be able to
> verify with weston_info that KWin sets the preferred flag correctly.

I skipped that step as it has to be added to kscreen anyway and it looks like it works fine: https://phabricator.kde.org/D8828
Comment 4 Sebastian Kügler 2017-11-16 10:22:53 UTC 
Thanks! Let's close this bug then, if the problem persists, we can always re-open it and investigate further.