- Status Closed
- Percent Complete
- Task Type Bug Report
- Category Shinko CHC-S2145
-
Assigned To
pizza - Operating System All
- Severity High
- Priority Very Low
- Reported Version 1.0
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
Attached to Project: Gutenprint / CUPS Dye-sublimation drivers
Opened by pizza - 2013-07-08
Last edited by pizza - 2013-07-16
Opened by pizza - 2013-07-08
Last edited by pizza - 2013-07-16
FS#476 - s2145 hangs on subsequent requests
The first request succeeds, but subsequent requests hang when trying to talk to the printer.
I suspect what's going on here is that the response buffers we're posting are simply too small and the printer loses its mind.
Closed by pizza
2013-07-16 22:30
Reason for closing: Fixed
Additional comments about closing: Committed to git, will mirror to gutenprint shortly. Went ahead and did this to all backends.
2013-07-16 22:30
Reason for closing: Fixed
Additional comments about closing: Committed to git, will mirror to gutenprint shortly. Went ahead and did this to all backends.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
Response buffers increased to 128 bytes, well above the necessary size. Also, libusb returns an error when the response buffer is too small.
Unfortunately, this didn't do anything to fix this problem. More investigation is necessary; perhaps some more sniffing of what the windows drivers use?
Further details:
Multiple requests back-to-back succeed. Next program invocation, the first two requests fail. Every subsequent request succeeds.
The problem is due to re-attaching it to the kernel printer driver. Just disable this entirely.