Assigning to maintainer now that our maintainers database has an entry for
this package. Please assign back to bugsquad@mageia.org in case of a mistake
from me.

CC: (none) => stormi
Assignee: bugsquad => balcaen.john

I have the same thing on my HD screen, however, iof i rmember rightly, I'm pretty sure taht it refers to the resolution that the system will use for the grub screenand then at boot up until the xserver starts.
However, after the grub screen this seems to be over ridden by kms if it is enabled (which leads to bug 1332)

Does your system run with KMS enabled? And does have a low resolution grub screen really cause that much of an issue?

I will check the grub docs to see what the maximum resolution it can support is.

pinging. because nothing happened to this report since more than 3 months ago, and it still has the status NEW or REOPENED


@ Donald

Please set status to ASSIGNED if you think this bug was assigned correctly. If for work flow reasons you can't do that, then please put OK on the whiteboard instead.

CC: (none) => marja11

Ok just for the record,this bug is still effective (i just noticed it on mageia 2 beta3 where default.png is using 1024x768 instead of my correct resolution which is a 1366x768)
Using the mageia-theme-kde-background instead of default.png allows me to workaround the issue but it's not a fix (since i guess others desktop will still be affected)
I'm not using kms (fgrlx driver with a AMD Radeon HD6310 )

Hardware: x86_64 => All

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

*** Bug 5989 has been marked as a duplicate of this bug. ***

CC: (none) => mage1888

*** Bug 6047 has been marked as a duplicate of this bug. ***

CC: (none) => fri

It seems /usr/share/mga/background/ is missing images of several common screen resolutions.  Are all supposed to be there, are they supposed to be generated from one of higher resolution when needed, or downloaded, or is some close resolution to be used instead with resizing/cropping during use?

ping?

CC: (none) => alien

(In reply to Morgan Leijström from comment #8)
> It seems /usr/share/mga/background/ is missing images of several common
> screen resolutions.  Are all supposed to be there, are they supposed to be
> generated from one of higher resolution when needed, or downloaded, or is
> some close resolution to be used instead with resizing/cropping during use?

There are backgrounds provided for 1920x1440, 1920x1200, 1920x1080, 1280x1024, 1024x600 and 800x600, these are symlinked to the smaller resolution backgrounds of the same aspect ratio.

The default.png is created as a link to the background with the appropriate resolution for your screen, however, the script that does this doesn't seem to get it right.

I have no idea about how this works so I am wondering if someone with more knowledge can take over this?

To whoever takes over, there must be some method for higher resolutions also ;)
I have screens 1600x1200, 2560x1600

anything above 1920xXXXX we don't support, this needs to be addressed in MGA4.

1600x1200 is a link to 1920x1440.

*** Bug 12310 has been marked as a duplicate of this bug. ***

CC: (none) => eeeemail

GDM is the same as Icewm in bug 12310 with classic 4RC dvd default gnome installation. 4:3 background centred in GDM.

Whiteboard: MGA2TOO => 4RC

RazorQT the background appears stretched horizontally to fit the 16:9 screen.

Somebody who has knowledge of the process for setting the default background needs to step in here as I havn't been able to trace it down.

XFCE it appears stretched vertically beyond the screen limits so the logo is half hidden behind the bottom panel.

In XFCE settings it says it is using default.jpg at size 1920x1440 which would explain it really.

When the background style is set to scaled there the logo appears in correct proportions but the background is again 4:3

Could it be that it is just not creating the correct symlinks for the screen sizes?

Mate and Cinnamon are the same

In Mageia 4 with dual monitors in IceWM, the background gets centered on the border between the two screens, leaving black on the outer edges.

Assigning to Atelier and bumping the priority.

I'll have a look into this one, we need to get rid of it :-)

Assignee: watersnowrock => atelier-bugs
Priority: Normal => High
CC: (none) => remi
Whiteboard: 4RC => 5beta2

Ok, I've had a deeper look at our scripts and I've narrowed down the issue to the screen resolution detection in libDrakx::Xconfig.

CC'ing Thierry and Anssi who last worked on drakx-kbd-mouse-x11 and Angelo who knows his way around perl modules too :-)


The %posttrans for mageia-theme-Default calls:
  /usr/share/bootsplash/scripts/switch-themes Mageia-Default

Among other things, the latter executes:
  /usr/sbin/drakx-update-background

Which runs:
  Xconfig::resolution_and_depth::set_default_background($resolution);

And this one starts with:

