Ubuntu
linux package

QinHeng CH340S (LogiLink) USB->Parallel adapter printer status failure

Bug #1156210 reported by Henrik Haftmann
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Expired
Medium
Unassigned

Bug Description

This seems to be a failing driver problem.

Doing (C):
 unsigned char r;
 int hIO = open("/dev/usb/lp0",O_RDWR|O_NONBLOCK); // O_NONBLOCK doesn't influence behaviour either
 ioctl(hIO,PPRSTATUS,&r); // in a more-or-less tight loop

I wouldn't get the right state for the three available status bits of a USB to parallel converter.

It seems that these bits are delayed, but even when I sleep(1) before ioctl(), these bits are sometimes wrong.
The same code works perfectly on a true parallel port (/deb/lp0).
Notably, the data output {ioctl(hIO,PPWDATA,&wert)} works as expected.

However, the Windows version works fine on the same machine and the same converter, on any Windows and any bitness, with a quite similar method:

 unsigned char r;
OVERLAPPED o;
 HANDLE hIO = OpenUsbPrn(PPort,FILE_FLAG_OVERLAPPED); // complicated subroutine, see line 343 of:
// www-user.tu-chemnitz.de/~heha/viewzip.cgi/bastelecke/Rund um den PC/EPROM-Simulator/PEPS-III/peps4win32.zip/src/sendiii.c?auton=C
 DeviceIoControl(hIO,IOCTL_USBPRINT_GET_LPT_STATUS,NULL,0,&r,1,&br,&o)

everything works fine.

SUMMARY:

Release of Ubuntu:
Sorrily, the version of Ubuntu is not available. Same behaviour on i32 and amd64 platforms.

Expected behaviour:
ioctl(hIO,PPRSTATUS,&r) should return the state of three (of five) LPT lines, after some blocking (upto 1 ms) doing the frame-based USB control (Endpoint0) transfer.

What happens:
This call seems to block too long (not measured), and returns wrong bits to r.
Even when I sleep() before this call, wrong bit values are returned.

Tags: bot-comment
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1156210/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
Fabio Marconi (fabiomarconi)
affects: ubuntu → cups (Ubuntu)
Revision history for this message
Henrik Haftmann (heha-v) wrote :

My first bug report was erraneous because I figured out now that this bug is hardware-dependent, a bit hard to track, and will occur on Windows too.

The USB->ParallelPrinter adapter "LogiLink", sold by Reichelt Elektronik (www.reichelt.de), chip marking: "WCH CH340S" (VID==1A86, PID==7584) has a serious built-in silicon (firmware) bug:

If write() is followed by ioctl(…PPRSTATUS…), the write() data will not put out at all!

It seems that ioctl() must be in the /next/ USB frame, otherwise, data of a non-full USB packet are lost.

This is important for printing! Because status-checking may eat up some printing data. The driver behind /dev/usb/lpX should add a small (1 ms) delay between sending data and receiving status, if VID&PID pair as above were found. Or reject loading itself, emit a serious warning, etc.

In my case, because I use this adapter as an LPT port replacement with this hardware:
http://www-user.tu-chemnitz.de/~heha/viewzip.cgi/hs_freeware/DLO_UsbPrn.zip/DLO_UsbPrn.png?bin=PNG
I can simply send full USB packets (64 bytes) instead.
I couldn't measure any performance impact, for sending 64 bytes instead of 1.
Of-course, this cannot be done for printing, but it's fully okay for the '574 latch in the schematic.

The Prolific PL-2305H (VID==06A9, PID==1991) doesn't have this bug.

henni

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Another user has run into problems with this adapter, too, but he used it only through the USB backend which is part of CUPS. See bug 1000253, comment #93 and following comments. It is there identified as the QinHeng CH340S. We have applied a workaround (available from Raring/13.04 on) in the CUPS backend to make the adapter work with CUPS.

The problem you are reporting is not a CUPS bug, as by directly talking to /dev/usb/lp0 from a C program you do not use CUPS. /dev/usb/lp0 is provided by the "usblp" kernel module (which is not used by CUPS). A workaround for the bug in your hardware which helps in your situation can therefore only be applied in the kernel. Therefore I move this bug to the kernel ("linux" source package).

affects: cups (Ubuntu) → linux (Ubuntu)
Till Kamppeter (till-kamppeter)
summary: - usb->parallel_printer status failure
+ QinHeng CH340S (LogiLink) USB->Parallel adapter printer status failure
Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1156210

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Joseph Salisbury (jsalisbury)
Changed in linux (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.