Initially, it was possible to turn on the system tray compatibility function in Unity with a simple dconf setting, but in 13.04, this was changed so that it would only work for java, and nothing else. In turn, this led to the creation of ppas for 13.04 and 13.10 to provide patched versions of Unity with the general purpose system tray restored (a one line change, apparently). I’ve been running with that for a while, but I didn’t want to swim upstream on this issue forever, so I decided to write a pidgin plugin that provides a proper indicator, with the same menu and behaviour as the tray icon.

It turned out to be an interesting exercise – creating indicators is extremely simple – all credit where it’s due – with the main challenge being building the menu without reinventing a wheel that’s already present inside pidgin. The pidgin tray icon (docklet is the internal name) is not a plugin, although there is a partial concept of different providers. Unfortunately, the interface can’t be used to drive an indicator as it assumes it can show the menu itself, while indicators require the menu be shown by the indicator. Ultimately, I had to copy the docklet code into my plugin to make the necessary modifications.

It would be possible to modify the docklet interface in pidgin to allow for an indicator provider with minimal impact on the existing providers, but I wanted to offer a working solution without requiring a newer version of pidgin, never mind the complexities of feeding changes upstream, etc. But, there’s an aspirational project there.

So, without further ado, I’d like to offer to all the stubborn people who want pidgin to work they way it always used to in Unity.

At some point I’ll get around to producing a deb for it, but just source for now.

Enjoy!

2 0

It’s been a while since my last update (over a month!) so it’s a good time to talk about what’s been going on.

Firstly, GVFS 1.16 is out – so that’s the first stable release with the MTP backend in it. w00t!

Before you wonder, it doesn’t include my work to support the Android Direct I/O extensions (that allow normal read/write access to files on the device). I’ve now got those to a point where I’m ready to get them in, but I’m waiting on a review in bugzilla. Since my last update, all the libmtp changes have been merged and released in version 1.1.16.

The second big thing I’ve done is completely change how mtp URIs work. In previous posts, I’ve talked about how I was putting entity IDs as path elements to save having to maintain an ID->filename mapping, and then relying on the gvfs display and copy name properties to make the files appear to have normal names when looked at. I ultimately decided to abandon this approach for a couple of reasons. The main one is that with Direct I/O support, every application that can operate on files can be used with an MTP device, and most of those apps don’t know anything about gvfs and can’t use the special properties. The second reason is that there are edge cases where it’s impossible to tell if you’re looking at a filename that’s all numbers or an entity ID. So, I’ve added a mapping system and URIs now use filenames.

Finally, I’ve fixed a bug in gvfs that only got triggered when unmounting an mtp device in Ubuntu 13.04 betas. The code in question hasn’t changed in gvfs for a long time, but the bug didn’t appear anywhere else. Still, there is a real code problem in there, so I’ve got a fix out for it.

I’ve updated my with builds that contain all these pending patches (although the raring gvfs got updated while mine was building so it’s now considered out-of-date) and the new libmtp, so please try the new stuff out.

For the curious, here are the GNOME bugzilla entries tracking these changes:

• Add support for Android direct I/O extensions
• Implement filename cache to enable name based URIs
• gvfsmonitor.c: backend_died needs to take a ref while unsubscribing subscribers

Enjoy!

0 0

I’ve now had a chance to put together an initial implementation of support for these extensions, and my PPA is in the process of rebuilding packages, so people can try them out easily. I’ve not started the upstreaming process on the GVFS changes as I still need to get the libmtp changes approved and upstreamed, but the libmtp maintainer has been AWOL for a few weeks now.

Obviously, it’s important to remember that these extensions are Android specific and won’t help you if you have a non-Android device, nor if your Android device doesn’t use Google’s MTP implementation (which, unfortunately, includes most Samsung devices).

You can grab Ubuntu packages from my ppa and the source is available on my github page.

0 0

Enjoy!

1 0

