Random stuff

New stuff in gnome-vfs-obexftp

Recently, Bastien has been doing a bit of hacking on gnome-vfs-obexftp. The changes remove the use of the org.bluez.RFCOMM interface to hcid, instead doing SDP and createing RFCOMM sockets directly. This removes the need to run hcid with its experimental interfaces enabled. This is also good because the org.bluez.RFCOMM interface has been removed in newer releases (replaced by org.bluez.serial.Manager).

I’ve now integrated that patch and made a number of further clean ups so that we don’t need any D-Bus requests to establish the connection to the remote device. Now the only D-Bus requests being made are for device enumeration used for the “obex:///” virtual folder. Should make it easier to switch over to HAL if/when it supports scanning for Bluetooth devices.

I also had a go at fixing bug #116912. Using the memory type information provided in folder listings on Nokia phones, I’ve now got the get_volume_free_space() routine to return the free space of the appropriate memory type for the folder. While this works fine in the GNOME-VFS API, unfortunately it hasn’t improved matters in Nautilus. It seems to always request the free space for the root directory, so I still see an incorrect free space value for e.g. obex://[...]/Memory%20card/ on my phone. I’m not sure how I’ll go about fixing that.

There does appear to be some problems with some Sony phones, but I don’t have any hardware to test this. Perhaps this is something to work on in the next release if I can get some help debugging the problem.

Update: looks like I spoke too soon about Nautilus not getting the correct free space value.  After restarting Nautilus again, it started showing the free space correctly, and I can copy large files to my memory card.

Stupid Patent Application

I recently received a bug report about the free space calculation in gnome-vfs-obexftp. At the moment, the code exposes a single free space value for the OBEX connection. However, some phones expose multiple volumes via the virtual file system presented via OBEX.

It turns out my own phone does this, which was useful for testing. The Nokia 6230 can store things on the phone’s memory (named DEV in the OBEX capabilities list), or the Multimedia Card (named MMC). So the fix would be to show the DEV free space when browsing folders on DEV and the MMC free space when browsing folders on MMC.

Doing a bit of investigation, I found that the information I wanted was in the folder listings:

<?xml version="1.0"?>
<!DOCTYPE folder-listing SYSTEM "obex-folder-listing.dtd"
 [ <!ATTLIST folder mem-type CDATA #IMPLIED> ]>
<folder-listing version="1.0">
    <folder name="Memory card" user-perm="RW" mem-type="MMC"/>
    <folder name="Images" created="19800101T000008" user-perm="R" mem-type="DEV"/>
    ...
</folder-listing>

I took a look through the OBEX specification, and this mem-type wasn’t defined. So it looked like a Nokia extension. Doing a quick search, the closest I came to a describing it was US patent application #20060095537.

So Nokia is effectively trying to patent an XML attribute. I’d seen a lot of bad patents, but this seemed particularly weak. The patent application even comes with a useful diagram explaining the invention:

Figure 2

As far as I can tell, using the information returned from the phone wouldn’t be covered by the patent (if it gets issued, that is). So it should be fine to use the information to calculate free space more accurately.

FM Radio in Rhythmbox – The Code

Previously, I posted about the FM radio plugin I was working on. I just posted the code to bug 168735. A few notes about the implementation:

  • The code only supports Video4Linux 2 radio tuners (since that’s the interface my device supports, and the V4L1 compatibility layer doesn’t work for it). It should be possible to port it support both protocols if someone is interested.
  • It does not pass the audio through the GStreamer pipeline. Instead, you need to configure your mixer settings to pass the audio through (e.g. unmute the Line-in source and set the volume appropriately). It plugs in a GStreamer source that generates silence to work with the rest of the Rhythmbox infrastructure. This does mean that the volume control and visualisations won’t work
  • No properties dialog yet. If you want to set titles on the stations, you’ll need to edit rhythmdb.xml directly at the moment.
  • The code assumes that the radio device is /dev/radio0.

Other than that, it all works quite well (I’ve been using it for the last few weeks).

Development

I developed this plugin in Bazaar using Jelmer‘s bzr-svn plugin. It produces a repeatable import, so I should be able to cross merge with anyone else producing branches with it.

It is also possible to use bzr-svn to merge Bazaar branches back into the original Subversion repository through the use of a lightweight checkout.

For anyone wanting to play with my Bazaar branch, it is published in Launchpad and can be grabbed with the following command:

bzr branch lp:~jamesh/rhythmbox/fmradio rhythmbox

FM Radio in Rhythmbox

  • Post author:
  • Post category:Uncategorized

I’ve been working on some FM radio support in Rhythmbox in my spare time. Below is screenshot

At the moment, the basic tuning and mute/unmute works fine with my DSB-R100. I don’t have any UI for adding/removing stations at the moment though, so it is necessary to edit ~/.gnome2/rhythmbox/rhythmdb.xml to add them.

FM Radio Tuners in Feisty

  • Post author:
  • Post category:Uncategorized

I upgraded to Feisty about a month or so ago, and it has been a nice improvement so far. One regression I noticed though was that my USB FM radio tuner had stopped working (or at least, Gnomeradio could no longer tune it).

It turns out that some time between the kernel release found in Edgy and the one found in Feisty, the dsbr100 driver had been upgraded from the Video4Linux 1 API to Video4Linux 2. Now the driver nominally supports the V4L1 ioctls through the v4l1_compat, but it doesn’t seem to implement enough V4L2 ioctls to make it usable (the VIDIOCGAUDIO ioctl fails).

To work around this, I ported the tuner code in Gnomeradio over to V4L2. The patch can be found attached to bug 429005. I don’t know if this patch will go in as is though, since it only works for drivers supporting V4L2. Perhaps it’d be worth supporting both APIs, using V4L2 if both are supported.