DPI is not recognized by UBUNTU, so fonts, icons and the whole system is too small

Bug #564072 reported by Pkhetan on 2010-04-15
36
This bug affects 7 people
Affects Status Importance Assigned to Milestone
gtk+2.0 (Ubuntu)
Low
Unassigned

Bug Description

Hi,

I'm using a 147x145 DPI screen. The fonts, icons and all the whole system seem too tinny.

If I change the System>Preferences>Appearance>Fonts>Details...>Resolution from 96 to 145, the fonts of the desktop get better, but the icons still too tinny, and the fonts in any other applications is still tinny.

I know that i can change the resolution of the screen to a smaller one (actual is 1920x1200) but i don't want to do that because it downgrade the quality of the display.

in Firefox, i can use Ctrl + to increase the fonts size, but this leads sometime to bigger fonts in small frames so sometimes i can't see all the fonts in a frame, or the frames can interfere with each others, and the enlarged photos are really bad quality.

My question is :

Is there a real way to make all the fonts, icons, photos and the whole system in all the applications to appear in a normal size instead of this tinny size that i get only because i have a 1920x1200 on a 15" screen ?

in termianl :

~:/var/log$ grep DPI Xorg.0.log

(--) NVIDIA(0): DPI set to (147, 145); computed from "UseEdidDpi" X config

~$ xdpyinfo | grep reso

  resolution: 147x145 dots per inch

And this is the right DPI of my screen 1920x1200 pixels (332x210 millimeters), but i don't know why the operating system is not applying these DPI?

My config :
Clevo M860TU with Quadro FX 2700M
UBUNTU 9.10 ( but this problem was also in earlier releases )
Driver : NVIDIA 185 ( but i tried also 173 )

Thanks

Architecture: amd64
DistroRelease: Ubuntu 9.10
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
MachineType: CLEVO CO. M860TU
NonfreeKernelModules: nvidia
Package: nvidia-glx-185 185.18.36-0ubuntu9
PackageArchitecture: amd64
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-20-generic root=UUID=5fc3daab-ecc1-421f-99cb-f1702f135e4b ro quiet splash
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-20.58-generic
RelatedPackageVersions:
 xserver-xorg 1:7.4+3ubuntu10
 libgl1-mesa-glx 7.6.0-1ubuntu4
 libdrm2 2.4.14-1ubuntu1
 xserver-xorg-video-intel 2:2.9.0-1ubuntu2.1
 xserver-xorg-video-ati 1:6.12.99+git20090929.7968e1fb-0ubuntu1
Uname: Linux 2.6.31-20-generic x86_64
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
XsessionErrors:
 (gnome-settings-daemon:2098): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (gnome-settings-daemon:2098): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (nautilus:2197): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed
 (polkit-gnome-authentication-agent-1:2224): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (firefox:2276): GLib-WARNING **: g_set_prgname() called multiple times
dmi.bios.date: 09/18/2009
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: 1.02.17
dmi.board.asset.tag: Tag 12345
dmi.board.name: M860TU
dmi.board.vendor: CLEVO CO.
dmi.board.version: Not Applicable
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 9
dmi.chassis.vendor: No Enclosure
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvr1.02.17:bd09/18/2009:svnCLEVOCO.:pnM860TU:pvrNotApplicable:rvnCLEVOCO.:rnM860TU:rvrNotApplicable:cvnNoEnclosure:ct9:cvrN/A:
dmi.product.name: M860TU
dmi.product.version: Not Applicable
dmi.sys.vendor: CLEVO CO.
fglrx: Not loaded
system:
 distro: Ubuntu
 architecture: x86_64kernel: 2.6.31-20-generic

Pkhetan (pkhetan) wrote : Lspci.txt
Pkhetan (pkhetan) wrote : Lsusb.txt
Pkhetan (pkhetan) wrote : UdevDb.txt
Pkhetan (pkhetan) wrote : Xrandr.txt
tags: added: apport-collected
Rickard Närström (riccetn) wrote :

The DPI setting to may knowledge is only used when rendering text or when calculating font matrices, otherwise its completely ignored.

To fully support DPI dependent rendering as a whole would require changes on pretty much all levels. As an example are image sizes on webpages often specified in pixels, to render the images at any other pixel size would not be compatible with current web standards.

