USplash/Splashy - Current status

KerowynM · 2007-05-15 23:53:47

Anybody know where I can grab splashy-0.3.2-4? *-7 looks great, but it's waaaaaayyyy toooooo slllllooooowww.

Fun stuff, but I almost miss my daemons loading

Edit: Sorry, I found the link in the AUR thread... reading comprehension FTW....

Edit2: *-4 was just as slow as *-7 for me. Other than the speed it works great.

Last edited by KerowynM (2007-05-16 00:35:39)

baze · 2007-05-16 04:56:48

-7 contains the working files from -4 so that one should work fine. it does for me.

KerowynM · 2007-05-16 05:51:51

Well, that explains the similar results. Did I perhaps miss a step or something?

dtw · 2007-05-16 18:35:39

djclue917 wrote:

I'm actually thinking about doing the latter because, in the original Debian package, that's really how it was done. I'd file a feature request soon after I've cleaned up Splashy some more, added more comments and documentation, and some other stuff. I was actually planning on orphaning Splashy and leaving the work to the devs/TUs who are interested in further improving Splashy on Arch.

OK, well, I'm up to the challenge. I already mailed you before I saw this.

I think you have done some great work on Splashy and I can see that you so far avoided getting into the Arch initscripts, which is pretty impressive but probably not as efficient as it could be.

I think we can easily add some basic hooks to the existing initscripts, based largely on the implementation of gensplash. I think gensplash messes more with the initscripts than most other implementations of splash so I think starting there is smart. This patch shows what gensplash changes. From this I think it is easy to see how a wrapper between the hooks and the necessary commands could work. If every splash pkg installs a wrapper with a pre-defined set of commands to a default location we can call this easily from hooks.

I'll build a new gensplash pkg to show you what I mean...it's the best way I think.

dtw · 2007-05-16 21:14:25

OK, here are the files I have in mind. The first is an update patch, which includes hooks for the initscripts. Basically this is about the minimum support we need from Arch.

Now, this is the wrapper, which is called by the hooks, which in turn calls the functions and commands specific to that splash method. It's total psuedo code (disguised as functions) and might work either as a file sourced by rc.sysinit, or actually as a big fat rc.d like script. The later is probably nicer but I couldn't be bothered to do that.

It's worth noting though that all functions would need to be included in the wrapper, even if they aren't used, hence the /bin/true command in my example.

This way the same hooks can refer to consistent set of functions.

It's worth adding that splashy has a nice implementation of an rc.d script which starts and stops the script at shutdown and startup respectively. That could work as is or could be called by the wrapper boot and exit hooks.

Feedback?

iphitus · 2007-05-17 09:32:32

dtw wrote:

OK, here are the files I have in mind. The first is an update patch, which includes hooks for the initscripts. Basically this is about the minimum support we need from Arch.
Now, this is the wrapper, which is called by the hooks, which in turn calls the functions and commands specific to that splash method. It's total psuedo code (disguised as functions) and might work either as a file sourced by rc.sysinit, or actually as a big fat rc.d like script. The later is probably nicer but I couldn't be bothered to do that.
It's worth noting though that all functions would need to be included in the wrapper, even if they aren't used, hence the /bin/true command in my example.
This way the same hooks can refer to consistent set of functions.
It's worth adding that splashy has a nice implementation of an rc.d script which starts and stops the script at shutdown and startup respectively. That could work as is or could be called by the wrapper boot and exit hooks.
Feedback?

just a tip, test things with options disabled. I havn't tested the above myself, but from observation....

/etc/rc.d/functions will barf if /etc/rc.d/$SPLASH-functions doesnt exist, breaking the scripts if splash is disabled. Fix:

if [ -f /etc/rc.d/$SPLASH-functions -a -n $SPLASH ]; then
 . /etc/rc.d/$SPLASH-functions
fi

and
if the ${SPLASH}_wrapper command doesnt exist, (eg, SPLASH="" or undefined), the scripts will probably barf with errors (command not found).

if [ -f /sbin/$SPLASH_wrapper -a -n $SPLASH ]; then
  run whatever splash_wrapper thingy
fi

THat tests for whether the wrapper exists (-f) and if $SPLASH is non zero in value.

Lastly, this one is more style, but IMHO, move the config out of rc.conf, to /etc/conf.d/splash, and have that sourced when sourcing /etc/rc.d/splash-functions, it's not important enough for rc.conf.

James

dtw · 2007-05-17 09:46:48

Er...thanks, iph. Valuable points but it was feedback on the theory and approach I was aiming for here, not elementary bash advice

