desktop-packages team mailing list archive

[Sergio Callegari <sergio.callegari@xxxxxxxxx>]

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).

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xorg-server in Ubuntu.
https://bugs.launchpad.net/bugs/589485

Title:
  Ignores physical display size and calculates based on 96DPI

Status in X.Org X server:
  Confirmed
Status in xorg-server package in Ubuntu:
  Confirmed

Bug description:
  The X server, starting with 1.7, ignores the physical size reported by
  the EDID or in xorg.conf and calculates it based on screen resolution
  and a DPI of 96.

  This is rather annoying for users of high DPI screens.

  GNOME and KDE (used?) to set 96 DPI by default in their settings.  We
  should check whether they still do, and if so let them handle this; I
  don't think X should be handling this.

To manage notifications about this bug go to:
https://bugs.launchpad.net/xorg-server/+bug/589485/+subscriptions