2.6.34 fixes laptop resume

My laptop had still been occasionally hanging on resume, but looking back over my blog, I realise that it may well have been because I re-enabled desktop effects.  So I'm not exactly sure why now, resume is completely fixed by 2.6.34.  There are still considerable improvements and fixes going into the kernel Radeon DRM, so it may have been fixed by that.  Or, it was the new asynchronous suspend & resume code that made its way into the kernel in 2.6.34, a project originated by Rafael Wysocki.  Either way, I am extremely happy.

Desktop effects occasionally borks resume?

After reverting the laptop to x86, I wasn't happy with the bugs in mesa-7.5, especially since they were solved in 7.6, so I keyworded X.org, Mesa and their dependencies and took a deep breath.  Not such a deep breath, as I had recently done the same thing on the desktop to no ill effect.  So the laptop was cruising with xorg-server-1.7 and mesa-7.7, and everything seemed fine.  However, an old problem had returned, or possibly a new one had appeared.  Either way, the symptom was that the laptop would occasionally hang after resuming from sleep.  Wasn't happening all the time, but often enough to be very annoying, as the only way out was by magic sysrq.  On a hunch, I disabled KDE-4's desktop effects and it hasn't happened since.  Doesn't sound like a fun problem to debug if it means rebooting every time it occurs, so I think I'll leave this one to the pros.

Wireless LED: solved by module parameter

At some point, my wireless LED stopped working again, after I thought I had solved it by enabling the extra kernel options mentioned in a previous post.  It was no big deal, so I ignored it.  Then, whilst searching for something else wireless related, I happened upon this laptop matrix about RF switches!  There I learnt that passing led=1 as a parameter to the ipw2200 module will enable the LED.  Hallelujah.  Why the LED worked in the past before I ever knew about this remains a mystery.

Laptop fails to suspend: fileshare related?

After initial teething problems with suspend & resume, it seemed to be working fine.  Every so often, though, it would just fail to suspend and return to the desktop.  Then, I think it went away, probably because I was using acpid to control the laptop lid button and was manually stopping netmount first.  After I upgraded to KDE4, I returned control to KDE because acpid's logging spam is quite annoying.  (There is another way to hook into the suspend action via scripts even when KDE is activating it, which I should look into.)  I think that I have finally found the cause: unreachable file shares.  I need to do some more testing, but my suspicion is strong.

Testing hassles: stable now

A month or so ago, both my desktop and laptop had independent heart attacks, so I downgraded them from testing to stable.  Was a pity to lose that cutting-edge and slightly unstable toy to play with, but a relief to now be able to get other things done.

The desktop still has a number of testing and bleeding edge packages installed, namely mesa and related ebuilds.

The laptop was exhibiting some weird behaviour--both Firefox and Amarok weren't working--so I reformatted it.  :)  It works fine now.

I guess I'm going to focus more on the stable experience of Gentoo from here on!

OpenOffice 3, KDE and GTK themes

For a while, OpenOffice integrated quite nicely with KDE.  Something happened recently that's causing missing captions in dialogues, PDF export failures and save-filename extensions to go missing in OO 3.1 (not sure about 3.0), details of which are here.  Pretty annoying for what is probably the most popular open-source office suite.  The Gentoo developers solved these issues by masking the "kde" flag.  I'm not sure what all the effects of that flag are, but visual integration with the desktop is the most salient: OO looks either very ugly (Raleigh theme) or screwed without that integration.  (The OO toolbars are essentially blank when using the default KDE theme.) The solution: x11-themes/gtk-engines-*, as mentioned in the official Gentoo KDE Guide.
The disappointing thing here is that the "GTK Styles and Fonts" settings item does not appear by default in the Appearance panel of KDE-4's System Settings.  It only appears after you install certain packages such as gtk-engines-qt, but not gtk-engines-qtcurve.  So if you go looking in System Settings first, you won't find anything that suggests that a solution even exists, and you may have themes installed that you can't select.  I think it makes more sense if the GTK settings item was enabled by the installation of gtk+.
The GTK settings item is installed by gtk-engines-qt as /usr/share/kde4/services/kcmgtk4.desktop, so the most straightforward solution would be to switch installation of that file to gtk+(+kde).  (By which I mean, when the kde USE flag is enabled.)  A crude stopgap measure could be to make all GTK themes depend on gtk-engines-qt if USE="kde", but that sounds messy and like it would just create more problems.  Something should change, though, because the way it currently works doesn't make sense.

Wireless LED

Somewhere around 2.6.25, a new option was added to Networking support: RF switch subsystem support.  I didn't notice it or didn't realise its significance at the time, but if I'd paid more attention to it, I probably would have realised that it was connected with the simultaneous failure of the wireless LED to work anymore.  The options are disabled by default and, as you can guess by the name, provide support for the 'RF kill switch'. This in turn affects the wireless LED.  It finally came to my attention when somehow, something enabled the RF kill switch and of course pressing it didn't disable it.  Just today I discovered that there is another kernel option that the wireless LED depends on in Networking support-->Wireless: Wireless extensions sysfs files (itself a sub-option of "Wireless extensions", which is forced on).