Happy New Year! And the new year brings new updates on the gvfs MTP front. I received a bunch of useful feedback from the gvfs maintainers last month, which I was finally able to get time to sit down and address over the last few days. Accordingly, I’ve made a series of updates that fix a variety of things, from small memory leaks all the way to, finally, implementing the right way to tell Nautilus to do directory downloads/uploads in the right way (You’ve got to return a specific error code) – which fixes the one remaining functional gap in the code. Uploading a directory is still not fully working as I need to handle the way Nautilus ends up referring to uploaded directories by name when trying to upload their contents. Right now there’s no logic to remap the name to the MTP entity ID so the file uploads fail, but I know what has to be done.

I think we’re nearing the finish line, with respect to getting this merged upstream. *phew*

As always, the easiest way to try the code out is to install the packages from my PPA. I have also put a build of libmtp 1.1.5 in there so that unlock events and thumbnails work out of the box too.

Enjoy!

1 0

It’s been quite a while since I wrote my gvfs MTP backend work, but that doesn’t mean nothing has happened in the meantime. Since then, I’ve improved the functionality quite a bit, including submitting patches to libmtp to support grabbing thumbnails and detecting “Add Storage” events (which you want to do so that when someone unlocks their phone, the phone storage automatically appears). I’ve also started the review process for submitting upstream (See GNOME Bug 666195), so hopefully we’ll see it upstream in the next couple of months.

More practically, and the main reason for writing this post, I’ve finally got around to setting up a ppa to host builds of gvfs with my patches applied. Learning how to set up a ppa was interesting, and pretty painless – so the end result is working packages for Ubuntu 12.10. Note that due to 12.10 only including libmtp 1.1.4, neither of the features I mentioned above is enabled in these builds (so you’ll have to refresh your nautilus window after unlocking). Perhaps I’ll throw a build of 1.1.5 in there too at some point.

You can find the ppa here. Enjoy!

1 1

What is MTP?

MTP is a standardised protocol that was originally designed to allow a PC to effectively manage the contents of a media player device – specifically, audio, video and image files. It is, in turn, based on an older specification called PTP (Picture Transfer Protocol) that was designed for use with Cameras. Note that neither of these uses cases has to do with managing the contents of an arbitrary filesystem. Of course, you can read more about MTP on wikipedia.

Why should I care?

Well, most people didn’t need to care about MTP for a long time – the chances were pretty good that their media player device didn’t use MTP (it either used USB Mass Storage or was an Apple device with its own crazy protocol), and their camera had a reasonable chance of using USB Mass Storage, and in the worst case you could always eject the memory card and use a reader with it.

However, since Android 3.0 (Honeycomb), Android devices have stopped using USB Mass Storage for PC connectivity, and switched to MTP. Now wait, you say, why would you use MTP to manage the contents of an arbitrary filesystem – a very good question. The primary reason is that USB Mass Storage is a block level protocol, and consequently operates below the filesystem layer. This means that it can’t be used to share a filesystem between the phone/tablet and the PC – only one device can read/write at a time. In older Android devices, this meant having a separate partition or memory card that was inaccessible to the phone while the PC was using it. But, from Honeycomb onward, Google wanted to have a more unified filesystem on the device, and not have to worry about ensuring there was a storage area that could be unmounted at random times. MTP may be an ill-fitting choice, but it’s the only standardised protocol which offers the key required feature – that being that you can have both the phone and PC use the filesystem at the same time.

This is posible because MTP treats files as the atomic data unit, rather than blocks. So you read and write whole files, and nothing smaller. At that point, the PC interacts with the filesystem pretty much like any other application running on the phone.

Ok, so I have to care about MTP to access files on my phone. Why’s that worth talking about?

Well, here’s the kicker. Your shiny new Android phone uses MTP, and there are a plethora of applications and components for Linux that notionally can manage MTP devices. Unfortunately, they are all limited in various ways, that make them pretty much unusable. The most common flaw is that the tools use an MTP library call that attempts to enumerate the entire device filesystem in one go. This causes the initial connection to be very slow, and on the newest Android devices, it flat out doesn’t work, as the phone end will timeout the operation before it completes. This ends up taking out every single tool on the market (including: mtpfs, gmtp, banshee, rhythmbox, gvfs gphoto2 backend) except for one: go-mtpfs.

go-mtpfs?

