Profile support for multiple concurrent pressure sensors

This finally handles multiple cylinder pressures, both overlapping and
consecutive, and it seems to work on the nasty cases I've thrown at it.

Want to just track five different cylinders all at once, without any
pesky gas switch events? Sure, you can do that.  It will show five
different gas pressures for your five cylinders, and they will go down
as you breathe down the cylinders.

I obviously don't have any real data for that case, but I do have a test
file with five actual cylinders that all have samples over the whole
course of the dive.  The end result looks messy as hell, but what did
you expect?

HOWEVER.

The only way to do this sanely was

 - actually make the "struct plot_info" have all the cylinder pressures
   (so no "sensor index and pressure" - every cylinder has a pressure for
   every plot info entry)

   This obviously makes the plot_info much bigger. We used to have
   MAX_CYLINDERS be a fairly generous 8, which seems sane. The planning
   code made that 8 be 20. That seems questionable. But whatever.

   The good news is that the plot-info should hopefully get freed, and
   only be allocated one dive at a time, so the fact that it is big and
   nasty shouldn't be a scaling issue, though.

 - the "populate_pressure_information()" function had to be rewritten
   quite a bit. The good news is that it's actually simpler now, although
   I would not go so far as to really call it simple. It's still
   complicated and suble, but now it explicitly just does one cylinder at
   a time.

   It *used* to have this insanely complicated "keep track of the pressure
   ranges for every cylinder at once". I just couldn't stand that model
   and keep my sanity, so it now just tracks one cylinder at a time, and
   doesn't have an array of live data, instead the caller will just call
   it for each cylinder.

 - get rid of some of our hackier stuff, like the code that populates the
   plot_info data code with the currently selected cylinder number, and
   clears out any other pressures. That obviously does *not* work when you
   may not have a single primary cylinder any more.

Now, the above sounds like all good things. Yeah, it mostly is.

BUT.

There's a few big downsides from the above:

 - there's no sane way to do this as a series of small changes.

   The change to make the plot_info take an array of cylinder pressures
   rather than the sensor+pressure model really isn't amenable to "fix up
   one use at a time". When you switch over to the new data structure
   model, you have to switch over to the new way of populating the
   pressure ranges. The two just go hand in hand.

 - Some of our code *depended* on the "sensor+pressure" model. I fixed all
   the ones I could sanely fix. There was one particular case that I just
   couldn't sanely fix, and I didn't care enough about it to do something
   insane.

   So the only _known_ breakage is the "TankItem" profile widget. That's
   the bar at the bottom of the profile that shows which cylinder is in
   use right now. You'd think that would be trivial to fix up, and yes it
   would be - I could just use the regular model of

     firstcyl = explicit_first_cylinder(dive, dc)
     .. then iterate over the gas change events to see the others ..

   but the problem with the "TankItem" widget is that it does its own
   model, and it has thrown away the dive and the dive computer
   information. It just doesn't even know. It only knows what cylinders
   there are, and the plot_info. And it just used to look at the sensor
   number in the plot_info, and be done with that. That number no longer
   exists.

 - I have tested it, and I think the code is better, but hey, it's a
   fairly large patch to some of the more complex code in our code base.
   That "interpolate missing pressure fields" code really isn't pretty. It
   may be prettier, but..

Anyway, without further ado, here's the patch. No sign-off yet, because I
do think people should look and comment. But I think the patch is fine,
and I'll fix anythign that anybody can find, *except* for that TankItem
thing that I will refuse to touch. That class is ugly. It needs to have
access to the actual dive.

Note how it actually does remove more lines than it adds, and that's
despite added comments etc. The code really is simpler, but there may be
cases in there that need more work.

Known missing pieces that don't currently take advantage of concurrent
cylinder pressure data:

 - the momentary SAC rate coloring for dives will need more work

 - dive merging (but we expect to generally normally not merge dive
   computers, which is the main source of sensor data)

 - actually taking advantage of different sensor data from different
   dive computers

But most of all: Testing.  Lots and lots of testing to find all the
corner cases.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>

0 files changed, 0 insertions, 0 deletions