Bug 90842 - sna driver ignores DisplaySize setting in xorg.conf
Summary: sna driver ignores DisplaySize setting in xorg.conf
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-04 09:27 UTC by Martin Steigerwald
Modified: 2019-11-27 13:37 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
xorg log with sna enabled where the driver does not seem to use DisplaySize setting (25.18 KB, text/plain)
2015-06-04 09:27 UTC, Martin Steigerwald
no flags Details
xorg log with UXA where driver seems to use DisplaySize setting (61.53 KB, text/plain)
2015-06-04 09:28 UTC, Martin Steigerwald
no flags Details
xorg log with sna with two different displaysize settings for each display (25.18 KB, text/plain)
2015-06-04 10:05 UTC, Martin Steigerwald
no flags Details
.tgz of Xorg.0.logs, xorg.confs, and summarizing .ods spreadsheet (250 total files) (1.36 MB, application/octet-stream)
2016-03-03 09:37 UTC, Felix Miata
no flags Details

Description Martin Steigerwald 2015-06-04 09:27:30 UTC
Created attachment 116282 [details]
xorg log with sna enabled where the driver does not seem to use DisplaySize setting

In order to try whether it helps with

[Bug 90835] New: [4.1-rc6] gpu hang: ecode 6:-1:0x00000000, Kicking stuck semaphore on render ring

I tried removing

AccelMethod "uxa"

setting.

Now despite:

martin@merkaba:~> cat /etc/X11/xorg.conf.d/anzeige.conf 
Section "Device"
        Identifier      "Grafikkern"

        Driver          "intel"

        # Monitore
        Option          "Monitor-LVDS1" "Notebook-Display"

        # Optionen
        #Option         "AccelMethod"   "uxa"
EndSection

Section "Monitor"
        Identifier      "Notebook-Display"

        DisplaySize     340 192
EndSection

which would give me a nice 143x143 dpi setting, I get:

martin@merkaba:~> xdpyinfo | grep dots
  resolution:    96x96 dots per inch

I see:

[     9.526] (II) intel(0): SNA compiled: xserver-xorg-video-intel 2:2.99.917-1 (Vincent Cheng <vcheng@debian.org>)
[     9.535] (II) intel(0): SNA initialized with Sandybridge (gen6, gt2) backend
[…]
[     9.628] (II) intel(0): switch to mode 1920x1080@60.0 on LVDS1 using pipe 0, position (0, 0), rotation normal, reflection none
[     9.633] (II) intel(0): switch to mode 1920x1080@60.0 on DP2 using pipe 1, position (0, 0), rotation normal, reflection none
[     9.638] (II) intel(0): Setting screen physical size to 508 x 285


in Xorg.0.log in that case.

With UXA I get:

[ 13202.437] (**) intel(0): Option "AccelMethod" "uxa"
[ 13202.494] (II) UXA(0): Driver registered support for the following operations:
[ 13202.494] (II)         solid
[ 13202.494] (II)         copy
[ 13202.494] (II)         composite (RENDER acceleration)
[ 13202.494] (II)         put_image
[ 13202.494] (II)         get_image

[ 13202.560] (II) intel(0): Setting screen physical size to 340 x 192


Thing is: I *know* it better. 143x143 dpi is just about right for ThinkPad T520 with 15 inch display, I measured the display size.

I think what may happen here that sna driver somehow takes second display into account. I have:

martin@merkaba:~> xrandr
Screen 0: minimum 8 x 8, current 3840 x 1080, maximum 32767 x 32767
LVDS1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 193mm
   1920x1080     60.00*+  59.93    50.00  
   1680x1050     59.95    59.88  
   1600x1024     60.17  
   1400x1050     59.98  
   1280x1024     60.02  
   1440x900      59.89  
   1280x960      60.00  
   1360x768      59.80    59.96  
   1152x864      60.00  
   1024x768      60.00  
   800x600       60.32    56.25  
   640x480       59.94  
