Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #225314 > unrolled thread

SANE default scanner

Back to article view | Back to linux.debian.user

Contents

  SANE default scanner Nicolas George <george@nsup.org> - 2020-07-27 12:00 +0200
    Re: SANE default scanner Georgi Naplatanov <gosho@oles.biz> - 2020-07-27 14:00 +0200
      Re: SANE default scanner Nicolas George <george@nsup.org> - 2020-07-27 14:50 +0200
        Re: SANE default scanner Brian <ad44@cityscape.co.uk> - 2020-07-27 15:00 +0200
          Re: SANE default scanner Nicolas George <george@nsup.org> - 2020-07-27 15:00 +0200
            Re: SANE default scanner Brian <ad44@cityscape.co.uk> - 2020-07-27 15:30 +0200
          Re: SANE default scanner Hans <hans.ullrich@loop.de> - 2020-07-27 15:10 +0200
            Re: SANE default scanner Nicolas George <george@nsup.org> - 2020-07-27 15:30 +0200
        Re: SANE default scanner Georgi Naplatanov <gosho@oles.biz> - 2020-07-27 15:10 +0200
          Re: SANE default scanner Reco <recoverym4n@enotuniq.net> - 2020-07-27 15:30 +0200
          Re: SANE default scanner Nicolas George <george@nsup.org> - 2020-07-27 15:40 +0200
            Re: SANE default scanner Brian <ad44@cityscape.co.uk> - 2020-07-27 16:00 +0200
              Re: SANE default scanner Nicolas George <george@nsup.org> - 2020-07-27 16:30 +0200
                Re: SANE default scanner Nicolas George <george@nsup.org> - 2020-07-27 17:40 +0200
                  Re: SANE default scanner Brian <ad44@cityscape.co.uk> - 2020-07-27 18:10 +0200
                Re: SANE default scanner Brian <ad44@cityscape.co.uk> - 2020-07-27 17:40 +0200
            Re: SANE default scanner Georgi Naplatanov <gosho@oles.biz> - 2020-07-27 16:50 +0200
              Re: SANE default scanner Nicolas George <george@nsup.org> - 2020-07-27 17:00 +0200
                Re: SANE default scanner Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-27 17:20 +0200
                  Re: SANE default scanner Nicolas George <george@nsup.org> - 2020-07-27 17:30 +0200
                    Re: SANE default scanner Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-27 18:10 +0200
                      Re: SANE default scanner Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-27 18:40 +0200
                        Re: SANE default scanner Brian <ad44@cityscape.co.uk> - 2020-07-27 19:20 +0200
                      Re: SANE default scanner Nicolas George <george@nsup.org> - 2020-07-27 18:40 +0200
                        Re: SANE default scanner Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-27 23:10 +0200
                          Re: SANE default scanner Nicolas George <george@nsup.org> - 2020-07-28 00:00 +0200
                            Re: SANE default scanner Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-28 00:30 +0200
                              Re: SANE default scanner Nicolas George <george@nsup.org> - 2020-07-28 14:20 +0200
                                Re: SANE default scanner Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-28 16:20 +0200
                                  Re: SANE default scanner Brian <ad44@cityscape.co.uk> - 2020-07-28 21:30 +0200
                                  Re: SANE default scanner Nicolas George <george@nsup.org> - 2020-07-29 11:20 +0200
                                    Re: SANE default scanner <tomas@tuxteam.de> - 2020-07-29 12:10 +0200
                                      Re: SANE default scanner Brian <ad44@cityscape.co.uk> - 2020-07-29 20:30 +0200
                                        Re: SANE default scanner <tomas@tuxteam.de> - 2020-07-29 21:40 +0200
                            Re: SANE default scanner <tomas@tuxteam.de> - 2020-07-28 09:40 +0200
                      Re: SANE default scanner Brian <ad44@cityscape.co.uk> - 2020-07-27 18:40 +0200
                        Re: SANE default scanner Nicolas George <george@nsup.org> - 2020-07-27 18:50 +0200
                          Re: SANE default scanner Brian <ad44@cityscape.co.uk> - 2020-07-27 19:10 +0200
                            Re: SANE default scanner Nicolas George <george@nsup.org> - 2020-07-27 19:20 +0200
                              Re: SANE default scanner Brian <ad44@cityscape.co.uk> - 2020-07-27 20:00 +0200
                    Re: SANE default scanner Nicolas George <george@nsup.org> - 2020-07-27 19:40 +0200
                      Re: SANE default scanner Brian <ad44@cityscape.co.uk> - 2020-07-28 14:20 +0200
                Re: SANE default scanner Brian <ad44@cityscape.co.uk> - 2020-07-27 20:40 +0200
                  Re: SANE default scanner Brian <ad44@cityscape.co.uk> - 2020-07-27 21:20 +0200
                  Re: SANE default scanner Gene Heskett <gheskett@shentel.net> - 2020-07-27 21:20 +0200
        Re: SANE default scanner John Boxall <jboxall47@gmail.com> - 2020-07-27 15:30 +0200
          Re: SANE default scanner Nicolas George <george@nsup.org> - 2020-07-27 15:40 +0200
            Re: SANE default scanner Liam O'Toole <liam.p.otoole@gmail.com> - 2020-07-29 00:00 +0200
    Re: SANE default scanner Nicolas George <george@nsup.org> - 2020-07-27 19:40 +0200
      Re: SANE default scanner Siard <shiems@mailbox.org> - 2020-07-27 20:00 +0200
    Re: SANE default scanner Siard <shiems@mailbox.org> - 2020-07-27 19:40 +0200
    Re: SANE default scanner George Shuklin <george.shuklin@gmail.com> - 2020-08-07 17:20 +0200
      Re: SANE default scanner Nicolas George <george@nsup.org> - 2020-08-07 17:30 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#225359

