Hi,

thank you for reporting the issue!

Would you mind upgrading to the latest sane-backends version (sane-backends-1.0.32-2), following steps here [1] and attaching the created file here as an attachment?

You device should be supported by epson or epson2 backends, so your environment variables for backends will be:

SANE_DEBUG_EPSON=255 SANE_DEBUG_EPSON2=255

and please turn on debugging SANE for your connection method too - how to is described in the link.

Thank you in advance!


[1] https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_debug_scanning_issues

Created attachment 1760357 [details]
not sure i do what you  want

I'm not very comfortable with this kind of procedure it's the first time for me I'm willing to collaborate but you'll have to explain me more precisely

(In reply to spavas from comment #2)
> Created attachment 1760357 [details]
> not sure i do what you  want

If you are not sure, then it is good to provide the text you wrote into command line which led into getting those logs.

Would you mind telling me the exact command did you use for creating the logs?

> 
> I'm not very comfortable with this kind of procedure it's the first time for
> me I'm willing to collaborate but you'll have to explain me more precisely

The link I shared with you should do the explanation and should tell you what to do generally - please tell me if something there is unclear to you and how you would rephrase it.

The wiki under the link is managed by myself to spare me some time when communicating with users and I want to make it understandable for everyone, so a feedback is welcomed.

the command
gil $ ~ :   scanimage -L
device `v4l:/dev/video0' is a Noname UVC Camera (046d:081b) virtual device
device `epson2:libusb:002:009' is a Epson GT-8200 flatbed scanner 


gil $ ~ :   SANE_DEBUG_DLL=255 SANE_DEBUG_EPSON=255 SANE_DEBUG_EPSON2_TCP=255 xsane &> debug_log

iread your explanation calmly and i choose this command among all that is proposed but I am not sure of me
that's all

(In reply to spavas from comment #4)
> the command
> gil $ ~ :   scanimage -L
> device `v4l:/dev/video0' is a Noname UVC Camera (046d:081b) virtual device
> device `epson2:libusb:002:009' is a Epson GT-8200 flatbed scanner 

Ok, you missed the point about scanner discovery and did the command for getting uri - did you just missed that or what gave you an idea to skip it?

I moved the 'getting scanner uri' paragraph further down in the wiki, hope it helps to make it more understandable.

> 
> 
> gil $ ~ :   SANE_DEBUG_DLL=255 SANE_DEBUG_EPSON=255
> SANE_DEBUG_EPSON2_TCP=255 xsane &> debug_log

Thank you! It is almost correct - you combined debugging EPSON2 backend (SANE_DEBUG_EPSON2=255) with connection debugging (SANE_DEBUG_SANEI_TCP=255) and you used a bad connection debugging, since your scanner is connected by USB (as you can see from 'scanimage -L').

The difference between connections are described in the initial paragraph of 'How to debug scanning issues' - would you mind telling me what suggested you to use an environment variable for network connections, but your device is connected via USB?

The similar situation for combining SANE_DEBUG_EPSON2 (which I mentioned in initial comment) and connection debugging.

Would you mind helping me out here? Right now I have no idea how to prevent this situation in wiki. What should I change in the wiki to make it more understandable in that matter?

So the command the wiki and my comment supposed to lead you was (for scanner discovery):

$ SANE_DEBUG_DLL=255 SANE_DEBUG_EPSON=255 SANE_DEBUG_EPSON2=255 SANE_DEBUG_SANEI_USB=255 scanimage -L &> debug_log

> gil $ ~ :   scanimage -L
> device `v4l:/dev/video0' is a Noname UVC Camera (046d:081b) virtual device
> device `epson2:libusb:002:009' is a Epson GT-8200 flatbed scanner 

Ok, so your scanner is recognized, but under its US name.

Does the scanning work for 'Epson GT-8200 flatbed scanner' in your case? In your original report you said you have a problem with scanner discovery, but you never said if the scanning works for 'Epson GT-8200 flatbed scanner', so that's why I'm asking.

Thank you in advance!

Created attachment 1760373 [details]
debug_log

It's my fault I wasn't attentive enough and I flew over this initial paragraph, and discovery_output misled me I think that as in the command you gave me it would be better to stay consistent and use debug_log, unless I misunderstand it again.

And make it clear that SANE_DEBUG_SANEI is a command
I'm not very perceptive on this one and I thought that SANEI was a scanner brand. 

Putting USB in bold in "connected by USB and supported" would have made me pay more attention as well, sorry. 

But it's largely my fault I have poor English and I didn't translate the whole text.
No my scanner does not work with simple-scan or xsane I have 
the impossible error to start scanning with simple-scan and 
failed to start the scanner operation not supported with xsane.

Sorry for the loss of time that I cause.

Translated with www.DeepL.com/Translator (free version)

(In reply to spavas from comment #6)
> Created attachment 1760373 [details]
> debug_log
> 
> It's my fault I wasn't attentive enough and I flew over this initial
> paragraph, and discovery_output misled me I think that as in the command you
> gave me it would be better to stay consistent and use debug_log, unless I
> misunderstand it again.
> 
> And make it clear that SANE_DEBUG_SANEI is a command

This is a substring of SANE_DEBUG_SANEI_USB or SANE_DEBUG_SANEI_TCP environment variables. Then you pass the environment variable/-s into the command 'scanimage' (every command in the wiki is in yellow box and starts with command prompt - '#' or '$') like this:

$ SANE_DEBUG_DLL=255 SANE_DEBUG_EPSON2=255 SANE_DEBUG_SANEI_USB=255 scanimage -L

> I'm not very perceptive on this one and I thought that SANEI was a scanner
> brand.

SANEI means SANE Interface and the usage is suppose to be explained in the initial paragraph of 'How to debug scanning issues' among the common environment variables.

> 
> Putting USB in bold in "connected by USB and supported" would have made me
> pay more attention as well, sorry.

Applied, thanks for the suggestion!

> 
> But it's largely my fault I have poor English and I didn't translate the
> whole text.
> No my scanner does not work with simple-scan or xsane I have 
> the impossible error to start scanning with simple-scan and 
> failed to start the scanner operation not supported with xsane.

Thanks for the data! It confirms the discovery works.

Ok, so the device is discovered, but the scanning itself fails.

Would you mind following the steps for debugging scanning itself https://fedoraproject.org/wiki/How_to_debug_printing_problems#Debugging_scanning_process ?

Please try to figure out the command based on the link and the previous paragraphs in the section 'How to debug scanning issues'.
.
.
.
.
.
.
(just for the check, the wanted command is:)

$ SANE_DEBUG_DLL=255 SANE_DEBUG_EPSON=255 SANE_DEBUG_EPSON2=255 SANE_DEBUG_SANEI_USB=255 xsane &> debug_log


> 
> Sorry for the loss of time that I cause.
> 
> Translated with www.DeepL.com/Translator (free version)

Created attachment 1760382 [details]
failed to start the scanner operation not supported

xsane is launched I have the choice between my webcam and the scanner 
and if I scan while having chosen the scanner I have the error 
failed to start the scanner operation not supported

and the I close and I leave xsane

Thanks, that helps a lot!

The logs show it is the same issue as it is reported upstream as https://gitlab.com/sane-project/backends/-/issues/445 .

Scanning fails for you because the backend fails to set focus for your scanner. And that is because there is no focus setting function assigned to the device, because your model is on denylist regarding setting focus (not sure why), but a flag which indicates focus support is set...

I created a testing patch, which unsets the focus flag - would you mind testing if it helps?

The rpms are here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=62999417

Just get the rpm links (by clicking to each rpm by right mouse button and choose 'copy link location') and put it into dnf transaction, f.e.:

$ sudo dnf -y install https://kojipkgs.fedoraproject.org//work/tasks/9417/62999417/sane-backends-1.0.32-2.fc33.epson2_testing.x86_64.rpm ...

(the command isn't full, add more rpm links)

it works great with simple-scan and xsane, bravo you're a performer.
I downloaded
sane-backends-1.0.32-2.fc33.epson2_testing.x86_64.rpm
sane-backends-drivers-cameras-1.0.32-2.fc33.epson2_testing.x86_64.rpm
sane-backends-drivers-scanners-1.0.32-2.fc33.epson2_testing.x86_64.rpm
sane-backends-libs-1.0.32-2.fc33.epson2_testing.x86_64.rpm

and I did rpm -Uvh with all four packages at the same time
congratulations

Thank you for letting me know!

I mentioned the fix in the upstream issue, so let's see what the final patch will be.

*** Bug 1936634 has been marked as a duplicate of this bug. ***

Is POST really the right status for this bug?  Asking because the default search only finds NEW and ASSIGNED bugs.

Yes, it is. See https://bugzilla.redhat.com/page.cgi?id=fields.html#bug_status . The patch has been posted for review upstream.

(In reply to Ian Pilcher from comment #13)
> Asking because the default search only finds NEW and ASSIGNED bugs.

If you use an 'advanced search' in bugzilla, you can set 'all open' option in 'Status' field, which will give you even POST bugzillas. It has 'NEW' and 'ASSIGNED' statuses pre-filled as default (IMHO it is because they are the most common statuses), but that doesn't invalidate usage of POST status in the correct circumstances. IMHO advanced search counts on user knowing 'NEW' and 'ASSIGNED' aren't the only 'opened' ticket statuses, but the most common.

If you use the 'simple search' in bugzilla, you have 'open' status for search by default. It contains all 'opened' statuses (NEW, ASSIGNED, POST...).

FEDORA-2021-bb570b4758 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-bb570b4758

FEDORA-2021-3223b86d70 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3223b86d70

FEDORA-2021-340b2a604b has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2021-340b2a604b

FEDORA-2021-bb570b4758 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-bb570b4758`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-bb570b4758

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-3223b86d70 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-3223b86d70`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-3223b86d70

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-340b2a604b has been pushed to the Fedora 32 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-340b2a604b`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-340b2a604b

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-340b2a604b has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2021-bb570b4758 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2021-3223b86d70 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.