modeset driver is missing some modes that the intel driver (and Mir) has

[Rocko]

My laptop's 4K screen (Dell XPS 15 9550) has these resolutions, according to the intel driver:

   3840x2160 60.00 +
   3200x1800 60.00
   2880x1620 60.00
   2560x1440 60.00*
   2048x1536 60.00
   1920x1440 60.00
   1856x1392 60.01
   1792x1344 60.01
   2048x1152 60.00
   1920x1200 59.95
   1920x1080 60.00 59.93
   1600x1200 60.00
   1680x1050 59.95 59.88
   1600x1024 60.17
   1400x1050 59.98
   1600x900 60.00
   1280x1024 60.02
   1440x900 59.89
   1280x960 60.00
   1368x768 60.00
   1360x768 59.80 59.96
   1152x864 60.00
   1280x720 60.00
   1024x768 60.00
   1024x576 60.00
   960x540 60.00
   800x600 60.32 56.25
   864x486 60.00
   640x480 59.94
   720x405 60.00
   640x360 60.00

But with the modeset driver, it detects these resolutions:

   3840x2160 60.00*+
   2048x1536 60.00
   1920x1440 60.00
   1856x1392 60.01
   1792x1344 60.01
   1920x1200 59.95
   1920x1080 59.93
   1600x1200 60.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.04 60.00
   960x720 60.00
   928x696 60.05
   896x672 60.01
   960x600 60.00
   960x540 59.99
   800x600 60.00 60.32 56.25
   840x525 60.01 59.88
   800x512 60.17
   700x525 59.98
   640x512 60.02
   720x450 59.89
   640x480 60.00 59.94
   680x384 59.80 59.96
   576x432 60.06
   512x384 60.00
   400x300 60.32 56.34
   320x240 60.05

It seems to be picking up some extra super-low resolutions (like 320x240) but not the higher 16:9 resolutions. I normally run it at 2560x1440, because the native resolution is too high with an external monitor attached at 1980x1080, but I can't do this with the modeset driver.

I'm reporting this as per https://tjaalton.wordpress.com/2016/07/23/intel-graphics-gen4-and-newer-now-defaults-to-modesetting-driver-on-x/, although note that there are several inaccuracies in that post - there's a typo in ‘cp /usr/share/doc/xserver-xoeg-video-intel/xorg.conf /etc/X11‘, the file doesn't exist in any case if you correct the typo, and I couldn't use ubuntu-bug to report this against xorg-xserver, because ubuntu-bug said the xorg-xserver package doesn't exist.

ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: xorg-server-source (not installed)
Uname: Linux 4.6.4-040604-generic x86_64
.tmp.unity_support_test.0:

ApportVersion: 2.20.2-0ubuntu1
Architecture: amd64
BootLog:

CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
CurrentDesktop: Unity
Date: Mon Jul 25 11:09:00 2016
DistUpgraded: 2016-07-25 02:38:44,004 DEBUG Running PostInstallScript: './xorg_fix_proprietary.py'
DistroCodename: yakkety
DistroVariant: ubuntu
DkmsStatus:
 bbswitch, 0.8, 4.4.0-28-generic, x86_64: installed
 bbswitch, 0.8, 4.6.4-040604-generic, x86_64: installed
 nvidia-367, 367.35, 4.4.0-28-generic, x86_64: installed
 nvidia-367, 367.35, 4.6.4-040604-generic, x86_64: installed
ExtraDebuggingInterest: Yes
GraphicsCard:
 Intel Corporation HD Graphics 530 [8086:191b] (rev 06) (prog-if 00 [VGA controller])
   Subsystem: Dell HD Graphics 530 [1028:06e4]