>> That's the kind of reason why I don't like using printer's own network
>> facilities and prefer to connect them over USB to a local GNU/Linux
>> server which can then share them over CUPS&SANE.
> There will be no computer close enough to the printer to do the job.

Indeed, it's not always a convenient option.
For me, the BananaPi homeserver was within reach of a USB cable, so it
was a no-brainer.

> And if you are suggesting I should buy a device, even an inexpensive

Definitely not.  The ecological impact of a new device dwarfs any of the
potential benefits.

>> It also has the side benefit that sleeping while connected via USB tends
>> to consume significantly less power than sleeping while connected via the
>> wifi network (can't remember what the numbers look like for ethernet).
>> The difference can be sufficient to power a BananaPi ;-)
> Have you considered turning the printer off and disconnecting it from
> the power mains with an external switch?

I could live with it, yes, but my wife expects the printer to "just
work", so it has to pretend it's always on.

> Well, in between explaining why all the answers I got do not match the
> question, I RTFS, and it seems indeed it is not possible with SANE.

It's definitely possible with SANE.  But apparently not with `hpaio`.

> What stupid design.

Yeah, I wish they'd just used SANE instead of inventing their own wheel.

> As for the hpaio backend, it relies on CUPS to find networked printers,
> but CUPS will not be always running. What stupid design.

At least they do use CUPS instead of reinventing yet another wheel.


        Stefan

[toc] | [prev] | [next] | [standalone]

#225362

>> > Well, in between explaining why all the answers I got do not match the
>> > question, I RTFS, and it seems indeed it is not possible with SANE.
>> It's definitely possible with SANE.  But apparently not with `hpaio`.
> libsane-hpaio is a backend that conforms to the SANE standard.

On one end, yes.  On the other end it talks the HPAIO "standard".

I was talking about the network protocol.  Apparently his scanner is not
connected to a `saned` daemon (that would talk the SANE protocol) but
talks an HPAIO-specific protocol instead.
Discovery is hence not performed by SANE but by the `libsane-hpaio`
backend itself.

IOW he wants/needs to use `libsane-hpaio` on the client rather than on
the server.


        Stefan

[toc] | [prev] | [next] | [standalone]

#225368

On Mon 27 Jul 2020 at 12:39:11 -0400, Stefan Monnier wrote:

> >> > Well, in between explaining why all the answers I got do not match the
> >> > question, I RTFS, and it seems indeed it is not possible with SANE.
> >> It's definitely possible with SANE.  But apparently not with `hpaio`.
> > libsane-hpaio is a backend that conforms to the SANE standard.
> 
> On one end, yes.  On the other end it talks the HPAIO "standard".
> 
> I was talking about the network protocol.  Apparently his scanner is not
> connected to a `saned` daemon (that would talk the SANE protocol) but
> talks an HPAIO-specific protocol instead.

Nicolas George appears to have ruled out using saned on a server. There
isn't a protocol specific to libsane-hpaio, not unless you are thinking
of DNS-SD/mDNS, which are standard protocols.

