Description of problem: Just as for http://www.phoronix.com/scan.php?page=news_item&px=mageia-5-intel-broadwell-nuc I ran into this problem. Not at first. I installed MGA5 B3 using the isodumper utility onto a usb drive. After solving a few problems (related elsewhere) the system booted up and I logged in and got a graphics screen. After playing around with the trackpad etc I decided to try to change resolution since the text was really tiny on a 13 in screen with HD display. That is when the disaster occured. I chose the 1600 resolution, and got exactly what Phoronix got, a magenta coloured, distorted display on the left half of the screen. When Itried to set it up, and test it, first got a tiny part of the resolution selection window against the terminal window. as a background. When I clicked OK (that being the only button visible) I finally got exactly the kind of display Phoronix has a picture of. I could work in that screen, and I tried to run MCC graphics again, and went back to Automatic, but it made no difference. I tried to go to 1200 x1000 and again that made no difference. I went back to Automatic and rebooted, and again no difference. I finally reinstalled from my usb stick (reformating the partition) and now I was back to an acceptable screen again. Ie, it is impossible to change resolutions on the Dell XPS13 9343 (2015) edition. Version-Release number of selected component (if applicable): MGA5 B3 How reproducible: Seems to be reproducible. Steps to Reproduce: See above. Install, and then try to change resolution. Reproducible: Steps to Reproduce:
Additional info. I copied all of /etc into a different partition. I then changed resolution, and used rsync -anv to compare. The differences were in /etc/X11/xorg.conf, and in /usr/share/mga/backgrounds. In the latter, before the change, one had /usr/share/mga/backgrounds/default.jpg->Mandriva-Default-1920x1080.jpg, and afterwards it pointed to Mandriva-Default-1920x1440.jpg In xorg.conf, the difference was 8a9 > Option "DontZap" "False" # disable <Ctrl><Alt><BS> (server abort) 11d11 < Option "DontZap" "False" # disable <Ctrl><Alt><BS> (server abort) 20a21 > Option "PreferredMode" "1600x1200" 39a41,61 > DefaultColorDepth 16 > > Subsection "Display" > Depth 8 > Modes "1600x1200" "1280x1024" "1024x768" "800x600" "640x480" > EndSubsection > > Subsection "Display" > Depth 15 > Modes "1600x1200" "1280x1024" "1024x768" "800x600" "640x480" > EndSubsection > > Subsection "Display" > Depth 16 > Modes "1600x1200" "1280x1024" "1024x768" "800x600" "640x480" > EndSubsection > > Subsection "Display" > Depth 24 > Modes "1600x1200" "1280x1024" "1024x768" "800x600" "640x480" > EndSubsection Not clear what is causing the problems. But there is another symptom as well. After I change the resolution as I said, I see a small piece of the X window where I changed the resolution, over the old terminal screen that would have been on F1. I happened to have a mouse plugged in and the mouse cursor was still on that screen. As I move the mouse around, I get the X screen being painted on under the mouse cursor (about a 100x100 patch) If I did alt-Ctl F2 I could type in the terminal, but the mouse cursor would also paint that screen (this time not the graphics resultion change window, but the MCC window that would have been below that) Again, I could type of the screen fine. Ie, X and the terminal window seemed to be very confused together. If I copied the old files back onto the changed ones, and did a double alt-ctrl-BKSP the screen would come back up again with the good display, while if I did that without the old files ( only xorg.conf I think) I would get the horrible magenta mess that Phoronix has a picture of. I now ran a couple of test. It is the line DefaultColorDepth 16 that causes the trouble. If I put that in, the screen goes all magenta and the desktop only covers half the screen. Without that line, things are "fine". On the other hand, if I put in DefaultColorDepth 24 I do not get the distorted halfwidth magenta screen. Ie, the new xorg.conf that you generate on screen change confuses the hell out of the system. In your options for the depth, you only have the option of 1600x1200, 1200x1024,... and 16 bit colour. You do not have the native option of 1920x1080 24 bit colour. Mind you selecting any of the alternative resolutions makes no difference anyway.
Some more information: I also installed fedora onto this machine. It does not seem to use /etc/X11/xorg.conf, since there is nothing there. Not sure where it hides your choice. But it also has a whole list of very very different choices in their display manager. 1920x1080, 11400x1050, 1280x1024, 1280x960,800x600, 640x480 which make more sense than the Mageia ones( eg the vertical is less than the maximum for all of them) Mageia's are simply a standard list. Also fedora seems to have no colour selection ( which is probably good, since it seems only 24 bits works at all.) Ie, they seem to have gotten their list of resolutions from somewhere close to the graphics driver, while Mageia's seems to be a stock list.
xrandr reports very different lists on fedora than on Mageia. (both are xrandr 1.4.3) In mageia xrandr reports only one resolution 1920x1080. On fedora it reports all of the resolutions listed in comment 2 as possible display resolutions. Also using mageia's xrandr under fedora gives the same report as fedora's xrandr, so it is not a difference in the version of xrandr, but something to do with the graphics drivers on the two machines I would guess.
Summary: Graphics goes crazy when changing resolution on Dell XPS13-9343 (2015 edition) => Graphics goes crazy when changing color depth on Dell XPS13-9343 (2015 edition)
Comparing the Xorg.0.log files on the Fedora and the Mageia, the Mageia does not load the "intel" module, while Fedora does. If I put in an explicit LoadModule "intel" line into /etc/xorg.conf, X loads the intel module and unloads it again.
Created attachment 6067 [details] Xorg.0.log on Mageia with LoadModule "intel"
Created attachment 6068 [details] Xorg.0.log on Fedora Note the loading of the intel module
I tried removing the xorg.conf file entirely from Mandriva, and it now behaves the same way as does Fedora. The xrandr lists a whole bunch of resolutions, it boots into X much faster. However the one difference is that the module "modesettings" does not exist in /usr/lib/xorg/modules/drivers. So, stopping XFDrake from generating an /etc/X11/xorg.conf file seems to solve a lot of the problems.
Attachment 6067 mime type: application/octet-stream => text/plainCC: (none) => thierry.vignaud
Attachment 6068 mime type: application/octet-stream => text/plain
What's the output of "lspcidrak -v|grep Card"? Also please attach (not paste) your original /etc/X11/xorg.conf.
Keywords: (none) => NEEDINFO
OK, this is Broadwell-U hardware for gfx.
Summary: Graphics goes crazy when changing color depth on Dell XPS13-9343 (2015 edition) => Graphics goes crazy when changing color depth on Dell XPS13-9343 (2015 edition) (Broadwell-U)
(from https://gist.github.com/semenko/60015029e13c1de65ff6)
Could you get XFDrake not to generate an /etc/X11/xorg.conf file for this machine? It really causes problems.
Mageia do load the intel driver. One difference is that FC tryes all drivers that could work (from generic fb/vesa/modesetting to the right one -- intel) Can you check if just commenting "DefaultColorDepth 16" in your /etc/X11/xorg.conf is enough to fix the issue? If that's the issue, we could just as well prevent 16bit bpp to be selected for newer Intel GFX, only allowing 24/26 depth. BTW can you try mga5 RC? It's not yet released but you can ask eg Marja in order to get it.
Source RPM: (none) => kernel, x11-driver-video-intel, ldetect-lst, drakx-kbd-mouse-x11Priority: Normal => release_blocker
Created attachment 6292 [details] Only allow 24bpp for intel (mga#15493) That's a huge hammer as we prevent selecting 16bpp for older intel too but at least it should do it... You can test this patch by opening a terminal as root then running the following commands cd /usr/lib/libDrakX patch -p1 < /where/it/was/downloaded/0001-only-allow-24bpp-for-intel-mga-15493.patch Note that you'll got a faillure (unlike git, there won't be a NEWS file to patch but we don't care about that one, we only care about the other file to patch). Then run XFdrake and reconfigure. Alternatively, we could split the intel entries in ldetect-lst. eg "Intel 810 and later" would be split between: - "Intel 810 up to Ivy Bridge" - "Intel Haswell and later If name would match the former, we would still default to offer 16,24 depths If name would match the later, we would only allow 24 depth. Obviously it would be best if either intel DRM or intel xorg driver could be fixed, that fills the gap... BTW can someone test what happens if we select 16bpp on older intel gfx card? Is it broken too?
Thomas, Anne, see my previous comment & proposed patch
CC: (none) => ennael1, tmbSummary: Graphics goes crazy when changing color depth on Dell XPS13-9343 (2015 edition) (Broadwell-U) => Graphics goes crazy when changing color depth on Broadwell-U
Keywords: (none) => PATCHURL: (none) => http://www.phoronix.com/scan.php?page=news_item&px=mageia-5-intel-broadwell-nuc
If that works (and it should) we should redo the classic & live images one last time so that we got good press on Phoronix :-) We could include a kernel with conflicts on older grub2 too BTW :-)
Is this actually still an issue with a fully updated system ? The problem with beta3 was partly becuse ldetect-lst was not updated for Broadwell so ve I now have a Intell NUC with Broadwell here, and it seemed to work ok now ... I will try to play with it tonight..
(In reply to Thierry Vignaud from comment #13) > > BTW can someone test what happens if we select 16bpp on older intel gfx card? > Is it broken too? 16bpp is no problem with Card:Intel 810 and later: Intel Corporation|3rd Gen Core processor Graphics Controller [DISPLAY_VGA] (vendor:8086 device:0166 subv:17aa subd:21f7) (rev: 09) (on laptop that was bought in 2013) I'll test some older ones
CC: (none) => marja11
Is this still an issue with a fully updated Cauldron ? One of the resons gpu failed on beta3 was that Broadwell was not listed in ldetect-lst. Also since beta3 there has been a lot of Broadwell related fixes in mesa , xorg intel driver, kernel... And atleast the Broadwell NUC I have here is not showing any problems with current cauldron (otoh I haven't tested switching display modes here, will do that tonight)
(In reply to Marja van Waes from comment #17) > (In reply to Thierry Vignaud from comment #13) > > > > > BTW can someone test what happens if we select 16bpp on older intel gfx card? > > Is it broken too? > > 16bpp is no problem with > Card:Intel 810 and later: Intel Corporation|3rd Gen Core processor Graphics > Controller [DISPLAY_VGA] (vendor:8086 device:0166 subv:17aa subd:21f7) (rev: > 09) > (on laptop that was bought in 2013) > > I'll test some older ones Btw, only testing 16bbp with "automatic" for hight and width Everything in updated cauldron (local mirror synced this morning) The 2nd one Card:Intel 810 and later: Intel Corporation|82852/855GM Integrated Graphics Device [DISPLAY_VGA] (vendor:8086 device:3582 subv:1014 subd:0562) (rev: 02) (bought in 2006) gave a very _crazy_dual_coloured_ bar around the user in KDM, that got _stripes_ in _more_colours_ when selecting that user, and the cursor was a black square for a while, but after having booted into KDE nothing is odd. ---------------- The 3rd one Card:Intel 810 and later: Intel Corporation|Mobile 4 Series Chipset Integrated Graphics Controller [DISPLAY_VGA] (vendor:8086 device:2a42 subv:17aa subd:213a) (rev: 07) (bought ± 2011?) Nothing odd ----------------- 4th one Card:Intel 810 and later: Intel Corporation|Core Processor Integrated Graphics Controller [DISPLAY_VGA] (vendor:8086 device:0046 subv:17aa subd:215a) (rev: 02) (not mine, don't know its age) exacly the same as the 2nd one: _crazy_colors_ for the bar around the user in KDM, black square around cursor between KDM and KDE reaching kde there is a message that kwin closed unexpectedly, but that may be unrelated. Apart from that, everything looks fine. I did not test watching videos or playing games that demand much of the video card
(In reply to Marja van Waes from comment #17) > (In reply to Thierry Vignaud from comment #13) > > > > > BTW can someone test what happens if we select 16bpp on older intel gfx card? > > Is it broken too? > > 16bpp is no problem with > Card:Intel 810 and later: Intel Corporation|3rd Gen Core processor Graphics > Controller [DISPLAY_VGA] (vendor:8086 device:0166 subv:17aa subd:21f7) (rev: > 09) > (on laptop that was bought in 2013) > *Not*true* with 16bpp on that laptop, tty 2-6 are unusable, and I get underruns see bug 14869 tty 2-6 give flickering screens that make it impossible to use them switching to 24bpp fixes it switching back to 16bpp makes it return :-(
(In reply to Marja van Waes from comment #20) > (In reply to Marja van Waes from comment #17) > > > *Not*true* > with 16bpp on that laptop, tty 2-6 are unusable, and I get underruns see bug > 14869 > > tty 2-6 give flickering screens that make it impossible to use them > > switching to 24bpp fixes it > switching back to 16bpp makes it return :-( Same for the 4th one I tested: fifo underruns that aren't there when using 24bpp, and tty2-6 are completely unusable. The other two do not have issues with tty 2-6 with 16bpp
CC: (none) => eeeemail
Unfortunately, as of Monday, I no longer have the machine on which I noticed this problem so cannot test out the solution. XFDrake dumped some default 16 bit stuff into xorg.conf, and that seemed to cause the trouble. I removed xorg.conf entirely and things worked, and continue to work. But as I said someone else, who does not have the expretise to test, now has the machine.
I don't have a Broadwell-U, but tested whether the patch would change if (member($card->{Driver}, qw(fglrx qxl savage))) { into if (member($card->{Driver}, qw(fglrx qxl savage intel))) { in /usr/lib/libDrakX/Xconfig/resolution_and_depth.pm However, nothing happened, here. Maybe because the patch, when standing in /usr/lib/libDrakX/ thinks the file is here: lib/Xconfig/resolution_and_depth.pm (where it is in git, starting from drakx-kbd-mousex11 root) instead of here Xconfig/resolution_and_depth.pm (where it is in my installed system, starting from /usr/lib/libDrakX/) ??? However, I didn't manage to adjust the patch so that it would work... thought that just removing all "lib/"s I saw would do the trick, but that didn't work here. I'll read up on creating and using patches /o\
(In reply to Marja van Waes from comment #23) > > I'll read up on creating and using patches /o\ Oops, sorry, should have done that before replying The -p1 takes care of the one level shorter path I don't know why the original patch didn't work for me to get that file adjusted, but a PEBCAK is very well possible :-)
Yeah, the path in git/svn does not always match, for example the "lib" in source code only usually means it will end up in some library path/package, not necessarily the toplevel one... But the patch utility is smart, so if you go to the directory where the file is you want to patch, it will auto-adjust path in the patch to match. And as you noted, if you want to manually strip path from the patch, use the -p flag
I didn't understand how to get around the needless NEWS part [root@Mga5RC_EFI libDrakX]# patch -p1 </home/marja/Downloads/0001-only-allow-24bpp-for-intel-mga-15493.patch can't find file to patch at input line 15 etc. So removed the "NEWS" part from the patch. After that, I had to manually give the path to the file to be patched: [root@Mga5RC_EFI libDrakX]# patch -p1 </home/marja/Downloads/0001-only-allow-24bpp-for-intel-mga-15493.patch can't find file to patch at input line 14 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |From b6f59f7caf39323545fbf14c9f370ccdd9a2d63f Mon Sep 17 00:00:00 2001 |From: Thierry Vignaud <thierry.vignaud@gmail.com> |Date: Thu, 16 Apr 2015 07:00:26 -0400 |Subject: [PATCH] only allow 24bpp for intel (mga#15493) | |--- | lib/Xconfig/resolution_and_depth.pm | 2 +- | 1 file changed, 1 insertion(+), 1 deletion(-) | |diff --git a/lib/Xconfig/resolution_and_depth.pm b/lib/Xconfig/resolution_and_depth.pm |index 06662ce..294fe5e 100644 |--- a/lib/Xconfig/resolution_and_depth.pm |+++ b/lib/Xconfig/resolution_and_depth.pm -------------------------- File to patch: Xconfig/resolution_and_depth.pm patching file Xconfig/resolution_and_depth.pm [root@Mga5RC_EFI libDrakX]# I'm blind to what I did wrong, why I had to adjust the patch and tell which file to patch. However, the patch works: it is impossible now to change back to 16bpp with XFdrake :-)
(In reply to Thomas Backlund from comment #25) > > But the patch utility is smart, so if you go to the directory where the file > is you want to patch, it will auto-adjust path in the patch to match. > Thanks, I hadn't seen your comment before I tried what I said in comment 26 So it should have worked if I had been in /usr/lib/libDrakX/Xconfig/ when I tried.
(In reply to Thierry Vignaud from comment #13) > > You can test this patch by opening a terminal as root then running the > following commands > cd /usr/lib/libDrakX > patch -p1 < > /where/it/was/downloaded/0001-only-allow-24bpp-for-intel-mga-15493.patch > > Note that you'll got a faillure (unlike git, there won't be a NEWS file to > patch but we don't care about that one, we only care about the other file to > patch). We've miscounted the slashes in the patch, the following works patch -p2 < /where/it/was/downloaded/0001-only-allow-24bpp-for-intel-mga-15493.patch After patch asks for the missing NEWS, it is enought to press "enter" and then answer "y" when it suggests to skip that patch (In reply to Thomas Backlund from comment #25) > > But the patch utility is smart, so if you go to the directory where the file > is you want to patch, it will auto-adjust path in the patch to match. > It wasn't that smart here (on two different laptops, one 32 and the other 64 bit)
btw, on the 32bit laptop it is now impossible, too, to change to 16 (or 15 or 8) bpp, only 24bpp is possible
Thomas, given Marja tests that show quite some Intel gfx chips are broken, WDYT about forbiding 16bpp for Intel?
Keywords: NEEDINFO => (none)
I'm a bit afraid that it could be too big hammer and we would get some systems that wouldn't work at all... Cant we just make it default to 24bpp and leave the others as backup
Created attachment 6376 [details] default to 24bpp for Intel
Created attachment 6377 [details] default to 24bpp (mga#15493) Alternatively, default to 24bpp for all cards that have DRI support. This might be more sensitive...
Created attachment 6378 [details] also default to 24bpp in test (b/c of automatic)
Marja, could you test one of - 6376: default to 24bpp for Intel - 6377: default to 24bpp (mga#15493) Plus: 6378: also default to 24bpp in test (b/c of automatic)
(In reply to Thierry Vignaud from comment #33) > Created attachment 6377 [details] > default to 24bpp (mga#15493) > > Alternatively, default to 24bpp for all cards that have DRI support. > This might be more sensitive... The patch applies fine, there is now: } elsif ($card->{use_DRI_GLX}) { $prefered_depth = 24; @depths = (24, 16); } else { in /usr/lib/libDrakX/Xconfig/resolution_and_depth.pm However, for both affected laptops, 24bpp was already used by default. I wouldn't have found the crazy flickering in tty 2-6 if I hadn't tested 16bpp for this bug. I don't know eihter whether the affected laptops (the ThinkPads L530 and T410 in this page https://wiki.mageia.org/en/User:Marja/QA/Hardware ) have DRI support. After applying the patch, with XFdrake still all resolutions (24, 16, 15, 8) seem available.
(In reply to Thierry Vignaud from comment #34) > Created attachment 6378 [details] > also default to 24bpp in test (b/c of automatic) The patch applied nicely. However, trying to test it, while leaving the configuration at 24bpp, X crashed. http://waesvanm.home.xs4all.nl/Packaging/Xorg.9.log Tbh, I hadn't pushed the "test" button in years.
after reverting the patch for "test", X crashes too on testing while leaving 24bpp. There is no diffence between the Xorg.9.logs, apart from the numbers between [ ] at the beginning of each line, the time and some pids
IIUC the evolution of this bug report, now the issue is that some Intel hardware do not handle properly other depths than 24 bpp, but XFdrake would select 24 bpp by default. So people would only hit the issue if they try to change the working default, to something that some intel hardware don't support well? If so, I think this bug would no longer be a critical release blocker. WDYT?
(In reply to Rémi Verschelde from comment #39) > IIUC the evolution of this bug report, now the issue is that some Intel > hardware do not handle properly other depths than 24 bpp, but XFdrake would > select 24 bpp by default. AFAIK the original issue also only occured after playing with the settings. > > So people would only hit the issue if they try to change the working > default, to something that some intel hardware don't support well? > > If so, I think this bug would no longer be a critical release blocker. WDYT? I agree, and maybe it can even be closed as fixed for this issue on a Broadwell (even if Thomas' Broadwell NUC isn't a Broadwell U) Or as old, because the reporter no longer has that machine? (In reply to Thomas Backlund from comment #18) > Is this still an issue with a fully updated Cauldron ? > > One of the resons gpu failed on beta3 was that Broadwell was not listed in > ldetect-lst. > > Also since beta3 there has been a lot of Broadwell related fixes in mesa , > xorg intel driver, kernel... > > And atleast the Broadwell NUC I have here is not showing any problems with > current cauldron > > (otoh I haven't tested switching display modes here, will do that tonight) Did you get around to trying that?
I was the OP. As I recall, I tried to change the default resolution, not colour. XFDrake then entered 16 bits as the default colour into xorg.conf, apparently because it could not figure out what the proper resolution/colour was for that card. That messed it all up. As far as I know the reporter in phoronix ran into the issue right off the bat on his XPS13 when he installed MGA5 beta on his machine. For me the issue went away when I removed xorg.conf entirely. I noted that in xfdrake there was a default section where it dumped a 16 bit colour section into xorg.conf if it could not figure anything else out. But as you say, I do not have the machine anymore-- it is 5000 miles away and is being run be a somewhat newbie, and asking him to test stuff that makes the machine completely unuseable is not on. Sorry.
tmb just said he considers this bug fixed
Status: NEW => RESOLVEDResolution: (none) => FIXED