go-mtpfs is a recent creation of a Google employee, who was aware of the timeout behaviour of android devices, and so they wrote a FUSE filesystem (much like the original mtpfs) but which did on-demand file enumeration, as each directory is loaded and queried (which is how the Windows MTP implementation works). The end result is quick connections, and a tool that can talk to Android devices well.

So we’re done?

Well, no, not quite. Although go-mtpfs uses MTP the right way, it can’t avoid the horrible impedence mismatch between MTP’s file-atomic model and a traditionally filesystem where you can do random I/O within a file (ie: open, seek, read, write, close, etc). MTP only allows you to download a complete file, or upload one – you can’t even move a file between locations on the device through MTP (you have to download it, delete it, then upload it to the new location). Of course, FUSE doesn’t care that you can’t provide normal filesystem semantics, so you have to improvise. In this case, that means that any read/write operations requires go-mtpfs to do an elaborate and fragile dance to download a file, modify it, and upload it again, and so on. This causes simple file operations to behave strangely, and things can go very bad if you use a tmpfs for /tmp and try to access a very large file.

And so: gvfsd-mtp

And finally we reach the meat of this post. gvfs is the virtual filesystem layer that’s used by Gtk+ based desktop environments (GNOME 3, Unity, XFCE, etc). It happens to allow backends to implement a much higher level API than FUSE, and this API happens to explicitly offer ‘pull’ and ‘push’ operations (download and upload respectively). As such, it’s possible to meaningfully map functionality without jumping through crazy hoops.

So, I’ve been working for the last few weeks on a native mtp backend for gvfs. It’s heavily based on the existing gphoto2 backend, but only attempts to implement the operations that MTP can cleanly accomplish.

The end result is a filesystem like view that you can effectively browse through nautilus, and that you can download files from and upload files to with a reasonable hope of success. It’s not seamless as gvfs/nautilus do not do anything very special when you attempt an unsupported operation – so trying to just open a file will probably fail (although some GNOME apps like evince or file-roller seem to be able to detect the behaviour and will automatically download the file and open the temporary copy), but it’s functional and reliable.

Another thing I did was to avoid caching any metadata that I could avoid caching. All other MTP implementations tend to save directory listings after getting them and don’t go back to the device. But the device can be adding/removing files all the time, so it’s important to be able to get a fresh listing when you need it. To achieve that, I took advantage of the fact that gvfs lets you define ‘display names’ for files – which can be completely different from the reported filename. So I directly mapped the MTP object IDs (numbers) to the reported filename and made the real filename appear as the display name – so the view in Nautilus looks completely normal but the gvfs URI might be something like mtp://[usb:001,015]/65537/1/128/2445

This general behaviour is actually very similar to how Windows presents MTP devices – they appear as normal looking drives and folders and files in Windows Explorer but you can only really download and upload files – it doesn’t pretend to offer normal read/write operations on the files.

Ok, where do I get it?

Here!. I’m continuing to work on it – I should be able to provide thumbnails from the MTP metadata, and I’d like to implement a way to copy directories back and forth (gvfs doesn’t implement recursive push/pull for you – you have to do it yourself), but it’s otherwise very usable – it was proper plug/unplug detection and I modified the gphoto2 backend to not grab mtp devices like it used to. Eventually I’d really like to get it upstream (especially as you can’t build gvfs backends outside of the gvfs source tree) but there’s a fair way to go yet.

Enjoy!

6 1

What is πfs?

πfs is a revolutionary new file system that, instead of wasting space storing your data on your hard drive, stores your data in π! You’ll never run out of space again – π holds every file that could possibly exist, so why put your files anywhere else?! They said 100% compression was impossible? You’re looking at it!

What does π have to do with my data?

π (or pi) is one of the most important constants in mathematics and has a variety of interesting properties (which you can read about at wikipedia)

One of the properties that π is conjectured to have is that it is normal, which is to say that its digits are all distributed evenly, with the implication that it is a disjunctive sequence, meaning that all possible finite sequences of digits will be present somewhere in it. If we consider π in base 16 (hexadecimal) , it is trivial to see that if this conjecture is true, then all possible finite files must exist within π. The first record of this observation dates back to 2001.

From here, it is a small leap to see that if π contains all possible files, why are we wasting exabytes of space storing those files, when we could just look them up in π!

Every file that could possible exist?

