From nobody Sun Mar 27 14:28:07 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7B8B71A425BE for ; Sun, 27 Mar 2022 14:28:30 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KRJ8s39xDz4hQr for ; Sun, 27 Mar 2022 14:28:29 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: by mail-ej1-x62f.google.com with SMTP id bg10so23813046ejb.4 for ; Sun, 27 Mar 2022 07:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ddQlPRgr/BMqUvBOul3p1EcTsrcb9ptvwGner16XrEY=; b=iOTuTwQaDzCQFgbNf1ulJ3E3Dfd/bRkLp3mvpNKB1e+kb6pSxxf18615qHGGoh8MqR zPfE7E3oYMldIuLVfpQlZeiHUn9++ktoCo7s18fzCeHlaKXdNRINw6l6Vb99Rc+/gznl lOyUBzZ7VcVgoa5zw8+upvx4uc0J0c3/QaMY5uQqwqhnBlh0KzO4kFc6srObA2UIwEp3 4+dNI8mWY58atEPEkrf9uEtUF7Dp/a3F6PzTXWP8L7yxv5tDNX0f0vRVgT0LjtmNOb/5 aWdPcUacobFe1rX5BZK1Cx/3uyVvmh1sjHsSkI3A7tEu3VlXOS3nTzg33nsmoEYlZ8i/ 4Rdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ddQlPRgr/BMqUvBOul3p1EcTsrcb9ptvwGner16XrEY=; b=aEliO13CezYPOfI6Z6AMEwaNLSSodLd7BVWUJ16NlmpmFXmVfpI/+0qyKS/zMRM35S pvth/zY2gZPQpcMk8X3ocwksk0xwnqpnvnMlqVQWs3Q4Pe/jVOPpmr+q27an7061ZwT8 iPIG11USjIyty4qgFlLjOUrJ6esFhphWsNrilH88OhvXrqPM9XGSl+nx+S02UAcIMsX5 4NaX8GCJNSAapqtEfH+Qhb37cMrZuy+Abmpt2wmwdNRhRNFiWsCDnTsuFq/fhSSe8Ocn cQtYo9hTIp29g0nWwgNKmIoM3Rnprw3MUaFrB+T0QHiXGZWDeZpUZdPS3GgSlrxdISqE IdHQ== X-Gm-Message-State: AOAM533ov0F4ltZwTQwt0BIAZvOeqBRR086lqe0Tky8uuIebWC+gLKhz NclqfciwhkpMpPEIJeKM0RtGT1VsF+E1jdxoUYwsWTTH X-Google-Smtp-Source: ABdhPJwm9/XOuEAhUXkaTAIkwEolIqtgKF8LvDpakROiXR4ev68XNFkA38ryWXpxsmzkHKuzr+zY889KUAtlUFE0wxA= X-Received: by 2002:a17:906:7304:b0:6e0:6918:ef6f with SMTP id di4-20020a170906730400b006e06918ef6fmr22046288ejc.370.1648391307524; Sun, 27 Mar 2022 07:28:27 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <7c67118e-f6ec-c87d-9a81-3ee6a5952f49@selasky.org> <60f98b10-dcdc-cdf4-3d7a-fe9fd4dff223@selasky.org> <8226461b-5740-9c19-0575-2740bd952e16@selasky.org> <5fcece51-b014-330e-b701-fd75fa1ac204@selasky.org> In-Reply-To: From: Archimedes Gaviola Date: Sun, 27 Mar 2022 22:28:07 +0800 Message-ID: Subject: Re: Raspberry Pi 3B USB Printing Issue To: Hans Petter Selasky Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="00000000000055ff3005db3402bb" X-Rspamd-Queue-Id: 4KRJ8s39xDz4hQr X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=iOTuTwQa; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of archimedesgaviola@gmail.com designates 2a00:1450:4864:20::62f as permitted sender) smtp.mailfrom=archimedesgaviola@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[0.996]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --00000000000055ff3005db3402bb Content-Type: text/plain; charset="UTF-8" On Sun, Mar 27, 2022 at 5:05 PM Hans Petter Selasky wrote: > On 3/27/22 07:55, Archimedes Gaviola wrote: > > On Sat, Mar 12, 2022 at 4:41 PM Hans Petter Selasky > wrote: > > > >> On 3/12/22 08:07, Archimedes Gaviola wrote: > >>> ugen1.5: at usbus1 > >>> ulpt1 on uhub1 > >>> ulpt1: 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 > >> > >> 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 > > bInterfaceSubClass = 0x00ff > > > > It should be a value of 7 for bInterfaceClass and a value of 1 in > > bInterfaceSubClass. > > > > bInterfaceClass = 0x0007 > > 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: at usbus1 > > ulpt0 on uhub1 > > ulpt0: 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 --00000000000055ff3005db3402bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Mar 27, 2022 at 5:05 PM Hans = Petter Selasky <hps@selasky.org&g= t; wrote:
On 3/2= 7/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, add= r 5> on usbus1
>>> device_attach: ulpt1 attach returned 12
>>
>> 12 : man errno :
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 12 ENOMEM Cannot allocate memory.
>>
>> I guess the EPSON printer you've got is not compatible with ul= pt<n>
>>
>> When printing, can you make sure that the length transferred is ne= ver a
>> multiple of 64 bytes?
>>
>> Also, there might be a bug lurking in the USB host controller driv= er,
>> like already mentioned.
>>
>
>
> Hi Hans,
>
> I just figured-out the ulpt(4) driver in my Epson printer while compar= ing
> with my Xprinter printer's USB device info. My Epson printer is pr= oviding
> vendor specific values of 255 in the bInterfaceClass and bInterfaceSub= Class
> respectively.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterfaceClass =3D 0x00ff=C2=A0 <Vendor= specific>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterfaceSubClass =3D 0x00ff
>
> It should be a value of 7 for bInterfaceClass and a value of 1 in
> bInterfaceSubClass.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterfaceClass =3D 0x0007=C2=A0 <Printe= r device>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 bInterfaceSubClass =3D 0x0001
>
> So, the ulpt_attach() routine below will break upon validation for
> mismatched values in UICLASS_PRINTER and=C2=A0 UISUBCLASS_PRINTER.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 } else {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 alt_index++;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if ((id->bInterfaceClas= s =3D=3D
> UICLASS_PRINTER) &&
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (id->bInt= erfaceSubClass =3D=3D
> UISUBCLASS_PRINTER) &&
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (id->bInt= erfaceProtocol =3D=3D
> UIPROTO_PRINTER_BI)) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 goto found;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 }
>
> What I did is temporarily replace these values in the USB definition. = In
> this case, how should the project handle this non-compliance USB devic= es?
> Though I will raise this to Epson if they could provide an updated fir= mware.
>
> 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=C2=A0 =C2=A0 =C2=A02022-03-27 02:5= 5:01.319235000 +0800
> +++ /usr/src/sys/dev/usb/usb.h=C2=A0 2022-03-27 02:57:10.608518000 +08= 00
> @@ -459,8 +459,10 @@
>=C2=A0 =C2=A0#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UICLASS_PHYSICAL=C2=A0 = =C2=A0 =C2=A0 =C2=A0 0x05
>=C2=A0 =C2=A0#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UICLASS_IMAGE=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x06
>=C2=A0 =C2=A0#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UISUBCLASS_SIC=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 1=C2=A0 =C2=A0 =C2=A0 =C2=A0/* still image clas= s */
> -#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UICLASS_PRINTER=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A00x07
> -#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UISUBCLASS_PRINTER=C2=A0 =C2=A0 = =C2=A0 1
> +/* #define=C2=A0 =C2=A0 =C2=A0UICLASS_PRINTER=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A00x07 */
> +/* #define=C2=A0 =C2=A0 =C2=A0UISUBCLASS_PRINTER=C2=A0 =C2=A0 =C2=A0 = 1 */
> +#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UICLASS_PRINTER=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A00xff
> +#define=C2=A0 =C2=A0 =C2=A0 =C2=A0 UISUBCLASS_PRINTER=C2=A0 =C2=A0 = =C2=A0 0xff
>
> I can print now with ulpt(4) driver but need further testing for any i= ssues.
>
> 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 all= owed. I already extended the code and on the way re-building the kernel.

Thanks,<= /div>
Archimedes
--00000000000055ff3005db3402bb--