https://bugzilla.suse.com/show_bug.cgi?id=1232727 https://bugzilla.suse.com/show_bug.cgi?id=1232727#c12 --- Comment #12 from Fabian Vogt <fvogt@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.