probe screen resolution at boot

This could be bug #150930 that has resurrected, but I have to check "Screens and Graphics". For sure, X is using 1024x768 like it should.

I also confirm this on Dell Inspiron 9300 laptop with ATI mobility radeon X300. Screen and Graphics does not show anything, but the real X resolution is 1440x900. /etc/usplash.conf contains 640x480 so usplash works but is also rough/coarse/grainy

Also numerous comments in other bug reports confirm that a lot of computers get 640x480 resolution in Hardy a3 and a4.

Adding ubiquity in packages since the values in /etc/usplash.conf are probably installed by ubiquity. Actual displayconfig-gtk does not display anything in Hardy (bug 17341) so it may be related. I think that we should not mix up this bug with bug #150930 because this one does not cause black boot screen and seems to be caused by the absence of any resolution detection. IMO, it's a different issue that needs to get some attention before hardy get stable.

As I have posted on my original duplicate, for me this wrong setting in usplash.conf causes for some reason a cycling through colored full screens until the moment gdm starts. (It was hard to guess the problem was in usplash.conf)...

This is a bug for me too - I have a 1440x900 screen, which is detected correctly eventually (at the login screen I think), but the usplash is at a lower resolution.

Actually my monitor says it's at the correct timing (1440x900) but the picture itself is at a lower resolution.

Increase importance to high since this should really get fixed before hardy release.

Same problem installing Hardy Alpha 6 Desktop to an Acer TravelMate 8101 with an ATI X700 card (radeon driver) and 1680x1024 LCD screen. Xorg is perfectly set up, but usplash.conf has 640x480.

Ubiquity itself doesn't actually create or add these values. The only part that it does is to issue a 'reconfigure' command on the usplash package.

Tracing this issue a little further, look at the usplash postinst. This is the code that is called to choose that value:

# Write a config file
setup_usplash_config()
{
        if [ ! -f /etc/usplash.conf ]; then
                db_version 2.0
                if db_get xserver-xorg/config/display/modes; then
                        FIRSTVAL=`echo $RET | sed 's/,.*//'`
                        x=`echo $FIRSTVAL | sed 's/x.*//'`
                        y=`echo $FIRSTVAL | sed 's/.*x//'`
                else
                        x=640
                        y=480
                fi
                echo "# Usplash configuration file" >/etc/usplash.conf
                echo "xres=$x" >>/etc/usplash.conf
                echo "yres=$y" >>/etc/usplash.conf
        fi
}

On my two hardy systems, I dont see anything in that debconf variable. A new method needs to be developed for determining the values to use for X & Y:

supermario@portablemario:~/usplash-0.5.16$ echo "get xserver-xorg/config/display/modes" | sudo debconf-communicate
10 xserver-xorg/config/display/modes doesn't exist

Interesting, I suggest xrandr -q. AFAIK, it's the only way I can get the resolution from X since Xorg now use xrandr 1.2 rather than old /etc/X11/xorg.conf config static file. I will look at this deeper.

Unfortunately, xrandr will only work when X is running so it does not seem to be a viable option.. And the new xserver-xorg does not set xserver-xorg/config/display/modes debconf variable anymore. What can-we use to fix this issue?

Saïvann Carignan wrote:
> Unfortunately, xrandr will only work when X is running so it does not
> seem to be a viable option.. And the new xserver-xorg does not set
> xserver-xorg/config/display/modes debconf variable anymore. What can-we
> use to fix this issue?
>
Well here's what I think.

Check for a valid DISPLAY variable in the postinst. If there is one, try to
query it via xrandr. If not, then fall back to a default of 640x480. I'm not
sure if generally DISPLAY is exposed though when running dpkg. It might be
cleared from the environment.

--
Mario Limonciello
<email address hidden>

This is possible and that would be better than nothing, but that would means that the alternate installer would not be able to install usplash with any other mode than 640x480. According to that fact, should we still consider xrandr as a viable solution? Otherwise what options can we use, ddcprobe?

After asking the maintainer of usplash, creating a postinst script based on xrandr does not make sense, also ddcprobe does not make sense since X might be running. The real fix for that bug would be the same as bug 158048, usplash should ddcprobe the right resolution automatically at each boot.

