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!

At this point, there won’t be much visible activity on forked-daapd for some time. I’m working on a couple of things, but they take time and they require a lot of new code.

So, for a couple weeks now, I’ve been working on that. I have some code outside forked-daapd that is starting to work well, but it’s not there yet, far from it. Then it’ll have to be integrated into forked-daapd, which means a lot of new code there too.

Bug fixes will still happen in the meantime, and some smaller new features may also appear before the Big Thing™. So if you find or encounter bugs, feel free to report them still. If you have patches or ideas you want to discuss, feel free too.

As I wrote to a couple people by mail already, good things come to those who wait or contribute.

With all that, I’ve updated the Debian packages, given that there won’t be important changes for a while; I hope they’re useful to some of you out there. Note that I’m making an amd64 binary package available alongside the source package; it’s built on a current Debian unstable system, but if that’s not suitable for you, in terms of dependencies or architecture, you can trivially build a suitable binary package from the source package. As a reminder, I have packages of the ANTLRv3 C runtime too. I’ve also added antlr-3.1.3.jar there, in case you need it and can’t find it at the upstream download site.

It’s been a fun ten years, with ups and downs, and I’m looking forward to what’s coming next.

The filescanner for forked-daapd on FreeBSD is now up to par with its Linux counterpart, as much as possible. Contrary to the latter, it will lose some metadata (play count, for instance) when files get moved around, because it’s not possible to track moves and renames accurately. It also performs more rescans than the Linux/inotify implementation. Still, it works just as good.

On a related note, the machine I tried to install FreeBSD 8.0 on and finally ended up installing GNU/kFreeBSD on just seemingly committed suicide. I’m not sure what message it’s trying to send me. It’s previously been my main workstation for the best part of 10 years, so this is a bit sad.

At least I found some bugs in the process and fixed some too:

• 2 bugs in forked-daapd, one of them a crasher,
• a bug in Avahi on kFreeBSD,
• a bug in GRUB2 as used on the kFreeBSD daily d-i images.

Not bad, is it?

So, I’ve just spent a day going through FreeBSD documentation, installing FreeBSD 8.0 in qemu (because it wouldn’t install on my spare machine due to a bootloader issue that’s at least 5 years old…), and started porting the codebase.

A dozen or so commits later, forked-daapd builds and runs on FreeBSD.

With one caveat: the filescanner doesn’t update the database on the fly when the library directory is modified. While I’ve put in support for kqueue/kevent to replace inotify, it’s only a stub for now. Someone will have to write the code to actually act on the events and trigger the rescans/database updates.

kqueue/kevent delivers a lot less information compared to inotify, which means there’s a lot of work needed to track renames and moves. And I didn’t feel like doing it.

So, FreeBSD users: send patches! :)

I’ve asked our customer for its approval for releasing our packaging scripts to the community and got it, so here are our packaging scripts for this version, courtesy of EDF. See the instructions in debian/README.source for what has to be done to turn it into a full source package.

The packaging is based on our previous 6.5.2 packaging, which was itself based (partially, at least) upon the Gento 6.5.2 ebuild. It uses a tweaked vmware-installer to install the products to debian/tmp, then makes use of the vmware-installer database to populate the packages.

I think this method should work with any VMware product using vmware-installer 1.1.

Packages have been built and tested on Etch and Lenny.

Hope it helps! Bugs, comments, questions to the email address listed as Maintainer in debian/control, please :-)

The biggest change is the addition of TV shows metadata as found, for instance, in TV shows bought on the iTunes store. Together with the added support for FrontRow and QuickTime clients, this means forked-daapd is a lot more able at streaming video files than it ever was. Kudos to Ace Jones for his work!

Note, however, that you’ll need a patched version of ffmpeg to pick up the TV shows metadata from your MP4 files. At the time of writing, the patches have not landed into ffmpeg upstream yet, and it’s a bit unclear when this will happen. Contact Ace for the patch and instructions, see the commits in the git tree for his email address.

Git tree on Alioth: http://git.debian.org/?p=users/jblache/forked-daapd.git (git URIs on the page)

Getting it to run smoothly under Linux is not a walk in the park, however. There are some quirks and some assembly is required, but once you’re done (that takes a couple of hours at most once you’ve got all the info, which you have if you’re reading this) this machine is just great.

It’s fast, with a 2.1 GHz Pentium Dual-Core (T4300) CPU, 4 GB of RAM, an Intel GM45 GPU with up to 256 MB of shared RAM, gigabit networking, a fast 320 GB SATA disk and a combo DVD-drive (not a slot-in, too bad). The screen is nice, and the touchscreen is incredibly smooth, precise and sensitive. The sound is good, the webcam is great and it works out of the box, too!

Update: added a note about the card reader.

Update 2: the instructions can also be found on the Debian wiki now.

Before you go

Enter the BIOS and bump the amount of memory allocated to the GPU to 256 MB. By default, the machine ships with only 64 MB allocated to the GPU, which is low and ridiculous considering it is equipped with 4 GB …

Installing Debian

Forget about installing Lenny with debian-installer on this machine. The standard installer with its 2.6.26 kernel doesn’t support the network interface properly. Upgraded installer images with 2.6.28 or 2.6.30 kernels end up locking the machine solid before the first installer screen.

