Installing 13.0-RELEASE on a new laptop

OK, I messed around in the BIOS:
  • Tried UEFI/non-UEFI booting. No such option in my BIOS, but Secure Boot does need to be turned off, otherwise FreeBSD won't boot at all.
  • Turning off support for legacy USB made no difference.
Messing with sysctl variables:
  • Tried changing the line in /boot/device.hints from hint.atkbdc.0.port="0x060" to hint.atkbdc.0.port="0x064" - no difference.
Next up, trying a -CURRENT kernel for FreeBSD 14, the AMD64 ISO from Feb. 24.

Edit: Tried starting an installation with 14-CURRENT. It took two tries (Kernel panic first time) to get the installer going, but it's still not detecting the internal keyboard after the kernel starts to boot. Gonna see if eternal_noob 's pointer pans out.
 
Have you read
forums.freebsd.org

Laptop keyboard and trackpad not working

Hi everyone. I'm running FreeBSD 12.2, but my laptop keyboard and trackpad don't work. I can plug in a USB keyboard and mouse and they work fine. I found this in the log file, but couldn't find much to explain the error message or how to fix it. I'm using a Surface Book. Intel Core i5-6300U...
forums.freebsd.org forums.freebsd.org
?
The guy says he needed to blacklist the uhid keyboard driver and some hw.usb.quirk magic in loader.conf.
 
eternal_noob said:
Have you read
forums.freebsd.org

Laptop keyboard and trackpad not working

Hi everyone. I'm running FreeBSD 12.2, but my laptop keyboard and trackpad don't work. I can plug in a USB keyboard and mouse and they work fine. I found this in the log file, but couldn't find much to explain the error message or how to fix it. I'm using a Surface Book. Intel Core i5-6300U...
forums.freebsd.org forums.freebsd.org
?
The guy says he needed to blacklist the uhid keyboard driver and some hw.usb.quirk magic in loader.conf.
Click to expand...
Followed that on my 13.0-RELEASE install. The only difference it made:
WARNING: Device "vkbdctl" is Giant locked and may be deleted before FreeBSD 14.0.
Used to be:
WARNING: Device "atkbd0" is Giant locked and may be deleted before FreeBSD 14.0.

I really appreciate the help, and disappointed to report from my end of things that it didn't work. 😩

FWIW, my laptop is Asus Rog Zephyrus g14, with a Ryzen 9 6900 HS, and RX 6700m. Specs can be confirmed from the attachment in this thread's post #25.
 
But boot a Manjaro install stick (manjaro-kde-21.2.4-minimal-220301-linux515.iso), and it works perfect! Laptop Keyboard detected no problem, even the trackpad works! That's the frustrating part, I want FreeBSD to work. 😩
 
Following eternal_noob 's pointer, I ran usbconfig as suggested by that thread, and discovered that my keyboard is most likely an ASUSTek N-Key board at /dev/ugen0.2. Digging a bit deeper, I disovered a possibly related PR (PR 181425)... This is a LOT of rather far-flung dots to connect, but I'm stubborn. That PR actually shows the exact problem I'm having, but I doubt I can summon enough discipline to make myself go down the additional rabbit hole of figuring out the ropes of getting that PR re-opened. I'm lucky enough to find it, and will probably get to studying it after I get some sleep tonight.
 
astyle said:
Following eternal_noob 's pointer, I ran usbconfig as suggested by that thread, and discovered that my keyboard is most likely an ASUSTek N-Key board at /dev/ugen0.2. Digging a bit deeper, I disovered a possibly related PR (PR 181425)...
Click to expand...
This PR is almost 9 years old. Back then, PS/2 keyboards were still widely available and being used by people who do more than two-finger-typing.
Real USB keyboards (eg those with N-key-rollover) were still a rare exotic thing.

Nowadays the situation is different. PS/2 hardware is no longer used/attachable in new products, and quality laptops get equipped with real USB keyboards with N-key-rollover. Over time, this will become common with desktops, too.
It would be a shame if FreeBSD users would have first to solve the hurdle to find out how to turn off quality hardware's features, only to make modern hardware work at all. This also affects multimedia keyboards, keyboards with extra function keys etc.
So it imho becomes a necessity to add full USB keyboard support.

For this reason, I'd suggest to make a feature request "Add USB N-key rollover keyboard support" instead of a "bug" report, linking to the old PR as "see also".
 