DP1 disconnected (normal left inverted right x axis y axis)
DP2 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 531mm x 299mm
   1920x1080     60.00*+  50.00    50.00    59.94  
   1920x1080i    60.00    50.00    59.94  
   1680x1050     59.95  
   1600x900      59.98  
   1280x1024     75.02    60.02  
   1440x900      59.89  
   1280x720      60.00    50.00    59.94  
   1024x768      75.08    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    60.00    59.94  
   720x400       70.08  
DP3 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
HDMI3 disconnected (normal left inverted right x axis y axis)
VGA1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)


Basically not even exactly that. Intel SNA driver just seems to do guesswork. Xrandr seem to report good sizes.

Okay, so I will remove DisplaySize setting and see whether it helps.
Comment 1 Martin Steigerwald 2015-06-04 09:28:42 UTC
Created attachment 116283 [details]
xorg log with UXA where driver seems to use DisplaySize setting
Comment 2 Martin Steigerwald 2015-06-04 09:47:14 UTC
Okay, so the SNA driver basically ignores XRandR display size measurements as shown with xrandr comment (see previous comment) as well as setting the DPI for each display separately:

martin@merkaba:~> cat /etc/X11/xorg.conf.d/anzeige.conf  
Section "Device"
        Identifier      "Grafikkern"

        Driver          "intel"

        # Monitore
        Option          "Monitor-LVDS1" "Notebook"
        Option          "Monitor-DP2"   "Extern"

        # Optionen
        #Option         "AccelMethod"   "uxa"
EndSection

Section "Monitor"
        Identifier      "Notebook"

        DisplaySize     344 193
EndSection

Section "Monitor"
        Identifier      "Extern"

        DisplaySize     531 299
EndSection

But I found a way to force it to use my higher 143x143 (instead of the 96x96 standard DPI setting that makes me want to use a magnifier glass): KDE Systemsettings, font setting, force DPI, enter value, be done with it.

This seems to work for KDE and GNOME applications. Chromium 43 has high DPI support on its own. With Firefox GUI it works, with webpage display I still use a addon that remembers zoom settings for page. I am using 150% on this bug reporting page for example.

In anyway, I do think the current DPI behavior of Intel SNA driver on ThinkPad T520 with 15 inch Full HD display is crap. Please let it use Xrandr display measurement and/or at least restore respecting manually setting display size.
Comment 3 Martin Steigerwald 2015-06-04 09:48:38 UTC
Some more information about this ThinkPad T520 and the used software versions:

martin@merkaba:~> phoronix-test-suite system-info

Phoronix Test Suite v5.2.1
System Information

Hardware:
Processor: Intel Core i5-2520M @ 2.00GHz (4 Cores), Motherboard: LENOVO 42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB, Disk: 300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel HD 3000 (1300MHz), Audio: Conexant CX20590, Network: Intel 82579LM Gigabit Connection + Intel Centrino Advanced-N 6205

Software:
OS: Debian unstable, Kernel: 4.1.0-rc6-tp520-btrfstrim-pstatetrace+ (x86_64), Desktop: KDE 4.14.2, Display Server: X Server 1.17.1, Display Driver: intel 2.99.917, OpenGL: 3.3 Mesa 10.5.5, Compiler: GCC 4.9.2, File-System: btrfs, Screen Resolution: 3840x1080
Comment 4 Martin Steigerwald 2015-06-04 10:05:49 UTC
Created attachment 116284 [details]
xorg log with sna with two different displaysize settings for each display

So with:

merkaba:~> cat /etc/X11/xorg.conf.d/anzeige.conf 
Section "Device"
        Identifier      "Grafikkern"

        Driver          "intel"

        # Monitore
        Option          "Monitor-LVDS1" "Notebook"
        Option          "Monitor-DP2"   "Extern"

        # Optionen
        #Option         "AccelMethod"   "uxa"
EndSection

Section "Monitor"
        Identifier      "Notebook"

        DisplaySize     344 193
EndSection

Section "Monitor"
        Identifier      "Extern"

        DisplaySize     531 299
