plymouth in quantal on arm does only boot with black screen

whoops, ignore teh first logfile, that was actually a boot without splash... new log attached

downgrading the following packages to their 12.04 versions seems to fix everything ...

libplymouth2
plymouth
plymouth-label
plymouth-theme-ubuntu-logo
plymouth-theme-ubuntu-text

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/1018907

The log shows:

[ply-renderer.c] ply_renderer_open_plugin:trying to open renderer plugin /lib/plymouth/renderers/drm.so
[...]
[./plugin.c] load_driver:Attempting to load driver 'omapdrm'
[...]
[ply-renderer.c] ply_renderer_open_plugin:opened renderer plugin /lib/plymouth/renderers/drm.so
[...]
[./plugin.c] ply_renderer_head_map:Creating buffer for 1920x1200 renderer head
[./ply-renderer-libkms-driver.c] create_buffer:Could not allocate GEM object for frame buffer: 22

So the kernel is exposing a DRM interface which is not usable by plymouth (or, according to what Oliver tells me on IRC, by anything else either). Either the kernel needs fixed, or we need to blacklist omapdrm so that we fall back to the framebuffer renderer instead, which is what was used in precise and earlier.

confirming that an:
rm /lib/plymouth/renderers/drm.so

fixes the issue on the pandaboard, i will research the issue on tegra ac100 tomorrow so we can see if thats similar.

I deleted the first log file that was incorrect. You can do this by clicking the pencil icon by the attachment name.

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

Removing the rls-q-incoming task as this is already targetted for fixing in Q.

digging deeper into this, there is now a libdrm-omap1in the archive, i suspect that will need someone to write a proper omap drm handler for plymouth (and also link plymouth agaist the omap stuff of libdrm)

additionally libdrm-omap1 as well as the new drm capable xserver-xorg-video-omap need to go onto the panda images

On Wed, Aug 15, 2012 at 02:28:14PM -0000, Oliver Grawert wrote:
> digging deeper into this, there is now a libdrm-omap1in the archive, i
> suspect that will need someone to write a proper omap drm handler for
> plymouth (and also link plymouth agaist the omap stuff of libdrm)

Why do we need a separate drm handler for plymouth? Why doesn't this work
with the generic drm backend?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

if plymouth will fall back to the "dumb scanout buffer" ioctl, it should work.. I'd have to look at plymouth src code to see if this is actually how it does work. If plymouth uses libkms then this should be automatic.

Testing with http://cdimage.ubuntu.com/daily-live/20120815/quantal-desktop-armhf+omap4.img, still at the first boot (installer), I got a different behavior:

[ply-renderer.c] ply_renderer_open_plugin:trying to open renderer plugin /lib/plymouth/renderers/drm.so^M
[./plugin.c] create_backend:creating renderer backend for device /dev/dri/card0^M
[./plugin.c] load_driver:Attempting to load driver 'omapdrm'^M
[ply-terminal.c] ply_terminal_open:trying to open terminal '/dev/tty7'^M
[ply-terminal.c] ply_terminal_look_up_geometry:looking up terminal text geometry^M
[ply-terminal.c] ply_terminal_look_up_geometry:terminal is now 240x67 text cells^M
[ply-terminal.c] get_active_vt:Remembering that initial vt is 1^M
[./plugin.c] query_device:Could not initialize heads^M
[ply-renderer.c] ply_renderer_open_plugin:could not query rendering device for plugin /lib/plymouth/renderers/drm.so^M
[./plugin.c] close_device:closing device^M
[./plugin.c] unload_driver:unloading driver^M
[./ply-renderer-libkms-driver.c] destroy_driver:uninitializing kms buffer driver^M
[ply-renderer.c] ply_renderer_open_plugin:trying to open renderer plugin /lib/plymouth/renderers/frame-buffer.so^M
[./plugin.c] create_backend:creating renderer backend for device /dev/fb0^M
[ply-terminal.c] ply_terminal_open:terminal /dev/tty7 is already open^M
[./plugin.c] query_device:32 bpp (8, 8, 8, 8) with rowstride 8192^M
[./plugin.c] initialize_head:initializing 1920x1080 head^M

The splash worked, but because for some reason it failed to query the device for omapdrm. I'm waiting the installer to finish and will test it again with proper debug after it's done.

At the attached patch I included a patch already available at upstream, that adds a new generic driver for the drm renderer plugin.

This generic driver is supposed to work on radeon, nouveau and omap, and any other generic use case using the drm driver. As the plymouth package implies at a bunch of ubuntu specific changes, I decided to just backport this patch instead of rebasing it on top of 0.8.5.1.

I also had to include another fix related with the new libdrm package (2.4.38), which changes the old nouveau library to libdrm_nouveau1, otherwise the nouveau plugin would be linked with the wrong libdrm nouveau implementation.

And, as a side effect, I had to update the autoreconf.patch, making the debdiff quite large, but due differences on using a newer autoconf/automake than the one previously used when the patch was previously updated.

Tested on Pandaboard and I can now see the splash screen during boot. Will attach plymouth.log as well.

This bug was fixed in the package plymouth - 0.8.4-0ubuntu2

---------------
plymouth (0.8.4-0ubuntu2) quantal; urgency=low

  * debian/patches/upstream-add-generic-driver-to-drm-renderer-plugin.patch:
    - Add the generic driver to the drm render plugin, which is the only one
      supported on latest upstream, working also for omap. Not yet disabling
      the others, as they can still be used in case the generic one fails,
      which keeps plymouth safe for x86 (LP: #1018907)
  * debian/patches/update-libdrm-nouveau-library-dependency.patch:
    - Old nouveau driver is now called libdrm_nouveau1 at the latest libdrm
      package (>= 2.4.38)
  * Refresh autoreconf.patch.
 -- Ricardo Salveti de Araujo <email address hidden> Thu, 16 Aug 2012 01:53:54 -0300