On a Acer Travelmate 803 with Radeon 9000 a regression in the display detection was introduced with 6.8.0 comared to 6.7.0 (aka XFree86 4.3.99.2). Starting X with no external display connected works fine. When starting X with a analog DDC capable display connected to the external port the external display is detected as the only available display. As such it is assigned to screen 0 and aquires the modes from the configuration file that were ment for the internal display while the internal display remains inactive. The previous versions detected both displays correctly and aquired DDC data for the external as well as the internal display. Comparing the code the new version obtains a list of available connectors from the BIOS while the older version proed every possible connector. I will attach the relevant log files. This BIOS list seems to be buggy on the system in question.
Created attachment 1033 [details] Working log from XFree86 4.3.99.2 This log file shows that all connectors are probed and the DDC data is found for both the external display and the internal panel.
Created attachment 1034 [details] Log from 6.8.0 showing regression This log only shows DDC data for the external display.
Created attachment 1035 [details] 6.8.0 log with only internal display connected This log contains no DDC data. The LVDS as primary display is a fallback.
Can you try with cvs prior to Hui's r400 support patch? I think that's what broke it. I think the display handling code committed was incomplete (it was a partial merge of Hui's original code drop for r400 support and better display handling). Someone probably needs to fully merge the original revamped display handling patch. It's complicated since the patch is substantial and it was against xorg prior to the the DRI merge and now that part of it was merged it's even more complicated. I started to a while back, but lack of time has prevented me from finishing it. The patch in question is here: http://www.botchco.com/alex/radeon/hy0/x440_radeon_4_newchips.diff I may get to it one of these days, but I can't make any promises. if someone beats me to it...
*** Bug 1482 has been marked as a duplicate of this bug. ***
*** Bug 1301 has been marked as a duplicate of this bug. ***
this patch should handle lvds + DVI, so it may help thinkpad owners with DVI ports in addition to their LCD's.
> Can you try with cvs prior to Hui's r400 support patch? That's not so easy because it is not my machine. A customer reported this problem and they are not very good at testing. However I'm positive that this patch is involved because the wrong information appearantly comes from RADEONGetConnectorInfoFromBIOS(). It only talks about one connector therefore the other one doesn't get probed.
It is caused my patch. Basically in the old code, the driver doesn't trust the DDC mapping info collected from BIOS, the DDC detection code made some default assumptions: DDC_DVI for first head and DDC_CRT for second head, both heads will fallback to DDC_CRT2 if not detected on the default line. This scheme works for most of existing cards, but has problem with new cards. Also this scheme causes longer delay in X startup because of redundant DDC detection. With the new code, driver trusts whatever collected from BIOS and just tries DDC pin indicated by BIOS. But this doesn't seem to work correctly always, especially for some laptops. I was hoping there won't be too many of these cases, in which you can overwrite the autodetection with MonitorLayout option. I'll look into this, see if I can find a better solution.
*** Bug 1374 has been marked as a duplicate of this bug. ***
Confirming the problem on a Compaq/HP NX9000 laptop with a Radeon IGP 340M. My second (VGA) monitor no longer gets detected with Xorg 6.8, and my logs look like Egbert's.
BTW, is there any workaround for this bug ? I tried the "NoDDC" option, but it seems not to be taken into account by the driver.
(In reply to comment #12) > BTW, is there any workaround for this bug ? I tried the "NoDDC" option, but it > seems not to be taken into account by the driver. You should be able to use override the detected outputs with the "MonitorLayout" option, however, if DDC doesn't work on one of the heads, you'll have to manually enter the hsync and vrefresh ranges for your monitor in the monitor section. See the radeon man page for the monitorlayout options.
*** Bug 1631 has been marked as a duplicate of this bug. ***
I'm having the same problem here with two radeon cards (one AGP, the other PCI). Below is the two cars I'm using. 0000:00:0f.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] 0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R100 QD [Radeon 7200] I did the suggestion of using MonitorLayout in the config, and after that X would try to start up, then segfault :(. I'm going to try rebooting and seeing if that helps. If you'd like, I can post the Xorg log file. Btw, I'm running 6.8.0. There's a followup bug on gentoo's bug site concerning this: http://bugs.gentoo.org/show_bug.cgi?id=67485 Thanks for any input!
*** Bug 1303 has been marked as a duplicate of this bug. ***
Created attachment 1121 [details] [review] Patch for fixing monitor detection bugs Here is a patch for fixing a few monitor detection bugs. 7200 related problem (Bug # 1301, Bug# 1622 and comment #15 From Lance Albertson) and MonitorLayout problem (Bug# 1374 and Bug# 1482) should be fixed with this patch. There are also some experimental code for fixing DDC detection problem originally reported in this bug report and in Comment #11 From Christophe Jacquet. Since I can't find any of these laptops, the fix is based on the log file posted. Please try this patch see if it makes any difference. If it still doesn't work, please post your log file, Thanks.
(In reply to comment #17) > Created an attachment (id=1121) [edit] > Patch for fixing monitor detection bugs > > Here is a patch for fixing a few monitor detection bugs. 7200 related problem for me it works so far (Bug # 1301) I was able to start xorg without the NoDDC option. Thanks for your patch
This patch fixed the issue I had! I'll have to test on my laptop to see if it fixes the lid problem which I think may be related. Thanks!
The Patch fixed the problem for a Radeon M6 LY in a Toshiba Libretto L5. Dual Head working again perfectly. Cheers..
bug 1666 may also be related. I haven't had a chance to look into it yet.
It's still not working on my computer (a presario 900 with an IGP320M). The only difference is that whithout the MonitorLayout option, now xorgs detects my internal monitor. I get the same results with two devices sections. I have post my xorg.conf (maybe I am doing something wrong in it ?) and Xorg.0.log in attachement.
Created attachment 1128 [details] config file with a IGP320M
Created attachment 1129 [details] a log file for IGP320M with MonitorLayout and not working
With the original version, I couldn't ovverride the detected outputs with "MonitorLayout". However, it works when I apply the patch, but only when using "MonitorLayout". If I don't use this option, I can't use dual head. Also, I had a look at radeon_bios.c, around line 240 (section modified by the patch): if I get it right, it assumes that if only one connector is found, it has index 0, and copies it to index 1. I tried to add a debugging output, and it turns out that my only connector originally found by the driver has index 1 and not 0 ! (when incrementing connector_found at line 230 or so, tmp1 is equal to 1 on my system...) Of course I tried to comment out the memcpy on line 242 or so, but the additionnal entry I get still doesn't hold a valid monitor description so I don't get any further.
Created attachment 1130 [details] [review] improved version for attachment# 1121 [details] [review] Here is an improved version of patch according to the feedback in comment #25 from Christophe Jacquet. As for the problem reported in comment #24 From Cyrille Berger, I don't think the problem is really monitor detection related. There are many IGP320M laptops that we have never be able to make them work with dual-head (I'm still not sure what's wrong with radeon driver for these laptops, I've never had access to one of them). I suspect this is one of them, try XFree86 4.4 (or FC2 or SuSE9.1) and see if it makes any difference. Thanks.
Unfortunately, I already tried xfree 4.4. I am available to provide any help possible to fix the problem with the IGP320m.
Just doing some regression testing with Hui's latest patch from comment #26 on the following cards: Radeon R100 QD Radeon R200 QL [8500 LE] Radeon R300 NE [9500 Pro] Radeon R300 ND [9700 Pro] Radeon RV280 5961 [9200] Radeon RV100 QY [7000 -- Dell dual head] The R100 and RV280 are single headed, and the rest are dual head. All worked fine with Hui's patch. I don't have access to any laptops with Radeons. The only oddity is that the 9200 detected two CRT heads, but there was only one connector detected.
Created attachment 1133 [details] [review] [FIXED_X11R68x] Another improved patch Good catch, Kevin. 9200 oddity is actually another bug. See new patch. To Cyrille Berger, if XFree86 4.4 doesn't work for your 320M, it's the old dual head problem I was talking about. I don't have a solution for this, unless I can access such a laptop some day.
Ok, I've got Hui's patch from comment #29 now added to our xorg-x11-6.8.1-11 as "xorg-x11-6.8.1-ati-radeon-mobility-display-detection-fix2.patch". Doing test build.
I tried the latest patch with two external monitors connected to a notebook equipped with an IGP 34OM: - Belinea/Maxdata monitor: the driver does not get DDC information (maybe this monitor is not DDC-capable ?). So by default, the monitor is not detected, and it displays a clone image of the integrated flat panel's. However I can activate dual head with "MonitorLayout" (all went fine without this extra option with X.org 6.7); - Iiyama AX3815U: the driver manages to get full DDC information. But in this case, the integrated flat panel is blanked and only the external monitor displays an image.
I can confirm the latest patch works on a RV350 (9600 Mobility) in an eMachines amd64 laptop - the MonitorLayout option is required however. Thanks Hui.
Comment on attachment 1133 [details] [review] [FIXED_X11R68x] Another improved patch Approved for checkin into X11R6.8.x in the 2004-11-12 release-wranglers call.
when this is applied to 6.8.2, can someone please update HEAD as well? If not, I'll do it if everyone is ok with that.
committed to HEAD
The last patch works for me (Acer TravelMate 803, Mobility Radeon 9000) and enables dualhead again. Thanks for this! However, it still has some disadvantages compared with the old XFree driver: - I need Option "MonitorLayout" "LVDS,TMDS" in my Xorg.conf - if external monitor is disconnected, the desktop still uses dualhead size which means windows appear in the "off". The old driver detected this and reduced desktop size to existing screens. It would be nice if you could fix this.
(In reply to comment #36) > The last patch works for me (Acer TravelMate 803, Mobility Radeon 9000) and > enables dualhead again. > Thanks for this! > > However, it still has some disadvantages compared with the old XFree driver: > - I need Option "MonitorLayout" "LVDS,TMDS" in my Xorg.conf Does you laptop actually have a DVI port? If not does replacing TMDS with CRT also work? Could you attach your xorg log?
On Dell Inspiron 4150 (Mobile Radeon 7200), it can get it working now, with the MonitorLayout option to "LVDS, CRT". I cannot get to any virtual consoles using alt-ctrl-f1 etc. now. X freezes and h as to be killed. I am not sure if it's related, but it's annoying.
(In reply to comment #38) > On Dell Inspiron 4150 (Mobile Radeon 7200), it can get it working now, with the > MonitorLayout option to "LVDS, CRT". > > I cannot get to any virtual consoles using alt-ctrl-f1 etc. now. X freezes and h > as to be killed. I am not sure if it's related, but it's annoying. can you please attach your xorg log?
Created attachment 1539 [details] Log of above note
Created attachment 1545 [details] Xorg.log on Acer TravelMate 803 > > - I need Option "MonitorLayout" "LVDS,TMDS" in my Xorg.conf > > Does you laptop actually have a DVI port? No, just an analog port. > If not does replacing TMDS with CRT also work? Yes, it also works.
Comment on attachment 1133 [details] [review] [FIXED_X11R68x] Another improved patch Patch checked-in into X11R6.8.x stable branch: /cvs/xorg/xc/ChangeLog,v <-- ChangeLog new revision: 1.365.2.97; previous revision: 1.365.2.96 cvs commit: Using deprecated info format strings. Convert your scripts to use the new argument format and remove '1's from your info file format strings. /cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_bios.c,v <-- radeon_bios.c new revision: 1.1.2.1; previous revision: 1.1 /cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v <-- radeon_driver.c new revision: 1.19.2.4; previous revision: 1.19.2.3 cvs commit: Using deprecated info format strings. Convert your scripts to use the new argument format and remove '1's from your info file format strings. Mailing the commit message to xorg-commit@lists.freedesktop.org...
I don't believe that the latest patch fixes all of the problems yet (although it certainly is an improvement). I have a Compaq Evo N1000c laptop with a Medion TFT monitor on the external port. I tried the patch before and it didn't work with the external monitor. I tried the 6.8.1-901 version today and it still has an issue. Have to be a bit vague about the problem as I'm not completely sure how to describe it. However the 6.7.0 version doesn't have any issues with this monitor and neither do I see any issues with the occasional use of an "other operating system". What I see on the Medion TFT monitor with 6.8.0 or later is that the displayed screen is shifted vertically and starts at about 1/3 of the monitor screen. By powering off/on the monitor, it displays correctly, but there is a "pop-up error box" that is displayed by the monitor over the screen. This is done by the monitor and it blocks part of the image. The makes it impossible to use the monitor. I'll attach the 6.8.1-901 and 6.7.0 Xorg-x11.log files next.
Created attachment 1611 [details] The 6.8.1-901 startup log for entry above
Created attachment 1612 [details] The 6.7.0 startup log for entry above
(In reply to comment #36) > The last patch works for me (Acer TravelMate 803, Mobility Radeon 9000) and > enables dualhead again. > Thanks for this! > > However, it still has some disadvantages compared with the old XFree driver: > - I need Option "MonitorLayout" "LVDS,TMDS" in my Xorg.conf > - if external monitor is disconnected, the desktop still uses dualhead size > which means windows appear in the "off". The old driver detected this and > reduced desktop size to existing screens. > It would be nice if you could fix this. I just tried the 6.8.1.902 release as packaged by Fedora Rawhide and still see these problems on my eMachines M6805 (x86_64) laptop (Radeon Mobility 9600). Seeing as how a switch between dual head and single head every day this is really a bummber for me. I'll attach the output and my config.
Created attachment 1683 [details] mobility 9600 not detecting dual head properly
Created attachment 1684 [details] mobility 9600 config With the monitorlayout option dual head works and single head does not. Without the monitorlayout option it's the other way around.
I have just tried the patch applied to CVS. My laptop is an IBM ThinkPad R50p with an ATI FireGL Mobility T2 (M10) NT (AGP) found. I am running FreeBSD 5.3 and xorg 6.8.1. I am using Option "MonitorLayout" "LVDS, CRT" which allows the X server to start when a monitor is attached, but the CRT does not seem to be functional, according to the logs I've attached. Without this option, the laptop's LCD is inactive, and the CRT says that the refresh rate 57.2kHz / 40 Hz is out of range. I'm attaching 4 things: 1. my xorg.conf 2. Xorg.0.log with just the LCD without the MonitorLayout Option 3. Xorg.0.log with the CRT plugged in without the MonitorLayout Option 4. Xorg.0.log with the CRT plugged in with the MonitorLayout Option the next thing I'm going to try is the current 6.8.2 CVS code for the radeon to see if i have anymore luck there.
Created attachment 1720 [details] Xorg.conf with MonitorLayout Option for R50p
Created attachment 1721 [details] Xorg.0.log with just laptop LCD for R50p without MonitorLayout Option
Created attachment 1722 [details] Xorg.0.log with just external CRT for R50p without MonitorLayout Option
Created attachment 1723 [details] Xorg.0.log with the CRT plugged in with the MonitorLayout Option
The use of the patch in attachment 1133 [details] [review] leads to the manifestation of bug 1991. The module without the patch does not have this bug.
> The use of the patch in attachment 1133 [details] [review] [edit] leads to the manifestation of bug 1991. > The module without the patch does not have this bug. Yeah, confirmed here. OTOH the X server version used (6.6.8 or any 6.7) does not matter, so that suggests it's in de patch as well.
mass update: the fix for this bug was applied to both HEAD and the stable 6.8 branch, but the bug was never closed. closing now.
Unless a fix was applied post-6.8.2 then this bug is not yet fixed for me. Using Fedora's xorg-x11-6.8.2-1.FC3.13 I still have to use MonitorLayout to get dual head to work and comment it out to switch back to single head when no monitor is plugged in.
*** Bug 1622 has been marked as a duplicate of this bug. ***
Please note: at least one CVS change since 6.8.2 has broken dual-head operation. I have located one already (a change in a macro that exposed an old bug), fixing of that makes 6.8.3-6.8.99 work. Now I run into another one which I am hunting down now.
There's another regression which is even worse :-( I'm testing SUSE 10.0 beta at the moment - when I start X with the external monitor connected, the laptop display is switched off. This means I have to _disconnect_ the external monitor _every time_ before starting X which is really annoying. My system is a Acer TravelMate 803 laptop with Mobility Radeon 9000. The same xorg.conf (with MonitorLayout option) worked on SUSE 9.3. X version is 6.8.2 in both cases, but SUSE has added some new patches to support new graphic cards AFAIK.
It seems to be that this is fixed in current CVS code. SUSE will ship 7.0 as soon as it is out, so this 'regression' shouldn't be seen too long. Waiting for customer input (Christian :) to confirm so we can close this one for good. Thanks Erik for working on this! Maybe it's good for you to know that CVS works better than 6.8.2, at least for me...
Christian just replied that for him the CVS driver doesn't work any better (even worse)... :-(
*** Bug 2755 has been marked as a duplicate of this bug. ***
*** Bug 2985 has been marked as a duplicate of this bug. ***
*** Bug 4606 has been marked as a duplicate of this bug. ***
This bug still exists in CVS as of 10/24/2005 and no one seems to be working it. I have a Dell Latitude C610 laptop with the Radeon Mobility M6 LY video chipset. Currently I must use manually switch between using an external or internal monitor, because if I let it auto detect, the external display is locked at 800x660 maximum resolution. Manual work around of: Option "MonitorLayout" "CRT, LVDS" Is used when wanting to drive an external display at anything higher than 800x600. Please fix this before 6.9/7.0 final. Please! This wasn't a problem with 6.8.2, that release worked perfect without workarounds. With this submission, I'll be attempting to change "Version" to CVS_head in hopes it will finally get some developer attention.
this bug is getting so long as to be useless. can people please clarify what the actual issue they're experiencing is?
(In reply to comment #67) > this bug is getting so long as to be useless. can people please clarify what > the actual issue they're experiencing is? Sure. As of today, using the X11R7.0 as distributed by Fedora Core 5 I can no longer get a monitor detected on the VGA port of my laptop's Radeon 9600. X 6.4 worked as expected. X 6.8 could be made to do dual head using a MonitorLayout incantation.
Ok, let's start again then :) Can you try the ati-1-0-branch driver (I suspect it needs xorg 7.0 though) and send me the logs if it still fails ? This branch is where we are trying to fix as much as possible of the known bugs without adding features in order to maybe, finally, have a radeon driver that doesn't suck like hell
> Can you try the ati-1-0-branch driver (I suspect it needs xorg 7.0 though) and > send me the logs if it still fails ? This branch is where we are trying to fix > as much as possible of the known bugs without adding features in order to maybe, > finally, have a radeon driver that doesn't suck like hell That would be great. For a long time I used the ati driver from 6.8.2 which I compiled myself, which (at least for LVDS+CRT) worked like a charm. After that version, it got worse and worse. My exact problem (still) is that with versions after 6.8.2 my CRT does get detected, but nothing is sent to it. Xorg log says it sees the monitor, gets the valid resolutions, picks a valid one, but the monitor says: no signal. I did some trickery to force the CRTC2 output to be sent to external TMDS (DVI) as well, and then on DVI it does show some picture, light blue, nothing on it, and a garbled mouse pointer. There must be something really screwed up here. Even if you start X afterwards with WORKING (i.e. 6.8.2 or older) dual head, the second screen is still messed up. It needs a reboot to get it right. Now I installed FC5 as well, of course new Xorg server, new driver model (.so) so my own compiled driver didn't load anymore. So I compiled again 6.8.2, now in so mode, copied the ati drivers over and now it works like a charm. But (of course) this is not satisfying, if only because Alex's superpatch, which I'd really like to see working, won't apply to it. OTOH I cannot apply it to newer versions; the driver simply won't work. So... I'd really like to see someone (preferrably the one who made the changes) to review the changes after 6.8.2 and reverse the change that broke a working dual head setup. If anyone is interested I can supply the 6.8.2 *.so files for ati/radeon, which do work.
I think I fixed that in the ati-1-0-branch driver, so please test and report
(In reply to comment #71) > I think I fixed that in the ati-1-0-branch driver, so please test and report I finally got to this... It appears that the "old" (non-modular) xserver cvs repository isn't being updated anymore. So I switched to the "modular" xorg cvs. And finally got it working :-( Now, when I do cvs update -r ati-1-0-branch in the ati directory, it doesn't compile. If I do the same on the top level, many files are thrown away and I can't compile anything anymore. How am I supposed to fetch this ati-1-0-branch and build it?
the ati-1-0-branch is for use with the 7.0 server. If you are using the server from CVS as well, use the normal top of tree ati driver, it contains the same fixes
I already compiled and tested Xserver & ati driver from CVS HEAD and it doesn't solve the problem. I still have no output from my second head at all, even though the monitor is probed and found, the head is initialised as :0.1 and xrandr says it is set to the right resolution (1280x1024@75). I also tried checking out -r ati-1-0-branch from both the "old" and "new" cvs server, both throw away a lot of files and do not compile. I have both a HEAD Xserver (installed in an alternative root) and 7.0 Xserver (from fedora core 5) installed in the usual location. 7.0 Xserver + ati driver that comes with it (from FC5 rpms) have the problem, HEAD Xserver and HEAD ati driver also have the problem The only thing that works is (again) to compile the 6.8 ati driver with .so output together with any post-6.8 Xserver. Please note that this change broke things to start with: Index: radeon_macros.h =================================================================== RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_macros.h,v retrieving revision 1.5 retrieving revision 1.6 diff -u -p -r1.5 -r1.6 --- radeon_macros.h 29 Mar 2005 03:49:04 -0000 1.5 +++ radeon_macros.h 23 May 2005 09:50:20 -0000 1.6 @@ -78,7 +78,7 @@ do { \ CARD32 tmp = INREG(addr); \ tmp &= (mask); \ - tmp |= (val); \ + tmp |= ((val) & ~(mask)); \ OUTREG(addr, tmp); \ } while (0) @@ -90,7 +90,7 @@ do { \ do { \ CARD32 tmp_ = INPLL(pScrn, addr); \ tmp_ &= (mask); \ - tmp_ |= (val); \ + tmp_ |= ((val) & ~(mask)); \ OUTPLL(pScrn, addr, tmp_); \ } while (0) Although I can't see anything wrong with it, apparently it triggers another bug. If I leave this change out, I can use newer releases, but from a certain point up (somewhere around XORG-6_8_99_7 IIRC) again it stops working, this time I get a picture, but it's completely lightblue with a garbled pointer and nothing shows up on the screen. Maybe it's this issue you resolved (I hope...)?
(In reply to comment #74) Interesting, sounds like at least one of the OUTPLLP() calls is incorrect. The ones in RADEONCrtIsPhysicallyConnected() look fishy, e.g.
Some words about the current status (SUSE 10.1 RC1, Xorg 6.9 + "radeon10b" driver on the Acer Travelmate 803 from initial comment) - dualhead works again :-)) - I currently use my old xorg.conf with "MonitorLayout" option - I didn't have the time to do tests without it yet. - but: Ctrl-Alt-F1 gives me a black laptop display (backlight is on) + external monitor "out of range". The funny thing: When I switch back to X, I see the console for about half a second on the laptop display...
The nasty thing is that once I had this sorted out, which exact line gave the problem, but I don't have the modified source anymore :-( I do know it's not a PLL thing, it's an INREG or OUTREG thing. it might be this one. If not, I guess I'll have to redo the search :-( (around line 899) if (info->MergedFB) OUTREGP(RADEON_CRTC2_GEN_CNTL, 0, ~(RADEON_CRTC2_DISP_DIS)); } else { switch (info->DisplayType) { case MT_LCD: case MT_DFP: case MT_CRT: -> OUTREGP(RADEON_CRTC2_GEN_CNTL, -> /* 0, */ RADEON_CRTC2_CRT2_ON | RADEON_CRTC2_EN, /*EMS*/ -> ~(RADEON_CRTC2_DISP_DIS)); break;
Yeah, that looks like it wouldn't work as intended either. BTW, I tracked the macro changes down to bug 3369, which has some interesting pointers to other bugs as well.
This is one of the reasons I dislike those "P" macros a lot: they tend to hid bugs like that. Also, it's never clear by reading the code if a given implementation does (old & mask) | new, (old & ~mask) | new, (old & mask) | (new & ~mask) or (old & ~mask) | (new & mask). All 4 variations "make some sense" and are used in various drivers every now and then . Even worse in radeon, we actually change the semantics of one. In general, I just prefer open coding: v = INREG(...); v &= ~(bits to clear); v |= (bits to set); OUTREG(..., v); I would suggest that for any "bug" you guys end up fixing regarding the misuse of those macros, to also open code the fix. One reason for the "P" accessors which can be considered useful is when fine-grained locking is needed on register accesses but that isn't the case for us. Ben.
(In reply to comment #76) > - but: Ctrl-Alt-F1 gives me a black laptop display (backlight is on)+external > monitor "out of range". The funny thing: When I switch back to X, I see the > console for about half a second on the laptop display... I just found that this is framebuffer-related. The TTYs work with vga=normal.
Well, are there still any open issues in this bugreport, which haven't been adressed yet?
Closing.
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.