Archive for April, 2005

26
Apr
05

splashutils-1.1.9.4 released

More than 24h ago I released splashutils-1.1.9.4. The new version includes many bugfixes and some minor speed enhancements. Have a look at the ChangeLog for a full list of changes. 1.1.9.4 was delayed by almost a week, all because of a speed-up idea I had. Instead of preparing things for a release, I was modifying the code and testing the performance of the splash daemon. The result? A 10% speed-up and the code turned into a mess. Since 10% doesn’t justify making splashutils even more difficult to maintain and potentially introducing new bugs, I decided to drop the idea for now. Fortunately, I’ve already come up with a solution that should allow me to make the code faster without making a mess of it. If all goes well, splashutils-1.1.9.5 will be 10% faster (not that anyone would actually notice that — it will translate into a 0.2s faster boot-up in common configurations..).

And speaking of 1.1.9.5, I thought I should elaborate on what’s in the development roadmap for the next few versions. 1.1.9.5 will be a bugfix-only release. I hope to get it out in a few days, provided that I’m able to fix all the important bugs in time. Whether 1.1.9.6 will be bugfix-only or not depends on how many unresolved bugs are left after 1.1.9.5 :) After that, I plan to get MNG support merged into the main source tree. This will make it possible to have animated themes, which sure will look nice if used properly. What will happen next is unknown — I’ll probably have a look at my old gensplash to-do lists and try to find things that haven’t already been implemented in splashutils-1.1.9.x.

03
Apr
05

The future of gensplash

For those who didn’t figure it out yet, let me break the news: my previous blog entry was an April Fool’s Day joke. The gensplash project is not dead, fbsplash is not going to be removed from gentoo-sources and neither fbsplash nor splashutils will be abandoned. In fact, the development is going quite well, and fbsplash+splashutils is gaining popularity, being used not only in Gentoo but also in a few other distros. The word is it will also be added to software-suspend 2. So the project is anything but dead :)

However, as people say, there is a grain of truth in every story and in every legend. And our case is not very different. While the gensplash project will not be discontinued, some things will have to be changed. Originally, the whole project was divided into two stages — stage 1 being fbsplash+splashutils and stage 2 — the final ‘gensplash’ program with all the fancy features. It was supposed to use the DirectFB library and XML config files. The way I see it now, neither of these was a good idea. DirectFB has proven to be difficult to use in the harsh conditions of the initial boot stages, and it increased the number of dependencies heavily. XML config files were something I came up with because I was too lazy to write a new config file parser from scratch ;)

As it turned out, it is possible to include virtually all gensplash features in splashutils, keeping the deps as minimal as possible and making the whole thing easy to manage. Support for icons and TTF fonts is already in place. So is support for the ‘daemon’ mode. Support for MNG animations will be coming soon. The current config file format seems to be flexible enough to handle new features as they get added to splashutils. The code handles various framebuffer formats quite well. And all this is possible without DirectFB, XML and other things that would make splashutils bloated.

So, to summarize, what is the meaning of all this? Well, there will most likely be no ‘gensplash’ app. The features that were planned for it will be added to splashutils, and care will be taken to keep the code as fast, lean and clean as possible. With the ‘release early, release often’ attitude that I have adopted now, splashutils 1.2.0 should be the equivalent of ‘gensplash stage 2’.

Is there a grain of truth in the statements about porting vesafb-tng to amd64/pcc and me helping the GeNToo project with the development of a graphics subsystem? Well, I’ll leave these two for people to figure out themselves :)

01
Apr
05

The gensplash project cancelled

After some 8 months without a single release of the “stage 2” version of gensplash, the time has come to cancel the project. The probability of ever completing it has been getting lower and lower with every passing week. It was about a month ago that I realized that something has to be done. Struggling with various technical problems with the current, unreleased gensplash code, I decided that it would best to simply cancel the project.

Does it mean that Gentoo will be left without a ‘bootsplash’ solution? One of the reasons it took me a month to come to the final conclusion is that I always wanted to provide an alternative solution. Obviously, being left with fbsplash and splashutils is not an option — without the gensplash project kicking, they will probably soon be abandoned. One alternative was going back to bootsplash. While it doesn’t provide all the eye candy that I once promised to deliver, it has proven stable over the years and it’s still widely supported. Its code is fast, clean, and easy to debug. Having the JPG decoder in the kernel, which has once been thought of as a disadvantage, seems to be a good solution. Neither developers, nor users seem to mind adding a few bytes to the kernel image. After almost making the decision to switch back to bootsplash, another idea came to my mind. I recalled a project called ‘rhgb’, which is a ‘bootsplash’ solution used in Fedora and Red Hat systems. After doing some initial tests and considering both its advantages and disadvantages, I came to the conslusion that this is the perfect solution for Gentoo. True, it might lengthen the boot process by some 10s or so, and it won’t make it possible to display images during early boot (ie. when the kernel is still initializing its subsystems), but these are a low price to pay for the new features. I’m sure no one will mind watching a black screen for a little longer during the initial boot stages. With rhgb, we will be starting an X server somewhere during the ‘sysinit’ runlevel. Thanks to the capabilities of X and GTK, it will be possible to use rhgb to handle the
verbose mode. This means that fbsplash will be removed from the newer gentoo
kernels.

Thanks to the flexible splash initscripts introduced a few months ago, the move to rhgb should be complete within as little as one week. Please stay tuned for more updates.

The precious development time saved thanks to this move will be used for more interesting projects, such as porting vesafb-tng to amd64 and ppc. I am also looking forward to working on graphics support for the GeNToo project. If all goes well, rhgb will be supported in GeNToo as well.