Summary: | sna driver ignores DisplaySize setting in xorg.conf | ||
---|---|---|---|
Product: | xorg | Reporter: | Martin Steigerwald <Martin> |
Component: | Driver/intel | Assignee: | Chris Wilson <chris> |
Status: | RESOLVED MOVED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
Severity: | normal | ||
Priority: | medium | CC: | mrmazda |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Description
Martin Steigerwald
2015-06-04 09:27:30 UTC
Created attachment 116283 [details]
xorg log with UXA where driver seems to use DisplaySize setting
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. 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 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. 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.... 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. 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).
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. 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. -- 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.