pommed v1.35: October 2010 MacBook Air

Published on November 13, 2010 in Hacks and pommed. Closed

I’ve just release pommed v1.35, adding support for the October 2010 MacBook Air machines.

Kernel support for these machines has been submitted during the 2.6.37-rc cycle, so it will appear in 2.6.37 or 2.6.38 depending on maintainers, merge window and patch readiness.

The machines have new keyboard assemblies (WellSpring IV and IVa) requiring new quirks in the HID layer, new trackpads, need sound & applesmc configurations of their own and the backlight module needs to know about them. So, make sure your kernel has all of that, otherwise your machine will be hard to use and pommed will not work at all.

Update: #603395 filed against linux-2.6 with all the needed patches attached. It looks like we’ll have all of this in Squeeze, thanks to our kernel team.

forked-daapd: Remote 2.0 and quick status update

Published on October 5, 2010 in forked-daapd and Hacks. Closed

Apple released Remote 2.0, which doesn’t work with forked-daapd. We are looking into it and trying to find out what the problem is. There are also more changes needed to support Remote 2.0 properly, so this will take some time.

Remote 2.0 also introduces support for the iPad, with very different features and new requests. I don’t have an iPad, so this won’t be supported.

For now, you should stick to the old version of Remote (1.3.3) until we get 2.0 working, at which point we’ll probably pull support for the previous version in an attempt to maintain everybody’s and the codebase sanity.

In other news, I have a few changes pending that I want to get in before I cut a new release.

forked-daapd: v0.12, release tarballs

Published on September 4, 2010 in forked-daapd and Hacks. Closed

Hey, look, a release! I’ve decided to start making tarball releases that make it easier to build forked-daapd, especially on embedded platforms.

The tarballs come with the build system already generated (as should any real release) and they also contain pre-generated source files for the ANTLR3-based parsers used in forked-daapd. The pre-generated files will be used if antlr3 is not available for the build.

I expect that pretty much everybody will end up using the generated files, given the feedback I’ve had about ANTLR3. I hope this will also clear the misconception that forked-daapd depends on Java.

I have expanded the installation instructions, making the distinction between building from the git tree and building from the tarballs.

A few more fixes made it to this version since my last post, and Kai also put the final piece to the sort headers by adding sort headers to the song listings.

Tarballs are available at http://alioth.debian.org/~jblache/forked-daapd/. Tarball integrity can be verified with GPG using the matching GPG signature file and my F5D65169 GPG key from the Debian keyring.

forked-daapd: new features, Squeeze

Published on August 29, 2010 in forked-daapd and Hacks. Closed

A number of things have happened in and around forked-daapd in the last month or so, so let’s review the new features and the plan for Squeeze.

On the features front, Kai Elwert has done a lot of work since July to implement missing features at the DAAP and DACP level to get better support for Remote:

  • playlists can now be played from Remote;
  • listings are sorted in a way that’s closer to what you get from iTunes;
  • sort headers are now generated when requested so Remote can display the A-Z quick access list.

Also, forked-daapd can now remember which speakers were selected before shutdown and attempts to automatically reselect these speakers the next time around. Speakers that were selected will be reselected if they appear at most 5 minutes after startup and the player isn’t running at that time.

On the Squeeze front, a viable snapshot of forked-daapd will release with Squeeze. This snapshot doesn’t have all the Remote improvements listed above, although it’s got the playlist support, can remember the speaker selection and includes bug fixes.

My plan is to provide backports through backports.org once Squeeze is released and for as long as possible after that.

There’s always more in the works, so stay tuned =)

Grand Central Dispatch available in Debian

Published on July 17, 2010 in Debian and Hacks. Closed

Thanks to the work of Mark Heily, both upstream and in Debian, this week saw the arrival of libdispatch in Debian.

libdispatch is the userspace component of Apple’s Grand Central Dispatch technology, designed to help write applications that really take advantage of multicore processors without having to fiddle directly with threads and locking (and getting it terribly wrong).

To get that working on Linux, Mark wrote a userspace implementation of the pthread workqueues and a kqueue compatibility library (libkqueue). He also packaged the Blocks runtime (libblocksruntime) for Debian so as to build libdispatch with Blocks support. That means code using libdispatch must be built with CLang (or llvm-gcc-4.2) rather than gcc, as getting Blocks support in gcc in the near future looks highly improbable.

On Mac OS X and FreeBSD, a kernel-based implementation of the pthread workqueues is used; we don’t have that for Linux yet. The all-userspace implementation we have at the moment works really well; there are some caveats, though, but that’s no reason for not starting to play with libdispatch right now!