That’s right! Every file you’ve ever created, or anyone else has created or will create! Copyright infringement? It’s just a few digits of π! They were always there!

But how do I look up my data in π?

As long as you know the index into π of your file and its length, its a simple task to extract the file using the Bailey–Borwein–Plouffe formula Similarly, you can use the formula to initially find the index of your file

Now, we all know that it can take a while to find a long sequence of digits in π, so for practical reasons, we should break the files up into smaller chunks that can be more readily found.

In this implementation, to maximise performance, we consider each individual byte of the file separately, and look it up in π.

So I’ve looked up my bytes in π, but how do I remember where they are?

Well, you’ve obviously got to write them down somewhere; you could use a piece of paper, but remember all that storage space we saved by moving our data into π? Why don’t we store our file locations there!?! Even better, the location of our files in π is metadata and as we all know metadata is becoming more and more important in everything we do. Doesn’t it feel great to have generated so much metadata? Why waste time with old fashioned data when you can just deal with metadata, and lots of it!

Yeah, but what happens if lose my file locations?

No problem, the locations are just metadata! Your files are still there, sitting in π – they’re never going away, are they?

Why is this thing so slow? It took me five minutes to store a 400 line text file!

Well, this is just an initial prototype, and don’t worry, there’s always Moore’s law!

Where do we go from here?

There’s lots of potential for the future!

• Variable run length search and lookup!
• Arithmetic Coding!
• Parallelizable lookup!
• Cloud based π lookup!
• πfs for Hadoop!

πfs: Download it today!

6 2

It’s been a few weeks since I last posted, and I’ve accumulated a couple of useful CrystalHD improvements that I think are worth talking about. First off, my comprehensive interlaced detection algorithm is now merged to the main git tree, as are the changes I’m about to talk about, so there are now no outstanding changes to merge.

Downscaling

The CrystalHD hardware is capable of downscaling, so that it will shrink the decoded frames before they are copied over to system memory. While all vaguely modern graphics hardware supports scaling, it’s still useful that the CrystalHD can do it, and that’s because it allows you to scale before the copy; smaller frames take less time and CPU to copy over. Normally, this isn’t an issue, but some videos can make the hardware grumpy such that the total time needed to decode and copy over the frame is more than the time available if you want to playback in realtime. So, being able to shrink the copy time can save you from an unplayable clip. Mind you, it’s a weird hardware/firmware bug that this is even an issue – I’ve been able to playback bluray video just fine but certain encoded files at much lower bitrates can trigger this slow decode behaviour.

To take advantage of downscaling you will also need to update your Mplayer as I had to make a change there to support FFmpeg per-codec command line options. With the latest code you can do:

mplayer -lavdopts o=crystalhd_downscale_width=[width]

to specify a width (eg: Use 1280 for 720p)

Packed b-frames

I mentioned this briefly in my last update, saying that the hardware has a bug where it would output certain frames twice when decoding a DivX/XviD video in an AVI file with packed b-frames. I implemented a work-around and thought that my work was done, but it turns out that there are at least two ways of indicating packed b-frames in a file, and one of them triggers the bug while the other does not. Sounds great, you might think – except that the files which don’t trigger the bug do still look like the files which do – which caused my work-around to kick in and ruin the playback.

So, I had to find another way to distinguish them. To achieve that, I ended up staring at a binary diff of two files and saw that they were using different frame types as placeholders for the packed frames. In the files that trigger the bug, they are “drop frames” and in the normal files, they are “delay frames”. Despite their names, I don’t believe a decoder is supposed to either drop or delay anything when encountering these; rather it’s supposed to replace them with the packed frame it received earlier. In other words, there’s a convention here that a decoder has to understand and respect, and it seems the CrystalHD is not completely up to speed with things.

With that difference identified, I was able to craft an additional test that lets us distinguish the two cases and now packed b-frame support is hopefully complete.

70012