This bug won't be fixed in usplash for Hardy. The only temporary solution for that bug is to generate correct usplash.conf file from ubiquity. I set the status of ubiquity to Confirmed.

The bootsplasg is really ugly!
And why not set the bootsplash to 640x480 for any display and make the bootsplash image smaller, so it would look good on any pc. Why do you think, I hope you understand me! Also by this way it could work without patching something by making the artwork in 640x480...

This is an installer problem which does not configure usplash correctly, usplash itself works well.

Changing importance to low: this bug has not a severe impact, and can be easily worked around.

I agree that this really detracts from the overall appearance of Ubuntu, and was the first thing I noticed when upgrading to Hardy from Gutsy. It looked really slick before on my 1400x1050 display but now it is not very attractive. I really hope a fix of some kind can be implemented for the final release of Hardy. If there is anything I can do let me know.

Andrea, are you sure about your changes?

As mentioned, while the current issue is a result of ubiquity, the proper solution as mentioned by Saïvann Carignan is for usplash to detect the resolution each time on startup, and as such it SHOULD also be a bug against usplash. I don't see why that is invalid.

This also affects a very large number of users and IS significant from a QA point of view, I believe Low would be grossly inappropriate and they both should be High, as they were previously.

I would appreciate your and anyone else's feedback in regards to this.

Please set again to high or medium! I hope it will be fixed for hardy though, as it can scare user maybe!
Detecting on each startup is a soltuion, is there already a patch?

I'd like to help, but I'm not skilled at programming at all -- is there any
testing I could do, or something?

On Sun, Mar 30, 2008 at 10:49 AM, Saïvann Carignan <email address hidden>
wrote:

> ** Changed in: ubiquity (Ubuntu)
> Importance: Undecided => Medium
> Status: Invalid => Confirmed
>
> --
> [hardy]640x480 usplash on all computers
> https://bugs.launchpad.net/bugs/188764
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Hi phix! Just voicing your concern is probably the most helpful thing to do at this point, here and on IRC in #ubuntu-bugs on irc.freenode.net.

Saïvann, Andrea and I discussed this bug and he (correct me if I am wrong with this pronoun) has stated that the bug really isn't in ubiquity because all ubiquity does is run a script which exists in usplash. If that is the case, the script needs to be fixed in usplash and it is invalid in ubiquity. Unless the problem is that ubiquity isn't properly running it, which in that case it IS valid in ubiquity, and also valid in usplash because as discussed above the proper solution is to have usplash detect the resolution each time. Would you mind just clarifying for me and records which situation is correct, Saïvann, or anyone else? Thanks!

Also, I think it is important to note in regards to this issue that while it may not seem important to developers and loyal users of Ubuntu like myself, for many this boot screen is the first thing they see and is their first impression of Ubuntu. And in public places, non-users are also going to see this screen and associate it with Ubuntu. An unpolished first impression for these people is unwise, IMO. Personally I don't care if there was no splash screen, or if it was a laughing monkey sitting on a rainbow in the clouds; I already know I love Ubuntu. But for people who don't already, it would be nice to present an elegant and slick first impression via usplash, not a huge, pixelated, unpolished looking logo.

The answer to this question is in the bug description, according to Matthew Garrett, the usplash maintainer, the best way to fix this temporary is through ubiquity. I let the bug open in both ubiquity and usplash so developers can take their decision about which solution will be applied. Automatic usplash detection won't happen in Hardy, but might be implemented for Intrepid. Colin Watson started to work on this in bug 150930.

adjusting this in ubiquity wont be possible in all different possible
frontends. the noninteractive frontend for example cant query the
current resolution in all cases.

On 3/30/08, Saïvann Carignan <email address hidden> wrote:
> The answer to this question is in the bug description, according to
> Matthew Garrett, the usplash maintainer, the best way to fix this
> temporary is through ubiquity. I let the bug open in both ubiquity and
> usplash so developers can take their decision about which solution will
> be applied. Automatic usplash detection won't happen in Hardy, but might
> be implemented for Intrepid. Colin Watson started to work on this in bug
> 150930.
>
> --
> [hardy]640x480 usplash on all computers
> https://bugs.launchpad.net/bugs/188764
> You received this bug notification because you are a member of Ubuntu
> Installer Team, which is subscribed to ubiquity in ubuntu.
>