> Discovery is hence not performed by SANE but by the `libsane-hpaio`
> backend itself.

Ok; I'll go with that.

> IOW he wants/needs to use `libsane-hpaio` on the client rather than on
> the server.

Indeed.

We have now briefly discussed the only two techniques possible to
achieve Nicolas George's objective.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#225363

[Multipart message — attachments visible in raw view] — view raw

Stefan Monnier (12020-07-27):
> It's definitely possible with SANE.  But apparently not with `hpaio`.

I insist: it is not possible with SANE to specify a list of extra
scanners.

And since SANE lies between applications and back-ends, it is the
correct place to implement it.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#225389

>> It's definitely possible with SANE.  But apparently not with `hpaio`.
> I insist: it is not possible with SANE to specify a list of extra
> scanners.

Indeed.  And given SANE's design, there shouldn't be much need for it:
it assumes that either the scanner is local (via a hardware-specific
driver, hpaio being one of them) or it's remotely accessed over the SANE
protocol, in which case it uses the DNS-SD protocol to find it.

The problem is with scanner that are remote but using a "local driver"
(local to the client rather than local to the scanner).

I suggest you open a feature request on the SANE's issue tracker.
Who knows, maybe this can even be solved already by somehow tweaking the
DNS server to advertize your hpaio device?


        Stefan

[toc] | [prev] | [next] | [standalone]

#225396

[Multipart message — attachments visible in raw view] — view raw

Stefan Monnier (12020-07-27):
> Indeed.  And given SANE's design, there shouldn't be much need for it:
> it assumes that either the scanner is local (via a hardware-specific
> driver, hpaio being one of them) or it's remotely accessed over the SANE
> protocol, in which case it uses the DNS-SD protocol to find it.
> 
> The problem is with scanner that are remote but using a "local driver"
> (local to the client rather than local to the scanner).

This is a sadly classic pattern in Libre software: "not my problem, it's
the other project doing it wrong".

Sorry guys, you're BOTH doing it wrong:

hpaio, you should not rely on a print server to detect scanners, even if
you're made by a company that first came to this business through
printers.

SANE, since you accept third-party back-ends, you should assume some
will get it wrong and have workarounds ready.

> I suggest you open a feature request on the SANE's issue tracker.

Already did. And to hplip too.

> Who knows, maybe this can even be solved already by somehow tweaking the
> DNS server to advertize your hpaio device?

No, it can't, that's pretty obvious looking at the source code:

- The only way to have SANE-using applications see the scanner is that
  hpaio detects it.

- The only way to have hpaio detect the scanner is to have CUPS running,
  the corresponding printer configured and hpaio allowed to connect to
  it.

Both these points are design mistakes.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#225398

Nicolas George [2020-07-27 23:49:59] wrote:
> Stefan Monnier (12020-07-27):
>> Indeed.  And given SANE's design, there shouldn't be much need for it:
>> it assumes that either the scanner is local (via a hardware-specific
>> driver, hpaio being one of them) or it's remotely accessed over the SANE
>> protocol, in which case it uses the DNS-SD protocol to find it.
>> 
>> The problem is with scanner that are remote but using a "local driver"
>> (local to the client rather than local to the scanner).
>
> This is a sadly classic pattern in Libre software: "not my problem, it's
> the other project doing it wrong".

I'm not sure where you found assignment of blame in what I wrote.

> - The only way to have SANE-using applications see the scanner is that
>   hpaio detects it.

Apparently not 100% so since it works if you provide the URI explicitly.

> Both these points are design mistakes.

I can't see any reason why your request can't be satisfied by a fairly
simple change to the code (e.g. to read extra URIs from a local
configuration file in the client; better would be to be able to read
this info from something like the DNS), with no need for any kind of
redesign.  So it seems like a simple missing feature.
I haven't looked enough at the code to be sure this can be done easily,
but if it can then it shows it's not a design problem.  Just yet another
missing feature.


        Stefan

[toc] | [prev] | [next] | [standalone]

#225418

[Multipart message — attachments visible in raw view] — view raw

Stefan Monnier (12020-07-27):
> >> The problem is with scanner that are

> I'm not sure where you found assignment of blame in what I wrote.

"The problem is" is an assignment of technical blame.

> Apparently not 100% so since it works if you provide the URI explicitly.

