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.
With EXA support enabled in the xorg.conf for radeonhd, I started to get X.org lock-ups when resuming from s2disk on the 2.6.28.8 kernel at random times; sometimes after 2 days of uptime, sometimes after just 15 minutes. Since I'm using a laptop with that funny Fn key layout, pressing alt-sysrq-k (SAK), alt-sysrq-u (remount read-only) and alt-sysrq-i (kill all tasks but init IIRC) makes the kernel believe I have pressed alt-sysrq-<insert numpad key here>, which doesn't do anything but set the kernel loglevel. Not being able to see anything on the pitch-black screen, all I have left then is alt-sysrq-s (sync system call) and alt-sysreq-b (reboot) and let fsck replay the ext3 journals while restarting.
Hearing that the drm kernel modules at the freedesktop.org repositories are not updated with the mainline kernel changes, I decided to try out the kernel 2.6.30-rc2. Fear. Despair. It locked up forever while suspending to disk.
Either it apparently did something more than mereley locking up, or the freedesktop.org drm and radeon kernel modules are more broken than I expected, but some hours after rebooting to 2.6.28.8 and doing my homework on the laptop, most of the running GUI programs crashed with random SIGSEGVs and SIGABRTs. Yes, what you read - even the KDE window manager got busted. Interestingly, I could bring it up again with some effort without restarting X, but then I noticed that one of the apps I was working with, Eclipse (3.4.x), didn't want to start again. When launched from the console, it would exit around 2 seconds after being invoked, with no explanation. After fiddling around with my ~/.eclipse dir, restarting X various times just to see knotify and artsd crashing like mad on KDE startup, I started session as another (dummy) user in X and tried to launch Eclipse 3.2 instead - its explanation was a bit more satisfactory: missing libraries.
"Of course", I thought, "the ldconfig cache may have become corrupted".
My thoughts at that moment: WHAT THE F* HELL HAS HAPPENED!!!?!?! Considering that I hadn't run Wine for months, and it wasn't running at that moment either... I ran some ls's to see what had become of those libraries... it wasn't pretty. They had become character, block devices and FIFOs. 😕 I rebooted, and fsck still ignored the "clean" /usr (/dev/sda5) filesystem until I forced it to check it all filesystems again by setting their mount counts to some funny values using tune2fs.
Indeed, /usr was corrupted.
After init dropped me to a emergency console to run fsck manually on sda5, running e2fsck threw some interesting stuff, which I forgot to save to a file, but it was something like this:
inode ####### has 'compressed' flag set on an unsupported filesystem
inode ####### has invalid size
inode ####### (fifo) has non-zero size
inode ######## has 'compressed' flag set on an unsupported filesystem
((ad infinitum, ad nauseam))
After it finished, I noticed that the /usr/lost+found directory got populated with files and directories resembling parts of the Python 2.4 and 2.5 foundations installed. Of course, missing entire directories is a really bad sign. But I could recover the affect packages I noticed, with help of apt-get install --reinstall. Those where anything aRts, Python, wine, Pango and Akregator (which I actually remembered to reinstall right now, while writing this), although I reinstalled the Samba server I had installed just some hours before the crash, just in case. Apparently I didn't lose anything else. None of the other filesystems were affected by whatever smashed parts of /usr.
The obvious course of action then was blacklisting drm and radeon, and removing the Option "AccelMethod" "exa" line in xorg.conf, and nuking the 2.6.30-rc2 kernel image just in case. 😛 Eclipse and artsd worked again, and nothing else has shown any symptoms of being affected by fsck's decisions since then. It's been just 5 days though, and I have many apps lying around that I only use when asked/forced to, so I don't even remember their names.
I didn't say goodbye to kompmgr, however; it has a pretty decent performance and marginal CPU usage even while using a shadow framebuffer, with just one CPU core enabled at half of its maximum frequency, and even if the system is under load, so I figured that I really didn't need DRI or EXA all the time (radeonhd still doesn't have a opengl implementation, so having DRI enabled made no difference for clients) Still, it was nice to be able to scroll a huge konsole or Iceweasel/Firefox window without experiencing flickering.
Thanks to the help of the guys at the #radeonhd channel on Freenode.net, I could quickly find out how to make DRI (and thus, EXA) work with my laptop's onboard graphics... thingy... I'll let lspci speak for itself; it's much easier that way:
01:05.0 VGA compatible controller: ATI Technologies Inc RS780M/RS780MN [Radeon HD 3200 Graphics]
[...]
Let's not forget that this is my current (it was new on December) laptop, not the old, broken lappy, and I'm running Debian stable.
The thing is, with their help I installed a newer-than-Debian (or actually, newer-than-the-kernel-that-is-newer-than-Debian's) radeon drm module, and also solved a little mistake that made X lock up after resuming from suspend-to-disk with DRI and EXA enabled. Now I can enjoy some real 2D acceleration at last!
Although it seems, judging from the git repository's logs, that the official EXA and XRender acceleration support for this chipset is pretty recent, it is very stable compared to a certain other driver for another onboard chipset which I won't mention here. I could even enable KWin's composition manager (kompmgr)!
I have not tried the other big composition/window managers (e.g. compiz), nor intend to, as they require a hardware OpenGL interface which is not available yet for this chipset, and since they are labeled "window managers", I'm guessing that I'll definitively lose the KWin look-and-feel that kompmgr doesn't intend to replace).
Nonetheless, my very limited candy set-up has an incredibly low CPU overhead (either that or the radeonhd driver is f***ing awesome), and I can even let it enabled while in powersave mode, and no matter what I do, I don't see any impact in the other program's performance. I couldn't say the same thing about radeonhd before getting EXA.
One really odd thing I noticed, though, is that kompmgr doesn't seem to want to have anything to do with translucency and pop-up menus. Side-effect, it is KDE (Qt3?) itself who must provide and option for that in the Control Center -> Styles page. But even if I tell it to use XRender acceleration, something doesn't fit - and it is that the changes going on windows below a pop up menu are not seen, e.g. the pop up menu rendering is completely static. This unlike regular translucent windows. I don't know what benefits this design decision may bring, but it's KDE 3.5.10 anyway, and KDE 4 users would laugh at me for my obsession with not switching to 4.x.
Note that I am aware that 4.2.x has fixed a lot of the stunningly awful usability and configurability regressions seen in earlier 4.x versions. But I am still pondering why all Qt 4 widget engines are pretty slow, compared to Qt 3 - so, until I get an answer of the kind "it's just you" or "can be solved" or "has been solved already", I'll not consider switching to KDE 4 an option.