EndSection

I still get:

[  1594.522] (II) intel(0): switch to mode 1920x1080@60.0 on LVDS1 using pipe 0, position (0, 0), rotation normal, reflection none
[  1594.531] (II) intel(0): switch to mode 1920x1080@60.0 on DP2 using pipe 1, position (0, 0), rotation normal, reflection none
[  1594.540] (II) intel(0): Setting screen physical size to 508 x 285

So it doesn´t use any of the given display sizes and it appears to use *one* screensize for both displays. Is this an Xorg limitation? xdpyinfo also only reports one dots per inch value. But even with the physical screen size it uses, dpi are still set to 96x96, which according to the resolution of the display just does not match reality.
Comment 5 Chris Wilson 2015-06-04 10:18:27 UTC
Individual output sizes are reported via RandR. Screen in X parlance refers to a single surface that may be split across multiple monitors.

The message you are quoting is from:

xf86RandR12CreateScreenResources():
        /*
         * Compute physical size of screen
         */
        if (monitorResolution) {
            mmWidth = width * 25.4 / monitorResolution;
            mmHeight = height * 25.4 / monitorResolution;
        }
        else {
            xf86OutputPtr output = xf86CompatOutput(pScrn);
            
            if (output &&
                output->conf_monitor &&
                (output->conf_monitor->mon_width > 0 && 
                 output->conf_monitor->mon_height > 0)) {
                /*
                 * Prefer user configured DisplaySize
                 */
                mmWidth = output->conf_monitor->mon_width;
                mmHeight = output->conf_monitor->mon_height;
            }
            else {
                /*
                 * Otherwise, just set the screen to DEFAULT_DPI
                 */
                mmWidth = width * 25.4 / DEFAULT_DPI;
                mmHeight = height * 25.4 / DEFAULT_DPI;
            }
        }
        xf86DrvMsg(pScrn->scrnIndex, X_INFO,
                   "Setting screen physical size to %d x %d\n",
                   mmWidth, mmHeight);

so yes, you can indeed only set it once and only if you guess what X chooses to use for the backwards compatible output. And screen dpi is just a fake number, and there is a very long and heated bug about that.

When output->conf_monitor is set we get

    if (output->conf_monitor) {
        xf86DrvMsg(output->scrn->scrnIndex, X_INFO,
                   "Output %s using monitor section %s\n",
                   output->name, output->conf_monitor->mon_identifier);
        xf86ProcessOptions(output->scrn->scrnIndex,
                           output->conf_monitor->mon_option_lst,
                           output->options);
    }
    else
        xf86DrvMsg(output->scrn->scrnIndex, X_INFO,
                   "Output %s has no monitor section\n", output->name);

i.e. [     9.527] (II) intel(0): Output LVDS1 using monitor section Notebook-Display

Since xf86CompatOutput() should never return NULL, the implication has to be that it is using a different CompatOutput. We set things up such that it should always choose the panel as the CompatOutput....
Comment 6 Martin Steigerwald 2015-06-04 11:08:26 UTC
Chris, okay, so its partly an X11 limitation, yet meanwhile I am setting DisplaySizes for both displays:

martin@merkaba:~> egrep -i "using (monitor|initial)" /var/log/Xorg.0.log
[     9.503] (II) intel(0): Output LVDS1 using monitor section Notebook
[     9.503] (II) intel(0): Output DP2 using monitor section Extern
[     9.504] (--) intel(0): Output LVDS1 using initial mode 1920x1080 on pipe 0
[     9.504] (--) intel(0): Output DP2 using initial mode 1920x1080 on pipe 1

And it even appears to use some display size:

martin@merkaba:~> grep -i "physical" /var/log/Xorg.0.log 
[     9.689] (II) intel(0): Setting screen physical size to 508 x 285

which is neither

martin@merkaba:~> grep DisplaySize /etc/X11/xorg.conf.d/anzeige.conf 
        DisplaySize     344 193
        DisplaySize     531 299


