Re: Example context needing use of hw.usb.usbhid.enable=0 : serial console keyboard input under Parallels (aarch64) [reproduces again]

Jordan Gordeev <jgopensource_at_proton.me> wrote on
Date: Wed, 13 Aug 2025 18:14:41 UTC :

> On Wednesday, 13 August 2025 at 08:30, Mark Millard <marklmi@yahoo.com> wrote:
> 
> > Jordan Gordeev <jgopensource_at_proton.me> wrote on
> > 
> > > Serial console is typically understood to mean a console over a serial link like RS-232. If you end up reporting this bug to the bug database, using confusing terminology should be avoided.
> > 
> > 
> > "Text console"? Some other suggestion to avoid misleading? It is not emulating any general graphics console as far as I can tell.
> 
> "Text console" is fine.
> 
> > > The hkbd(4) driver detects the keyboard and attaches successfully. Adding the following to /boot/loader.conf will enable debug output from the driver:
> > > hw.hid.hkbd.debug="100"
> > 
> > 
> > Added for now.
> 
> Okay, you've enabled the generation of debugging output by hkbd(4). What did you do with the generated output?

Other than the diff's I'd provided (as referenced below)?

> It's the most important piece of information in this situation.
> 
> > dmsg -a output capture differences from different boots follow.
> 
> There are three cases here:
> Case A: usbhid is disabled; the keyboard works
> Case B: usbhid is enabled; the keyboard works
> Case C: usbhid is enabled; the keyboard doesn't work

You deleted the text here that provided a diff for, for example,

QUOTE
In the below "-" is for failing (default ...usbhid.ignored) and "+" is for working ( ...usbhid.ignored=0 )
END QUOTE

As I understand, that translates to my "-" being your (C) and to my "+" being your (A).

> You recently observed Case B. The difference in dmesg between Case B and Case C is what is of interest.

I've no known way to cause (B). As far as my classifications back then, any (B)-like example may have been a misclassification of the context that I had at the time [so: actually (A)?]. I'm unable to produce a (B) example so far.

Sorry for my apparent classification screwup.

> > > Also, when the keyboard doesn't work does the mouse work?
> > 
> > 
> > This is not a graphics window context. Clicking in that window captures the mouse/cursor and stops displaying it until Ctrl+Alt are both pressed at the same time "too free the cursor", as it says.
> > 
> 
> If you start moused, you would get a mouse cursor in the text console. However, with usbhid enabled, the mouse will always not work (the cursor won't move at all) because the current version of moused does not support hms(4) devices. Forget about the mouse for a while.

Okay.

> One extra thing to try is resetting the keyboard with a command such as this:
> usbconfig -d /dev/ugen1.3 reset
> 
> If the keyboard doesn't work, the command might make it work. Perhaps the opposite is also possible.

For both types of contexts, (A) and (C), the usbconfig command made no difference to keyboard input status for the context. I did not ever end up with a (B) context.


===
Mark Millard
marklmi at yahoo.com