Try it out, it’s great. Thanks again, Mark!

forked-daapd: available in experimental

Published on July 7, 2010 in forked-daapd and Hacks. Closed

Following the update of antlr3 in unstable, I have now uploaded forked-daapd to Debian. For now, and until the new version of antlr3 is ready to migrate to testing, forked-daapd will only be available in experimental.

I have also uploaded the ANTLR v3 C runtime (aka libantlr3c) to unstable. It’s currently blocked from migrating to testing, until antlr3 is ready to migrate.

Hopefully, the issues affecting antlr3 3.2 in unstable will be resolved soonish and all of this will migrate to testing and be part of Squeeze.

forked-daapd: now with AirTunes v2 streaming

Published on May 2, 2010 in forked-daapd and Hacks. Closed

I’ve been working on this for a few months now; it’s taken quite some time because I wanted to do it right and deliver something better than what already existed in the OpenSource world as far as that particular technology was (not) concerned. So here it is:

AirTunes v2 UDP streaming

forked-daapd can now do streaming to multiple AirTunes devices (as well as the local soundcard) and can be controlled from Remote (and, ideally, from anything that speaks DACP).

I’m releasing this early while the paint is still wet and not everything works on the DACP-side of things. Case in point, while playing a song or an album is supported, playing a playlist isn’t. There’s some work needed on this particular feature, and it’ll get there eventually.

There have been a couple of other changes in the codebase in recent weeks too; details after the jump.

Implementing AirTunes v2 has been quite fun and, in addition to releasing the forked-daapd code today, I’ve also taken the time to write down my findings about the protocol so others can experiment with it. This documentation is by no means exhaustive nor complete as far as the protocol goes; if you find out anything I haven’t, let me know so I can update this document.

Continue reading ‘forked-daapd: now with AirTunes v2 streaming’

rEFIt on x64: finally fixed

Published on April 21, 2010 in Debian. Closed

When I got my Mac Mini, one of the very first things I did was to test the Debian build of rEFIt on the machine, given the EFI firmware is x64 on the newer machines whereas it’s ia32 on my MacBookPro; it was the very first time I could test the x64 build.

And the results weren’t good: some images couldn’t be loaded, and it all seemed to be random.

Disabling optimization in both GNU EFI and rEFIt for the x64 builds helped somewhat, at least it made rEFIt reliable enough to be usable.

Now, with this new release, I started getting error messages, requiring a key press before the menu would be displayed. It’s annoying but it’s also very helpful as I now had an error message to work with, and even if the error message wasn’t reliable, it would still point me to some part of the code. The message was: Invalid argument.

On x64, the use of a call wrapper is mandatory because the EFI x64 calling convention doesn’t match the calling convention of the ELF executables we’re building and later disguising as EFI executables. The call wrapper has always been the prime suspect in this issue, it’d be an obvious candidate for anyone looking at this issue.

Today, digging into the issue with some new data, I realized what the problem was: when using the call wrapper, all arguments need to be of the UINT64 type. That’s the type the call wrapper uses when extracting the arguments from its va_list.

Introduce some more macros on top of the call wrapper, build, test: voila, it’s fixed! That was tricky one.

Let’s sum it up for the search engines: all the arguments to the EFI interface called through uefi_call_wrapper() in GNU EFI need to be cast to UINT64.

rEFIt 0.14-1, available in unstable in a couple hours.

Next, I’ll see if I can reenable optimization in both GNU EFI and rEFIt.

pommed v1.32: maintenance release

Published on March 19, 2010 in Hacks and pommed. Closed

I’ve just released pommed v1.32, a minor maintenance release for the 12″ PowerBook G4.

I’ve just realized that I did not post an announce for pommed v1.31 a while back, which was also a maintenance release, adding support for the MacBookPro5,4 (15″ June 2009) and the latest wireless keyboard.

Transitioning to a new RSA key

Published on March 5, 2010 in Debian. Closed

After weeks of trying to get around to doing that, I am finally starting the process of replacing my 10-year old 1024 bits DSA key with a shiny new 4096 bits RSA key.

The old key ID is F5D65169, the new key ID is FA1E5292; it’s available from the keyservers or my website.

I have put up a transition document, signed with both keys; if you’ve signed my old key, grab it, verify it and if all is OK on your end, please sign the new key.

You’ll notice that one of the old UIDs did not make it to the new key; that’s because I’m not using that email address and don’t actually intend to use it in the future.

Thanks!