Re: [sane-devel] OpenDeviceDB lists the scanners SANE supports, with links to the backend man pages

[Till Kamppeter <till.kamppeter@gmail.com>]

[ Adding OpenPrinting's developer mailing list ]

On 10/26/26 17:04, abel deuring via sane-devel wrote:
> Am Sonntag, dem 25.10.2026 um 09:07 +0100 schrieb sebastien michea:
>> Untested and unsupported entries are left out, and so is the escl backend: 
>> eSCL/AirScan is a published standard, so listing those scanners would suggest 
>> reverse engineering that never happened. If you think any of these choices is 
>> wrong, please tell me and I'll fix the importer.
> 
> 
> Did you consider this use case for https://opendevicedb.org <https:// 
> opendevicedb.org>
> 
> Somebody wants to switch from Windows to Linux. This person is a bit wary of 
> drivers problems under Linux and thus checks on your website if their scanner is 
> supported. Now they might not find it because it is only supported by the Sane's 
> eSCL backends.
> 
> This might stop them from abandoning Windows. I doubt that you want this...
> 
> Another question: I wrote a considerable part of the Sharp backend using 
> documentation provided to me by Sharp. Reverse engineering was not needed at 
> all. Would't this mean that you should also remove the Sharp backend? (Well, in 
> practice this doesn't matter much as I suspect that only very few people still 
> use a scanner that's more 20 years old...)
> 
> Fujitsu is even more complicated: In the 1990ies they published programming docs 
> for their scanners (well, at least some of their scanners) on their website. 
> Later they became more restrictive, and IIRC Allan Noah did indeed reverse 
> engineer the details how to communicate with some scanners because Fujitsu USA 
> did not want to provide the relevant docs. Out of curiosity I asked Fujitsu 
> Europe (or was it Fujitsu Germany - I can't remember...) for the docs of one 
> scanner by a phone call – and received a PDF from them one or two hours later.
> 
> How should this be handled? Should this scanner (fi-4120, IIRC) be removed from 
> the list when the HTTP request comes from Europe because docs are available 
> there but should be listed when the HTTP request comes from the USA where docs 
> are not available?
> 
> A central list of peripheral devices supported under Linux is a very nice idea 
> (though requires also a lot of maintenance work, I suspect...) But please do not 
> put artifical restrictions onto that list, like "reverse enigneered" of 
> "publicly documented protocol". If these critria are important to you, add 
> filter options for them.
> 
> cheers
> Abel
> 

I got asked the same but for OpenPrinting and printer drivers.

I think, any device about which we know whether, how, and how well it works with 
Linux and open source in general should be listed by https://opendevicedb.org/.

Windows users who want to switch to Linux do no know why and how their device is 
supported under any OS. Also under Windows they do not know whether the device 
is supported by a device-specific manufacturer or a manufacturer-independent 
standard (like IPP for printers and eSCL for scanners). So only listing devices 
at https://opendevicedb.org/ which work due to a certain method, in our case 
reverse-engineering of the devices communication protocol by independent open 
source developers, defeats the purpose of a hardware compatibility list. The 
list can tell the method for advanced, more technically interested users, but it 
should no exclude any device.

To make https://opendevicedb.org/ useful and successful, it should

- Be a central place for checking the open source support for hardware devices, 
to save the user from needing to find many different places, like OpenPrinting, 
SANE, ... and many others.
- It should list devices regardless of how they are supported: Common standards, 
official (open source) driver from manufacturer, specifications published by the 
manufacturer, driver based on reverse-engineering, ...
- Giving information about the type and quality of support, both how much of the 
functionality actually works but also giving higher value to common standards 
and/or open source drivers from the manufacturer than to closed-source drivers 
from the manufacturer or reverse-engineered drivers from an independent developer.

The site should

1. Automatically poll the full databases of as many sites as possible. We at 
OpenPrinting would also help by improving/adding an API to our site
2. Update often, use things like RSS feeds or other notification mechanisms of 
the source sites to repoll, or, use a cron job.
3. Let the user enter a device (manufacturer/model) and tell them how and how 
well it is supported. Which driver, which standard, download URL, support 
quality ...
4. The results should not depend on where the inquiry comes from. The hardware 
is usually the same all over the world, the open source software also and so the 
drivers are everywhere the same. Only if the manufacturer is geo-fencing driver 
downloads, make this clear to the user. If an open source developer gets specs 
from the manufacturer's office in their country but another developer does not 
get the specs for the same device from the manufacturer's office in another 
country, do not worry, we have the specs and it is not problem for the first 
developer to make a driver available for everybody and the second help testing 
and confirm that it works for them, too.

    Till

OpenPrinting organization lead