I suspect there is a requirement for a simple setting that sets the desktop DPI to the native DPI of the display (primary display?). The consequence would be that one desktop pixel is equal to one physical pixel for all applications no matter how or when they were written or whether they are running in Wayland or XWayland. There are several use-cases where this brings distinct advantages: 1) When using the desktop for photography there would be an easy way to ensure that photos are rendered and viewed at 100% are viewed as they were captured by the camera. Currently the myriad of browsers, photo-editors, photo-viewers, and graphical tools vary in their awareness of scaling. Many are not scaling aware, and those that are vary in what they do about it. 2) When working with printed documents, there would be an easy way to preview the document at actual print size. This applies not only to photography, but to any situation where it would be desirable to proof a document at its real size. 3) When working with architectural, engineering, clothing-design, or other documents with measurable lengths, there would be a way to take rough measurements directly from the screen. When dealing with the above use cases, it could be argued that the user could determine their physical DPI and convert back to achieve a scale based on dividing by 96 DPI, but I would question why achieving a view at native DPI should be so difficult. It would be easier to tick a "native-DPI box", or to be able to specify a DPI directly. Such a setting may affect the way the desktop looks. Given the requirements presented in the above use cases, I think the the value of seeing documents at the right size may outweigh seeing the desktop elements correctly proportioned. There is already the relatively unknown QT_FONT_DPI which appears to work well with desktops scaled to 1.0. I've found using that with KDE6 in Wayland quite effective with no noticeable detrimental effects. Perhaps this could be exposed as a setting.
Some relevant discussions: https://discuss.kde.org/t/return-dpi-resolution-adjustments-in-font-settings-support/11860/12
(In reply to Michael Hamilton from comment #0) > ... > When dealing with the above use cases, it could be argued that the user > could determine their physical DPI and convert back to achieve a scale based > on dividing by 96 DPI, but I would question why achieving a view at native > DPI should be so difficult. It would be easier to tick a "native-DPI box", > or to be able to specify a DPI directly. > ... I experimented with this approach. The scaling leads to different on screen size in different applications, Qwenview shows a image of a plan at one scale, and the browser at another. So this suggestion is not a feasible workaround if consistency across the board is what is required.
> The scaling leads to different on screen size in different applications That's the problem, yes: the DPI setting in Qt is global, not per-screen. The only thing that's per-screen is the current scale system we're trying to encourage everyone to use. As such I'm not sure this is feasible unless we make it clear to the user that it will not work properly if they have a multi-monitor setup where the monitors' DPIs don't match. This would include the common setup of plugging an external screen into a laptop. Ultimately I think this is just one of those awkward issues that we have to expect until apps are properly ported to Wayland.
(In reply to Nate Graham from comment #3) > > The scaling leads to different on screen size in different applications > That's the problem, yes: the DPI setting in Qt is global, not per-screen. > The only thing that's per-screen is the current scale system we're trying to > encourage everyone to use. > > As such I'm not sure this is feasible unless we make it clear to the user > that it will not work properly if they have a multi-monitor setup where the > monitors' DPIs don't match. This would include the common setup of plugging > an external screen into a laptop. > > Ultimately I think this is just one of those awkward issues that we have to > expect until apps are properly ported to Wayland. I think I've already encountered this with X11. The old X11 Fonts->Force font DPI setting is multi-monitor. I'm not sure if my case is typical, but I'll note it here in case it helps to see an actual use case. I set the font-DPI to 162 for my primary 4K unscaled monitor. Photo editing and architectural plans are then consistently scaled (the plans are particularly important as interpreting them wrong could be quite costly). My secondary monitor is then scaled so that the apparent size of windows is the same as the unscaled 4K monitor. I find this very workable, I trust the primary, and use the secondary mainly as a place to park work, read manuals, or edit text. In this instance I would prefer that you trust the user to do something sensible for their unique situation and accept that they are responsible for the consequences of their own actions. I do see that the desktop should be shipped with some training-wheels attached along with a warning about removing them. Providing no attempt is made to defeat the use of QT_FONT_DPI, could it at least be acceptable that it remains a documented solution that can be employed in such cases? Rather than having people wait, or potentially move on to some other alternative, it would provide a "buyer beware" way forward.
Sorry, but if you want to have content be shown at specific (physical or otherwise) sizes, you need to request that feature from apps, otherwise you will never have any guarantees - no matter if system wide scaling is involved or not. > Providing no attempt is made to defeat the use of QT_FONT_DPI, could it at least be acceptable that it remains a documented solution that can be employed in such cases? We can't ensure that workarounds keep working, as it comes at the cost of the intended system working. If it turns out that many people are causing bugs on their PC by having the environment variable set, we might override it in Plasma at some point.
(In reply to Zamundaaa from comment #5) > Sorry, but if you want to have content be shown at specific (physical or > otherwise) sizes, you need to request that feature from apps, otherwise you > will never have any guarantees - no matter if system wide scaling is > involved or not. Thanks for taking the time to think over the request and providing some feedback, much appreciated. A few comments... For photographic images, if I set scaling to 1.0, I cannot see any sensible photo application deciding to overrule that. I think that's a pretty safe. The less guaranteed side is having document viewers that can show documents at actual print-size or with the correct drawing scale. While there may be no guarantees, all document oriented applications have historically "just worked" as long as the desktop DPI can be set to the actual DPI of the viewing device. Up until now this has been pretty easy to achieve. > > > Providing no attempt is made to defeat the use of QT_FONT_DPI, could it at least be acceptable that it remains a documented solution that can be employed in such cases? > We can't ensure that workarounds keep working, as it comes at the cost of > the intended system working. If it turns out that many people are causing > bugs on their PC by having the environment variable set, we might override > it in Plasma at some point. In making this request, I'm raising an issue around supporting a particular user-case and describing how I really use the desktop on a daily basis. Which is not to say you "have to" support this use-case, but to at least raise some awareness that some of us work this way and you might like to take that into consideration going forward in some way or other.
We're still very much in the middle of the Wayland transition. It's expected that apps have to port to be Wayland-native. When they do so, they have an opportunity to use 1:1 scaling for content with a real-world physical size exists and makes sense to replicate on the screen. For any apps that have not done so, the ball is in their court. I would suggest contacting them.