Linux 2.6.23 was released a few hours ago. See the kernelnewbies changelog lots of details.
In addition to all the upstream changes, gentoo-sources-2.6.23 (which will be in portage very soon) has some Gentoo-specific feature changes worth noting:
vesafb-tng replaced with uvesafb
Michal is the author of vesafb-tng, which is popular as it allows you to use higher frequency refresh rates on the VESA framebuffer to stop you getting headaches on CRT monitors.
Michal has always been first to admit that vesafb-tng was an ugly hack and has no future. He’s now able to refrain from insulting his own coding abilities though, as he has reimplemented the functionality in a way that isn’t an ugly hack.
uvesafb is the replacement. The fundamental difference is that much of the functionality has been moved out of the kernel into userspace, so the kernel doesn’t have to worry about the ugly details.
The big change on the inside means that it’s unfortunately not a direct switchover to uvesafb from vesafb-tng. There are installation instructions on the uvesafb project homepage.
In fact, the uvesafb code is so non-ugly that it has been accepted into the upstream Linux kernel for the 2.6.24 release. Thanks Michal!
fbsplash replaced by fbcondecor
Michal also authored fbsplash, a kernel patch to allow you to place a pretty splash image behind the framebuffer console.
Due to confusion in the naming, fbsplash has been renamed to fbcondecor (FrameBuffer CONsole DECORations). However, this is just a simple rename, so the migration path is not difficult. See Michal’s blog for further details.
speakup isn’t back yet
speakup is an in-kernel speech synthesizer for blind/hard-of-sight Linux users.
We dropped speakup for 2.6.22 as it was no longer compatible with the kernel. I was planning to revive it for 2.6.23 but I haven’t had time, so it will have to wait for 2.6.24.
Um. How soon will v86d be stabilized? At the same time that gentoo-sources-2.6.23 is stabilized? Any ETA on when that will be?
While this news is certainly exciting (now my kernel source isn’t the only one that provides uvesafb!), I’m just now realizing it’s going to mean fairly extensive documentation changes.
Also, if Spock’s directions for running uvesafb will still be required, compiling a kernel will still be really stupidly hackish, and really, just completely unacceptable. We need our users to do what they do right now with gentoo-sources, which is just make menuconfig && make modules_install etc. Anything more complicated, like multiple configure/make cycles, emerging v86d and klibc . . . yeah. No? Please no. Also, dear LORD what will this do to all the poor folks that have to recompile kernels regularly for external drivers. Methinks module-rebuild won’t be enough?
Finally, I assume non-x86/amd64 users of gentoo-sources won’t have any problems with the kernel and using whatever framebuffer it is they use.
Very nice, thanks man. the ACPI laptop changes look cool, I know a few people that’s going to help out.
nightmorph, I think you’ve misunderstood uvesafb. At least, your comment doesn’t make much sense. find me on irc and I’ll clarify…
Daniel, it’s entirely possible. I’m on interesting pain medication at the moment. Right now I’m more lucid. My comment doesn’t make much sense to me, except the bit about the required installation/compilation steps for uvesafb and v86d as given in spock’s uvesafb homepage. Will users still have to perform about 10 steps to make them work? That’s my chief concern; that users will face additional hassle when working with their kernels. I was expressing my worry that the old easy way of doing kernels is gone, as outlined in the following scenario:
old way:
make menuconfig
make && make modules_install && make install (. . .etc.)
worrisome new way:
make menuconfig
make
emerge klibc
emerge v86d
make menuconfig
make && make modules_install && make install (. . . etc.)
We’ll take this to email if we have to; I don’t think I’ll be able to handle IRC yet. The less time I spend looking at computer screens, the less it hurts. :(
Exciting, Daniel.
On the speakup front, thanks for your efforts (plans) to maintain it, a friend of mine relies on it. I even tried to port it to 2.6.23, I failed (due to kernel console utf-8 conversion), but I’ll keep trying.
So I’m willing to test your patches / help out (if I am able to – I’m a junior C programmer), you may contact me on strohel (a.t) gmail (dott) com, if you want.