<div dir="ltr"><div dir="ltr">Hi,</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, May 29, 2025 at 12:44 PM m. allan noah <<a href="mailto:kitno455@gmail.com">kitno455@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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?</div><div><br></div><div>allan</div></div><br></blockquote><div><br></div><div>That's an interesting idea, getting new functionality by a backdoor effectively.</div><div>Although xsane has no way to know if the installed dll layer actually supports it, it becomes a NOP if it doesn't, defaulting back to the full search.</div><div><br></div><div>I will have a look to see if this might work.</div><div><br></div><div>Something else we might look at (at some point) is how we might add some enhancements to the SANE API and migrate to it. We would have to do it in such a way to ensure backward compatibility since many third party backends are unlikely to get an upgrade.</div><div><br></div><div>Cheers</div><div>Ralph</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 29, 2025 at 1:48 PM Ben Olden-Cooligan <<a href="mailto:ben.cyanfish@gmail.com" target="_blank">ben.cyanfish@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.).</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 29, 2025 at 1:42 AM Perry Hutchison <<a href="mailto:pluto@agora.rdrop.com" target="_blank">pluto@agora.rdrop.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ralph Little <<a href="mailto:skelband@gmail.com" target="_blank">skelband@gmail.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> On Wed, May 28, 2025 at 9:32???PM Ben Olden-Cooligan <<a href="mailto:ben.cyanfish@gmail.com" target="_blank">ben.cyanfish@gmail.com</a>><br>
> wrote:<br>
><br>
> > It's very hacky but I get around this in NAPS2 by creating a temporary<br>
> > config dir with only the one backend for the specified device.<br>
><br>
> It certainly sounds a bit janky, but I didn't think of this. It might<br>
> be the only option to get the information without an API change.<br>
<br>
I haven't looked into the code, but just thinking about how something<br>
like this "has to" work I would expect sane_get_devices() to do, roughly:<br>
<br>
    for b in backends<br>
    {<br>
        ...<br>
        b->get_devices();<br>
        ...<br>
    }<br>
<br>
IOW each backend has to already implement a specified interface that<br>
probes for devices supported by that backend and (somehow) loads the<br>
results into SANE_Device.<br>
<br>
Is there some reason why a program like xsane, when told which<br>
backend to use, cannot just call that one backend's get_devices()<br>
function directly -- at the same point where it would otherwise<br>
call sane_get_devices()?  This is effectively what Ben's solution<br>
accomplishes by limiting "backends" to the one of interest, but<br>
without having to create and populate a scratch directory somewhere.<br>
<br>
> The other option actually is just to replace that descriptive<br>
> information with something nondescript like "None" or "Unknown".<br>
> Doesn't look all that great but it would avoid the delay on startup.<br>
><br>
> Cheers,<br>
> Ralph<br>
><br>
> > <a href="https://github.com/cyanfish/naps2/blob/master/NAPS2.Sdk/Scan/Internal/Sane/SaneScanDriver.cs#L324" rel="noreferrer" target="_blank">https://github.com/cyanfish/naps2/blob/master/NAPS2.Sdk/Scan/Internal/Sane/SaneScanDriver.cs#L324</a><br>
> ><br>
> > Certainly it would be nice if there was an API for this but there doesn't<br>
> > seem to be.<br>
> ><br>
> > On Wed, May 28, 2025, 21:24 Ralph Little <<a href="mailto:skelband@gmail.com" target="_blank">skelband@gmail.com</a>> wrote:<br>
> ><br>
> >> Hi Devs,<br>
> >> I'm looking at an issue that affects xsane that I have had a number<br>
> >> of complaints about.<br>
> >><br>
> >> When xsane starts, it calls sane_get_devices() regardless of whether<br>
> >> or not a specific device was specified by the user. The main issue<br>
> >> is the long delay before xsane starts up while device polling is<br>
> >> happening, which *can* be annoying long.<br>
> >><br>
> >> On the face of it, this seems pointless if we already know which<br>
> >> device the user wants to use. However, in various places, xsane<br>
> >> uses the descriptive information for that device that we get in the<br>
> >> SANE_Device structure which can only be got from sane_get_devices()<br>
> >> This seems like a gaping hole in the protocol that the information<br>
> >> about a specific device cannot be determined without searching for<br>
> >> all devices.<br>
> >><br>
> >> Does anyone have any ideas how we might get around this without<br>
> >> breaking backwards compatibility in the SANE API and have<br>
> >> I missed some official method whereby this information might be<br>
> >> obtained?<br>
> >><br>
> >> Cheers,<br>
> >> Ralph<br>
</blockquote></div>
</blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">"well, I stand up next to a mountain- and I chop it down with the edge of my hand"</div>
</blockquote></div></div>