When I used MergedFB with a Dell Latitude D610 laptop (ATI Mobility X300), the internal panel stopped working after a reboot. It happened twice with the same model but with different laptops. The two screens (internal LCD + external LCD) work fine untill you reboot, then only the external LCD works. It seems that the internal panel isn't detected anymore. It doesn't work in POST or Windows either.
Can you use Fn-F8 or another keystroke to get LCD display back?
(In reply to comment #1) > Can you use Fn-F8 or another keystroke to get LCD display back? No, nothing works. The Dell diagnostics program indicates that the "LCD connection failed", but the invertor works. The BIOS reports an "unidentified panel" with a resolution of "0x0". When I use MergedFB it seems that the backlight is working, but there is no display. I think this is a reproducable and very serious error, because it happened with two laptops with MergedFB. For obvious reasons, I won't try it with a third laptop.
Could this be related to #3015?
(In reply to comment #3) > Could this be related to #3015? I doubt it, because 1) The D610 doesn't have the BIOS setting as the IBM in #3015 2) The laptop panel isn't working or detected anymore (not even in Windows). The second display is now used as first (and only) display. 3) Dell replaced the panel, not the video card, and everything works now.
*** Bug 2628 has been marked as a duplicate of this bug. ***
The driver should not destroy hardware.
Same happened here on a Latitude D600.
This is a serious one. I had that twice on my Dell Inspiron 8600 (Radeon 9600Pro and 1920x1200 display). BTW: Did anyone try the R300 driver according to this issue?
I reported this bug (Bugzilla#2628) ten months ago and It is very discouraging that no progress has been made. Your screen should not burn under any circumstance. Even a workaround to just use the external LCD without burning the laptop screen would be great.
i have an ACER TM 291, with ati radeon mobility 9700, Xorg: 6.9 yesterday i set a working dual monitor layout with MergedFb, but after rebooting my laptop monitor is dead too. All i can see is a black screen... Luckly i have at least an external monitor working.. Fn+xx dosen't work.. Can i do something to recover? PS what kind of info may you need?
I don't think you can do anything but call Acer support and have your display exchanged. Yes, it sucks big time. At least the manpage should have a big fat warning that this option might really destroy your hardware (with a reference to this bugreport).
I don't think the panel is "burned" or damaged or anything ... There are a couple of things you guys can test... - Some register is left in a state the BIOS doesn't like. Make sure the laptop is totally reset by removing the power supply and the battery and leaving it alone overnight. See if it comes back the next day - If that doesn't help, the only explanation I see at this point is that those laptops use some kind of i2c mecanism (maybe an EDID eeprom) to identify the panel and that eeprom shokes due to the way the server accesses it. I've been told X has some interesting timing issues with EDID, in addition, the radeon driver does some weird stuff with the i2c lines before doing the actual i2c transaction, maybe that's causing the problem... At this point, it's difficult to know what's up, though I can't see how that can be related to mergedfb in anyway (I would expect normal Xinerama mode to do the same) though ... we do i2c on all connectors regardless of the connection... hrm.. If we have a clear repro-case of laptop model causing that, the best we can do at this point is have the laptop vendor and/or ATI help with a solution
With some experience in the laptop hardware fixing field, I can add another idea to test out, however this requires some resources: - Have a replacement panel working again (without burning it again), after which the old panel could be replaced back and see if it still doesn't work. This should check if the panel is "burned" or damaged or anything, as benh suspects it might not be. If the old panel works then again, it obviously was not the panel getting damaged, but something else, which gets fixed by throwing a different unit at it. Other probably less helpful ideas I have: - Try to remove the little BIOS battery in addition to the removal of regular battery and leaving it completely powerless for a night. Watch out for warranty voiding stuff. - During the work on various laptop models, I found many of the manufacturers motherboards we dealt with (not Dell) to have a set of switchers (or jumpers or however you call them) that did various things. Usually one was forcing a BIOS reset if computer was turnt on, and three were selecting the panel type. A selection change on the panel type (SXGA, WXGA, XGA, etc) seemed to reinitialize something on the graphics hardware, so I often actually was able to fix customer display related problems (such as indeed no display) by swapping the setting to something wrong, turning the laptop on (and sometimes seeing a distorted/corrupted display, usually with WXGA instead of XGA or similar), turning it off, setting the switches back to the correct one, and turning it back on getting the display back uncorrupted. This however assumes some knowledge of what one is doing, which I had in the form of reference documents for the particular motherboards switches/jumpers.
Thanks for your reply! i will try something, but not opening my laptop, because the warranty is still valid. thanks anyhow! if you tell me what info you need, i'll create the attachment (what do you mean for clear repro-case?) PS sorry for my bad english.
Hi all, Last week I received my new Dell Latitude D610 Laptop. I was aware of this issue. So, obviously, I decided not to touch MergeFB. The laptop was working just fine. But this morning the internal LCD didn't work, even in POST or windows as the other people here. I think that, in the session just before it burns, I loaded the kernel module agpgart so it might have something to do. I have necer used MergeFB nor Xinerama. I put out the battery a few seconds (I know it's not enough), didn't work. The good nes is that I run the Dell diagnostics cd. I run a complete video test. It said it found no problem with the external LCD.... After a reboot, the internal LCD worked again. No idea why or if it is really related with the problems here.
> I think that, in the session just before it burns, I loaded the kernel module > agpgart so it might have something to do. Ooops, I meant radeonfb module (on a linux box)
Finally acer give me back my laptop. They have changed the mother board and now lcd mointor is working. What information about the hw of laptop do you need? greetings, evaimitico
I am experiencing the same problem too on a Dell Latitude D610 with the radeon driver. The LCD has been replaced for three times now. I have had an external CRT attached for more than a year without a problem, but the problems began when I replaced that with a LCD monitor capable of 1600x1024 instead of 1400x1050 supported by the internal LCD. The CRT monitor was running at 1400x1050 too, so the problem might be caused by the radeon exposing a resolution to the internal LCD that is not supported. Also note that it does work once, but the internal screen is broken after a reboot or restart of the X server. I will attach two xorg.conf files, one with the SGI GDM20E21 CRT that worked and one with the 1600SW LCD (with Multilink adapter) that gives problems. regards, -Martin
Created attachment 6048 [details] xorg.conf for external SGI 1600SW flatpanel -- does not work
Created attachment 6049 [details] xorg.conf for external SGI GDM20E21 -- does work
Today I connected an external Philips 190B5 LCD screen to my z60m and played around with xorg and xrandr with clone and mergedfb at work. The internal screen is 1680x1050 pixels and the Philips LCD is 1280x1024. When I suspended to swap and then resumed the laptop at home the internal LCD display was dead. The external VGA still works but Im not getting any activity at all on the internal LCD. No BIOS output, no output in vesa mode, no output in X.org. Radeontool is unable to light the backlight and changing BIOS settings doesnt produce any results. On top of that I think I've tried almost all variations and settings in xorg for both the radeon and the fglrx driver. From Xorg I can also conclude that the LCD no longers gives any DPMS data at all, except when forced showing up as 640x480 which I guess is some kind of default minimum value. The only thing I've noticed is that it looks like the screen lights up in _some_ xorg modes, but I cant see anything, just a faint light and perhaps som weak horizontal lines. Other than that the screen is totally black, not even a flicker when booting. From reading the reports here I guess its the MergedFB modes that still lights up the display. Anyway, removing the battery and changing display parameters in BIOS doesnt change anything and today i returned the laptop to Lenovo for warranty repairs.
I have a laptop dell latitude D610 with an ATI Mobility X300 card. Fedora Core 6 installed. Since two weeks ago, after reinstaling the X server, I have experienced problems while booting the machine. The LCD is completely black, even during the bios startup. The only way I have found to get my screen back is to boot Windows XP. After rebooting I usually get my screen back, but sometimes it is necessary to boot it twice. It does not always happen, if I reboot the machine a few minutes after powering it off it works normally. The problem appears when the machine has been powered off several hours and it does not happen always. I do not think seriously it is a hardware problem because I do not experience the problem if I only work with windows. I do not know if it is the same problem here. The symtoms are just the same, the machine works ok until you reboot it. But I have never used MergedFB though. Also I am able to recover my display booting with windows one or twice without an external monitor connected. If someone suggest it I will fill a new bug. It also happens with the propietary driver fglrx. I have not tried vesa yet. I have tried several configurations in xorg.conf, with some configurations (dri, gl enabled) the problem happens more times. Now I am eliminating dri, gl and so on to see if I can isolate the exact component (if any) that makes everything fail, but it is slow. No extrange messages neither in dmesg nor in Xorg.0.log
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
(In reply to comment #22) > I have a laptop dell latitude D610 with an ATI Mobility X300 card. I have had the same problem with a Dell Lattitude D600, ATI Mobility X270. I am on my third dead LCD Panel since Oct 2006. It worked fine from Feb 2005 through Oct 2006. I did not start using the mergeFB mode until about Apr 2006 - before that it was either no external monitor or docked with external monitor only. The internal LCD Panel is 1400x1050 with an external 1600x1200 attached to the dock VGA out (dock DVI out won't give the 1600x1200 resolution). In my case, the most recent failure happened while I was operating it undocked without an external monitor attached (but with mergeFB still thinking it was there). It actually failed while I was running the MythTV frontend.
Sounds to me like something is corrupting the firmware on the LCD panel
I've posted a C program I've used to restore similarly 'destroyed' panels as an attachment to related-looking bug #34554. The program reads and writes EDID blocks over the I2C interfaces exported by most video card drivers. It can fix simple errors (bad header, bad checksum) itself, and worse corruption can be remedied by obtaining a copy of the desired EDID block from another monitor or possibly another port on the affected monitor. See my long post at #34554.
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.
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.