Bug 389329

Summary:	4k HiDPI wayland 2x display scaling issues
Product:	[Plasma] plasmashell	Reporter:	bug2017
Component:	generic-wayland	Assignee:	Plasma Bugs List <plasma-bugs-null>
Status:	RESOLVED NOT A BUG
Severity:	normal	CC:	kde, nate
Priority:	NOR
Version First Reported In:	5.11.95
Target Milestone:	1.0
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	current screenshot.png

Description bug2017 2018-01-22 21:29:30 UTC

I'm running the plasma-5.12 branch from the kde overlay (with qt 5.10). My Notebook has an 15.6" 4k screen. And on wayland I run into the fallout of the new scaling feature:
http://blog.davidedmundson.co.uk/blog/kwin_and_scaling/

Some of the issues:

1) Many applications which respect the screens resolution and scale well, are rendered with half resolution. It looks worse than a 1080p screen, where it is possible to enable sub pixel rendering for fonts.

2) The mouse pointer size changes depending on the window type, it shrinks to the half size above scaled up applications.

3) Kicker: The Application menu has much higher spacing between the items.

4) Tiling is ok for scaled up applications (like dia, chrome ...) But completely messed up for application which run on the native resolution (like kwrite):
Top Left corner: Almost maximized in top left
Left: Similar layout
Bottom Left: Similar size, but half of the window below the screen

Bottom right: Only the upper left quarter is visible (centered on bottom right corner)
Right: Only left half is visible
Top right: Similar to Right
For me it looks like these tiled applications windows are twice as large as they should be.

5) Full screen applications/games like sauerbraten: Not usable at all. Only the upper left quarter scaled by 2.
In window mode the mouse is not passed through. Without the ability to aim, it is quite unfair (maybe unrelated)

I suggest to set the default scaling for the upcoming plasma-5.12 back to 1x

While writing this bug report I have switched it back to 1x scaling and set the font DPI to 192. This setup give a much better 4k support. Some old legacy application don't scale correctly (like dia or imagej), but it would be much better to have fixes per window or application, than breaking the whole desktop.

In future it might be a good idea to not assume that a screen has 96DPI. It would be much better to respect the values from the EDID. In case of notebook screen a correction might be a good idea, as they are typically a little closer than regular screens.
The DPI override should move from the font configuration to each display. Maybe the display with the the highest DPI can be used as rendering resolutions. For other lower resolution display it would be better to downscale. But in that case even sub pixel rendering can help, to preserve as much information as possible.
So instead using a 2x scale, we need a 0.5x scale for peasant displays (or 0.33 for cloning too a 720p projector)

For legacy applications it would be nice to have an 2x scaling (which also fakes a 96dpi pixel size) Nice to have in the compositor would be an optional pixel art scaling algorithm like hq2x or 2xsai.

I think things like QT_SCALE_FACTOR should be only used for mitigation of legacy applications. Try to force a 2x scaling onto other applications will bring us crappy scaling for the next 5 years. After that it repeats with 8k notebook screens.

Comment 1 David Edmundson 2018-01-22 21:54:17 UTC

1) Those apps are probably running in X. There are very few apps that fall into the valley of having both have high DPI support and aren't being ported to wayland. It's an issue that will solve itself by the time wayland is mainstream.

2) There's another bug report for that somewhere

3) I don't understand, can you include a screenshot. Ideally as a new report.

4) What do you mean by tiling? Can you include a screenshot

5) As in you can only see the top left quarter when fullscreen?
If so will be fixed soon with the new xdg-output and new xwayland.

If you mean something else, please include a screenshot.

As for the rest, duly noted. I'm happy to fix any bugs, but I'm not going to revert any defaults. 

Your ideas miss some key aspects of how things work, and why they can't be done the way you suggest.
You can follow more on the threads of the wayland mailing list.

>So instead using a 2x scale, we need a 0.5x scale for peasant displays

If the app is scaling at 2x, and on a 1x screen, that's *exactly* what happens.
If the app can't scale to 2x then you're not in a position to halfscale it.

You can't just assume bodge "scaling" with font DPI, because an app has no way to report whether it's following that or not.. and we can't add a protcol for that into existing applications. 


 >I think things like QT_SCALE_FACTOR should be only used for mitigation of legacy applications.

That would mean kwrite would be tiny?

Comment 2 David Edmundson 2018-01-23 09:45:21 UTC

Marking as needs info as I'm waiting on the screenshots. Please reset status to unconfirmed when done, or reopen as relevant separate issues.

Comment 3 bug2017 2018-01-23 12:01:50 UTC

Created attachment 110072 [details]
current screenshot.png

1) That are X applications. (chrome, dia and a few others) Especially chrome works fine if the font dpi is set to 192

2) I think it is  bug 389337

3) I would like to attach a screenshot for the application issue, but bug 389164 makes it impossible. I will open that as new bug.

4) After updating, the tiling has improved (see screenshot). The size of the HiDPI windows is still a little bit off compared to the two dia windows below. Dragging the title bars to left, right and top, puts them still into a corner instead left/right half or maximized. I will test today evening again. And maybe report as a new bug.

5) Sauerbraten / fullscreen, I've could get one screenshot, tried to get a better one and it crashed the session. I'm not sure if xdg-output is related to that issue, my guess would be that sauerbraten runs over xwayland and is scaled up like the other applications.

Comment 4 Christoph Feck 2018-02-05 23:27:57 UTC

David, does comment #3 provide the requested information? Please set the bug status or add a comment.

Comment 5 David Edmundson 2018-02-06 00:43:39 UTC

1. can't fix
2. cool, glad you've found a bug

if screenshots don't work, photos with your phone can do. 

3. There was a fix in p-f that might make a difference to some plasma widget sizes

4. by tiling you mean where you drag a window to a screen edge and it snaps to fill the quarter/half of the screen?

If Sauerbraten is an xwayland app, having it get the wrong screen size and drawing half of it offscreen is a known thing that I need to fix. Two different xwayland versions behave differently. I don't think I have a bug report for it, but it's going to happen for 5.13.

Comment 6 David Edmundson 2018-02-11 23:07:23 UTC

Please report back on 3 with frameworks 5.43 

and can you clarify 4.

Comment 7 Christoph Feck 2018-02-28 23:54:45 UTC

If you can provide the information requested in comment #6, please add it. Plasma developers still need more information to understand issue 4).

Comment 8 Christoph Feck 2018-03-29 13:57:50 UTC

To further investigate this issue, Plasma developers need the information requested in comment #6. If you can provide it, or need help with finding that information, please add a comment.

Comment 9 Christoph Feck 2018-04-26 21:22:54 UTC

No response, changing status. If you have new information, please add a comment.