Bug 22454

Created attachment 27084 [details]
output of dmesg

Created attachment 27085 [details]
Xorg.0.log

Created attachment 27086 [details]
output of xrandr

the DVI2 output status should be "disconnected"

Seems similar to bug#20619. But that was said to be fixed before 2.6.30.

Matej, before this bug fixed, you can add a Monitor section for the non-existed DVI2 and explicitly "Ignore" it, as a workaround.

Could you please describe what's your configuration environment such as monitor type, and how connect with machine, i.e. dvi-i or dvi-d ? then  please upload xorg.log file with modedebug option in UMS.

Thanks for your help.
Ma Ling

Created attachment 27122 [details]
UMS debug Xorg.0.log

I have the HP LP2065 LCD panel.
And I use DVI-D cable.
I attach the debug UMS Xorg.0.log

Created attachment 27129 [details]
pleaset try the patch on your machine, thanks.

UMS log shows it works fine, so please use the debug patch then upload dmesg.

Thanks for your help
Ma Ling

(In reply to comment #7)
> Created an attachment (id=27129) [details]
> pleaset try the patch on your machine, thanks.
> UMS log shows it works fine, so please use the debug patch then upload dmesg.
> Thanks for your help
> Ma Ling

ping ~

Don't worry, Ling - I have been away from that computer and moreover I had to check out how to compile a kernel :-)
Actually, what is that patch about? Is it a git WIP kernel? I can't patch 2.6.30 sources with it...

we have a P5Q-EM, x-g45b. though not exactly same as the bug reporter's environment,  might worth testing on it...

Looks like the only chance can make this the detection procedure could pass the get_edid check in the detect func, would be it thought the EDID from the VGA monitor is its EDID (because on the G4x system, VGA and HDMI share the DDC port ), but how does it pass the DRM_EDID_INPUT_DIGITAL check?

according to zhenyu, ought to because of patch:

commit e14cbee401cd00779a5267128371506b22c77bc9
Author: Michel Dänzer <michel@daenzer.net>
Date:   Tue Jun 23 12:36:32 2009 +0200

drm: Fix shifts which were miscalculated when converting from bitfields.

Looks like I managed to mess up most shifts when converting from bitfields. :(

The patch below works on my Thinkpad T500 (as well as on my PowerBook,
where the previous change worked as well, maybe out of luck...). I'd
appreciate more testing and eyes looking over it though.

Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Tested-by: Michael Pyne <mpyne@kde.org>
Signed-off-by: Dave Airlie <airlied@linux.ie>

(In reply to comment #11)
> according to zhenyu, ought to because of patch:
> 
> commit e14cbee401cd00779a5267128371506b22c77bc9
> Author: Michel Dänzer <michel@daenzer.net>
> Date:   Tue Jun 23 12:36:32 2009 +0200
> 
> drm: Fix shifts which were miscalculated when converting from bitfields.

This patch fixes a couple of regressions I introduced with the initial DRM EDID endianness fixes. Are you saying there are still regressions with this patch?

(In reply to comment #12)
> (In reply to comment #11)
> > according to zhenyu, ought to because of patch:
> > 
> > commit e14cbee401cd00779a5267128371506b22c77bc9
> > Author: Michel Dänzer <michel@daenzer.net>
> > Date:   Tue Jun 23 12:36:32 2009 +0200
> > 
> > drm: Fix shifts which were miscalculated when converting from bitfields.
> 
> This patch fixes a couple of regressions I introduced with the initial DRM EDID
> endianness fixes. Are you saying there are still regressions with this patch?
> 

no. exactly the regression of EDID endianness which caused this bug were fixed by your patch. :)

commit e14cbee401cd00779a5267128371506b22c77bc9
Author: Michel Dänzer <michel@daenzer.net>
 Date:   Tue Jun 23 12:36:32 2009 +0200
Fixed the issue, close it now.