usplash messes up colors on console

Hi Michael, what graphics card do you have and what X driver are you using?

2006/9/17, Paul Sladen <email address hidden>:
> Hi Michael, what graphics card do you have and what X driver are you
> using?

It's a Radeon Mobility 9200.
lscpi -vv output:

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250
[Mobility FireGL 9000] (rev 01) (prog-if 00 [VGA])
        Subsystem: Compaq Computer Corporation Unknown device 0860
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping+ SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 128 (2000ns min), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 10
        Region 0: Memory at 98000000 (32-bit, prefetchable) [size=128M]
        Region 1: I/O ports at 3000 [size=256]
        Region 2: Memory at 90400000 (32-bit, non-prefetchable) [size=64K]
        [virtual] Expansion ROM at 90420000 [disabled] [size=128K]
        Capabilities: [58] AGP version 2.0
                Status: RQ=48 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64-
HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
                Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit-
FW- Rate=x4
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

I use the standard radeon driver for X and the current edgy eft kernel

I can confirm this on Edgy with an ati rage 128 chip.

usplash needs to restore the original palette values on shutdown.

Fixed in bzr, will be uploaded after beta.

Not fixed in 0.4-30.

Not fixed in 0.4-31 either. Maybe it's time to reopen this bug? Or am I the only one who still has a console with wrong colors? Additionally, since upgrade to 0.4-30, progress-bar seems to have wrong colors, too (white with brown highlights). At the moment I don't have a digicam, otherwise I would post a screenshot.

No, you are not the only one. I can confirm that the bug is still not fixed. If a screenshot is needed, I can provide one.

Setting back to Confirmed due to comments.

Just upgraded from dapper to edgy - ATI 9600Xt card
had problems at first with kde overwriting the ubuntu splash - finally got that sorted and have run into this problem - startup is fine , shutdown is psychedelic and the progress bar has question marks in it

Can you confirm if this bug also happens with latest gutsy / development hardy alpha release? Thanks for the informations you provided to this bug report so far.

My problem (which is described in detail in the duplicate bug 118906) is unchanged. I'm running a fully-updated Gutsy. (My symptoms are a bit different, though, so I'm unsure whether that bug should be a duplicate.)

New Hardy release is out! Can you install/upgrade to Hardy and confirm if this bug is still there?

There has been works done on console colors in hardy, can someone confirm if this bug still exist in hardy?

Still there in intrepid. Radeon 7000/VE.

I've been fooling around with the code a bit and here's what I've figured out so far:

1) If you don't boot usplash there's no problem.

2) restorepalette (from svgalib-bin) from will fix the problem temporarily (see below). In particular, it's the part that restores vga color map registers that does the trick. But here's what's weird: if you write code to query those vga registers, you find that the mapping is already correct. So it's the act of rewriting the correct values into the registers that fixes it.

3) Switching back to X and then back to the console screws everything up again, even after you've run restorepalette. But again, there's no problem if usplash was never run in the first place.

So presumably we either have a) the svgalib code setting up something wrong (note that usplash calls routines in the wrong order in some cases, for example calling vga_setchipset before vga_init, though as far as I can see all the initialization happens correctly), or b) there's a bug either in the ATI X driver or ATI's VBE implementation.

Me again. The second half of my point 2) above was an error on my part: I was reading the wrong register. Querying the registers shows the messed up mapping.

A little sleep and I realized what's going on in point 3): X saves the state (with the screwed up palette registers) that it sees when GDM starts, and restores it every time you go back to the console. You can fix it on the console, but it gets unfixed every time you go back to X. Thus, as long as the problem is fixed by time X starts, everything is fine.

So, the quick and dirty fix is to run the attached code right after usplash exits (essentially restorepalette pared down to the bare essentials to fix this problem).

Of course, the logical thing would be to put this code into usplash itself; however, putting it in the obvious place (the atexit routine in svgalib/src/vesa.c) didn't seem to do the trick.

This may be the problem with bug #139453 also...

J. Scott Berg : Can you provide a debdiff and subscribe ubuntu-main-sponsors? Also, it might be interesting to discuss about these changes with ubuntu-developers mailing list or on IRC so they can give feedback and improvements. Thanks for your work on usplash!

I'm attaching the debdiff, but I really wouldn't recommend this be released. It's a hack, cleaning up the mess that usplash left. Really we should prevent usplash from leaving a mess in the first place, because it may not only be scribbling on the palette registers.

My gut feeling from looking at the code is that the most straightforward fix would be to combine all the _init and _done stuff into a single routine (or a pair of routines, one in vga.c and one in vesa.c, the latter called directly by the former). There are int 10h calls to save and restore the VESA/VGA state, though some of these are commented out in svgalib for reasons I have yet to investigate. There may be some issues regarding the setting of the mode as well (my initial look indicated that my ATI card listed a bunch of VESA modes but then said that none of them were available, but this latter fact was ignored by svgalib; I still need to verify this more carefully; if this is the case, then we would need to use EDID requests to get modes, which is probably the right thing to do anyhow). As you said, this should all be discussed on ubuntu-developers...

I confirm also that this problem exists and is caused by usplash.

My system is an AMD 64bit laptop with a new install of Ubuntu 9.04 beta (jaunty) only a few days old now (4 days?).

Upon reading these posts here, I removed usplash from the system, rebooted, and the problem was gone.

Thanks to those who figured this out.

Terry Mackintosh <email address hidden>
(I use ASK, so can give my email address:-)

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