Mike Hewner's Homepage

This is a problem I don’t think I ever would have solved if not for a combination of caffeine and tattoo pain that kept me up all night. Context: I have a nice new external usb hard drive I decided to use for backups. It worked great with Ubuntu right up until the time that I realized that I was never going to be able to use the truly slick rsnapshot unless I was backing up to a drive that was something fancier than VFAT. So I partitioned it and formatted it ext3 and even gave it a volume label and then ubuntu stopped mounting it automagically when I plugged it in.

Why was ubuntu not mounting my ext3 usb external drive?

The first thing I did was add a line to /etc/fstab

LABEL=bookbak /media/bookbak ext3 defaults,user,auto 0 0

Now when I typed “mount /media/bookbak” or “mount -a” it worked like a charm. Also dmesg looked great when I plugged in the device. But it still wouldn’t mount it when I plugged it in. Hmmm…so I went online and found a million unhelpful forum entries. And one helpful one, which explained (and I paraphrase here) that there’s a whole load of funky crap going on with automatic mounting but that the thing that finally really does the mounting is a program called “gnome-volume-manager”. And then I discovered if you do something like this:

killall gnome-volume-manager
gnome-volume-manager -n

You can see what happens when your device gets plugged in. And from that I discovered an error message to the effect of “volume.ignore set to true”. And then, using another helpful blog post I can no longer find I looked here /usr/share/hal/fdi/policy/10osvendor/20-storage-methods.fdi and saw this:

<!– Ignore fixed partitions which are automatically mounted from fstab, –>
<!– but are not mounted; users should not mess with this situation –>
<match key=”linux.fstab.mountpoint” exists=”true”>
<match key=”volume.is_mounted” bool=”false”>
<merge key=”volume.ignore” type=”bool”>false</merge>
<match key=”linux.fstab.options” contains=”defaults”>
<merge key=”volume.ignore” type=”bool”>true</merge>
</match>
<match key=”linux.fstab.options” contains=”auto”>
<merge key=”volume.ignore” type=”bool”>true</merge>
</match>
</match>
<match key=”linux.fstab.options” contains=”noauto”>
<merge key=”volume.ignore” type=”bool”>false</merge>
</match>
</match>

And that gave me the inspiration to change my fstab entry to this:

LABEL=bookbak /media/bookbak ext3 defaults,user,noauto 0 0

And that worked. So yes, turns out if you want your external usb hard disks to be mounted automatically, you have to set noauto. I imagine this makes complete sense, auto no doubt referring to drives that are supposed to be mounted at boot time etc. Anyways, somewhat uninitive on the surface.

So I just finished my GRE a few hours ago. This officially means an end to learning silly words from flashcards and doing practice exams – hopefully for my whole damn life. In theory, it also means I should be able to get back to working on the RubyUSB and other projects, although I will be doing some more college-app specific work as well.

I’m happy with my scores in Quantative and Verbal (though I did better in Quantative – guess this means I haven’t been reading enough fantasy novels lately). Writing – who knows? I’ll find out in a few weeks.

Josh suggested that my introductary page could use a little beefing up, and I agree. So there’s a new introduction with an extended example plus descriptions of each of the classes and how they fit together.

Yay documentation! I documented most of the methods is libusb but I’m not sure it really makes anything that much clearer if you don’t already have a fairly good understanding of the USB device specification. Anyways, take a look around and tell me what you think!

http://www.technofetish.net/repos/buffaloplay/ruby_libusb/doc/

As you might have guessed it would, my peculiar madness had me wandering ValueVillage this Saturday. I was looking for cheap USB keyboards to hack together into my ultimate VI keyboard. The keyboards were a lost cause as it turns out…only PS/2 stuff there…but I did discover something: the Toshiba LED Control Module PMD-C0188. It’s this chuky plastic box with two rows of buttons and a volume knob. If I had to guess I would say that it’s likely built to control some sort of fancy telephony app – but this is a guess.

Anyways, I took it home with me ($5) on the theory that it problably was a USB HID device that I could reprogram to control my little TV watching computer.

Altogther too long later, it finally works. Reverse engineering the button’s protocol turned out to be pretty easy (here’s the app that did it). That was the easy part. The annoying part was getting it to control VLC properly, and then getting it installed on my other box. For the most part, not problems you would be interested in.

Anyways, it works now and I’m going to watch a little anime in celebration. Here’s the code that did it.

Ever since I read the Raskin’s The Humane Interface, I’ve been especially noticing what Raskin calls “mode errors” in VI. Mode errors happen when you have two different modes of operation and you accidently do a Mode A command in Mode B.

Raskin really hates this kind of error, partly because they interfere with the feedback that you need to become skilled. Every key combination needs to have a implict but because sometimes that involves doing something and sometimes it dosen’t, it’s difficult to train your fingers to do it automatically.

I can hear you VI users scoffing at me. I dunno if Raskin’s right about this, but every UI mode problem can be solved most ridiculously by adding more buttons…right?

So partly as a joke, partly to write a more interesting example of my USB library, and partly to see what it would be like, I’ve built a ruby script that let’s you use a USB be keyboard as “VI inserting keyboard”. Every text key presed in this keybord maps to “a[KEY][ESC][ESC]“. So if you use this keyboard in VI command mode you can enter whatever you want but stay in command mode. It strikes me that it might be saner to do the opposite – have an external keyboard permanently in command mode – perhaps that can be version 2.

