usb/113060: Samsung printer not working in bidirectional mode

[Hans Petter Selasky]

The following reply was made to PR usb/113060; it has been noted by GNATS.

From: Hans Petter Selasky <hselasky at freebsd.org>
To: freebsd-usb at freebsd.org
Cc: Ulrich Spoerlein <uspoerlein at gmail.com>,
 FreeBSD-gnats-submit at freebsd.org
Subject: Re: usb/113060: Samsung printer not working in bidirectional mode
Date: Sun, 27 May 2007 22:32:32 +0200

 On Sunday 27 May 2007 17:33, Ulrich Spoerlein wrote:
 > >Number:         113060
 > >Category:       usb
 > >Synopsis:       Samsung printer not working in bidirectional mode
 > >Confidential:   no
 > >Severity:       non-critical
 > >Priority:       low
 > >Responsible:    freebsd-usb
 > >State:          open
 > >Quarter:
 > >Keywords:
 > >Date-Required:
 > >Class:          sw-bug
 > >Submitter-Id:   current-users
 > >Arrival-Date:   Sun May 27 15:40:04 GMT 2007
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     Ulrich Sp=F6rlein
 > >Release:        FreeBSD 6.2-STABLE i386
 > >Organization:
 > >Environment:
 > >Description:
 >
 > The following printer, when attached via USB fails to work
 >
 > port 2 addr 2: full speed, self powered, config 1, SAMSUNG Laser Printer
 > ML-4600(0x3004), SAMSUNG ELECTRONICS CO., LT(0x04e8), rev 1.00
 >
 > Peter van Heusden identified the problem to be the bi-directional mode.
 > When adding the quirks as given below *OR* chmod a-w /dev/ulpt0 CUPS will
 > print just fine.
 >
 > Please note that under the new USB stack developed by Hans Petter Selasky
 > the printer works out of the box. This, and usb/112944 leave me to believe
 > it is a more general problem with bidirectional support under ulpt(4).
 >
 > Perhaps HPS can comment on the architectural differences between the old
 > and his new ulpt(4)?
 >
 > PS: Whitespace and sorting in usb_quirks.c are, well, interessting.
 >
 > >How-To-Repeat:
 > >Fix:
 >
 > --- ml4600.diff begins here ---
 > Index: usb_quirks.c
 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 > RCS file: /home/ncvs/src/sys/dev/usb/usb_quirks.c,v
 > retrieving revision 1.41.2.8
 > diff -u -p -r1.41.2.8 usb_quirks.c
 > --- usb_quirks.c	28 Apr 2007 20:31:30 -0000	1.41.2.8
 > +++ usb_quirks.c	27 May 2007 15:31:37 -0000
 > @@ -99,6 +99,7 @@ Static const struct usbd_quirk_entry {
 >   { USB_VENDOR_HP, USB_PRODUCT_HP_810C,		    ANY,   { UQ_BROKEN_BIDIR }},
 >   { USB_VENDOR_HP, USB_PRODUCT_HP_830C,		    ANY,   { UQ_BROKEN_BIDIR }},
 >   { USB_VENDOR_HP, USB_PRODUCT_HP_1220C,		    ANY,   { UQ_BROKEN_BIDIR }},
 > + { USB_VENDOR_SAMSUNG, USB_PRODUCT_SAMSUNG_ML4600,  ANY,   {
 > UQ_BROKEN_BIDIR }}, { USB_VENDOR_XEROX, USB_PRODUCT_XEROX_WCM15,	    ANY,=
  =20
 > { UQ_BROKEN_BIDIR }}, /* YAMAHA router's ucdDevice is the version of
 > farmware and often changes. */ { USB_VENDOR_YAMAHA,
 > USB_PRODUCT_YAMAHA_RTA54I,
 > Index: usbdevs
 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 > RCS file: /home/ncvs/src/sys/dev/usb/usbdevs,v
 > retrieving revision 1.232.2.24
 > diff -u -p -r1.232.2.24 usbdevs
 > --- usbdevs	20 May 2007 12:34:39 -0000	1.232.2.24
 > +++ usbdevs	27 May 2007 09:30:30 -0000
 > @@ -1491,6 +1491,7 @@ product RATOC REXUSB60		0xb000	REX-USB60
 >  product SAGEM USBSERIAL		0x0027	USB-Serial Controller
 >
 >  /* Samsung products */
 > +product SAMSUNG ML4600		0x3004	ML-4600 laser printer
 >  product SAMSUNG ML6060		0x3008	ML-6060 laser printer
 >
 >  /* SanDisk products */
 > --- ml4600.diff ends here ---
 >
 > >Release-Note:
 > >Audit-Trail:
 > >Unformatted:
 >
 
 Hi,
 
 The main difference between the old "ulpt" and the new "ulpt" is that the n=
 ew=20
 use asynchronous reading of data, while the old "ulpt" uses synchronous=20
 reading. That means that the new "ulpt" transfers data to/from all endpoint=
 s=20
 in the background.
 
 Maybe that has something to do with the problem, that the IN enpoint is not=
 =20
 polled.
 
 =2D-HPS