[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] SiRF gpsmon client mode
From: |
Eric S. Raymond |
Subject: |
Re: [gpsd-dev] SiRF gpsmon client mode |
Date: |
Thu, 12 Feb 2015 09:06:25 -0500 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
Gary E. Miller <address@hidden>:
> > > Yeah, I made it wider, but not wide enough for bad cases. Also not
> > > sure why PPS is in the packet 7 box? Clearly it is not in a packet.
> >
> > Both problems have the same cause: we're badly short on screen space
> > if we want the top panel and at least one line of log window to fit
> > in a 80x25 terminal emulator. I spent a lot of ingenuity packing
> > stuff in tight, but I admit the results are not entirely satisfactory.
>
> Some programs, like atop, show more as the screen size grows. Prolly
> a PITA to code, but a possible direction to go. Or maybe some page
> flipping?
Possible. SiRF mode already does something like this -- IIRC part
of the monitor panel changes according to a mode command. But...
* If this is going to happen, post-3.12.
* I view gpsmon mainly as a way to smoke-test new hardware so people
qualifying GPSes can check that they're alive and emitting sane data.
I'm generally reluctant to add complexity to it, because it's not
a production tool and thus the payoff relative to extra maintainance
costs is not all that high.
I think making enough space for a full PPS offset *is* worth doing,
because that's a significant diagnostic for people setting up time
service. But given a choice between dramatically increasing the
complexity of gpsmon and bumping something less important off the
screen, I lean in favor of the latter.
How many spaces do I need to give the PPS offset, worst-case? I can
do a pass through the monitor implementations looking to see if I
can squeeze that in, though possibly not until after 3.12.
> > > Plus still the garbage on the right.
> >
> > I think that garbage is remnants of what was onscreen before the panel
> > was painted. You can test this by doing a 'clear' before calling
> > gpsmon; if I'm right, there will be no garbage.
>
> Sort of. I see the garbage is some JSON displayed after gpsmon
> starts and before the curses painted. Annoying, but not fatal.
I just pushed a small patch that I think fixes this. It does a clear
screen before each driver switch.
> > > Pull git head and check it out. I think the PPS in gpsmon now
> > > looking almost good. Still need to fix that ntpshm_latch() is
> > > called more than once a second in gpsmon hardware mode.
> >
> > It's on my list of things to look at.
>
> I committed a small patch to fix that. Better. The PPS now looks good
> as I stare at it, so no obvious glitches in the steady state.
Yes, it's looking good here, too.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
- [gpsd-dev] SiRF gpsmon client mode, Gary E. Miller, 2015/02/11
- Re: [gpsd-dev] SiRF gpsmon client mode, Eric S. Raymond, 2015/02/11
- Re: [gpsd-dev] SiRF gpsmon client mode, Gary E. Miller, 2015/02/11
- Re: [gpsd-dev] SiRF gpsmon client mode, Gary E. Miller, 2015/02/12
- Re: [gpsd-dev] SiRF gpsmon client mode,
Eric S. Raymond <=
- Re: [gpsd-dev] SiRF gpsmon client mode, Gary E. Miller, 2015/02/12
- Re: [gpsd-dev] SiRF gpsmon client mode, Eric S. Raymond, 2015/02/12
- Re: [gpsd-dev] SiRF gpsmon client mode, Gary E. Miller, 2015/02/12
- Re: [gpsd-dev] SiRF gpsmon client mode, Hal Murray, 2015/02/12
- Re: [gpsd-dev] SiRF gpsmon client mode, Gary E. Miller, 2015/02/12
- Re: [gpsd-dev] SiRF gpsmon client mode, Hal Murray, 2015/02/12