Anyways, this works beautifuly and it only took me a couple of hours (mostly involved with finding the appropiate way to simulate X keys and map USB usages to X keysyms). Just figured you might be amused:

http://www.technofetish.net/repos/buffaloplay/vikeyboard/

If I’m really feeling motivated maybe I’ll glue two keyboards together tomorrow and try it out properly.

So I haven’t been slacking off, even though things have been pretty quiet on the blog lately. What I’ve been doing is integrating both my HIDParser and libusb into ruby. This isn’t so much of a straight port like my evdev stuff…I’ve worked really hard to build interfaces hid most of the unecessary complexity from you but inferring everything from the USB descriptors. So for example here’s an application that listens for “F” presses on any appropiate USB keyboard:

require ‘libusb’

hid_device = USB::devices.select { |d| d.hid? }[0]
hid_interface = hid_device.interfaces { |i| i.hid? }[0]
hid_interface.detach_kernel
listener = USB::UsageListener.new(hid_interface)
usage = USB::Usage.find_usage_named(/Keyboard f/)
puts “listening for usage #{usage}”
listener.on_usage_value_change(usage) { |new_val| puts “New value: #{new_val}” }
listener.start_listening

Pretty simple, eh? In this case the application assumes that the first hid device on your system is capable of producing an F keypress (a slightly more complex example could check first).

Anyways, there’s a lot more that needs to be done in terms of fleshing out the interface – exposing greater amounts of the C/C++ layer and (perhaps) supporting a greater variety of USB transport mechanisms. But still, I’m pretty pleased with how simple the main case was able to get.

All the code is in my source control if you want to play around with it or look at it (the example is map_example). No documentation yet, but if that’s what’s holding people back I could be convinced to write it.

In theory it should be compatable with BSD and MacOS X though that has certianly never been tested. If you try it and you have trouble building or running the app, let me know I’m happy to help you figure it out.

The annoyance of proprietary formats. I hacked the data files include with the HIDDescriptorTool too produce one big json file that I could use for usage/usage page mappings.

Incidently, this is your opportunity to discover all the bizarre stuff specified in the USB spec. Did you know you can have a “Chaff Release” button? That way, anytime you need to release some chaff, in any program, you can do it in a generic way.

I know what you’re thinking: why don’t I have a chaff release button on *my* keyboard? Well I can show you how to make one.

http://www.technofetish.net/repos/buffaloplay/upg/usages.json

So I have a more-or-less working USB HID parser. It took a good bit longer than I thought it would and it didn’t come out as well as I thought it would. I might write some blog posts about that. But still, it’s not too embarrasing:

http://technofetish.net/repos/buffaloplay/HIDParser/

Notice the fancy unit tests and whatnot.

I also built one test application – hid_report_dumper. You give it a product_id and vendor_id (observable in /proc/bus/usb) for a USB HID device on your system and it will print out some interesting details about the format of its data reports. It’s not at this point stuff that a layperson might fight useful but it is interesting (and I can help you intepret if you’re curious). If you actually want to compile and run this you’ll need libhid installed on your system.

Assuming all goes well, you can make it with “make dumper” and run it like this “sudo ./hid_report_dumper 0×0637 0×3″. Bear in mind that it will disconnect whatever device you pick from the kernel’s HID driver so that device will stop working.

Ok geeklings, I could use a little advice. I’m looking at using/modifing libhid: a small but not inconsequential library. One of the primary things this library does is parse the HID report, which is a small but not inconsequential language that describes human interface devices and their data. The problem: this parsing is rather crude right now, so that doing something that should be pretty simple (say, “what is the current state of this HID device”) is pretty hard in the general case. Worse, the library’s design is itself rather nasty – or at least, it’s not what I want, which is some nicely factored data structures & functions that describe all characteristics of the HID device in a Object-Oriented way that’s easy to query. Basically, I want a parse tree of the HID report.

So I could rewrite the C library, but generating this parse tree without the facilities of an OO language is going to be ugly (or maybe that’s just because I’m not familiar with C-style). At the very least, rolling my own C data structures (like lists, and perhaps maps) is gonna be an annoyance. Also problematic will be memory allocation/deallocation (this is where C++ constructors/destructors really come in handy). Also virtual functions will be missed for querying aggregate data on the parse tree once it’s built.

Possible solutions:

1. Try to use the library as it is (perhaps with a few crude extensions) and then glom a fancy OO interface layer in something like ruby that hides the ugliness. Pros: easy Cons: might not be able to keep some of the ugliness from poking through, other users of the C are still screwed
2. Rewrite the parsing in C++ using the STL. Pros: Not that hard. Also a nice clean C++ interface. Cons: This is currently a C library and I’m not sure if the maintainers would appreciate C++. Increased binary size with the STL. Increased difficultly iterfacing with other langauges using swig (but not impossible).
3. Rewrite the parsing in the cleanest possible C. Possibly using a C data structure library that somebody could point me to. Pros: small binary size, good C interface. Cons: Possibly hard, especially if I have to use my own data structures. Not as clean as the C++ interface (especially if somebody like me, still thinking C++-style, writes it)

What would you do?