Hi Guennadi, > But that patch only re-reads the flags. What does that give you? Do those > flags change? In which way? As far as I understand the UVC Autoupdate > feature, a change in GET_INFO data is only one possibility, (arguably) a > more important one is changes in GET_CUR data. My understanding of the driver is rather narrow, so please correct me if I am wrong. >From what I can see the uvc driver is currently not asking the device if a property has self modifying properties (and thus would require the AUTO_UPDATE flag). This is only done for properties in the extension unit but not for 'standard' properties. Thus properties exhibit different behavior depending on where they are defined. By changing this the driver now assumes that a property with AUTO_UPDATE has to be re-read when getting/setting a property and does not rely on cached values, no matter if extension unit or not. I did not consider the possibility that a lower level change would be necessary or that a more previce update mechanism for different property parts was possible. Basically the entry point for my change would be here: https://git.linuxtv.org/media_tree.git/tree/drivers/media/usb/uvc/uvc_ctrl.c#n1405 How an update is handled by the driver did not seem important for this patch as the retrieval of a correct property value seemed more important. > In either case, this should > be implemented using the UVC Interrupt endpoint. Here's my latest > asynchronous control patch: > > https://patchwork.linuxtv.org/patch/42800/ > > As you can see, it only handles the VALUE_CHANGE (GET_CUR) case. I would > suggest implementing a patch on top of it to add support for INFO_CHANGE > and you'd be the best person to test it then! I will try it out. I should be able to give you feedback tomorrow. I will also ask the firmware developer if only value changes are available or flag changes are also a possibility. Cheers, Edgar
