Stephan Kulow wrote:
OK, I looked into this yesterday and there are some problems:
- plymouth is out as it requires DRM and while fedora has tons of drm patches in their kernel I don't see us going there - perhaps 11.3 if everything needed settled in Xorg and kernel. As far as I can see for intel chips the required work is already in kernel and X.Org and settled. For radeon chips upto and including r600(?) the respective work is in the staging area of the kernel (correct me please if that is wrong, Greg).
- bootsplash works, but is limiting the artists and is only used for booting, not for suspend. And it has no support for e.g. error boxes and password queries - splashy is from what my experiments easy to fix, it has support for not so useful effects (you can emulate them in bootsplash using mng anims, but you need a tool to create these), displaying errors in truetype fonts and getting password queries. suspend & resume already use it, so we have some experience with it - and a package ready.
I agree with you. However, splashy needs an fb console. Thus my question would be, if we can use the fb device created by the KMS drivers for the devices mentioned above. That would guarantee a smooth transition without flickering to the X.Org display. For other devices the VGA fb console should do the trick.
The problems I faced with splashy are: it flickers one more often than bootsplash as the kernel will setup the framebuffer and detect hardware and _then_ splashy comes up to paint over it. With bootsplash the kernel will display an initial graphic and _then_ the userspace will take over showing a progress bar. And I didn't yet experiment to see how we can go from initrd to booting, but that should be possible - splashy has chroot support.
Can we keep the kernel quiet until fb console is set up? That would get rid of this problem.
Now I wonder if we can leave the bootsplash kernel patch in and use it only to display the initial graphic. My experiments were with a vanilla kernel. Oppinions? Volunteers? :)
To be honest I would try to get rid of that ASAP in favor of the suggestion above. Cheers, Johannes P.S.: Please only use the email address jcnengel@googlemail.com and not wasabgeben@googlemail.com, since the second one is not my personal address. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org