Free as in speech

The radeonhd xorg driver recently gained full RandR 1.2 support, I’ve tested it out moments ago and it works. It just works. (DIE fglrx, DIE DIE DIE).

Joy and happiness today, and thanks to Julien CRISTAU, it’s even packaged in experimental (I owe you a beer, obviously).

Now, given that we now have a working video driver, and an opensource one even, let’s think about implementing something in pommed for that nice little video switch button that’s on F7.

I don’t really know how to go about implementing the video switch feature. Either I’m doing it in pommed in the form of a shell script that will have to “steal” the user’s X session, or I’m doing it in the frontends, which will obviously be a bit easier.

Which raises another question: shell script around xrandr, or RandR support in the frontends?

That latter option doesn’t look terribly appealing to me, as it involves quite some code that will have to be maintained up-to-date wrt RandR evolutions, and that also means being backward-compatible with older RandR versions etc.

So it’s probably going to be only a simple shell script, executed by the frontend.

I’d like more input on this, so if you have a take on how it should/could be done, please drop me a mail. Otherwise you’ll have to live with whatever I’ll come up with ;-)

That’s a bugfix release for MacBook, PowerBook and iBook users. Pommed v1.11 will refuse to start on these machines claiming it didn’t find any event devices to use; I raised the number of expected event devices in v1.11, but unfortunately that number is only correct for the MacBook Pro.

So, here is v1.12 to fix that, and sorry :-)

Pommed v1.11 is out, including bugfixes, support for new hardware and some other changes.

As I mentioned already, the MacBook3,1 is now partially supported.

Also, I’ve fixed a long lasting bug with event devices disappearing after suspend; details can be found in this post.

If you use an external Apple USB keyboard, it should now work with pommed. At least the White and the Alu keyboards have been added, but there may be some other variants that I don’t know about.

If you were having trouble with the system beep feature, it may be because your system has the uinput device node in a different location than /dev/input/uinput; pommed now knows about 2 other locations.

Speaking of the beep, pommed now beeps when the audio volume is changed through the volume up/down keys. This used to be done in gpomme, but as pommed can do this by itself now, it was a good opportunity to remove some code from gpomme.

Ever since I wrote pommed, a really painful bug existed: after suspend, some event devices (anything USB-related) disappear and pommed must reopen them, and sometimes it failed to do so.

The problem is that the event devices can take an unspecified amount of time to reappear, and sometimes it exceeds the timeout set in pommed. To add insult to injury, depending on the machine and the setup, it can work every time, fail every time, or anything inbetween.

I’m very happy to tell pommed users that this problem is finally fixed. It’s in the SVN trunk for anybody who wants to test it, and I’m interested in feedback on that fix.

Now the gory details: I’ve rewritten all the event handling to use epoll() instead of poll() and added an inotify watch on /dev/input to catch newly created files. epoll() wasn’t necessary for that, but it’s more convenient to use compared to poll() when the list of fds to watch is dynamic.

Also, I’ve been asked to add support for the external Apple USB keyboards. Thanks to Carmine Paolino for this request which gave me the idea for the inotify watch, which is the real fix for the aforementioned bug.

If you have such a keyboard and its USB product ID is not 0×020c nor 0×0221, please mail me with the ID and the model name.

The latest MacBook equipped with a Core2 Duo and the Santa Rosa platform, dubbed MacBook3,1, is now partially supported by pommed, thanks to Paul van Tilburg who sent me the data I needed yesterday. It is available in the pommed SVN, but read on.

As with the last MacBook Pro refresh, I do not have support for the LCD backlight yet. It may or may not be supported by the ACPI video driver; if someone has access to a new MacBook and can test that and report back, that’d help.

Note that you’ll also need to patch your kernel, because Apple changed the keyboard and trackpad in this refresh. The new device is called Geyser IV-HF, and according to the Info.plist from the OS X kext, it’s compatible with the previous Geyser III and Geyser IV devices - you’re lucky. USB IDs for the new devices are 0×0229 for the ANSI version, 0×022a for the ISO version and 0×022b for the JIS version.

This refresh also brought a new iSight, USB ID 0×8300. The Apple IR receiver hasn’t changed (USB ID 0×8242).

The most common (and, in fact, visible) complaint concerning the New Maintainer process is the time it takes for the DAM to approve the applicant and, after that, create her account. No need to rehash over that.

Another very common problem seems to lie at the AM level, with a number of AMs being mostly inactive, as far as the NM process is concerned, for long periods of time. I know a number of NMs who are waiting for their AM to, basically, come back to life.

It’s not OK for an NM to have to wait for months for her AM at whatever step of the procedure without any reply whatsoever to her mails/IRC pings. It’s even less OK to have NMs wait for months for their final AM report to be posted on -newmaint.

The problem is not with the time taken by the whole procedure (though that can be improved too), the problem is with unresponsive AMs. If you can’t keep up, give up. Don’t let your NMs wait for you indefinitely.

It’s even worse when the AM wants to be the exclusive sponsor for her NM. That means the NM cannot properly take care of her packages in Debian. That’s not acceptable. That practice should be discouraged.

And, oh, this works both ways: if you’re in the NM queue and have time constraints impacting your application, please tell so to your AM and ask to be put on hold until you can find enough time to resume your application. You’ll help everybody by doing so.