> > Mark Kettenis <mark.kette...@xs4all.nl> writes: > > >> From: timo.my...@wickedbsd.net (Timo =?utf-8?Q?Myyr=C3=A4?=) > >> Date: Thu, 31 Dec 2015 13:01:45 +0200 > >> > >> Mark Kettenis <mark.kette...@xs4all.nl> 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
