Xsplash image sized to suit gdm screen, not user session

Curiously, now xsplash's image is centered in the screen, leaving a wide border of light grey around it.

xsplash version is the same. Seems like some times it's placed at top-left, but more of the time it's centered on creen. How odd.

Ermm, well, all of the above applies: After login, xsplash image first goes to left-top corner, then becomes centered on screen.

Sorry for so many rectifications, seems I can't think clearly these hot days :-)

This should already be fixed in bzr. We'll try to get a new release out soon. I'll keep this bug open until then so you can hopefully comment and let me know if it is indeed fixed.

Many thanks for fixing this!

I'll report on the fixes when your release is available.

The new release came out today, so once you've had a chance to update xsplash I would appreciate any reports on this one. Thanks very much Eduardo!

Hi, this is with xsplash 0.6-0ubuntu1 (after updating the system tonight).

Things seem to have improved. I'll try to describe the steps in my PC from GDM to Gnome session fully loaded (I'll make a video of it too).

After choosing user and typing password, xsplash shows its image (the default background in Karmic) in 1024x768 resolution (that of gdm screen).

After 2-3 seconds screen goes black and inmediately adopts session's resolution of 1152x864. Background image is still 1024x768, so it goes left-top aligned in the screen, leaving stripes of black at right and bottom of screen (the parts not covered by the image).

Then, after a moment, those black strips get painted in somewhat a similar color to the background image (though it's still discernible the image and the stripes of color).

After another few seconds, gnome's panels appear, then session's background image is painted by nautilus, and after 1 second or so this image is replaced by a solid light grey color (same as that of panels).

Desktop continues loading, and after 2 or 3 seconds background image reappears, with a nautilus window I usually keep open (restores session), and I think desktop loading is finished.

Sorry if this is confusing. I'll make a video of it with my photo camera, so that you can judge better what happens.

Hmm, that's unfortunate that your session resolution is changing. We need to find someone who might know why that is happening, as that's definitely not desirable. Once X11 starts we should be staying in the same resolution the whole time.

That said, xsplash should be able to handle this case if the resolution does change. I'll look into this. Thanks very much.

Yeah, would be nice if this could be solved (without much effort).

Some possible solutions that come to my mind (they may be silly, I'll try to investigate them in the weekend):

a) (Maybe doable) Have each user 's session resolution (width, height) stored somewhere in their home directory, e.g. in gconf or some xorg file.

That way it could be read in advance, before starting the user's session, and xsplash image could be adapted to those values.

b) (Unrealistic?) Have the same resolution for all users (maybe set by users with administrative rights), and "convince" gdm to adopt that same resolution (I haven't found where gdm takes its screen resolution). This seems problematic (each user should be allowed to set a resolution that suits its taste, and vision).

c) (Workaround, simpler way) Just show the background image used in gdm till there is a resolution change, and when/if that occurs, read user's background image and use it instead (sizing it apropiately for the new resolution). Could require knowing user session's resolution in advance (case a).

About the video, I tried attaching it but it's too big (.avi format). Will try to compress it somehow, or change its format to .ogv.

Cody Russell wrote:
> Hmm, that's unfortunate that your session resolution is changing. We
> need to find someone who might know why that is happening, as that's
> definitely not desirable. Once X11 starts we should be staying in the
> same resolution the whole time.
>
For better or worse, X and GDM allow users to have custom screen
resolutions, which can be different to the one X initially adopts. We
could make changes in the UI to make resolutions global but that would
be a regression for many people.

Since this is fairly obvious X behaviour, the xsplash design should
accommodate it. We can fade out, change resolution and fade back in.

Mark

This is the video (11.7 MB) of xsplash going from GDM to Gnome desktop.

Quality is terrible (640x480, camera hand-holded), but I hope you can see what's goin on.

I've got a branch that I think may fix the problem. If you're willing to build from source and test it, that would be fantastic. Otherwise we'll try to get a PPA build up soon that you can test from.