While I don’t have anything meaningful to report in this area, I did spend some more time poking at the 70012, and while the existing code will likely yield something pretty close to a sane video stream, I still see discontinuities in the output, where frames mysteriously disappear, which very quickly leads to audio de-sync in Mplayer (which doesn’t understand the concept of a frame that fails to be decoded, so doesn’t know to re-sync the audio). I tried a number of different approaches, all with the same result – missing frames from files that play perfectly on the 70015. I know it’s possible to make it work, as both the gstreamer plugin and xbmc can do it; however, they are very different architectures that use separate input and output threads, which is not possible in FFmpeg. Ultimately, I’m not sure the support can really be improved, given the constraints of the FFmpeg architecture. Such is life.

Update: Reimar rightly points out that Mplayer can understand frames that fail to decode; I failed to remember the problem properly. What’s actually going on is that you indicate a failed frame by returning nothing; however, we only find out by obtaining the next output frame and seeing that it’s not the one we expected. At this point, returning an error would mean having to store the output frame for the next decode call and accepting that the input pipeline would increase by one frame. If that happens enough times, the pipeline will fill up completely and then we’re in real trouble. So, rather, I’m wishing I could return a frame and indicate that other frames had failed to be decoded at the same time.

2 0

In terms of features, the merged code doesn’t differ a great deal from my original announcement – there’s now support for interlaced VC1 and MPEG4 Part 2, but interlaced H.264 remains problematic. I’ve got patches in my github tree that get very close to full support, but there’s still a corner case which can cause one type of file to play back incorrectly.

I have to say, I’ve learnt far more about interlaced encoding than I ever wanted to know, working on this project. I think it’s safe to say that I’ve spent at least 70% of my time working on it, and it’s still not perfect. With progressive content, it’s simple – you have a compressed frame going in one end, and an uncompressed one coming out the other end – there’s really no ambiguity (modulo the hardware’s odd treatment of packed b-frames where it will output the packed frame twice and you have to skip one of them).

But with interlaced content, on this hardware, you have to deal with multiple variations of input and output packing; check out wikipedia if you want a quick introduction to interlacing. When compressed video is packed into a container (like AVI or matroska), it is typically split up into packets, and those packets will correspond to compressed frames or fields, and this where the fun begins. With progressive content, a packet is obviously one frame, but with interlaced content, it could be one field or two fields – sometimes the container or video format will enforce that it is one or the other, and sometimes both are valid. On the output side, the hardware, in its infinite wisdom, will sometimes output individual fields or a full frame of two fields, without much rhyme or reason. And naturally, with h.264, all four combinations are possible. That’s bad enough; to add insult to injury, the flags that the hardware is supposed to set to identify the fields/frames is bogus – meaning that it’s simply not possible to distinguish three out of the four cases until it’s too late. With a little help from FFmpeg, I was able to identify one of those three formats, but for the last two, I had to use a method that relies on peeking ahead at the next frame/field – which is great when it works, but sometimes the hardware hasn’t decoded the next frame/field sufficiently to answer the question, and then I just have to guess.

It should come as no surprise that all the other projects that support CrystalHD have punted on interlaced support

As for the future, I still need to get the improved interlaced support merged, and then I have to start looking at how to support the older 70012 hardware. This chip is very sensitive to the rate that frames are submitted to, and retrieved from, it; the code today will work enough that you should see frames most of the time, but the hardware will do odd things and drop frames or stall, so the experience isn’t good at all. I can at least take comfort from the fact that Broadcom’s gstreamer plugin and XBMC have both got it working.

Onward and upward, etc!

3 3

The hardware is particularly attractive because it’s low cost and can be added to any system, regardless of the GPU it uses. It provides MPEG1/2, H.264 and VC-1 decode capabilities in all hardware versions, and the latest 70015 part also adds MPEG4 Part 2 / DivX / XviD support – and, if you care about such things, it does so in a way that means all the infamous patent issues are handled in hardware.

Once the drivers and library were released, we started to see plenty of application support emerge, with XBMC, Xine and MythTV drivers under development early on, and a gstreamer plugin provided by Broadcom with the library. In the last couple of months, a VLC patch has been proposed. But, for all this, there was no movement on FFmpeg or Mplayer; the first being the most widely used codec library around and the later, one of the most widely used media players (and obviously a consumer of FFmpeg). I bought myself a 70012 and later a 70015 with the intention of playing around with them, but when I got some free time last month, I started working on FFmpeg and Mplayer support.

