Quote:
Even correct-looking EDID data doesn't seem to guarantee that there would be correct output. On my HP DVI display the EDID info seemed to be perfectly fine when read from /proc, but the only mode Ubuntu would ever display was 1024x768, in spite of any command line switches. Tried both with HDMI-DVI converter and cable. Android, however, did display 1280x720, so definitely it should be doable.
Autodetection is fine as long as it works, but not when it overrides even the manual settings. Wouldn't it make sense to let the user force whatever mode they see fit for their hw, even if risking getting a blank screen?
Because in the vast majority of cases specifying a mode on the command line gets it shoved through the core of the framebuffer subsystem and it has about as much of a clue about deriving mode timings for HDMI displays as my cats.
We are working on a little fix to allow users to specify their own modes on the command line, but a CVT mode is not guaranteed to display on an HDMI monitor, or even a DVI one. Unless you have one that specifically supports EDID 1.4, which is so rare as to be irrelevant anyway, we can't tell if the mode calculation being done is going to be supported, and if you don't have a monitor that supports EDID 1.4, we can't tell regardless.
With your average flat panel display, guessing that it can support "HxW@R" style modes based on anything but the EDID data reported is going to get you a black screen or a "no signal" prompt.
It's much, much safer to restrict you to supported modes. We're going to do a match against the mode you asked for, so it will still be an EDID reported mode, after the incompatibility cull, and if that doesn't work as in the cases above (i.e. an EDID reported mode doesn't display anything) you are still going to be totally out of luck.
Login
Register
FAQ
Search