Yes, we realize setting the resolution to 640x480 is not likely to work and not likely to be what we want in the end; usplash has some logic for picking the highest resolution supported by the video output backend and the configured theme. We didn't get as far as debugging why it's not trying to use the highest resolution, perhaps it's not reading the current resolution from the kernel properly, but when we started looking into the splash screen issue this system hang showed up. So in all cases usplash shouldn't be able to hand the whole system; this is what the bug is about.
We've put a workaround in place (we read the resolution set on the kernel cmdline and pass that to usplash) but that's less than ideal because: - we'd like to not hardcode the resolution anywhere; it should be autodetected with EDID and reported to userspace - we rely on fragile cmdlibe parsing - usplash is still able to hang the system in some cases (might be another bug) -- mxcfb framebuffer driver crashes the board hard on attempt to use a different resolution than the one specified on cmdline https://bugs.launchpad.net/bugs/420555 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