InstallationDate: Installed on 2016-07-04 (20 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
JournalErrors:
 Error: command ['journalctl', '-b', '--priority=warning', '--lines=1000'] failed with exit code 1: Hint: You are currently not seeing messages from other users and the system.
       Users in the 'systemd-journal' group can see all messages. Pass -q to
       turn off this notice.
 No journal files were opened due to insufficient permissions.
MachineType: Dell Inc. XPS 15 9550
ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.6.4-040604-generic root=UUID=8de7ebec-48db-48b6-9eb9-fafdee4eb7d6 ro rootflags=subvol=@ quiet splash nogpumanager vt.handoff=7
SourcePackage: xorg-server
UpgradeStatus: Upgraded to yakkety on 2016-07-24 (0 days ago)
dmi.bios.date: 04/07/2016
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 01.02.00
dmi.board.name: 0N7TVV
dmi.board.vendor: Dell Inc.
dmi.board.version: A01
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr01.02.00:bd04/07/2016:svnDellInc.:pnXPS159550:pvr:rvnDellInc.:rn0N7TVV:rvrA01:cvnDellInc.:ct9:cvr:
dmi.product.name: XPS 15 9550
dmi.sys.vendor: Dell Inc.
version.compiz: compiz 1:0.9.13.0+16.10.20160714.2-0ubuntu1
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.69-1
version.libgl1-mesa-dri: libgl1-mesa-dri 12.0.1-3ubuntu2
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 12.0.1-3ubuntu2
version.xserver-xorg-core: xserver-xorg-core 2:1.18.4-1ubuntu3
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.2-1ubuntu1
version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20160706-1ubuntu1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A

[Rocko (rockorequin)]

To clarify my comment about 'ubuntu-bug xorg-server' not working, I had to do 'ubuntu-bug xorg-server-source', although it seems to have actually reported it against xorg-server in the end.

[Daniel van Vugt (vanvugt)]

This bug might need reassigning to the kernel instead.

I'm guessing that (like Mir) the mode-setting driver doesn't invent in-between modes like Xorg drivers do (and like legacy VGA BIOS's do for old CRTs)

Please run this command to see if the kernel is the one failing to report those modes:
   grep . /sys/class/drm/*/modes

[Rocko (rockorequin)]

This is the output for kernel 4.6.4-040604-generic (running back on Ubuntu 16.04, but I guess that shouldn't make any difference if we're just reading the kernel info):

/sys/class/drm/card0-eDP-1/modes:3840x2160

(There's a bunch of other modes but they are all for the various resolutions on the HDMI screen).

So it looks like it's just seeing one mode for the laptop screen, the native resolution. Does that mean it's inventing a bunch of modes anyway - just not the right ones?

[Rocko (rockorequin)]

The output is the same for the 4.7.0 kernel.

[Daniel van Vugt (vanvugt)]

Thanks Rocko (my fellow Perthian?). It seems you're right the modeset driver is just not /inventing/ the fake modes you desire.

[Rocko (rockorequin)]

Another Ubuntu Perthian! Excellent! I checked another laptop and the kernel only listed the native resolution of the screen on that as well, so perhaps the issue is in xserver/modeset after all. But out of curiosity, what role is the kernel supposed to take here? It does list all the modes for my external monitor, just not for the laptop screens.

[Daniel van Vugt (vanvugt)]

In the KMS world (kernel mode setting) the kernel maintains the list of real modes available. Previously (where Xorg drivers would communicate with the hardware directly), the kernel was less involved and the Xorg driver would invent the in-between modes mostly to support CRT monitors which don't have a specific native resolution. And also for legacy support just so that people don't complain that the list of modes has shrunken.

In the "modern" KMS world however we (and the kernel) recognise that LCDs only have one real resolution and one preferred (highest) refresh rate. So you will sometimes see the kernel being brutally honest and reporting one/few modes. This is reasonable because using anything other than the native mode will make the image on an LCD blurry. In an ideal world you would always use the native mode of the LCD panel and just scale things up in software if they're too small. But I know Unity7 still doesn't quite do that as well as we'd like it to...

Another reason is slightly harder to explain; external monitors continue to report they support more modes than internal laptop LCD panels. They just tell us over the wire that they can do more. Which is not a software decision.

[Rocko (rockorequin)]

Thanks for the info.

So it turns out that the problem is that the modesetting driver is pruning these modelines because it thinks their vertical refresh is greater than the max vrefresh.

The function in question is hw/xfree86/drivers/modesetting/drmmode_display.c#add_gtf_modes(), and it is calculating refresh rates between 65 and 85 but thinks that the max vrefresh is 60.599998 because of these lines:

    max_vrefresh = max(max_vrefresh, 60.0);
    max_vrefresh *= (1 + SYNC_TOLERANCE);

However, I can see from the MonPtr variable passed to hw/xfree86/modes/xf86Modes.c#xf86ValidateModesSync() that the driver has figured out a range of 56.25 to 120 for this screen, so my guess is that it shouldn't be restricting the max to 60 plus 1% in add_gtf_modes().

Looking at get_modes(), which calls add_gtf_modes(), it is also extracting a MonPtr variable from the EDID, so perhaps it could pass this pointer to add_gtf_modes() and add_gtf_modes() could use the actual maximum vertical refresh for the monitor instead of locking it to 60.

[N. W. (nw9165-3201)]

Wouldn't it be better to report such things to the upstream developers of xf86-video-modesetting on bugs.freedesktop.org:

https://bugs.freedesktop.org/buglist.cgi?component=Driver%2Fmodesetting&order=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=xorg&query_format=advanced&resolution=---

?

Is Launchpad really the correct place for it?

[Rocko (rockorequin)]

Is that the right place? The modesetting driver is incorporated into xserver now, so the versions it offers to report against are very old.

I reported it anyway (against git) at https://bugs.freedesktop.org/show_bug.cgi?id=97163, in case it helps.

[Rocko (rockorequin)]

Just FYI, I proposed a patch at https://bugs.freedesktop.org/show_bug.cgi?id=97163. I can't test it beyond checking it compiles without warnings because when I built my own xserver xorg-server_1.18.4 and installed it to the default prefix (/usr/local/bin), X crashed. This was without any changes to the source returned by apt-get source command, so it's not due to code changes; I'm not sure if this is because I need to build more modules or whether I need to install to /usr/bin, or something else entirely. Does anyone have any hints?

[Rocko (rockorequin)]

From https://bugs.freedesktop.org/show_bug.cgi?id=97163#c15, I think it's just a matter of some modelines missing from the xf86DefaultModes array in xf86DefModeSet.c, eg I suspect that adding this:

/* 2560x1440 59.96 Hz (CVT 3.69M9) hsync: 89.52 kHz; pclk: 312.25 MHz */
        {MODEPREFIX, 312250, 2560,2752,3024,3488,0, 1440,1443,1448,1493,0, V_NHSYNC | V_PVSYNC, MODESUFFIX},

will give me my missing 2560x1440 mode. My xserver builds but I still haven't figured out how to get it to run, so I can't test it.

[Timo Aaltonen (tjaalton)]

That makes no sense, there is no xf86DefModeSet.c, nor can I find xf86DefaultModes array.

You need to build the server with dpkg-buildpackage, not manually with 'make build'.

[Rocko (rockorequin)]

Ok, thanks for the info re dpkg-buildpackage.

xf86DefModeSet.c is created by hw/xfree86/common/modeline2c.awk. If you run dpkg-buildpackage, you'll find it two places:

$ find -name xf86DefModeSet.c
./build-main/hw/xfree86/common/xf86DefModeSet.c
./build-udeb/hw/xfree86/common/xf86DefModeSet.c

xf86DefModeSet.c is built using the files hw/xfree86/common/vesamodes and hw/xfree86/common/extramodes. extramodes is modified in the build process by debian/patches/001_fedora_extramodes.patch, so editing extramodes directly means the patch and therefore build fails. The packages do build if I add my missing modes to vesamodes and because all the modes are combined into the one xf86DefModeSet.c, I assume it'll work for testing purposes.

dpkg-buildpackage builds a whole bunch of debs:

xserver-common_1.18.4-1ubuntu6_all.deb xserver-xorg-core-udeb_1.18.4-1ubuntu6_amd64.udeb
xserver-xephyr_1.18.4-1ubuntu6_amd64.deb xserver-xorg-dev_1.18.4-1ubuntu6_amd64.deb
xserver-xorg-core_1.18.4-1ubuntu6_amd64.deb xserver-xorg-legacy_1.18.4-1ubuntu6_amd64.deb
xserver-xorg-core-dbg_1.18.4-1ubuntu6_amd64.deb xserver-xorg-xmir_1.18.4-1ubuntu6_all.deb

It looks like installing xserver-common and xserver-xorg-core should be sufficient to test my changes, is that correct or do I need the udeb or any of the other packages?

[Timo Aaltonen (tjaalton)]

Ah, ok. So add a new patch that adds your mode to extramodes? But sounds like you've never heard of quilt either..

core and common are all you need

[Rocko (rockorequin)]

So I can confirm that adding the extra modeline works, eg I now have 2560x1440@60 Hz both appearing in xrandr and working on the laptop monitor using the modeset driver.

(There's a separate bug for the modeset driver whereby if you change the mode, eg from 1920x1080 to 2560x1440, the new screen only uses the top 1920x1080 display space - except, curiously, for the unity launcher and top bar - but once I restarted lightdm, the new resolution works fine.)

No, I hadn't heard of quilt before. I'll check it out.