On Fri, Apr 26, 2024 at 08:31:17AM -0000, Stuart Henderson wrote: > On 2024-04-25, Wolfgang Pfeiffer <r...@gmx.net> wrote: > > ----- Forwarded message from Harald Dunkel <ha...@afaics.de> ----- > > This morning I've got a HUNSN RJ43 network appliance with N100 and > > 4 2.5Gbit network interfaces. Problem: The keyboard is lost at boot > > time. It still worked at the boot> prompt, but in OpenBSD's installer > > menu or at the login prompt it is ignored. I have to pull it out and > > plug it into another socket to make OpenBSD 7.5 recognize it, but > > even this workaround fails sometimes. > ... > > Another 15+ years old USB keyboard works out of the box, so maybe the > > keyboard is to blame here. It worked fine on other hosts running > > OpenBSD 7.4 or 7.5, though. > > > > BIOS had been reset to the defaults. dmesg output is attached, of > > course. Every helpful idea is highly appreciated. I would be glad > > to help to track down this problem. > > So another keyboard works with this machine, and this keyboard works > with other machines. > > I suspect some quirk with the keyboard that interacts with a quirk in > the BIOS. > > If there are options to change things to do with keyboard device > emulation / USB legacy support / 8042 emulation / port 60/64 emulation > then it might be worth toggling to see if they help. Or look for > different BIOS/UEFI versions for the machine. This class of hardware is > not exactly known for high quality firmware. >
Also the keyboard is a bit strange since the actual keyboard is attaching after a lot of other uhids. So it is well possible that stuff gets a bit confused: uhidev0 at uhub0 port 6 configuration 1 interface 0 "SINO WEALTH Newmen Bluetooth Keyboard" rev 1.10/30.04 addr 3 uhidev0: iclass 3/1 ukbd0 at uhidev0: 8 variable keys, 6 key codes wskbd0 at ukbd0: console keyboard, using wsdisplay0 uhidev1 at uhub0 port 6 configuration 1 interface 1 "SINO WEALTH Newmen Bluetooth Keyboard" rev 1.10/30.04 addr 3 uhidev1: iclass 3/0, 13 report ids uhid0 at uhidev1 reportid 1: input=1, output=0, feature=0 ucc0 at uhidev1 reportid 2: 573 usages, 20 keys, array wskbd1 at ucc0 mux 1 wskbd1: connecting to wsdisplay0 uhid1 at uhidev1 reportid 5: input=0, output=0, feature=5 ukbd1 at uhidev1 reportid 6: 120 variable keys, 0 key codes wskbd2 at ukbd1 mux 1 wskbd2: connecting to wsdisplay0 There is wskbd0 which is a ukbd with 8 keys then there is wskbd1 which is ucc0 (control keyboard) and finally wskbd2 at ukbd1 at uhidev1 reportid 6 is the actual keys. So I'm not that surprised that this causes problems. -- :wq Claudio