And also it calculates standard DPI value of 96:

martin@merkaba:~> xdpyinfo | grep -i dots   
  resolution:    96x96 dots per inch

But well if it uses the 24 inch display as compat device, it may even make some sense. The fonts still looked really small on it. But 1920x1080 on 24 inch is certainly a much lower DPI than 1920x1080 on 15 inch.

Well, if its something that cannot be solved differently with X.org, I think I will wait for Wayland and KDE Frameworks / Plasma 5 to deal with that, and use the KDE setting for now. It works well enough.

So feel free to close the bug report.
Comment 7 Felix Miata 2016-03-03 09:37:21 UTC
Created attachment 122094 [details]
.tgz of Xorg.0.logs, xorg.confs, and summarizing .ods spreadsheet (250 total files)

I spent an obscene portion of the past two weeks tripping over what resembles this bug in trying to get a handle on how window management has regressed in responding to global Xorg configuration.

The attachment includes files accumulated to that other end, but that also support an inescapable conclusion that Xorg using the Intel driver exhibits regressive behavior not evident using ati/radeon or nouveau drivers, to wit: disregarding DisplaySize. In my tests I found no evidence sna or uxa affected whether DisplaySize was respected or not, and indeed, logic says it should not, as xrandr proved 100% reliable when used instead of xorg.conf to achieve identical global Xorg configuration. Note that the summarizing spreadsheet in the attachment is sorted with all failures at the top. 

Disregard occurred using one machine with "4 Series" (iG41) gfx and another with "Xeon E3-1200 v3/4th Gen Core" (Haswell Pentium dual core), both using VGA cable for one display and DVI cable for other display. Another "4 series" machine using VGA cable for one and DisplayPort cable for other matched the behavior of all amd/ati/radeon- and nouveau-driver'd machines in reliably respecting DisplaySize. I observed no disregard of DisplaySize using any gfxchip or FOSS video driver while using openSUSE 13.1's 1.14.3 server. Observed failures occurred using Fedora 23 and 24 as well as openSUSE Tumbleweed. Only three machines were used for my testing, but PCIe AMD/ATI and GeForce gfxcards were temporarily installed in the two without HDMI or DisplayPort connectors to rule out OS installation differences having any impact on results.

In Fedora, using only the older machine, failures occured on both VGA connection and DVI connection (HDMI according to Xorg). On Haswell, Tumbleweed failures were observed only for the VGA connection, while on the older machine in Tumbleweed, failures were observed only for the DVI connection (HDMI according to Xorg).
Comment 8 Andrey 2016-07-15 14:07:53 UTC
I have Nvidia video card and I'm using nouveau driver for it.
And the same, I can't set DisplaySize for my 1920x1080 monitor. It is 381x214mm physical (mesured myself) size and, so, dpi must be 128, but is sets 96 (and wrong phisical size). However, xrandr returns more correct values instead of xdpyinfo:

# xdpyinfo | grep -e dimensions -e resolution
  dimensions:    1920x1080 pixels (508x285 millimeters)
  resolution:    96x96 dots per inch

# xrandr --verbose | grep " connected"
LVDS-1 connected primary 1920x1080+0+0 (0x65) normal (normal left inverted right x axis y axis) 380mm x 220mm

If I set correct size at /etc/X11/xorg.conf.d/50-screen.conf it returns me:

(WW) NOUVEAU(0): Option "DisplaySize" is not used

So, what do you suggest? I want 128 dpi at Xorg startup.
Comment 9 Andrey 2016-07-16 16:53:22 UTC
Felix Miata, Thanks!
I have changed monitor identifier.
Your suggest "monitor-LVDS-1", but it doesn't work. However, "LVDS-1" is working.

/etc/X11/xorg.conf.d/50-monitor.conf

Section "Monitor"
    Identifier     "LVDS-1"
    DisplaySize   381   214
EndSection

_ _ _ _
My issue is solved.
Comment 10 Martin Peres 2019-11-27 13:37:40 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/53.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.