On Thu, Feb 25, 2010 at 07:18:47PM +0100, Stefan Bader wrote: > I recently (triggered by a bug report as well as some personal experience) > tried > to influence the mode that is used when there is no (or invalid) EDID > information available. > > And I have not been very successful on that. There have been suggestions of > trying "video=VGA1:<x>x<y>" and I tried various variations on that. > VGA= is clearly deprecated. GFXPAYLOAD also seems to have no effect. > > Some use cases might be setting a better terminal resolution (without X). In > my > case I used to provide a monitor definition in xorg.conf to define the > capabilities of my monitor (as the KMV-switch does not supply any data), which > are now ignored. There seems to be a hard coded 1024x768 in KMS but nothing > more. > > But I think it would be vital to be able to define a mode as > - there might be (still) monitors not providing that info > - KMV-switches providing no EDID information > - KMV-switches providing a generic (too high) resolution > > So did I miss something?
I have also been wondering about this question. I poked through the kernel drm code a bit looking at the edid retrieval code but did not see any associated code for handling user overrides to this data. While the drivers share the actual edid probing code, it's up to each driver to sort out what to do when the edid isn't present. It looks like they fall back to some permutation of standard VESA modes in this case. The routines drm_mode_getconnector and drm_connector_init seems to be where the configuration is set up. drm_mode_getconnector() calls a *fill_modes(), which is a pointer to the routine drm_helper_probe_single_connector_modes(). This routine handles if the connector is forced on, and if no modes are found it tries to add them via drm_add_modes_noedid(). This routine uses the drm_dmt_modes[] table defined in drm_edid.c, does some basic checking that the default resolution is within the monitors display limits, and adds it to the list of modes. Anyway, this drm_helper_probe_single_connector_modes() routine seems to me to be where a user-override functionality would hook in if it existed, but I don't see any hint of one here. Maybe something should be added? Bryce P.S., drm_edid.c is very interesting to study, as it is where all the quirks live for working around hardware problems. There's a lot of resolution picking errors being reported by users which may be worked around with an appropriately crafted quirk, so understanding the quirks defined in this function would be very valuable. I would suggest looking at my old pre-KMS X quirk documentation at http://wiki.ubuntu.com/X/Quirks and craft something similar for the Linux kernel. There are going to be a LOT of such bugs, and having a cookie-cutter process for users to test for the need for a quirk can save everyone a LOT of time and hassle. -- Ubuntu-x mailing list Ubuntu-x@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