skunk said:
[...] For this reason, I'd suggest to make a feature request "Add USB N-key rollover keyboard support" instead of a "bug" report, linking to the old PR as "see also".
Click to expand...
That would be a good thing, in general. However:
astyle said:
[...] Laptop's keyboard starts out working fine. Escaping to loader prompt works fine.
Click to expand...
I'm trying to interpret the messages and behaviour that's been reported. That means to me that at that time (during the boot process) OP has a working laptop keyboard. That means that the keyboard driver then active is functioning ok. When the system is up and running something has changed: other driver active or other settings active. I think its worthwhile to explore that option. Unfortunately I don't have an idea how to attack the problem from that angle, others might.

In the end it may very well be that using the same settings/driver as during the boot screen in message #1 is unsatisfactory and won't allow full use of all keyboard features but at least, for the moment, the internal keyboard could be fucntioning (until the PR or feature request is solved).
 
Erichans said:
I'm trying to interpret the messages and behaviour that's been reported. That means to me that at that time (during the boot process) OP has a working laptop keyboard. That means that the keyboard driver then active seems to function ok. When the system is up and running something has changed: other driver active or other settings active. I think its worthwhile to explore that option. Unfortunately I don't have an idea how to attack the problem from that angle, others might.

In the end it may very well be that using the same settings/driver as during the boot screen in message #1 is unsatisfactory and won't allow full use of all keyboard features but at least, for the moment, the internal keyboard could be fucntioning (until the PR or feature request is solved).
Click to expand...
at that time keyboard is driven by EFI, the loader (boot menu) does not talk directly to the hardware
 
astyle said:
Following eternal_noob 's pointer, I ran usbconfig as suggested by that thread, and discovered that my keyboard is most likely an ASUSTek N-Key board at /dev/ugen0.2. Digging a bit deeper, I disovered a possibly related PR (PR 181425)... This is a LOT of rather far-flung dots to connect, but I'm stubborn. That PR actually shows the exact problem I'm having, but I doubt I can summon enough discipline to make myself go down the additional rabbit hole of figuring out the ropes of getting that PR re-opened. I'm lucky enough to find it, and will probably get to studying it after I get some sleep tonight.
Click to expand...

