I was asked to test/reprocude this. I don't have a 4K monitor to test this but I can run modes on my HDMI screen that have vertical refresh of 75.00 so for me it looks like there is no hard-coding to 60 + 1% happening as per bug description.

Does your screen report the 75 Hz mode it supports directly to the kernel? ie does the command "grep . /sys/class/drm/*/modes" show the mode you are trying? The modesetting driver will accept modelines reported directly to the kernel (eg I can run my laptop's 3840x2160 mode, because the laptop screen reports that it supports it).

This bug is only an issue for modes that the modesetting driver tries to guess. For instance, my laptop screen only reports the one mode, but xserver comes up with a whole list of modes it has guessed (see https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1606103 for the complete list). But the modes it guesses are limited to 60 Hz.

You can see why the modes are limited from the code in drmmode_output_add_gtf_modes:

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

    ...

    for (i = m; i; i = i->next) {
        if (xf86ModeVRefresh(i) > max_vrefresh) {
            i->status = MODE_VSYNC;
        } 
        ...
    }

    xf86PruneInvalidModes(output->scrn, &m, FALSE);

(In reply to rockorequin from comment #2)
> Does your screen report the 75 Hz mode it supports directly to the kernel?
> ie does the command "grep . /sys/class/drm/*/modes" show the mode you are
> trying? The modesetting driver will accept modelines reported directly to
> the kernel (eg I can run my laptop's 3840x2160 mode, because the laptop
> screen reports that it supports it).

yes, these modes are listed under /sys/class/drm/*/modes
 
> This bug is only an issue for modes that the modesetting driver tries to
> guess. For instance, my laptop screen only reports the one mode, but xserver
> comes up with a whole list of modes it has guessed (see
> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1606103 for the
> complete list). But the modes it guesses are limited to 60 Hz.

OK, so if I understand correctly .. modesetting driver design supports only modes that are reported by the display and Intel DDX takes the risk and adds even more modes. UXA and SNA seem to have very similar looking loops in them but SNA adds even more modes (having a comment 'And then add all the standard modes to fake the fullscreen experience. If it is incorrect, please fix me.') This has been somewhat optional under config option "DefaultModes"? Will need to dig out more to understand if this has been 'experimental', maybe modesetting could support that option as well (?)

Created attachment 126094 [details] [review]
Guess modelines using monitor's reported max vertical refresh where possible

The attached might fix the issue, but I haven't tested it other than to ensure it compiles without warnings and links.

drmmode_display.c#add_gtf_modes() is passed an xf86OutputPtr output, and if I have understood the code correctly in xf86Crtc.c#xf86ProbeOutputModes(), output->conf_monitor->mon_vrefresh is an array of records for reported modelines, with a range for vertical refresh defined by lo and hi in each record.

So if the monitor info "output->conf_monitor" is not null and there is at least one modeline, the idea is to select the max value of all the 'hi' values from these modelines, and to use this as the actual monitor max vrefresh instead of 60 Hz. It still defaults to 60 + 1% tolerance if there is no info.

Sorry, just saw your comment previous to my last one. I'm not sure what you mean by 'This has been somewhat optional under config option "DefaultModes"', and I haven't looked at the intel driver code, so I can't help much there.

Does my logic make sense in the patch? I didn't want to try it a) in case I've made an error, b) there's something I'm not aware of that makes it dangerous to try higher frequencies, and c) because when I was trying to run my local version of xserver to debug this in the first place it didn't actually load (this was with unmodified code, so was a configuration issue rather than anything I changed in the code). For the last issue, I assume I'd need to either deploy it to /usr/bin instead of /usr/local/bin or build more of xserver locally.

It occurred to me that by "Default Modes" you might mean the modelines that modesetting/intel guesses? The design of modesetting seems to be that it takes the reported modelines without question, and then get_modes/add_gtf_modes tries to guess a bunch of default modelines, and the end result is the reported modelines plus the guessed ones. The issue is that the guessed ones are all restricted to 60 Hz. Maybe this is because the driver was designed some years ago and 60 Hz seemed to be a safe upper limit?

(In reply to rockorequin from comment #6)
> It occurred to me that by "Default Modes" you might mean the modelines that
> modesetting/intel guesses? The design of modesetting seems to be that it
> takes the reported modelines without question, and then
> get_modes/add_gtf_modes tries to guess a bunch of default modelines, and the
> end result is the reported modelines plus the guessed ones. The issue is
> that the guessed ones are all restricted to 60 Hz. Maybe this is because the
> driver was designed some years ago and 60 Hz seemed to be a safe upper limit?

Yes, the "DefaultModes" option (see xorg.conf) makes X to add bunch of extra modes that were not in EDID data from the monitor. AFAICT the logic in modesetting driver is to play safe, there will be additional modes added but not with higher refresh rates than EDID has said to be supported. One cannot assume that display can drive any given resolution with refresh rate from another, however if you want to test I believe you can add additional modes using xrandr tool.

>AFAICT the logic in modesetting driver is to play safe, 
>there will be additional modes added but not with higher 
>refresh rates than EDID has said to be supported.

Do you mean "there will be additional modes added but not higher than 60 Hz" (ie because the modesetting driver is hard-coding the 60 Hz limit - that is what this bug is about). The patch I put in attempts to find the highest refresh rate that the EDID actually says is supported (120 Hz in my case) and uses this instead of 60 Hz.

>if you want to test I believe you can add additional modes using xrandr tool.

It kind of works. I used cvt to generate a modeline for 2560x1440, added it with xrandr --newmode (xrandr --output eDP-1 --newmode "2560x1440_60.00"  312.25  2560 2752 3024 3488  1440 1443 1448 1493 -hsync +vsync), and added it with xrandr --addmode (xrandr --addmode eDP-1 2560x1440_60.00). With only the laptop screen enabled, changing to this resolution works fine. With my external monitor attached (1920x1080), the laptop switches correctly to the new mode and unity's launcher and top bar are fine, but I only get a display of 1920x1080 to work with on the laptop screen (anything that moves outside of this persists and flickers horribly). However, the same thing happens also if I select the native 4K resolution. This, however, would seem to be a separate bug (and possibly not in xserver). It also seems that xrandr thinks it's a 60 Hz mode, when it's not (but then it seems to  think that for all modes, even with the intel driver - again, another bug).

But by test, what I meant was test whether my patch works. I already knew that the monitor supported the 2560x1440 resolution because it works fine with the intel driver.

(In reply to rockorequin from comment #8)
> >AFAICT the logic in modesetting driver is to play safe, 
> >there will be additional modes added but not with higher 
> >refresh rates than EDID has said to be supported.
> 
> Do you mean "there will be additional modes added but not higher than 60 Hz"
> (ie because the modesetting driver is hard-coding the 60 Hz limit - that is
> what this bug is about). The patch I put in attempts to find the highest
> refresh rate that the EDID actually says is supported (120 Hz in my case)
> and uses this instead of 60 Hz.

AFAICT drmmode_output_add_gtf_modes() iterates through all the modes it is given (that originate from kernel) and figures out maximum refresh rate available from those. Then (assuming GTF is supported and we have a panel fitter) it will iterate through a set of 'default modes' where it checks if mode has greater refresh rate than maximum reported by display, if so it will reject it. AFAICT this does not gap refresh rate to 60 Hz limit but it gaps to whatever display has stated as its maximum. I haven't worked on this code before though, so I may be wrong and need to debug some more :)

Did you see the code I posted above from drmmode_output_add_gtf_modes()?

   max_vrefresh = max(max_vrefresh, 60.0);

Before this line, max_vrefresh is set to the highest vertical refresh from the default (guessed) modes. It's pretty clear in that line that max_vrefresh is being capped to 60 Hz. Then a couple of lines later, this code removes any default modes that with refresh rates above this:

for (i = m; i; i = i->next) {
        if (xf86ModeVRefresh(i) > max_vrefresh) {
            i->status = MODE_VSYNC;
        } 
        ...
    }

    xf86PruneInvalidModes(output->scrn, &m, FALSE);

Since max_vrefresh has already been capped to 60 Hz, the function must be limiting the default modes to a max of 60 Hz. Why do you think it is not doing this?

Also, what did you think of the patch I posted?

(In reply to rockorequin from comment #10)
> Did you see the code I posted above from drmmode_output_add_gtf_modes()?
> 
>    max_vrefresh = max(max_vrefresh, 60.0);

this line takes maximum from these 2, which for example with my monitor is 75.0
 
> Before this line, max_vrefresh is set to the highest vertical refresh from
> the default (guessed) modes. It's pretty clear in that line that
> max_vrefresh is being capped to 60 Hz. Then a couple of lines later, this
> code removes any default modes that with refresh rates above this:
> 
> for (i = m; i; i = i->next) {
>         if (xf86ModeVRefresh(i) > max_vrefresh) {
>             i->status = MODE_VSYNC;
>         } 
>         ...
>     }

right, this removes any modes where refresh is bigger than 'max_vrefresh' (75.0 for me)
 
>     xf86PruneInvalidModes(output->scrn, &m, FALSE);
> 
> Since max_vrefresh has already been capped to 60 Hz, the function must be
> limiting the default modes to a max of 60 Hz. Why do you think it is not
> doing this?
> 
> Also, what did you think of the patch I posted?

I'll need to get more familiar with how XF86ConfMonitorPtr has been read for the output. I don't quite understand why it contains different info than the modes inputted to the function. I'll take a look at how mine looks like.

>>    max_vrefresh = max(max_vrefresh, 60.0);
>
>this line takes maximum from these 2, which for example with my monitor is 75.0

Ah, well, that's somewhat embarrassing.

Ok, I think I understand it a bit better now. It turns out that my mode 3840x2160 has a vrefresh of 60 Hz, and this is the only mode that drmmode_output_add_gtf_modes() sees when checking for maximum frequency. Therefore, just like you said, it limits the default modes to 60+1% Hz, even though the screen can (I think) handle 120 Hz. I got this figure of 120 Hz from one of the functions called from xf86ProbeOutputModes(), which appears to be passed something constructed from its output->conf_monitor. Unfortunately, output->conf_monitor is NULL when drmmode_output_add_gtf_modes() is called.

If xf86ProbeOutputModes() does have access to this 120 Hz figure, the modesetting driver must be reading something (from the EDID?) at some point that defines the maximum frequency, just not at the point where drmmode_output_add_gtf_modes() is called.

It's kinda frustrating trying to figure out what's going on when my locally-built xorg-xserver keeps crashing on me, so any suggestions you have as to how I should install it would be welcome...

(In reply to rockorequin from comment #12)
> Ok, I think I understand it a bit better now. It turns out that my mode
> 3840x2160 has a vrefresh of 60 Hz, and this is the only mode that
> drmmode_output_add_gtf_modes() sees when checking for maximum frequency.
> Therefore, just like you said, it limits the default modes to 60+1% Hz,
> even though the screen can (I think) handle 120 Hz.

Although monitor could handle 120Hz, everything needed to get data to the monitor doesn't necessarily handle the bandwidth needed to get it at 4K resolution.  You need also GPU, connector and cable that can handle the output bandwith (AFAIK dual link DVI-D or DP 1.3, eDP 1.3 isn't enough).  Do you have those?


> It's kinda frustrating trying to figure out what's going on when my
> locally-built xorg-xserver keeps crashing on me, so any suggestions you have
> as to how I should install it would be welcome...

Where it's crashing?

For example, when you're using modesetting i.e. your X is using Mesa, you need to build Mesa with "--enable-gles2 --with-egl-platforms=x11,drm" otherwise modesetting initialization fails and X segfaults.

>Although monitor could handle 120Hz, everything needed to get data 
>to the monitor doesn't necessarily handle the bandwidth needed to 
>get it at 4K resolution.  You need also GPU, connector and cable
>that can handle the output bandwith (AFAIK dual link DVI-D or
>DP 1.3, eDP 1.3 isn't enough).  Do you have those?

My guess is yes... it's the laptop screen and the resolutions requiring higher vrefresh rates work fine with the intel driver, so the hardware can certainly handle it. I even got the screen to working correctly at 2560x1440 with the modesetting driver, although there were issues with an external monitor connected (see my comment above re flickering).

>Where it's crashing?
>
>For example, when you're using modesetting i.e. your X is using Mesa, 
>you need to build Mesa with "--enable-gles2 --with-egl-platforms=x11,drm" >otherwise modesetting initialization fails and X segfaults.

I have no idea why it fails; I just get the screen saying X failed to set the screen resolution and the system will be run in lo-res unless I want to configure it manually (neither of which seems to work, anyway). I got the source for xorg-server using "apt-get source xorg-server" in Ubuntu, which, as I understand it, gets the source including any Ubuntu modifications (I assume that means it builds it the same as Ubuntu builds it...?).  Modesetting works with the default Ubuntu xorg-server package, so does that imply the default Ubuntu mesa packages were built with those flags set? Or do you need to set them specifically for xorg-server? grep doesn't find them anywhere in the source folder.

Hmm. It might just be that the driver is missing some default modes. I added this 60 Hz modeline obtained from cvt to the xf86DefaultModes array in xf86DefModeSet.c and 2560x1440 is present as one of the probed modes at the end of the xf86ProbeOutputModes() function:

/* 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},

... although my xserver still crashes, so I couldn't check if it works.

I think the main hires modes present in the intel driver but missing from the modesetting driver are these ones:

# 3200x1800 59.96 Hz (CVT 5.76M9) hsync: 111.82 kHz; pclk: 492.00 MHz
Modeline "3200x1800_60.00"  492.00  3200 3456 3800 4400  1800 1803 1808 1865 -hsync +vsync

# 2880x1620 59.96 Hz (CVT 4.67M9) hsync: 100.67 kHz; pclk: 396.25 MHz
Modeline "2880x1620_60.00"  396.25  2880 3096 3408 3936  1620 1623 1628 1679 -hsync +vsync

# 2560x1440 59.96 Hz (CVT 3.69M9) hsync: 89.52 kHz; pclk: 312.25 MHz
Modeline "2560x1440_60.00"  312.25  2560 2752 3024 3488  1440 1443 1448 1493 -hsync +vsync

# 2048x1152 59.90 Hz (CVT 2.36M9) hsync: 71.58 kHz; pclk: 197.00 MHz
Modeline "2048x1152_60.00"  197.00  2048 2184 2400 2752  1152 1155 1160 1195 -hsync +vsync


Would it make sense to add them to xf86DefaultModes?

(In reply to rockorequin from comment #14)
> I got the
> source for xorg-server using "apt-get source xorg-server" in Ubuntu, which,
> as I understand it, gets the source including any Ubuntu modifications (I
> assume that means it builds it the same as Ubuntu builds it...?). 

Yes.

> Modesetting works with the default Ubuntu xorg-server package, so does that
> imply the default Ubuntu mesa packages were built with those flags set? Or
> do you need to set them specifically for xorg-server? grep doesn't find them
> anywhere in the source folder.

Looking at the Ubuntu 16.04 diffs to Mesa, it does include those options (as Ubuntu ships modesetting driver, it needs them):
http://archive.ubuntu.com/ubuntu/pool/main/m/mesa/mesa_11.2.0-1ubuntu2.diff.gz

By crashing, I assume you mean that the regular X crashes and you get failsafe X version.

Can you attach your X log file?

This shows where the X logs go:
  sudo ls -l /proc/$(pidof Xorg)/fd | grep log

Created attachment 126153 [details]
xorg failsafe log

Yes, the failsafe server runs. Here's the log it produces.

I think only thing that could be tested with this is to remove the gapping to the 'preferred' mode size and resolution (seems to me that xf86ValidateModesSize has already validated sizes anyway against max reported?) and see if this helps you. I can try to craft a patch to do this if you get your xserver builds working ok, or you can try, just remove following check in the loop:

--- 8< ---
        if (preferred &&
            i->HDisplay >= preferred->HDisplay &&
            i->VDisplay >= preferred->VDisplay &&
            xf86ModeVRefresh(i) >= xf86ModeVRefresh(preferred))
            i->status = MODE_VSYNC;
--- 8< ---

If not, then this bug should be probably resolved as NOTABUG. Reasoning for this is that modesetting driver is designed to support modes reported by the kernel and any other modes seems to be out of scope.

Any hints as to how I can get my xserver running? It builds and installs fine, it just doesn't run.

Also, do you object to adding the extra modelines to the xf86DefaultModes array in xf86DefModeSet.c as per comment #15? I think that my original guess about modes being rejected was totally wrong and the issue is simply that these modes are not defined anywhere so they aren't being checked for validity. (I was hoping for hints about how to get my xserver working so I could test this!)

(In reply to rockorequin from comment #19)
> Any hints as to how I can get my xserver running? It builds and installs
> fine, it just doesn't run.

For some reason your server selects 'fbdev' driver, not modesetting and that is 
failing. I don't understand why I don't see something like following in your log:

--- 8< ---
[ 26386.927] (==) Matched intel as autoconfigured driver 0
[ 26386.927] (==) Matched intel as autoconfigured driver 1
[ 26386.927] (==) Matched modesetting as autoconfigured driver 2
[ 26386.927] (==) Matched fbdev as autoconfigured driver 3
[ 26386.927] (==) Matched vesa as autoconfigured driver 4
--- 8< ---

so far what I've seen that's typically there ... how do you compile X, are you giving any options or such? (I don't give any options, only custom installation prefix)
 
> Also, do you object to adding the extra modelines to the xf86DefaultModes
> array in xf86DefModeSet.c as per comment #15? I think that my original guess
> about modes being rejected was totally wrong and the issue is simply that
> these modes are not defined anywhere so they aren't being checked for
> validity. (I was hoping for hints about how to get my xserver working so I
> could test this!)

I don't personally object this. It's just that when I asked about this I was told that "modesetting should not be exposing anything more than provided by the kernel, these were a hack" ... so I don't feel confident such patch would fly, one can always try though :)

Created attachment 126257 [details]
Makefile.am

Re the configuration flags, I'm building with whatever came out of the box from Ubuntu. I did a "apt source xorg-xserver", changed into its directory and ran autogen.sh. This is the Makefile.am that Ubuntu ships, does that show Ubuntu is using the standard configuration options?

> I was told that "modesetting should not be exposing anything more
> than provided by the kernel, these were a hack"

I know what you mean, but as I understand it most laptops only report their native resolutions, so it would be pretty limiting if we didn't have that hack. I hope it doesn't mean that the X management team objects to adding more modelines to the hack?

This is a general problem, do we want to expose standard resolutions?

My opinion is yes, as quite often beamers are in a stupid shape and expose modes they do not support. On the other hand, the intel HW planes support whatever format you send to them, and they will upscale it to the native resolution of the display.

So, the kernel definitely exposes this capability already, even if it is not listed in the EDID.

There are workarounds (we can ask the kernel to report user-provided modes), but I would rather have it sort of ready to begin with.

Ok, so I can confirm that I've got the new modelines working in xserver now. (See also https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1606103). I should have been building the xserver package with dpkg-buildpackage instead of make.

The missing modelines actually need to be added to hw/xfree86/common/extramodes, because the xf86DefModeSet.c is auto-created from this file (and vesamodes in the same directory). Debian already applies a patch (debian/patches/001_fedora_extramodes.patch) to add some extra modelines to this file.

I'll see if we can upstream the debian patches

(In reply to rockorequin from comment #8)

> it with xrandr --addmode (xrandr --addmode eDP-1 2560x1440_60.00). With only
> the laptop screen enabled, changing to this resolution works fine. With my
> external monitor attached (1920x1080), the laptop switches correctly to the
> new mode and unity's launcher and top bar are fine, but I only get a display
> of 1920x1080 to work with on the laptop screen 

Could it be when booting dual monitors with different resolutions, the DRM infrastructure only uses the minimum of both resolutions. Recently got a patch that seems to address that issue:

https://lists.freedesktop.org/archives/intel-gfx/2016-December/114329.html

(In reply to Abdiel Janulgue from comment #25)
> (In reply to rockorequin from comment #8)
> 
> > it with xrandr --addmode (xrandr --addmode eDP-1 2560x1440_60.00). With only
> > the laptop screen enabled, changing to this resolution works fine. With my
> > external monitor attached (1920x1080), the laptop switches correctly to the
> > new mode and unity's launcher and top bar are fine, but I only get a display
> > of 1920x1080 to work with on the laptop screen 
> 
> Could it be when booting dual monitors with different resolutions, the DRM
> infrastructure only uses the minimum of both resolutions. Recently got a
> patch that seems to address that issue:
> 
> https://lists.freedesktop.org/archives/intel-gfx/2016-December/114329.html

No. fbdev is its own deadend for handling text mode VT. X operates independently (in graphics mode).

-- 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/xserver/issues/26.