On Sat, Jan 03, 2015 at 04:00:44PM -0800, Linus Torvalds wrote: > On Sat, Jan 3, 2015 at 1:38 PM, Dirk Hohndel <[email protected]> wrote: > > > > Fix will be pushed momentarily > > Thanks, seems to work fine. Now it didn't complain when I updated to > the latest version. > > I think I have everything I can do for EON Steel easily done. There's > a few things I wouldn't mind to expose, but I don't think > libdivecomputer has the interfaces for them.
Then let's propose some interfaces may be? Or are these too specialized to make sense? > For example, the EON Steel has this per-cylinder, in addition to the gas mix: > > - what kind cylinder usage it is (primary/diluent) > - PO2 > - transmitter ID That seems useful and generic - and the CCR crowd will go wild :-) > and right now I just expose the transmitter ID as a string (and not > per cylinder - if you have multiple transmitters, you'll just get > multiple "Transmitter ID" strings). > > I think that's fine for the transmitter ID, but I'd like to expose the > cylinder type somehow. I didn't figure out how, though. How about you do this as strings? "Cylinder n use", "primary" "Cylinder n PO2", "1.6" We can then decide if we want to add such strings as "API" and parse them on the Subsurface side. > There's a few more things I could add, like "conservatism" (P-2 .. P2). That one is definitely "extra data" that you could expose as a string. > And I just noticed that in the "state" and "notification" event mess, > I had missed the fact that there is a separate set of "warning" > events. So I'll send a libdicecomputer patch for that soon. > > But other than that, things look good to me. Cool. /D _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
