Graphics dithered on Desktop image

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

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

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

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.

See comment https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1046951/comments/14 for what is going on.

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.

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.

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

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

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.

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?

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

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

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.

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

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.

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.