Created attachment 30897 [details] Kernel log booting with enabled KMS Radeon DRM module does detect connectors which differ from those physically present and configures display in a way that lets attached monitor display black content (sometimes hesitating if there is signal at all, sometime displaying garbage or eventually a few frames that might be the linux console) Display is connected via DVI, under sysfs the HDMI connector is reported as connected, enabled and has some EDID, the other connectors are reported as disabled. Using 2.6.31.5 kernel with airlied's for-linus of 2009-11-01 applied on top (reverting stable i915 commits to avoid merging conflicts)
Created attachment 30898 [details] lspci -nv output
Created attachment 30899 [details] VBIOS dump
Created attachment 30900 [details] edid reported under HDMI connector for DVI-connected display
Created attachment 30902 [details] [review] use standard gpio map for ddc This patch should fix the driver for your chip, but since your board does not unique subsystem ids, it will break other systems. I need to find some way to uniquely identify your board.
Actually, thinking about it more, it seems a bit strange that the oem would use DDIA for the build in DVI port rather than LVTMA. I suspect the current code may be correct, but the connector types are wrong. Is there any chance you can try a different monitor or mode (e.g., 1024x768)?
(In reply to comment #4) > Created an attachment (id=30902) [details] > use standard gpio map for ddc > > This patch should fix the driver for your chip, but since your board does not > unique subsystem ids, it will break other systems. Will try out this evening when I get home. > I need to find some way to uniquely identify your board. That will be difficult with this BIOS revision... DMI is just "To be filled by O.E.M.". Best option would be BIOS upgrade (a later revision has proper entries under DMI) but when I tried that later version back in July or so it failed S3, rebooting instead of resuming (and ACPI/BIOS state looked broken after that, don't remember the details) (In reply to comment #5) > Actually, thinking about it more, it seems a bit strange that the oem would use > DDIA for the build in DVI port rather than LVTMA. I suspect the current code > may be correct, but the connector types are wrong. Is there any chance you can > try a different monitor or mode (e.g., 1024x768)? I can test a different monitor as well as this one on VGA, but all monitors I have available are same size. For different mode I will have to try kernel cmd-line as fbset version I have at hand refuses to work with KMS (because of -1 for dot clock)
Created attachment 30921 [details] edid reported under HDMI connector for DVI-connected display (Iiyama) This is the edid of the working monitor (Iiyama Prolite E431S) Non-working monitor is AOC display
Ok. it looks like the GPIOs are correct, just the connector types are wrong (HDMI-0 is the built in DVI-0 port) and DVI-0 is probably actually an hdmi port available via an add-in card. We just need some way to uniquely id the board to fix the connector names. As to the monitor, I suspect the non-working one doesn't like something about the clock. I'd suggest playing with the pll_flags set in atombios_crtc_set_pll().
Created attachment 30924 [details] Dump of some of the regs (KMS versus VGA text console on AOC DVI monitor)
Some of the DRM patches between 2.6.32 and 2.6.33-rc1 do fix the issue, I've tried to determine the exact patch. It's probably one of those that touch EDID handling/parsing as it did work for the Iiyama monitor but not for the AOC one.
(In reply to comment #10) > Some of the DRM patches between 2.6.32 and 2.6.33-rc1 do fix the issue, I've > tried to determine the exact patch. I've *not yet* tried to determine the exact patch.
(In reply to comment #10) > Some of the DRM patches between 2.6.32 and 2.6.33-rc1 do fix the issue, I've > tried to determine the exact patch. > It's probably one of those that touch EDID handling/parsing as it did work for > the Iiyama monitor but not for the AOC one. > It's probably the new pll code: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=b27b63750d912e80d61d2120c4a1664062d0f808 If the monitor works now, can we consider this bug closed? I'm not sure how to correct the connector type as your board has no unique identifier, but it should work even if the names are wrong.
(In reply to comment #12) > If the monitor works now, can we consider this bug closed? I would say yes. > I'm not sure how to correct the connector type as your board has no unique > identifier, but it should work even if the names are wrong. The interesting question in this regard, is IF the newer version of the BIOS that failed resume by rebooting (and some more oddities triggered by suspend/resume-attempt - it might have been fixed on kernel side sine then as well) does also have the wrong connector types. At least that version does have proper unique identifiers. Unfortunately I currently don't have enough unfragmented time available to test that out.
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.