Bug 111516 - make 'respect_downstream_limits' configurable
Summary: make 'respect_downstream_limits' configurable
Status: RESOLVED MOVED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: All All
: not set enhancement
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-29 10:49 UTC by Marco Munderloh
Modified: 2019-11-29 19:25 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
The boolean should be configurable as a module option (921 bytes, patch)
2019-08-29 10:49 UTC, Marco Munderloh
no flags Details | Splinter Review

Description Marco Munderloh 2019-08-29 10:49:10 UTC
Created attachment 145203 [details] [review]
The boolean should be configurable as a module option

In our  company, we have a lot of Dell U2713HM in use. We recently switch from nvida to onboard intel graphics for all our computers and now have the problem that these old monitors only support their full resolution (2560x1440) on Dual-Link DVI or DP. On our mainboards, only the HDMI output is available. On HDMI, the monitor only supports 1920x1080.

However, if the port_clock is increased beyond limits, the 2560x1440 mode works perfectly fine with this monitor. I used the monitor for years this way, until it suddenly did not work anymore because the respect_port_limits was included to intel_hdmi.c as a bug fix - which broke it for me.

I understand that the problem is the monitor firwmare, but I am patching my kernel for years now whithout problems (I'm uisng the intel graphics since we bought the monitors) and I always hoped that the fixed boolean will once become a configurable module parameter - which never happend.

So I'm asking if it would be possible to make the fixed boolean a module parameter (like respect_port_clock_limit or so). I'm not good at kernel programming so I don't really know how to do this, but I provided a patch where the boolean needs to be placed.
Comment 1 Jani Nikula 2019-08-30 09:10:50 UTC
Presumably if the display advertizes a mode on DVI that requires dual-link DVI to work, said DVI interface supports dual-link DVI. However, we have no way of knowing if the HDMI to DVI adapter you have actually supports dual-link or not; most don't. In your case, using a HDMI to single-link DVI adapter without limits would lead to a black screen, but with the current restriction it leads to a working albeit reduced resolution display.

The way the limit works is filtering the EDID provided modes. So you just won't see the modes that exceed single-link DVI capabilities. However, if you explicitly add a user mode for 2560x1440 you should be able to use it without adding a new module parameter or patching the kernel.

You can add the mode using xrandr.
Comment 2 Marco Munderloh 2019-08-30 11:48:14 UTC
xrandr --addmode actually works, but it only works on Xorg but not on wayland where the mode setup is left to the kerne.

Also the xrandr solution is kind of semi-nice as every user in our cluster has to put it in it's autostart and the used desktop environment varies. Evenmore: user might swap workstations (we have computer labs for our students with different hardware) so it has to be insured that xrandr is only called on the affected machines. It might be possible to put it into the global xinitrc or so - I have to check what our linux distribution allows (mostly using openSuSE and a little ubuntu).

A simple module parameter would be much more convenient ;)
Comment 3 Martin Peres 2019-11-29 19:25:20 UTC
-- 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/drm/intel/issues/386.


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.