I have pushed that branch into the xsplash-team ppa for testing:

https://edge.launchpad.net/~xsplash-team/+archive/ppa

It isn't built yet, in the queue with an estimate of 1h. The version should be obvious, xsplash - 0.7+r56+-resolution-changed-r57+200908281752

Thanks for putting it in a ppa: Can compile and build but don't know anything about VCSs.

I will test your ppa and report as soon as I finish the updating-of-the-day.

I'll add a video of how it looks, in the case you want to see how things are going.

I installed your PPA build, xsplash - 0.7+r56+-resolution-changed-r57+200908281752, and it seems to work similarly to version 0.6-0ubuntu1.

The only change I see from my (rather long) description in coment #6 is that, when there is the resolution change, the stripes of black turn now to a flesh-like color.

Background image is still 1024x768 when resolution goes to 1152x864, so it goes to left-top of screen leaving those stripes or bands at right and bottom of screen, as before.

See video attached.

Anyway, my case might be a very corner case, as it seems there is no other people reporting bugs about this. So it might be better not to spend too much time on this situation.

Perhaps the use of TFT monitors nowadays makes people stay in one resolution all the time (monitor's native resolution), so there is not much to worry about.

I posted a new revision that might help. We'll try to get you a new PPA build sometime soon to see if this helps you out.

Many thanks! I'll test your build as soon as my system finishes updating.

(Hmm, I had to post this twice, my first one got eaten by LP or so).

Hi, I've just tested your changes (version 0.7+r56+-resolution-changed-r58+200908310231).

It's not bad, but now when resolution changes there is a white or light grey corner at left and top sides of screen.

I think it's more clear if you could see the video attached.

By the way, the other banding at right and bottom of screen is not so bad. The flesh color looks very similar to the image background, I think I can live with it :-)

A possible solution to the stripes at right and bottom of screen could be:
- Using as xsplash's image one whose borders are of a single, solid color (e.g. using some Gimp gradient from image's central stuff to that solid color)
- Using as X server's background color that same solid color.

This way when session's resolution changes, stripes or bands not covered by the image can't be seen -they mix seamlessly with xsplash's image borders-.

This occurred to me when seeing the new image used at boot, that with black background and a light from top illuminating the Ubuntu logo. Now the change in resolution leaves no noticeable stripes at right and bottom of screen because X's color background is black too -unfortunately it changes after a bit to some orange and the stripes become visible-.

Hope this helps.

I have a similar problem.
I use a Thinkpad with an internal display (1440x900) which is turned of while the gdm session.
An external LG Display (1280x1024) shows the desktop then.
But after login when setting the resolution to 1280x1024 the xsplash is shown too small. On the right side and on the bottom there are two 200px broad strips, where you can see the desktop background and the panels loading.
This looks very ugly!
Two videos are attached to show the issue.
The first one with an default installation from 09-09-09 of ubuntu.
The second video shows the xsplash updated with the daily ppa mentioned above. ( xsplash - 0.7+r58+-new-assets-r63+200909020056 )

Hope you can fix this issue, if you need any logs please post!
jango

This bug is still present in Karmic beta.

I think xsplash should use the user's resolution right from the beginning and should not allow a resolution switch inbetween.

If a resolution change inbetween is not avoidable, xsplash should adapt as far as possible and resize it's display.

Seems like bug #433289 is a duplicate of this.

Andreas Schildbach, the problem is that if you have dual monitors, X starts with mirrored displays. Also, different users might have different resolutions set.

This bug was fixed in the package xsplash - 0.8.3-0ubuntu1