astyle, reading through PR 181425 (yes, as mentioned also, it's old but your problem description is there)
  1. you can compile a FreeBSD kernel
  2. # usbconfig -d ugen.0.2 dump_device_desc will give you the idVendor & idProduct

Perhaps try adding your own two lines after /sys/dev/usb/quirk/usb_quirk.c:
Code: 
	/* Holtek USB gaming keyboard */
	USB_QUIRK(HOLTEK, F85, 0x0000, 0xffff, UQ_KBD_BOOTPROTO),

	/* Asus Rog Zephyrus g14 keyboard */
	USB_QUIRK( ...  UQ_KBD_BOOTPROTO),
 
Erichans said:
astyle, reading through PR 181425 (yes, as mentioned also, it's old but your problem description is there)
  1. you can compile a FreeBSD kernel
  2. # usbconfig -d ugen.0.2 dump_device_desc will give you the idVendor & idProduct

Perhaps try adding your own two lines after /sys/dev/usb/quirk/usb_quirk.c:
Code: 
    /* Holtek USB gaming keyboard */
    USB_QUIRK(HOLTEK, F85, 0x0000, 0xffff, UQ_KBD_BOOTPROTO),

    /* Asus Rog Zephyrus g14 keyboard */
    USB_QUIRK( ...  UQ_KBD_BOOTPROTO),
Click to expand...
Thanks, Erichans . I did try the usbconfig method, adjusting for my hardware. In the thread that eternal_noob was suggesting (Thread laptop-keyboard-and-trackpad-not-working.79163), the method was to edit /boot/loader.conf with those USB_QUIRK variables, rather than stuff them into /sys/dev/usb/quirk/usb_quirk.c... is there a benefit to recompiling the kernel over messing with /boot/loader.conf?
 
I did see this in the PR:
Fix: The keyboard works fine in boot protocol. Running this

# usbconfig -d 0.4 add_quirk UQ_KBD_BOOTPROTO

and unplugging and plugging the keyboard back in fixes it, as does
adding the quirk for vendor 0x0665 product 0x6000 in usb_quirk.c.
Click to expand...
I deduced that usbconfig will only work after a new scan is initiated when the keyboard goes from unplugged to plugged; that scenario didn't seem feasible in your brandnew laptop case :)

I am uncertain as to the exact difference between adding to /boot/loader.conf something like:
Code: 
hw.usb.quirk=0x045e 0x07cd 0xffff UQ_KBD_BOOTPROTO
(as mentioned in Thread laptop-keyboard-and-trackpad-not-working.79163) and "compiling it in". I do not know where "0xffff" comes from; I'm going by the contents of the PR mentioned. Perhaps others can shine their light on this. In any case, unless someone states otherwise, trying this beats waiting for a solution of a PR or a feature request, but that's my look on things.
 
Tried using a non-uefi image (12.3 STABLE, an iso from 3/3/22), that one showed a text-based beastie logo to prove it's non-uefi, but problem remains.
covacat said:
at that time keyboard is driven by EFI, the loader (boot menu) does not talk directly to the hardware
Click to expand...
I strongly suspect covacat's hunch is correct, and think that a solution will probably be based on that. But I'm still lost as to what I can try to verify that line of thinking.
 
Well, it was my oversight and covacat's statement of fact :) In the very beginnings of the "good old MS DOS" era the BIOS was actually used as a Basic Input Output System to comminucate with the hardware. I suspect not with then 386BSD as the first PC based spin-off of BSD. Being simply a keyboard it should be possible to still get your keyboard kicks (ehh clicks) via the now UEFI firmware interface; the loader can ... ;) But that possibility has passed I'd think.

If you will not find an immediate solution, I hope the driver can be patched/upgraded for your NKRO keyboard. It could be of help for the driver developer if you can identify the keyboard controller chip that processes your keyboard, especially if more than a simple patch is needed. The appropriate mailing list might also give that a start.
 
grahamperrin said:
iichid(4), maybe?

Lazily based on a mention in NomadBSD Forum.

astyle can you share the result of a hardware probe?
  1. pkg install sysutils/hw-probe sysutils/pciutils sysutils/usbutils
  2. hw-probe -all -upload
Click to expand...
Probe URL: https://bsd-hardware.info/?probe=20cdc9d999

This has been run on a 13.0-RELEASE install.
1646573969332.png

The N-KEY internal keyboard has been at least detected, so this has me thinking that it's not impossible to make it work, given proper fiddling with sysctl(8) variables and the like.

Edit: The USB external keyboard that works (listed right below the N-KEY Asus keyboard that does not) - it uses the ukbd driver. Exploring both - they both have the same message:
We have not found anything related to this device in any FreeBSD versions up to 14-CURRENT. See FreeBSD hardware notes.
Click to expand...
 
Update: re-read the PR 181425, and tried to do some troubleshooting as suggested there. Results are attached:

A short summary: I added the line hw.usb.ukbd.debug=1 to /boot/loader.conf to produce the files. A look through them suggests to me that the kernel actually sees the keyboard, and all the keys, but fails to attach it. It re-tries the attachment 3 times before giving up (see towards the end of attached dmesg_debug.txt)

Looking at uhidd_report.txt, it looks like something is up with how the USB bus is scanned - a lot of UNKNOWN values at the beginning, but towards the end, they get properly filled. 😩

Any ideas on what I can do to finish this?
 

Attachments

  • dmesg_debug.txt
    23.5 KB · Views: 88
  • uhidd_report.txt
    6.6 KB · Views: 87
From uhidd_report.txt: Looks like the section titled ugen0.2[2] is the one for the keyboard, while the one titled ugen0.2[3] is for the mouse.

Seems like my next step is to capture 3 versions of dmesg (but with hw.usb.ukbd.debug=1!)
  • with usb keyboard plugged in
  • without usb keyboard plugged in
  • on a different laptop where the built-in keyboard works under 13.0-RELEASE or later.
Reading the manpages is a good skill to have, but it still takes some brains to take notes and connect the dots and figure out how to approach the problem after all that reading. 😩 Like what actually comes first, second, and why that is technically the case.
 
Looked through bsd-hardware.info... My hardware scan is the only one there with an N-KEY keyboard. Compared that with information from linux-hardware.org. Both places list device class as 03-01-01. And even Device ID looks similar: USB 0b05:19b6 for bsd-hardware.info, vs USB 0b05:1866 on linux-hardware.org...

Which suggests to me that covacat 's line
covacat said:
try this in /boot/loader.conf
hw.usb.quirk.0="0x0b05 0x19b6 0 0xffff UQ_KBD_BOOTPROTO"
Click to expand...

could be changed to:
hw.usb.quirk.0="0x0b05 0x1866 0 0xffff UQ_KBD_BOOTPROTO"

Does anyone think this just might work, or are there pitfalls to that idea?
 
You must log in or register to reply here.
Back
Top