Re: Raspberry Pi 3B USB Printing Issue
- Reply: Archimedes Gaviola : "Re: Raspberry Pi 3B USB Printing Issue"
- In reply to: Hans Petter Selasky : "Re: Raspberry Pi 3B USB Printing Issue"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 27 Mar 2022 14:28:07 UTC
On Sun, Mar 27, 2022 at 5:05 PM Hans Petter Selasky <hps@selasky.org> wrote: > On 3/27/22 07:55, Archimedes Gaviola wrote: > > On Sat, Mar 12, 2022 at 4:41 PM Hans Petter Selasky <hps@selasky.org> > wrote: > > > >> On 3/12/22 08:07, Archimedes Gaviola wrote: > >>> ugen1.5: <EPSON EPSON UB-U03II> at usbus1 > >>> ulpt1 on uhub1 > >>> ulpt1: <EPSON EPSON UB-U03II, class 0/0, rev 1.10/2.00, addr 5> on > usbus1 > >>> device_attach: ulpt1 attach returned 12 > >> > >> 12 : man errno : > >> 12 ENOMEM Cannot allocate memory. > >> > >> I guess the EPSON printer you've got is not compatible with ulpt<n> > >> > >> When printing, can you make sure that the length transferred is never a > >> multiple of 64 bytes? > >> > >> Also, there might be a bug lurking in the USB host controller driver, > >> like already mentioned. > >> > > > > > > Hi Hans, > > > > I just figured-out the ulpt(4) driver in my Epson printer while comparing > > with my Xprinter printer's USB device info. My Epson printer is providing > > vendor specific values of 255 in the bInterfaceClass and > bInterfaceSubClass > > respectively. > > > > bInterfaceClass = 0x00ff <Vendor specific> > > bInterfaceSubClass = 0x00ff > > > > It should be a value of 7 for bInterfaceClass and a value of 1 in > > bInterfaceSubClass. > > > > bInterfaceClass = 0x0007 <Printer device> > > bInterfaceSubClass = 0x0001 > > > > So, the ulpt_attach() routine below will break upon validation for > > mismatched values in UICLASS_PRINTER and UISUBCLASS_PRINTER. > > > > } else { > > alt_index++; > > if ((id->bInterfaceClass == > > UICLASS_PRINTER) && > > (id->bInterfaceSubClass == > > UISUBCLASS_PRINTER) && > > (id->bInterfaceProtocol == > > UIPROTO_PRINTER_BI)) { > > goto found; > > } > > } > > > > What I did is temporarily replace these values in the USB definition. In > > this case, how should the project handle this non-compliance USB devices? > > Though I will raise this to Epson if they could provide an updated > firmware. > > > > freebsd@generic:~ % diff -Nur /usr/src/sys/dev/usb/usb.h.orig > > /usr/src/sys/dev/usb/usb.h > > --- /usr/src/sys/dev/usb/usb.h.orig 2022-03-27 02:55:01.319235000 > +0800 > > +++ /usr/src/sys/dev/usb/usb.h 2022-03-27 02:57:10.608518000 +0800 > > @@ -459,8 +459,10 @@ > > #define UICLASS_PHYSICAL 0x05 > > #define UICLASS_IMAGE 0x06 > > #define UISUBCLASS_SIC 1 /* still image class */ > > -#define UICLASS_PRINTER 0x07 > > -#define UISUBCLASS_PRINTER 1 > > +/* #define UICLASS_PRINTER 0x07 */ > > +/* #define UISUBCLASS_PRINTER 1 */ > > +#define UICLASS_PRINTER 0xff > > +#define UISUBCLASS_PRINTER 0xff > > > > I can print now with ulpt(4) driver but need further testing for any > issues. > > > > ugen1.5: <EPSON EPSON UB-U03II> at usbus1 > > ulpt0 on uhub1 > > ulpt0: <EPSON EPSON UB-U03II, class 0/0, rev 1.10/2.00, addr 5> on usbus1 > > ulpt_attach: setting alternate config number: 0 > > ulpt0: using bi-directional mode > > > > Hi, > > I think you can just extend that piece of code to accept either value > using a boolean OR, ||. > Hi Hans, Ah okay, this is noted. I just thought it's not allowed. I already extended the code and on the way re-building the kernel. Thanks, Archimedes