On Wed, Aug 03, 2022 at 07:17:27AM +0200, Anton Lindqvist wrote:

Hello Anton,

>> `disable ucc` has no effect (it doesn't attach normally, so I guess that's
>> not surprising?) -- I still get a kernel panic.
> ucc does attach according to your dmesg. However, while ucc attaches it
> sets it's own layout to `KB_US | KB_NOENCODING', meaning that
> wskbd_load_keymap() requests are ignored since only one map is provided.

OK, this one baffled me for a while! You're quite right, in the very first
dmesg I got (which is the one I sent in my first email):

  ucc0 at uhidev1 reportid 1: 4 usages, 3 keys, enum
  wskbd1 at ucc0 mux 1

but I have a record of several subsequent dmesg's and not one of them
contains ucc -- even if I boot with the same snapshot kernel (#658).

It turns out that's because my first dmesg was recorded while attached to an
external keyboard (via a hub) and all the subsequent ones without an
external keyboard.

Here's wsconsctl if I boot without the external keyboard attached:

  $ doas wsconsctl | grep "^keyboard"
  wsconsctl: Use explicit arg to view keyboard.map.
  keyboard.type=pc-xt
  keyboard.bell.pitch=400
  keyboard.bell.period=100
  keyboard.bell.volume=50
  keyboard.bell.pitch.default=400
  keyboard.bell.period.default=100
  keyboard.bell.volume.default=50
  keyboard.repeat.del1=400
  keyboard.repeat.deln=100
  keyboard.repeat.del1.default=400
  keyboard.repeat.deln.default=100
  keyboard.ledstate=0
  keyboard.encoding=unknown_0

And when I attach the external keyboard this becomes:

  $ doas wsconsctl | grep "^keyboard"
  keyboard.type=pc-xt
  keyboard.bell.pitch=400
  keyboard.bell.period=100
  keyboard.bell.volume=50
  keyboard.bell.pitch.default=400
  keyboard.bell.period.default=100
  keyboard.bell.volume.default=50
  keyboard.repeat.del1=400
  keyboard.repeat.deln=100
  keyboard.repeat.del1.default=400
  keyboard.repeat.deln.default=100
  keyboard.ledstate=0
  keyboard.encoding=uk
  keyboard1.type=usb
  keyboard1.bell.pitch=400
  keyboard1.bell.period=100
  keyboard1.bell.volume=50
  keyboard1.bell.pitch.default=400
  keyboard1.bell.period.default=100
  keyboard1.bell.volume.default=50
  keyboard1.repeat.del1=400
  keyboard1.repeat.deln=100
  keyboard1.repeat.del1.default=400
  keyboard1.repeat.deln.default=100
  keyboard1.ledstate=0
  keyboard1.encoding=uk
  keyboard2.type=usb
  keyboard2.bell.pitch=400
  keyboard2.bell.period=100
  keyboard2.bell.volume=50
  keyboard2.bell.pitch.default=400
  keyboard2.bell.period.default=100
  keyboard2.bell.volume.default=50
  keyboard2.repeat.del1=400
  keyboard2.repeat.deln=100
  keyboard2.repeat.del1.default=400
  keyboard2.repeat.deln.default=100
  keyboard2.ledstate=0
  keyboard2.encoding=us.noencoding
  keyboard3.type=usb
  keyboard3.bell.pitch=400
  keyboard3.bell.period=100
  keyboard3.bell.volume=50
  keyboard3.bell.pitch.default=400
  keyboard3.bell.period.default=100
  keyboard3.bell.volume.default=50
  keyboard3.repeat.del1=400
  keyboard3.repeat.deln=100
  keyboard3.repeat.del1.default=400
  keyboard3.repeat.deln.default=100
  keyboard3.ledstate=0
  keyboard3.encoding=uk

Note that after the external keyboard attaches keyboard.encoding has changed
from unknown_0 to uk; if I unplug the external keyboard the encoding goes
back to unknown_0.

I did a bit more digging and I've confused myself considerably, possibly
because I don't know how wscons works. If I boot the machine without the
external keyboard attached, stay in the console (i.e. outside X), and then
plug in the external keyboard causes the laptop keyboard behaves bizarrely:
for example "1" and "a" are inverted (i.e. I press "1" and "a" is
displayed). After I unplug the external keyboard, I seem to get a new (more
bizarre) map in the console where "a" is some sort of control code. I
eventually managed to trigger a panic in wskbd_translate by doing this:

  https://postimg.cc/JtrN1GWy

Note this happened with the stock #658 kernel (i.e. without Miod's patch). I
suppose this isn't a very interesting panic in the sense that something has
gone wrong quite before this panic occurred, but still, it might be useful
info for someone!


Laurie

Reply via email to