Comment 5 for bug 648013

I found a solution to this problem, possibly one that can be addressed through a configuration patch to grub2.

When my system boots to grub, I selected 'c' for command-line, and issued "vbeinfo" to figure out what vesa video modes my particular card supports. Interestingly 640x480 is not on the list :). 1400x1050 was the highest listed on my ATI adapter to use on my 1680x1050 panel.

using this information, I simply added

 GRUB_GFXPAYLOAD_LINUX=1400x1050

to /etc/default/grub and issued an update-grub.

This gave me the standard/unchanged low resolution grub menu that "paints" quickly and is easy to read, but allowed the graphical splash to work at the highest resolution possible, which is also used for my tty's .. which is great too for console real-estate outside of X.

Note, this is NOT the option that appears commented out in /etc/default/grub by default. Changing this more obvious option to a valid resolution (indicated by vbeinfo) and uncommenting it affects the resolution of the grub menu itself. This new option I added, shown above, additionally 'passes' on a mode to the linux kernel whereby plymouth picks it up. (if I'm not mistaken)

This works without any messing with initramfs config files, uvesafb modules or kernel command line parameters directly which likely makes it more future-compatible with a permanent fix as this change can be more managed by dpkg upgrades. I suspect a few other non-ATI graphical splash issues may be workable using this grub option also.

Attached is my new plymouth-debug output, which includes the following line that shows the rendering device being selected.

[./plugin.c] create_backend:creating renderer backend for device /dev/fb0