Option key as Alt in KDE apps on Mac (Mac annoyance Saturday)

The default keyboard setup of Apple's X11.app for Mac OS X doesn't support Alt- shortcuts in KDE apps (at least not when KDE's installed via current fink, e.g. by sudo /sw/bin/fink install kdebase). This makes konsole just about unusable, as konsole translates Alt events into Meta keypresses on the underlying terminal, and discards true Meta events. To fix this, assign the keycodes as follows in your ~/.Xmodmap:

keycode 66 = Alt_L
keycode 69 = Alt_R

Then, ensure that your X11 "Preferences..." are as follows (dialogue box is from Leopard):

Finally, restart X11.

For completeness, here's the keyboard layout kcontrol module (you shouldn't have to do anything here, as these are the default settings):

Credit to this macosxhints.com post, which took an astonishing amount of searching to sift from the vast oceans of trash and non-working solutions that you get when you search for X11 issues for Mac. I post this in the hope that it will serve as more efficient Google-food.

(Background: I recently killed the hard drive on my ~2.5-year-old work MacBook, and so I've been reconstructing my work environment on the shiny new MacBook they requisitioned for me. Running emacs in a screen session on a remote Linux box is one of my most common activities, so having konsole with no Alt/Meta makes Mac usage just about unbearable. I could not for the life of me remember the magical incantation I did to fix Alt last time, so I literally spent about half a workday intermittently typing random permutations of "kde", "fink", "alt", "meta", "konsole", and "leopard" into my web search box. Blech.)

Video corruption on resume from suspend on Thinkpad T42 with Fedora Core 5 and Xorg

Note: Narrowly targeted Google-food. Skip if you do not run a recent version of Linux on a Thinkpad T42 with the Xorg X server.

I run Fedora Core 5 on a Thinkpad T42. Like a good conscientious user, I run yum update regularly to download and install the latest security fixes and patches. Sometime in the past month or so, one of these updates broke suspend. Whenever I resume from suspend --- i.e., whenever I close the laptop's lid and open it again --- my desktop's background wallpaper gets corrupted. My lovely shot of Lake Union gets overwritten with noise: either jaggy, staggered horizontal black and white lines, or a sprinkling of randomly colored "off" pixels.

Oddly, this symptom does not manifest itself when I set my desktop background to plain black. However, using a computer without wallpaper is clearly beyond the pale of what a civilized human being can rationally tolerate.

I have no clue what's at fault: the kernel, the X server, or some other part of my laptop's software ecosystem? Who knows? My wild-assed guess is that somewhere during suspend, the video driver or kernel decides that the video memory buffer allocated for the wallpaper bitmap can be safely used for scratch space to doodle upon, or whatever it is that OS software does. I don't want to manually roll back the scads of packages I've updated via yum (Xorg alone installs about two dozen RPMs), and I don't know how to go about debugging this problem for real. I don't even know whose Bugzilla to report this to --- Fedora? Linux kernel? Xorg? Probably all of them will either ask me to debug the problem, or tell me to file the problem on someone else's Bugzilla.

Sigh. Such is the life of the user of a computer system where nobody takes responsibility for the entire hardware/software stack. I like Linux considerably, but at times like this I wonder if I should just ditch it all for a Mac, thereby giving up freedom for convenience.

In any case, my mad Google-fu did not turn up a solution, strictly speaking. However, it did turn up a pointer that eventually led me to vbetool, a system for tickling your video BIOS. My current suspend-and-resume script (/etc/acpi/actions/sleep.sh) now uses the following magic (recent additions in orange):

#!/bin/sh

# Sleep the network
# (Following should all be one line.
# Blogger keeps borking backslash-escaped EOLs)
/usr/bin/dbus-send --system
      --dest=org.freedesktop.NetworkManager
      --type=method_call
      /org/freedesktop/NetworkManager
      org.freedesktop.NetworkManager.sleep

# Save vbestate
/usr/bin/chvt 1
/usr/sbin/vbetool vbestate save >/var/tmp/vbestate

/usr/sbin/hwclock --systohc
echo -n mem >/sys/power/state
/usr/sbin/hwclock --hctosys

# Fix video corruption on resume by resetting vbestate.
/usr/bin/chvt 1
if [ -f /var/tmp/vbestate ]; then
    cat /var/tmp/vbestate | /usr/sbin/vbetool vbestate restore
    rm -f /var/tmp/vbestate
fi
/usr/bin/chvt 7

# Wake the network
# (Following should all be one line.
# Blogger keeps borking backslash-escaped EOLs)
/usr/bin/dbus-send --system
      --dest=org.freedesktop.NetworkManager
      --type=method_call
      /org/freedesktop/NetworkManager
      org.freedesktop.NetworkManager.wake

Note the chvt and vbetool vbestate calls, which save the state to /var/tmp/vbestate before suspend and restore it after suspend. You're not supposed to save and restore the Video BIOS state while you're in an X session, so I use chvt to switch to a text console before invoking vbetool, and back to the X console afterwards. This appears to fix the video corruption problem. Truthfully, I don't know why. Oh well. In the absence of understanding, I'll settle for voodoo.

For reference, I am currently running:

• kernel-2.6.16-1.2133_FC5
• xorg-x11-server-Xorg-1.0.1-9.fc5.5

UPDATE 26 August 2006: Fixed sleep/wake of network.

linux, fedora, thinkpad, xorg, suspend, troubleshooting