Description of problem: The background in kdm is a black one. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3.
Assignee: mageia-artwork => bugsquadSource RPM: mageia-kde4-config-common 3.mga1 => mageia-theme-Default
What's the output of 'rpm -q mageia-theme-Default' and: ls -l /usr/share/mga/backgrounds/default.jpg
[dimitris@localhost ~]$ rpm -q mageia-theme-Default mageia-theme-Default-1.5.0.13-1.mga1 [dimitris@localhost ~]$ ls -l /usr/share/mga/backgrounds/default.jpg lrwxrwxrwx 1 root root 27 May 15 16:10 /usr/share/mga/backgrounds/default.jpg -> Mageia-Default-1024x768.jpg
The issue happens when updating to mageia-theme-Default-1.5.0.13-1.mga1, Mageia-Default-1024x768.jpg doesn't exist any more, so the symlink is dangling. (If possible, lease don't change it manually until the next mageia-theme package which should fix the issue is available).
Next package should be on the mirrors soon, please test. Thanks.
New package fixed the problem. Thank you.
so closing as fixed.
Status: NEW => RESOLVEDCC: (none) => balcaen.johnResolution: (none) => FIXED
*** Bug 1341 has been marked as a duplicate of this bug. ***
CC: (none) => kobi.tk
Reopening as kobi seems to be affected.
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
@Kobi: what's the output of: rpm -qa '*mageia-theme*' | sort
Fixed with mageia-theme-1.5.0.14, 1024x768 wasnt re-added after the time of the day wallpapers were removed. Kobi can you confirm please.
CC: (none) => watersnowrock
(In reply to comment #10) > Fixed with mageia-theme-1.5.0.14, 1024x768 wasnt re-added after the time of the > day wallpapers were removed. > > Kobi can you confirm please. Which isn't a proper fix in this particular bug; /usr/share/bootsplash/scripts/switch-themes should create the symlink to wallpaper with the best fitting resolution (in %posttrans of mageia-theme-Default), and it definitely won't/shouldn't create a symlink to a non-existent file, that's the actual bug here, if Kobi could still reproduce it with mageia-theme-Default-1.5.0.13-3.mga1. And IIRC, according to ennael and mikala (on IRC), the 1024x768 was dropped as not needed any more, with the prerogative that 1024x600 is enough (targeting netbooks with small resolutions), maybe I understood wrongly after all.
That is true, however, not providing a 1024x768 background when the switch-themes script hasn't been fixed seems a little premature. Also, re-adding the background takes a few seconds and I could do it straight away, whereas fixing the script could take a lot longer as I have no idea when anyone would have time to look at it. It also seems a little early to drop 1024x768, as it may be old, but it is still used by a good few computers, and as they tend to be of lower spec range, surely having full support is good as there is a decent chance that they might try Linux on them. Either way, if this was wrong I will revert the changes if not, then the problem is solved and the script can be fixed later.
(In reply to comment #12) > That is true, however, not providing a 1024x768 background when the > switch-themes script hasn't been fixed seems a little premature. The point is, the script isn't broken as far as we know, given it worked in my test VM, worked for Dimitris, and probably for the rest of the population out there since we saw no other reports of the issue, and that's an eye-poker, we'd have had torrential duplicates by now given that due to another bug during the first couple of months, lots of users got a symlink to 1024x768; there was only one report that the issue isn't resolved, as reported by Kobi... :)
@Ahmad [kobi@localhost ~]$ rpm -qa '*mageia-theme*' | sort mageia-theme-common-1.5.0.13-3.mga1 mageia-theme-Default-1.5.0.13-3.mga1 mageia-theme-Default-screensaver-1.5.0.13-3.mga1 I have installed beta2 and after some time I have updated it to latest caudron. After restart there was no background (blue color in gmd and desktop). I have checked syslog for postinstall scripts errors related to mageia theme, no errors was found. I suspect that default.jpg link was not "recreated" and is pointing to removed background.
While installed latest updates there was some errors: 23/24: mageia-theme-Default ############################################################################# 24/24: mageia-theme-Default-screensaver ############################################################################# Can't call method "get_resolution" on an undefined value at -e line 1. Can't call method "get_resolution" on an undefined value at -e line 1. Can't call method "get_resolution" on an undefined value at -e line 1. Can't call method "get_resolution" on an undefined value at -e line 1. But I think they are related to initrd recreation.
@Donald I confirm, mageia-theme-1.5.0.14 fixes this problem.
Ahmad you are right, my "fix" was more than somewhat wrong...... 1920x1440 == 1024x768 So it is a symlink issue, will go and check properly now.
Ok, tmhe symlinks aren't being made by the makefile in mageia-theme anymore. Mikala told me that they were being made in switch-themes, however, there is nothing there atm. Ahmad - are you planning on adding symlinks in switch-themes?
(In reply to comment #15) > While installed latest updates there was some errors: > 23/24: mageia-theme-Default > ############################################################################# > 24/24: mageia-theme-Default-screensaver > > ############################################################################# > Can't call method "get_resolution" on an undefined value at -e line 1. > Can't call method "get_resolution" on an undefined value at -e line 1. > Can't call method "get_resolution" on an undefined value at -e line 1. > Can't call method "get_resolution" on an undefined value at -e line 1. > > But I think they are related to initrd recreation. No, this is the cause of this bug, you don't have an /etc/X11/xorg.conf, so the routines run by the switch-theme script can't guess your resolution and so the symlink never gets created/updated.
CC: (none) => pterjan
(In reply to comment #18) > Ok, tmhe symlinks aren't being made by the makefile in mageia-theme anymore. They never were created by the makefile IIUC. > Mikala told me that they were being made in switch-themes, however, there is > nothing there atm. There's: [ -f /usr/lib/libDrakX/Xconfig/resolution_and_depth.pm ] && perl -I/usr/lib/libDrakX -MXconfig::xfree -MXconfig::resolution_and_depth -e 'Xconfig::resolution_and_depth::set_default_background(Xconfig::xfree->read->get_resolution)' which does the job (pterjan explained that to me on IRC a couple of days ago). [...]
Closing this report. Kobi's issue will be tracked in bug 1341.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
Ahamd: which symlinks are you meaning? The ones from the resolution to default.jpg or from the large resolution images to the lower resolution images of the same aspect ratio? The high res to low res with same aspect was done in the makefile, look at the diff between 1.5.0.13 and 1.5.0.12. Readding those links would have had the same effect as readding the 1024x768 image that I did here. (Note that there are links for the time of day crap in there, I am meaning specifically from resolution to smaller resolution, that was repeated 4 times oer image [0000 0700 1300 1800]) The ones from the different resolutions to the default.jpg was never something that has changed to my knowledge.
(In reply to comment #22) > Ahamd: which symlinks are you meaning? The ones from the resolution to > default.jpg or from the large resolution images to the lower resolution images > of the same aspect ratio? > The former.
Ok, well, the links in the mageia-theme makefile need put back as atm we are without lots of resolutions unless switch-theme-sh can automate this somehow.
What/where is that makefile you keep mentioning?
In mageia-theme in soft.
AFAICS a symlink to default.jpg was/is never created in the Makefile, I've checked the very first svn revision in svn/soft http://svnweb.mageia.org/soft/theme/mageia-theme/trunk/Makefile?revision=477&view=markup .
(In reply to comment #19) > > No, this is the cause of this bug, you don't have an /etc/X11/xorg.conf, so the > routines run by the switch-theme script can't guess your resolution and so the > symlink never gets created/updated. Yes and no ;-) I quickly looked /usr/lib/libDrakX/Xconfig/resolution_and_depth.pm IIUC, if it can't detect resolution, it uses 1024x768 by default (lines 283-286). so 1024x768 shouldn't be dropped from mageia-theme until resolution_and_depth.pm was changed to used another default fallback resolution. I tried to remove default.jpg, and manually run switch-themes Mageia-Default; the symlink default.jpg->Mageia-Default-1024x768.jpg is created (with message "defaulting background resolution to 1024x768").
CC: (none) => lmenut
Then the symlink should be to 1920x1440 & not to 1024x768 (for the background)
(In reply to comment #28) > (In reply to comment #19) > > > > No, this is the cause of this bug, you don't have an /etc/X11/xorg.conf, so the > > routines run by the switch-theme script can't guess your resolution and so the > > symlink never gets created/updated. > > Yes and no ;-) > > I quickly looked /usr/lib/libDrakX/Xconfig/resolution_and_depth.pm > IIUC, if it can't detect resolution, it uses 1024x768 by default (lines > 283-286). > so 1024x768 shouldn't be dropped from mageia-theme until > resolution_and_depth.pm was changed to used another default fallback > resolution. Right. But if there's no xorg.conf it fails altogether with the get_resolution error, comment#15. I've already added pterjan to CC in both reports, he said that the code needs to be fixed..
(In reply to comment #27) > AFAICS a symlink to default.jpg was/is never created in the Makefile, I've > checked the very first svn revision in svn/soft > http://svnweb.mageia.org/soft/theme/mageia-theme/trunk/Makefile?revision=477&view=markup > . I never said that it was. Its the symlinks from the high res images to low res images of same aspect ratio that were done here.
While installing lates updates on RC (other hardware) i noticed message "defaulting background resolution to 1024x768" but on this computer I have fglrx and 1280x1024 monitor. xorg.conf is present, but there is no information about resolution.
Check the output of 'ls -l /usr/share/mga/backgrounds/default.jpg'.
Created attachment 461 [details] Ugly fix for detect resolution I have made quick and ugly fix for this problem. It use monitor-edid to get resolution. It works for me. You can use it or trash it. I hope this will help.
Well, the problem with monitor-edid is: - it doesn't usually work on laptops - the user mayn't be using the native resolution, but a lower one So a more robust solution is better, I think Anssi committed a change to drakx-kbd-mouse-x11 to get the resolution using the X server auto-detection.
Status: RESOLVED => REOPENEDCC: (none) => anssi.hannulaResolution: FIXED => (none)Summary: Black background in kdm => The code creating default.jpg needs to be improvedSource RPM: mageia-theme-Default => drakx-kbd-mouse-x11
Hm. If monitor-edid works: => XFdrake will use it to detect resolution and set it in /etc/X11/xorg.conf => XFdrake will be able to use the values in xorg.conf for background resolution If monitor-edid doesn't work: => XFdrake will not put resolution information into /etc/X11/xorg.conf => The ugly fix in attachment #461 [details] can't work either. I guess the cause of the issue might be that monitor-edid doesn't work in installer (as no KMS/xrandr is available there, and probing EDID directly is not 100% reliable on laptops) so it creates an xorg.conf without resolution information. I'm a bit unsure on how to fix this - using monitor-edid to probe for resolution in XFdrake when it isn't set in xorg.conf is certainly an option, but it wouldn't help during installation if the resolution indeed can't be probed (as is probably the case as xorg.conf doesn't it).
Setting the resolution to automatic in XFdrake makes it not put any resolution info in xorg.con, right?
Keep in mind that older monitors like my 20 year old Mitsubishi Diamond Scan 20, do not support edid, so the command has a null output. [root@hodgins ~]# monitor-edid [root@hodgins ~]#
CC: (none) => davidwhodgins
Over 4 months later now, is the issue still there in current cauldron?
CC: (none) => marja11, thierry.vignaud
How would setting a default resolution for install as a fall back be, and once the system installs, re run the resolution test to check that it is right, if not, overright the default one with the newly detected one.
(In reply to comment #40) > How would setting a default resolution for install as a fall back be, and once > the system installs, re run the resolution test to check that it is right, if > not, overright the default one with the newly detected one. Thanks for your reply, thanks for trying to help, but that doesn't answer my question ;). @ Anyone who knows: Please confirm or disconfirm that the bug still exists in current cauldron, so I'll know whether this bug can be assigned to the maintainer of drakx-kbd-mouse-x11 or be closed.
Keywords: (none) => NEEDINFO
(In reply to comment #41) > > @ Anyone who knows: > Please confirm or disconfirm that the bug still exists in current cauldron, so > I'll know whether this bug can be assigned to the maintainer of > drakx-kbd-mouse-x11 or be closed. Reporter, or anyone else, could you please reply to the previous question? If you don't reply within two weeks from now, I will have to close this bug as OLD. Thank you.
Status: REOPENED => NEW
(In reply to comment #42) > (In reply to comment #41) > > > > > @ Anyone who knows: > > Please confirm or disconfirm that the bug still exists in current cauldron, so > > I'll know whether this bug can be assigned to the maintainer of > > drakx-kbd-mouse-x11 or be closed. > > > > Reporter, or anyone else, could you please reply to the previous question? If > you don't reply within two weeks from now, I will have to close this bug as > OLD. Thank you. Closing
Status: NEW => RESOLVEDResolution: (none) => OLD