djclue917 · 2007-05-19 17:53:12

Do we run Splashy "normally" or from initramfs? I have to ask this because Splashy manifests some problems when running from initramfs. One such problem is that even after Splashy terminates (e.g., ESC is pressed), its image is left in the framebuffer. In effect, the display doesn't go back to text mode. I've already confirmed that the said problem doesn't happen when Splashy is run "normally", i.e., not from initramfs. Any ideas? Or did I just missed anything?

Xilon · 2007-05-19 18:15:58

Yes this does seem like a bug. After booting you are simply left with the image. To get the console back you can just ctrl+alt+F1 or whatever, or you can simply install a login manager like I did.

dtw · 2007-05-19 23:14:28

I'm guessing the change VT command is not working there then....

dongiovanni · 2007-05-20 19:29:06

Splashy looks _realy_ good! The only problem is, that Arch needs on my pc much more time to boot! (about 4 times!). Can I anything do against it?

dtw · 2007-05-20 20:12:10

dongiovanni wrote:

Splashy looks _realy_ good! The only problem is, that Arch needs on my pc much more time to boot! (about 4 times!). Can I anything do against it?

Hopefully we can. I have spent most of the weekend with a headache (from various causes) so I have not had much time to look at it. I also need to speak to an Arch dev to find exactly what support they are happy to include. Volunteers?

iphitus · 2007-05-21 02:33:47

dtw wrote:

Er...thanks, iph. Valuable points but it was feedback on the theory and approach I was aiming for here, not elementary bash advice

oh ok I thought you intended it as an implementation.

well i did suggest you move the config file to /etc/conf.d

dtw · 2007-05-21 07:53:35

iphitus wrote:

well i did suggest you move the config file to /etc/conf.d

Well, the problem with that is I then have to source that config file from each start-up script, which I think pollutes the scripts unecessarily. If Arch will let us add the wrapper hooks to the start-up scripts then it make sense that the config go in rc.conf...but then, I guess I forgot we're talking about a generic initscripts-splash pkg not full splash support in the stock initscripts...doh! I'll get my coat...and finish the scripts tonight!

iphitus · 2007-05-21 08:42:34

dtw wrote:

iphitus wrote:
well i did suggest you move the config file to /etc/conf.d
Well, the problem with that is I then have to source that config file from each start-up script, which I think pollutes the scripts unecessarily.

Not really, no harm in it at all. It'll only be read from the hdd the first time, and from then on it will exist in cache. Sourcing a script of that size has negligable cost <0.01s.

If Arch will let us add the wrapper hooks to the start-up scripts then it make sense that the config go in rc.conf...but then, I guess I forgot we're talking about a generic initscripts-splash pkg not full splash support in the stock initscripts...doh!

I'd merge the patch as suggested with my changes to the stock scripts -- they're fairly minor. That's if it was my choice. File a bug report, i'll nag some devs, and if it's given the OK, ill merge it for ya.

I still think seperate /etc/conf.d/ is the way to go, as plenty of other things go there, and splash is not remotely as important as anything else in rc.conf. A splash application is an addon package, so ought to be stored seperately --we don't want to confuse new users with these splash options in rc.conf who dont have splashy installed.

James

dtw · 2007-05-21 09:04:34

iphitus wrote:

I still think seperate /etc/conf.d/ is the way to go, as plenty of other things go there, and splash is not remotely as important as anything else in rc.conf. A splash application is an addon package, so ought to be stored seperately --we don't want to confuse new users with these splash options in rc.conf who dont have splashy installed.
James

OK, I concede all that as sound points. The problem is though each splash pkg will have it's own "daemon" in rc.d with a relevant conf file in conf.d. If they have a common config file in conf.d then that's not as KISS as it could be, it also raises an issue of ownership of that file by a pkg, you wouldn't want each pkg to have it's own for example. That suggests the addition of a new file to the initscripts pkg which would contain, at most, two variables that doesn't seem to cool to me. This could be avoided by making the splash implementations mutually exclusive (i.e. conflict in pacman) but that almost defeats the point of generic splash support.

I'm sure rc.conf is not the best place for the vars but what's a good solution for that one file? That's my quandry.

iphitus · 2007-05-21 09:30:26

dtw wrote:

