On Thu, 24 Aug 2023 10:28:01 +0200 Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > On Thu, Aug 24, 2023 at 10:24 AM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > > This should definitely be reflected in the scale attribute for the > > raw channel instead, > > Actually both IIO_CHAN_INFO_SCALE and IIO_CHAN_INFO_OFFSET > as it looks. > > I usually use tools/iio/iio_generic_buffer.c to test the result after > applied scale and offset as it takes those into account. > > Yours, > Linus Walleij Not 100% the follow is relevant as I've lost track of the discussion but maybe it is useful. Worth noting there are a few reasons why RAW and PROCESSED can coexist in drivers and indeed why SCALE can be absent.. (OFFSET is much the same) 1) If SCALE = 1.0 the driver is allowed not to provide it - the channel might still be raw if OFFSET != 0 2) If the channel has a horrible non linear and none invertable conversion to standard units and events support the you might need PROCESSED to provide the useful value, but RAW to give you clue what the current value is for setting an event (light sensors are usual place we see this). 3) Historical ABI errors. If we first had RAW and no scale or offset because we had no known values for them. Then later we discovered that there was a non linear transform involved (often when someone found a magic calibration code somewhere). Given the RAW interface might be in use and isn't a bug as such, we can't easily remove it. The new PROCESSED interface needs to be there because of the non linear transform.. Odd corner cases... In this particular case the original code made no sense but might have allowed for case 3 by accident? Jonathan
