[sane-devel] SANE_Device issue

[m. allan noah]

Hmm, could the frontend set an environment variable which contains the
devicename it wants to open, and have the core sane dll parse out the
backend name?

allan

On Thu, May 29, 2025 at 1:48 PM Ben Olden-Cooligan <ben.cyanfish at gmail.com>
wrote:

> That might be possible in theory, but at a minimum you'd need to duplicate
> SANE's DLL loading logic which is nontrivial (e.g. it works differently on
> different kinds of systems, can depend on compiler flags, etc.).
>
> On Thu, May 29, 2025 at 1:42 AM Perry Hutchison <pluto at agora.rdrop.com>
> wrote:
>
>> Ralph Little <skelband at gmail.com> wrote:
>>
>> > Hi,
>> >
>> > On Wed, May 28, 2025 at 9:32???PM Ben Olden-Cooligan <
>> ben.cyanfish at gmail.com>
>> > wrote:
>> >
>> > > It's very hacky but I get around this in NAPS2 by creating a temporary
>> > > config dir with only the one backend for the specified device.
>> >
>> > It certainly sounds a bit janky, but I didn't think of this. It might
>> > be the only option to get the information without an API change.
>>
>> I haven't looked into the code, but just thinking about how something
>> like this "has to" work I would expect sane_get_devices() to do, roughly:
>>
>>     for b in backends
>>     {
>>         ...
>>         b->get_devices();
>>         ...
>>     }
>>
>> IOW each backend has to already implement a specified interface that
>> probes for devices supported by that backend and (somehow) loads the
>> results into SANE_Device.
>>
>> Is there some reason why a program like xsane, when told which
>> backend to use, cannot just call that one backend's get_devices()
>> function directly -- at the same point where it would otherwise
>> call sane_get_devices()?  This is effectively what Ben's solution
>> accomplishes by limiting "backends" to the one of interest, but
>> without having to create and populate a scratch directory somewhere.
>>
>> > The other option actually is just to replace that descriptive
>> > information with something nondescript like "None" or "Unknown".
>> > Doesn't look all that great but it would avoid the delay on startup.
>> >
>> > Cheers,
>> > Ralph
>> >
>> > >
>> https://github.com/cyanfish/naps2/blob/master/NAPS2.Sdk/Scan/Internal/Sane/SaneScanDriver.cs#L324
>> > >
>> > > Certainly it would be nice if there was an API for this but there
>> doesn't
>> > > seem to be.
>> > >
>> > > On Wed, May 28, 2025, 21:24 Ralph Little <skelband at gmail.com> wrote:
>> > >
>> > >> Hi Devs,
>> > >> I'm looking at an issue that affects xsane that I have had a number
>> > >> of complaints about.
>> > >>
>> > >> When xsane starts, it calls sane_get_devices() regardless of whether
>> > >> or not a specific device was specified by the user. The main issue
>> > >> is the long delay before xsane starts up while device polling is
>> > >> happening, which *can* be annoying long.
>> > >>
>> > >> On the face of it, this seems pointless if we already know which
>> > >> device the user wants to use. However, in various places, xsane
>> > >> uses the descriptive information for that device that we get in the
>> > >> SANE_Device structure which can only be got from sane_get_devices()
>> > >> This seems like a gaping hole in the protocol that the information
>> > >> about a specific device cannot be determined without searching for
>> > >> all devices.
>> > >>
>> > >> Does anyone have any ideas how we might get around this without
>> > >> breaking backwards compatibility in the SANE API and have
>> > >> I missed some official method whereby this information might be
>> > >> obtained?
>> > >>
>> > >> Cheers,
>> > >> Ralph
>>
>

-- 
"well, I stand up next to a mountain- and I chop it down with the edge of
my hand"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/sane-devel/attachments/20250529/2f8f9b38/attachment.htm>