|
Description
Bryce Harrington
2008-07-14 04:09:42 UTC
The behavior described by the user is pretty weird. I don't think the pipea force quirk is the problem though, that would just leave the output on but shouldn't break anything. Moreover, the resolutions for the VGA connected displays seem to be detected properly, so I'm not sure why things aren't working for him. The screen shot looks typical of what you'd expect a cloned configuration to look like where one head was running at a different resolution than the LCD (that's why the desktop is smaller). Maybe you can try setting different modes by hand on the external displays by hand? E.g. $ xrandr --output VGA --mode 800x600 --right-of LVDS or something. Also choosing a lower refresh rate might help. The last comment in the launchpad entry is disturbing too, he says with the latest bits VGA isn't even detected properly, even when a display is plugged in? That sounds bad... The logs actually look pretty normal; what you'd expect for a dual head config. I had to send my laptop for assistance, as soon as it is back I will test more, however I have seen other -945 that behave the same (on sony vaio laptops). (In reply to comment #2) > however I have seen other -945 that behave the same (on sony vaio laptops). > any specific links where we can find details? Vincenzo Ciancia , have you got your machine back? Unfortunately not yet. Also the persons owning the sony vaio laptops I mentioned are on vacation. I hope to have the laptop soon but I will leave on the 9th, if toshiba assistance will repair my laptop later, I will be back to italy at the end of august. Vincenzo Ciancia, What's the model of your sony vaio? I don't have a sony vaio, but a toshiba M400 (tablet). The sony vaio I mentioned are from my colleagues but they are on vacations right now. My laptop has been repaired and they are about to send it back, I hope to have it at latest on monday. I got my machine back. It is still half-broken (thanks, toshiba!) and I have to send it back for further repair. Before doing that, I just downloaded the sources for version 2.3.2 of the driver (from ubuntu intrepid) and tested those on ubuntu hardy but nothing changed. I also tested the whole intrepid but cant manage to log in (X hangs due to keyboard, dont know why). I also tried xrandr --output VGA --mode 800x600, and tried the new ubuntu GUI for xrandr, but nope: the CRT is correctly detected, the resolution is changed, but nothing appears on the screen, as if was physically disconnected. I also tried the same screen with another intel laptop running ubuntu hardy, and everything works fine. (In reply to comment #8) > I also > tried the same screen with another intel laptop running ubuntu hardy, and > everything works fine. > it sounds like maybe a HW problem of your laptop...Hmm.. Do you have another kind of monitor that you can connect to your toshiba to see if it works or not? Under windows my vga out works fine and it also used to work fine with the i810 driver. I have other monitors and I tried an LCD panel. I reported the results in the following ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/137234 (see the comments past 2008-04-14 for some screenshot and xrandr output using both monitors). My laptop is now back to the toshiba service, I fear that I won't get it back until the end of august since they'll have their vacation now. We recently fixed an issue with the pipe a force code; the SAREA for 3D apps wasn't getting updated which might have caused anything outside the initial configuration to not show up. Can you try git master and see if the issue is fixed for you? Fwiw, I have an Aug 12 snapshot deb of -intel built for Intrepid built here; dunno if it's new enough tho: http://people.ubuntu.com/~bryce/Testing/Gem/ At least some of the fixes made it in after that... do you have anything more recent? Not at this time. The user will need to rebuild from the git source then. ping Vincenzo for comments.... My laptop was back from warranty after more than two months. I have tested both the driver currently in ubuntu intrepid (2.4.1) and the git version (2.5.96) - the latter required me to install git libdrm. Using both drivers, I don't get any output from secondary monitor. However, with 2.4.1 (the older version) if I connect the cable before system power on I get both outputs correctly, even tough the primary LCD panel of the laptop is much less bright than ordinary (don't know why). There are other bugs, but this is sufficient to give a talk if one remembers to boot with vga connected. Using the latest git version of the driver, if I connect vga before boot, I only see the secondary monitor and there is no way to view the integrated LCD panel of the laptop. I am going to attach the output from xrandr and the server log in the latter case (xrandr shows that the laptop LCD panel is not detected at all). From what I can see (e.g. screen blinking sometimes) the problems with second display not enabled when the cable is NOT connected at boot time are related to wrong frequencies - maybe there is some number calculation error in the driver itself? Created attachment 19202 [details]
x server log with driver version 2.5
Created attachment 19203 [details]
output from xrandr with 2.5 driver and secondary display attached at boot time
Vincenzo, can you attach the output of the 'intel_reg_dumper' program after you've tried to enable the VGA output? Also, can you try using the xrandr tool to reduce the refresh rate sent out to the VGA display? I attach the output from intel_reg_dumper before plugging the CRT, after plugging it, and after setting both the displays to 1024x768@60hz, hope this helps. In the latter case, the monitor (a 17'' sony multiscan E200) says "out of scan range" or something like that (yes I've the monitor in italian :)). Created attachment 20743 [details]
output from intel_reg_dumper before plugging in the VGA cable
Created attachment 20744 [details]
output from intel_reg_dumper after plugging in the VGA cable
Created attachment 20745 [details]
output from intel_reg_dumper after plugging in the VGA cable and setting the monitor to 1024x768@60hz
read through both bug reports. I still can't figure out what kind of laptop are you using....:( can you tell us the model of the laptop you are testing? and a log with ModeDebug option turns on , please. thanks! (In reply to comment #24) > read through both bug reports. I still can't figure out what kind of laptop are > you using....:( can you tell us the model of the laptop you are testing? > Ignore this. A Toshiba M400.. Vincenzo, we will need a more comprehensive description of your envrionment... Are you using a Port Duplicator? I'm asking because of a very similar bug# 16777 (toshiba M400, as well). in comment# 16, you mentioned using git version, your integrated LVDS can't work at all. that should be a problem , too. From the xrandr, it seems the LVDS is not detected at all... I am not using a port replicator. Will report debug output next week since I am leaving my country again in a couple of hours (yes I travel a lot, that's why I really need a working VGA out). For what I said in comment# 16, keep in mind that I can't power my LVDS on only if I boot the system with the vga out connected, which is also the only way to make the external adaptor work properly. It seems to me that if you boot with the VGA out connected there is some automatic mode programming that takes place independently of what the operating system does next so perhaps we should debug that case separately. Vincenzo, are you able to provide the xorg.log with modedebug turns on? I'm interested with: a) Xorg log of 2.5 driver with VGA cable connected before power on - you said the integrated LCD can't even be detected in this case. b) Xorg log of 2.5 driver without VGA cable connected - integrated LCD works now but VGA doesn't. thanks. Vincenzo, Let's move the conversation here from bug# 16777. you can use 'X --configure' to let X spit out the default configuration it uses and save it as /etc/X11/xorg.conf, then add the Option "ModeDebug" "True" to the Device section. thanks. Created attachment 21054 [details]
Xorg log with modedebug enabled and vga cable connected after boot
The LCD works correctly but the external monitor can't be enabled. I tried in various ways during the session.
Created attachment 21055 [details]
Xorg log with modedebug enabled and vga cable connected *before* boot
I am now using latest git (which seems to be version 2.6 of the drivers). Here, the LCD is working again, but brightness is dimmed and cannot be changed, even though pressing the appropriate keys shows the overlay brightness bar going up or down in gnome. The external monitor is working properly, and I can change all the settings from the gnome configuration tool (which uses xrandr).
Ok sounds like the original bug is fixed here then. The brightness problem could be a kernel issue, can you file a new bug for that with the output of "xrandr --prop" attached and also a listing of your /sys/class/backlight directory (along with the other usual bits)? (In reply to comment #33) > Ok sounds like the original bug is fixed here then. The brightness problem > could be a kernel issue, can you file a new bug for that with the output of > "xrandr --prop" attached and also a listing of your /sys/class/backlight > directory (along with the other usual bits)? > Jesse, only if Vincenzo connect the monitor _before_ power on the machine, it works. If boot without external monitor , there is no way to bring it up using xrandr. That's what comment# 31 mean... It looks like a pipe is always disabled... Correct me if I'm wrong, Vincenzo. thanks. (In reply to comment #34) > (In reply to comment #33) > > Ok sounds like the original bug is fixed here then. The brightness problem > > could be a kernel issue, can you file a new bug for that with the output of > > "xrandr --prop" attached and also a listing of your /sys/class/backlight > > directory (along with the other usual bits)? > > > > Jesse, only if Vincenzo connect the monitor _before_ power on the machine, it > works. If boot without external monitor , there is no way to bring it up using > xrandr. That's what comment# 31 mean... It looks like a pipe is always > disabled... > > Correct me if I'm wrong, Vincenzo. Oh I thought #32 meant everything was working, but on looking at the logs (please just attach the plain logs next time, no need to gzip) it does look like both are the git version of the driver, sorry about that. Looking again at the dumps and at the latest logs, the startup states are as follows: plugged in before boot: ADPA: 0x80008018 (enabled, pipe A, +hsync, +vsync) plugged in after boot: ADPA: 0x40008c18 (disabled, pipe B, +hsync, +vsync) so far, so good. The VGA output in the first case is enabled and in VGA mode (for text mode probably). And in the second case it's disabled in VGA mode, with DPMS indicating that the monitor is off. Now once the server starts and programs things, they go bad: plugged in before boot: ADPA: 0x80000018 (enabled, pipe A, +hsync, +vsync) plugged in after boot: ADPA: 0x80000000 (enabled, pipe A, -hsync, -vsync) the first case looks ok, VGA mode just gets disabled, but otherwise the output looks ok. In the second case though it looks like we get the wrong polarity for the mode for some reason. You're not providing any custom modelines are you? Can you try adding one with xrandr that has positive polarity? Also, can you make sure your machine's ACPI DOS setting (somewhere in /proc/acpi/video) is 2, 3, 6 or 7?
> plugged in after boot: ADPA: 0x80000000 (enabled, pipe A, -hsync, -vsync)
>
Jesse, where did you see this? I can't find it in the log...
That line was from the register dump from booting w/o the monitor was connected but after the 'xrandr' command was used to enable it (which failed). Jesse, It seems the mode is from the Sony monitor itself: (II) intel(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) Vincenzo, have you tried command 'xrandr --auto' after connect the VGA monitor after booting up without it? Just to reply to recent confusion: 1) yes the problem is still there 2) I upload .gz only when bugzilla (or whatever) says the size matters :) 3) Yes I tried xrandr --auto with no difference - well, the gnome desktop gets resized in a wrong way with panels at half of the LCD panel, just like the panels had been moved to match the resolution of the CRT, but the LCD resolution remains unchanged. Regarding 4) trying a custom modeline - I will do that if you tell me how because that's beyond my abilities (is this a bug report or an exam on my linux hacking skills? :) ) Thanks a lot for taking care of this bug Vincenzo hi Vincenzo, based on Comment #35, I also think the problem is from vga polarity. In the below 4 command group, let us try to find the right polarity pairs. Could you test the blow command groups one by one when vag pluged after boot. //command group 1 $xrandr --newmode "1024x768_1" 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync $xrandr --addmode VGA 1024x768_1 $xrandr --output VGA --mode 1024x768_1 //command group 2 $xrandr --newmode "1024x768_2" 65.00 1024 1048 1184 1344 768 771 777 806 -hsync +vsync $xrandr --addmode VGA 1024x768_2 $xrandr --output VGA --mode 1024x768_2 //command group 3 $xrandr --newmode "1024x768_3" 65.00 1024 1048 1184 1344 768 771 777 806 +hsync -vsync $xrandr --addmode VGA 1024x768_3 $xrandr --output VGA --mode 1024x768_3 //command group 4 $xrandr --newmode "1024x768_4" 65.00 1024 1048 1184 1344 768 771 777 806 +hsync +vsync $xrandr --addmode VGA 1024x768_4 $xrandr --output VGA --mode 1024x768_4 Thanks Ma Ling I tried all the modes on a sony trinitron ES200 without any luck. I fear that the timings might be not accepted by the monitor, thus masquerading an eventual solution for the polarity. Ma Ling, are these timings standard for 1024x768? If not, is there a way to dump the default and working timings after booting with VGA plugged in? Notice that I sometimes changed monitor during tests. hi Vincenzo, because you sometimes changed monitor during tests, so Could you help us to unfiy all test reports again? 1) I assume your comment #31 and comment #32 use the same SW and HW environment. Only difference: commnet #31 is pluged with vga after boot, #32 is pluged with vga before boot, right ? 2) if yes: a) under the same environment with comment #31, after starting Xorg ,before connect VGA please paste dump_register file and output from "$xrandr --verbose". after connect VGA and runing "$xrandr --output VGA --auto", paste dump_register file and output from "$xrandr --verbose" b)under the same environment with comment #32(because vga is pluged before boot, vga work fine ),after starting Xorg, paste dump_register file and output from "$xrandr --verbose" Thanks Ma Ling ping Vincenzo ? ping for response...vincenzo Very sorry for the delay. I am extremely busy at work these days - for the same reason, please forgive me for attaching a single file instead of separate files. I attach all the information required; even tough they are under the same environment of comment #31 and comment #32, I also re-attach the various xorg logs. Very sorry for the delay. I am extremely busy at work these days - for the same reason, please forgive me for attaching a single file instead of separate files. I attach all the information required; even tough they are under the same environment of comment #31 and comment #32, I also re-attach the various xorg logs. Dear all, I clicked by mistake on the last radio button "Reassign bug to default assignee and QA contact, and add Default CC of selected component" before submitting my previous comment, then I hit stop and resubmitted with the radio button in the correct position. I had the chance to overwrite previous changes and did so, but don't know the results, please could you re-check if everything is ok? Sorry for the inconvenience, touchpads make me click in the wrong place sometimes. Created attachment 22130 [details]
Various tests on a sony vaio multiscan E200 monitor.
(In reply to comment #48) > Created an attachment (id=22130) [details] > Various tests on a sony vaio multiscan E200 monitor. > Vincenzo Ciancia, To confirm with you. A1 is after starting Xorg ,before connect VGA A2 is after connect VGA and runing "$xrandr --output VGA --auto" B is vga is pluged before boot Neither A1 nor A2 case make your LCD and external VGA work at the same time, while B case, LCD and VGA can both work at the same time. Is the above statement right? If that's true, one interesting thing is, the reg_dump in comment# 23 is identical with B case, while comment# 23 doesn't work while B works... This senario is identical with bug# 16777. It seems vbios did something we are not aware... Michael: I confirm that your summary is correct. However the following statement can be made a bit more precise (just to summarize): "Neither A1 nor A2 case make your LCD and external VGA work at the same time, while B case, LCD and VGA can both work at the same time." In fact, in A1 and A2 cases, my VGA output does not work at all, even with the LCD disabled. In B case, LCD and VGA work at the same time, but the LCD is set at minimum brightness and changing the setting using the hotkeys seems to do whatever it has to do, but does not do anything. (In reply to comment #50) > Michael: I confirm that your summary is correct. However the following > statement can be made a bit more precise (just to summarize): > > "Neither A1 nor A2 case make your LCD and external VGA work at the same time, > while B case, LCD and VGA can both work at the same time." > > In fact, in A1 and A2 cases, my VGA output does not work at all, even with the > LCD disabled. In B case, LCD and VGA work at the same time, but the LCD is set > at minimum brightness and changing the setting using the hotkeys seems to do > whatever it has to do, but does not do anything. > Let's not to mention the brighteness or hotekey.. those are not related with this bug... thanks. hi Vincenzo Ciancia,
as we know A2 case is from pluging VGA after boot and run "$xrandr --output VGA --auto"
I find the register-dump difference between case A2 and case B is mode line.
for case A2 is
1024x768 (0x3e) 94.5MHz +HSync +VSync *current +preferred
h: width 1024 start 1072 end 1168 total 1376 skew 0 clock 68.7KHz
v: height 768 start 769 end 772 total 808 clock 85.0Hz
for case B is
1024x768 (0x5c) 65.0MHz -HSync -VSync *current
h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.4KHz
v: height 768 start 771 end 777 total 806 clock 60.0Hz
So under A2 case, could you try to run "$xrandr --output VGA --mode 0x5c"
then run "$xrandr --verbose" to check whether VGA is using the same mode line with that of above case B ? (key *current shows the current mode line )
Thanks
Ma Ling
I hoped but nothing new happened, the monitor is still out of scan range: $ xrandr --output VGA --mode 0x5c $ xrandr --verbose|grep current Screen 0: minimum 320 x 200, current 1024 x 768, maximum 1792 x 1792 1024x768 (0x5c) 65.0MHz -HSync -VSync *current 1024x768 (0x5c) 65.0MHz -HSync -VSync *current (In reply to comment #53) > I hoped but nothing new happened, the monitor is still out of scan range: > $ xrandr --output VGA --mode 0x5c > $ xrandr --verbose|grep current > Screen 0: minimum 320 x 200, current 1024 x 768, maximum 1792 x 1792 > 1024x768 (0x5c) 65.0MHz -HSync -VSync *current > 1024x768 (0x5c) 65.0MHz -HSync -VSync *current hi Vincenzo Ciancia, please paste dump-register in comment #53 case. Thanks Ma Ling (In reply to comment #54) > (In reply to comment #53) > > I hoped but nothing new happened, the monitor is still out of scan range: > > $ xrandr --output VGA --mode 0x5c > > $ xrandr --verbose|grep current > > Screen 0: minimum 320 x 200, current 1024 x 768, maximum 1792 x 1792 > > 1024x768 (0x5c) 65.0MHz -HSync -VSync *current > > 1024x768 (0x5c) 65.0MHz -HSync -VSync *current > > hi Vincenzo Ciancia, > > please paste dump-register in comment #53 case. > > Thanks > Ma Ling > ling, if I understand correctly, it's the reg_dump in comment# 23 you are asking for... Created attachment 22180 [details]
register dump after setting mode to 0x5c
hi Vincenzo, Please use $xrandr --output VGA --off before using $xrandr --output VGA --mode 0x5c under A2 case, after that try "$xrandr --output VGA --mode 0x5c" again. Thanks Ma Ling (In reply to comment #49) > (In reply to comment #48) > > Created an attachment (id=22130) [details] [details] > > Various tests on a sony vaio multiscan E200 monitor. > > > > Vincenzo Ciancia, > > To confirm with you. > > A1 is after starting Xorg ,before connect VGA > A2 is after connect VGA and runing "$xrandr --output VGA --auto" > > B is vga is pluged before boot > > Neither A1 nor A2 case make your LCD and external VGA work at the same time, > while B case, LCD and VGA can both work at the same time. > > Is the above statement right? > > If that's true, one interesting thing is, the reg_dump in comment# 23 is > identical with B case, while comment# 23 doesn't work while B works... This > senario is identical with bug# 16777. It seems vbios did something we are not > aware... > Vincenzo, I went through the bug comments and am not sure if you have tested this case, let's call it A3: boot system up without VGA connected, but boot to console mode, connect VGA monitor, they run startx. Will both your LCD and VGA work? please attach xorg.log with modedubug turns on. thanks! ping for response... Vincenzo As usual, very sorry for my delay, It seems that I am constantly either travelling, or under heavy overwork. Next week I will change the country where I work and live for 9 months (this includes changing monitor) and I am extremely busy for this reason. I will absolutely find some time later today to check what you requested, if something else that requires to use the same monitor comes to your mind let me know, otherwise I will have to redo all the tests with a new monitor in my next office. I did the test you requested: boot in text mode, plug the VGA cable in, run startx. Gnome is started at a lower resolution than ordinary, indicating that the display has been correctly autodetected, and the monitor says "out of scan range". I attach the X server log, and the output from intel_reg_dumper and xrandr. Created attachment 23325 [details]
X server log with modedebug on
Created attachment 23326 [details]
Dump
Created attachment 23327 [details]
output from xrandr
I forgot to reply to comment #57, I tried xrandr --output VGA --off, and then xrandr --output VGA --mode 0x5c, but the effect is exactly the same. I believe I am also seeing this issue, I am only able to use an external monitor when the VGA adapter is plugged in at boot time.
I am running ubuntu jaunty
Module intel: vendor="X.Org Foundation"
compiled for 1.5.99.902, module version = 2.6.1
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 5.0
My laptop is a Toshiba dynabook SS RX1/T7E, which is equivalent to the Portege R500 I believe.
I am able to perform some testing with an external monitor later this week if you are able to tell me what versions of code I should be running and what logs you wish to see.
Any news on this issue? Bryce, we are using high priority bug as blocking release. this bug is specific to the model of laptop, so won't be P1 to us. We are currently out of idea. will look at this after Q2 release. thanks. If having access to the hardware would help to solve this bug and #16777 which appears to be related (very similar problem, same hardware), I'd be willing to mail you my M400 laptop and docking station. I'd wipe the drive before sending it to you, so you could install whatever tools were needed without having to worry about preserving the data. Thanks, Hugh (In reply to comment #69) > If having access to the hardware would help to solve this bug and #16777 which > appears to be related (very similar problem, same hardware), I'd be willing to > mail you my M400 laptop and docking station. I'd wipe the drive before sending > it to you, so you could install whatever tools were needed without having to > worry about preserving the data. > > Thanks, > Hugh > thanks for your offering, Hugh. In fact, we have bought a M400 for this bug.. that's why I said we still remember this bug , but just out of idea for now. Given currently we are at the last minute of Q2 release, we will come back to this bug after the release is done.. sorry about the delay and really appreciated your report. On this M400 laptop I found another interesting scenario.
>The VGA is attached before powering on. After the system is powered on, the system will select the VGA as the primary display device in BIOS phase. Then I use the hotkey of "Fn+F5" to switch the primary display device from VGA to LVDS panel. And after the system is booted, the VGA can't work well, neither.
If it can display on both VGA and LVDS in BIOS phase, the VGA monitor can work well as expected.
Thanks.
On the M400 I also found another test case besides the case in comment #71. It is described in the following: No external monitor is attached when powering on. I press the hotkey of Fn+F5 before loading the kernel. Then after the system is booted, the external monitor can be detected correctly and work well. From the above test cases it seems that the system behaviour can be changed if the hotkey of "Fn + F5" is pressed before loading the linux kernel. Thanks. Yakui Michael, since you guys have the M400, can you find someone to work on this one? Maybe the DDC routing changes based on the BIOS boot setting or something? So, is this bug still active or it was fixed meanwhile? reassign to Nanhai for triage. Marking as NEEDINFO to refresh the current status of this bug. Timeout. Please do reopen if you can still reproduce the issue and help us diagnose the problem, thanks. From reading the last several comments it looks like Intel was going to re-test on their M400 but so far there's no indications anyone has confirmed it fixed, so I think this got closed out too quickly. The downstream bug shows one user still reproducing the bug in precise as of June (dmesg and Xorg.0.log on that bug if interested). Needinfo again, we need someone to actually test this on the latest kernels ... Looks like at least one reporter said this was fixed in the LP bug. |
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.