| 1 |
On Mon, Jul 21, 2014 at 9:16 PM, Ian Stakenvicius <axs@g.o> wrote: |
| 2 |
> I'm not against dropping splashutils, but is there an alternative to |
| 3 |
> creating or managing framebuffer-splash in the tree? fbsplash doesn't |
| 4 |
> seem to be there (tho i don't know if that's the same upstream package |
| 5 |
> or not) |
| 6 |
|
| 7 |
Fbsplash is a part of splashutils. There is also an fbcondecor kernel |
| 8 |
patch, apparently maintained by someone else now. Splashutils have an |
| 9 |
extremely complex structure of daemons, control programs, and |
| 10 |
interaction with the kernel via UVESAFB — I had to revisit this |
| 11 |
structure every time I had to change something wrt. splashutils |
| 12 |
integration. |
| 13 |
|
| 14 |
Not to claim that plymouth is the solution — last time I tried it (~ 2 |
| 15 |
years ago) it was practically unusable with OpenRC. It took control of |
| 16 |
the console in some weird and buggy way, etc. I guess you could |
| 17 |
integrate it into a specific system with specific video driver, but I |
| 18 |
gave up on plymouth as a generic solution. Maybe it works well with |
| 19 |
systemd, but from what I gathered the last time, it is (or used to be) |
| 20 |
explicitly disabled on unsupported video cards by the relevant |
| 21 |
distros. |
| 22 |
|
| 23 |
-- |
| 24 |
Maxim Kammerer |
| 25 |
Liberté Linux: http://dee.su/liberte |
Archives