The X.org radeon driver continues to be very stable with Mesa 7.7 and a newer libdrm (2.4.17), and now I'm running the Linux kernel 2.6.32.2. When building it for the first time, I enabled ACPI S3 suspend (to RAM) support in the configuration because I had initially planned to try it with the kernel mode-setting drivers (that part of the plan got scrapped when I found out that the KMS drivers are not intended to work well for 3D yet) — so, after rebooting, I noticed a new button in the power management widget in KDE's panel.

A shiny new button... S3 suspend had not worked for me during all this time because uswsusp and the kernel were unable to bring the keyboard, touchpad and screen back to life when resuming normal system operation, so I had disabled support for it in the configuration for many kernel versions for fear of accidentally suspending to RAM instead of disk, and losing my current work as a consequence.

However, the power of Debian Squeeze's current hibernate script package (?), the vanilla+TuxOnIce 2.6.32 kernel, and all the new graphics drivers, seems to do miracles. Suspend-to-RAM works at last on this laptop! After a year of fiddling with build and run-time kernel configuration and tools! (And this is why it's a bad idea to run Linux on a brand-new laptop; but I knew it was going to be like this and still went ahead, mind you.)

This means that the ATI mayhem is over (well, except for a little problem), and now that I can run some of my favorite OpenGL-based software, suspend to RAM and disk safely and run KDE 4, my mission is complete my work here is done. My local builds of this software are my very own Christmas gift this year.

Yays for the open-source community! \o/

The End.

...OR IS IT?

Some days ago, I was told that Google had released a beta version of their Chrome browser for the GNU/Linux operating systems, all in middle of a discussion about how much Failbox sucked — er, I mean Firefox.

So, I downloaded a Debian package, installed, ran the application, and it crashed on my face right after trying to show the first-run page. That's not a very good start; not even Firefox does that. Then I try to run it again, it worked, okay.

Google Chrome seems to be rather nice, and reminds me of Apple's Safari in appearance. It's fairly quick to start compared to Firefox/Iceweasel 3.0 and 3.5 (which I now got from the Debian testing distribution), and its simplicity feels generally comfortable. I could quickly find an extension for hiding ads and browse some web pages afterwards.

It's pretty nice for testing web pages and even has some neat web development features. However, I'm probably not using it for regular browsing since it lacks an off-line browsing mode option as far as I can see. I have very good reasons for requiring that feature that Opera, Firefox and even Internet Explorer provide. Also, it doesn't respect some fontconfig settings in Debian Squeeze for some reason.

Besides that, I got switched to Iceweasel 3.5 as a consequence of running aptitude full-upgrade blindly. It does appear to be more stable than Iceweasel and Mozilla Firefox 3.0, although I should wait some more time before assuming this to be true; the 3.0 bugs on amd64 Linux were pretty random and sometimes I could run the browser for days without crashing, and in other occasions it would crash after running for a few seconds, while trying to contact a web server for the first time in the session.

There are no visible UI changes in 3.5 as far as I'm concerned (besides the tab bar, and some menu icons which got some hue changes), and some glitches remain — for example, scrolling pages is less laggy now, but only if smooth scrolling is disabled; and the status bar still glitches for the current web site if one clicks on a single link a lot. However, I've heard rumors that many security vulnerabilities were fixed in this version, so I guess it's a reasonable trade-off; not that I'd visit suspicious websites, or worse, run a web browser on Windows.

So, for now, I still use Opera when I need reliability, and Firefox when I forget that I'm supposed to use Opera.

Although the combination of drm/radeon, the X.org radeon module and newer Mesa drivers (now using 7.7 RC 2) is pretty much stable for me at the moment, I keep hitting what probably is a bug in the synaptics touchpad driver (X.org), which I recently updated while following other new packages in the Debian testing distribution (currently Squeeze) — the X server occasionally locks up when restarting via kdm (KDE's login and display manager) and the last bits in the logs indicate that it's trying to process the input device configuration; plus, the busy 'X' cursor appears on the screen before it gets locked up. Again, pressing the system's ACPI power-down button helps and I don't need to resort to “emergency” reboots.

Besides that little annoyance, there's the infamous BSS I mentioned in earlier iterations of this story. However, I have found a tricky solution to this dreaded disease with a non-KMS configuration.

Basically, I must first get to a text-mode console (read: text-mode, not a graphics framebuffer console, although I suppose it could work as well) and save the graphics hardware state for later with vbetool as root:

# vbetool vbestate save > ~/textmode_vbestate

Then I create an appropriately named set of screen sessions as my normal user from a text-mode console; say, screen -S radeonfix, and don't detach it from the terminal. Later, when radeon finally screws up, I reattach from a terminal emulator under X using screen -x radeonfix (where -x is for attaching to the session without detaching it from the real text-mode console, which we'll need) and type the magic words, but do NOT run the last command as it could harm X.org or the hardware in some way:

$ su
# vbetool vbestate restore < ~/textmode_vbestate

Then I switch back to the console (which is under the effects of BSS by now) that has the same screen session attached and blindly press Enter. Voilà! I get a “Function not supported” warning but it still restores the text-mode console to normality without having to restart the whole system. However, the X.org radeon module is trying to be too smart and causes BSS again after I switch back and out of X. This seems to happen because it's attempting to do a similar function with its own copy of the hardware state, unfortunately captured after breaking the consoles. The solution? Kill and restart X right after using vbetool to fix the text-mode consoles and before switching back to X (or otherwise you won't be able to see the command you're typing to restart X) — this way radeon starts fresh and grabs a copy of the good hardware state.

It's probably not necessary to grab the hardware state with vbetool upon every boot, as long as it is compatible. I have successfully used an old captured state with the same console settings.

If I had a separate machine from which I could connect to the laptop, I'd be able to attach in multi-display mode to the screen session using SSH, but since I don't, I have to do this unelegant maneuver with a running X. And if there's no X running, well, crap. Fortunately the BSS is fairly inoffensive otherwise, and console applications will still receive input events normally, including the CTRL+ALT+DEL sequence and the machine's ACPI power-down button.

Note that the aforementioned theory may also serve as basis to explain why radeon + KMS causes immediate BSS for me. Let me think:

Firstly, X.org starts up, radeon loads the kernel's drm and radeon modules, they take over the text consoles using a special KMS-based framebuffer driver as soon as I switch away from X. But radeon (the X.org driver) keeps a copy of the hardware state taken at X's startup, when there was no framebuffer driver managing the consoles, so it has the state of the controller in text mode. Later, when I switch to a text terminal from X for the second time, the X.org driver switches the controller to the text mode state. Oops! That won't work very well with a framebuffer (read: graphics mode) console driver, he he! So the theoretical solutions are:

1. Make drm/radeon part of the kernel image in the build configuration; or
2. Insert drm/radeon when running /etc/rc.local, that is, before X starts.

I could easily try these but I'm currently enjoying this basic accelerated 3D rendering, which I guess — just like XRender acceleration — won't work with KMS. I've also heard rumors that ATI R6xx/R7xx KMS and hibernation are not a perfect combination yet, so I'd better keep away from it for now, lest my files literally go to hell.

Freenode's staff and a group of users have been busy testing ircd-seven, the ircd which will eventually replace the aging collection of ugly hacks known as hyperion-ircd. So far it seems I've been the only one who's found and reported bugs in channel management code (account bans + forwarding, in particular), which is a pity; we need more testers!

Occasionally, the server instances get restarted and some people complain.

I think I cannot complain, because I just got my own 10 seconds of fame. It's a pity that I didn't have a better one-liner or a larger audience for the occasion!

<@shadowmaster> eh.