Most applications do not allow to specify an arbitrary scanner URL.

> I can't see any reason why your request can't be satisfied by a fairly
> simple change to the code (e.g. to read extra URIs from a local
> configuration file in the client; better would be to be able to read
> this info from something like the DNS), with no need for any kind of
> redesign.  So it seems like a simple missing feature.
> I haven't looked enough at the code to be sure this can be done easily,
> but if it can then it shows it's not a design problem.  Just yet another
> missing feature.

The fact that this option did not exist first and before probing is what
I call a design mistake.

And the fact that hpaio relies on CUPS is inexcusable.

There is no doubt it can be done. I just doubt it will.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#225422

>> >> The problem is with scanner that are
>> I'm not sure where you found assignment of blame in what I wrote.
> "The problem is" is an assignment of technical blame.

I was just pointing out in which circumstances the problem appears.
No blame was meant and when I reread it I don't see blame being
assigned either.

>> Apparently not 100% so since it works if you provide the URI explicitly.
> Most applications do not allow to specify an arbitrary scanner URL.

The fact that you sometimes can, seems a clear indication that the
underlying design still makes it possible: you just need a bit of code
somewhere in SANE so you can specify this URL in a more central place
than on the command line.  IOW, a trivial new feature.

> The fact that this option did not exist first and before probing is what
> I call a design mistake.

You're free to do so, but usually "design mistake" refers to a problem
whose consequences can only be addressed properly by a redesign, which
implies a significant rework of the code.

> And the fact that hpaio relies on CUPS is inexcusable.

I don't see why: first, AFAICT it is still fully functional without
CUPS, and the fact that it tries to make use of CUPS's config
information in order to overcome specifically the problem you're in is
not dangerous.  It's kind of hackish but I can't see any situation where
it would harm any(think|one), so I'm not sure why you'd find
it inexcusable.

> There is no doubt it can be done. I just doubt it will.

Maybe if you write a patch and submit it along with your
bug-report/feature-request there's more chance it will?
And if you can't do it yourself, why not pay someone to do it for you?

Also, maybe if you stop accusing people of incompetence or gross
negligence (which is what "inexcusable" and "design mistake" evokes for
me), they'll be more accommodating?



        Stefan

[toc] | [prev] | [next] | [standalone]

#225429

On Tue 28 Jul 2020 at 09:56:20 -0400, Stefan Monnier wrote:

> > And the fact that hpaio relies on CUPS is inexcusable.
> 
> I don't see why: first, AFAICT it is still fully functional without
> CUPS, and the fact that it tries to make use of CUPS's config
> information in order to overcome specifically the problem you're in is
> not dangerous.  It's kind of hackish but I can't see any situation where
> it would harm any(think|one), so I'm not sure why you'd find
> it inexcusable.

There are two ideas expressed here:

1. ... first, AFAICT it is still fully functional without  CUPS ...

   That's quite correct and has been clearly demonstrated to be the case.

     https://lists.debian.org/debian-user/2020/07/msg01200.html

   Any idea that libsane-hpaio relies on CUPS is without any basis.

2. ... the fact that it tries to make use of CUPS's config information
   in order to overcome specifically the problem you're in is not
   dangerous.

   libsane-hpaio does not use or attempt use any aspect of CUPS' config.
   It has nothing to overcome. If we were to explore what the HPLIP
   hp-setup and hp-makeurl utilities do when CUPS is on the system, we
   could have a different conversation. But that has nothing to do with
   libsane-hpaio.

> > There is no doubt it can be done. I just doubt it will.
> 
> Maybe if you write a patch and submit it along with your
> bug-report/feature-request there's more chance it will?
> And if you can't do it yourself, why not pay someone to do it for you?

Dream on. The submitted bogus bug reports are where we end. Nicolas
George will hopefully eventually cotton on.
 
> Also, maybe if you stop accusing people of incompetence or gross
> negligence (which is what "inexcusable" and "design mistake" evokes for
> me), they'll be more accommodating?

You are asking a leopard to change its spots.

-- 
brian.

[toc] | [prev] | [next] | [standalone]

#225471

[Multipart message — attachments visible in raw view] — view raw

Stefan Monnier (12020-07-28):
> The fact that you sometimes can, seems a clear indication that the
> underlying design still makes it possible: you just need a bit of code
> somewhere in SANE so you can specify this URL in a more central place
> than on the command line.  IOW, a trivial new feature.

