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