From cool.chris65 at web.de Thu May 2 07:43:14 2024 From: cool.chris65 at web.de (Christoph) Date: Thu, 2 May 2024 08:43:14 +0200 Subject: [sane-devel] RaspiOS - Scanimage 1.2.1 - esci-driver-problem In-Reply-To: References: Message-ID: <368eea16-bc11-446d-a0b1-6806097131e0@web.de> Hi Thank you for your support. At the moment I'm still struggling with the after-effects of the flu, so it may take me a little longer to react... You say to copy your patch into the bin folder - how should I understand this? Simply copying it into there should hardly work, there are no executable binaries in your archive, but various *.deb packages, should I install them on the Raspi? Greetz, Christoph Am 30.04.24 um 23:55 schrieb thierryh at vivaldi.net: > I've added the patch that fixes the problem to your distribution's > package. You'll need to install the files in the bin folder. > > Download link : www.grosfichiers.com/8e6eHhqx9Pe > > Thierry > > Le 2024-04-30 18:08, Christoph a ?crit?: >> Hi, >> >> I tried to compile the v1.3, but it stop's during configure with an >> error: >> >> checking for pkg-config... /usr/bin/pkg-config >> checking pkg-config is at least version 0.9.0... yes >> ./configure: line 20920: syntax error near unexpected token `noext,' >> ./configure: line 20920: `AX_CXX_COMPILE_STDCXX_11(noext, optional)' >> >> I started building like this: >> >> ./autogen.sh >> ./configure --prefix=/usr --libdir=/usr/lib/arm-linux-gnueabihf >> --sysconfdir=/etc --localstatedir=/var? --enable-avahi >> >> Greetz >> Am 30.04.24 um 17:22 schrieb thierryh at vivaldi.net: >> >>> Le 2024-04-30 15:00, Christoph via sane-devel a ?crit : >>> >>>> Hi, >>>> >>>> I've just installed a raspi3 with raspiOS32 based on debian >>>> bookworm. >>>> >>>> When I tried to scan with this command: scanimage -d >>>> escl:https://192.168.1.121:443 --source "ADF Duplex" --mode >>>> Lineart >>>> --resolution 300 --progress >>>> >>>> --format=png --batch --buffer-size=128 >>>> >>>> come back like this: >>>> >>>> scanimage: rounded value of resolution from 300 to 300 >>>> scanimage: rounded value of br-x from 215.9 to 215.9 >>>> scanimage: rounded value of br-y from 297.18 to 297.18 >>>> Scanning infinity pages, incrementing by 1, numbering from 1 >>>> Scanning page 1 >>>> scanimage: sane_start: Document feeder out of documents >>>> Batch terminated, 0 pages scanned >>>> >>>> Same command with same raspi but older raspios bullseye works as >>>> expected, but only with --format=png over all pages in ADF. There >>>> was >>>> used scanimage v1.0.31 >>>> >>>> I'm using an EPSON XP-7100 >>> >>> Hi, >>> >>> This is solved, but you need to upgrade to sane-backend 1.3. >>> >>> Do you know how to build a debian package with the sources? >>> >>> Thierry >>> >>>> Greetz, Christoph From thierryh at vivaldi.net Thu May 2 09:10:29 2024 From: thierryh at vivaldi.net (thierryh at vivaldi.net) Date: Thu, 02 May 2024 08:10:29 +0000 Subject: [sane-devel] RaspiOS - Scanimage 1.2.1 - esci-driver-problem In-Reply-To: <368eea16-bc11-446d-a0b1-6806097131e0@web.de> References: <368eea16-bc11-446d-a0b1-6806097131e0@web.de> Message-ID: <070a2d45bef4c3bc3d18d19631330bc3@vivaldi.net> The archive supplied contains 4 folders: - src: contains the sources including the patch - dbg : contains debugging symbols - dev : development symbols - bin : binary packages to install To update sane-backends, simply install the packages in the bin folder: # sudo apt install bin/*.deb To avoid breaking your OS, you need to use the native packaging (debian package). Avoid this type of installation : # ./configure; make; make install Thierry Le 2024-05-02 06:43, Christoph a ?crit?: > Hi > > Thank you for your support. At the moment I'm still struggling with the > after-effects of the flu, so it may take me a little longer to react... > > You say to copy your patch into the bin folder - how should I > understand > this? Simply copying it into there should hardly work, there are no > executable binaries in your archive, but various *.deb packages, should > I install them on the Raspi? > > Greetz, Christoph > > Am 30.04.24 um 23:55 schrieb thierryh at vivaldi.net: >> I've added the patch that fixes the problem to your distribution's >> package. You'll need to install the files in the bin folder. >> >> Download link : www.grosfichiers.com/8e6eHhqx9Pe >> >> Thierry >> >> Le 2024-04-30 18:08, Christoph a ?crit?: >>> Hi, >>> >>> I tried to compile the v1.3, but it stop's during configure with an >>> error: >>> >>> checking for pkg-config... /usr/bin/pkg-config >>> checking pkg-config is at least version 0.9.0... yes >>> ./configure: line 20920: syntax error near unexpected token `noext,' >>> ./configure: line 20920: `AX_CXX_COMPILE_STDCXX_11(noext, optional)' >>> >>> I started building like this: >>> >>> ./autogen.sh >>> ./configure --prefix=/usr --libdir=/usr/lib/arm-linux-gnueabihf >>> --sysconfdir=/etc --localstatedir=/var? --enable-avahi >>> >>> Greetz >>> Am 30.04.24 um 17:22 schrieb thierryh at vivaldi.net: >>> >>>> Le 2024-04-30 15:00, Christoph via sane-devel a ?crit : >>>> >>>>> Hi, >>>>> >>>>> I've just installed a raspi3 with raspiOS32 based on debian >>>>> bookworm. >>>>> >>>>> When I tried to scan with this command: scanimage -d >>>>> escl:https://192.168.1.121:443 --source "ADF Duplex" --mode >>>>> Lineart >>>>> --resolution 300 --progress >>>>> >>>>> --format=png --batch --buffer-size=128 >>>>> >>>>> come back like this: >>>>> >>>>> scanimage: rounded value of resolution from 300 to 300 >>>>> scanimage: rounded value of br-x from 215.9 to 215.9 >>>>> scanimage: rounded value of br-y from 297.18 to 297.18 >>>>> Scanning infinity pages, incrementing by 1, numbering from 1 >>>>> Scanning page 1 >>>>> scanimage: sane_start: Document feeder out of documents >>>>> Batch terminated, 0 pages scanned >>>>> >>>>> Same command with same raspi but older raspios bullseye works as >>>>> expected, but only with --format=png over all pages in ADF. There >>>>> was >>>>> used scanimage v1.0.31 >>>>> >>>>> I'm using an EPSON XP-7100 >>>> >>>> Hi, >>>> >>>> This is solved, but you need to upgrade to sane-backend 1.3. >>>> >>>> Do you know how to build a debian package with the sources? >>>> >>>> Thierry >>>> >>>>> Greetz, Christoph From cool.chris65 at web.de Thu May 2 09:43:32 2024 From: cool.chris65 at web.de (Christoph) Date: Thu, 2 May 2024 10:43:32 +0200 Subject: [sane-devel] RaspiOS - Scanimage 1.2.1 - esci-driver-problem In-Reply-To: <070a2d45bef4c3bc3d18d19631330bc3@vivaldi.net> References: <368eea16-bc11-446d-a0b1-6806097131e0@web.de> <070a2d45bef4c3bc3d18d19631330bc3@vivaldi.net> Message-ID: Hi, ok, i tried it out, the installation works, but at least, the error with an "empty adf" is there as before ... scanimage -d escl:https://192.168.1.121:443 --source "ADF Duplex" --mode Lineart --resolution 300 --progress -- format=png --batch --buffer-size=128 scanimage: rounded value of resolution from 300 to 300 scanimage: rounded value of br-x from 215.9 to 215.9 scanimage: rounded value of br-y from 297.18 to 297.18 Scanning infinity pages, incrementing by 1, numbering from 1 Scanning page 1 scanimage: sane_start: Document feeder out of documents Batch terminated, 0 pages scanned If I look which packages are installed, I got this output (here sane-utils): apt list sane-utils Auflistung? Fertig sane-utils/now 1.2.1-5test arm64 ?[Installiert,lokal] sane-utils/stable 1.2.1-2 armhf If I'm right, it is just installed your version - and for the other packages it looks similar Greetz, Christoph Am 02.05.24 um 10:10 schrieb thierryh at vivaldi.net: > The archive supplied contains 4 folders: > > - src: contains the sources including the patch > - dbg : contains debugging symbols > - dev : development symbols > - bin : binary packages to install > > To update sane-backends, simply install the packages in the bin folder: > > # sudo apt install bin/*.deb > > To avoid breaking your OS, you need to use the native packaging > (debian package). > Avoid this type of installation : > # ./configure; make; make install > > Thierry > > Le 2024-05-02 06:43, Christoph a ?crit?: >> Hi >> >> Thank you for your support. At the moment I'm still struggling with the >> after-effects of the flu, so it may take me a little longer to react... >> >> You say to copy your patch into the bin folder - how should I understand >> this? Simply copying it into there should hardly work, there are no >> executable binaries in your archive, but various *.deb packages, should >> I install them on the Raspi? >> >> Greetz, Christoph >> >> Am 30.04.24 um 23:55 schrieb thierryh at vivaldi.net: >>> I've added the patch that fixes the problem to your distribution's >>> package. You'll need to install the files in the bin folder. >>> >>> Download link : www.grosfichiers.com/8e6eHhqx9Pe >>> >>> Thierry >>> >>> Le 2024-04-30 18:08, Christoph a ?crit?: >>>> Hi, >>>> >>>> I tried to compile the v1.3, but it stop's during configure with an >>>> error: >>>> >>>> checking for pkg-config... /usr/bin/pkg-config >>>> checking pkg-config is at least version 0.9.0... yes >>>> ./configure: line 20920: syntax error near unexpected token `noext,' >>>> ./configure: line 20920: `AX_CXX_COMPILE_STDCXX_11(noext, optional)' >>>> >>>> I started building like this: >>>> >>>> ./autogen.sh >>>> ./configure --prefix=/usr --libdir=/usr/lib/arm-linux-gnueabihf >>>> --sysconfdir=/etc --localstatedir=/var? --enable-avahi >>>> >>>> Greetz >>>> Am 30.04.24 um 17:22 schrieb thierryh at vivaldi.net: >>>> >>>>> Le 2024-04-30 15:00, Christoph via sane-devel a ?crit : >>>>> >>>>>> Hi, >>>>>> >>>>>> I've just installed a raspi3 with raspiOS32 based on debian >>>>>> bookworm. >>>>>> >>>>>> When I tried to scan with this command: scanimage -d >>>>>> escl:https://192.168.1.121:443 --source "ADF Duplex" --mode >>>>>> Lineart >>>>>> --resolution 300 --progress >>>>>> >>>>>> --format=png --batch --buffer-size=128 >>>>>> >>>>>> come back like this: >>>>>> >>>>>> scanimage: rounded value of resolution from 300 to 300 >>>>>> scanimage: rounded value of br-x from 215.9 to 215.9 >>>>>> scanimage: rounded value of br-y from 297.18 to 297.18 >>>>>> Scanning infinity pages, incrementing by 1, numbering from 1 >>>>>> Scanning page 1 >>>>>> scanimage: sane_start: Document feeder out of documents >>>>>> Batch terminated, 0 pages scanned >>>>>> >>>>>> Same command with same raspi but older raspios bullseye works as >>>>>> expected, but only with --format=png over all pages in ADF. There >>>>>> was >>>>>> used scanimage v1.0.31 >>>>>> >>>>>> I'm using an EPSON XP-7100 >>>>> >>>>> Hi, >>>>> >>>>> This is solved, but you need to upgrade to sane-backend 1.3. >>>>> >>>>> Do you know how to build a debian package with the sources? >>>>> >>>>> Thierry >>>>> >>>>>> Greetz, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From cool.chris65 at web.de Thu May 2 11:52:18 2024 From: cool.chris65 at web.de (Christoph) Date: Thu, 2 May 2024 12:52:18 +0200 Subject: [sane-devel] RaspiOS - Scanimage 1.2.1 - esci-driver-problem In-Reply-To: References: <368eea16-bc11-446d-a0b1-6806097131e0@web.de> <070a2d45bef4c3bc3d18d19631330bc3@vivaldi.net> Message-ID: In addition to my post before - just testet with raspi os (64bit) testsystem because of your packages - normaly I'm using the 32-bit-version on this raspi3 ... Am 02.05.24 um 10:43 schrieb Christoph: > > Hi, > > ok, i tried it out, the installation works, but at least, the error > with an "empty adf" is there as before ... > > scanimage -d escl:https://192.168.1.121:443 --source "ADF Duplex" > --mode Lineart --resolution 300 --progress -- > format=png --batch --buffer-size=128 > scanimage: rounded value of resolution from 300 to 300 > scanimage: rounded value of br-x from 215.9 to 215.9 > scanimage: rounded value of br-y from 297.18 to 297.18 > Scanning infinity pages, incrementing by 1, numbering from 1 > Scanning page 1 > scanimage: sane_start: Document feeder out of documents > Batch terminated, 0 pages scanned > > If I look which packages are installed, I got this output (here > sane-utils): > > apt list sane-utils > Auflistung? Fertig > sane-utils/now 1.2.1-5test arm64 ?[Installiert,lokal] > sane-utils/stable 1.2.1-2 armhf > > If I'm right, it is just installed your version - and for the other > packages it looks similar > > Greetz, Christoph > > > Am 02.05.24 um 10:10 schrieb thierryh at vivaldi.net: >> The archive supplied contains 4 folders: >> >> - src: contains the sources including the patch >> - dbg : contains debugging symbols >> - dev : development symbols >> - bin : binary packages to install >> >> To update sane-backends, simply install the packages in the bin folder: >> >> # sudo apt install bin/*.deb >> >> To avoid breaking your OS, you need to use the native packaging >> (debian package). >> Avoid this type of installation : >> # ./configure; make; make install >> >> Thierry >> >> Le 2024-05-02 06:43, Christoph a ?crit?: >>> Hi >>> >>> Thank you for your support. At the moment I'm still struggling with the >>> after-effects of the flu, so it may take me a little longer to react... >>> >>> You say to copy your patch into the bin folder - how should I >>> understand >>> this? Simply copying it into there should hardly work, there are no >>> executable binaries in your archive, but various *.deb packages, should >>> I install them on the Raspi? >>> >>> Greetz, Christoph >>> >>> Am 30.04.24 um 23:55 schrieb thierryh at vivaldi.net: >>>> I've added the patch that fixes the problem to your distribution's >>>> package. You'll need to install the files in the bin folder. >>>> >>>> Download link : www.grosfichiers.com/8e6eHhqx9Pe >>>> >>>> Thierry >>>> >>>> Le 2024-04-30 18:08, Christoph a ?crit?: >>>>> Hi, >>>>> >>>>> I tried to compile the v1.3, but it stop's during configure with an >>>>> error: >>>>> >>>>> checking for pkg-config... /usr/bin/pkg-config >>>>> checking pkg-config is at least version 0.9.0... yes >>>>> ./configure: line 20920: syntax error near unexpected token `noext,' >>>>> ./configure: line 20920: `AX_CXX_COMPILE_STDCXX_11(noext, optional)' >>>>> >>>>> I started building like this: >>>>> >>>>> ./autogen.sh >>>>> ./configure --prefix=/usr --libdir=/usr/lib/arm-linux-gnueabihf >>>>> --sysconfdir=/etc --localstatedir=/var? --enable-avahi >>>>> >>>>> Greetz >>>>> Am 30.04.24 um 17:22 schrieb thierryh at vivaldi.net: >>>>> >>>>>> Le 2024-04-30 15:00, Christoph via sane-devel a ?crit : >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I've just installed a raspi3 with raspiOS32 based on debian >>>>>>> bookworm. >>>>>>> >>>>>>> When I tried to scan with this command: scanimage -d >>>>>>> escl:https://192.168.1.121:443 --source "ADF Duplex" --mode >>>>>>> Lineart >>>>>>> --resolution 300 --progress >>>>>>> >>>>>>> --format=png --batch --buffer-size=128 >>>>>>> >>>>>>> come back like this: >>>>>>> >>>>>>> scanimage: rounded value of resolution from 300 to 300 >>>>>>> scanimage: rounded value of br-x from 215.9 to 215.9 >>>>>>> scanimage: rounded value of br-y from 297.18 to 297.18 >>>>>>> Scanning infinity pages, incrementing by 1, numbering from 1 >>>>>>> Scanning page 1 >>>>>>> scanimage: sane_start: Document feeder out of documents >>>>>>> Batch terminated, 0 pages scanned >>>>>>> >>>>>>> Same command with same raspi but older raspios bullseye works as >>>>>>> expected, but only with --format=png over all pages in ADF. There >>>>>>> was >>>>>>> used scanimage v1.0.31 >>>>>>> >>>>>>> I'm using an EPSON XP-7100 >>>>>> >>>>>> Hi, >>>>>> >>>>>> This is solved, but you need to upgrade to sane-backend 1.3. >>>>>> >>>>>> Do you know how to build a debian package with the sources? >>>>>> >>>>>> Thierry >>>>>> >>>>>>> Greetz, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From symphorien_sane at xlumurb.eu Thu May 9 16:39:12 2024 From: symphorien_sane at xlumurb.eu (Guillaume Girol) Date: Thu, 09 May 2024 17:39:12 +0200 Subject: [sane-devel] Passing all scanner usage through local saned Message-ID: <77ba6b466d78b1fbe706baf366ca2c66978e2a1f.camel@xlumurb.eu> Hello, I'm a downstream maintainer of SANE on NixOS, a linux distribution. I consider modifying NixOS to make it so all application using libsane would actually only use saned, and never load the backends to directly access scanners themselves. I send this message to the mailing list to know if I missed reasons it could be a bad idea. Rationale ========= NixOS is quite different from typical linux distributions in that there is no globally installed library. /usr/lib does not exist and without special packaging care, dlopen() never finds anything. Each library is installed in a unique prefix /nix/store/unique-id/lib/foo.so so several versions of the same library can coexist. Exeecutable find the libraries they depend on via explicit RPATH. As a result I can have an old version of python in /nix/store/some-id/bin/python using an old version of glibc in /nix/store/other-id/lib/libc.so via RPATH and the rest of the system using a newer version of glibc in /nix/store/yet- another-id/lib/libc.so also via RPATH. This does not work for SANE as it uses dlopen() to find backends depending on a single, global configuration file. For now we have an exception to the "no lib installed globally" design for SANE. However this is not perfect: if I use an old version of, say, simple-scan, it may dlopen() more recent version of some SANE backend, which depends on a more recent glibc than the version that old simple-scan brings with its RPATH. Thus dlopen() fails. In practice this means that software installed from the past or the future often fails to scan, whereas this usually works quite well for other functionnality. Solution considered =================== To solve this, I want applications using SANE to stop using dlopen() to access the scanner, but to use a network protocol instead. This is a bit like glibc can talk to nscd over a socket instead of dlopening nss modules. The solution I'm considering consists in linking all normal applications to a stripped-down variant of libsane which only has the network backend and is configured to connect to a saned instance on localhost (instead of obeying what you would find in /etc/sane.d on typical distros). Each application comes with its own copy of this libsane, it's not global anymore. (Don't mind the disk space cost, all of NixOS works this way, this is part of the tradeoff). When the user configures their system for scanner support, a global instance of saned is setup which is linked against a full-fledged copy of libsane obeying the full configuration files you would typically find in /etc/sane.d. When an old application attempts to scan, it uses its own, old version of libsane to talk to a recent saned which dlopen()s sane backends of matching version, so all works fine. Possible issues? ================ Any issues with this design I missed? In my light testing, it appears to work quite fine. The problems I found: - all users can use the scanners instead of just users in the lp or scanner group previously. I suppose this can be solved with a firewall (firewalls can filter the uid of local sockets). - network scanners are not available. I propose a fix in https://gitlab.com/sane-project/backends/-/merge_requests/834 - is the network protocol that saned uses stable across versions? In my testing, it is, but maybe it's by sheer luck. - maybe stuff I have not considered. Cheers, Guillaume Girol From Ulf.Zibis at gmx.de Fri May 10 13:31:11 2024 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 10 May 2024 14:31:11 +0200 Subject: [sane-devel] Missing package on Launchpad for current Ubuntu LTS version Message-ID: Hi, I like to report, that there is no SANE release for Ubuntu 24.04 by Launchpad PPA. -Ulf -- Von meinem Seibert gesendet From till.kamppeter at gmail.com Fri May 10 20:11:01 2024 From: till.kamppeter at gmail.com (Till Kamppeter) Date: Fri, 10 May 2024 21:11:01 +0200 Subject: [sane-devel] Passing all scanner usage through local saned In-Reply-To: <77ba6b466d78b1fbe706baf366ca2c66978e2a1f.camel@xlumurb.eu> References: <77ba6b466d78b1fbe706baf366ca2c66978e2a1f.camel@xlumurb.eu> Message-ID: <465ed5b3-c5e1-4f9b-aa2f-2196f8bd3884@gmail.com> Hi, this sounds interesting. I am running into a similar problem. Generally we have immutable distributions. The core system and the applications are in their own, isolated sandboxes, which could be Snaps, Docker containers, Flatpaks, ... With this, each application brings its own libraries and they often are of mismatching versions, and also any system-provided, centrally stored scanner drivers (SANE backends) cannot be dlopened as the core system's or a driver container's file system is not visible inside the application's sandbox. IP connections can usually be easily defined between sandboxes/containers though. So my idea, mainly with the all-Snap Ubuntu Core Desktop in mind, but applying to any immutable distro, is to use the same IP protocol as driverless network scanners and printer/scanner multi-function devices already use. These protocols are well-defined, established in the industry, and (therefore) stable across different software versions and implementations. In my design (derived from driverless IPP printing) the applications come with only the sane-airscan (written by Alexander Pevzner, CCed) backend, the backend which supports driverless scanning, currently eSCL and WSD, later perhaps also IPP Scan. All modern driverless printer/scanner multi-function devices understand either eSCL or WSD (and IPP for printing). There are also some driverless standalone scanners around which support these standard protocols. This way the applications talk directly to the scanners, without need of any centralized scanner support in the operating system. Also USB devices can be driverless. Here the IPP-over-USB standard comes to play which maps the USB device onto localhost, port 60000 and following (should be actually HTTP-over-USB, as it supports all HTTP protocols: IPP, eSCL, WSD, web admin interface). Using industry-standard protocols also allows connections across operating systems and does not limit to only SANE (we did it more than a decade ago with CUPS, replacing CUPS' own broadcasting/browsing protocol by DNS-SD). For scanners which need a driver, as they have a non-standard communication protocol, we introduce emulations of eSCL scanners, the so-called Scanner Applications. At the front they appear as eSCL (driverless) scanners and at the back they are talking with the actual scanner device, converting the protocols internally. Like a physical network device they advertise the presence of the scanner via DNS-SD (Avahi under Linux) and the eSCL protocol allows clients to poll the full set of capabilities (resolutions, scan sizes, ADF, ...) from the Scanner Application and also to conduct the actual scan. One Scanner Application can contain any amount of scanner drivers and there can be any amount of Scanner Applications installed on the system. So we can have one Scanner Application retro-fitting the whole sane-backends package and other Scanner Applications issued by scanner manufacturers to support their devices. Internally Scanner Applications do not need to use SANE, they can accomplish their job with whatever the developer considers best. So we will have native Scanner Applications not using SANE internally and retro-fitting Scanner Applications using SANE. Applications which scan and scanner drivers (Scanner Applications) can be in different sandboxes and so be installed independently on immutable (and also classic) operating system distributions, so especially one can add scanner drivers to an immutable distribution this way, and as each sandboxed package brings their own libraries, they can work with different libraries. So especially also the situation of packages using different libraries in Nix OS gets solved this way. For the implementation, on the client side there is not much to do. One only needs to have a SANE-supporting application and ship it together with the sane-airscan backend. On the server/driver/device side is more to do but we are well into it. As we come from the situation of printer/scanner multi-function devices, out emulation is actually also an emulation of such a multi-function device if we want to support a non-driverless multi-function device. Several years back we (at OpenPrinting) have already started with printing. All modern printers are driverless. they do driverless IPP printing. AirPrint, Mopria, IPP Everywhere, and Wi-Fi Direct Print are all just flavors of driverless IPP printing. Here the printer always advertises itself by DNS-SD. Then clients can find the printer and poll the printer's capabilities from the printer via an IPP request and then print the job in a standard data format (PDF, but also some raster formats for cheaper printers), so there is no need for a driver (aka device-model-specific software or data, like CUPS filters and/or PPD files) for printing. For non-driverless legacy or specialty printers we have introduced Printer Applications, emulations of driverless IPP printers. To create such Printer Applications there is a standard library, PAPPL (Printer APPlication Library) written by Michael Sweet, author of CUPS. It contains everything which every Printer Application needs: Daemon, handlers for DNS-SD and IPP, web admin interface, ... and Michael also ha written two native (no CUPS filters and PPD files hidden inside) Printer Applications, hp-printer-app (for legacy PCL lasers) and LPrint (for label printers). I have written pappl-retrofit, an additional library for PAPPL with which one can easily wrap classic CUPS printer drivers and PostScript PPD files into Printer Applications (retro-fitting). Currently Akarshan Kapoor (CCed), GSoC contributor for OpenPrinting last year and this year, is adding scanner support to PAPPL, so that with PAPPL one can make both Printer and Scanner Applications, even support multi-function printers with one single application. He is adding eSCL support to PAPPL (which before only supported IPP printing) and SANE support to pappl-retrofit. This way we get a universal Printer/Scanner driver format which allows for distribution-independent binary package and for adding drivers not only to classically installed but also to immutable operating systems. We are snapping these Printer and Scanner Applications and putting them into the Snap Store. Currently you find all free software printer drivers which usually come with Linux distributions in 4 retro-fitting Printer Applications and the 2 native Printer Applications from Michael Sweet. Scanner Applications will hopefully come soon. Printer Applications and Scanner Applications are not required to get distributed as Snaps, one can also just install them classically or put them into other containers. At OpenPrinting we have this year also a GSoC project on OCI (Docker, ROCKs, podman, ...) containerization to cover most immutable distros which are around. For the issues you mentioned, network scanners are available, those on modern network multi-function devices usually directly, without need of a Scanner Application. SANE-shared scanners we can support by the planned sane-backends-retro-fitting Scanner Applications. Scanner Applications can be configured to share scanners in the local network or to restrict them for only local use. The eSCL being an industry standard protocol it will be supported by any version of sane-airscan and PAPPL once it has scanning support. No changes between software versions are expected. Links: Printer Applications: https://openprinting.github.io/achievements/#all-free-drivers-in-a-ppd-less-world---or---all-free-drivers-in-snaps Scanner Applications: https://openprinting.github.io/current/#scanner-applications PAPPL: https://github.com/michaelrsweet/pappl/ pappl-retrofit: https://github.com/OpenPrinting/pappl-retrofit/ LPrint: https://github.com/michaelrsweet/lprint/ OpenPrinting in the Snap Store: https://snapcraft.io/publisher/openprinting LPrint in the Snap Store: https://snapcraft.io/lprint Scanning support for PAPPL: https://dev.to/kappuccino111/sandboxing-scanners-a-leap-into-the-driverless-realm-gsoc-23-report-3eci https://www.youtube.com/watch?v=AAeUseU35Cc Till On 09/05/2024 17:39, Guillaume Girol via sane-devel wrote: > Hello, > > I'm a downstream maintainer of SANE on NixOS, a linux distribution. I > consider modifying NixOS to make it so all application using libsane > would actually only use saned, and never load the backends to directly > access scanners themselves. I send this message to the mailing list to > know if I missed reasons it could be a bad idea. > > Rationale > ========= > > NixOS is quite different from typical linux distributions in that there > is no globally installed library. /usr/lib does not exist and without > special packaging care, dlopen() never finds anything. Each library is > installed in a unique prefix /nix/store/unique-id/lib/foo.so so several > versions of the same library can coexist. Exeecutable find the > libraries they depend on via explicit RPATH. As a result I can have an > old version of python in /nix/store/some-id/bin/python using an old > version of glibc in /nix/store/other-id/lib/libc.so via RPATH and the > rest of the system using a newer version of glibc in /nix/store/yet- > another-id/lib/libc.so also via RPATH. > > This does not work for SANE as it uses dlopen() to find backends > depending on a single, global configuration file. For now we have an > exception to the "no lib installed globally" design for SANE. However > this is not perfect: if I use an old version of, say, simple-scan, it > may dlopen() more recent version of some SANE backend, which depends on > a more recent glibc than the version that old simple-scan brings with > its RPATH. Thus dlopen() fails. In practice this means that software > installed from the past or the future often fails to scan, whereas this > usually works quite well for other functionnality. > > Solution considered > =================== > > To solve this, I want applications using SANE to stop using dlopen() to > access the scanner, but to use a network protocol instead. This is a > bit like glibc can talk to nscd over a socket instead of dlopening nss > modules. > > The solution I'm considering consists in linking all normal > applications to a stripped-down variant of libsane which only has the > network backend and is configured to connect to a saned instance on > localhost (instead of obeying what you would find in /etc/sane.d on > typical distros). Each application comes with its own copy of this > libsane, it's not global anymore. (Don't mind the disk space cost, all > of NixOS works this way, this is part of the tradeoff). When the user > configures their system for scanner support, a global instance of saned > is setup which is linked against a full-fledged copy of libsane obeying > the full configuration files you would typically find in /etc/sane.d. > > When an old application attempts to scan, it uses its own, old version > of libsane to talk to a recent saned which dlopen()s sane backends of > matching version, so all works fine. > > Possible issues? > ================ > > Any issues with this design I missed? In my light testing, it appears > to work quite fine. The problems I found: > - all users can use the scanners instead of just users in the lp or > scanner group previously. I suppose this can be solved with a firewall > (firewalls can filter the uid of local sockets). > - network scanners are not available. I propose a fix in > https://gitlab.com/sane-project/backends/-/merge_requests/834 > - is the network protocol that saned uses stable across versions? In my > testing, it is, but maybe it's by sheer luck. > - maybe stuff I have not considered. > > > Cheers, > Guillaume Girol > > From till.kamppeter at gmail.com Sat May 11 08:19:43 2024 From: till.kamppeter at gmail.com (Till Kamppeter) Date: Sat, 11 May 2024 09:19:43 +0200 Subject: [sane-devel] Passing all scanner usage through local saned In-Reply-To: References: <77ba6b466d78b1fbe706baf366ca2c66978e2a1f.camel@xlumurb.eu> <465ed5b3-c5e1-4f9b-aa2f-2196f8bd3884@gmail.com> Message-ID: <33bd3571-10bb-497e-99be-5f398fb24e20@gmail.com> On 11/05/2024 02:54, Steven Santos wrote: > At this point, maybe we should be talking about if SANE is the correct long-term > scanning solution for linux. > With printing we have gone completely to the industry standards: IPP + DNS-SD With scanning we should do the same way. > More or less, all modern scanners are supported by the eSCL backend, and will be > going forward. > > So why not standardize Linux scanning via eSCL? > This is what I am suggesting/introducing. Apps find scanners via DNS-SD and communicate with them via eSCL. This is exactly what sane-airscan is doing and so we get this by sandboxing scanning frontend applications together with sane-airscan. It can even later on happen that eSCL client applications show up which do not use SANE any more (but it is not urgent to create those, as long as the SANE API does not apply a functional bottle neck to eSCL. > It would seem to me that we could just develop a dummy scanner app to expose the > current SANE and its drivers as an eSCL front end. > This "dummy scanner app" is what I call a retro-fitting Scanner Application. Emulation of an eSCL scanner using PAPPL with Akarshan's scanning support and using Akarshan's SANE-backend-retro-fit support which he is adding to pappl-retrofit. > One advantage to this is it would give us a path to support all TWAIN scanners > on Linux via TWAIN Direct.? It would just be a matter of building a TWAIN > Driect?to eSCL in the same way. For this we would need a Scanner Application which on its back side speaks TWAIN Direct, and this running on Linux and ideally on any operating system. We would ideally have the specification of TWAIN Direct. Is this specification published? Or is it only available under NDA for paying customers.Or do you think about reverse-engineering here, as we have done with the many scanners with their proprietary protocols do get SANE drivers for them? Reverse-engineering is principally possible (we started eSCL this way, too) but always prone to incompleteness and inaccuracy. If somebody steps up doing this and implements it in a native PAPPL-based Scanner Application, this would be great. This also looks like that hardware manufacturers do three different approaches for driverless scanning, eSCL, WSD, and TWAIN Direct. Here we need to observe the market. eSCL seems to be the most commonplace, WSD is also visible, but I do not know whether there are still many new devices exclusively using it or whether it is turning legacy. WSD is at least already supported, by sane-airscan. But is TWAIN Direct widely made use of by the scanner industry? Does perhaps every scanner which does TWAIN Direct also do eSCL and so TWAIN Direct gets redundant? Or is TWAIN Direct even a nice name for actually being eSCL (or WSD or IPP Scan)? We have a similar thing with printing. Driverless IPP printing comes under the 4 names IPP Everywhere, AirPrint, Mopria, and Wi-Fi Direct Print. Internally this is all the same. So we need to investigate TWAIN Direct, how it internally works and how widespread is its use. Till From thierryh at vivaldi.net Sat May 11 10:40:36 2024 From: thierryh at vivaldi.net (thierryh at vivaldi.net) Date: Sat, 11 May 2024 09:40:36 +0000 Subject: [sane-devel] Passing all scanner usage through local saned In-Reply-To: <33bd3571-10bb-497e-99be-5f398fb24e20@gmail.com> References: <77ba6b466d78b1fbe706baf366ca2c66978e2a1f.camel@xlumurb.eu> <465ed5b3-c5e1-4f9b-aa2f-2196f8bd3884@gmail.com> <33bd3571-10bb-497e-99be-5f398fb24e20@gmail.com> Message-ID: <6310c952c1b70736f749bb588356c372@vivaldi.net> Le 2024-05-11 07:19, Till Kamppeter a ?crit?: > On 11/05/2024 02:54, Steven Santos wrote: >> At this point, maybe we should be talking about if SANE is the correct >> long-term scanning solution for linux. >> > > With printing we have gone completely to the industry standards: IPP + > DNS-SD With scanning we should do the same way. It seems to me that this is the role of the sane-net backend. > >> More or less, all modern scanners are supported by the eSCL backend, >> and will be going forward. >> >> So why not standardize Linux scanning via eSCL? As far as the eSCL protocol is concerned (as I've already pointed out), the capacities on display are lesser. Admittedly, this will suit most users, but that won't always be the case, as of late: https://gitlab.com/sane-project/backends/-/issues/747 >> > > This is what I am suggesting/introducing. Apps find scanners via DNS-SD > and communicate with them via eSCL. This is exactly what sane-airscan > is doing and so we get this by sandboxing scanning frontend > applications together with sane-airscan. It can even later on happen > that eSCL client applications show up which do not use SANE any more > (but it is not urgent to create those, as long as the SANE API does not > apply a functional bottle neck to eSCL. > >> It would seem to me that we could just develop a dummy scanner app to >> expose the current SANE and its drivers as an eSCL front end. >> > > This "dummy scanner app" is what I call a retro-fitting Scanner > Application. Emulation of an eSCL scanner using PAPPL with Akarshan's > scanning support and using Akarshan's SANE-backend-retro-fit support > which he is adding to pappl-retrofit. > >> One advantage to this is it would give us a path to support all TWAIN >> scanners on Linux via TWAIN Direct.? It would just be a matter of >> building a TWAIN Driect?to eSCL in the same way. > > For this we would need a Scanner Application which on its back side > speaks TWAIN Direct, and this running on Linux and ideally on any > operating system. We would ideally have the specification of TWAIN > Direct. Is this specification published? Or is it only available under > NDA for paying customers.Or do you think about reverse-engineering > here, as we have done with the many scanners with their proprietary > protocols do get SANE drivers for them? Reverse-engineering is > principally possible (we started eSCL this way, too) but always prone > to incompleteness and inaccuracy. > > If somebody steps up doing this and implements it in a native > PAPPL-based Scanner Application, this would be great. > > This also looks like that hardware manufacturers do three different > approaches for driverless scanning, eSCL, WSD, and TWAIN Direct. Here > we need to observe the market. eSCL seems to be the most commonplace, > WSD is also visible, but I do not know whether there are still many new > devices exclusively using it or whether it is turning legacy. WSD is at > least already supported, by sane-airscan. But is TWAIN Direct widely > made use of by the scanner industry? Does perhaps every scanner which > does TWAIN Direct also do eSCL and so TWAIN Direct gets redundant? Or > is TWAIN Direct even a nice name for actually being eSCL (or WSD or IPP > Scan)? We have a similar thing with printing. Driverless IPP printing > comes under the 4 names IPP Everywhere, AirPrint, Mopria, and Wi-Fi > Direct Print. Internally this is all the same. > > So we need to investigate TWAIN Direct, how it internally works and how > widespread is its use. > > Till From pzz at apevzner.com Sat May 11 14:08:00 2024 From: pzz at apevzner.com (Alexander Pevzner) Date: Sat, 11 May 2024 16:08:00 +0300 Subject: [sane-devel] Passing all scanner usage through local saned In-Reply-To: <33bd3571-10bb-497e-99be-5f398fb24e20@gmail.com> References: <77ba6b466d78b1fbe706baf366ca2c66978e2a1f.camel@xlumurb.eu> <465ed5b3-c5e1-4f9b-aa2f-2196f8bd3884@gmail.com> <33bd3571-10bb-497e-99be-5f398fb24e20@gmail.com> Message-ID: <72dc1484-0bd4-4f4f-bc26-51cd44d2bf82@apevzner.com> Hi, guys! On 5/11/24 10:19, Till Kamppeter wrote: >> One advantage to this is it would give us a path to support all TWAIN >> scanners on Linux via TWAIN Direct.? It would just be a matter of >> building a TWAIN Driect?to eSCL in the same way. > > For this we would need a Scanner Application which on its back side > speaks TWAIN Direct, and this running on Linux and ideally on any > operating system. We would ideally have the specification of TWAIN > Direct. Is this specification published? Or is it only available under > NDA for paying customers.Or do you think about reverse-engineering here, > as we have done with the many scanners with their proprietary protocols > do get SANE drivers for them? Reverse-engineering is principally > possible (we started eSCL this way, too) but always prone to > incompleteness and inaccuracy. Regarding TWAIN Direct, I have few comments. First of all, TWAIN Direct has nothing in common with the classical old-fashion TWAIN except that it is backed by the same organization. The classical TWAIN is the scanner API standard, like SANE. Driver may implement any protocol under the hood, but if it implements the TWAIN API, it is compatible with all apps that can work with TWAIN drivers. The TWAIN Direct is the, first of all, network protocol. It is similar to eSCL and WSD on its spirit, uses HTML as a transport and, as far as I remember, DNS-SD for discovery. Requests and responses are encoded in JSON (unlike eSCL and WSD; these are XML-based), Specification is freely available, but it's quality, well, like WSD: many ambiguous places that needs experimenting. In theory, TWAIN Direct can be one of the driverless protocols for scanner, like others already in use. Practically, scanners that support TWAIN Direct in firmware are very rare things. So far I know only one such a device, Xerox D70n Scanner (https://www.xeroxscanners.com/en/us/products/item.asp?PN=D70N) but never seen it in real life. If TWAIN Direct scanners will become more popular, I will consider adding support of this protocol into sane-airscan. Currently I even don't have a device for testing. -- Wishes, Alexander Pevzner (pzz at apevzner.com) From till.kamppeter at gmail.com Sat May 11 17:15:11 2024 From: till.kamppeter at gmail.com (Till Kamppeter) Date: Sat, 11 May 2024 18:15:11 +0200 Subject: [sane-devel] Passing all scanner usage through local saned In-Reply-To: <6310c952c1b70736f749bb588356c372@vivaldi.net> References: <77ba6b466d78b1fbe706baf366ca2c66978e2a1f.camel@xlumurb.eu> <465ed5b3-c5e1-4f9b-aa2f-2196f8bd3884@gmail.com> <33bd3571-10bb-497e-99be-5f398fb24e20@gmail.com> <6310c952c1b70736f749bb588356c372@vivaldi.net> Message-ID: On 11/05/2024 11:40, thierryh at vivaldi.net wrote: > > As far as the eSCL protocol is concerned (as I've already pointed out), the > capacities on display are lesser. > Admittedly, this will suit most users, but that won't always be the case, as of > late: https://gitlab.com/sane-project/backends/-/issues/747 > Good to know that. Another reason to add/switch to IPP Scan on the long run. In the beginning I wanted to use IPP Scan, as we use already IPP for printing. Then Michael Sweet told me that available hardware is not using IPP Scan but only eSCL or WSD and so it would be better to do the Scanner Applications with eSCL and therefore I started wit eSCL, not looking for somebody adding IPP Scan support to sane-airscan and letting Akarshan do the Scanner Application support eSCL-based. Later on I came already to thoughts that sooner or late we will have to use IPP Scan, even if there is no hardware device using it. IPP Scan is much more powerful and versatile for enterprise network scanning, as for each device, independent whether printer, scanner, or multi-function device, one has common things like IPP System Service. Also IPP has encryption (IPPS) and OAuth2 authentication. This would also cover the problem ----- - all users can use the scanners instead of just users in the lp or scanner group previously. I suppose this can be solved with a firewall (firewalls can filter the uid of local sockets). ----- mentioned in the end of the initial mail of this thread. Now you are telling that eSCL supports less functionality than SANE's own network protocol does, I assume that IPP Scan, which is thoroughly designed by the Printer Working Group (PWG, www.pwg.org) as part of the whole IPP, is most probably at least superior compared to eSCL perhaps even to SANE's protocol. So then we should proceed as follows: - Akarshan completes the eSCL-based Scanner Application support, so that we have Scanner Applications at least. - Somebody starts an IPPScan (as a client) backend ort adds IPP Scan support to the sane-airscan backend. - Somebody adds IPP Scan (as a server) to PAPPL. This way we get a more future-proof and versatile network scanning protocol for everyone which also integrates well for printing. Till From till.kamppeter at gmail.com Sat May 11 17:30:06 2024 From: till.kamppeter at gmail.com (Till Kamppeter) Date: Sat, 11 May 2024 18:30:06 +0200 Subject: [sane-devel] Passing all scanner usage through local saned In-Reply-To: <72dc1484-0bd4-4f4f-bc26-51cd44d2bf82@apevzner.com> References: <77ba6b466d78b1fbe706baf366ca2c66978e2a1f.camel@xlumurb.eu> <465ed5b3-c5e1-4f9b-aa2f-2196f8bd3884@gmail.com> <33bd3571-10bb-497e-99be-5f398fb24e20@gmail.com> <72dc1484-0bd4-4f4f-bc26-51cd44d2bf82@apevzner.com> Message-ID: On 11/05/2024 15:08, Alexander Pevzner wrote: > > Regarding TWAIN Direct, I have few comments. > > First of all, TWAIN Direct has nothing in common with the classical old-fashion > TWAIN except that it is backed by the same organization. > > The classical TWAIN is the scanner API standard, like SANE. Driver may implement > any protocol under the hood, but if it implements the TWAIN API, it is > compatible with all apps that can work with TWAIN drivers. > > The TWAIN Direct is the, first of all, network protocol. It is similar to eSCL > and WSD on its spirit, uses HTML as a transport and, as far as I remember, > DNS-SD for discovery. Requests and responses are encoded in JSON (unlike eSCL > and WSD; these are XML-based), > > Specification is freely available, but it's quality, well, like WSD: many > ambiguous places that needs experimenting. > > In theory, TWAIN Direct can be one of the driverless protocols for scanner, like > others already in use. > OK, good to know that TWAIN Direct is a forth network scanning protocol in addition to IPP Scan, eSCL, and WSD and we have also specs for it naturally knot knowing the quality of these specs. > Practically, scanners that support TWAIN Direct in firmware are very rare > things. Also good to know. We must check whether these scanners are TWAIN-Direct-only, in this case we would need a TWAIN-direct backend, if all these scanners are also eSCL or WSD we can perhaps consider TWAIN Direct as dead standard. > So far I know only one such a device, Xerox D70n Scanner > (https://www.xeroxscanners.com/en/us/products/item.asp?PN=D70N) but never seen > it in real life. > > If TWAIN Direct scanners will become more popular, I will consider adding > support of this protocol into sane-airscan. Currently I even don't have a device > for testing. > Yes, we would need at least one device for testing if we want to add support for it. So for me there is higher priority on adding support for IPP Scan, client (ans backend, sane-airscan) and server (PAPPL). Till From thierryh at vivaldi.net Sat May 11 17:44:33 2024 From: thierryh at vivaldi.net (thierryh at vivaldi.net) Date: Sat, 11 May 2024 16:44:33 +0000 Subject: [sane-devel] Passing all scanner usage through local saned In-Reply-To: References: <77ba6b466d78b1fbe706baf366ca2c66978e2a1f.camel@xlumurb.eu> <465ed5b3-c5e1-4f9b-aa2f-2196f8bd3884@gmail.com> <33bd3571-10bb-497e-99be-5f398fb24e20@gmail.com> <6310c952c1b70736f749bb588356c372@vivaldi.net> Message-ID: <9a7e6d81912fb7a4e906950456148d05@vivaldi.net> Le 2024-05-11 16:15, Till Kamppeter a ?crit?: > mentioned in the end of the initial mail of this thread. > > Now you are telling that eSCL supports less functionality than SANE's > own network protocol does, I assume that IPP Scan, which is thoroughly > designed by the Printer Working Group (PWG, www.pwg.org) as part of the > whole IPP, is most probably at least superior compared to eSCL perhaps > even to SANE's protocol. I don't think I understand what you're saying! The eSCL and WSD devices provide their capabilities, so I don't see how an "IPP Scan" overlay would be better (the implementation why not). I prefer the PIXMA or EPSONSCAN2 backends, which expose many more properties than eSCL or WSD. Thierry From pzz at apevzner.com Sat May 11 18:16:31 2024 From: pzz at apevzner.com (Alexander Pevzner) Date: Sat, 11 May 2024 20:16:31 +0300 Subject: [sane-devel] Passing all scanner usage through local saned In-Reply-To: <9a7e6d81912fb7a4e906950456148d05@vivaldi.net> References: <77ba6b466d78b1fbe706baf366ca2c66978e2a1f.camel@xlumurb.eu> <465ed5b3-c5e1-4f9b-aa2f-2196f8bd3884@gmail.com> <33bd3571-10bb-497e-99be-5f398fb24e20@gmail.com> <6310c952c1b70736f749bb588356c372@vivaldi.net> <9a7e6d81912fb7a4e906950456148d05@vivaldi.net> Message-ID: <4bb33cec-bcd5-41ae-a177-7b5195d7c2cc@apevzner.com> Hi Thierry, On 5/11/24 19:44, thierryh at vivaldi.net wrote: > I don't think I understand what you're saying! > The eSCL and WSD devices provide their capabilities, so I don't see how > an "IPP Scan" overlay would be better (the implementation why not). > I prefer the PIXMA or EPSONSCAN2 backends, which expose many more > properties than eSCL or WSD. Let me try to explain these things a little bit. We are currently speaking about the following SANE architecture switch. Intead dlopen-ing libsane-XXX.so backends directly by the client application, the new architecture proposes the following: 1. There are one (or even multiple) system daemons 2. These daemons dlopen appropriate libsane-XXX.so backend 3. And these daemons expose scanner functionality using some network protocol and localhost address 4. And user applications don't speak directly with hardware, but using these daemons as proxy. It sounds a bit overcompensated, but this architecture has many advantages over existent one: 1. libsane-XXX.so can be isolated (into snap, flatpack or whatever else) together with its own instance of scanning daemon. This is important for distros that prefer to keep all parts in separate containers 2. The daemon may initialize early, so when user application wants to scan, everything is ready (currently, if there are many backends enabled, initialization may take seconds). 3. Only this scanning daemon needs direct access to USB. Users will not longer need direct access to USB devices. 4. Access control can be implemented very straightforward and cleanly, in the scanning daemon in pure software, not near hardware. What we are actually discussing now, is what network protocol to use for communication with that daemon. The choice is between SANE's native protocol (used by saned and sane-net backend) and standard-compliant scanning protocol (here we have eSCL, WSD, TWAIN Direct and IPP-scan). Please note, we are speaking about communication protocol that will be used to communicate with software daemon, not with the printer hardware. So it is not actually correct to say that eSCL is limited in comparison to the PIXMA protocol. Cannon implementation of eSCL may be limited (and this is Canon's decision to promote their proprietary protocol by limiting their implementation of the standard eSCL), but these limitations are not part of the eSCL specification by itself, and other hardware exposes all its functionality to both proprietary protocol and to eSCL. -- Wishes, Alexander Pevzner (pzz at apevzner.com) From thierryh at vivaldi.net Sat May 11 18:39:44 2024 From: thierryh at vivaldi.net (thierryh at vivaldi.net) Date: Sat, 11 May 2024 17:39:44 +0000 Subject: [sane-devel] Passing all scanner usage through local saned In-Reply-To: <4bb33cec-bcd5-41ae-a177-7b5195d7c2cc@apevzner.com> References: <77ba6b466d78b1fbe706baf366ca2c66978e2a1f.camel@xlumurb.eu> <465ed5b3-c5e1-4f9b-aa2f-2196f8bd3884@gmail.com> <33bd3571-10bb-497e-99be-5f398fb24e20@gmail.com> <6310c952c1b70736f749bb588356c372@vivaldi.net> <9a7e6d81912fb7a4e906950456148d05@vivaldi.net> <4bb33cec-bcd5-41ae-a177-7b5195d7c2cc@apevzner.com> Message-ID: <0eb529e7bdc30f7ac8400cbb53d622b0@vivaldi.net> Le 2024-05-11 17:16, Alexander Pevzner a ?crit?: >> The eSCL and WSD devices provide their capabilities, so I don't see >> how an "IPP Scan" overlay would be better (the implementation why >> not). >> I prefer the PIXMA or EPSONSCAN2 backends, which expose many more >> properties than eSCL or WSD. > > Let me try to explain these things a little bit. Thanks Alexander, that makes it clearer! > 2. The daemon may initialize early, so when user application wants to > scan, everything is ready (currently, if there are many backends > enabled, initialization may take seconds). From my point of view, a scanner configuration module is missing, so as not to waste time on initialization. Initialization should just be a readout of configured devices. > The choice is between SANE's native protocol (used by saned and > sane-net backend) and standard-compliant scanning protocol (here we > have eSCL, WSD, TWAIN Direct and IPP-scan). Once a configuration exists, sane-net is operational. > So it is not actually correct to say that eSCL is limited in comparison > to the PIXMA protocol. > > Cannon implementation of eSCL may be limited (and this is Canon's > decision to promote their proprietary protocol by limiting their > implementation of the standard eSCL), but these limitations are not > part of the eSCL specification by itself, and other hardware exposes > all its functionality to both proprietary protocol and to eSCL. You're right, the problem isn't the protocol but the manufacturers, because this isn't unique to Canon. Thierry From symphorien_sane at xlumurb.eu Sat May 11 19:02:58 2024 From: symphorien_sane at xlumurb.eu (Guillaume Girol) Date: Sat, 11 May 2024 20:02:58 +0200 Subject: [sane-devel] Passing all scanner usage through local saned In-Reply-To: <465ed5b3-c5e1-4f9b-aa2f-2196f8bd3884@gmail.com> References: <77ba6b466d78b1fbe706baf366ca2c66978e2a1f.camel@xlumurb.eu> <465ed5b3-c5e1-4f9b-aa2f-2196f8bd3884@gmail.com> Message-ID: Le vendredi 10 mai 2024 ? 21:11 +0200, Till Kamppeter a ?crit?: > > > In my design (derived from driverless IPP printing) the applications > come with > only the sane-airscan (written by Alexander Pevzner, CCed) backend, > the backend > which supports driverless scanning, currently eSCL and WSD, later > perhaps also > IPP Scan. [...] > > For scanners which need a driver, as they have a non-standard > communication > protocol, we introduce emulations of eSCL scanners, the so-called > Scanner > Applications. At the front they appear as eSCL (driverless) scanners > and at the > back they are talking with the actual scanner device, converting the > protocols > internally. Like a physical network device they advertise the > presence of the > scanner via DNS-SD (Avahi under Linux) and the eSCL protocol allows > clients to > poll the full set of capabilities (resolutions, scan sizes, ADF, ...) > from the > Scanner Application and also to conduct the actual scan. > Thank you for this initiative, it sounds like an interesting solution to the problem I'm trying to solve. Will you post progress news here, or is there a better channel? The main upside of your approach is that it uses a standard protocol, but the main downside for now is that it does not exist yet. So I'm still curious, has the saned protocol been stable in the past? Are there hidden downsides to using saned as it exists now? Guillaume Girol From ben.cyanfish at gmail.com Sat May 11 18:43:32 2024 From: ben.cyanfish at gmail.com (Ben Olden-Cooligan) Date: Sat, 11 May 2024 10:43:32 -0700 Subject: [sane-devel] Passing all scanner usage through local saned In-Reply-To: <0eb529e7bdc30f7ac8400cbb53d622b0@vivaldi.net> References: <77ba6b466d78b1fbe706baf366ca2c66978e2a1f.camel@xlumurb.eu> <465ed5b3-c5e1-4f9b-aa2f-2196f8bd3884@gmail.com> <33bd3571-10bb-497e-99be-5f398fb24e20@gmail.com> <6310c952c1b70736f749bb588356c372@vivaldi.net> <9a7e6d81912fb7a4e906950456148d05@vivaldi.net> <4bb33cec-bcd5-41ae-a177-7b5195d7c2cc@apevzner.com> <0eb529e7bdc30f7ac8400cbb53d622b0@vivaldi.net> Message-ID: I would also add that, as an application developer, I would much appreciate something like this being available in general (not just on NixOS). When I distribute as a Flatpak/Snap, my application can't access all SANE scanners on the system, only those whose drivers I've specifically bundled in the Flatpak. A level of network indirection would solve this. To answer the question of whether the saned protocol is stable, it is part of the SANE Standard which hasn't been updated since 2008, so presumably it is very stable. As far as which protocol to use - my 2c is that saned is an existing protocol with the needed capabilities (perhaps with some minor tweaks). Implementing a new standard seems like overkill, and attempting to map every possible SANE parameter to eSCL seems unnecessary. On Sat, May 11, 2024 at 10:39?AM ThierryFR via sane-devel < sane-devel at alioth-lists.debian.net> wrote: > Le 2024-05-11 17:16, Alexander Pevzner a ?crit : > >> The eSCL and WSD devices provide their capabilities, so I don't see > >> how an "IPP Scan" overlay would be better (the implementation why > >> not). > >> I prefer the PIXMA or EPSONSCAN2 backends, which expose many more > >> properties than eSCL or WSD. > > > > Let me try to explain these things a little bit. > Thanks Alexander, that makes it clearer! > > > 2. The daemon may initialize early, so when user application wants to > > scan, everything is ready (currently, if there are many backends > > enabled, initialization may take seconds). > From my point of view, a scanner configuration module is missing, so as > not to waste time on initialization. > Initialization should just be a readout of configured devices. > > > The choice is between SANE's native protocol (used by saned and > > sane-net backend) and standard-compliant scanning protocol (here we > > have eSCL, WSD, TWAIN Direct and IPP-scan). > Once a configuration exists, sane-net is operational. > > > > So it is not actually correct to say that eSCL is limited in comparison > > to the PIXMA protocol. > > > > Cannon implementation of eSCL may be limited (and this is Canon's > > decision to promote their proprietary protocol by limiting their > > implementation of the standard eSCL), but these limitations are not > > part of the eSCL specification by itself, and other hardware exposes > > all its functionality to both proprietary protocol and to eSCL. > You're right, the problem isn't the protocol but the manufacturers, > because this isn't unique to Canon. > > Thierry > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From symphorien_sane at xlumurb.eu Sat May 11 19:58:50 2024 From: symphorien_sane at xlumurb.eu (Guillaume Girol) Date: Sat, 11 May 2024 20:58:50 +0200 Subject: [sane-devel] Passing all scanner usage through local saned In-Reply-To: References: <77ba6b466d78b1fbe706baf366ca2c66978e2a1f.camel@xlumurb.eu> <465ed5b3-c5e1-4f9b-aa2f-2196f8bd3884@gmail.com> <33bd3571-10bb-497e-99be-5f398fb24e20@gmail.com> <6310c952c1b70736f749bb588356c372@vivaldi.net> <9a7e6d81912fb7a4e906950456148d05@vivaldi.net> <4bb33cec-bcd5-41ae-a177-7b5195d7c2cc@apevzner.com> <0eb529e7bdc30f7ac8400cbb53d622b0@vivaldi.net> Message-ID: <0510fc9c8ff2520a03fccb71767e404e497097a2.camel@xlumurb.eu> Le samedi 11 mai 2024 ? 10:43 -0700, Ben Olden-Cooligan a ?crit?: > > To answer the question of whether the saned protocol is stable, it is > part of the SANE Standard which hasn't been updated since 2008, so > presumably it is very stable. > > Oh thank you I did not know that SANE was a standard and not just one specific implementation! Guillaume Girol From thierryh at vivaldi.net Sun May 12 10:55:24 2024 From: thierryh at vivaldi.net (thierryh at vivaldi.net) Date: Sun, 12 May 2024 09:55:24 +0000 Subject: [sane-devel] Passing all scanner usage through local saned In-Reply-To: <77ba6b466d78b1fbe706baf366ca2c66978e2a1f.camel@xlumurb.eu> References: <77ba6b466d78b1fbe706baf366ca2c66978e2a1f.camel@xlumurb.eu> Message-ID: Le 2024-05-09 15:39, Guillaume Girol via sane-devel a ?crit?: > Hello, > > I'm a downstream maintainer of SANE on NixOS, a linux distribution. I > consider modifying NixOS to make it so all application using libsane > would actually only use saned, and never load the backends to directly > access scanners themselves. I send this message to the mailing list to > know if I missed reasons it could be a bad idea. > > Rationale > ========= > > NixOS is quite different from typical linux distributions in that there > is no globally installed library. /usr/lib does not exist and without > special packaging care, dlopen() never finds anything. Each library is > installed in a unique prefix /nix/store/unique-id/lib/foo.so so several > versions of the same library can coexist. Exeecutable find the > libraries they depend on via explicit RPATH. As a result I can have an > old version of python in /nix/store/some-id/bin/python using an old > version of glibc in /nix/store/other-id/lib/libc.so via RPATH and the > rest of the system using a newer version of glibc in /nix/store/yet- > another-id/lib/libc.so also via RPATH. > > This does not work for SANE as it uses dlopen() to find backends > depending on a single, global configuration file. For now we have an > exception to the "no lib installed globally" design for SANE. However > this is not perfect: if I use an old version of, say, simple-scan, it > may dlopen() more recent version of some SANE backend, which depends on > a more recent glibc than the version that old simple-scan brings with > its RPATH. Thus dlopen() fails. In practice this means that software > installed from the past or the future often fails to scan, whereas this > usually works quite well for other functionnality. > > Solution considered > =================== > > To solve this, I want applications using SANE to stop using dlopen() to > access the scanner, but to use a network protocol instead. This is a > bit like glibc can talk to nscd over a socket instead of dlopening nss > modules. > > The solution I'm considering consists in linking all normal > applications to a stripped-down variant of libsane which only has the > network backend and is configured to connect to a saned instance on > localhost (instead of obeying what you would find in /etc/sane.d on > typical distros). Each application comes with its own copy of this > libsane, it's not global anymore. (Don't mind the disk space cost, all > of NixOS works this way, this is part of the tradeoff). When the user > configures their system for scanner support, a global instance of saned > is setup which is linked against a full-fledged copy of libsane obeying > the full configuration files you would typically find in /etc/sane.d. > > When an old application attempts to scan, it uses its own, old version > of libsane to talk to a recent saned which dlopen()s sane backends of > matching version, so all works fine. > > Possible issues? > ================ > > Any issues with this design I missed? In my light testing, it appears > to work quite fine. The problems I found: > - all users can use the scanners instead of just users in the lp or > scanner group previously. I suppose this can be solved with a firewall > (firewalls can filter the uid of local sockets). > - network scanners are not available. I propose a fix in > https://gitlab.com/sane-project/backends/-/merge_requests/834 > - is the network protocol that saned uses stable across versions? In my > testing, it is, but maybe it's by sheer luck. > - maybe stuff I have not considered. > Hi, Just a question about this operation: How are the scanners discovered? Thierry > > Cheers, > Guillaume Girol From thierryh at vivaldi.net Sun May 12 11:10:36 2024 From: thierryh at vivaldi.net (thierryh at vivaldi.net) Date: Sun, 12 May 2024 10:10:36 +0000 Subject: [sane-devel] Passing all scanner usage through local saned In-Reply-To: References: <77ba6b466d78b1fbe706baf366ca2c66978e2a1f.camel@xlumurb.eu> Message-ID: Le 2024-05-12 09:55, ThierryFR via sane-devel a ?crit?: > Le 2024-05-09 15:39, Guillaume Girol via sane-devel a ?crit?: >> Hello, >> >> I'm a downstream maintainer of SANE on NixOS, a linux distribution. I >> consider modifying NixOS to make it so all application using libsane >> would actually only use saned, and never load the backends to directly >> access scanners themselves. I send this message to the mailing list to >> know if I missed reasons it could be a bad idea. >> >> Rationale >> ========= >> >> NixOS is quite different from typical linux distributions in that >> there >> is no globally installed library. /usr/lib does not exist and without >> special packaging care, dlopen() never finds anything. Each library is >> installed in a unique prefix /nix/store/unique-id/lib/foo.so so >> several >> versions of the same library can coexist. Exeecutable find the >> libraries they depend on via explicit RPATH. As a result I can have an >> old version of python in /nix/store/some-id/bin/python using an old >> version of glibc in /nix/store/other-id/lib/libc.so via RPATH and the >> rest of the system using a newer version of glibc in /nix/store/yet- >> another-id/lib/libc.so also via RPATH. >> >> This does not work for SANE as it uses dlopen() to find backends >> depending on a single, global configuration file. For now we have an >> exception to the "no lib installed globally" design for SANE. However >> this is not perfect: if I use an old version of, say, simple-scan, it >> may dlopen() more recent version of some SANE backend, which depends >> on >> a more recent glibc than the version that old simple-scan brings with >> its RPATH. Thus dlopen() fails. In practice this means that software >> installed from the past or the future often fails to scan, whereas >> this >> usually works quite well for other functionnality. >> >> Solution considered >> =================== >> >> To solve this, I want applications using SANE to stop using dlopen() >> to >> access the scanner, but to use a network protocol instead. This is a >> bit like glibc can talk to nscd over a socket instead of dlopening nss >> modules. >> >> The solution I'm considering consists in linking all normal >> applications to a stripped-down variant of libsane which only has the >> network backend and is configured to connect to a saned instance on >> localhost (instead of obeying what you would find in /etc/sane.d on >> typical distros). Each application comes with its own copy of this >> libsane, it's not global anymore. (Don't mind the disk space cost, all >> of NixOS works this way, this is part of the tradeoff). When the user >> configures their system for scanner support, a global instance of >> saned >> is setup which is linked against a full-fledged copy of libsane >> obeying >> the full configuration files you would typically find in /etc/sane.d. >> >> When an old application attempts to scan, it uses its own, old version >> of libsane to talk to a recent saned which dlopen()s sane backends of >> matching version, so all works fine. >> >> Possible issues? >> ================ >> >> Any issues with this design I missed? In my light testing, it appears >> to work quite fine. The problems I found: >> - all users can use the scanners instead of just users in the lp or >> scanner group previously. I suppose this can be solved with a firewall >> (firewalls can filter the uid of local sockets). >> - network scanners are not available. I propose a fix in >> https://gitlab.com/sane-project/backends/-/merge_requests/834 >> - is the network protocol that saned uses stable across versions? In >> my >> testing, it is, but maybe it's by sheer luck. >> - maybe stuff I have not considered. >> > Hi, > > Just a question about this operation: > How are the scanners discovered? My bad. I've just tested it and it works pretty well. > > Thierry >> >> Cheers, >> Guillaume Girol From andrea.croci at gmx.de Mon May 13 23:19:58 2024 From: andrea.croci at gmx.de (Andreas Croci) Date: Tue, 14 May 2024 00:19:58 +0200 Subject: [sane-devel] Canon MF746Cx not working under OpenSUSE Message-ID: Hello, I have a multifunction Canon MF746Cx and several machines: one Ubuntu 22.04 and one OpenSUSE Leap 15.5 (the others don't matter really). In Ubuntu, when I run "scanimage -L" I get [00:06:02.547369] [bjnp] add_scanner: Scanner MF745C/746C is not supported, model is unknown! Please report upstream Created directory: /var/lib/snmp/cert_indexes device `escl:http://192.168.200.103:80' is a Canon MF745C/746C platen,adf scanner device `airscan:e0:Canon MF745C/746C' is a eSCL Canon MF745C/746C ip=192.168.200.103 so I am able to scan using the escl and airscan backends. On OpenSUSE there are no such backends in /etc/sane.d/ and I didn't find any option to install them (zypper doesn't find them in the default repositories). Also there is no dll.d direcotry under /etc/sane.d/ in OpenSUSE. Another thing is that in OpenSUSE, other than in Ubuntu, all backends are commented out in /etc/sane.d/dll.conf, so in order to try making it work I uncommented "pixma" because I thought it would be the closest to the right backend for my machine. I also tried adding in pixma.conf the line "bjnp://address.to.scanner" and "mfnp://address.to.scanner" and now "scanomage -L" gives me [00:17:39.635393] [bjnp] add_scanner: Scanner MF745C/746C is not supported, model is unknown! Please report upstream No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). "sane-find-scanner" doesn't find anything. How can I get this scanner to work in OpenSUSE too? Is there a place where I can download either "airscan" or "escl" for this OS? Thank you, Andreas From jsmeix at suse.de Tue May 14 06:33:52 2024 From: jsmeix at suse.de (Johannes Meixner) Date: Tue, 14 May 2024 07:33:52 +0200 Subject: [sane-devel] Canon MF746Cx not working under OpenSUSE In-Reply-To: References: Message-ID: Hello, On 2024-05-14 00:19, Andreas Croci via sane-devel wrote (excerpts): > multifunction Canon MF746Cx > OpenSUSE Leap 15.5 ... > Is there a place where I can download either "airscan" > or "escl" for this OS? See https://software.opensuse.org/search?baseproject=ALL&q=airscan There is "sane-airscan" listed. When you "View" that, there becomes "openSUSE Leap 15.5" shown and there is a "Show experimental packages" which shows "graphics [Experimental] 0.99.29 [1 Click Install] [Expert Download]" where e.g. [Expert Download] is a link to https://software.opensuse.org/download/package?package=sane-airscan&project=graphics Alternatively you can access openSUSE binary RPM packages directly e.g. sane-airscan from the openSUSE Build Service (OBS) development project "graphics" (that is what "graphics" and "experimental" above means - i.e. from a development project) which is built for openSUSE Leap 15.5 on x86_64 architecture at http://download.opensuse.org/repositories/graphics/15.5/x86_64/ I do not have a scanner that uses "airscan" or "escl" so I can neither try out how this software works nor could I help in case of issues with this software or in general with scanners that use "airscan" or "escl". For generic information about "Configuring Scanners" see https://en.opensuse.org/SDB:Configuring_Scanners Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Frankenstr. 146 - 90461 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Ivo Totev From andrea.croci at gmx.de Tue May 14 13:19:53 2024 From: andrea.croci at gmx.de (Andreas Croci) Date: Tue, 14 May 2024 14:19:53 +0200 Subject: [sane-devel] Canon MF746Cx not working under OpenSUSE In-Reply-To: References: Message-ID: <406f6961-3dc8-48a6-b771-360d0259220d@gmx.de> Thank you very much for your reply. I tried the first of you solutions, but it didn't work. I clicked on "Expert Download" and it offered me a few more options, among other LEAP 15.5. I downloaded that and it saved a "sane-airscan.ymp". I right-clicked on it and it offered me to 1-Click-install it with YAST. That's what I did, but it failed installing the repositories "SUSE:SLE-15-SP1:GA" through "SUSE:SLE-15-SP5:GA". The installation failed. I repeated the process and this time it said the installation (of "sane-airscan") was successful. But scanning still doesn't work. In the directories "/etc/sane.d" and "/etc/sane.d/dll.d" there are the files "airscan.conf" and "airscan"? respectively, but "scanimage -L" gives: "[13:58:00.608002] [bjnp] add_scanner: Scanner MF745C/746C is not supported, model is unknown! Please report upstream No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages)." basically the same as before. "sudo airscan-discover -d" gives: "airscan-discover: symbol lookup error: /usr/lib64/libtiff.so.6: undefined symbol: jpeg12_write_raw_data, version LIBJPEG_8.0" A "sudo zypper refresh" says: "Retrieving repository 'SUSE:SLE-15-SP2:GA' metadata ...................................................[error] Repository 'SUSE:SLE-15-SP2:GA' is invalid. [https-download.opensuse.org-21540982|https://download.opensuse.org/repositories/SUSE:/SLE-15-SP2:/GA/pool/] Valid metadata not found at specified URL History: ?- [https-download.opensuse.org-21540982|https://download.opensuse.org/repositories/SUSE:/SLE-15-SP2:/GA/pool/] Repository type can't be determined. Please check if the URIs defined for this repository are pointing to a valid repository. Skipping repository 'SUSE:SLE-15-SP2:GA' because of the above error." and the same for SP1, SP3, SP4 and SP5. Now I'm more out of clue than I was before. On 14/05/24 07:33, Johannes Meixner wrote: > > Hello, > > On 2024-05-14 00:19, Andreas Croci via sane-devel wrote (excerpts): >> multifunction Canon MF746Cx >> OpenSUSE Leap 15.5 > ... >> Is there a place where I can download either "airscan" >> or "escl" for this OS? > > See > https://software.opensuse.org/search?baseproject=ALL&q=airscan > > There is "sane-airscan" listed. > When you "View" that, there becomes "openSUSE Leap 15.5" shown > and there is a "Show experimental packages" which shows > "graphics [Experimental] 0.99.29 [1 Click Install] [Expert Download]" > where e.g. [Expert Download] is a link to > https://software.opensuse.org/download/package?package=sane-airscan&project=graphics > > > Alternatively you can access openSUSE binary RPM packages directly > e.g. sane-airscan from the openSUSE Build Service (OBS) > development project "graphics" (that is what "graphics" and > "experimental" above means - i.e. from a development project) > which is built for openSUSE Leap 15.5 on x86_64 architecture at > http://download.opensuse.org/repositories/graphics/15.5/x86_64/ > > I do not have a scanner that uses "airscan" or "escl" > so I can neither try out how this software works > nor could I help in case of issues with this software > or in general with scanners that use "airscan" or "escl". > > For generic information about "Configuring Scanners" see > https://en.opensuse.org/SDB:Configuring_Scanners > > > Kind Regards > Johannes Meixner From pribyl at lowlevel.cz Sat May 18 12:03:33 2024 From: pribyl at lowlevel.cz (Adam Pribyl) Date: Sat, 18 May 2024 13:03:33 +0200 (CEST) Subject: [sane-devel] CanoScan LIDE 120 black scans - lamp remains off Message-ID: I have older installation of Ubuntu 16.04 with libsane 1.0.28 where this scanner works OK. On Ubuntu 22.04 neither with libsane 1.1.1 from distro or 1.2.1ppa3-jammy0 from sane-releases ppa I can not make it to scan anything but a black page. I found out the lamp is never on. I also tried vuescan and results same, switching back to pc with Ubuntu 16.04 scanner works - so lamp is OK. Any idea how to fix that? Thanks Adam Pribyl From Ulf.Zibis at gmx.de Sun May 19 11:47:13 2024 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 19 May 2024 12:47:13 +0200 Subject: [sane-devel] Missing package on Launchpad for current Ubuntu LTS version In-Reply-To: References: Message-ID: Am 10.05.24 um 14:31 schrieb Ulf Zibis via sane-devel: > Hi, > > I like to report, that there is no SANE release for Ubuntu 24.04 by Launchpad PPA. The latest Ubuntu LTS release is 4 weeks old. Why isn't there a matching package here? : https://launchpad.net/~sane-project/+archive/ubuntu/sane-release Or at least a dev version here: https://launchpad.net/~sane-project/+archive/ubuntu/sane-git -Ulf -- Von meinem Seibert gesendet