sub set_default_background {
    my ($resolution) = @_;
    
    $resolution->{X} && $resolution->{Y} or do {
	$resolution = { X => 1024, Y => 768 };
	log::l("defaulting background resolution to $resolution->{X}x$resolution->{Y}");
    };

http://gitweb.mageia.org/software/drakx-kbd-mouse-x11/tree/lib/Xconfig/resolution_and_depth.pm#n253


Here it seems that "my ($resolution) = @_" is not retrieving the wanted X and Y values, so it defaults to 1024x768 in all cases.

It would be _awesome_ to get this fixed for Mageia 5, so I'm looking forward to some input from our perl/libDrakX experts :-)

CC: (none) => anaselli, anssi.hannula, thierry.vignaud

Silly me, the "my $(resolution) = @_" call only retrieves the resolution passed as an argument.

The issue is then one line above in /usr/sbin/drakx-update-background:

my $resolution = eval { Xconfig::xfree->read->get_resolution };

( http://gitweb.mageia.org/software/drakx-kbd-mouse-x11/tree/tools/drakx-update-background#n10 )

So it seems the issue should be investigated here:

http://gitweb.mageia.org/software/drakx-kbd-mouse-x11/tree/lib/Xconfig/xfree.pm#n155

Just for the reference, I can confirm that hardcoding my resolution in Xconfig::resolution_and_depth::set_default_background does work around the issue of the background that appears at boot time between plymouth and the DM.

As advised by Angelo, I added a Data::Dumper call to get the value of the $resolution variable, and it does lack X and Y components:

$VAR1 = {
          'automatic' => 1,
          'Depth' => undef
        };

I wrote a silly test file getting resolution from ModeLine:
http://pastebin.com/pQGvbKkC

I don't know if it's the right way to, and of course that gets only the first
monitor configuration, but it could be better managed to eventually fix
get_resolution and get_resolutions

could it be that the resolutions don't work when there is no X.org file as there is normally no need for a real config file?)

is that were the trouble lies?

@Angelo: your script looks not much different from the code, tbh... what's the difference that yours work and this doesn't?

@AL1EN at first looking maybe :) but as far as I understood get_resolution looks for sections and subsections that are not in xorg.conf (at least I haven't seen them since a lot of time, such as Display, Modes, Virtual etc.)
I looked for ModeLine instead

Next simple variant of the scripst:
######
use lib qw(/usr/lib/libDrakX);
use Xconfig::xfree;
use Data::Dumper;

my $resolution = Xconfig::xfree->read->get_resolution;

print Dumper($resolution);
######
can be run in a system that has xorg.conf and the result is the same as in comment #23 e.g.:
VAR1 = {
          'Depth' => undef,
          'automatic' => 1
        };

In any case iirc the fallback 1024x768 resolution is set as said in comment#21 and comment #22
my $resolution = eval { Xconfig::xfree->read->get_resolution };
Xconfig::resolution_and_depth::set_default_background($resolution);

if the first call to get fails the second one to set looks for X and Y fields and
if they are not defined (both) sets the default resolution.

maybe it's better to use xset to get the current resolution?

allthough it looks like it's trying to get the defined resolution which means it's getting it while X is inactive?

so, i get this correctly, no matter if x.org is defined or not, you don't get X and/or Y.

so the modeline script doesn't work either? did any of the scripts work at this point? i thought with comment 24 , it got resolution?

perhaps you could print Dumper($Screen) at http://gitweb.mageia.org/software/drakx-kbd-mouse-x11/tree/lib/Xconfig/xfree.pm#n165 

to find out if the $Display was found and if $depth can be found or if there are no modelines...

perhaps test this with both xorg.conf file and without it?

hmm, at home i don't have any "Screen" sections. But i thought here at office as well. But now it's in, and the script (comment #26) works now, so i guess also
for this bug should work. e.g. with no changes.

I wonder if it is related to the today xorg update (at least in mga4).

Into my virtualbox cauldron VM i have:
Section "Screen"
    Identifier "screen1"
    Device "device1"
    Monitor "monitor1"
EndSection

Display and related subsection Modes are not in.

@angelo:

you mean that *with* a screen section it works (and without it doesn't), no matter if there's any modes in?

have you been able to add these Dumper thingies?

also, maybe a better approach is to have always a 1024x768 one after install and during X startup a script that:

# get xset resolution for each screen
# get /etc/sysconfig/resolutions
# if configured, check for each screen if current resolution matches
# if not matched, or unconfigured, store the current resolutions and also resymlink the correct background.

wouldn't that be more robust?

perhaps this script could be set early during X start when background isn't shown yet?

or... maybe udev gets a resolution change hook via dbus? and we could use this to trigger the background change?

perhaps an easy way to fix this is to have background be SVG... that way the resolution is never wrong...

CC: (none) => atelier-bugs

if that isn't possible...

perhaps it's a better/easier solution if we put an extra script in the beginning of prefdm, so that it can use xset to have the current resolution and resymlink the correct one.

if resolution later changes, at least that would be adaptable...

make a small script:

#!/bash

res=$( xrandr | grep primary | awk '{print $4}' )
res=${res%%+*}
pushd /usr/share/mga/backgounds
if [[ -f "Mageia-Default-$res.jpg" ]]; then
        ln -sf "Mageia-Default-$res.jpg" Default.jpg
fi
popd


and have the first lines of /etc/X11/prefdm execute that one.

that should always fix the problem, since xrandr is always installed.

(it works with multiple monitors, it uses the primary one)

@AL13N I thought we needed a perl code to manage it :)  
anyway xrandr seems to give a valid value. I don't know if it is also valid for VirtualBox though.

As reported by luigiwalser, this bug also affects the background in IceWM (and maybe other WMs that do not override this default setting of 1024x768).

Just to add to what Remi said, this affects anything that takes default.jpg as the image to display.

CC: (none) => watersnowrock

ok, so is the small script ok? can we do this to fix all problems?

@anaselli & others: someone else test it like this?

The script could do, but if we can, it would be better to fix libDrakX; the problem does not happen only when setting the background after installing mageia-theme-Default, but also when using XFdrake apparently.

As far perl modules that could be of help, I found:
http://search.cpan.org/~bidulock/X11-Protocol-More-0.05/lib/X11/Protocol/Ext/RANDR.pm

I guess a solution could be to use xrandr's output directly in libDrakX? Provided it's installed and running also on the install ISOs. Maybe a simplified version of: https://github.com/jamesronan/Misc-Tools/blob/master/xrandr_autoconfig.pl
(The main interest over AL13N's workaround being that there would not be a script called at each boot, but only when configuring the display).

Source RPM: mageia-theme => drakx-kbd-mouse-x11-1.4-1.mga5

I should note that starting an X session triggers the script, which means logout would trigger it.

you do have a point that the code is used by XFdrake too, except that after running XFdrake, (which one has to run when X is stopped), starting X also triggers this code.

it doesn't matter to me, i just figured this quick script could fix all that.

fixing libDrakX would be nice, but the problem is that i don't see it, the code looks good actually, and introducing another dependency... i don't know...

How about running the xrandr binary in libDrakX? (i.e. added the equivalent of your bash script directly in the perl code, to run it only when necessary).

that won't actually work when running XFdrake, cause then there's no X to check the resolution from.

it appears the libDrakX gets it from config file, but config file these days is sometimes non-existant.

I propose to run it during X startup, which means that reconfiguring X will also trigger this.

the overhead of starting this every X startup is small it's just a few microseconds.

imho it's a much better idea to check the actual resolution when X is starting, rather than checking the config up front, when the config doesn't matter much anymore.

it doesn't look like there's a better working idea, so if you want to have a working mga5, we might as well do this. at least it'll work, and if people complain, they can fix it in another way.

i propose for now to put this code in the X startup before anything is shown, so that at least the background is shown properly. It's better than doing nothing.

maybe it would be even better to get rid of the resolution check in libDrakX, so that there's no interference, but perhaps it's safer to leave it in for now.

@Remi, I think that adding a new dependency could be wrong, you need to ask to whom work at install stage if it can be done.

@ALI3N i don't like the idea to patch X startup script, if our tools fail i think we have to fix our tools not to change upstream one to work with our failures :D

@Akien while i generally agree, i think that trying to get resolution from config (while X is not running) is not a good idea anymore, since configs are getting more an more dynamic.

iow: i think the approach is not good anymore.

the real way to fix this is for every DE seperately for every monitor attached to hook something in order to get the correctly sized background for every type of monitor resolution (on every resolution change).

as a fallback, i think X startup to get the primary monitor's background on the correct size is the best way to get the most correct results.

especially since resolutions change not only during configuration.

in time, i would propose to get rid of the X resolution code grabbing from config, which (as a bonus) will actually loosen up some requirements, possibly making basesystem-minimal a bit smaller. (i wouldn't do it now)

> imho it's a much better idea to check the actual resolution when X is starting, rather than checking the config up front, when the config doesn't matter much anymore.

You have a point :-)
I just wonder whether your script would not conflict with custom user settings, i.e. if a primary monitor has a resolution of 1920x1080, but the user chose on purpose 1600x900 using XFdrake. In this case XFdrake would probably set the correct default.jpg, but I wonder what your script would do?

It seems that the configured resolution is indicated by *+, so maybe it would be better to do:
res=$(xrandr | grep *+ | awk '{print $1}')

anyway it isn't that good idea, and Col would probably be unhappy but we can run xrandr into our perl script, and if we want to leave the door open to RANDR.pm evaluate if it can be loaded and use it in the case or run xrandr directly...
Just a thought

the problem with that approach is that you'll be getting the current resolution and not the configured one if you want a new different resolution

@Akien the script doesn't conflict at all, it just changes the background at X start time. if the configured resolution doesn't work and it gets a different one, you still end up with one that fits the monitor.

@AL13N but if the configuration you change is not working who really cares about
a right background for the fallback configuration? 

Then I see:
1. I'm configuring X with a specific configuration (our script can read from
   xorg.conf the size) and bg could fail if the configuration is wrong (but there
   is a test before accepting the conf).
2. default configuration data are not found in xorg,conf (hope a day dbus will
   have also this kind of configuration) and we can try xrandr way

Shouldn't that work for the most? Did i miss any other cases?

xrandr can only be used if X is running and it will give the current resolution, ie: the one before the change.

if you're using XFdrake without X, it won't work at all.

plus that would be ok-ish, but it seems that even in the regular case where and X config is set, that somehow doesn't work.

imho the approach of just checking X resolution when you actually start X, seems to be a better approach, and it only doesn't handle dynamic changing of resolutions, but that's something for DE's to handle anyway.

in fact, i can't really see any comment and the current approach doesn't work anyway... so, i'm kinda tired of too much talk and less action, so i'm just gonna do it my way, and if anyone finds a better way, they can do the change...

Making this one release blocker, we need to get rid of it.

Priority: High => release_blocker
Summary: mageia-theme-Default defaulting background to wrong resolution (also kdm) => libDrakX defaulting background to wrong resolution (also affects mageia-theme-Default and kdm)

Unassigning Atelier since it's clearly something that needs to be fixed in libDrakX or via a script.

Assignee: atelier-bugs => bugsquad
QA Contact: (none) => atelier-bugs

Well i don't know if installer has hwinfo installed but 
hwinfo --monitor
33: None 00.0: 10002 LCD Monitor                                
  [Created at monitor.95]
  Unique ID: rdCR.7Lnh6Fwg2O8
  Hardware Class: monitor
  Model: "SAMSUNG SMBX2335"
  Vendor: SAM "SAMSUNG"
  Device: eisa 0x0702 "SMBX2335"
  Serial ID: "H9MZ600710"
  Resolution: 720x400@70Hz
  Resolution: 640x480@60Hz
  Resolution: 640x480@67Hz
  Resolution: 640x480@72Hz
  Resolution: 640x480@75Hz
  Resolution: 800x600@56Hz
  Resolution: 800x600@60Hz
  Resolution: 800x600@72Hz
  Resolution: 800x600@75Hz
  Resolution: 832x624@75Hz
  Resolution: 1024x768@60Hz
  Resolution: 1024x768@70Hz
  Resolution: 1024x768@75Hz
  Resolution: 1280x1024@75Hz
  Resolution: 1280x960@60Hz
  Resolution: 1280x1024@60Hz
  Resolution: 1920x1080@60Hz
  Size: 510x287 mm
  Detailed Timings #0:
     Resolution: 1920x1080
     Horizontal: 1920 2008 2052 2200 (+88 +132 +280) +hsync
       Vertical: 1080 1084 1089 1125 (+4 +9 +45) +vsync
    Frequencies: 148.50 MHz, 67.50 kHz, 60.00 Hz
  Driver Info #0:
    Max. Resolution: 1920x1080
    Vert. Sync Range: 56-75 Hz
    Hor. Sync Range: 30-81 kHz
    Bandwidth: 148 MHz
  Config Status: cfg=new, avail=yes, need=no, active=unknown

34: None 00.1: 10002 LCD Monitor
  [Created at monitor.95]
  Unique ID: jyhG.7Lnh6Fwg2O8
  Hardware Class: monitor
  Model: "SAMSUNG SMBX2335"
  Vendor: SAM "SAMSUNG"
  Device: eisa 0x0702 "SMBX2335"
  Serial ID: "H9MZ600710"
  Resolution: 720x400@70Hz
  Resolution: 640x480@60Hz
  Resolution: 640x480@67Hz
  Resolution: 640x480@72Hz
  Resolution: 640x480@75Hz
  Resolution: 800x600@56Hz
  Resolution: 800x600@60Hz
  Resolution: 800x600@72Hz
  Resolution: 800x600@75Hz
  Resolution: 832x624@75Hz
  Resolution: 1024x768@60Hz
  Resolution: 1024x768@70Hz
  Resolution: 1024x768@75Hz
  Resolution: 1280x1024@75Hz
  Resolution: 1280x960@60Hz
  Resolution: 1280x1024@60Hz
  Resolution: 1920x1080@60Hz
  Size: 510x287 mm
  Detailed Timings #0:
     Resolution: 1920x1080
     Horizontal: 1920 2008 2052 2200 (+88 +132 +280) +hsync
       Vertical: 1080 1084 1089 1125 (+4 +9 +45) +vsync
    Frequencies: 148.50 MHz, 67.50 kHz, 60.00 Hz
  Driver Info #0:
    Max. Resolution: 1920x1080
    Vert. Sync Range: 56-75 Hz
    Hor. Sync Range: 30-81 kHz
    Bandwidth: 148 MHz
  Config Status: cfg=new, avail=yes, need=no, active=unknown

35: None 00.2: 10002 LCD Monitor
  [Created at monitor.95]
  Unique ID: aHB6.7Lnh6Fwg2O8
  Hardware Class: monitor
  Model: "SAMSUNG SMBX2335"
  Vendor: SAM "SAMSUNG"
  Device: eisa 0x0702 "SMBX2335"
  Serial ID: "H9MZ600710"
  Resolution: 720x400@70Hz
  Resolution: 640x480@60Hz
  Resolution: 640x480@67Hz
  Resolution: 640x480@72Hz
  Resolution: 640x480@75Hz
  Resolution: 800x600@56Hz
  Resolution: 800x600@60Hz
  Resolution: 800x600@72Hz
  Resolution: 800x600@75Hz
  Resolution: 832x624@75Hz
  Resolution: 1024x768@60Hz
  Resolution: 1024x768@70Hz
  Resolution: 1024x768@75Hz
  Resolution: 1280x1024@75Hz
  Resolution: 1280x960@60Hz
  Resolution: 1280x1024@60Hz
  Resolution: 1920x1080@60Hz
  Size: 510x287 mm
  Detailed Timings #0:
     Resolution: 1920x1080
     Horizontal: 1920 2008 2052 2200 (+88 +132 +280) +hsync
       Vertical: 1080 1084 1089 1125 (+4 +9 +45) +vsync
    Frequencies: 148.50 MHz, 67.50 kHz, 60.00 Hz
  Driver Info #0:
    Max. Resolution: 1920x1080
    Vert. Sync Range: 56-75 Hz
    Hor. Sync Range: 30-81 kHz
    Bandwidth: 148 MHz
  Config Status: cfg=new, avail=yes, need=no, active=unknown

Though on virtualbox:
hwinfo --monitor
19: None 00.0: 10000 Monitor                                    
  [Created at fb.71]
  Unique ID: rdCR.EY_qmtb9YY0
  Hardware Class: monitor
  Model: "Generic Monitor"
  Vendor: "Generic"
  Device: "Monitor"
  Resolution: 800x600@75Hz
  Driver Info #0:
    Max. Resolution: 800x600
    Vert. Sync Range: 50-90 Hz
    Hor. Sync Range: 31-48 kHz
  Config Status: cfg=new, avail=yes, need=no, active=unknown

I don't get as much info as you do:

# hwinfo --monitor
27: None 00.2: 10002 LCD Monitor                                
  [Created at monitor.95]
  Unique ID: aHB6.kFPaWnDZ447
  Hardware Class: monitor
  Model: "LG Display LCD Monitor"
  Vendor: LGD "LG Display"
  Device: eisa 0x0259 
  Resolution: 1920x1080@60Hz
  Size: 345x194 mm
  Detailed Timings #0:
     Resolution: 1920x1080
     Horizontal: 1920 1968 2000 2080 (+48 +80 +160) -hsync
       Vertical: 1080 1083 1088 1111 (+3 +8 +31) -vsync
    Frequencies: 138.50 MHz, 66.59 kHz, 59.93 Hz
  Config Status: cfg=new, avail=yes, need=no, active=unknown

(no max resolution)

Maybe it's bios related? I see hwinfo talking about bios something when it's started.

Try the following:

find /sys -name edid
# find the one for your monitor, let's call it EDID_FILE
monitor-parse-edid < $EDID_FILE

This is drakx stuff so if it does not work it could explain why you don't get a correct resolution.

I get lots of "Use of uninitialized value" for my amp (followed by a list of modes). No errors on the computer monitor's edid.

CC: (none) => cjw

on comment #57 Christiaan, the idea could be good if were sure that the way to retrieve it works for all.
Anyway looking for proc file info i got:
find /sys -name edid
/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-1/edid
/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-VGA-1/edid
/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/edid
/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-1/edid
So which is the right one to use? i have two monitors connected, which is the primary one?
Again if i have to leave the user the decision, better not to set background here and providing a tool to do that when X is started using at that point xrandr maybe.

i looked into using xrandr, and got the proper resolution, of the correct primary monitor (even in dual monitor setups), but i hit a snag...

the problem is that i had ran this script in xinit.d/ ... but apparently this gets run by X start (at login time) but AFTER privileges are dropped to the regular user... which means that the script doesn't have the right to change the default.jpg symlink... :-(

i first tried to resolve this with pkexec but when doing autologin, systemd actually starts polkit.service later than it's starting X...

so, i tried to make the helper script input resolution secure and tried with suid root... but that didn't seem to work for some reason... it was still executed with the normal user...

I asked at #xorg if there was a script that was executed BEFORE it dropped privileges, but i didn't get an answer...


so, i was nearly there... but not completely... :-(

ok, i have a PoC working! finally.

Luigi told me that setuid doesn't quite work for scripts, so i wrote a small C program that could change the default.jpg symlink given a resolution.

i'll put this and a /etc/X11/xinit.d/ script into a package and submit it to the buildsystem. this tiny package will have to be installed in the basic install, but it does mean that at X startup (login time) before the DE actaully starts, the resolution is fit to the correct resolution of the primary connected display.

this means that even if your X doesn't have a config file, it will still work.

Sounds great.  Have a nice beer now!

ok, so i put everything in a package:

mga-bg-res

can some people try to install this and see if this works in all environments with all types of screens?

ie: laptops with external sources/dual monitor/TV connected/etc...

if several people report this as ok, then it's time to put this in the isos and have mageia-theme-Default require or suggest it and then make sure it ends up on the isos...

Awesome! I'll give it a try now.
Once the fix is confirmed, it should probably be added as a Requires to libDrakX/Xfree directly (i.e. drakx-kbd-mouse-x11)

I tested mga-bg-res on my laptop. It worked fine to change the symlink after the first boot, but it was not fast enough to prevent displaying the wrong background the first time. All subsequent boots have the good resolution since the symlink has been fixed.

I'm not sure if we can do better than that though, it seems pretty hard to run something before the X server has started that relies on xrandr. But you reduced the systematic bug to a first-boot issue, and IMO that's already great :-)

I made some tests using virtualbox, with a non fullscreen mode the size could 
have no corresponding jpg for background so no link is created and the old one 
left. Fullscreen mode worked instead.

On comment #63 Rémi i'm not sure it should be related to drakx-kbd-mouse-x11 because no changes have been added to our tools. This tool should be related
more to X or our theme, since it change the link on X startup.

On comment #64 for first boot again, I'm not sure it works, since the bg is changed on X startup, and if I'm not mistaken seen on the next one.

ah shit, and i had hoped to have gotten this right...

maybe if we made a wrapper around the DE startup scripts, like, instead of:

/usr/bin/startkde => /usr/bin/startDE /usr/bin/startkde

maybe that would be certain to be before the DE startup? not sure if this would be easy, i'm not certain if X is started inside startkde or before it... (i fear the first one)

i asked around for other X startup stuff that would be earlier, but there isn't any...

there should be some code that uses inotify in some DE's that would handle a diff file, but i guess it doesn't work for symlinks...

on top of that, there is not a good way to handle a DE wrapper either...

i looked into getting info via dbus (even X startup would be nice), but that's not happening either...

thinking about this...

perhaps it might work if we do a hardlink change... then inotify would kick in and maybe a few DE's would change the background on the fly...

looking more into this... it seems KDE would not be affected, since it uses a different schema:

[alien@localhost ~]$ ls /usr/share/wallpapers/Mageia/contents/images/ -lshatr
totaal 28K
4,0K lrwxrwxrwx 1 root root  54 apr 18  2014 800x480.png -> ../../../../mga/backgrounds/Mageia-Default-800x480.png
4,0K lrwxrwxrwx 1 root root  56 apr 18  2014 2560x1920.png -> ../../../../mga/backgrounds/Mageia-Default-2560x1920.png
4,0K lrwxrwxrwx 1 root root  56 apr 18  2014 1920x1440.png -> ../../../../mga/backgrounds/Mageia-Default-1920x1440.png
4,0K lrwxrwxrwx 1 root root  56 apr 18  2014 1920x1200.png -> ../../../../mga/backgrounds/Mageia-Default-1920x1200.png
4,0K lrwxrwxrwx 1 root root  56 apr 18  2014 1920x1080.png -> ../../../../mga/backgrounds/Mageia-Default-1920x1080.png
4,0K lrwxrwxrwx 1 root root  56 apr 18  2014 1280x1024.png -> ../../../../mga/backgrounds/Mageia-Default-1280x1024.png
4,0K lrwxrwxrwx 1 root root  55 apr 18  2014 1024x600.png -> ../../../../mga/backgrounds/Mageia-Default-1024x600.png


how is this for gnome and others?

perhaps we can fix this better in the DE's themselves?

if KDE and Gnome are not affected, at least the live is safe and we can still have this fallback with xrandr... that should at least drop it's priority...

Yeah KDE and GNOME seem to find out about the screen resolution by themselves, and then they use the proper wallpaper. If this bug has been there for so long it's precisely because most DEs handle the resolution themselves, and the only symptom of the bug was the 1024x768 background before the start of the DMs.

So there will still be an issue with KDM on the first boot, but it's no big deal IMO. I don't know for GDM, I'd have to test.

ah, you mean the dm's, not the DE's...

anyone agree to have mageia-theme-Default require mga-bg-res and drop priority?

(In reply to AL13N from comment #71)
> anyone agree to have mageia-theme-Default require mga-bg-res and drop
> priority?

Fine by me :)

the new mageia-theme-Default is uploading now...

decreasing priority...

Assignee: alien => bugsquad
Priority: release_blocker => Normal
Status: ASSIGNED => NEW

Um..??
Updated my laptop now, it pulled 17 updates including this, wrote five lines
  defaulting background resolution to 1024x768
which is completely wrong
And on next boot i got just a black hang after grub.
Power off/on and all is OK.

This screen is 1920x1200, highest resolution variant of Thinkpad T61p.
Interestingly the lowest resolution variant of same machine is 1024 x 768.
http://support.lenovo.com/en/documents/pd008989

> Updated my laptop now, it pulled 17 updates including this, wrote five lines
>  defaulting background resolution to 1024x768

Yep, that's what this very bug is about. We decreased the priority since there is now a workaround that will correct libDrakX's wrong detection of your screen resolution (first boot might show the 1024x768 before the DM, but it should be fixed afterwards).

> And on next boot i got just a black hang after grub.
> Power off/on and all is OK.

That's an unrelated issue IMO, though I can't tell for sure. The only change brought by this update was to add a mga-bg-res binary that gets run *after* the plymouth animation (i.e. before/during X server startup) to workaround bug 763.

This is still not a proper fix, that's why the bug is still open, but it should not cause a hang after grub, it's not supposed to intervene there.

The current implementation is not sufficient, because it expects to find an image which exactly the same resolution as the one taken from xrandr.

But actually the /usr/share/mga/backgrounds folder contains one background per image ratio (actually two for 1.33, but that's a mistake IMO):

Mageia-Default-1024x600.jpg    => 1.7067
Mageia-Default-1280x1024.jpg   => 1.25
Mageia-Default-1920x1080.jpg   => 1.7778
Mageia-Default-1920x1200.jpg   => 1.6
Mageia-Default-1920x1440.jpg   => 1.3333
Mageia-Default-2560x1920.jpg   => 1.3333
Mageia-Default-800x480.jpg     => 1.6667


So here for example in VBox, my display is 1280x960.
The result of mga-bg-res 1280x960 is: "No image for this resolution."

But this resolution is 1.3333, so it should use 1920x1440 or 2560x1920.

Assignee: bugsquad => alien

i don't know if convert is available during installer, but we could provide a single svg and convert it to the right size and format...

Nope, the background can't be made into an SVG, it's not a vector drawing. And resizing means changing the aspect ratio of the Mageia logo, and that's not good, that's why we provide hand-edited backgrounds for each aspect ratio.

We just need to calculate the ratio, and then get the first jpg in the list for which the width/height ratio corresponds to what we're looking for (only if the native resolution is not available, to prevent useless computation).

IIRC that's just what libDrakX does after the step where is fails to retrieve the good resolution.

I didn't mean that i mean exactly to convert the svg to jpg with the right
size
form convert manual
convert  -  convert  between  image  formats as well as resize an image, blur, crop, despeckle, dither, draw on, flip, join, re-sample, and much
       more.

But which SVG?

theorethically it's possible to have a .svg (if the designer works like that) and generate a png when a new resolution is chosen...

anyway, with virtualisation any kind of resolution is possible.

but don't forget, the real fix is that the program itself (DE's or DM's) pick the right resolution...

KDE does this, i've seen it, they don't look at the default.jpg file

Gnome should have something similar

but i don't know if kdm or gdm use this or not.

anyway, i'm done with this, priority is lower, there's a bunch of higher priority bugs.

nothing is perfect, and if you want it differently, you're gonna have to code for this, but preferably after mga5 release...

There's nothing to code differently, I just say that you can just grab the output of xrandr and then find out that there is no pre-processed background image for this given resolution.

It's not that hard to add a for loop to pickup the right resolution among the pre-processed images that we provide in /usr/share/mga/backgrounds.

But I guess I'll do it if you don't find it relevant.

(Just in case you misunderstood me:)

What libDrakX does theoretically when it finds the correct resolution, is to create a symlink that points to the premade image with the same *aspect ratio* (because the same resolution is not always available).

For example the current broken libDrakX defaults to a resolution of 1024x768, and since there is no Mageia-Default-1024x768.jpg picture, it uses the 1920x1440 version that has the same *aspect ratio*.

What I'm saying is that with mga-bg-res, we do the first step but forget the second one, and therefore it's useless in all cases where the user has a support aspect ratio which is not precisely the same resolution.

Then the DM or DE resizes the background to the correct resolution without any problem, but it's important to pick the correct aspect ratio.

Anyway, I'm on it.

I propose to replace /etc/X11/xinit.d/01mga-bg-res by this script:
https://framalab.org/zerobin/?4cf7d6b2b94cc356#oL21FvqiVnWGPKpLJsVQLkAlqWX91Q3FNh6G1hGvh90=

WDYT? It's a bit overkill to have to loop through all wallpapers at each boot, but at least it should work.

Could it somehow put a note to itself what worked last time and try that first?

> Could it somehow put a note to itself what worked last time and try that first?

Yeah I thought about something like that too. And then I thought that I simply need to provide a kind of array with the aspect ratio precomputed, and choose the right combination according to the xrandr resolution.

That would prevent a for loop on all files (the drawback is that if we change the "default" resolutions, we'll have to update the script, but anyway the theme name is hardcoded now so it's already quite dirty ;-)).

Here's a somewhat more elegant implementation using an associative array:
https://framalab.org/zerobin/?7e4cab4a7d92f8ff#KdJuW4z/GmI+3Ge1k7Ty+35/aE3a1zs1AiQiSm9/4sw=

good luck, you can just change the code ... oh wait...

/me sighs

colin needs to provide me a git repos so i can put all of it on there... :-(

another solution would be to provide more resolutions...

(In reply to AL13N from comment #89)
> another solution would be to provide more resolutions...

You still don't understand. If your screen ratio is 1.333 with a resolution of 1024x768, you have to use Mageia-Default-2560x1920.jpg which also has a resolution of 1.333. And that's _fine_. It will scale down to 1024x768 perfectly.
We've always done like this, I don't see the point in providing more resolutions.

> colin needs to provide me a git repos so i can put all of it on there... :-(

I told you to put the code in http://gitweb.mageia.org/software/design/theme/ that's the most relevant place for it IMO, since it's *meant* to be used with mageia-theme.

I pushed a version 0.3 with this modified xinit script: https://framalab.org/zerobin/?32cf73910d94b8f2#ZCdgDQN1kWACJdF3AgWdLCYOnpeHQZkqPutyTlf/w+c=

It should hopefully cater for most cases. The only possible drawback could be that if you have a desktop with a huge resolution that happens to have the same aspect ratio as Mageia-Default-1024x600.jpg (1.701 = 128/75) or Mageia-Default-800x480.jpg (1.667 = 5:3), you might end up with a low-res background.

But those two aspect ratios does not seem standard at all: http://en.wikipedia.org/wiki/Display_resolution#Current_standards

Though I see that 1280x768 would have an aspect ratio of 5:3 too... I'll see with Anne if she remembers the rationale behind the current set of resolutions that we provide, and if it could be changed.

(I comment without reading the code)
If we select the resolution with closest ration match we do the best we can on all old, odd, and future resolutions.  And tolerate for roundup errors.

i understood perfectly 

i don't quite agree that that is the perfect place for it, but sure...

do you want me to push my code? or, since you're working on it already, are you gonna push yours directly?

Pascal said:
<pterjan> if it's not part of the theme it should go somewhere else

So I asked coling to create a mga:software/design/mga-bg-res git repo.
Once it's done, maybe you can commit version 0.2 in the repo, and then I'll commit my patch for version 0.3 (and a version 0.4 that I have been working on locally), so that we have some history :)

just a thought to release that to theme. A new package has been added. Such a commit means changing the another package instead. Are we sure that is ok?

I'm not sure I understand, but finally my proposal is to put it in mga:software/design/mga-bg-res (i.e. not in the mga:software/design/theme repo, but in its own repo). It will be easier to keep track of versioning.

@AL13N: I just thought about something: what if we used /usr/sbin/drakx-update-background instead of writing our own hack in C to change the symlink?

Currently drakx-update-background is:

#-----------
#!/usr/bin/perl

use lib qw(/usr/lib/libDrakX);
use common;
use Xconfig::xfree;
use Xconfig::resolution_and_depth;

require_root_capability();

my $resolution = eval { Xconfig::xfree->read->get_resolution };
Xconfig::resolution_and_depth::set_default_background($resolution);
#-----------

Maybe we could change it to accept an optional argument (the resolution) that would bypass "my $resolution = eval { Xconfig::xfree->read->get_resolution };" and call Xconf::resolution_and_depth::set_default_background with our optional argument?

This was all my hack in the xinit script would become obsolete, since it's just reimplementing what libDrakX already does when it gets the proper resolution as an argument.

So the xinit script could be:

#-----------
#!/bin/sh

res=$( xrandr | awk '/\sconnected/{i=split(substr($0,0,index($0,"+")-1),a);if($0~/\sprimary\s/){if(p==""){p=a[i]}}else{if(d==""){d=a[i]}}}END{if(p==""){print d}else{print p}}' )

/usr/sbin/drakx-update-background $res
#-----------

And voilà!

why not

that should be a good idea...

there is one problem though, how does drakx-update-background get it's root capability?

i tried with policykit at first, but it didn't work, because at the time of execution, policykit.service wasn't started.

that's why mga-bg-res is setuid.

(btw: mga-bg-res is not actually a hack, the code itself is pretty clean and simple.)

also, i chose C at the time, so that i could make it very light (it's just a few glibc function calls), since it was gonna be run at every X startup, and i didn't want to delay anything further.

of course, i didn't take into account the resolution matchings and such which are gonna slowdown anyway.

i'm not certain how this would work, but if this also works and is quick enough and works, even if it's on an autologin bootup (i tested with sddm), then i guess it's less different code to maintain and thus better.

since you took over, it's essentially your choice...

anyway, if you want my original code in the git, i'll do it.

also, imho we spend way too much time on this bug and not enough on the release_critical ones... my point was to get a simple fix in it that was good enough to at least drop this bug from release_critical state and so that people can do something else...

(In reply to AL13N from comment #100)
> also, imho we spend way too much time on this bug and not enough on the
> release_critical ones... my point was to get a simple fix in it that was
> good enough to at least drop this bug from release_critical state and so
> that people can do something else...

I agree, but we need to have something that works nevertheless for most resolutions.

(In reply to AL13N from comment #99)
> there is one problem though, how does drakx-update-background get it's root
> capability?

I guess with this call: require_root_capability();

> (btw: mga-bg-res is not actually a hack, the code itself is pretty clean and
> simple.)

Yes I did not mean that your code was a hack, but the whole workaround to bug 763 is a hack IMO. And actually what libDrakX did was also kind of hack, so we're replacing a broken hack by a working hack ;-) It's just a shame that ours will be run at each boot even when it's not needed, so IMO finding a better solution for this will be in the release schedule for mga6.

Here's my proposed patch to /usr/sbin/drakx-update-background:


--- /usr/sbin/drakx-update-background   2015-02-11 16:58:40.000000000 +0100
+++ /usr/sbin/drakx-update-background2  2015-02-13 22:30:20.493423369 +0100
@@ -7,5 +7,11 @@
 
 require_root_capability();
 
-my $resolution = eval { Xconfig::xfree->read->get_resolution };
+# The optional arguments are expected to be the screen width and height
+if (defined $ARGV[0] and defined $ARGV[1]) {
+  $resolution = { X => $ARGV[0], Y => $ARGV[1] };
+}
+else {
+  $resolution = eval { Xconfig::xfree->read->get_resolution };
+}  
 Xconfig::resolution_and_depth::set_default_background($resolution);



And then the xinit script:

#------------
#!/bin/sh

res=$( xrandr | awk '/\sconnected/{i=split(substr($0,0,index($0,"+")-1),a);if($0~/\sprimary\s/){if(p==""){p=a[i]}}else{if(d==""){d=a[i]}}}END{if(p==""){print d}else{print p}}' )
width=$(echo $res | cut -f1 -d"x")
height=$(echo $res | cut -f2 -d"x")

/usr/sbin/drakx-update-background $width $height
#------------


I've yet to try it live and confirm that it works though.

Running the xinit script as root works fine, but indeed it does not seem to work at boot time, so I guess it doesn't get root capability... :-/

indeed require_root_capability just checks if you have the root capability:
return if $::testing || !$>; # we're already root

AL13N tried to use a script file for setting it but he could not get either run it in suid of course or get the root rights, that's why he decided to work in C.

@Akien: it's not that we not need to make everything working, it's just that, i would leave this as as (except for possibly getting aspect ratio right.

after speaking with #xorg people, the REAL fix here, is to fix all DE's and DM's that are broken (ie: fetch the proper resolution image on their own). some of the DE's at least should have this working, (or can be configured like that)

list of working software:
 - KDE4 (and KF5/plasma)
 - Gnome3 should have this for a while now
 - thus possibly mate and cinnamon too
 - KDM is becoming obsoleted, so would shouldn't care about that one..
 - ...


this would mean there is no need for a "default.jpg" symlink in the first place

so, we should get the aspect ratio correct, and then leave this bug for mga6 and list ALL the DMs and DE's (possibly in different BZs and have them blocking this one... in order to get it fixed for real.

(In reply to AL13N from comment #105)
> @Akien: it's not that we not need to make everything working, it's just
> that, i would leave this as as (except for possibly getting aspect ratio
> right.
> 
> after speaking with #xorg people, the REAL fix here, is to fix all DE's and
> DM's that are broken (ie: fetch the proper resolution image on their own).
> some of the DE's at least should have this working, (or can be configured
> like that)
> 
> list of working software:
>  - KDE4 (and KF5/plasma)
>  - Gnome3 should have this for a while now
>  - thus possibly mate and cinnamon too
>  - KDM is becoming obsoleted, so would shouldn't care about that one..
>  - ...
> 
> 
> this would mean there is no need for a "default.jpg" symlink in the first
> place
> 
> so, we should get the aspect ratio correct, and then leave this bug for mga6
> and list ALL the DMs and DE's (possibly in different BZs and have them
> blocking this one... in order to get it fixed for real.

This report doesn't depend on any (such) bug report, so it seems none of this was done. However, I guess we have more severe issues to care about for Mga6.... should we leave this one for Mga7?

Another thing is, this bug report is way too long. Would anyone be willing to clone it and put all needed information in the description of the new bug (or bug/tracker)?

Assignee: bugsquad => pkg-bugs

Closing as I believe we have everything that default.jpg interacted with fixed and also most of the scaling issues.

If there are others left, so as Marja suggests and open new ones

Status: NEW => RESOLVED
Resolution: (none) => FIXED