A bugfix release for pommed, fixing a crash when the default beep file is not available. One part of the audio code we’ve reused had a broken error handling, and you know how that kind of things tend to end (badly).
Also, the default beep sound was pretty horrible according to the feedback I’ve got so far, so the default beep sound has changed and another sound is shipped if you don’t like the default (the clicking sound that was in gpomme).
Pommed v1.13 is out and features a couple of new features and a bugfix for a potentially annoying bug.
This release adds support for the MacBook3,1 LCD backlight; turns out the 965GM works pretty much the same way the previous versions did.
Following my previous post on the subject, I’ve added the ability to run a script when the video switch button is pressed. The script is run by the frontend, so you need to have either gpomme or wmpomme running; see the documentation in the INSTALL file for details. Feedback on this feature and sample scripts for the different machines are welcome.
In v1.11, I moved the beep code from gpomme to pommed, making pommed beep on volume change. Not everybody likes this, so you can now turn that off in the config file (beep = no in the audio section).
And, last, the bugfix. Pommed could turn into a CPU hog under certain circumstances; this releases fixes that, and though most systems won’t trigger this bug, you should upgrade if you’re running 1.11 or 1.12.
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).
A new release with a new feature: pommed can now act as a replacement for the PC Speaker and play your favorite WAV file as the system beep.
The feature is disabled by default as it’s not needed on all machines (most of the PowerPC machines have their system beep handled by the sound driver) and I guess not everybody wants it by default. You need to load the uinput driver before pommed starts for this to work.
If you want your Mac to behave like a good old Mac and have it quack at you, Google for Quack.aiff and turn that into a WAV file ;)
Have fun!
After adding the ability to load 64bit kernels on machines equipped with a 32bit PROM, I’ve now added initrd support to arcload.
I’ve tested that code on IP22, if you give it a go on another platform please let me know how it goes! Don’t bother with IP27, initrd is unsupported in the kernel on that one (some work required). Patches welcome if any are required.
To add an initrd to your arcload config, use the initrd keyword in the same manner you use the image keyword. And to be on the safe side, add a test entry, so that you can still boot the machine if for some reason the initrd can’t be loaded :)
I’ve produced a patch for arcboot too, so that will appear in arcboot at some point in the near future too.
For the past weeks, I’ve been working on getting an SGI Origin200 system to run Debian.
Getting a working kernel for the machine took some time and lead to the discovery of 2 nasty bugs, which will be fixed in 2.6.23 thanks to Ralf Baechle (who found and fixed both bugs). There’s still some work left but the machine is in a usable state, except for a dead eth1 interface.
Now I’m having some fun with the bootloader, namely ARCLoad in this case. ARCLoad supports all the Linux-supported SGI MIPS machines, but couldn’t load 64bit kernels on machines equipped with a 32bit PROM; all Debian kernels for SGI MIPS machines have been 64bit for some time now, so that means ARCLoad was unusable with these machines (note that the Origin200 comes with a 64bit PROM, so this wasn’t a showstopper for this project).
Thankfully another bootloader, arcboot, is used for these machines and supports 64bit kernels. Stealing a snippet of code from arcboot I’ve now uploaded arcload 0.5-5 which fully covers our needs. The joy of free software.
I’ve also been working on getting the latest rEFIt version to build with GNU EFI, which means updating GNU EFI to efi110. Took some time, but everything built in the end. I haven’t tested the resulting rEFIt binary yet, waiting some feedback from GNU EFI uptream before doing so.