> You're free to do so, but usually "design mistake" refers to a problem
> whose consequences can only be addressed properly by a redesign, which
> implies a significant rework of the code.

"Significant" is a subjective threshold. Probing is less reliable than
configuration: relying on probing first is a mistake. Call it design or
not if you will.

> I don't see why: first, AFAICT it is still fully functional without
> CUPS,

Not for GUI applications that do not let set an arbitrary URL.

> Maybe if you write a patch and submit it along with your
> bug-report/feature-request there's more chance it will?

It completely depends on the mindset of the project, I am waiting to get
a feel of it. Some projects have a patch welcome attitude, some do not.
More importantly, some project have the attitude "I do not need this,
but if you think you do, and your patch is clean and does not make the
rest of the code more complex, then ok", while others have the attitude
"I do not need this, therefore nobody does" and would reject the patch.

If the patch is to be rejected, or just ignored, then my time would be
better invested in an external work-around, it would be less effort than
forking, and more convenient.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#225475

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jul 29, 2020 at 11:11:22AM +0200, Nicolas George wrote:
> Stefan Monnier (12020-07-28):
> > The fact that you sometimes can, seems a clear indication that the
> > underlying design still makes it possible [...]

> "Significant" is a subjective threshold. Probing is less reliable than
> configuration: relying on probing first is a mistake. Call it design or
> not if you will.

i.e. "explicit is better than implicit"

> It completely depends on the mindset of the project, I am waiting to get
> a feel of it. Some projects have a patch welcome attitude, some do not.
> More importantly, some project have the attitude "I do not need this,
> but if you think you do, and your patch is clean and does not make the
> rest of the code more complex, then ok", while others have the attitude
> "I do not need this, therefore nobody does" and would reject the patch.

Quite long-winded way to say "would they accept my patch?" ;-)

> If the patch is to be rejected, or just ignored, then my time would be
> better invested in an external work-around, it would be less effort than
> forking, and more convenient.

I'd just ask them. I.e. explicit is better than implicit.

If you need a second pair of eyes to look over your patch, I'm ready. I
can read C.

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#225503

On Wed 29 Jul 2020 at 12:07:08 +0200, tomas@tuxteam.de wrote:

> On Wed, Jul 29, 2020 at 11:11:22AM +0200, Nicolas George wrote:
> 
> > If the patch is to be rejected, or just ignored, then my time would be
> > better invested in an external work-around, it would be less effort than
> > forking, and more convenient.
> 
> I'd just ask them. I.e. explicit is better than implicit.
> 
> If you need a second pair of eyes to look over your patch, I'm ready. I
> can read C.

Reviewing a patch for a non-extisting bug? That's above and beyond the
call of duty :).

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#225504

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jul 29, 2020 at 07:28:21PM +0100, Brian wrote:
> On Wed 29 Jul 2020 at 12:07:08 +0200, tomas@tuxteam.de wrote:

> > [...] can read C.
> 
> Reviewing a patch for a non-extisting bug? That's above and beyond the
> call of duty :).

Always glad to please ;-P

Perhaps I should temper my offer. By "reading C" I wasn't including
things like this [1]... or that [2].

Cheers
[1] https://www.ioccc.org/2019/dogon/prog.c
[2] https://www.ioccc.org/2018/bellard/prog.c
-- t

[toc] | [prev] | [next] | [standalone]

#225408

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jul 27, 2020 at 11:49:59PM +0200, Nicolas George wrote:

[...]

> This is a sadly classic pattern in Libre software: "not my problem, it's
> the other project doing it wrong".

...and of all the rest of humanity, too.

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#225364

On Mon 27 Jul 2020 at 12:05:15 -0400, Stefan Monnier wrote:

> 
> > Well, in between explaining why all the answers I got do not match the
> > question, I RTFS, and it seems indeed it is not possible with SANE.
> 
> It's definitely possible with SANE.  But apparently not with `hpaio`.

libsane-hpaio is a backend that conforms to the SANE standard. In what
way is it different from, say, libsane-pixma?

> > What stupid design.
> 
> Yeah, I wish they'd just used SANE instead of inventing their own wheel.
> 
> > As for the hpaio backend, it relies on CUPS to find networked printers,
> > but CUPS will not be always running. What stupid design.
> 
> At least they do use CUPS instead of reinventing yet another wheel.

