Graphics dithered on Desktop image

Bug #1040526 reported by Lars Noodén
36
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Ubuntu CD Images
New
Undecided
Unassigned
linux (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

The graphics on the install disk for the 20120821 Desktop image are dithered and ugly. See attached screen shot.

WORKAROUND: Booting with kernel parameter:
live video=ofonly

Revision history for this message
Lars Noodén (larsnooden) wrote :
Revision history for this message
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1040526

tags: added: iso-testing
tags: added: quantal
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubiquity (Ubuntu):
status: New → Confirmed
Revision history for this message
ojordan (ojordan12345) wrote :

This is the continuing saga of what to do with radeonfb on PowerPC

affects: ubiquity (Ubuntu) → linux (Ubuntu)
Revision history for this message
ojordan (ojordan12345) wrote :

Radeonfb shouldn't be removed without the boot message on the CDs being updated. Otherwise we are going to have a lot of people with frozen computers, not knowing what is going on. They will need to reduce the AGP number, probably infact switching to PCI mode radeon.agpmode=-1 . All references to video=ofonly in /install/boot.msg should be removed, and 'nomodeset' suggested instead.

tags: added: powerpc ppc
Revision history for this message
ojordan (ojordan12345) wrote :
Revision history for this message
ojordan (ojordan12345) wrote :

I've been experimenting with fbdev and the openfirmware framebuffer. It is not good. Instead of 8 bit graphics it is more like 4 bits. Removing radeonfb is going to be even more painful for those that can't run KMS out of the box. You can use radeonfb as a module (there are instructions in the FAQ), but it is just how compilcated you want to make it. I can forsee a lot of Lubuntu users running the fbdev driver. I think maybe the current kernel config should stay.....but it is down to the lubuntu testers to decide.

Changed in linux (Ubuntu):
importance: Undecided → Medium
Revision history for this message
ojordan (ojordan12345) wrote :

These are the current workarounds for radeon users:

1. Turn on KMS - the boot parameter video=ofonly should do this. If this causes freezing then combine with radeon.agpmode=-1

2. Use the fbdev driver. To increase the colour depth use a boot parameter such as video=radeonfb:1024x768-32@60. Obviously what you write is monitor dependant, but note the 32 for the depth and not 24 (that caught me out for a while). You could alternatively write an xorg.conf to increase the colour depth.

You have suspend with the fbdev driver and that may appeal to some people. You get hardware acceleration with KMS and that maybe needed by some people. What you can't have currently in 12.10 is both.

Revision history for this message
Lars Noodén (larsnooden) wrote :

Booting with the parameters 'live video=ofonly' got rid of the dithered graphics, things look nice now. This also seems to fix bug 1040544

https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1040544

Revision history for this message
ojordan (ojordan12345) wrote :

With grub I always seem to have the boot option 'vt.handoff=7' added. Just wondering if this should be added to the default yaboot parameters along with 'quiet splash'? It seems to cause me to boot into 16 bit mode which is obviously more desirable than 8 and makes ubiquity work.

http://askubuntu.com/questions/32999/what-is-vt-handoff-7-parameter-in-grub-cfg

Revision history for this message
Colin Watson (cjwatson) wrote :

vt.handoff=7 is only really any use in combination with the other graphics setup that GRUB does. I suspect we could only do that if we changed boot loader as well, which might be nice but it seems a little late for 12.10 really.

Revision history for this message
ojordan (ojordan12345) wrote :

Changing bootloader is overkill for this problem, although if you are interested I have written a guide to using grub2 on PowerPC https://wiki.ubuntu.com/PowerPCFAQ#Can_I_install_grub2.3F . The sticking point for grub2 is can it boot macos/macosx (neither or which I have on my machine)? Or do you need to create a CHRP script (ofboot.b) to do this like yaboot does?

Revision history for this message
ojordan (ojordan12345) wrote :

Note, there is a new bug when using KMS - see bug 1058641 . The kernel config can't be now changed until that is sorted.

Revision history for this message
ojordan (ojordan12345) wrote :

I've also asked the X people in bug 1058753 if they can confirm what is going on.

Revision history for this message
ojordan (ojordan12345) wrote :

A lot of the Apple PowerPC users will be using a radeon 9200 card or something similar. It is probably worth pointing out that there has been a kernel release note about these cards for a long time now:

"On systems with an ATI Radeon 9200 graphics card the system will boot to a black screen. As a work around edit the kernel command line in the boot loader and add 'nomodeset'."

See bug 725580 .

So the idea that using a boot parameter is unusual or unacceptable rather goes against what has happened in the past on 'regular' architectures.

Revision history for this message
ojordan (ojordan12345) wrote :

For my new suggestion on how to fix this, see the kernel mailing list thread https://lists.ubuntu.com/archives/kernel-team/2012-October/022270.html

Revision history for this message
ojordan (ojordan12345) wrote :

Attached is a patch for yaboot-installer. It shows how easily this bug could be fixed on an installed system by just using the vt.handoff=7 boot parameter (the same as Grub2 does). It also creates a recovery option (the same as Grub2). This is therefore a low risk solution to the problem.

The same solution could be applied to the live ISOs. Just add vt.handoff=7 to the live/live64 options.

tags: added: patch
Revision history for this message
ojordan (ojordan12345) wrote :

Nvidia cards will also have this problem when they turn off KMS (nomodeset or nouveau.modeset=0) . At present it is likely to be a lot worse for them; they will possibly only have 16 colours due to the limitations of the openfirmware framebuffer. To solve this you will have to build back in the legacy framebuffers:

-CONFIG_FB_RIVA=m
+CONFIG_FB_RIVA=y
-CONFIG_FB_NVIDIA=m
+CONFIG_FB_NVIDIA=y

This will disable KMS by default, but it can be re-enabled with the video=ofonly parameter. It will make the nouveau setup the same as radeon's current setup.

penalvch (penalvch)
description: updated
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.