The last post (minus the hard disk driver crash during preparation for S3 issue) turns out to be a rather embarrassing case of not doing the research, so I deserve a punch from a drm/radeon dev for that.

What I should've done if I were connected to the Internet at the time I decided to start to experiment with KMS again, is reading the instructions from the X.org wiki for properly setting up the drivers with KMS support. It wasn't as trivial as I had expected because of the missing firmware blobs I mentioned the last time.

I was hoping to not have any more problems with Linux and my HP Pavilion dv5-1132la laptop since the last installment of this series of posts. However, with the release of Linux 2.6.33 and the improvements on KMS and general direct rendering support for the ATI R6xx and R7xx chipsets, I wanted to give KMS a try — this kernel version also improves support for some HDMI thing that I don't understand exactly what it is about, apparently related to digital audio devices or something.

(In other words, I shouldn't be complaining. Most of what comes in this post is the result of a voluntary experiment, and not some unfortunate incompatibility...probably.)

I use KDE 4...

Sounds suicidal? Go check your facts. Anyway, I use Mesa 7.7 for 3D, plus libdrm and the X.org radeon driver from their git repositories. The system is Debian Squeeze, but it's a few weeks behind testing because I've not had access to a strong connection to download the shitload of packages (~350 MB) for upgrading.

I normally use the QtCurve style for Qt3, Qt4 and Gtk2 applications, but last night I decided to give Nitrogen-style (based on Oxygen) a go again.

I found that if I open Konqueror's bookmarks menu, when it has many more elements than they fit in the whole screen, X.org crashes!

Backtrace:
0: /usr/bin/X(xorg_backtrace+0x26) [0x4ee056]
1: /usr/bin/X(xf86SigHandler+0x39) [0x484199]
2: /lib/libc.so.6 [0x7ffc172e8fd0]
3: /usr/lib/dri/r600_dri.so(r600SetTexOffset+0x8b) [0x7ffc028e306b]
4: /usr/lib/xorg/modules/extensions//libglx.so [0x7ffc163b911c]
5: /usr/lib/xorg/modules/extensions//libglx.so(__glXleaveServer+0x18) [0x7ffc163affa8]
6: /usr/lib/xorg/modules/extensions//libglx.so [0x7ffc163b055f]
7: /usr/bin/X(Dispatch+0x374) [0x44d494]
8: /usr/bin/X(main+0x3aa) [0x43337a]
9: /lib/libc.so.6(__libc_start_main+0xfd) [0x7ffc172d5abd]
10: /usr/bin/X [0x432819]

Fatal server error:
Caught signal 11.  Server aborting

It reproduces with the Oxygen theme too. All with KDE 4.3.2 — but the crash seems to come via Mesa 7.7's ATI R6xx/R7xx DRI driver. Ah, yays for newborn drivers.

Finally, it's January! The New Year celebrations are mostly over and fading away, and people all around the world are going back to regular business and everything should be back to normal in a few days.

I used to be fond of the Christmas and New Year celebrations as a child as I could spend time with my family and eat delicious food. That is not the case anymore, because, even if I still live with my parents, there's no longer a sense of family here and we only want to throw sharp stuff at each other. There's not much enthusiasm by the end of the year anymore, and phrases such as “Merry Christmas” and “Happy New Year” (in Spanish, though) are truly unheard of in this house. Recent disagreements amongst us indicate that this is not going to be a good year for anyone. To add insult to injury, one of our cats died in a rather tragic and violent fashion on December 22th — it's a tradition here that one or more pets must always die in December. While we have many of them, the first ones to die are those whom we are most attached to.

To mark the actual start of 2010 (as far as the Gregorian calendar is involved, of course), there was a black-out on the area about 6 minutes 7 seconds past midnight, which left us with no Internet or tap water until around 1:50 AM. What a great way to start the first day of the year.

(In case there's doubt — I assure you, I'm not making any of this up.)

But there's still some hope at the moment. Some days before Xmas, my creativity returned from its long, chaotic journey and my Wesnoth add-on, After the Storm (sequel to Invasion from the Unknown has seen steady progress and two new releases were published in less than two weeks. Keep in mind that this add-on had not seen any public releases for almost a year.

After the last released version of AtS (0.2.1) including 5 of 12 planned scenarios in Episode I, there has been more progress in the Wesnoth-UMC-Dev repository. Just yesterday, I finished the two-part cutscene that is the sixth scenario of Episode I, one of the most important points of the plot's development, in which two forest elves finally make contact with the desert/Quenoth elves.

I won't be able to release AtS 0.2.2 or 0.3.0 until scenario 7 and the next cutscene (appropriately named “Resolutions”) are finished, since I'd be teasing the players otherwise. However, those who are really interested on it can always check AtS out from the repository's trunk into their <wesnoth preferences dir>/data/add-ons dir and play using the latest development version of Wesnoth:

svn co https://wesnoth-umc-dev.svn.sourceforge.net/svnroot/wesnoth-umc-dev/trunk/After_the_Storm

It's really exciting to work with several plot elements from quartex's Under the Burning Suns in new, creative manners — kind of like Fanfic production taken to a new level using the power of the GNU General Public License (version 2 or later!). Nevertheless, I am fairly sure he deliberately left much details unresolved in the original campaign, and that he'd fry us (Espreon, AI0867 and me) alive if he found out what we are doing with his story.

One week before Xmas, the Wesnoth.org forums saw another upgrade on which Turuk and I worked hard and quickly to improve forum usability by not only upgrading the codebase to phpBB 3.0.6, but also tweaking the templates, adding modifications and a couple of new forum styles to take advantage of the new features implemented by the phpBB devs in this iteration of their software. The main points were highlighted in this forum post (originally a Global Announcement).

This year should also bring us a new stable series (1.8) of the Battle for Wesnoth game itself. There are currently some problems delaying the first Release Candidate and getting us flooded with generic beta releases, but the developers in charge of them will (hopefully!) find a solution so we can get 1.8 released and trunk “thawed” soon, to work on new features and allow new code contributors to join the project. As for me, I can't wait for the new stable series — development series players seem to be scarce and the new versions of IftU and AtS are receiving little feedback on the forums because of this! I suppose Multiplayer content authors are similarly eager to get more fresh meat to play their add-ons.

I also recently talked about how I can finally suspend my laptop to RAM using Linux, and run some basic OpenGL-based software without crashing or destroying anything. That's something I didn't expect to be able to do in the near future, so the Mesa, libdrm and X.org radeon driver developers have my thanks for improving the Linux experience of those unfortunate enough to own onboard ATI graphics controllers!

In summary, as usual, a new year brings good and bad news. I guess it's up to us to take what's good and fix what's wrong. So, anyway (although I guess it's pretty much unnecessary at this point): happy New Year and have fun!

