Comment 96 for bug 589485

Thanks for your observations.

In fact, in my comments there were multiple points.

One of them is different DPI for different screens. As you mention, this cannot be more than a wish for now, as Linux is very badly lagging wrt windows that has been enjoying per-display DPI settings for more than 2 years now, since Windows 8.1 (see https://blogs.windows.com/windowsexperience/2013/07/15/windows-8-1-dpi-scaling-enhancements/). Clearly, for MS developers the idea was that no one uses applications halfway between screens unless they are on very specific arrangements (e.g. screen walls) where all screens have homogeneous properties. But rightly, to lag is not a bug. Still, I hoped that the 'wishlist' nature of my comment #92 was clear and I thought that "wishlist item" != "off topic item". In this respect, I am quite curious of how Ubuntu touch will deal with the matter when the convergence thing is finally in place, since apps will need to be seamlessly movable from a pad screen with >400 dpi to a display with <100 dpi and remain readable.

For the other comment #91, you are once again right on a formal point of view. DPI is just a physical property of the screen. As a matter of fact, from a similarly formal point of view, it is a property that projectors do not have at all, unless you consider the projection distance, since for projectors DPI depends on the latter. Please, s/viewing distance/projecting distance/ in my post if you prefer. Quite evidently, the concept of modelling screen with their physical DPI in graphical environments roots in times when the screen could be only a big box with a CRT placed on a desk at about 50cm from the viewer. Indeed, in the 80s I was perfectly happy with it. Now, with the large variety of devices used for display, the concept is already being stretched a little (at least to accommodate for projectors for which the physical DPI does not exist independently of the projecting setup). In my view, physical DPI is a concept that is mostly critical for screen manufacturers. For a graphical environment designer, the ultimate goal is being able to deliver readable text and images on the screen and what should count is 'perceived dpi' that is more or less the dpi projected on the viewer retina. This is a concept that could be also expressed using DPD (dots per degree) and working in an angular fashion. Again, I totally agree that making the system aware of user perception is nothing more than a wishlist item at the time being.

It is worth mentioning that at the time I commented, the bug status was precisely "wishlist".

For the other points in my post, I cannot not see 1) - 4) in #91 (as well as the 'in the short term' conclusion) can be off-topic, as they pointed out practical problems and suggested an operative (though short term and suboptimal) solution.

Obviously, I agree that this is not a very important bug, since people have happily coped with it for the past 6 years. In the end, coping with it is as easy as using NVIDIA hardware with the proprietary driver or recompiling xorg with the DPI patch that had been floating around since 2010 (in the end, this is one of the reasons why open source exists).