On In-Kernel Drivers
It’s pretty well-known that the Linux kernel developers advocate getting your drivers into the main line kernel tree. Doing so ensures that your driver always gets fixed to conform to the latest “correct” internal interfaces when they change, and in-kernel device drivers always get distributed with the kernel, so you get automatic end-user distribution for free.
While I agree with that (without touching the question of whether or not a stable driver binary API/ABI would be useful), I’m not entirely sure it’s the best thing in the world for some types of device drivers.
While reading a post by Carl Worth on recent (perceived?) driver stability issues with the Intel video driver for Linux, I came across this bit of insight:
It used to be that getting the latest Intel driver just meant updating an xf86-video-intel module or upgrading an xserver-xorg-video-intel package. But now it’s essential to get a recent kernel as well… And these fixes aren’t in a major kernel release until 2.6.30 which appeared only today.
This is a problem that perhaps highlights some types of drivers that may be served better by being maintained outside the main line Linux kernel tree. Of course, this is only true while the driver is actively maintained and maintainers are able to quickly update the driver for new kernels (without breaking backward compatibility) as in-kernel interfaces change.
He also notes that distribution maintainers tend to update critical parts of the system (like the kernel) less often than userspace portions (like X.org video drivers). Since the xorg-video-intel driver depends on an in-kernel driver, it’s easy for these two things to become out of sync on an end-user’s system without testing. Or, frustratingly, the maintainer of the userspace package for a video driver might be unable to update to a newer version of the userspace driver because the kernel packager doesn’t wish to upgrade the entire kernel to become compatible with that userspace package (which is an entirely reasonable position to take).
And with more video drivers expected to move toward having significant kernel portions, this problem can only get worse. What if the latest userspace package for drivers A and B both depend on kernel 2.6.30, and the maintainer of package A wants to update, but the package B maintainer doesn’t (perhaps there’s a bad bug in the latest version of B)? Even if the A package maintainer can convince the kernel maintainer to update, doing so might break things for other users.
Now, sure, having dependency issues like that is nothing new, but I submit that this is a bit different. The kernel contains so much “unrelated” functionality that it has the potential to be a root dependency of many unrelated packages. For example, if a video player depends on a particular version of a codec library, you can often update that codec library without causing issues with other video players (ignoring, for a moment, ffmpeg’s inability to maintain a stable API). But updating the kernel because a userspace video driver requires a new kernel version could potentially cause problems with anything ranging from a USB storage device, to a hard disk controller, to an audio card.
Now, of course, the Intel video driver has been undergoing some very large changes lately. In theory, these things will settle down, interfaces will stabilize, and you can expect the tight coupling between the kernel version and userspace package version to relax a bit. But perhaps during this transition period it might make sense to avoid merging kernel code like this at all, and instead do separate releases of (in this case) the DRM modules that are paired to the userspace package. I imagine it wouldn’t be too much of a burden for distro packagers to disable building the in-kernel versions of these drivers, and instead ship an extra module package that the userspace driver packages can depend on.
On In-Kernel Drivers
It’s pretty well-known that the Linux kernel developers advocate getting your drivers into the main line kernel tree. Doing so ensures that your driver always gets fixed to conform to the latest “correct” internal interfaces when they change, and in-kernel device drivers always get distributed with the kernel, so you get automatic end-user distribution for free.
While I agree with that (without touching the question of whether or not a stable driver binary API/ABI would be useful), I’m not entirely sure it’s the best thing in the world for some types of device drivers.
While reading a post by Carl Worth on recent (perceived?) driver stability issues with the Intel video driver for Linux, I came across this bit of insight:
It used to be that getting the latest Intel driver just meant updating an xf86-video-intel module or upgrading an xserver-xorg-video-intel package. But now it’s essential to get a recent kernel as well… And these fixes aren’t in a major kernel release until 2.6.30 which appeared only today.
This is a problem that perhaps highlights some types of drivers that may be served better by being maintained outside the main line Linux kernel tree. Of course, this is only true while the driver is actively maintained and maintainers are able to quickly update the driver for new kernels (without breaking backward compatibility) as in-kernel interfaces change.
He also notes that distribution maintainers tend to update critical parts of the system (like the kernel) less often than userspace portions (like X.org video drivers). Since the xorg-video-intel driver depends on an in-kernel driver, it’s easy for these two things to become out of sync on an end-user’s system without testing. Or, frustratingly, the maintainer of the userspace package for a video driver might be unable to update to a newer version of the userspace driver because the kernel packager doesn’t wish to upgrade the entire kernel to become compatible with that userspace package (which is an entirely reasonable position to take).
And with more video drivers expected to move toward having significant kernel portions, this problem can only get worse. What if the latest userspace package for drivers A and B both depend on kernel 2.6.30, and the maintainer of package A wants to update, but the package B maintainer doesn’t (perhaps there’s a bad bug in the latest version of B)? Even if the A package maintainer can convince the kernel maintainer to update, doing so might break things for other users.
Now, sure, having dependency issues like that is nothing new, but I submit that this is a bit different. The kernel contains so much “unrelated” functionality that it has the potential to be a root dependency of many unrelated packages. For example, if a video player depends on a particular version of a codec library, you can often update that codec library without causing issues with other video players (ignoring, for a moment, ffmpeg’s inability to maintain a stable API). But updating the kernel because a userspace video driver requires a new kernel version could potentially cause problems with anything ranging from a USB storage device, to a hard disk controller, to an audio card.
Now, of course, the Intel video driver has been undergoing some very large changes lately. In theory, these things will settle down, interfaces will stabilize, and you can expect the tight coupling between the kernel version and userspace package version to relax a bit. But perhaps during this transition period it might make sense to avoid merging kernel code like this at all, and instead do separate releases of (in this case) the DRM modules that are paired to the userspace package. I imagine it wouldn’t be too much of a burden for distro packagers to disable building the in-kernel versions of these drivers, and instead ship an extra module package that the userspace driver packages can depend on.
Git Weirdness, Part 2
Ok, now this is just ridiculous:
[brian@machine1 airconfig $] pwd /home/brian/src/airconfig [brian@machine1 airconfig $] git branch -a advanced-ip-settings * master nm-frontend notification-rework reconnect origin/master origin/pre-hal [brian@machine1 airconfig $] cd .. && mkdir t && cd t [brian@machine1 t $] git clone ../airconfig Initialized empty Git repository in /home/brian/src/t/airconfig/.git/ [brian@machine1 t $] cd airconfig [brian@machine1 airconfig $] git branch -a * master origin/HEAD origin/advanced-ip-settings origin/master origin/nm-frontend origin/notification-rework origin/reconnect
Ok, that makes sense! Now:
[brian@machine1 airconfig $] cd .. [brian@machine1 t $] rm -rf airconfig [brian@machine1 t $] git clone file:///home/brian/src/airconfig Initialized empty Git repository in /home/brian/src/t/airconfig/.git/ remote: Counting objects: 1272, done. remote: Compressing objects: 100% (486/486), done. remote: Total 1272 (delta 778), reused 1270 (delta 776) Receiving objects: 100% (1272/1272), 360.40 KiB, done. Resolving deltas: 100% (778/778), done. [brian@machine1 t $] cd airconfig [brian@machine1 airconfig $] git branch -a * master origin/HEAD origin/advanced-ip-settings origin/master origin/pre-hal
What. The. Fuck.
Yes, the git-clone man page tells me that, when using a local pathname (and not using a file: URI), it assumes the other repo is local and uses hardlinks between the repos. But hey, if I specify –no-hardlinks when cloning, I still get all branches if I use the “../airconfig” method.
And if I go to machine2 and do “git clone machine1:src/airconfig” I get the same broken result with the file:// method.
Git, I think you rock. But why does your user interface suck so much? And why do you just appear to be broken right now? I can’t seem to find anything else in the man page to help here. (I’m using git 1.6.1.3 if that matters.)
Git Weirdness, Part 2
Ok, now this is just ridiculous:
[brian@machine1 airconfig $] pwd /home/brian/src/airconfig [brian@machine1 airconfig $] git branch -a advanced-ip-settings * master nm-frontend notification-rework reconnect origin/master origin/pre-hal [brian@machine1 airconfig $] cd .. && mkdir t && cd t [brian@machine1 t $] git clone ../airconfig Initialized empty Git repository in /home/brian/src/t/airconfig/.git/ [brian@machine1 t $] cd airconfig [brian@machine1 airconfig $] git branch -a * master origin/HEAD origin/advanced-ip-settings origin/master origin/nm-frontend origin/notification-rework origin/reconnect
Ok, that makes sense! Now:
[brian@machine1 airconfig $] cd .. [brian@machine1 t $] rm -rf airconfig [brian@machine1 t $] git clone file:///home/brian/src/airconfig Initialized empty Git repository in /home/brian/src/t/airconfig/.git/ remote: Counting objects: 1272, done. remote: Compressing objects: 100% (486/486), done. remote: Total 1272 (delta 778), reused 1270 (delta 776) Receiving objects: 100% (1272/1272), 360.40 KiB, done. Resolving deltas: 100% (778/778), done. [brian@machine1 t $] cd airconfig [brian@machine1 airconfig $] git branch -a * master origin/HEAD origin/advanced-ip-settings origin/master origin/pre-hal
What. The. Fuck.
Yes, the git-clone man page tells me that, when using a local pathname (and not using a file: URI), it assumes the other repo is local and uses hardlinks between the repos. But hey, if I specify –no-hardlinks when cloning, I still get all branches if I use the “../airconfig” method.
And if I go to machine2 and do “git clone machine1:src/airconfig” I get the same broken result with the file:// method.
Git, I think you rock. But why does your user interface suck so much? And why do you just appear to be broken right now? I can’t seem to find anything else in the man page to help here. (I’m using git 1.6.1.3 if that matters.)
Git Weirdness
So I have a git repo on my machine at home, that’s cloned from a repo on git.xfce.org. I was doing some work in it the other day — in a private branch, not published to git.xfce.org — and I wanted to continue working on the private branch from another machine. But… it won’t work. Let’s say ‘machine1′ has the repo with the private branch, and ‘machine2′ is where I want to work today.
So, on machine2, I cloned from the master repo on git.xfce.org:
[brian@machine2 src $] git clone git@git.xfce.org:kelnos/airconfig [... stuff happens...] [brian@machine2 src $] cd airconfig [brian@machine2 airconfig $] git branch -a * master origin/master origin/pre-hal
Ok, cool, that’s what I expect. So I ssh over to machine1 (the one I eventually want to pull from), and I check out my list of branches there:
[brian@machine1 airconfig $] git branch -a advanced-ip-settings master * nm-frontend notification-rework reconnect origin/master origin/pre-hal
Ok, cool. the ‘nm-frontend’ branch is the one I want to pull to machine2. So on machine2, I do this:
[brian@machine2 airconfig $] git remote add machine1 machine1:src/airconfig [brian@machine2 airconfig $] git pull machine1 nm-frontend fatal: Couldn't find remote ref nm-frontend fatal: The remote end hung up unexpectedly
Uh… what? Do I have the wrong syntax? Ok, let me just try to pull everything from the remote:
[brian@machine2 airconfig $] git pull machine1 remote: Counting objects: 1085, done. remote: Compressing objects: 100% (301/301), done. remote: Total 1085 (delta 774), reused 1085 (delta 774) Receiving objects: 100% (1085/1085), 323.43 KiB | 14 KiB/s, done. Resolving deltas: 100% (774/774), done. From machine1:src/airconfig * [new branch] advanced-ip-settings -> machine1/advanced-ip-settings * [new branch] master -> machine1/master * [new branch] pre-hal -> machine1/pre-hal
And then at the bottom it prints out a message about not knowing which local branches to merge stuff into. That’s fine, no big deal. But… how come it pulled 3 of my local branches on machine1, but left off 2 of them (‘notification-rework’ and ‘nm-frontend’). No combination of src:dest refspecs seem to do the trick. Pulling one of the 3 branches it seems to like using the syntax I used above seems to work fine, but it can’t see the one I want. What am I doing wrong…?
Git Weirdness
So I have a git repo on my machine at home, that’s cloned from a repo on git.xfce.org. I was doing some work in it the other day – in a private branch, not published to git.xfce.org – and I wanted to continue working on the private branch from another machine. But… it won’t work. Let’s say ‘machine1’ has the repo with the private branch, and ‘machine2’ is where I want to work today.
So, on machine2, I cloned from the master repo on git.xfce.org:
[brian@machine2 src $] git clone git@git.xfce.org:kelnos/airconfig [... stuff happens...] [brian@machine2 src $] cd airconfig [brian@machine2 airconfig $] git branch -a * master origin/master origin/pre-hal
Ok, cool, that’s what I expect. So I ssh over to machine1 (the one I eventually want to pull from), and I check out my list of branches there:
[brian@machine1 airconfig $] git branch -a advanced-ip-settings master * nm-frontend notification-rework reconnect origin/master origin/pre-hal
Ok, cool. the ‘nm-frontend’ branch is the one I want to pull to machine2. So on machine2, I do this:
[brian@machine2 airconfig $] git remote add machine1 machine1:src/airconfig [brian@machine2 airconfig $] git pull machine1 nm-frontend fatal: Couldn't find remote ref nm-frontend fatal: The remote end hung up unexpectedly
Uh… what? Do I have the wrong syntax? Ok, let me just try to pull everything from the remote:
[brian@machine2 airconfig $] git pull machine1 remote: Counting objects: 1085, done. remote: Compressing objects: 100% (301/301), done. remote: Total 1085 (delta 774), reused 1085 (delta 774) Receiving objects: 100% (1085/1085), 323.43 KiB | 14 KiB/s, done. Resolving deltas: 100% (774/774), done. From machine1:src/airconfig * [new branch] advanced-ip-settings -> machine1/advanced-ip-settings * [new branch] master -> machine1/master * [new branch] pre-hal -> machine1/pre-hal
And then at the bottom it prints out a message about not knowing which local branches to merge stuff into. That’s fine, no big deal. But… how come it pulled 3 of my local branches on machine1, but left off 2 of them (‘notification-rework’ and ‘nm-frontend’). No combination of src:dest refspecs seem to do the trick. Pulling one of the 3 branches it seems to like using the syntax I used above seems to work fine, but it can’t see the one I want. What am I doing wrong…?
Xfce 4.6.0 Released
I’m a bit late with this, but we finally got Xfce 4.6.0 out the door. Others have written much more about this than I have, so feel free to read about it on our blog aggregator.
Xfce making great strides with version 4.6
A little more than two years after version 4.4 was released into the wild (on 21 January 2007), the Xfce development team has announced the availability of the new version of the Xfce desktop environment yesterday (yes I’m late to the party…).
In an email, release manager Stephan Arts announced the new version 4.6 (only even numbers are used for stable releases), which has already been picked up in various articles all over the web’s darkest corners.
Xfce is an integral part of Xubuntu. In its role as the desktop environment it provides vital applications such as the panels, the desktop, the file manager and the window manager (i.e. the thing that paints the borders around your windows and handles how they are placed in your screen), among others. In fact, it is the primary reason for Xubuntu’s existence – when Jani Monoses founded the project he did so because he wanted to combine the features of Xfce with the advantages Ubuntu brings.
So what’s new?
Due to technical problems, I haven’t been able to run Xfce 4.6 on my personal computer as of yet (something which I hope to change in the coming week), so I’m going to base myself on the excellent Xfce tour prepared by Xfce developer and previous Xubuntu developer Jérôme Guelfucci and my experiences while running Xubuntu from my USB drive. I’ll also be using the screenshots provided by Xfce developer and Xubuntu-Xfce Liaison Jannis Pohlmann because I’m lazy.
First of all, Xfce’s panel (xfce4-panel) has received some love with lots of bugs fixed that especially the proud owners of multiple monitors won’t mind to miss. It also comes with updated panel plugins. This adds nifty new features to e.g. the system tray, which now allows you to hide certain icons. This is quite useful to hide, for example, that NetworkManager icon that always sits there yet is almost never needed after your network has been set up.
Although not part of the release, the screenshot plugin has been developed into its own application by Jérôme Guelfucci (and David Collins added some nice new features, too) and is now named Xfce4 Screenshooter. It, among other features, allows you to capture a region of the screen or a single application. Now the keyboard shortcut for PrtScn can be set by default 
.
The desktop manager, xfdesktop, now includes an oft-requested feature: rubber banding, or the ability to click and drag to select multiple icons to manipulate. Furthermore, the Xfce menu is now a submenu of the context menu when you have icons on your desktop – something that some people have expressed dissatisfaction about.
On the xfce4-mixer front, Jannis Pohlmann has rewritten it to sport a more polished interface, and to use Gstreamer. Some refer to this as bloat, but it really makes for a more maintainable application that supports multiple sound systems more easily, is better tested and will work on the systems of more people (although it will undoubtly not work on the systems of some others, namely those who can’t get Gstreamer to work).
With the new mixer also comes a panel plugin that allows you to change the volume with a mere scroll over the panel icon, which is very useful unless you don’t have a scroll wheel.
The session manager has also received some love. Based on code in Xubuntu, originally written by Jani Monoses, but almost entirely rewritten, Xfce now supports suspending and hibernation by default. Though the Suspend and Hibernate buttons might attract a bit too much attention with their size, considering how often they’ll be used, it’s a useful addition nonetheless.
A feature that will help out a lot of users and will save me a lot providing support, is its ability to automatically restart important applications if they just so happen to crash. The reason this is so useful is because the panel has a habit of occasionally crashing seemingly without reason, with people left not knowing what to do.
Of course, the Xfce Window Manager, xfwm4, was also updated, mainly thanks to the work of the Xfce project founder Olivier Fourdan, from France. It can now see when an application is busy and won’t respond, and offer you to force it to quit.
It also offers a useful new “Fill” option that allows you to resize a window to use as much space as possible that is left unused by other windows. This can come in handy when working with applications such as the Gimp. Besides these improvements there are some other tweaks and stability and performance improvements.
Xfce’s file manager that Benedikt Meurer developed for Xfce 4.4, Thunar, has received attention from Nick Schermer and Jannis Pohlmann. Being one of Xfce’s show-off applications, it just got a little better with many bug fixes and performance improvements coming in. It also ships a new plugin to set an image as your wallpaper from within Thunar, and now follows the XDG user directories specification, which basically means that it provides you with folders for Music, Videos, Pictures, etc. and translates their names if you use another language.
Furthermore, connected drives that have not been mounted (i.e. prepared for reading by the computer) will be distinguishable by their translucent icons. Encrypted devices are now supported as well. As for Xubuntu, word has it that we may get folder sharing in 9.04, which many people have been clamouring for.
Jannis Pohlmann and Jasper Huijsmans have been working on a rewrite of the AppFinder. It now has a cleaner interface and updates in real-time, as always allowing you to easily find installed applications and, by dragging them to the Launcher-creation interface, easily create panel shortcuts.
The Xfce menu has also been updated to really comply with the freedesktop.org standard (perhaps you noticed that the menu in previous versions was structured a bit oddly). Unfortunately, no menu editor is included and, with menu merging not being supported yet, using an alternative menu editor like Alacarte won’t work either. It’s manually editing the files or making do with the menu as-is, for now.
And last but certainly not least, one of the biggest new features: xfconf. Admitted, you won’t (shouldn’t) notice much of this, but it’s quite the improvement. Basically, it provides a new, central configuration system for Xfce similar to, but simpler than, GNOME’s gconf.
It does offer some nifty new useful applications though. For example, there’s now one central place to edit the settings of all applications that use xfconf – the Settings Editor (xfce4-settings-editor).
It also includes a command-line tool, and it is this that looks extremely valuable to me. Not because I like to type commands, but because you can bind them to keyboard shortcuts. Yep – editing preferences with a simple key combination.
For example, if you’re a programmer, it can be very useful to switch your keyboard layout on-the-fly – use dead keys when doing normal stuff like writing a blog post, and stop using them when you’re programming and want your quotes to appear directly. With xfconf, this can be done very easily. For example, the command to set your keyboard layout to the US layout without dead keys, you’d use:
xfconf-query -c keyboard-layout -p /Default/XkbLayout -s "us" && xfconf-query -c keyboard-layout -p /Default/XkbVariant -s "altgr-intl"
Similarly, if you wanted to change the layout to US with dead keys, you’d use:
xfconf-query -c keyboard-layout -p /Default/XkbLayout -s "us" && xfconf-query -c keyboard-layout -p /Default/XkbVariant -s "intl"
Now all you need to do is bind them to a keyboard shortcut and you’ll be set!
Of course, this is some pretty advanced stuff, but it’s there when you need it and hardly noticeable when you don’t. Plus, it might make for a good blog post in the future, so if you have any more useful applications of this, do tell me .
With the new settings backend comes a new Settings Manager which allows you to edit many of the settings in one window and is more neatly organised and better suited to small monitors in general.
Furthermore, a lot of the settings windows have been redesigned and options have been added – I’ll kindly refer you to the excellent tour for an overview.
So how do I get it?
You can download Xfce in source code form or using the oft-praised graphical installers. Packages for several distributions will without doubt already be available. However, the easiest and recommended way is to wait for your distribution to provide the packages. Xubuntu 9.04 will have Xfce 4.6.0 and already has Release Candidate 1. If we’re lucky, version 4.6.1 will even make it in time which will contain the first important bugfixes and translation updates.
If you’re running Xubuntu 8.04 “Hardy Heron” or 8.10 “Intrepid Ibex”, then you’re lucky, because Jérôme Guelfucci has prepared packages with help of the Debian Xfce group and Lionel Le Folgoc.
So what is ahead?
The Xfce development team is already looking forward to version 4.8. The plan is to do a shorter release cycle this time, with one (probably optimistic) guess targeting a new release in about a year. Some excellent features have already been developed to be included in 4.8, such as my pet peeve drag ‘n drop support for panel icons (no more messing with commands in launchers!), menu merging so you can actually use a menu editor, and several improvements to Thunar.
All in all, this has shaped up to be a very nice release with some excellent new features, some of them nowhere to be found in other desktop environments, which demonstrates once again why I like Xfce for more than performance alone. With some of the improvements for 4.8 already checked in and many more waiting in line, I’m already excited. I’ve fallen far short when it comes to attributions, failing to name Xfce’s excellent translation team, the people behind the Xfce distros, the various communites, Brian Tarricone, Mike Massonnet, -I guess I should stop naming people because I’m bound to forget many more, or even people of whom I don’t even know they’ve contributed.
To whomever contributed to Xfce in any way: thanks!
Licensing Suckage
I just got an email from a developer who works on the nifty cairo-dock application, pointing me to a thread about licensing issues.
A bunch of months ago, he’d emailed me asking about how to best use code from my Xfce Mailwatch Plugin in cairo-dock to add mail-checking capabilities. At the time, I was pretty stoked that someone else had actually found my code useful enough to incorporate into their program, and offered my encouragement.
Sadly, though, licensing ugliness has reared its… well… ugly… head.
When licensing code under the terms of the GNU GPL or LGPL, the FSF suggests (and most people follow) that you license under “or (at your option) any later version” terms, which means that, while you initially license the code under the version of the GPL or LGPL of your choice, someone can later take your code and relicense it under the terms of a later version of the same license. This also makes the code automatically compatible with future versions of the license.
You might think this sounds pretty good for convenience and licensing compatibility, and you’d probably be right.
However, this isn’t so great from a philosophical perspective, at least from my philosophical perspective. The problem I have is this:
Licensing a work under “GPL version 2 or later” terms means that I am implicitly agreeing with any new restrictions that the FSF dreams up (or any existing restrictions the FSF wants to drop), forever. I’d basically be saying that I agree with something that doesn’t exist yet, and could take any shape or form imaginable.
Don’t get me wrong: in general, I think the FSF is good people, and I agree with their message for the most part.
But I don’t know them, personally, and I don’t agree with them 100%. And I don’t know who’s going to be running the FSF next year, or in five years, or in 20 years. So how can I know, or even have reasonable belief, that their philosophies and values will align with mine such that I’ll agree with future versions of their licenses? There are already parts of version 3 of the GPL and LGPL that I don’t completely understand or agree with, so why should I expect that versions 4, 5, or 10 will be completely to my liking?
The short answer is: I can’t.
And so, for the most part, I release my software under “GPL version 2 only” terms. (Because I’m a bit lazy and don’t want to make a big stink, I’ll release code under “or any later version” terms if I’m contributing to an existing code base that uses those terms.)
it really pained me to have to answer that email saying that my code’s licensing (GPLv2-only) wasn’t compatible with theirs (GPLv3-or-later), but it’s the truth, and there’s not much I can (or want to) do about it.
The only solution I can think of (I’m not a lawyer, of course) that allows them to use my code is that they relicense their code under GPLv2-or-later terms. Of course, then they lose any restrictions that the GPLv3 has over the GPLv2, which I assume they’d prefer to have, since that’s how they’ve licensed their code.
(Before anyone says it, another possible solution would be for me to relicense under LGPLv2.1. The problem with that is one I’ve discussed before: section 3 of the LGPLv2.1 explicitly allows a recipient of the code to relicense the code under regular GPLv#-or-later terms, regardless of the only/or-later status of the original LGPL licensing. This of course completely defeats the intent of my rationale above.)
And so, the OSS licensing mess has caused yet more pain to people who just want to share code and avoid duplicating effort. I love the GPL. I really do. But I also hate it.
Backlight Change Notification?
Is there a decent (non-polling) way to get notified when a laptop panel’s backlight brightness changes? HAL exports methods to set and get the brightness level, as well as query the number of possible levels, but there doesn’t appear to be a way to get notified if the level changes. Calling org.freedesktop.Hal.LaptopPanel.GetBrightness() every five or ten seconds or so sounds like an awful idea, of course.
I’ve heard plans to use the XBACKLIGHT randr 1.2 property to do backlight setting, but I don’t think any drivers use this yet. Polling /sys is just as bad (why doesn’t sysfs or procfs support inotify, dammit!), and obviously isn’t portable anyway (not that HAL is particularly portable these days either).