| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In compiler.h, it adds the missing "std::" namespace prefixes to the
memory_barrier() definition.
In gpsd.h it:
1) Moves the include of compiler.h outside the conditional 'extern
"C"', since the "atomic" stuff in the former is incompatible with the
latter.
2) Fixes DEVICEHOOKPATH for C++11 (C++11 requires spaces between
literals and string macros).
3) Cleans up some ordering of system includes left over from the
former head/tail setup.
TESTED:
Ran "scons build-all check" on OSX 10.5-10.12, Ubuntu 14, CentOS 7,
Fedora 25, FreeBSD 10.3, OpenBSD 5.6 (32- and 64-bit), and NetBSD
6.1.5. Also tested Qt builds with OSX 10.9 (Qt4 and Qt5), OSX 10.12
(Qt5), and Fedora 25 (Qt5).
Observed the correct DEVICEHOOKPATH in the log on OSX.
|
| |
|
|
|
|
|
|
|
|
|
| |
The reason for directly including the contents of gpsd_config.h in
gpsd.h is long gone, so there's no longer any reason to create the
latter by concatenation rather than just making it a normal header
which #includes gpsd_config.h. This is a minimal rework of this form.
TESTED:
Ran "scons build-all check" on OSX 10.9 and Fedora 25 (without Qt in
the latter case, where the Qt build needs further work).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This defines a new function os_daemon() (in os_compat.c), which is
either the old replacement daemon() renamed, or a wrapper around the
actual daemon() call. This allows any issues related to daemon()
(which exist on some platforms) to be dealt with in one place. No
such changes are present yet, so platforms giving warnings for the use
of daemon() continue to do so, but now only in the compilation of
os_compat.c. Unfortunately, the current build procedure typically
compiles os_compat.c multiple times, so the warnings still appear
multiple times.
TESTED:
Ran "scons build-all check" on OSX 10.9, OSX 10.12, Ubuntu 14, and
FreeBSD 10.3.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This creates a header for os_compat.c, and moves the related
prototypes into it from gpsd_config.h (as created by SConstruct),
after adding references to it to gpsd.h (via gpsd.h-tail) and a few
other sources that need it but don't include gpsd.h.
It also removes includes of <time.h> in the places where they were
only needed for the code now removed from gpsd_config.h.
TESTED:
Ran "scons build-all check" on OSX 10.9 (with strlcat/strlcpy but no
clock_gettime), OSX 10.12 (with strlcat/strlcpy and clock_gettime),
and Ubuntu 14 (with clock_gettime but no strlcat/strlcpy). Also
verified that fallback versions were not being included where
unnecessary.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This rearranges the order of some conditionals and includes, in order
to avoid some gratuitous includes where unnecessary.
Due to the fact that some actual definitions for the clock_gettime
fallback are embedded directly in gpsd_config.h, it's necessary to
include <time.h> prior to including it. This will be fixed once the
relevant definitions are moved to the upcoming os_compat.h.
This also replaces the "UNUSED" in clock_gettime with a void cast,
eliminating the need for compiler.h.
TESTED:
Ran "scons build-all check" on OSX 10.9, OSX 10.12 (which has real
clock_gettime) and Ubuntu 14. Also verified that the clock_gettime
fallback is present in OSX 10.9, but absent in OSX 10.12 and in Ubuntu
14.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change:
1) Makes a few comment-only edits to os_compat.c.
2) Updates the build procedure to use os_compat.c in libgps and
in the Python extensions.
3) Deletes the now-obsolete clock_gettime.c, daemon.c, and strl.c.
TESTED:
Ran "scons build-all check" on OSX 10.9 and Ubuntu 14.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This file combines the code from clock_gettime.c, daemon.c, and strl.c
into a single "OS compatibility" module. This initial version is just
a verbatim concatenation of those three sources, which is not yet
used. Editing it for initial use is left to a separate commit for
easier tracking of the edits.
Since there's no "git cat" operation, the history of the code in this
file is not directly available in relation to this file, but can be
found in the histories of its three component sources (even after
their upcoming deletions).
TESTED:
Inapplicable.
|
| | |
|
| |
|
|
| |
Actually build something.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This value is only provided as a convenience, and has no internal
function at all. It was never updated to reflect the two increases in
gps.h. The new value would be excessive for xgps, but that no longer
uses this definition.
TESTED:
No point.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current MAXCHANNELS value in xgps, obtained from gps.py, has been
observed to be inadequate. The value in gps.py is an outdated value
that was never updated when the C value was changed, but using the new
value of 72 in xgps would result in a huge window. This change
defines a local MAXCHANNELS in xgps, which does not need to match the
value in gps.py. It's currently set to 28, based on having observed a
case with 25 visible satellites. It would be better to make it
dynamic, but that would require reworking some of the Gtk setup code.
TESTED:
Ran against a receiver reporting 25 visible satellites, seeing all
satellites reported and no console error messages.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until recently, PPS_ENABLE was always true by default, even on
platforms where it was intended to be forced off. Fixing this exposed
some issues in gpsmon. This generally related to confusion between
*displaying* PPS info versus *capturing* it. Since gpsmon can be run
against a remote target, it should be able to report PPS info even
when running on a host that doesn't support PPS, but the code was
conflating the two issues.
The changes here are:
1) There is now a PPS_DISPLAY_ENABLE, which is always true, and should
be used in place of PPS_ENABLE in code related to displaying PPS info,
to the extent possible.
2) The code related to processing remote TOFF and PPS events now uses
this new conditional. Aside from restoring the presence of the "PPS
offset" lines in the scrolling data, this also fixes a problem where
the display malfunctioned when this code was absent. The exact nature
of this dependency hasn't yet been determined, but there's a FIXME to
document the issue.
3) The reporting of PPS offsets in the windowed area still doesn't
work without PPS_ENABLE, due to the entanglement between that code and
the pps_thread code. There are now a couple of FIXMEs related to that
issue, which is being left for future work.
4) A couple of unnecessary PPS_ENABLE conditionals were eliminated by
making use of the existing conditionally-defined lock/unlock
functions.
TESTED:
Ran gpsmon on OSX 10.9 (where PPS_ENABLE is off) against three
receivers (one local and two remote), with the expected results. Also
ran it on Ubuntu 14 (where PPS_ENABLE is on) against the same three
receivers (again one local and two remote), again with the expected
results.
|
| | |
|
| |
|
|
| |
Strangely, this changed no regressions....
|
| |
|
|
| |
regressions updated. Other rdivers prolly need similar fixes.
|
| |
|
|
|
| |
Gotta clear the computed DOPs so that fill_dop() will recompute
them. I suspect this is the tipo of the iceberg.
|
| |
|
|
|
|
|
| |
Any DOP not provided from the GPS must be reset so that the
next SATELLITE_SET will recompute it. This problem is not
only on SiRF and not only on TDOP. But I do not have the proper
fixes yet.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The clock_gettime() fallback code was using clock_get_time() on OSX,
presumably in order to get its apparent nanosecond resolution. But it
turns out that clock_get_time() only has microsecond resolution, in
spite of the nanosecond-resolution data format. This makes it no
better than gettimeofday() in practice. In addition, it's
substantially slower. The clock_get_time() version as typically
implemented (including here) takes about 3us on a 3GHz Mac Pro, as
compared to about 43ns for gettimeofday(). Even if the code is
improved by cacheing the clock port rather than obtaining it once per
call, it still takes over 800us. Thus, using gettimeofday() and
scaling the microseconds to nanoseconds is actually the best approach.
Since there was already a fallback based on gettimeofday() for other
clock_gettime()-impaired platforms, this fix simply removes the
OSX-specific version and the related conditional.
It's worth noting that the official OSX clock_gettime(), which
appeared on 10.12 (Sierra), still has only microsecond resolution, and
comparable speed to gettimeofday().
The gettimeofday()-based fallback included some "paranoid" code
checking for out-of-range microsecond values. But in addition to its
being questionable to check the direct return results of system calls,
the "paranoid" checks were *after* the tv_usec value had already been
used. Hence, that code never could have had any effect, and would
have been optimized out by a clever compiler. It's now been removed.
TESTED:
Ran "scons build-all check" on OSX 10.5, 10.9, and 10.12, as well as
Ubuntu 14.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The commonly circulated code for nanosecond-resolution time of day in
OSX has a bug. The port obtained by mach_host_self() is a resource
which needs to be freed after use. This issue has been observed in
connection with a different Mach port use in:
https://codereview.chromium.org/279293002/
It's not known how long one has to run gpsd in order to run afoul of
this bug, or whether it has been observed in practice, but fixing it
proactively is wise. Note that this code disappears in macOS >=10.12,
once native clock_gettime finally appeared.
Also note that the host port is only needed to *obtain* the clock
port, not to *use* the clock port, so it can be freed prior to
actually reading the clock.
TESTED:
Ran "scons build-all check" on OSX 10.5-10.12.
Ran gpsd for a few hours on OSX 10.9.5 (with one receiver).
|
| |
|
|
|
|
|
|
|
|
| |
Temporarily reinstating the CheckFunc hack, pending further
investigation.
TESTED:
Verified that the only differences in SConstruct across the
revert/unrevert are the minor intervening changes. Ran "build-all
check" on OSX.
|
| | |
|
| |
|
|
| |
Otherwise we get mysterious failures on Raspberry Pis.
|
| |
|
|
|
|
| |
The broken tests are the ones where we have to do our own conversion from
week/second to UTC because the device either doesn't supply UTC or its
reporting is broken.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This changes the default value of the target_python option to
'python', i.e. the system default Python. The former blank default
based the selection on the SCons Python, which is guaranteed not to be
the system default Python if the latter is any Python 3.
TESTED:
Running xgps now works when the default Python is Python 3, without
explicitly specifying target_python.
|
| |
|
|
|
|
|
|
|
| |
In general, tabs are a bad idea in Python, and Python is getting
pickier about mixing tabs and spaces. This instance caused Python 3.6
to barf.
TESTED:
Now works with Python 3.6.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Although poll() is generally preferred to select() in C code, in
Python, select.poll is considered OS-dependent, and is missing in some
Python versions, notably in some OSX cases. Since gpscat is not a
performance-critical application, simply using the older but more
portable select.select is preferable to some fancier scheme using
different methods on different OSes.
TESTED:
Ran gpscat on OSX with all supported Python versions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An unadorned 64-bit literal provokes a width warning on 32-bit
platforms. Depending on whether the compiler promotes such literals
to a 64-bit type, this case could represent an actual malfunction.
The fix is simply to use the "LL" suffix (actually "ULL" in these
cases).
This also switches to ~0 as the all-ones mask, for better readability.
It also changes a nearby "1LL" to "1ULL" for consistency with its
unsigned context.
TESTED:
Ran "scons build-all check" on four versions of OSX, two versions of
Linux, and FreeBSD, OpenBSD, and NetBSD, with two cases being 32-bit.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Although the exact nature of the original problem is neither
fully understood nor easily reproducible, the change that
moved the warning setup toward the end of the Configure section
makes the "CheckFunc for strict prototypes" hack almost certainly
unnecessary.
TESTED:
Ran "scons build-all check" on four versions of OSX and two versions
of Linux, as well as FreeBSD, OpenBSD, and NetBSD.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Given that the data returned bye fake.py may include binary data,
'bytes' is a more appropriate type. Unlike the client API, where it's
easy to provide both return types, it would be less convenient to do
that here, so 'bytes' is preferred as the one choice (and is
consistent with network sockets).
When sending such data to stdout (or stderr), the straightforward
method is to write to sys.stdXXX.buffer rather than sys.stdXXX. That
doesn't exist in Python 2, but a helper function is now provided to
get the appropriate 'bytes' stream for stdXXX.
Since no previous *release* of GPSD is compatible with Python 3,
changing this now doesn't break anything based on released code.
TESTED:
Ran "scons check" on OSX with all supported Python versions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Python 2, 'bytes' and 'str' are synonyms, but in Python 3 they are
not. Since the client may return binary data in some cases, 'bytes'
is a more appropriate data type. Rather than requiring double
conversions in this case (the socket returns 'bytes'), this adds an
alternative response item which is typed as 'bytes'.
Although the accessor method 'data()' has always existed, it's
shadowed by a name collision in some cases, resulting in the
requirement that the caller access the 'response' item directly (as
noted in the documentation). Thus, it's not possible to avoid the
conversion to 'str' in the cases where it isn't actually used.
This change doesn't bother to add an accessor method for 'bresponse',
for consistency with the way the API is normally used, though that
should be fixed if this aspect of the API is ever cleaned up.
TESTED:
Ran "scons check" on OSX with all supported versions of Python.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MAGIC_HAT code was always pointless without KPPS support, but the
recent change to skip the "fake PPS" device caused it to reference a
function which is not defined without KPPS support. The fix is to
disable MAGIC_HAT altogether in this case.
Doing this required moving the PPS-related configure checks earlier,
so that the magic_hat option can be turned off before it gets exported
to the config file.
TESTED:
Built (on Ubuntu) both with and without sys/timepps.h, and verified
correct setup in gpsd_config.h, as well as successful builds. Also
ran "scons check" for good measure (in both cases).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) This excludes satellites with zero azimuth and elevation from the
skyview display. This is mainly for receivers (e.g. Navika-100) which
fail to report az/el for SBAS satellites, avoiding displaying them
erroneously at the top. There was already a filtering condition to
exclude satellites with az, el, and SNR all 0; this simply removes the
SNR portion of the condition.
2) The default skyview orientation is now the downward-facing "map
view". In spite of the name, GPS skyviews pretty much always use this
orientation rather than the upward-facing view suggested by the name
(the former snarky comment on the parameter notwithstanding).
TESTED:
Viewed the page simultaneously with xgps with "bad" SBAS entries
present, and verified consistent behavior.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the Linux kernel is built with CONFIG_PPS_CLIENT_KTIMER=y, then a
synthetic PPS source is added to allow testing without a real PPS
source. However, this source doesn't even run at exactly 1Hz, so any
attempt to use it for real time synchronization is disastrous.
To make matters worse, this is usually the first PPS driver
configured, causing it to appear as /dev/pps0, which is the implied
PPS device used by the "Magic HAT" kludge.
This change adds detection for the fake source (based on its name),
both to provide a warning if it is configured explicitly, and to skip
over it when applying the "Magic HAT" kludge.
TESTED:
Tested both gpsmon and gpsd on a Beaglebone Black with added symlinks
for testing "Magic HAT". Did this with kernels with and without the
KTIMER enabled. Verified that the proper PPS device is selected by
"Magic HAT", and that a warning is generated when expected.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a build option called 'magic_hat', and makes the code for
MAGIC_HAT_GPS and MAGIC_LINK_GPS conditional on it. It currently
defaults to True on Linux and False otherwise. It's meaningless on
non-Linux platforms, though at present there are no
conditionally-present options, so this one is also present on all
platforms.
TESTED:
Tested on a Beaglebone Black with suitable symlinks added (and running
a kernel with PPS_CLIENT_KTIMER turned off. Verified that the kludge
behaves as intended when enabled, and is inoperative when disabled.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This bug was intended to be fixed by commit 074499e16. The problem is
that the total satellite count in xxGSV sentences is per-talker rather
than global, but the sanity check only has the global total available
for comparison. The original change attempted to fix this by
suppressing the check whenever non-GPS talkers are detected (in the
current cycle), on the assumption that GPGSV blocks always come first.
Thus, the GPGSV total would be checked, but not the others. However,
the sense of the conditional was inverted, disabling the check for
GPGSV while causing it to produce bogus warnings in most multi-GNSS
cases. This change corrects that.
The proper fix for this would be to implement per-talker satellite
totals. There's now a FIXME to that effect.
TESTED:
All regression tests pass, and running gpsmon against a GPS/GLONASS
receiver no longer produces spurious warnings (when enabled).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Although the LIBPATH override removal wasn't bad per se, it
exacerbated a bug where the standard LIBPATH setup was being bypassed
in the "cleaning or helping" cases, causing many targets to mismatch
for cleanup. That was missed due to not including a "cleanup test" in
the testing. The fix is simply to move the LIBPATH setup out of the
conditional area.
TESTED:
Ran scons "build-all check" followed by "scons -c" and then "git clean
-dxf", and verified that now only the usual scons-internal files
remain after cleanup.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 6e1d6bd6 added "LIBPATH='.'" overrides to most build setups,
though the purpose was unclear. The SConstruct script already sets up
LIBPATH to include the current directory, as well as the sysroot
directory when that option is being used. It also includes the
directory for the dbus library when applicable, though that is also
passed via the dbusflags variable where needed.
That change used to break dbus linking on non-Linux platforms. It no
longer does so after fixing the dbusflags setup, but cross-linking may
still be broken by the sysroot removal. In any case, it seems rather
pointless to both set up and then discard a proper LIBPATH value.
It's also worth noting that commit 6e1d6bd6 also switched from dynamic
linking to static linking, eliminating any long-term effect of the
LIBPATH choice. The LIBPATH overrides may have been an unsuccessful
attempt to make dynamic linking work without chrpath.
TESTED:
Tested builds and ran regression tests on all OSX versions from 10.5
through 10.12, as well as Ubuntu 14.04.1, CentOS 7, FreeBSD 10.3,
OpenBSD 5.6, and NetBSD 6.1.5.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change defers the conditional enabling of various compiler
warnings until after various other Configure checks are performed,
for a couple of reasons:
1) It reduces the noise in config.log, by not having warnings
come from the more substantive Configure checks.
2) It *may* avoid the CheckFunc problem with -Wstrict_prototypes
without having to rewrite it, though that hasn't been confirmed.
TESTED:
Ran "scons build-all check" with this change successfully. Also
compared before and after versions of config.log, seeing expected
improvements and nothing unreasonable.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes a couple of minor improvements to the xgps[speed] UIs:
1) If a target (host/port/device) is specified, it is included in the
window title. This is especially useful when running multiple
instances pointing at different targets.
2) Interprets blank host and/or port fields in host:port:device
notation as the default values. This allows, e.g., specifying a
device without having to explicitly specify the default host/port.
Also replaces all hardcoded '2947' instances with gps.GPSD_PORT.
TESTED:
Tried various arguments, including using the option forms in
xgpsspeed. Also tried a long string of leading zeroes on the port
number to verify that a ridiculously long target string is taken in
stride.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The two flags -Wmissing-prototypes and -Wmissing-declarations were
being both conditionally included after a validity test, and then
unconditionally included later. In cases where they were acceptable,
that resulted in doubly including them, and in cases where they
were unacceptable, that meant breaking the build.
The fix is simply to remove the unconditional adds. This is a
necessary but not sufficient condition for building with CC=c99
to work.
TESTED:
Ran "scons build-all check" on OSX, and verified that the two
flags were still present in the appropriate commands, but now
only once. Also verified that building with CC=c99 no longer
fails in a manner related to those flags.
|
| |
|
|
|
|
|
|
|
| |
Debug level 3 makes macro definitions available to the debugger, which
can be useful. Given that debug=yes is only used when necessary,
there's no reason to be stingy with the debug info when it is.
TESTED:
Ran a debug build and observed "-g3" in the command lines.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code that generates the version string for development versions
tries to identify the specific code state in one of two ways. When
the build is within a git repo, it uses "git describe" output. When
the build is not within a git repo, it uses the date and time.
Before this change, the applicable date and time was the current date
and time, causing revision.h and everything that depends on it to be
rebuilt every time, even if no sources changed. This change causes it
to use the latest mtime among the relevant sources instead, thus still
having the desired effect without unnecessary changes in the version
string.
Since git doesn't preserve mtimes, the resulting date/time may reflect
the last checkout of the relevant files rather than the last actual
change, but this is still a vast improvement. And recent versions of
git avoid clobbering the mtimes of files that are not actually altered
by the checkout.
This change also alters the version format somewhat in this case, both
to incorporate the actual version number, and to eliminate some
truncation which was probably slightly incorrect, anyway.
A sample new format is:
"3.17~dev-2016-09-24T19:06:46"
TESTED:
Tested both git and non-git cases. Did not test the non-"dev" case,
but that code path is untouched.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The clock_gettime() function was originally a "second-tier" library
function in Linux, implemented in librt and requiring "-lrt" when
linking. Later versions moved it to libc, with the "-lrt" being
unnecessary. The build recipe for test_gpsmm here was failing to
account for the optional need for the "-lrt", causing it to fail
to build on debian Wheezy.
TESTED:
Now passes "scons build-all check" on a Beaglebone Black running
Debian Wheezy, where test_gpsmm formerly failed to build. Also
retested on OSX 10.9 (where librt doesn't exist) for good measure.
|
| |
|
|
|
|
|
|
|
|
| |
The original change was based on a misconception about why Navika GSV
handling improved in v3.15, which was actually due to the
already-documented signal ID fix.
Also fixes a typo in the original text.
(cherry picked from commit 4418bc6be13aa372a372c41c996437b321b4248e)
|
| | |
|