Pkhetan (pkhetan) wrote :

So you tell that it's not the job of the OS to render the webpages for example at the DPI of the screen ?

Under Windows 7, there is something that function partially, it doesn't detect the DPI automatically, but you can choose to big-size the system by 125% or 150%, but even when doing this, it will affect only the IE not the FireFix.

For Ubuntu, why at least we don't have the icons bigger when we change the DPI settings under System>Preferences>Appearance>Fonts>Details>Resolution, and why it's not automatically setted anyway, i mean the system recognize the 147 DPI even with the generic driver but Ubuntu still at 96 unless you modify it manually.

Rickard Närström (riccetn) wrote :

I think you are pointing at a real problem, we don't make use of the full capabilities of high DPI monitors. I think we should and if you understood me different I'm sorry.

What I wanted to do is to point out that doing so may not be as easy at it first appears. Size of on screen objects including images, icons, controls and more has traditionally under a vary long time been specified in pixels. To brake the general contract between components and render at a different pixel size then specified may cause us problems of other nature.

Rickard Närström (riccetn) wrote :

I'm assigning this to gtk+ now, which handles most of the rendering work. I'm sorry if this is wrong.

affects: ubuntu → gtk+2.0 (Ubuntu)
Sebastien Bacher (seb128) wrote :

the issue is not a gtk one no

Changed in gtk+2.0 (Ubuntu):
importance: Undecided → Low

It seems I have the same bug on my laptop with the Natty release.

I'm using a Dell Latitude D830 with an Nvidia Quadro NVS 135M. I installed the proprietary drivers.

I try to change the resolution (in pixel) with nvidia-settings.

With 1920*1200 (native resolution) I have :
xdpyinfo | grep dime && xdpyinfo | grep reso
  dimensions: 1920x1200 pixels (331x210 millimeters)
  resolution: 147x145 dots per inch

with 1680*1050 I have :
xdpyinfo | grep dime && xdpyinfo | grep reso
  dimensions: 1680x1050 pixels (290x183 millimeters)
  resolution: 147x146 dots per inch

In the second case, the quality of the image was worse than with the native resolution : can it be explained by the dpi difference 146 vs 145 ?

I forgot to mention that the native ratio of the screen is 16:10. Can it cause some mistakes when the values are rounded ?

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gtk+2.0 (Ubuntu):
status: New → Confirmed
madbiologist (me-again) wrote :

Thibault - sort of. The main reason that the image quality is worse is that LCD panels just dont look much good at anything other than their native resolution, even on Windows or OS X. The difference in DPI is probably only one of the intermediate factors involved.

The good news is that Unity 7 on Ubuntu 14.04 "Trusty Tahr" will have support for HiDPI displays. Additionally, Ubuntu developers are planning HiDPI support for the Ubuntu Linux boot experience - when dealing with GRUB2's boot-loader menu and the Plymouth boot splash screen. They are also investigating HiDPI support for Linux virtual consoles. Specifically, "Developers at this week's vUDS session will be working on a 2x version of the GRUB2 font for basic HiDPI support by just appearing twice as big, working on GRUB2 support for returning a display's physical dimensions, work out support for a scaling factor within Ubuntu's Plymouth theme, and support for a scaling factor within the console-setup font configuration."

There is also bug #1292218 which is described as "The lockscreen has correct Panel HiDPI support, but the prompt doesn't scale right now."

Some of this additional work might be ready for Ubuntu 14.04 "Trusty Tahr" but it is unlikely that all of the HiDPI improvements will be ready for that release.

Andreas E. (andreas-e) wrote :

Since this bug is labeled as gtk+2.0, I'd be interested to see also work continued on the gtk+2.0 toolkit.

By manually editing gtk+2.0 themes, one can at least double some elements' dimensions and it seems not to break the layout of applications (of course such a theme derivative is then specifically targeted for dpi). So there is definitely something that can be achieved by default, and at a lower level (in the theme engine or even toolkit).

Gtk+2.0 is far from disappearing (with distributions pertinaciously sticking to it, as well as all non-native toolkits like java, qt, vcl, xul basing there themes on it) and users will have to deal with it for years. Because of that, better dpi support —be it only partial— is wishable.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers