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
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.
** Bug watch added: freedesktop.org Bugzilla #971
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=advanc
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 calcul
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 h
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 e
