dimanche 26 juillet 2009

Modern Begging

The more I hack on libgpod, the more I realize that having iPod models from various generations would be really helpful. When implementing support for setting the iPod time, for parsing the iPod timezone, for figuring out which information is useful in SysInfoExtended, ... I always end up running after people with various iPod models to make sure the code works as expected both on new and old iPods.

I'm sure some of you have old iPods they no longer use hidden somewhere in their room, if you are in this situation, a donation would be really welcome and helpful :) Even iPods with dead batteries or broken screens might be useful.

And while I'm at it, it would also really really help if I could get my hands on an old iPod touch or iPhone. Because this is where most of the work is to be done today, and without one such device, I cannot test thoroughly and get into shape stuff like that.

So if you're feeling generous today and want to help support iPods on linux, drop me an email or leave a comment below!

mercredi 27 mai 2009

Rhythmbox GSoC

The coding period for this year Google Summer of Code has just started. I haven't blogged yet about Rhythmbox GSoCs, now is a good time to do it ;)

This year, 2 students will be hacking on Rhythmbox. Paul Bellamy (who I am be mentoring) started hacking on synchronization between Rhythmbox and media players.

And John Iacona (mentored by Jonathan Matthew) will spend the whole summer working on a contextual information pane for Rhythmbox. This information pane will display various information about the song being played (artist bio, similar artists, ...)

mardi 19 mai 2009

Adventures in udev land

I've mentionned a while ago the work that has been done on libgpod hal callout. It's working nicely, but with HAL being deprecated, I thought now might be a good time at looking at how to do things in the future, and to check if udev already lets us do what we do in the HAL callout. The good news is that it's working now and is pretty straightforward. However, I got stuck on a few details, so I thought it might be useful to others if I documented my findings here.

Currently, libgpod installs a .fdi file with the iPod vendor ID/device ID and a binary name. When HAL detects that a device that matches these 2 IDs is plugged in, it runs the binary. The binary issues a SCSI inquiry command to the iPod to get various information, and set some HAL properties using libhal.

My goal was to do something similar with udev, ie get udev to run a binary when an iPod is inserted and then associate some information with the iPod device in udev database so that other applications can access it.


iPod detection

Running a binary when the iPod is inserted wasn't too hard, it's done with a udev rule file (the format is documented in udev manpage, don't forget to read it if you have to write such a file! ) which goes to /lib/udev/rules.d. My first version was simple enough:

ACTION=="add", SUBSYSTEM=="block", ENV{ID_FS_USAGE}=="filesystem",
ATTRS{idVendor}=="05ac", ATTRS{idProduct}=="1204",
RUN+="/tmp/udev-test.sh"

udev-test.sh is a simple shell script wrapping the actual udev callout. It makes it easier to dump various information to a log file (for example the callout environment which udev uses to pass useful information to the callout). And, lo and behold, after plugging an iPod, my shell script was run!


Adding information to the udev database

The next logical step was to add some values read from the iPod to udev database so that other apps can get this additionnal information. And this is one of the steps that gave me some troubles. I was a bit ashamed of finding a really informative post by Kay Sievers answering my question right after having sent this email...

In short, it's really easy to import new values in the udev database, all you have to do is to output key/value pairs on stdout. This is nice, since udev passes information through environment variables and adds information to its database by reading stdout, this means that your callout doesn't have to depend in anyway on libudev.

I quickly modified my test program to print a few key/value pairs to add to the environment, triggered an unplug/replug of my ipod with udevadm, and watch the 'block' subsystem devices with the devkit binary. But I was really disappointed not to find my values associated with the iPod :(

After double checking everything and fiddling a bit to try to figure out what was wrong, I read again Kay's email, and I saw there was another difference between his code and mine: he is using an IMPORT rule to run his binary while I was still using a RUN rule.

I changed my udev rule to an IMPORT rule and.... it still didn't work :;)After staring at udevadm monitor output, I noticed that when the iPod was plugged in, there was first an "add" udev event for the iPod device shortly followed by a "change" event. Since my rule was only catching the "add" event, I hypothetized maybe my changes to the udev database were first properly added, and then overwritten by the "change" event. So I changed my rule file to catch "change" events in addition to "add" events, and it finally worked!

ACTION=="add|change", SUBSYSTEM=="block", ENV{ID_FS_USAGE}=="filesystem",
ATTRS{idVendor}=="05ac", ATTRS{idProduct}=="1204",
IMPORT{program}="/tmp/udev-test.sh"

I was very happy with my udev callout, however I shortly realized that when going from a RUN rule to an IMPORT rule, udev no longer passed me the device name (/dev/sd??) in the DEVNAME environment variable. I went to #udev on freenode to check if this was the expected behaviour, and Kay confirmed this is normal because when IMPORT rules are run, the final device doesn't exist yet.

However, the $tempnode variable can be used as an argument to the binary that is being run to give it access to a temporary device node which can be interacted with. And indeed, after adding this argument to my udev rule, I could do everything that I wanted to :)


Final polish

After this successful experiment, all that remained to be done was to make the udev callout as featureful as the HAL callout. This was pretty straightforward, I abstracted the information gathering part from the HAL callout. This generic code then uses some backend-specific code to set the values. The HAL backend does that by using libhal, the udev backend does that by just outputting values to stdout.

David Zeuthen was (as always) really helpful by pointing me at the udev/devicekit equivalent for info.desktop.icon and info.desktop.name: DKD_PRESENTATION_NAME and DKD_PRESENTATION_ICON_NAME. I also cooked up some variable names in a LIBGPOD namespace to have an udev equivalent to the stuff provided by podsleuth, let me know if it could be useful in your projects, it can be changed to fit your needs :)


