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

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.

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

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?

The output is the same for the 4.7.0 kernel.

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

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.

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.

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.

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?

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.

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?

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.

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'.

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?

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

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.