Closed Florob closed 1 year ago
I've been working on this for the past few months but it's taking a long time to correctly handle all non-top level descriptors. I've an almost ready version to test if you really need, it will be soon pushed in the beta update channel. Along with supporting SELECTOR it will try to ignore incorrect sequencing if it's something it doesn't understand.
I've been working on this for the past few months but it's taking a long time to correctly handle all non-top level descriptors.
This is slightly orthogonal. While I would be very happy if non-top level (CONTROL
) descriptors were supported, this only shows up because CONTROL
s on CONFIGURATION
are handled. So the issue really is about control_value_type
s.
I've an almost ready version to test if you really need, it will be soon pushed in the beta update channel. Along with supporting SELECTOR it will try to ignore incorrect sequencing if it's something it doesn't understand.
That sounds promising. I'm not in any particular hurry. However, the log message explicitly told me to file an issue, so here we are.
Well, everything is kind of actually linked all together. I first got the non-IEEE device issue when I started handling controls at all levels (the only device I have with controls at multiple levels, also uses a SELECTOR). And that's at this point I discovered the library would incorrectly flag a device as non-IEEE altough it's not the device's fault.
Title pretty much covers it.
CONTROL_SELECTOR_*
controls are not implemented yet:Aside: It is unfortunate that this leads to Hive claiming the device is not IEEE 1722.1 compliant, since this leaves a whole in the descriptor IDs, when in reality it is a shortcoming of the library.