Hell Labs

Or a case study on how the knowledge of the basics of the Ancient Art of Assembly Programming can still save the day. Remember the last time you had to binary patch a program in Linux? Neither did I. But when we came across a binary-only executable doing very stupid things, with no source code in sight, no viable replacement at hand and no time or patience to code our own, binary patching didn’t sound too bad.

(more…)

A friend of mine pointed me to a bizarre site called Blackle which is, essentially, Google with a black background. Blacke claims that:

Blackle saves energy because the screen is predominantly black. “Image displayed is primarily a function of the user’s color settings and desktop graphics, as well as the color and size of open application windows; a given monitor requires more power to display a white (or light) screen than a black (or dark) screen.” Roberson et al, 2002 (…) We encourage you to set Blackle as your home page. This way every time you load your Internet browser you will save a little bit of energy. Remember every bit counts! You will also be reminded about the need to save energy each time you see the Blackle page load.

Which seems to be a ludicrous attempt to capitalize on web audience based on the fact that people tend to believe in the strangest things if they’re told it’s for some noble cause. While it is actually true for CRT monitors, the first thing that popped in my mind is that the effect should be exactly the opposite in LCD displays. From Wikipedia:

In a twisted nematic device (still the most common liquid crystal device), the surface alignment directions at the two electrodes are perpendicular, and so the molecules arrange themselves in a helical structure, or twist. (…) When a voltage is applied across the electrodes, a torque acts to align the liquid crystal molecules parallel to the electric field, distorting the helical structure (this is resisted by elastic forces since the molecules are constrained at the surfaces). This reduces the rotation of the polarization of the incident light, and the device appears gray. If the applied voltage is large enough, the liquid crystal molecules are completely untwisted and the polarization of the incident light is not rotated at all as it passes through the liquid crystal layer. This light will then be polarized perpendicular to the second filter, and thus be completely blocked and the pixel will appear black.

So in most LCD displays, the amount of energy applied to produce a black pixel is actually larger than producing a white pixel. No wonder screen savers in Nokia and Sony Ericsson cell phones are mostly white. But one doesn’t even need to gather information elsewhere about power usage in LCD devices, a quick look at the paper cited as reference in Blackle itself reveals that:

Among CRTs, maximum on power appears to be associated with a white display, or a maximum-sized application window (which approximates a white display). Among the few LCD monitors in the table, the power used to display a white screen is indistinguishable from power used to display the desktop. Thus, it appears that display color is a significant determinant of on power for CRTs, but not for LCDs.

If you want to be a nice person and save the planet, do it the right way. Research. Check if your acts actually have some significance. Don’t believe something just because someone told it’s a good thing. If you are actually concerned and want to help, good. Buy a less power-hungry CPU. Install cpufreq. Use power management. Reduce brightness or intensity of the backlight. Turn off lights you don’t need. Use Blackle you find it funny and amusing, but don’t do that thinking you’re doing any good — especially if you use an LCD monitor. It’s plain stupid.

Let’s hypothesize for a moment that you must make an old, binary-only Conexant HSF softmodem driver (that you, for some reason, can’t upgrade) peacefully coexist with a newer 2.6.22 kernel ALSA HDA driver. “Oh, what an embarrassing situation!” you might think — but I assure you, this can actually happen to some unfortunate souls among us. A workaround for this problem is twofold: first, you must graft the HSF appendages to your existing HDA driver (the HSF driver comes with its own HDA driver that potentially won’t have some features you need), and then resolve a recursion in module loading since 2.6.22 merged snd-hda-codec and snd-hda-intel in a single module and the binary-only culprit used to sit between the two.

So without further ado, here is what it takes to have this setup working:

1. Revert the hda-codec and hda-intel merge, to work around the HSF initialization recursion.
2. Apply Herton’s HSF patch against 2.6.22 so you can use the binary-only portion with the stock HDA driver from your kernel.

Generally speaking, binary-only modules can be a pain in the ass and this situation illustrates well how. Always verify driver availability before purchasing hardware, and that can save you some headaches.