gnome-screensaver & keytouch

My experience with a quirk in keytouch, and the workaround I'm using.

One of my frustrations with gnome is a peculiar problem the gnome-screensaver has with keytouch. With Xscreensaver configured to work with keytouch it just works upon login. With gnome-screensaver I had to open the keytouch preferences (/usr/bin/keytouch) and ‘apply’ the settings first. After a little debugging I found that even pre-apply it’s actually trying to run the command. I set up a custom command to point to a shell script that would run ‘gnome-screensaver-command -l’ and had no results, but ‘gnome-screensaver-command -V -l > /tmp/helloworld.txt’ did indeed print the version to the aforementioned text. So I downloaded the source to find out what that magical ‘apply’ button does. What it does is commits the settings and then ‘killall keytouchd’, sleeps for 5 seconds, and then runs ‘keytouchd &’ So next I created a shell script to be run on login that does exactly that last part (killall, sleep, run it). Still failed. For reasons I’m not going to wonder about because setting the keys to run the ‘lock screen’ plugin function works. So now I don’t have to futz around when I login to be able to lock my screen and I can finally run gnome-screensaver. A few points: I don’t really prefer gnome-screensaver to Xscreensaver. The consistent GUI is nice, but it was more of the basic principle ‘hey, this should work.’ The problem with keytouch seems to extend to other programs as well. Apparently has something to do with the way (at least in debian) it gets started on login. I’m not familiar enough with dbus and the like to say exactly what it does to startup or why the hell it works for some things and not others (ie, volume controls work fine either way, Xscreen worked without this workaround, etc.) If I had to guess it’s probably because keytouchd gets tangled with dbus-launch and gnome-screen probably uses dbus in some capacity that leads to the problem. This is no more than a base hypothesis and I have no supporting evidence. Finally, I don’t really know if this breaks anything yet. I’m pretty sure it won’t break anything for my particular user. If I were a multiuser system and others didn’t run it the script it _probably_ wouldn’t break them, but it will definitely leave instances of keytouchd sitting around. If you have some program configured with keytouch that requires you to ‘apply’ the settings each session before it will work, this solution may be worth looking at. If I find a better (more consistent) method to solve this, I’ll do a followup. -Adam

Please Deposit Two Cents: Cancel reply