summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--Makefile.am2
-rwxr-xr-xgpsd.hotplug9
-rw-r--r--gpsd.rules4
-rw-r--r--www/hacking.html81
4 files changed, 89 insertions, 7 deletions
diff --git a/Makefile.am b/Makefile.am
index 53b11704..b7ad6a51 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -916,7 +916,7 @@ udev-uninstall:
rm -f /lib/udev/rules.d/25-gpsd.rules
udev-test:
- $(srcdir)/gpsd -N -F /var/run/gpsd.sock -D 5
+ $(srcdir)/gpsd -N -n -F /var/run/gpsd.sock -D 5
# Release machinery begins here
#
diff --git a/gpsd.hotplug b/gpsd.hotplug
index afa74f24..805f9419 100755
--- a/gpsd.hotplug
+++ b/gpsd.hotplug
@@ -14,7 +14,7 @@ GPSD_OPTIONS = os.getenv('GPSD_OPTIONS') or ""
WHEREAMI = __file__
-def gpsd_control_connect():
+def gpsd_control_connect(complain=True):
"Acquire a connection to the GPSD control socket."
if not os.path.exists(CONTROL_SOCKET):
syslog.syslog("socket %s doesn't exist" % CONTROL_SOCKET)
@@ -23,7 +23,8 @@ def gpsd_control_connect():
sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM, 0)
sock.connect(CONTROL_SOCKET)
except socket.error, msg:
- syslog.syslog("socket %s creation failure: %s" % (CONTROL_SOCKET, msg))
+ if complain:
+ syslog.syslog("socket %s creation failure: %s" % (CONTROL_SOCKET, msg))
if sock:
sock.close()
sock = None
@@ -34,14 +35,14 @@ def gpsd_control_connect():
def gpsd_control(action, argument):
"Pass a command to gpsd; start the daemon if not already running."
syslog.syslog("gpsd_control(action=%s, arg=%s)" % (action, argument))
- connect = gpsd_control_connect()
+ connect = gpsd_control_connect(complain=False)
if connect:
syslog.syslog("reached a running gpsd")
elif action == 'add':
gpsdcmd = "gpsd %s -F %s" % (GPSD_OPTIONS, CONTROL_SOCKET)
syslog.syslog("launching %s" % gpsdcmd)
os.system(gpsdcmd)
- connect = gpsd_control_connect()
+ connect = gpsd_control_connect(complain=True)
if not connect:
syslog.syslog("can't reach gpsd")
return None
diff --git a/gpsd.rules b/gpsd.rules
index de0b66e8..bf06cd32 100644
--- a/gpsd.rules
+++ b/gpsd.rules
@@ -10,8 +10,8 @@
# that it should look at the device that just went active, because it
# might be a GPS.
#
-# The following setup works on Debian - something similar will apply on
-# other distributions:
+# The following setup works on Debian and Ubuntu - something similar
+# will apply on other distributions:
#
# /lib/udev/rules.d/25-gpsd.rules
# /lib/udev/gpsd.hotplug.wrapper
diff --git a/www/hacking.html b/www/hacking.html
index e0047c28..bf54f222 100644
--- a/www/hacking.html
+++ b/www/hacking.html
@@ -88,6 +88,8 @@ file in the source distribution.</p>
<li><a href="#debugging">Debugging</a></li>
<li><a href="#profiling">Profiling</a></li>
<li><a href="#porting">Porting to weird machines: endianness, width, and signedness issues.</a></li>
+<li><a href="#udev">The moving target that is udev.</a></li>
+
<li><a href="#architecture">Architecture and how to hack it</a></li>
<li><a href="#autoconfiguration">Autoconfiguration</a></li>
<li><a href="#error">Error modeling</a></li>
@@ -563,6 +565,85 @@ typedefs.</p>
<p>(No, we don't know why splint doesn't handle these natively.)</p>
+<h2 id="udev">The moving target that is udev.</h2>
+
+<p>The Linux udev system has been prone to change out from under us,
+breaking our hotplug support for USB receivers. Accordongly, here's a
+short guide to verifying that the different pieces are working
+correctly, with indications of where to troubleshoot on failure.<p>
+
+<p>First, verify that your USB subsystem can see your receiver. Run
+lsusb(1). Plug the receiver in and run lsusb(1) again, looking for
+the extra line - it will be identified by a serial-to-USB converter
+chip type such as a PL2303. Unplug the receiver and verify that
+the line describing the device is gone.</p>
+
+<p>If this test fails, something very basic is wrong at hardware
+level. If your receiver has a two-section cable joined by something
+like a <a href="http://en.wikipedia.org/wiki/Mini-DIN_connector#6-pin">6-pin
+mini-DIN connector</a>, with a component housing between that and the
+USB plug, be aware that the serial converter may live in that housing
+and you have to unplug the <b>entire cable</b> from your computer, not
+just separate the halves of the mini-DIN connector. If there os no
+such joint, it may be that your receiver is defective or dead. The
+leatt likely failure is for the USB hardware on the PC side to be
+buggy.</p>
+
+<p>Next thing to try is watching the hotplug events in your system logs.
+Do <code>tail -f /var/log/syslog</code>; plug in and unplug the receiver.
+You should see messages indicating from the USB subsystem in the kernel
+indicating device connect and disconnect. If you don't, check your
+kernel configuration; USB support may be absent or misconfigured.</p>
+
+<p>Now we involve the udev system. Unplug the receiver. Run
+<code>make udev-install</code> from the source directory to install
+the required udev rules. (There is a <code>make udev-uninstall</code>
+for cleaning up after this test.) Do <code>tail -f
+/var/log/syslog</code> if you have not. Now plug in the receiver.</p>
+
+<p>You should see messages that include something like the following
+text (the USB device may vary):</p>
+
+<pre><code>
+gpsd.hotplug: gpsd_control(action=add, arg=/dev/ttyUSB0)
+gpsd.hotplug: launching gpsd -F /var/run/gpsd.sock
+</code></pre>
+
+<p>These are from the gpsd.hotplug handler called by udev on a hotplug
+event matching one of the known udev types for a USB GPS, and indicating
+the launch of a gpsd instance.</p>
+
+<p>If you don't see this, several things could be going wrong. The
+udev rules may not be installed correctly. Or the handler they call
+may be unable to run for some reason; it has two layers, a shellscript
+wrapper around a little Python program that does the real work. You
+may have to figure out where the udev log messages go on your system
+an use udevadm(8) to crank up the log level until you can see what's
+going on.</p>
+
+<p>If your GPS uses an unusual serial-to-USB converter, the GPSD rules
+may not recognize it as a probable GPS. You'll need to look at the
+converter type indicated in the lsusb(1) listing and match it against
+the rules in the gpsd.rules file. If it's not known, please report
+this as a bug to the GPSD developers.</p>
+
+<p>Once you know that udev can launch gpsd, you'll want to watch what
+it's doing with the hotplug notifications. Unplug the receiver and kill
+the running gpsd instance, if there is one. Now run <code>make
+udev-test</code> and plug in the receiver.</p>
+
+<p>You should see log messages from gpsd indicating that the control
+socket has received a command to add the device, and then data
+from the device. When you unplug and replug the device, gpsd
+should emit messages about the device closes and opens.</p>
+
+<p>If you don't see this, there's a bug or misconfiguration
+somewhere. Check to make sure the hotplug handler and gpsd have
+matching expectations about the location of the control socket.</p>
+
+<p>If you do see these device file opens and closes logged, the
+udev end of the configuration is working.</p>
+
<h2 id="architecture">Architecture and how to hack it</h2>
<p>There are two useful ways to think about the GPSD architecture.