---------------
xsplash (0.8.3-0ubuntu1) karmic; urgency=low

  * New upstream version (LP: #446658)
    - watch for monitors-changed signal (LP: #413348)
    - set a blank cursor on the cow foreign window (LP: #432179)
    - setgid fixes (LP: #439268)
    - 16bpp depth fixes (LP: #423632)
  * debian/patches/90_correctly-setuid.patch
    - Removed, merged upstream

 -- Ken VanDine <email address hidden> Fri, 09 Oct 2009 08:16:49 +0200

xsplash 0.8.3 doesn't fix this problem for me.

The only difference I can notice is that xsplash indeed watches for the resolution change and afterwards stops drawing it's GUI elements at all. The weird-sized background textures are still there.

I'm away from home now so I can't test this, but when I return I'll see if I can try to reproduce. Leaving open until then. If you have any comments that might help me reproduce it, feel free to record them here.

"The only difference I can notice is that xsplash indeed watches for the resolution change and afterwards stops drawing it's GUI elements at all. The weird-sized background textures are still there."
I also had this issue on one or two startups, but not always. Atm it is gone.

I made a video of the recent situation:
*) The panel is showing up again, after the resolution change.
*) For my opinion the resolution change looks not good. Isn't it possible to read the resolution earlier? So that xsplash has to change only once after login.

Thanks a lot for your work!

Re-opened while we try to reproduce the latest problem report.

Dude, thanks so much for that video. That really helped a lot, because I was previous reproducing this issue in a different way (where it was disabling one monitor and switching to another at a different resolution during boot).

I've got a new patch that I believe will fix this problem. I'll try to get a PPA build of this for you to test.

We have uploaded a test branch to the team ppa for testing. It isn't built yet but you can watch for that. It is version is xsplash_0.8.3+r85+200910091650

https://edge.launchpad.net/~xsplash-team/+archive/ppa

Thanks Ken!

This is how it looks with xsplash_0.8.3+r85+200910091650 (this monitor is being set to 1600x1200 from the 1152x864 it had during login, the laptop display is being disabled).

for me it looks like in Kai's video. There is no visible difference to 0.8.3.
The resolution should change direct after login screen. I think there is too much flickering during startup now.

sorry for spamming, but..
after i logged in and out for a few times and changed the resolution each time (i think 3 times) the problem seems to be fixed.
The new resolution is now set directly after the login screen. No flickering and changing any more!
Great think!

... but the resolution change is still here when rebooting with automatic login.

Can confirm this on a Karmic Beta installation with all updates installed this morning

Okay, I have the same symptom from the following arrangement:

I have two displays, a secondary 1600x1200 screen on VGA to the left, and a primary 1920x1200 display via internal DVI to the right. The graphics are handled via the Nvidia driver, and the multi-display setup configured via the nvidia-settings app with the 1920x1200 display marked as primary

GDM displays only on the primary screen (the secondary screen is initialized & running at the correct res, but is blank)

Xsplash is rendered at 1920x1200, but is positioned from 0x0 (i.e. the far top-left corner, on the secondary display) rather than either spanning both screens or covering only the primary display

I'm going to go ahead and get the last branch merged in today. There is a moment in Kai's video where xsplash has not yet resized the image, but it corrects itself. Maybe for some reason it's not receiving expose events, or maybe it's still dealing with the scaling. Either way, this branch does seem to improve things in some cases, even if it doesn't fix every corner case.

Okay, merged into bzr trunk.

I think this is about as good as it's going to get for Karmic. xsplash startup is really tight on resources as it is, which you probably notice even in a more typical setup by how the throbber is not completely smooth. Getting a resize event and having to scale the image again is most likely going to stress it out further and cause it to not respond for a moment.

This bug was fixed in the package xsplash - 0.8.4-0ubuntu1

---------------
xsplash (0.8.4-0ubuntu1) karmic; urgency=low

  * New upstream version
    - Fix resolution setting to match desktop session after gdm (LP: #413348)
    - Fix top panel appearing above over xsplash (LP: #447084)
    - Fix broken logging (LP: #439268)

 -- Ken VanDine <email address hidden> Thu, 15 Oct 2009 13:36:24 -0400