Comment # 12 on bug 1232727 from Fabian Vogt

(In reply to Dominique Leuenberger from comment #8)
> Plymout has a patch called
>   Patch4:         plymouth-only_use_fb_for_cirrus_bochs.patch

I think at this point we should try to be optimistic and just drop this in
favor of removing framebuffer support altogether, resp. not doing anything
because the kernel doesn't expose it anyway.

However, there might be more issues. The plymouth code does:

static bool
verify_drm_device (struct udev_device *device)
{
        const char *id_path;

        /*
         * Simple-framebuffer devices driven by simpledrm lack information
         * like panel-rotation info and physical size, causing the splash
         * to briefly render on its side / without HiDPI scaling, switching
         * to the correct rendering when the native driver loads.
         * To avoid this treat simpledrm devices as fbdev devices and only
         * use them after the timeout.
         */
        id_path = udev_device_get_property_value (device, "ID_PATH");
        if (!ply_string_has_prefix (id_path, "platform-simple-framebuffer"))
                return true; /* Not a SimpleDRM device */
...
}

if (strcmp (subsystem, SUBSYSTEM_DRM) == 0) {
        if (!manager->device_timeout_elapsed && !verify_drm_device (device)) {
                ply_trace ("ignoring since we only handle SimpleDRM devices
after timeout");
                return false;
        }
        ply_trace ("found DRM device %s", device_path);
        renderer_type = PLY_RENDERER_TYPE_DRM;
        ...

i.e. for simpledrm devices.

There are three issues with this approach:

1. A bug in the code: ID_PATH does not start with platform-simple-framebuffer,
but it's in the middle, e.g.
ID_PATH=pci-0000:00:01.0-platform-simple-framebuffer.0
2. For platforms where only the simpledrm driver is available there is an
arbitrary timeout (8s by default) until plymouth tries to display anything.
3. For platforms where the simpledrm driver is available but not supposed to be
used (because a native one will be loaded), it might still break if the native
driver doesn't take over within that arbitrary timeout.

Issue 1 negates issue 2 but amplifies issue 3. That would've been present
before CONFIG_FB_DEVICE=n though, so we can probably ignore it for this
particular bug report.