(The Abridged version: let's get this party started already and kill some spambots! GAAAA!)

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?

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.

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!

So, I have a HP laptop; a Pavilion dv5-1132la, to be specific. It's pretty, it has some fancy multimedia buttons, a fingerprint reader, an annoying and huge illuminated logo on the lid, yet another of those fantastic touchpads that break near the end of the warranty period, a fan (a.k.a. hair magnet) that's impossible to clean without disassembling the whole machine, an utterly useless fingerprint reader, some Lightscribe thingy which I don't use, and yet another on-board graphics adapter from ATI that has very, very poor support in the Linux world. I couldn't choose otherwise — it was a Christmas present and I was really, really desperate.

Since Wesnoth uses 2D rendering (with plain SDL primitives) for everything, I do not need accelerated 3D rendering for software development. However, people in RL have asked me why I don't have fancy desktop effects (gaa, Compiz) or play 3D games like other Windows and Linux users do. And even worse, a handful of Wesnoth developers and artists started a side project that uses OpenGL for 2D rendering!

So, last Friday I finally got around to upgrade from Debian Lenny (Stable) to Squeeze (Testing), but not without facing some problems: network-manager got restarted too early while I still needed to download more packages to finish the upgrade, I got stuck for 20 minutes trying to convince cnetworkmanager to make the wifi adapter work again until I figured out I just needed to restart D-Bus, the Linux kernel package v2.6.30-2 in Squeeze has some patches that rendered the wifi adapter completely useless after restarting, had to quickly rebuild a custom kernel to solve that, and work with Squeeze's udevd and get rid of the annoying default console bell (BEEP! — in a university library, thrice), and then had to build another kernel enabling PAT support because the new X.org needs it for some reason or radeonhd gets unusably slow — phew.

It was much better than I expected and the migration from KDE 3.5.9/10 to 4.3.1 was relatively seamless; Opera 10.0 and VirtualBox 3.0.10 for Debian lenny still work fine after the upgrade, and KDE 4 didn't try to eat my /home dir, nor did I try to prevent that after all.

After a few hours of using the new desktop environment I started to like it. IMHO, rumors of KDE 4's suckiness are being greatly exaggerated now that it's at 4.3.x.

Of course not everything is perfect, and I hit a very bad bug in Dolphin, KDE 4's lightweight file manager, which turns it into a time-bomb of sorts, crashing roughly after 1 minute of use. However, that bug doesn't affect good old Konqueror and that gave me an opportunity to go "whoaaah" and "ahhhh" and "ohhhh" at the various user interface changes in this version; for example, the previews of directories are much better than on the KDE 3.5 version of Konqui — now we have actual previews embedded on the directory icons, rather than little icon overlays. IMHO such feature belongs in the realm of eye candy, but there's still a fair possibility of revealing your pr0n stash if you navigate the parent directory with this enabled.

KDE 4.3's performance here is far better than what I experienced with a amd64 openSUSE-based LiveCD image using KDE 4.2.x. I couldn't know if this is because it's Debian, or because it's KDE 4.3, or because my custom kernel config rocks. Regardless, the laptop's battery still lasts almost the same as before upgrading to Squeeze — roughly 45 minutes. Of course, although I did enable some eye-candy to give radeonhd's XRender acceleration a decent work-out, I made sure that the new power management applet will turn it off when running on batteries. This is all very handy and beautiful...

But Squeeze lacks an important component for me, uswsusp, which provided some reliable work-arounds to get my laptop working fine both before and after suspending to disk (S4 power state). It is currently excluded from Squeeze due to some rather astonishing bugs, which means I had to seek other solution for suspending my pretty Linux system to disk...

And the solution in my case is the TuxOnIce patch, which surprisingly manages to bring the screen, keyboard and touchpad back to life — a feat that the kernel's built-in S4 support won't perform here. With this patch applied on top of an otherwise vanilla Linux kernel I now have a completely usable Squeeze system that supports all the hardware and software features I need.

Apparently, touchpad and/or laptop manufacturers don't expect anyone to use touchpad buttons at all.

It's been less than a year since I bought this HP Pavilion dv5-1132la laptop and the touchpad's primary/right button (I'm left-handed with computer mice) is already malfunctioning. It triggers a button press event at the slightest touch in some areas, even before pushing it enough to hear the "click" sound". My older Acer Aspire 5050 laptop also had a similar issue right after the end of the 1-year warranty period, except that the primary button simply stopped working.

Some genius decided to make touchpads emulate mouse clicks with "tapping", which seems to be preferred by many end-users over the normal buttons - in fact, I've got people confused when lending them my laptop because tapping doesn't work at all! He he.

For some reason, I've never learned to use these devices properly and most of the time, while moving the pointer across the screen, I end up unconsciously "tapping" it. Depending on the driver or operating system I'm using, I could also accidentally drag stuff this way. At least Windows Vista keeps an old Windows 95 feature which asks the user prior to moving directories like \Program Files and \Windows. Oops.

Even if I'm not using Windows, closing a terminal emulator by accident while dpkg or something (not in a screen session) was running in it can't be good.

So, disabling this tapping "feature" gets rid of these annoyances and lets me use this thing as if it was a normal mouse, more or less. I have even successfully used it for drawing pixel art for my Wesnoth add-ons!.

But it seems that I'm not supposed to use touchpads that way for very long! What the hell, QA department? So now I should ponder whether to go and ask the manufacturer's tech support for help before the laptop's warranty period is over this Xmas, or live with the problem because I'm not really willing to leave my little toy alone for a few days!

Fortunately I still have a USB mouse for pixel art- oh wait, its scrolling wheel doesn't work very well anymore because manufacturers seem not to expect anyone to use those a lot! But that's no problem because it's a very cheap accessory and I can easily replace it, unlike, uh, a touchpad?

So, I've got a multifunctional printer. It was part of a special discount offer for the laptop I got last December. That's cool and dandy. Problem: it doesn't provide drivers but for that Other Operating System.

I am extremely lazy so I didn't try to find drivers for using it on Debian lenny until just last night a few days ago. Found some references to a japanese website which provides Linux drivers for quite a lot of EPSON hardware (apparently due to some sort of partnership with the original manufacturer): they provide only 32-bit binaries for the printer component's drivers, and not even for the new Debian stable, and building the source code is pretty useless since I cannot figure out their weird post-installation config procedures, which is part of the auto-installing 32-bit binaries, but isn't documented or (apparently) provided in the source code distro.

Hit the nail with a spanish forum post. I had to install a newer version of the Gutenprint driver (lenny provides 5.0, the post stated 5.2.3 as minimum requirement, which also happens to be the latest provided at SF.net). A simple backport from the unstable (Sid) distribution was sufficient.

# apt-get -b source cups-driver-gutenprint

The first hard part was chasing down the generated .debs mixed between the ones from my other simple backport from sid (GIMP 2.6). Okay, not so bad. But then I figured out that the new drivers I was expecting wouldn't appear in foomatic-gui or KDE's printer manager tool (kcmshell printers, although you may know it better for its entry in the Control Center). Uncanny.

Then I figured it would appear in the CUPS config itself.

Next step: scanning with SANE!