OpenBSD/amd64 and OpenBSD/i386 have been supporting multiple wsdisplay(4) devices for a while now. Somewhat recently it became also possible to use inteldrm(4) as a secondary display device. There have always been some issues with pairing wskbd(4) keyboard devices with wsdisplay(4) devices. But since it is fairly common for people to have a desktop PC with both Intel integrated graphics and a discrete graphics card, these issues affect many more people now.
On the amd64/i386 architecture, there is the concept of a primary graphics device. This is the device that the BIOS uses for its output when the machine boots. We try very hard to use this device as our console, and it should become wsdisplay0 if we detect it as such. We also make sure that console keyboard attaches to wsdisplay0. All other keyboards are attached, through wsmux(4), to the wsdisplay(4) device that attaches first. Now figuring out what the console keyboard is, is abit tricky on amd64/i386. The BIOS is a very poor excuse for a firmware and doesn't really tell us. So we always attach pckbd(4) as the console keyboard, and only if we don't detect a pckbc(4) controller, we bombard the first USB keyboard as the console keyboard. Since most desktop PCs still contain a PC keyboard controller, this means that if you're using a USB keyboard, it is unlikely to become the console keyboard. As a result it attaches to the first wsdisplay(4) device that attaches. If that happens to be wsdisplay1, the keyboard appears to be non-functional. And since radeondrm(4) doesn't fully attach until it can load its firmware, the USB keyboard will almost certainly attach to wsdisplay1 at inteldrm0. I'm still looking for a clever way to detect that the USB keyboard should become the console keyboard even in the presence of pckbc0. But it would already help these people if wemade sure the non-console keyboards pair themselves with wsdisplay0 as well. Fortunately, there is an easy way to do this. These keyboards attach themselves to the keyboard wsmux(4) device wsmux1 (wsmux0 is used for mouse devices). By default wsdisplay(4) devices take control over wsmux1 ifnobody else has done so yet. But we can prevent this from happening by specifying "mux -1" in the kernel configuration file. I don'thave a system with both inteldrm(4) and radeondrm(4), but on my system with two readeondrm(4) devices, this makes sure an additional USB keyboard connects itself to wsdisplay0 instead of wsdisplay1. ok if I commit the equivalent changes to i386 as well? Index: GENERIC =================================================================== RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v retrieving revision 1.406 diff -u -p -r1.406 GENERIC --- GENERIC 31 Dec 2015 13:06:49 -0000 1.406 +++ GENERIC 3 Jan 2016 20:03:13 -0000 @@ -313,12 +313,12 @@ agp* at intagp? drm0 at inteldrm? console 1 drm* at inteldrm? wsdisplay0 at inteldrm? console 1 -wsdisplay* at inteldrm? +wsdisplay* at inteldrm? mux -1 radeondrm* at pci? # ATI Radeon DRM driver drm0 at radeondrm? console 1 drm* at radeondrm? wsdisplay0 at radeondrm? console 1 -wsdisplay* at radeondrm? +wsdisplay* at radeondrm? mux -1 pcppi0 at isa?