Your best friend: System Rescue CD. Your other best friend: debootstrap.

Before rebooting, install the 2.6.30 kernel from backports.org. It works like a charm, even if the 2.6.30 on the upgraded installer locked up solid. Go figure :) While you’re at it, install X from Testing. You need a recent enough version of the intel driver that will support the GM45 chip.

Configuring X

This is the first and the biggest quirk on this machine. The LCD is actually wired up to both the VGA and the LVDS outputs on the graphic card, and advertises different resolutions on both. The native resolution (1600×900 on this model) is only advertised on the LVDS output.

While fiddling with X, it becomes obvious that the VGA output is used as the boot video device. If you disable the output in X with xrandr, you loose the text consoles. My un(?)educated guess is that this setup allowed them to use a standard desktop PC BIOS instead of using a more expensive laptop BIOS. I may be wrong, but that’s pretty much the only thing that makes sense to me.

Anyway. If you want X to work properly, you’ll have to tell it to ignore the VGA output entirely.

Section "Device"
 Identifier      "Intel X4500"
 Option          "Monitor-LVDS"  "Panel on LVDS"
 Option          "Monitor-VGA"   "Panel on VGA"
EndSection

Section "Monitor"
 Identifier      "Panel on LVDS"
EndSection

Section "Monitor"
 Identifier      "Panel on VGA"
 # The LCD panel is wired up on both VGA and LVDS
 # Ignore the VGA output as far as X is concerned
 Option          "Ignore"        "True"
EndSection

If you don’t tell X to ignore the VGA output, you’ll end up with a mirror setup and your desktop will use the smallest size so as to fit on both monitors. It isn’t pretty, it’s plain silly and we want those 20″ used fully, dammit!

See the full xorg.conf.

Touch screen

The touch screen is an infrared multipoint touch screen from Quanta. No kernel driver is needed, only an input driver for X is required.

Start by adding an udev rule like this one:

SUBSYSTEM=="usb", ATTRS{idVendor}=="0408", ATTRS{idProduct}=="3000", SYMLINK+="usb/quanta_touch"

The touch screen will now appear as /dev/usb/quanta_touch, which is more handy and stable than /dev/usb/hiddevN.

Grab xf86-input-hidtouch from HidTouch Suite on SF.net, and apply this patch. The aim of the patch is to ignore anything but the first reported pressure point. The touch screen is a multipoint touch screen and as such can report 2 or 3 (not sure) pressure points at the same time. The driver can’t handle that … yet. The patch also fixes a bad comment and an API difference with newer X versions.

Build and install the driver, then edit xorg.conf:

Section "InputDevice"
 Identifier      "Optical Touch Screen"
 Driver          "hidtouch"
 Option          "SendCoreEvents"        "true"
 Option          "ReportingMode"         "Raw"
 Option          "Device"                "/dev/usb/quanta_touch"
 Option          "PacketCount"           "13"
 Option          "OpcodePressure"        "852034"
 Option          "OpcodeX"               "65584"
 Option          "OpcodeY"               "65585"
 Option          "CalibrationModel"      "1"
 Option          "CornerTopLeftX"        "0"
 Option          "CornerTopLeftY"        "0"
 Option          "CornerTopRightX"       "1600"
 Option          "CornerTopRightY"       "0"
 Option          "CornerBottomLeftX"     "0"
 Option          "CornerBottomLeftY"     "900"
 Option          "CornerBottomRightX"    "1600"
 Option          "CornerBottomRightY"    "900"
 Option          "CornerScreenWidth"     "1600"
 Option          "CornerScreenHeight"    "900"
EndSection

There you are. Working touch screen!

Credit: the above touch screen setup instructions, including the patch (which I reworked slightly…) were taken from this post on the Ubuntu-fr.org forum. The instructions cover the Packard Bell Viseo 200T touch screen, which is identical to what’s used on the OneTwo. If you’re looking for a 20″ touch screen, go for it; at 200 Euros it’s a good deal.

Sound

The Realtek ALC268 codec as used in the OneTwo isn’t properly supported yet, however using model=acer-aspire works for the integrated speakers and the headphone jack. Line out and the integrated microphone do not work.

Webcam

The webcam is a UVC webcam and the image quality is stunning. I’m seriously considering stealing that webcam to replace the iSight in my MacBook Pro. It works out of the box without any firmware. Quite a good surprise :)

Flash card reader

The integrated flash card reader also works out of the box, for the card formats supported by Linux.

• a crasher bug on PowerMac machines
• a bug in the sysfs backlight driver, mishandling brightness values with more than 3 digits

If you are running on a recent MacBook/MacBook Pro with a recent kernel, you’ll probably want to upgrade to this release.

When pressing the video switch key, your graphical pommed client of choice checks which VT its X server is running on and whether this VT is the active one before executing your video mode switch script.

To check that the VT is currently active, it is necessary to open one VT (we use the one our X server is running on) and perform an ioctl() call on it.

Depending on your setup (login manager or startx, basically), your user will or will not have any right on the device node associated to the VT. Which means the VT state checking code would always fail in some setups.

This is now fixed by moving that code into pommed itself, with a DBus method for the clients to call. You’ll need to update both pommed and the clients for this to work, for obvious reasons.