After some experimentation, I did the initial implementation as a native Mplayer decoder, which helped remove FFmpeg as a variable while I tried to get things working correctly, and after some effort, I came up with something that worked pretty well for progressive content. and partially worked for some interlaced content. In my initial discussion on the mplayer mailing list, it became clear that it needed to be an FFmpeg decoder to be maintainable for the long term. So I went back and converted it, which was relatively straight-forward as the APIs are very similar. I’ve now started getting review feedback on the FFmpeg list, and I expect it will be quite a while before it gets in, assuming it ever does, but the code is definitely usable enough to publicise more widely.

What Works

• MPlayer playback
• 70015 Hardware: This is the newest part, with extra codec support
• All the officially supported content types except DivX 3.11
• Progressive Content
• Interlaced MPEG2 and H.264 MBAFF Content

You’ll note that I said MPlayer playback works but nothing about FFmpeg even though it’s an FFmpeg decoder. The issue here is that the hardware is pipelined, so it is normal for many frames to be in flight at one time – perhaps as many as 20 under normal conditions, and over a hundred if things start going wrong… This means that the application has to have a concept of lag in the decoding process. Now, while Mplayer uses FFmpeg’s codecs, it handles frame timing and av sync in a completely different way from the actual FFmpeg transcoding application, and it happens to do it in a way that can cope with the hardware behaviour (although I had to increase the number of frames in flight that Mplayer can handle). FFmpeg on the other hand assumes that when it submits a frame for decoding, the frame it gets back is the same one. From the discussion, it sounds like I’ll need to add the same mechanism that Mplayer uses to FFmpeg. So, for now, it’s an FFmpeg decoder that doesn’t work with FFmpeg

The 70012 is the previous generation of hardware and it has some significant differences from the 70015. Beyond the reduced codec support, it has much tighter requirements with respect to keeping the pipeline happily fed, and I haven’t had a chance to investigate what this really means yet. For now, it will kind-of work, but expect something to go wrong with the pipeline and either get input overflow or output underflow pretty quickly.

Interlaced content is tricky because it can appear in many different forms, and if you look at all the other applications out there with CrystalHD support, none of them really even try to handle it. This inherent challenge is compounded by the fact that the frames don’t seem to get marked correctly when returned from the hardware, so it’s hard to tell the cases apart. I have been able to verify that MPEG2 style interlacing (where the hardware returns each field separately) and H.264 MBAFF (where the hardware returns a field pair as one frame, but with dubious flags) work correctly. H.264 PAFF should work the same as MPEG2 but I haven’t found a sample that isn’t a scary DVB broadcast stream, which introduces all sorts of other complications. There’s also a concept of interlaced content that’s marked as progressive (so you just get a field pair frame) and this should just work but I haven’t found a sample yet.

Other things of note

If you’re trying to play very high bandwidth files, make sure your I/O path is actually fast enough to move the data (so don’t expect Bluray content to work over an 802.11g link). And if your file is encoded with features that aren’t supported by the hardware, then all bets are off; the most common example of this would be an H.264 file where the encoder decided to use the highest possible settings – such as 16 b-frames on 1080p content. The CrystalHD appears to try its best to play these files but you’ll see glitches (eg: In the 16 b-frame case, it will just silently fail to resolve references to the additional b-frames)

Performance

As all codec work is done in hardware, the CPU utilization is purely based on the video resolution – almost all the time is spent copying frames back and forth. In my very unscientific tests, my old 2.2GHz Core 2 Duo laptop can play 1080p content at 25% of a core compared to 70-100% for software decoding. Also note that the X server (and window manager if you use a composited desktop) will burn measurable amounts of CPU time to display the frames. It’s supposed to be possible to do 1080p playback on a single-core Atom, but I’m not in a position the test that. Nevertheless, the benefits are clear.

Getting the code

First off, you’ll need the latest driver and userspace library from Jarod’s git tree.

Then you should grab my patched Mplayer and FFmpeg trees from github, and then construct a full Mplayer tree on disk. That means:

• mplayer/: My mplayer tree
• mplayer/ffmpeg/: My ffmpeg tree
• mplayer/ffmpeg/libswcale/: From mplayerhq
• mplayer/libdvdread4/: From svn at svn://svn.mplayerhq.hu/dvdnav/trunk/libdvdread/src
• mplayer/libdvdnav/: From svn at //svn.mplayerhq.hu/dvdnav/trunk/libdvdnav/src

Then you should be able to build Mplayer as normal. CrystalHD support should be auto-detected and will be preferred at playback to the software decoder. In theory, mencoder should also work correctly but I haven’t tried it.

Enjoy!

7 0

The NS4600 is pretty neat because it’s actually x86 compatible – it uses an Intel EP80579 SoC with a Pentium M core; it’s not a common sight (we’re drowning in high-end Atom based NASs) so the novelty is neat and being able to compile and run code easily is a plus.

The guide is here.

Enjoy!

2 10

My first decision was language, and I went with Python as I’ve wanted to use it more and I know how laborious it would be to write this kind of utility in C. I then had to dig around to find out how to write a status area plugin in Python, and luckily there is a way, and it’sfairly well documented.
The biggest source of confusion is that the get_dbus_connection method isn’t exposed in the Python bindings. So, after that took *way* too much time to work out, I had to try and achieve the same thing with direct DBus calls (get a private connection that doesn’t kill the app if it dies), which I reckon I’ve got right.

Once you’ve got the basic stuff sorted out, it becomes really easy to iterate and test – you replace the python file and move .desktop file in and out of a specific directory and Hildon will reload it. Debugging was a real pain because the phone components that I’m talking too don’t exist inside the scratchbox dev environment – so I had to play a trial and error game on the N900 itself, where my only feedback was the icon failing to appear – what fun.

The next challenge was investigating what DBus interfaces to use to find the necessary information. The most important one is com.nokia.csd.GPRS. It’s not documented anywhere, but it’s fortunately introspectable and has obviously named methods and signals, so I was able to establish when a connection is made, suspended or disconnected.

Unfortunately, you see the same set of signals whether the connection is made by the phone itself or a tethered client, so then I had to find a way to detect if the phone was using the connection. I eventually found a way by using com.nokia.icd and com.nokia.icd2 – the first is undocumented and unintrospectable while the second is actually documented. For com.nokia.icd, I was able to use dbus-monitor to find a useful status signal and the get_ipinfo() method I needed had been explored by others. So, now I can avoid false positives from phone initiated connections.

There is one problem that remains, however: It’s possible to tether through the phone at the same time that the phone is using the connection for itself – this is apparently not as amazing as it sounds; all my old phones could do it. In this case, there appears to be no way to notice the tethered connection, so the monitor will not report it. At the moment, I’ve got no good ideas for doing this cleanly – I might be able to poke sysfs or look for pnatd processes, but neither is particularly attractive. But it’s not that common a case, so I consider the program useful before this gets solved.

And what does the program actually do? It shows an icon in the status area that reflects the connection state: disabled, attached, or suspended. I actually think that showing an icon when there’s no connection is a bad use of real eastate, so I’m going to take that out of the next release, but it’s there for now and helpful for confirming that the plugin actually started.

If you’re interested, you can grab it from extras-devel.

Enjoy!

15 0

The extras-testing repository is not intended for un-adventurous users, but if you’re interested in getting my package, it’s the place to go to. In the latest version, it will correct start the service when you install the package, and shut it down when you remove it. The actual upstart script hasn’t needed to change since I fixed the dependency issue.

And on an unrelated note, there’s now a way to reliably trigger the portrait mode ‘hack’ – if you want to try out portrait mode browsing, etc. You can find that here.

16 0

I’ve now updated the script to wait until the socket appears before continuing. (And as upstart is asynchronous, only the DUN service is delayed by the wait).

Now, the mechanism I used for the wait is a crude ‘while-not-exist’ loop with a one second sleep. The dbus script does this so I felt it was morally acceptable. It’s crude and an inotifywait approach would be better but that utility isn’t installed by default. Finally, the delay should really be in the bluetoothd script so that it doesn’t signal readiness until it really is…

19 0

Perhaps, unsurprisingly, I got myself an n900 and it’s a great device; I’m using it as my primary phone and it really is impressive.

