Plug and Pray in GPS-land
<p>Welcome, ladies and gentlemen, to another darkly humorous tale of the <a href="http://esr.ibiblio.org/?p=801">seamy side of GPS interfacing</a>.  GPSD working with USB GPS mice has, when properly installed, lovely plug-and-play self-configuring behavior. That is, you plug a USB GPS into a USB port, the  hotplug system notifies the gpsd daemon that the GPS is available, the daemon records this fact&#8230;and subsequently when you start up any GPSD client application It Just Works.  Well, usually.  There&#8217;s a dangerous weakness in the machinery, and yesterday it came around and bit us in the ass.</p>
<p><span id="more-2849"></span></p>
<p>The root of the problem is a hole in the the USB standard.  For most other kinds of USB devices (printers, mice, mass storage, smart cards, hubs, what have you) there&#8217;s a defined device class code which gets presented to your USB subsystem; so, for example, your print spooler can enumerate all the USB printers attached to your system and ignore everything that isn&#8217;t a printer.   But the standard does not define a device class code for GPSes.</p>
<p>If there were a GPS device class, and GPS manufacturers followed the standard, then GPSD&#8217;s hotplug rules could simply say &#8220;hand everything with that type to GPSD&#8221; and all would be happiness.  But there&#8217;s no such class, so we have to whitelist a bunch of vendor/product IDs and assume that if the device presents one on this list, it&#8217;s a GPS.</p>
<p>In truth, we&#8217;d probably have to do this even if there were a GPS device class.   You see, all the GPS mice we&#8217;ve ever seen are are lash-ups consisting of a receiver module that&#8217;s wedded by a sort of bastardized TTL version of RS-232 with an RS-232-to-USB adapter chip. The USB device class is presented down the wire to your PC by the adapter chip, which would have to be custom-modified to show something other than its <em>own</em> device class and vendor/product ID.  These devices are produced on such thin margins that the vendors might not spend the extra pennies for the customization.</p>
<p>In point of fact, USB to serial adapters don&#8217;t have their own USB class either (they return 0xFF for &#8220;Vendor Specific&#8221;).  So we have to whitelist the vendor/product ID pairs of the USB adapter chips most commonly used in GPS mice; by far the most common of these, incidentally, is a doohickey called the Pacific Logic 2303.</p>
<p>So here we are with our udev rules file that&#8217;s watching for a plugin event from anything on the whitelist.  The udev rule calls a Python script written by yours truly which launches a gpsd instance if one is not already running, then stuffs a notification up the daemon&#8217;s special control socket that said device might be a GPS.  Later, when a GPSD client app wants location data, the daemon will actually open every device on its stash list and attempt to recognize GPS information flooding from them (not a trivial process; the GPS information could arrive in any of 13 mutually incompatible formats, which are untangled from each other by a big honkin&#8217; state machine also written by yours truly).</p>
<p>Astute readers will already see the problem.  We don&#8217;t actually have any guarantee that the thing behind any given whitelisted adapter is, in fact, a GPS.  But for six years this failure case remained theoretical.  Until yesterday.</p>
<p>Yesterday, we got a plaintive bug report from a guy who was trying to mate a cute little Linux SBC called a <a href="http://www.gumstix.com/">Gumstix</a> with a GSM modem. A perfectly reasonable thing to do if you were, say, trying to remote-control some kind of instrumentation package over a GSM cell network.  Our guy complained that every time he plugged in one of his modems,  gpsd would spam a bunch of data at it.  This sometimes gave the modem indigestion.</p>
<p>Well, guess what?  Both of the USB-to-serial adapters he tried using with his GSM modem were in our whitelist, and gpsd duly sent them the crapload of vendor-specific probe strings it uses to try to prod a GPS into returning an identifying response.  So our friend tried removing the GPSD package from the Gumstix, only to find that the KDE environment depends on it. FAIL.</p>
<p>The workaround is to uninstall GPSD&#8217;s udev rules.  But now he&#8217;s going to have to peg GPSD&#8217;s version, or his modems will fall down go boom again right after his next upgrade pulls a new GPSD package installation and installs a new copy of our udev rules.</p>
<p>This basically sucks all around.  And there&#8217;s no good fix.  And if there were one, the skeezy Pacific-Rim fly-by-nights who pump out the world&#8217;s production of GPS mice probably wouldn&#8217;t apply it.  Sigh&#8230;another wonderful day in the life of GPSD.</p>
<p>UPDATE:  The person who reported the bug says I misunderstood his use case, though apparently not in an essential way.  <a href="http://fedetft.wordpress.com/2011/01/07/linux-today-too-much-plug-and-play/">You can read his description.</a></p>
<p>UPDATE2: Ah, seems I conflated two bug reports from different people, one of which really did involve a Gumstix.</p>