End result

And here is the end result after plugging in my iPod:

# udevadm info --query=env --name=sdb2

DKD_PRESENTATION_ICON_NAME=multimedia-player-apple-ipod-color
LIBGPOD_VERSION=1
LIBGPOD_IS_UNKNOWN=0
LIBGPOD_FIREWIRE_ID=000A270002BAD546
LIBGPOD_SERIAL_NUMBER=JQ446FN4R5Q
LIBGPOD_FIRMWARE_VERSION=1.2.1
LIBGPOD_IMAGES_ALBUM_ART_SUPPORTED=1
LIBGPOD_IMAGES_PHOTOS_SUPPORTED=1
LIBGPOD_IMAGES_CHAPTER_IMAGES_SUPPORTED=1
LIBGPOD_DEVICE_CLASS=color
LIBGPOD_MODEL_GENERATION=4.000000
LIBGPOD_MODEL_SHELL_COLOR=white
LIBGPOD_PRODUCTION_FACTORY_ID=JQ
LIBGPOD_PRODUCTION_YEAR=2004
LIBGPOD_PRODUCTION_WEEK=46
LIBGPOD_PRODUCTION_INDEX=20272
LIBGPOD_MODEL_CONTROL_PATH=/iPod_Control



Et voilà! The code is available from the devicekit branch of my libgpod git repo
and will be committed to libgpod svn soon.

mardi 31 mars 2009

Solutions Linux 2009

It's tomorrow. 9am. I'll be there. Waiting for you.

dimanche 29 mars 2009

Why is so hard to find a blog post title?

GSoC 2009




GNOME is a mentoring organization for the Google Summer of Code 2009. If you are a student who wants to get paid to hack all summer on free software, now is the time to apply, the deadline for application is on Friday, April 3rd.

You can find a list of ideas that have been proposed by GNOME contributors here but this list is in no way exhaustive so you can apply for any idea you care about and you think would improve the GNOME desktop!


Rhythmbox

Rhythmbox 0.12 was finally released a few weeks ago, it contains a lot of bugfixes and new features compared to the aging Rhythmbox 0.11.6. And development and bugfixing is going on in svn contrary to the impression some people had

There are 2 ideas proposed for the GSoC, one about media player synchronization (to keep Rhythmbox library and you favourite media player in sync), and one about getting information about the currently playing song (to know everything about your favourite group, get stats about the song that is playing, ...). You can find more details on the GSoC idea page on live.gnome.org

