If you have a laptop with Intel graphics and broken backlight control…

e.g. a Sony Vaio Y-series, where upon seeing the debugging data kernel developer Matthew Garrett (mjg) pronounced it “what an awful implementation — utterly broken”, there is hope yet.

Matthew has been working on native backlight control for a while, and for Intel hardware, there’s currently only one patch left to merge onto Linus’ kernel tree; it applies cleanly onto the most recent kernel release candidate (3.0-rc7).

Unfortunately, by default the ACPI subsystem will still be used if available, which is the sensible default. You do want to use the predefined backlight values whenever possible, not the raw values the graphics card let you set.

Ubuntu users have been resorting to Kamal Mostafa’s linux-kamal-mjgbacklight repository, which enables native backlight control, disable the ACPI video driver, and provide a patched GNOME Power Manager that can interface with the native backlight control.

The workaround I came up with is more lightweight — it just uses inotify-tools to monitor the brightness file, and apply an appropriate equivalent value to the native backlight control. Feel free to use this if you’re affected by a similar problem.

Try Thunderbird 5.0 now — without hassle

There are cases when getting a specific software from one’s Linux distribution is not the optimal solution — and I’m saying this as a package maintainer myself. The main ones are:

  • the distribution package might be out of date
  • legal reasons prohibiting the software from being packaged (e.g. Skype, Flash, Adobe Reader)

Note that the first point is not exactly a criticism — after all, distributors tend to be wary of introducing breaking changes in a stable release. For software in the second category, upstream often provides binary packages, but again, using a tarball requires users to deal with dependency resolution themselves, and even when Debian or RPM packages are provided, the packaging is often sub-par (upstream developers can’t be expected to be well-versed in the subtleties of each distribution’s packaging).

Enter 0install. Now installing, e.g. Thunderbird 5.0, is a simple process:


yum install zeroinstall-injector
0alias thunderbird5 http://mojo.informatik.uni-erlangen.de/interfaces/2011/thunderbird.xml

or use “Add New Program” from the application menu and provide it with the URL for the Thunderbird feed. This currently lets you easily select between Thunderbird 5.0 beta 2 and 5.0 final (for both 32-bit and 64-bit builds) as well as the distribution’s packaging (on RPM-based and Debian-based distributions as well as Gentoo), and will pull in needed dependencies (please report any problem here).

You can browse http://mojo.informatik.uni-erlangen.de/interfaces/2010/ and http://mojo.informatik.uni-erlangen.de/interfaces/2011/ to see other available feeds that I maintain (and 0install’s site for even more). Of note: Eclipse JEE, Maven 2.2.1/3.0.3, Skype and Tomcat.

The compat-wireless dance

At Fedora, our kernels tend to track upstream as much as possible, which sometimes makes for an amusing wireless experience. Here’s a tale, amusing in hindsight, of my three Sony computers, all using the ath9k module.

Firstly acquired is the 15″ Vaio EB I use as a desktop replacement. It works fine with stock drivers — at least, no known problem until today. We’ll get back to it later. Next, the 10.2″ Vaio W netbook. With this the wireless driver would need to be cycled — unload and reload — unless it’s kept active by, say, a continuous ping session.

Now, the EB did not use to work with the experimental compat-wireless drivers — basically the wireless code not yet merged into the Linux kernel; while the W absolutely requires these to avoid the ping keep-alive workaround.

Then comes the 13″ Vaio Y I got on a closing sale — at a nice discount price. Both the EB and the Y need to be on Fedora 15 because of graphics quirks (the former Radeon 5650, the latter Intel Arrandale), but that’s for another article. Everything seems to work fine, until I realized today, attempting to transfer a large-ish (> 100 MB) tarball from the Y to the EB, that the wireless on the Y keeps freezing up if I continuously transmit! It’s not a regression, or not a recent one, since older kernels do that too.

In goes compat-wireless to the rescue, and lo and behold, the transmission now works fine. Only then I find out that now the EB also acts up when it’s downloading at maximum speed. Sigh… funnily, now compat-wireless works fine on it, and fixes the problem.

I don’t even think I want to file bugs on this — different issues on different laptops — I’m just glad the latest wireless code works uniformly well now, and am just waiting for it to land in the mainline kernel.

HOWTO: Unchain Yourself from Proprietary Formats

Today being Document Freedom Day, I’m taking stock of how unencumbered my digital lifestyle is — both on the consumption as well as on the production side. I’ll try and explore alternatives for each category. But before that, one must first explore why proprietary and patent-encumbered formats are bad, 

  1. Patents — if some entity holds patents that apply to a format, your ability to distribute your files might be compromised by the need to pay patent royalties. Even if the patent holder covenants not to exercise enforcement of the patents, they or the patents could end up being bought, at which point who knows what could happen. Even Microsoft got into trouble with Alcatel Lucent; the case was later thrown out of court but only after a headline-grabbing $1.52 billion award of damages was initially awarded. And Alcatel is not even a patent troll! Best protection is to use software licensed with a retroactive patent retaliation clause (e.g. Apache license, Eclipse Public License, GNU Public License v3) and whose copyright holders and distributors are in a defensive patent pool such as the Open Invention Network
  2. Format obsolescence – even NASA has had trouble reading precious sensor data from old punch cards and magnetic tapes generated by previous missions, because the documentation for the file formats have been lost!
  3. DRM — Digital Rights, or Restrictions, Management, depending on which side of the coin you’re looking at it from. It’s not impossible to create a DRM policy that is flexible enough to guarantee you your fair use rights you enjoyed with older analog technologies — the printed book, the audio CD — but it’s not in the interest of (most) publishers and distributors to do so. Unless forced by regulation or unless you vote with your wallets.
  4. Walled gardens — remember the pre-Internet days of AOL, CompuServe, etc.? We still have walled networks, they are just built on top of the Internet instead.

Continue reading