Ticket #35 (closed defect: fixed)

Opened 20 months ago

Last modified 19 months ago

X forced to 90dpi

Reported by: vcaron Owned by: ppronchery
Priority: normal Milestone:
Component: applications Version: rev2
Severity: minor Keywords:
Cc:

Description

On h1rev2, X is run with the -dpi 90 argument. The FreeRunner? resolution is something between 280 and 285dpi.

X apps mostly ignore the xserver dpi setting and just pick pixel-based values (including gnome). But those that use it like to be told the truth (printing, sketching, barcodes, etc). IMHO it's better to pick a meaningful value at leat for the FreeRunner? that any other generic value like 75, 90 or 120.

Change History

  Changed 20 months ago by ppronchery

As far as I know GNOME doesn't pick pixel-based values, but has a separate DPI meter (with a default of 96).

On a related note, I am regularly emulating the Freerunner screen on my i386 box with Xephyr

$ Xephyr :1 -ac -br -dpi 150 -screen 640x480

and as you can see I found "150" to be a nice trade-off. Running it at 285dpi makes the fonts really too big at a reasonable point size default of 8.

In hackable:1 rev2 this setting is in /etc/init.d/xserver-hackable1 iirc. In hackable:1 daily images it is in /home/hackable1/.xserverrc instead (when using nodm).

follow-up: ↓ 3   Changed 20 months ago by vcaron

That's backwards reasoning ! You don't pick a screen resolution value on aesthetical considerations.

The screen's pixel size is a factual information which can be reported automatically by some display drivers (my old Dell laptop does it via a special VGA BIOS table). Flat panels vendors can even give very stable and precise figures (which could not be done on CRTs).

And that makes X's DisplayWidthMM macro lie. Then every software will consider that X can't be trusted and will implement its own way of handling the screen physical resolution (sort of already happened). That reminds me of a proprietary world when you cannot fix things right, but here we certainly can. I'd be surprised it's more than a few lines fix in GTK+ and/or Gnome at most.

I've run H1 with X set to 285dpi and noticed that only the "Registerin..." text on top changed, that is... honoured it! Everything else is "broken", unless the H1 GTK+ theme explicitly set font sizes in pixels. Which is then more or less a famous webdesign issue and another topic...

Seriously, I guess hackable devices will vary wildly in screen sizes and resolution, it should be very interesting to have those metrics right from the start. Accessibility people will love you for this. Future hackable designers certainly will. I'm willing to help, of course.

in reply to: ↑ 2   Changed 20 months ago by ppronchery

Replying to vcaron:

That's backwards reasoning ! You don't pick a screen resolution value on aesthetical
considerations.

Absolutely correct! But sadly, on my Freerunner I have bugs like:

$ DISPLAY=:0.0 xdpyinfo
[...]
screen #0:
  dimensions:    640x480 pixels (43x58 millimeters)
  resolution:    378x210 dots per inch

and even on my LCD and laptop screens, I have regularly either wrong information, or a multi-head setup that totally breaks the notion of DPI (different screens). Let's not even talk about beamers here (which usually have an LCD inside).

There's still a lot of work to be done :(

I've run H1 with X set to 285dpi and noticed that only the "Registerin..." text on top
changed, that is... honoured it! Everything else is "broken", unless the H1 GTK+ theme
explicitly set font sizes in pixels. Which is then more or less a famous webdesign issue
and another topic...

I just made the test: the "Registering" text was correct for me, until the settings-manager kicked in and changed the fonts everywhere at once...

Seriously, I guess hackable devices will vary wildly in screen sizes and resolution, it
should be very interesting to have those metrics right from the start. Accessibility
people will love you for this. Future hackable designers certainly will. I'm willing to
help, of course.

The build system already supports different configuration for different devices. The current settings let X pick the DPI value itself in all cases.

in reply to: ↑ description   Changed 20 months ago by ppronchery

Replying to vcaron:


X apps mostly ignore the xserver dpi setting and just pick pixel-based values

This article contains highly interesting information: http://scanline.ca/dpi/

However, while his proposal was maybe valid at the time of writing (2004), I think we should really try our best at supporting dynamic DPI settings. The Xresources setting he mentions is very useful to test different values without running gnome-settings-manager.

For example, on the Freerunner, place this in your ~/.Xresources file:

Xft*dpi: 285

You can force it with this command:

$ DISPLAY=:0.0 xrdb ~/.Xresources

(you have to launch your application again, I don't know how to make it refresh automatically although gnome-settings-manager manages to do it)

  Changed 19 months ago by ppronchery

  • owner changed from jblondon to ppronchery
  • status changed from new to accepted

I'm getting knowledgeable about this.

  Changed 19 months ago by ppronchery

  • version set to rev2

This is fixed in trunk as of [357], but not found in any release yet.

  Changed 19 months ago by ppronchery

  • status changed from accepted to closed
  • resolution set to fixed

rev3 ships with 280 dpi.

Note: See TracTickets for help on using tickets.