Solutions Linux

Solutions Linux
will take place in Paris on the 31st March, 1st and 2nd April (this is Tuesday, Wednesday, Thursday this week). This year it has moved from CNIT/La Défense to Paris Expo/Porte de Versailles so this will be an exciting new experience for exhibitors ;) Mandriva and GNOME-FR both have a booth, you should definitely come to visit us, entrance is free! And there will be tshirts and stickers on the GNOME booth, and plenty of good stuff on the Mandriva booth!

vendredi 6 février 2009

FOSDEM!

It's this week-end in Brussels, so make sure to go there if you don't already have plans for the week-end! I'll arrive in Brussels on Friday evening, not sure I'll be able to attend the beer party. Then I'll enjoy most of the great talks in the GNOME devroom and spend some time on the Mandriva booth as well. And am not sure yet what I'll be doing on Saturday evening, I guess something with the GNOMErs. Or the Mandrivians, we'll see ;)

If you are a GNOME contributor, don't forget the group photo on Saturday at 3.45pm. And there will be cool GNOME tshirts on sale as well.

Well, that's it, I don't really have much to say, this is just some shameless advertising ;)

vendredi 23 janvier 2009

Bloody spammers

If you are subscribed to a GNOME mailing list, you probably got a really long and off-topic email from me. Except it wasn't me who sent it.

Yesterday, I was spending a nice evening enjoying some good home-made sushis, and when I went back home, I was really surprised to see lots of emails about waking up the world, meeting the new boss, ... And I got very annoyed when I realized that these emails had been sent from my email address to most GNOME mailing lists existing on earth. I felt really bad when I saw some replies showing that some people thought this email really originated from me. So I did the only thing I could do, some limited damage control. I replied to the persons who mailed me directly and to a few select mailing lists to make it perfectly clear that this mail didn't originate from me despite what it seemed.

By looking at the headers of the email, it's quite clear (at least to me) that I didn't send it: it was sent from a US ISP and I'm living in France these days and mainly using gmail as a mailer. Moreover, careful readers of the email (I haven't even read it myself ;) will have noticed that this email is signed "david duke" which is not my name ;).

I think some guy box was taken over by a trojan and that it crawled gnome.org mailing list archives, got my email address from there and gathered the addresses of most mailing GNOME lists and then blindly spammed them. I sent an email to the abuse contact of the ISP, but I don't really expect too much from them.

Now you know about as much as I do about that embarrassing email that some spam bot sent impersonating me. If you know people who got this email and think it was really from me, please spread the word and let them know that I had nothing to do with that. I'd never sent some political email to dozens of mailing lists where it's off-topic, especially not a really controversial one like this one.

That's all folks, let's go back to hack now :)

mercredi 21 janvier 2009

First news of 2009 :)

New job

In my last post, I was looking for a job. The good news is that I started working at Mandriva 2 weeks ago. I'll be working on the core distro to (partially) replace pixel which means I'll hack on urpmi and bootloaders among tons of other things. Thanks to everyone who helped me with job opportunities!

libgpod

After far too much time, we finally released libgpod 0.7. It contains tons of improvements, the most noticeable being support for the latest Nano and iPod Classic, but there were lots of other improvements: writing of compact artwork files making the iPod more responsive, chapter data support, better iPod model detection, updated python bindings, improved API documentation, ...

There aren't many changes in this release for iPhone/iPod Touch support. However, in addition to the great work from the iFuse team, marcan figured out how to add songs to a jailbroken iPhone using amarok/gtkpod/rhythmbox/. If you add to that the iPod Touch is on its way to being jailbroken, this means that people really insisting on buying those devices will at least be able to use them without iTunes.

FOSDEM

FOSDEM is only a few weeks away now (7th and 8th of February), the GNOME and Freedesktop devrooms are booked and their schedule has been published. You should definitely plan a trip in Brussels if it's not done already :) And don't forget our group picture on Saturday if you are a GNOME hacker!