iphitus wrote:
I still think seperate /etc/conf.d/ is the way to go, as plenty of other things go there, and splash is not remotely as important as anything else in rc.conf. A splash application is an addon package, so ought to be stored seperately --we don't want to confuse new users with these splash options in rc.conf who dont have splashy installed.
James
OK, I concede all that as sound points. The problem is though each splash pkg will have it's own "daemon" in rc.d with a relevant conf file in conf.d. If they have a common config file in conf.d then that's not as KISS as it could be, it also raises an issue of ownership of that file by a
pkg, you wouldn't want each pkg to have it's own for example.

That suggests the addition of a new file to the initscripts pkg which would contain, at most, two variables that doesn't seem to cool to me.

Maybe. Depending on the implementation, it could be used for other things, such as theme, resolution...

This could be avoided by making the splash implementations mutually exclusive (i.e. conflict in pacman) but that almost defeats the point of generic splash support.
I'm sure rc.conf is not the best place for the vars but what's a good solution for that one file? That's my quandry.

I think that one file is sufficient on it's own. It's not that bad, one tiny file is hardly going to cause any heartache.

Alternatively, how about just SPLASH= in /etc/rc.conf, and any other variables in /etc/conf.d/splashname, to be sourced automatically by scripts? I don't think verbose on fail is important enough to go into rc.conf, putting it there sets a precedent for other splash options to be placed there.

However, to get this merged to stock initscripts, it'd probably be better if you dont have much in rc.conf, as some people may be quite opposed to it.

James

dtw · 2007-05-21 10:47:00

iphitus wrote:

Maybe. Depending on the implementation, it could be used for other things, such as theme, resolution...

Hmmm, maybe, might be a nice idea but would require some serious jigging of the curretn implmentation becuase ATM they look in their own config files...plus ome potions ar eunique to one implementation. So this would not be best IMO.

iphitus wrote:

I think that one file is sufficient on it's own. It's not that bad, one tiny file is hardly going to cause any heartache.
Alternatively, how about just SPLASH= in /etc/rc.conf, and any other variables in /etc/conf.d/splashname, to be sourced automatically by scripts? I don't think verbose on fail is important enough to go into rc.conf, putting it there sets a precedent for other splash options to be placed there.
However, to get this merged to stock initscripts, it'd probably be better if you dont have much in rc.conf, as some people may be quite opposed to it.

I think that's a pretty decent compromise. VERBOSEONFAIL may not work with some implementations anyway so could be spurious in some cases.

So, yeah, if we could get the hooks in the initscripts and SPLASH in the rc.conf file that'd be nice.

If we do do the official support for splash then non-stock kernels that support splash can still be support by the right pkgs, which I think is really nice for users.

aRcHaTe · 2007-06-01 05:12:40

how can i configure to use allways on verbose mode?

djclue917 · 2007-07-04 15:20:44

Hi all, I just want to inform you that I am no longer maintaining the Splashy package in AUR. The current maintainer is now imachine.

dtw · 2007-07-04 16:24:23

I'll be putting a veriosn in community as soon as I get it working with initscripts pkg ;-)

Arch Linux

#76 2007-05-15 23:53:47

Re: USplash/Splashy - Current status

#77 2007-05-16 04:56:48

Re: USplash/Splashy - Current status

#78 2007-05-16 05:51:51

Re: USplash/Splashy - Current status

#79 2007-05-16 18:35:39

Re: USplash/Splashy - Current status

#80 2007-05-16 21:14:25

Re: USplash/Splashy - Current status

#81 2007-05-17 09:32:32

Re: USplash/Splashy - Current status

#82 2007-05-17 09:46:48

Re: USplash/Splashy - Current status

#83 2007-05-19 17:53:12

Re: USplash/Splashy - Current status

#84 2007-05-19 18:15:58

Re: USplash/Splashy - Current status

#85 2007-05-19 23:14:28

Re: USplash/Splashy - Current status

#86 2007-05-20 19:29:06

Re: USplash/Splashy - Current status

#87 2007-05-20 20:12:10

Re: USplash/Splashy - Current status

#88 2007-05-21 02:33:47

Re: USplash/Splashy - Current status

#89 2007-05-21 07:53:35

Re: USplash/Splashy - Current status

#90 2007-05-21 08:42:34

Re: USplash/Splashy - Current status

#91 2007-05-21 09:04:34

Re: USplash/Splashy - Current status

#92 2007-05-21 09:30:26

Re: USplash/Splashy - Current status

#93 2007-05-21 10:47:00

Re: USplash/Splashy - Current status

#94 2007-06-01 05:12:40

Re: USplash/Splashy - Current status

#95 2007-07-04 15:20:44

Re: USplash/Splashy - Current status

#96 2007-07-04 16:24:23

Re: USplash/Splashy - Current status

Board footer