One thing that doesn’t work out of the box is DUN (Dial-Up Networking) over Bluetooth. DUN is one of the simplest ways to tether a computer to a phone, so it’s a useful feature to have. (The n900 does support DUN over USB by default). Fortunately, it’s very easy to turn on, as documented on the maemo wiki. However, if you want the feature to always be ready to go (say, after you restart your phone), you need to do a little more.

Like modern versions of Ubuntu, the n900 with Maemo 5 uses upstart to control most startup services, such as bluetooth. So, if we want the DUN service to be nicely coordinated, we should start it with upstart too. Here’s my script:


description "DUN over Bluetooth"
author "Philip Langdale"

respawn
console none

start on started bluetoothd
stop on stopping bluetoothd

pre-start script
sdptool add --channel 1 DUN
end script

exec rfcomm -S -- listen -1 1 /usr/bin/pnatd '{}'

post-stop script
sdptool del `sdptool browse local | grep Dial-Up -A 1 -m 1 | tail -n 1 | cut -d ' ' -f 3`
sleep 1
end script


So, what is this doing? As upstart is pretty new, and quite different from old style init-scripts, it’s worth explaining a bit.

The description and author fields are just for documentation. respawn means to restart if the main process exits. console none means don’t log stdout or stderr anywhere.

Now, the start on and stop on directives are the heart of Upstart. They allow you to express dependencies between services, events, and each other. In this case, we want to start the DUN server after bluetoothd is started and stop it as soon as we start stopping bluetoothd. You can express multiple start and stop conditions and the upstart site documents these.

With that done, we can move on to the functional code. From the wiki page, we see that the invocation of rfcomm is the key call. What happens here is rfcomm will wait for an incoming connectio request on channel 1 and then spawn pnatd and connect it to that channel. When the connection is complete, pnatd will exit and then rfcomm will too. Upstart either tracks a particular binary or a script. In either case, it execs the binary or script and watches the resulting process to see when it exits. So, we can conveniently transfer the rfcomm command line to an upstart exec directive.

However, there’s more to do. We have to register the service with sdpd so that clients know we offer DUN, and we have to unregister when the service is terminated. This can be done with the pre-start and post-stop blocks. This also gives us a place to enforce the one second delay suggested by the example script.

Registering the service is easy, but unregistering it is a bit of a chore. The example script can avoid it because it uses the while loop, but for upstart, the entire service is ‘inside’ the loop, so we must unregister to avoid adding an extra registration each time. The problem arises because you can only unregister by the service record ID which is selected at registration time, but not provided back to us. So, we must look for it ourselves. The long command line searches the list of services for DUN and then extracts the ID.

Now, all you have to do is drop the script into /etc/event.d/ and then execute start bluetooth-dun, assuming you name the script “bluetooth-dun”. Obviously, you must be root for both these steps.

You can download the script from here. I’ll probably package it up as a deb in due course, but I don’t have a working scratchbox environment right now.

Enjoy!

Update: It seems that it’s not perfect yet. I’ve had a report, and reproduced, it failing to start when the phone boots, even though it starts reliably if you stop/start bluetoothd. My suspicion is that there’s an additional dependency (maybe the rfcomm kernel module) that needs to be accounted for. I will investigate.

17 1

You can find my custom kernel, patches and instructions here.

10 0

You can find my custom kernel, patches and instructions here.

9 0

What does this mean? Not that much in terms of Linux kernel support for MMC; Pierre already used his copy of the 4.2 spec to fix any problems and 4.3 doesn’t really add anything new that affects us. eMMC (Embedded MMC) is mostly just a new form-factor and doesn’t appear differently from a regular card. The one substantive new feature is the introduction of a special ‘boot partition’ which are accessed in a simplified way – presumably this was added to make it easy for a bootloader to load an OS off an eMMC. I don’t really see much demand emerging for this, so we have no immediate plans to support it (and good luck finding a card with a boot partition!) but if the need arose, we’d be able to do it.

So, nothing’s changed in practical terms, but it’s still helpful for us that the spec is now freely available; however, it probably won’t do much to help MMC against the SD juggernaut. Anyone seen a high capacity MMC card despite them being ‘available’ for over two years now? Thought so.

7 0