[sane-devel] Setting backend capabilities
paddy-hack at member.fsf.org
Sun Mar 8 08:28:18 GMT 2020
Ralph Little writes:
> 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 as
> 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
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
More information about the sane-devel