Mark Kettenis <[email protected]> writes: >> >> Mark Kettenis <[email protected]> writes: >> >> >> From: [email protected] (Timo =?utf-8?Q?Myyr=C3=A4?=) >> >> Date: Thu, 31 Dec 2015 13:01:45 +0200 >> >> >> >> Mark Kettenis <[email protected]> writes: >> >> >> >> > Can you try the diff below in addition to the previous diff? >> >> > >> >> > Thanks, >> >> > >> >> > Mark >> >> >> >> >> >> Applying this diff fixes the display but curiously breaks my USB >> >> keyboard. The keyboard ceases to work after bootloader. USB mouse >> >> works just fine though. If I disable inteldrm on boot the keyboard >> >> works fine. >> > >> > Please send me a new dmesg of the machine with both radeondrm(4) and >> > inteldrm(4) *enabled*. >> > >> > This might actually be expected behaviour. You now effectively have >> > two glass consoles: wsdisplay0 and wsdisplay1. The keyboard attaches >> > to one of those, for example: >> > >> > ukbd0 at uhidev0: 8 variable keys, 6 key codes >> > wskbd0 at ukbd0: console keyboard, using wsdisplay0 >> > >> > Now if you've connected your monitor to wsdisplay1 and your keyboard >> > attaches to wsdisplay0, it will appear not to work. >> > >> > You can easily identify which display you'relooking at. If the login >> > greeting shows ttyC0, you're looking at wsdisplay0, if it shows ttyD0, >> > you're looking at wsdisplay1. >> > >> > In any case, I went ahead and committed the diffs as they are a clear >> > improvement over a black screen ;). >> > >> > Cheers, >> > >> > Mark > > Hi Timo, > > So radeondrm attaches first: > >> radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 6950" rev 0x00 >> drm0 at radeondrm0 >> radeondrm0: msi > > but doesn't fully attach because it needs to load firmware. The > follows inteldrm: > >> inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 3000" rev 0x09 >> drm1 at inteldrm0 >> inteldrm0: msi >> inteldrm0: 1024x768 >> wsdisplay1 at inteldrm0 mux 1 >> wsdisplay1: screen 0-5 added (std, vt100 emulation) > > It doesn't need to load any firmware, so it goes all the way and > attaches as wsdisplay1 since we can tell it isn't the console. > > After a while the "standard" PC keyboard attaches: > >> pckbc0 at isa0 port 0x60/5 irq 1 irq 12 >> pckbd0 at pckbc0 (kbd slot) >> wskbd0 at pckbd0: console keyboard > > You probably don't have one, but the kernel can't really tell whether > one is connected or not. This becomes the console keyboard. That's > not very useful for you, but unfortunately it is the best guess we can > make. > > And here is your USB keyboard: > >> uhub4 at uhub2 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2 >> uhidev1 at uhub4 port 1 configuration 1 interface 0 "Holtek USB Keyboard" >> rev 1.10/3.90 addr 3 >> uhidev1: iclass 3/1 >> ukbd0 at uhidev1: 8 variable keys, 6 key codes >> wskbd1 at ukbd0 mux 1 >> wskbd1: connecting to wsdisplay1 > > As you can see it attached to wsdisplay1. If you had a monitor > connected and a getty running on /dev/ttyD0, you would be able to log > in there using your USB keyboard. But you probably don't have ttyD0 > listed in /etc/ttys, and you probably wouldn't want such a setup anyway. > > Then, after the root partition has been mounted, radeondrm loads its > firmware and continues: > >> radeondrm0: 1920x1200 >> wsdisplay0 at radeondrm0 mux 1: console (std, vt100 emulation), using wskbd0 >> wsdisplay0: screen 1-5 added (std, vt100 emulation) > > As you can see, it attaches as wsdisplay0 as it is your primary > graphics device and therefore becomes the console. > > If you had a "standard" PC keyboard connected everything would work > fine, but you don't. If we could somehow detect that your USB > keyboard is your "primary" keyboard, we could make it the console > keyboard and everything would work fine. But I haven't found a good > way to do that yet. > > You can however, reassign your USB keyboard to wsdisplay0. To do so, > you need to first create /dev/ttyDcfg: > > # cd /dev > # ./MAKEDEV ttyDcfg > > You only need to do this once. > > Then you can detach the USB keyboard from wdisplay1: > > # wsconscfg -f /dev/ttyDcfg -k -d 1 > > And reattach it to wsdisplay0: > > # wsconscfg -f /dev/ttyCcfg -k 1 > > You may want to add the last two wsconscfg commands to /etc/rc.local. > > Cheers, > > Mark
Seems logical and I'll try to see if it helps. But why has the USB keyboard started to attach to wsdisplay1 in -current? What has changed? I haven't touched the BIOS settings and things used to work without any modifications until I updated the OpenBSD installation. If I remember correctly the desktop was running few months old snapshot before xmas update. Timo
