On Tue, Oct 28, 2014 at 11:36:51AM -0700, Dirk Hohndel wrote:
On Tue, Oct 28, 2014 at 11:01:10AM -0700, Linus Torvalds wrote:
On Tue, Oct 28, 2014 at 10:39 AM, Dirk Hohndel dirk@hohndel.org wrote:
When discussing this with Jef he usually is not in favor of adding all these speacial things so I'm thinking of doing the parsing in Subsurface instead. You should implement a SAMPLE_VENDOR_EONSTEEL and pass the raw sample data back to subsurface...
I'd much rather just these things as some "string event" back, and *not* make them special to the EON steel.
That is EXACTLY what I want. I need to understand what you pass to the callback:
if (!callback(dc_buffer_get_data(file), dc_buffer_get_size(file), NULL, 0, userdata))
What's in that buffer?
So I think we might want to introduce an event type that literally gives two strings: a description and a value. And then subsurface can show that in an information window or something (maybe similarly to how we show the dive computer name - hover over the name, and get the dive computer "random data" fields.
This would allow returning things like "Conservatism" and "Dive mode" too. Again, these things don't have any meaning *across* dive computers, and not all dive computers necessarily even agree about the meaning, so there is no sense in some kind of organized model for the data, but it can be interesting for a human who knows the dive computer to see.
You can do this already. You just need to cheat. DC_SAMPLE_VENDOR allows you to pass data of a given length. Simply have two strings in there, both \0 terminated.
Actually, dive mode and conservatism and battery voltage are all per dive, not per sample. So we don't even need DC_SAMPLE_VENDOR. This should all be contained in the dc_buffer_get_data(file) - so the question remains, what's in that buffer?
/D