hi,
we are trying to use the display port with the following resolution: 3840X1200 , 30Hz or 60Hz.
Currently it appears that this resolution is not supported:
we used xrandr command with -newmode arg. (we extracted the timing parameters with gtf command).
when we add this resolution with -addmode arg, it fails. maybe it because our screen not support it?
is there any fix to that problem? we still want to use this resolution.
is there any list of supported resolution by our monitor? do we need to update this list manually or maybe use xrandr to do it automatically?
we found in Linux_for_Tegra\source\public\kernel_src\kernel\kernel-4.9\drivers\gpu\drm\drm_edid.c some timing parameters related to specific resolutions but we dont know if we need to change it in order to fix our problem or not.
I thought more in a direction of “quick” guide to beginners with zero previous knowledge.
Again, I’m interested in very specific information (what i asked above), So if there is any thing you recommend to start with i will appreciate it.
I can list some points here. But what I am going to tell is just let you know how display works. It may not resolve any problem here.
Back to your original question. You want to add a mode to support 3840x1200 @30/60 hz. Then here comes the question… Have you ever wondered why you cannot just buy a FHD monitor, which only supports 1080p and ask this monitor to render out a 3840x1200 mode? or even more, why you cannot use a FHD monitor to scan out 8k resolution?
Smart as you may know that it is because the monitor physically cannot support it.
Then how does source device like tegra or your host dGPU knows what mode the monitor can support? There is a eeprom device on your monitor. When HDMI or DP cable is connected to the monitor, the source device (tegra) will read the “edid” from your monitor eeprom. EDID would tell source device what mode is supported here.
Then back to tegra specific setting. As I said previously, our driver does not allow user to add mode arbitrarily. We only accepts what the hardware/edid tells us. It may also cause problem if we directly feed a mode that monitor physically not supports.
Some users also hack a fake edid to our driver because we have some debug functions there which can pick hardcoded edid instead of that one from sink edid. However, it causes problems like unstable signal as my point (3). Thus, I don’t suggest to use that either.
