Hi all, On my G45, KMS enabled setup, I get the right resolution before the display manager starts. Then it goes down to 1024x768. I suspect that it is because although there is only one monitor connected to the computer, xrandr reports that another one with max resolution 1024x768 is connected, too. Which is not true. I attach Xorg.log, dmesg and xrandr outputs. I use Archlinux, the motherboard is Asus P5Q-VM Versions of my packages: xf86-video-intel 2.7.1 libdrm 2.4.11 xorg-server 1.6.1.901 xf86-video-intel 2.7.1 kernel 2.6.30.0 intel-dri 7.4.2 Regards, Matej
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.
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.