Hi Ralph, Ralph Little writes:
> Hi, > > On 2020-03-07 6:06 p.m., Olaf Meeuwissen wrote: >> >> [...], I also think SANE_CAP_SOFT_SELECT is the better choice from >> the user point of view. However, you might consider adding a check for >> the current hardware side setting to sane_control_option() so it can >> signal the frontend in case changes were made hardware side. >> >> # I considered adding a polling loop but that doesn't make much sense. >> # You can only signal the frontend via sane_control_option() that it >> # needs to SANE_INFO_RELOAD_OPTIONS, so checking there is good enough. > > Ah, I have implemented and checked in the change to make those sensors > work but as you say, xsane currently does not take account of changes > made on the hardware which is a shame. As mentioned in my other reply, it is a limitation of the SANE API :-/ > I will look into the SANE_INFO_RELOAD_OPTIONS aspect. And I only mentioned that as the best work-around I could think of within the confines of the current SANE API (version 1.x). > I think most proprietary scan software implementations that I have > observed use a polling loop of some sort, some utilizing USB INTERRUPT, > some not. Making it clear that this needs to be absorbed by the backend so frontends will not have to deal with this. Fun point to consider: It has to work over the network protocol[2] as well :-? [2]: https://sane-project.gitlab.io/standard/net.html > When I have looked into that, perhaps you would be kind enough to > review the changes? :D Sure but anything that goes around version 1.x of the SANE API is a no-no. Hope this helps, -- Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Software https://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join
