Falling through the cracks: why GPSD sometimes bogarts non-GPS devices

In a recent Google+ comment, H. Peter Anvin grumped about GPSD using “braindead heuristics” to determine which USB devices it should sniff as possible GPses when it gets a hotplug notification saying that one has connected. I was going to reply in a comment there, but the explanation ran too long for that.

Short version: yes, GPSD will very occasionally sniff at a device that is none of its business. We’re stuck in a bad place because of deficiencies in the USB standard, But it doesn’t happen often, and all the alternative behaviors I’ve been able to imagine would be worse in very obvious ways. Detailed explanation follows.

USB devices are supposed to present a “device class” number that clues in the host system what kind of thing it is and how to talk to it. In an ideal world, there would be a “GPS” device class which every GPS would present, and GPS would cheerfully ignore anything that didn’t present it, and all would be gladness and joy.

We don’t live in that world. Look at the list of USB device classes and notice that none of them is “GPS”. Lacking any defined GPS class, the standard tells vendors that GPSes have to sit in the stupid corners labelled “00h” and “FFh”. Along with every other USB devices type lacking an assigned class number, including in particular serial-to-USB adapter chips.

You may recall from some of my previous rants that your basic bog-standard USB GPS consists of a GPS chip shipping data over RTTL-vevel RS232 lines to a serial-to-USB adapter chip. And that’s the root of GPSD’s problem right there. GPSD will never mess with your mouse or your modem or your mass storage but here’s no way that a USB GPS is distinguishable from some random other device that happens to be lurking behind a serial-to-USB adapter – it’s classes 00h/FFh all the way down.

So GPSD goes to the next level and watches for the specific Vendor-ID/Product IDs of serial-to-USB adapters that usually mean aha that’s a GPS. The most common VID/PID combination is 067b:2303 which is a Prolific Logic 2303; GPSD also recognizes nearly a dozen other specific VID/PID pairs mostly corresponding to various serial-to-USB adapter chips.

And 99% of the time “that’s a GPS” is exactly what these VID/PID pairs do in fact mean; for end users, anyway. The exceptions are things like Arduino prototyping boards that will only ever be hooked up by a tiny minority of geeks like…H. Peter Anvin. Who will grumble.

This sucks in a minor way, but watcha gonna do? With this behavior. GPSD has very nice autoconfiguration in almost all cases – you plug in the GPS, hotplug wakes up the daemon, it autobauds and autoconfigures, and location data magically appears on port 2947 without the user having had to hand-tweak a blessed thing. This is good!

Unfortunately, the only way to prevent GPSD from occasionally sniffing at a device that turns out not to be a GPS would be to disable hotplug startup and require users to manually launch GPSD when they want to run it and know what their device inventory is. This would end the muttering from people like H. Peter Anvin, but at the cost of requiring hundreds of thousands of bewildered end-users to hand-lunch GPSD and remember details like device names, rather than having things Just Work.

This would not, in my view, be an acceptable tradeoff. This is one time I’m afraid I have to tell the hard core to live with the occasional glitch; greatest good for the greatest number and all that. Even adding a GPS class to the USB standard wouldn’t solve the problem at this point – too many GPSes already fielded, and many of the vendors are such sketchy low-margin operations that it’s not clear they’d add the production step to do the right thing even if it were available.