DPI in intel modesetting driver

Adam Jackson ajackson at redhat.com
Thu Jan 4 17:05:16 UTC 2007


On Thu, 2007-01-04 at 17:25 +0100, Nicolas Mailhot wrote:

> - OLPC has to dynamically adjust GNOME dpi when screen mode switches (but
> the scaling preferences of the user didn't change!)

This doesn't actually happen in current OLPC builds.  Whacking the
grayscale button doesn't change font sizes.

Nor, really, does it need to.  There is a minimum legible font size; and
if it's legible in color mode, it'll be legible in gray mode too.  The
noise about different effective resolutions is true as far as it goes,
but it doesn't impact the user experience in any meaningful way.  Your
UI just needs to occupy more pixels, period.

My experience with the OLPC screen is that the minimum legible text size
in color mode is very close to the minimum legible text size in gray
mode.  You may as well make them the same, and forget about runtime
adjustment, especially since the latency to reflow the whole screen is
just prohibitive.

> The "scaling factor" is the excuse GNOME people have found to avoid fixing
> this. "it's not a real value" => "we don't have to compute it correctly"

But considering it a scaling factor is _correct_.  If it means other
things besides scale factor, then that needs deconflation within Gnome
itself.

I'm aware that probably requires fixing Gnome, but there's certainly no
fixing this within core X.  Mangling DisplaySize in the config file is
not a fix.  That has a well-defined meaning, unlike Gnome DPI.

(New RANDR may allow you to modify the server's perception of display
size at runtime, for the case where you've got a monitor that can
stretch or not but there's no way of determining which from software.
So the need for root privs does go away, but the server still needs to
report _physically_ how big pixels are, so it's not a mechanism for font
scaling.)

- ajax




More information about the fedora-devel-list mailing list