--
Sent from Gmail for mobile | mobile.google.com

Mario Limonciello
<email address hidden>

This should not be done in ubiquity; the less package-specific work done there the better. It's perfectly possible for usplash to look at DISPLAY in its own postinst when writing out its default usplash.conf, rather than the baroque idea of having it write out usplash.conf and then have ubiquity go round and fiddle with it immediately afterwards.

And yes, anything based on interrogating the current X display will lose on the alternate install CD, on ubiquity's noninteractive frontend, and probably in other cases. The only way to fix *that* is to probe at boot time, which is definitely too risky for 8.04. I'll leave this bug open for that work to be done later.

usplash (0.5.18) hardy; urgency=low

  * Let usplash use the minimum mode in the theme if we don't know the
    correct modes, rather than forcing 640x480.
  * Fetch modes from the current display if we're being configured within X
    (works around LP #188764).

 -- Colin Watson <email address hidden> Sun, 30 Mar 2008 22:43:16 +0100

I think that should be good enough for 8.04.

Colin Watson : Thank you very much for your work on this. Tested here and your update works perfectly, we can now keep this bug open for Intrepid.

I was there was an update but it still looks bad!
If I understeand your solution, it's the same as I said: keep 640x480 and make the theme look better for 640x480, But could it look smaller/better, but I think that is the work of the artwork team to make the theme, right?

Warren Dumortier : The update fix the problem completely if you are using X when installing usplash (so it will not work from the alternate install CD). To test it, remove your /etc/usplash.conf and reinstall usplash. You'll see that usplash now creates a /etc/usplash.conf file that contains the good values. That's all we can do from now. The real solution is to probe automatically the good resolution at each boot and to stop using static configuration files (/etc/usplash.conf), but this won't happen for Hardy according to Matthew Garrett.

Cool, great work! Now it looks better, nice to have it centered!

Hmm, this still seems to fail within ubiquity, because usplash.postinst doesn't have access to the X authorisation cookie. Drat.

Is there something wrong with using ddcprobe in postinst (whether X is
running or otherwise)? Seems to work fine for me, and gives me more
information than I can shake a stick at with no interruptions to the
graphical output at all.

You have to be very careful when using ddcprobe; xresprobe used to have a slew of hardware-dependent hacks to avoid problems. I'm not comfortable with doing that for 8.04. It won't be necessary, either; although my first attempt at using xdpyinfo failed I'm confident I can fix it.

Thanks Colin, great work so far. After a "sudo rm /etc/usplash.conf && sudo aptitude reinstall usplash", it looks great.

I agree that this is probably sufficient for Hardy, however does this only work with LiveCD installs? What about Wubi? It seems like most of the people that couldn't fix this manually would be coming from the LiveCD or Wubi. If not, is there a way to detect the resolution in Windows and put it in the usplash.conf? It seems relatively safe to assume the Windows resolution is that user's preferred resolution, certainly better than assuming 640x480 anyway.

Okay, thanks again, just wondering about Wubi.

Actually, according to Colin comments, it does not work correctly yet when installing the computer with ubiquity, so further work is needed. However, it won't work for the alternate CD for Hardy. The real solution to that bug (automatic probing) will have to wait for Intrepid.

On Tue, Apr 1, 2008 at 2:14 PM, Colin Watson <email address hidden> wrote:
> You have to be very careful when using ddcprobe; xresprobe used to have
> a slew of hardware-dependent hacks to avoid problems. I'm not
> comfortable with doing that for 8.04. It won't be necessary, either;
> although my first attempt at using xdpyinfo failed I'm confident I can
> fix it.

xdpyinfo is giving me bogus details about the size of my screen right
now, even though radeon driver detects everything correctly (according
to X log), ddcprobe detects everything correctly and xrandr detects
everything correctly. xdpyinfo is the only one getting it wrong -- I'd
be careful of that, too! (There is a bug open for this.)

Alexander: What's the bug number? That sounds like a serious issue that should be fixed. There's really no reason why xdpyinfo shouldn't be workable here - although ideally it might make sense to step through the resolutions offered by xrandr until we find a VESA mode.

https://bugs.launchpad.net/bugs/201491

I am still unsure of using X tools though, don't these all require an X
connection? If we really have to probe and hardcode at configure time can we
not use non-X tools?

This bug was fixed in the package ubiquity - 1.8.2

---------------
ubiquity (1.8.2) hardy; urgency=low

  [ Evan Dandrea ]
  * Treat the dbfilter returning nonzero as a fatal error in the
    noninteractive frontend.
  * Clean up the reboot message in the noninteractive frontend.
  * Optimize the md5 check on file copy (LP: #198019).
  * Copy the locale over to the target system when using oem-config.
    This was previously fixed for the alternate CD in LP 181291.
  * Use + instead of : for a replacement character for m-a as it is
    explicitly allowed by debconf policy.
  * Break out of resizing the partition in cases where partman fed us bad
    boundary values (LP: #197838).
  * Don't miscalculate with nested partitions in 03partition_too_small (LP:
    #198039).
  * Automatic update of included source packages: apt-setup
    1:0.31ubuntu7, choose-mirror 2.19ubuntu5, clock-setup 0.92ubuntu3,
    console-setup 1.21ubuntu6, localechooser 1.42ubuntu4, migration-
    assistant 0.6.1, partman-auto 73ubuntu7, tzsetup 1:0.20.

  [ Mario Limonciello ]
  * Don't unnecessarily hardcode the return of get_hostname()
    in the noninteractive frontend.
  * Turn off console blanking in Ubiquity init script to prevent
    confusion on the noninteractive frontend.
  * Update mythbuntu ubiquity icon.

  [ Colin Watson ]
  * Fix crash if partitioning failed when partitioning was automated (see LP
    #206113).
  * Remove packages in the restricted section from the installed system if
    apt-setup/restricted is false.
  * Fix crash with the "don't use" partitioning option (LP: #132611).
  * Use localised, human-readable names for partitioning methods.
  * Reorganise the wrapper script to cope with kdesu's broken argument
    handling.
  * Add a "Format the partition?" checkbox to the partition edit dialog
    (LP: #184838).
  * Give reconfigured packages access to our X display, so that
    usplash.postinst can check its dimensions (LP: #188764).

 -- Evan Dandrea <email address hidden> Tue, 08 Apr 2008 02:02:23 -0400

Alexander: the reason to use X tools is precisely so that we can take advantage of the probing already done at X server startup. Yes, it does require an X connection; this is a downside, but not an immediately fatal one.

Your xdpyinfo bug report seems to be mainly about the physical dimensions of the screen; this code doesn't rely on that information.

I can confirm this problem is still in latest hardy, upgraded yesterday

Hi Åskar, this issue should no longer exist in Hardy. Note the "Fix Released" status. The patch will work fine for new users but for beta users, the configuration file needs to be recreated. Have you followed the instructions? The old configuration file needs to be deleted and usplash must be reinstalled, as stated above. See my previous post for instructions. Let me know if the issue still persists after following the instructions.

Mike,

In response to your above comment, I am experiencing the same problem as Åskar with the Hardy release candidate.

I did follow your directions ("sudo rm /etc/usplash.conf && sudo aptitude reinstall usplash"), which resulted in my /etc/usplash.conf changing to the following:

-----
# Usplash configuration file
# These parameters will only apply after running update-initramfs.

xres=1280
yres=800
-----

1280x800 is the proper resolution for my monitor. Previously the /etc/usplash.conf resolution was 1024x768, which resulted in an oddly stretched splash screen.

However, even with usplash set to that 1280x800 and update-initramfs being properly updated, the splash screen is now off-center and oddly distorted. I set it back to 1024x768, as it's at less distorted.

I just want to follow up, are there any status updates on probing resolution at boot time for Intrepid?

The splash screen is stretched on my monitor (1280x800)... usplash.conf values are correctly set, but the splash image is still skewed... is this a symptom of this problem?

The usplash package has been superseded by plymouth and has been removed from the Ubuntu archive. Closing all related bugs.