Hi everyone, I have the following bug on my setup : toshiba L40 with intel chipset and graphics intel 945GM samsung syncMaster 225BW (22' monitor with wsxga 1680x1050 rez) debian lenny updated, i386 - kernel 2.6.23-12, vanilla - xorg 1.3.0, 19th april 2007, debian package - xrandr 1.2 The laptop is packed with a custom vista installation, the intel driver on this platform works for my setup, with samsung .inf file for the monitor. note : using vista only for testing, else I never ever boot it, too slow and crappy ;). Description of the problem : xrandr detects screen correctly when plugged as --output VGA, with standard modes (VESA) well detected. But the maximum resolution I can reach is 1280x1024. using the xrandr-detected modeline --mode 1680x1024 gives random output on the external screen. It seems there is a synchronisation problem with this precise resolution. on win, the screen is detected with good modeline in its native resolution. So I tought it was a modeline problem with EDID bad detection. And also, the 1680x1050 rez is not VESA on this screen (samsung doc). So I got modeline from powerstrip, namely Modeline "1680x1050_test" 146.742 1680 1784 1960 2240 1050 1053 1059 1089 -Hsync +Vsync And tried to force it to the screen by adding it to xrandr and as a permanent solution, later to xorg.conf. But even with the good modeline, the screen will keep outputting garbage only in that resolution. The 1280x1024 resolution was not working either with EDID-read settings, but adding a custom modeline, generated with http://xtiming.sourceforge.net/ worked : Modeline "1280x1024_60" 109.62 1280 1336 1472 1720 1024 1024 1026 1062 So I found reports of wrong EDID detection : http://softwarecommunity.intel.com/isn/Community/en-US/forums/30246090/ShowThread.aspx http://softwarecommunity.intel.com/isn/Community/en-US/forums/permalink/30231135/30231179/ShowThread.aspx#30231179 But changing EDID table is not documented as far as I know for the intel graphics linux driver. And that doesn't change the problem, as we'll see : I tried 915resolution to force the 1680x1024 resolution in the bios, without sucess, even with the resolution loaded, still garbage on the VGA output. Strangely, the table there was filled only with 1280x800, and still I can change resolution of my xserver without problem, even with two screens in extended desktop mode (rez independent). I tried to use xvidtune, but it would not be able to select an output to play with, and it would always load settings for LVDS and sometime for the VGA monitor, not useable. So now I am quite desperate because it won't work on my platform, I cannot use windows and I hope the linux driver can reach the windows ones in term of functionality. I tried alot before posting here, so I hope my report is clear. Summing it up : Samsung syncMaster 225BW, 1680x1050 on VGA output -> working on windows (intel driver + monitor .inf) -> garbage output on linux -> with EDID-detected modeline -> with "good" modeline (not EDID-detected) -> does not seem to depend on modeline setting -> even with 915resolution forcing mode in bios I can try anything you tell me, because I've got not idea left :/ Cheers, Joa
Created attachment 13413 [details] xorg startup log
This seems similar to bug#10545 and bug#10814, which has been fixed. Joa, could you check if your driver contains that fix, or try the latest driver (2.2.0 release or git tip)?
I have tried to use the debian sid packages of x.org, version labeled 7.3+9 as version number. Didn't work either. Right now I am trying to build the lastest xorg from tree. I will keep you informed about my progress, build should be finished by tomorrow.
I am running fedora core 8 with almost identical hardware: In my case: Samsung syncMaster 223BW Intel 945GM and I didn't get 1680x1050 to work on VGA output as well using the current 2.1.1 driver from the distribution. Compiled 2.2.0 from git and it works fine now - thanks !
(In reply to comment #3) > I have tried to use the debian sid packages of x.org, version labeled 7.3+9 as > version number. Didn't work either. Right now I am trying to build the lastest > xorg from tree. I will keep you informed about my progress, build should be > finished by tomorrow. > Joa, any update from you?
> Joa, any update from you? > Hello Michael, Yes, I have build the intel driver from git repository with debian sid packages for dependancies and headers. Building the xorg tree didn't work :/ Alas the problem is still there with this newest version of the driver, exactly the same symptoms :/
Would you please try the following modeline by xrandr? (using +hsync +vsync) Modeline "1680x1050_test" 146.25 1680 1784 1960 2240 1050 1053 1059 1089 +hsync +vsync Thanks, Hong
Bugzilla Upgrade Mass Bug Change NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO. - benjsc fd.o Wrangler
joa, any response?(In reply to comment #7) > Would you please try the following modeline by xrandr? (using +hsync +vsync) > > Modeline "1680x1050_test" 146.25 1680 1784 1960 2240 1050 1053 1059 1089 > +hsync +vsync > > Thanks, > Hong > Joa, any response from you?
last ping for bug report to response comment# 7
I am really sorry about the delay. I was not at the same place at this time. Nertheless, I tried your suggestion but it didn't work. Same garbage on the screen, there seems to be a synchronisation problem.
Joa, are you able to test on another montior, maybe different model or brand, that support 1680x1050? Could you please attach the inf file for the 225BW monitor used in windows?
(In reply to comment #12) > Joa, are you able to test on another montior, maybe different model or brand, > that support 1680x1050? > > Could you please attach the inf file for the 225BW monitor used in windows? > Joa, any repsonse? By the way, would you please also attach your xorg.conf file with the modeline Hong suggested added? thanks.
I'm rejecting this bug due to no response from bug reporter. please reopen with response to comment# 12 and 13.
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.