Description of problem: For the last few weeks Cauldron has exhibited this followed recently by Mageia 8. My monitor is 1280x1024 but mga-bg-res is setting /usr/share/mga/backgrounds/default.jpg symlink to: default.png -> /usr/share/mga/backgrounds/Mageia-Default-3840x2160.png I am seeing the same in a new cauldron net install done today and in Mga 8. Looking at mga-bg-res output in cauldron it seems to be coming from /usr/sbin/monitor-edid Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3.
Priority: Normal => High
It is true that /usr/share/mga/backgrounds/default.jpg symlink to: default.png -> /usr/share/mga/backgrounds/Mageia-Default-3840x2160.png But this doesn't matter at any of my machines (MGA8, MGA), VB) with different monitors and resultions as the standard setting for background by default is "scaled" and "cut". So it seems to be a non conformant setting on your machine. See also bug 32320
See also bug 31320
(In reply to sturmvogel from comment #1) The two bugs you cite above were both mine and different, relating only to cauldron and not to the output of ma-bg-res which was correct at that time. > But this doesn't matter at any of my machines It certainly does on mine! When the Mageia logo is cut in half it gives a really bad impression of the distro! Maybe your monitors are roughly the same aspect ratios and fairly high ratio, so it is not so noticeable. I spent a lot of time getting this sorted for Mageia 6 so that the correct resolution was carried right through from grub2 -> plymouth -> sddm -> desktop. Now it's a mess and it's also been broken just recently the same way in Mga8 which was perfectly OK, as was cauldron. I was tempted to set this as a release blocker however I suspect it could be fixed after release.
Whiteboard: (none) => MGA8TOO
What's the output of (as root) "monitor-get-edid|monitor-parse-edid|head -n 20"?
CC: (none) => davidwhodgins
This is something that used to work, but does not now - even if only Barry currently sees it - for both Mageia 8 and Cauldron. So something has changed. Barry: can you remember where you had to fiddle to get it right for Mageia 6? And say where you are seeing the corrupt screens: boot, login, desktop? If possible, please attach a screenshot. Frank: where are the "scaled" and "cut" settings you mention in comment 1? We can check ours. I cannot find 'mga-bg-res' at all.
CC: (none) => lewyssmith
(In reply to Lewis Smith from comment #5) > Frank: where are the "scaled" and "cut" settings you mention in comment 1? > We can check ours. Right-click at your desktop -> Background (In reply to Lewis Smith from comment #5) > I cannot find 'mga-bg-res' at all. It's in package mageia-theme
/usr/libexec/mga-bg-res it's run as a systemd service(In reply to sturmvogel from comment #6) > (In reply to Lewis Smith from comment #5) > > Frank: where are the "scaled" and "cut" settings you mention in comment 1? > > We can check ours. > Right-click at your desktop -> Background > That is only for the plasma D.E. AFAIK > > (In reply to Lewis Smith from comment #5) > > I cannot find 'mga-bg-res' at all. > It's in package mageia-theme /usr/libexec/mga-bg-res it runs as systemd service I will get the o/p from monitor-get-edid later from the machine with the 4:3 monitor.
(In reply to Dave Hodgins from comment #4) > What's the output of (as root) "monitor-get-edid|monitor-parse-edid|head -n > 20"? This returns "bad data" since monitor-get-edid outputs nothing. This is in Mga8 and recent Mga9 on the same hardware. However: [baz@localhost ~]$ xrandr --verbose|grep "*current +preferred"|cut -d ' ' -f3 1280x1024 which is correct and 1.25 aspect ratio compared to the 1.77 selected by mga-bg-res: default.png -> /usr/share/mga/backgrounds/Mageia-Default-3840x2160.png As a point of interest when connected to this machine over ssh from the laptop, monitor-get-edid correctly outputs the details of the laptop display, but for some reason it is not reporting the EDID of the Dell 1280x1024 monitor locally.
I had similar problems with a very old 1280x1024 svga monitor that did not return any edid info. That monitor failed due to a lightning strike, but IIRC, unlike with newer monitors, it required a properly setup xorg.conf file. I also seem to remember having to add vga=263 to the kernel parameters.
(In reply to Dave Hodgins from comment #9) > I had similar problems with a very old 1280x1024 svga monitor that did not > return any edid info. That monitor failed due to a lightning strike, but > IIRC, unlike with newer monitors, it required a properly setup xorg.conf > file. I also seem to remember having to add vga=263 to the kernel parameters. Hmm.. I have a Sony monitor with the same aspect ratio - I will try that tomorrow. I am not happy about the default changing from 4:3 to 16:9, it seems rather extreme since newer (horrible wide screen) monitors are more likely to be correctly identified than older sensibly shaped ones. I can only imagine that if the edid is not being read then the old default always matched my monitor. However I'm not convinced. The Dell 1708FP monitor spec [1] does say: "The monitor automatically provides the computer system with its Extended Display Identification Data (EDID) using Display Data Channel (DDC) protocols so the system can configure itself and optimize the monitor settings." [1] https://dl.dell.com/manuals/all-products/esuprt_electronics/esuprt_display/dell-1708fp_user%27s%20guide_en-us.pdf
OK problem resolved. A different monitor's EDID was read and worked perfectly with all screens displayed correctly using the 1280x1024 resolution. Just why my monitor is not being read correctly I have not determined. It could be the cable which is plugged both ends so not specific to the the monitor. As a workaround I have used a generic EDID which can be created in the kernel sources and passed on the kernel command line.[1] It works perfectly with my original monitor so I will open an enhancement bug to request tmb to create and package these 5 tiny binaries in /lib/firmware/edid/ so they are there for immediate use should they be required. [1] https://docs.kernel.org/admin-guide/edid.html So thankfully closing as invalid :)
Resolution: (none) => INVALIDStatus: NEW => RESOLVED