(And if you don't use freenode or IRC at all, you won't understand any of this.

In my endless quest to make all the features of this ATI RS780-based HP laptop work completely with Debian GNU/Linux, I have come to great lengths. In summary, I have:

• Learned to use X.org modules from their upstream repositories and keep them always up-to-date, commit by commit;
• Patched the ACPI DSDT to gain thermal zone readings on Linux;
• Blown up the X server with ATI's crappy proprietary driver, fglrx;
• Nuked shared libraries in /usr/lib after attempting to use an RC Linux kernel version from mainline; and
• Upgraded Debian Lenny (stable) to Debian Squeeze (current testing distribution) and acquired superpowers involving the manipulation of time learned to use Tux-On-Ice.

Other people would have given up very quickly and sticked with Windows Vista, but no, here I am, spending time researching the problems in detail and running fsck after every forced reboot and reporting back to my Lair.

Fortunately, now I can see the light at the end of this very convoluted dark... tunnel thingy, and I have finally found the solution for one of the problems I have long sought to solve: the lack of accelerated 3D rendering.

The last time I messed with the graphic drivers in this ATI RS780-based laptop, things didn't go so well with fglrx and I had to go back to the X.org radeon module in order to protect whatever piece of hardware made a buzzing sound with ATI's proprietary drivers.

I knew that radeon occasionally failed to restore non-X framebuffer consoles and they become black screens. Now I've unfortunately confirmed that this does not affect just the framebuffer (fbcon/vesafb) consoles, but also plain text-mode consoles. It's probably a known bug that this happens under some conditions, however this snippet of code in radeon's source code (src/radeon_driver.c) does not give me much hope since it's been around since 2003 according to the commit logs:

#if 1
    /* Temp fix to "solve" VT switch problems.  When switching VTs on
     * some systems, the console can either hang or the fonts can be
     * corrupted.  This hack solves the problem 99% of the time.  A
     * correct fix is being worked on.
     */
    usleep(100000);
#endif

Interestingly radeon inserts long extra delays (thousands of µsec) for many operations “just in case”, whereas radeonhd uses delays of less than 10 µsec in all but one case.

Nevertheless, I've not stumbled upon any race condition when resuming X.org from hibernation with this driver, although it's only had chances for acting up during 5 days — that is, 5 hibernation cycles. When it was the time for the 6th cycle, I upgraded Squeeze's X.org synaptics driver and restarted the X server, and it mysteriously locked up forever, forcing me to reboot the whole system — although there was still a process listening to the laptop's power button event so it was a safe shutdown. Since X stopped logging when it locked up, I cannot really prove that radeon wasn't at fault there, but I strongly suspect it was the synaptics driver upgrade what caused it. The kernel logs don't indicate anything unusual at that time either.

And in other news, the Linux kernel version 2.6.32 has been released, and one of the many changes in this version includes Kernel Mode-setting for the ATI R7xx chipsets. I guess I'll check it out once there's a Tux-On-Ice patch for it and I feel like replacing Debian's libdrm with an upstream version.

UPDATE: there's a Tux-On-Ice patch (3.0.99.32) for this version now. You know what that means. Let's rock!

While checking the Wesnoth.org forums ensuring that everything is working properly, I occasionally find spambots who have managed to make it past our hacky anti-bot registration measures, probably with help from humans. Most of these spambots go into a hit-and-run attack leaving one spammy post in some random place of the forums — sometimes in existing threads, sometimes starting new threads themselves.

Two nights ago (November 30th, 4:45 AM), some guy came into our Off-topic section asking this:

Post subject: Linux

How long does it take to become a Linux Administrator? Also is 1 year of linux study enough to get a job as System linux administrator? What exactly do I need to learn to achieve that goal?

It was his first post, and there were no signature or links whatsoever. He joined the forums two days before that (November 28th, 8:08 AM). You may note that the message above is not in proper English, but there are many underage or foreign users in the board. Nonetheless, some regulars and I replied to this guy's message in good faith.

On the next day, December 1st 8:36 AM, “he” edits his message adding spammy links after a fake signature separator similar to the phpBB 3 subsilver2 template's, except a bit longer. The post spent approximately 14 hours as search-engine bait because no other Wesnoth developers noticed the cheat (or read the Off-Topic forum, I guess) and I was away for the whole day until I went in and found this surprise after a third look at the thread.

Fascinating.

In one occasion I had one of these drones join the forums and make their first spam post after 6 weeks (and shortly get kicked out of the house by my Mighty Foot™). I guess it must have been collecting posts and feeding them to a learning engine in order to enhance future spam posts by fitting them into the board's context for the time being. Not that its own attempt at posting succeeded.

The problem is that they sometimes do manage to produce reasonable posts — as long as you use a very flexible definition of “reasonable”, which is more or less required around the Wesnoth.org forums these days especially since there are real people who join the board and never post anything constructive or interesting and roam just the Off-Topic forum asking weird, unimportant questions and answering other weird, unimportant questions with bogus, misleading or uninformed answers or opinions (no, not pointing at anyone in particular here). On the other hand, it's still possible that those weird guys or gals will eventually drop their masks and reveal their true identities as spambots. Or maybe someone else will remove it for them.

libpng is a the reference implementation of the PNG file format, which has become quite popular during the last decade thanks to the benefits of lossless compression coupled with multiple storage formats — including indexed pixmaps, RGB pixmaps with optional alpha channel, or 256 grayscale colors, adding Adam7 interlacing as an option to allow displaying incomplete drafts of images before reading all the pixmap data in the stream. It also allows for some metadata such as text comments and internal timestamps, or even unknown chunks of (meta)data, allowing it to become a container format of sorts, most infamously abused by Mozilla Firefox to implement animated PNGs through a slightly modified version of the library — because lossless RGB pixmaps with alpha transparency are so cool compared to indexed pixmaps with binary opacity...

As cool as this sounds, libpng by itself is a trap for the unexperienced and/or impatient programmer, of which I fall into the latter category.

The API allows for many different applications, resulting in a convoluted interface and some poor or missing documentation for it. Reading the manual and examples included with it does not help a lot; when skimming through the header one can find some undocumented interfaces. It's a hell of flexibility that makes me feel lost in middle of a big forest without a map.

I foolishly wrote Wesnoth-TC without knowing any of this beforehand, and ended up creating a monster known as version 1.0, which is a mess of quickly crafted ugly code that breaks under big-endian platforms and leaves huge memory leaks when running on anything. I could have used a different library but I didn't have more documentation than libpng's at the time. Now that I'm preparing to release Wesnoth-TC 1.5.0 and have learned to keep away from this library, I'm turning my attention to wrapper libraries that should be hopefully much easier to work with if I just want to read and write ARGB streams from/to PNG files.

But Wesnoth-TC 1.5.0 will still use libpng, although I'll rewrite the code that uses it. Why? Because this time, It's Personal.