My partner has acquired a Dell XPS15 with a QHD+ screen (3200x1800 @235dpi). Of course she wanted it dual-booted (openSUSE 13.1, and it's not booted Windows since ) but is having one or two issues with aspects of the workspace/desktop that don't cope well with the high DPI display.

In particular the system tray icons are so small as to make it not only near-impossible to see status indications, but so small as to make it rather hard to get the mouse cursor on them to change settings, get "hover" popups, etc.. I get that this is because the icons are fixed to a size, but not what is or will be done about it in new releases nor what the timeline for a fix is likely to be. Or whether nothing will be done about it until the next major release i.e. Plasma 2.

Would also be interested to know if fixes to how X deals with DPI (currently defaulting to 96) would resolve most of the issues experienced.

There's a page about high DPI issues here;

https://community.kde.org/KDE/High-dpi_issues

but it appears to be no longer maintained. If there's a high DPI working group and it needs testers, I've left enough space on her XPS to triple-boot it, so I'm happy to volunteer.

The settings we have changed to make KDE more usable I think could easily be scripted to make it easier for someone less technical to achieve the same result.

[[[For anyone reaching here trying to tweak KDE for a similar display, start with the KDE System Settings (Configure Desktop) and in Application Appearance, go to Fonts, enable Force Fonts DPI and set it to 144 or above, in Icons > Advanced set every icon type to at least one higher than it starts at. Then in Workspace Appearance > Window Decorations > Configure Decoration set Button Size to Very Large. Also set the Panel height to be 40+.

For Firefox page text to be displayed at a comfortable size, try about:config > layout.css.dpi and set it to 1.5 (and tinker from there).]]]

As that is a wiki page, I would advise adding the issues you have found to the page. Unfortunately i'm not aware of any specific group working on high-dpi screen issues.

Ok, have posted this as a bug (it is, particularly to a normal user, a Grave bug because it renders the desktop unusable on these high DPI screens and there's no easy way to resolve it).

https://bugs.kde.org/show_bug.cgi?id=329518

Confirmation and lots of votes welcomed

Promptly marked as duplicate of a 3 year old bug (it's not really) which is "unconfirmed" and unassigned. Insanity. Which way the QA contact details? Usability of a GUI environment on a top class display should surely (a) be high priority for a resolution and (b) damn easy to confirm.

> in Application Appearance, go to Fonts, enable Force Fonts DPI and set it to 144 or above;
You're "high quality screen" is apparently broken, at least exposes false EDID info - there should be no need to enforce this value, but it should be correctly determined by Xorg (as seen in "xdpyinfo | grep resolution") as it is on every "low quality screen" here.
If it's not, you better fix that though some /etc/X11/xorg.conf.d snippet.
You can also alter the value per session by "xrandr --dpi 144", but that should happen very early.

FDO style systray icons will never scale, since it's actually an embedded window, ie. part of that application.

A global zoom can only be perfomed by "xrandr --output [--mode|--scale]", ie. actually changing the screen resolution.
A scaling through the compositor could only happen on wayland (since X11 doesn't provide input redirection) and would not be any different anyway.

Kai Uwe Broulik has stated to work on this item for frameworks ("notKDE5")
https://git.reviewboard.kde.org/r/108504/
notice that kdelibs is feature frozen since "Thursday, May 12, 2011: KDE 4.7 Hard Feature Freeze" (because of the frameworks split)

And there's a page that lists various known issues.
https://community.kde.org/KDE/High-dpi_issues

I btw. googled all that up within 5 minutes.

Thanks for the Google, I saw most of that info and more, including one discussion indicating X has force set 96DPI. If the screen wasn't reporting the correct information how would Windows 8.1 be scaling appropriately? I also understand that the shipping Ubuntu install also now works correctly, with some minor fixes.

The systray issue is an open bug:

https://bugs.kde.org/show_bug.cgi?id=133936

If it wasn't going to be fixed surely it would be marked "Will not fix"?

I referenced and linked the wiki page above in the OP, looks inactive in that last batch of fixes are marked for 4.9 series, nothing for 4.11 or 4.12 - so either the page is no longer being used to post updates or resolving visual/UX issues has been set as a low priority - which is odd for a GUI.

For FDO systray "it's complicated"
Of course a hardcoded value in the systemtray implementation is a bug in the systray only, but you're stuck with what the client offers nevertheless - what's usually 22px and only sometimes (little) more (of course it would be possible to make the icon bigger and paint a local image as icon, but that would not cover icon changes, nor would clicking into expanded regions cause any feedback)
The dbus driven SNI protocol allows for random sizes, though.

The resolution is supposed to be calculated from the announced physical geometry and the set resolution by Xorg - unless it's somwhere set explicitly (eg. through xorg conf snippet or xrandr call), what might be distro dependent.
The computed dpi (iff so) should show up in /var/log/Xorg.0.log; to inspect the edid information, you can use read-edid and edid-decode (you'll likely have to install that)

About fixes towards 4.11/4.12
As mentioned kdelibs was feature frozen for the frameworks split and since (Kai determined and it's true that) it makes far more sense to add the resolution awareness in the supplying libs than to each client, you cannot expect fixes in this regard for any "KDE SC 4" (i hope that's the corect marketing term de toujours version.
kde-workspace is feature frozen since 4.11.0, so nothing will happen on that front either (until it became "plasma workspaces 2" or whatever it will be called on release)

So the remaining high DPI issues for KDE are "will not fix"?

They will be fixed, but can only be fixed in a later version - as the underlying libraries the current version is based upon are frozen.

My hidpi use case is related, though a bit different.

I have a laptop with resolution 3200x1800. I'd like to use it in a dual-screen setup with an external 24" monitor, 1920x1200. After some research, I think KDE itself doesn't support this at all, and the proposed font / icon size changes are a wrong approach for this: increasing font size and icon size would affect both screens, which obviously will render the external monitor unusable.

It's possible to tell xrandr to scale the other screen (as explained at http://forums.linuxmint.com/viewtopic.php?f=42&t=159064), but that leads to mouse pointer issues where the pointer either is huge on the external screen, or tiny on the laptop screen. Also, one will lose any gains from using a high dpi screen, and the login screen isn't affected.

It's also possible to decrease the resolution on the laptop screen. This, too, will naturally negate any hidpi gains.

I'm wondering if I should create a new bug ticket of this use case, just to have it documented. Or maybe I'm missing some aspect of the proposed changes and this could be supported sometime in the future?

the "correct" way is to enforce some resolution:

xrandr --dpi 120

Afaik, you cannot have different densities on one X11 screen, where "one X11 screen" is any setup where you can move windows between the panels.
Only a zaphod/multihead setup would support different densities, but you'd then have to run a KDE session on each (what will cause some trouble, mostly around global shortcuts)

Hi all,

since quite a few KDE core developers are also now using high-dpi notebooks, one of the core targets for Plasma Next was to make it fully dpi-independent which means it will work pretty well on high-dpi screens automatically as you can see from the promo screenshots (for the Alpha release) which were actually taken at high-dpi.

And there you can also see the issues we still have with widget-based applications. Many dialogs are quite old and have just been ported to the new Qt versions over the years without re-thinking or re-doing the layouts.
Qt 5 also brings significant improvements with regards to that topic, so overall Plasma Next and KDE Applications 5 will drastically improve the high-dpi issues and once the major plumbing has been done, we can focus on fixing all the little dpi issues that will remain.

Thanks for reminding me about the icon dialog btw.

Hi all,
I have got my M4800 and finally having some working setup with arch kde.
One this that I can't manage to work is connecting external monitor?
Has anyone of You managed to do that?

Thanks,
Josip