<div dir="auto"><div>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.<div dir="auto"><br></div><div dir="auto"><a href="https://github.com/cyanfish/naps2/blob/master/NAPS2.Sdk/Scan/Internal/Sane/SaneScanDriver.cs#L324">https://github.com/cyanfish/naps2/blob/master/NAPS2.Sdk/Scan/Internal/Sane/SaneScanDriver.cs#L324</a></div><div dir="auto"><br></div><div dir="auto">Certainly it would be nice if there was an API for this but there doesn't seem to be.</div><br><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, May 28, 2025, 21:24 Ralph Little <<a href="mailto:skelband@gmail.com">skelband@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Devs,</div><div>I'm looking at an issue that affects xsane that I have had a number of complaints about.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>Cheers,</div><div>Ralph</div><div><br></div><div><br></div></div>
</blockquote></div></div></div>