Gnome

Investigating OBEX over USB

I’ve had a number of requests for USB support in gnome-vfs-obexftp. At first I didn’t have much luck talking to my phone via USB. Running the obex_test utility from OpenOBEX gave the following results:

$ obex_test -u
Using USB transport, querying available interfaces
Interface 0:   (null)
Interface 1:   (null)
Interface 2:   (null)
Use 'obex_test -u interface_number' to run interactive OBEX test client

Trying to talk via any of these interface numbers failed. After reading up a bit, it turned out that I needed to add a udev rule to give permissions on my phone. After doing so, I got a better result:

$ obex_test -u
Using USB transport, querying available interfaces
Interface 0: Nokia Nokia 6230 (null)
Interface 1: Nokia Nokia 6230 (null)
Interface 2: Nokia Nokia 6230 (null)
Use 'obex_test -u interface_number' to run interactive OBEX test client

With the change, I was also able to access the phone using the obexftp command line client. This seemed enough to start investigating a bit further. The OpenOBEX API for setting up USB connections goes something like this:

  1. The app calls OBEX_FindInterfaces(), which returns a list of obex_interface_t structures that represent the different discovered interfaces.
  2. The app picks one of the discovered interfaces (based on the manufacturer, product and serial number strings), then connects to it using OBEX_InterfaceConnect().

There are a number of issues with this interface though.

  • If the phone doesn’t provide a serial number via its USB interface (like my 6230 doesn’t), the obex_interface_t structure is not enough to identify a particular phone.
  • If the phone exposes multiple OBEX USB interfaces for some reason, OpenOBEX lists it multiple times. In the obex_test output shown above, there was a single phone attached – not three.
  • There is no way to tell when phones are connected or disconnected. While HAL can do that job for us, there is no way to map from the device information provided by HAL to one of the discovered interfaces provided by OpenOBEX.

To sum up, it shouldn’t be difficult to hack support for USB connections into gnome-vfs-obexftp with URLs like obex://usb-N/ (where N is the number of the discovered interface), but there are a number of features I’d need to provide a good user experience:

  1. The ability to ask OpenOBEX to connect to a particular USB device, rather than having to deal with its discovery interface.
  2. A good set of udev rules to grant the needed permissions on common phones so they don’t need to find out why things only work as root.

TXT records in mDNS

Havoc: for a lot of services advertised via mDNS, the client doesn’t have the option of ignoring TXT records if it wants to behave correctly.

For example, the Bonjour Printing Specification puts the underlying print queue name in a TXT record (as multiple printers might be advertised by a single print server). While it says that the server can omit the queue name (in which case the default queue name “auto” is used), a client is not going to be able to do what the user asked without checking for the presence of the record.

Rather than thinking of TXT records as optional data, it is better to think of them as “stuff that is can not be used to perform searches”. In the printer example above, the fact that you can’t search by print queue name is not a problem because users instead pick a printer based on the human readable service name which is exposed as a DNS name.

In your example of including session and machine identifiers in TXT data, it would be enough to tell a client that two services belonged to the same machine or session, but it wouldn’t let you do searches like “find all the card game servers belonging to the same session as the guy I’m chatting with”.  For that you’d also need to advertise DNS names that include the machine identifier or session identifier.

gnome-vfs-obexftp 0.3

I’ve just released a new version of gnome-vfs-obexftp, which includes the features discussed previously. It can be downloaded from:

http://download.gnome.org/sources/gnome-vfs-obexftp/0.3/

The highlights of the release include:

  • Sync osso-gwobex and osso-gnome-vfs-extras changes from Maemo Subversion.
  • Instead of asking hcid to set up the RFCOMM device for communication, use an RFCOMM socket directly. This is both faster and doesn’t require enabling experimental hcid interfaces. Based on work from Bastien Nocera.
  • Improve free space calculation for Nokia phones with multiple memory types (e.g. phone memory and a memory card). Now the free space for the correct memory type for a given directory should be returned. This fixes various free-space dependent operations in Nautilus such as copying files.

Any bug reports should be filed in Launchpad at:

https://bugs.launchpad.net/gnome-vfs-obexftp/

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