libsane-hpaio needs CUPS to deal with scanners? Imagination is a great
asset. Sometimes!

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#225365

[Multipart message — attachments visible in raw view] — view raw

Brian (12020-07-27):
> libsane-hpaio needs CUPS to deal with scanners? Imagination is a great
> asset. Sometimes!

If you do not believe me, just RTFS or use ldd and nm to check.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#225366

On Mon 27 Jul 2020 at 18:39:45 +0200, Nicolas George wrote:

> Brian (12020-07-27):
> > libsane-hpaio needs CUPS to deal with scanners? Imagination is a great
> > asset. Sometimes!
> 
> If you do not believe me, just RTFS or use ldd and nm to check.

Ok, libsane-hpaio requires libcups.so.2. That's nowhere near requiring
CUPS, in particular cups-daemon. The printing system is not involved
with scanning.

-- 
Brian

[toc] | [prev] | [next] | [standalone]

#225367

[Multipart message — attachments visible in raw view] — view raw

Brian (12020-07-27):
> Ok, libsane-hpaio requires libcups.so.2. That's nowhere near requiring
> CUPS, in particular cups-daemon. The printing system is not involved
> with scanning.

This is the last time I grace you with a reply. As I have told you twice
now, unlike you, I have read the source code and I know what I am
talking about. Here are the excerpts:

    /* Look for Network Scan devices if localonly flag if FALSE. */
    if (!localOnly)
    {
        /* Look for all-in-one scan devices for which print queue created */
        cnt = GetCupsPrinters(&cups_printer);
        for (i=0; i<cnt; i++)
        {
            total += AddDevice(cups_printer[i]);
            free(cups_printer[i]);
        }

and:

static int GetCupsPrinters(char ***printer)
{
   http_t *http=NULL;     /* HTTP object */
   ipp_t *request=NULL;  /* IPP request object */
   ipp_t *response=NULL; /* IPP response object */
   ipp_attribute_t *attr;     /* Current IPP attribute */
   int cnt=0;

   /* Connect to the HTTP server */
   if ((http = httpConnectEncrypt(cupsServer(), ippPort(), cupsEncryption())) == NULL)
      goto bugout;

   /* Assemble the IPP request */
   request = ippNew();

   ippSetOperation( request, CUPS_GET_PRINTERS );
   ippSetRequestId( request, 1 );

   ippAddString(request, IPP_TAG_OPERATION, IPP_TAG_CHARSET, "attributes-charset", NULL, "utf-8");
   ippAddString(request, IPP_TAG_OPERATION, IPP_TAG_LANGUAGE, "attributes-natural-language", NULL, "en");
   ippAddString(request, IPP_TAG_OPERATION, IPP_TAG_KEYWORD, "requested-attributes", NULL, "device-uri");

   /* Send the request and get a response. */
   if ((response = cupsDoRequest(http, request, "/")) == NULL)
      goto bugout;

   for (attr = ippFirstAttribute ( response ); attr != NULL; attr = ippNextAttribute( response ))
   {
      /* Skip leading attributes until we hit a printer. */
      while (attr != NULL && ippGetGroupTag( attr ) != IPP_TAG_PRINTER)
         attr = ippNextAttribute( response );

      if (attr == NULL)
         break;

      while (attr != NULL && ippGetGroupTag( attr ) == IPP_TAG_PRINTER)
      {
         if (strcmp(ippGetName( attr ), "device-uri") == 0 && ippGetValueTag( attr ) == IPP_TAG_URI && AddCupsList(ippGetString( attr, 0, NULL ), printer) == 0)
            cnt++;
         attr = ippNextAttribute( response );
      }

      if (attr == NULL)
         break;
   }

   ippDelete(response);

 bugout:
   return cnt;
}

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#225373

On Mon 27 Jul 2020 at 19:12:10 +0200, Nicolas George wrote:

> Brian (12020-07-27):
> > Ok, libsane-hpaio requires libcups.so.2. That's nowhere near requiring
> > CUPS, in particular cups-daemon. The printing system is not involved
> > with scanning.
> 
> This is the last time I grace you with a reply. As I have told you twice

I don't usually triumph so quickly in a discussion. :)

> now, unlike you, I have read the source code and I know what I am
> talking about. Here are the excerpts:

You are quite right - I have not read any source code; I'm illiterate!
However, I do have four scanners available over the network so must be
doing something right.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web