Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 Feb 2016 19:06:59 +0100
From:      Polytropon <freebsd@edvax.de>
To:        freebsd-questions@freebsd.org
Subject:   Re: kbdmux disabled --> no useable keyboard?!
Message-ID:  <20160219190659.88944fc4.freebsd@edvax.de>
In-Reply-To: <20160219161801.GC73442@hp.tbl>
References:  <20160217164414.GA73442@hp.tbl> <20160218011023.8519212d.freebsd@edvax.de> <20160219161801.GC73442@hp.tbl>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Thu, 18 Feb 2016 15:00:52 +0000, Luis P. Mendes wrote:
> On 2016.02.18 01:10:23 +0100, Polytropon wrote:
> > On Wed, 17 Feb 2016 16:44:14 +0000, Luis P. Mendes wrote:
> > > On 2015.11.25 Polytropon wrote:
> > > > On Tue, 24 Nov 2015 23:23:56 +0000, Luis P. Mendes wrote:
> > > > >   Hi,
> > > > >
> > > > >   I'm setting up a multiseat workstation, where two users, with two
> > > > >   monitors, two keyboards, two mice and two X sessions can be
> > > > >   connected to the same computer at the same time.
> > > > >
> > > > >   For this to happen, one of the things that is necessary to do is to
> > > > >   disable kbdmux in order for the two keyboards to be considered
> > > > >   independent.
> > > > >
> > > > >   In the past, I've accomplished this with syscon, which had other
> > > > >   problems.  But now with vt, when I disable kbdmux either on
> > > > >   /boot/device.hints or in /boot/loader.conf with:
> > > > >     hint.kbdmux.0.disabled="1"
> > > > >
> > > > >   No keys are recognized by the OS, although dmesg seems to know about
> > > > >   the existence of the USB keyboard.
> > > >
> > > > You need to manually transfer the control of one keyboard to the
> > > > other - from the "active" to the "inactive" one (to become the
> > > > "active" one). Use the kbdcontrol program to do this, "man kbdcontrol"
> > > > has more information about the -k option.
> > > >
> > > > This of course only works when kbdmux is disabled.
> > > 
> > > Only now, could I return to this project.
> > > 
> > > The steps I've taken:
> > > 1. Have an USB keyboard attached to the motherboard.  No serial keyboard used.
> > 
> > The AT keyboard isn't a typical serial keyboard. A Sun keyboard is. ;-)
> Ok, always learning :-) 

The "normal PC keyboard" is called "AT keyboard". Keyboards such
as the classic "round plug" Sun keyboards and the classic Apple
ADB keyboards are real serial keyboards. On the PC, there also
was the XT keyboard (not compatible with AT keyboard controllers,
but the same plug". USB keyboards are "more serial" than AT keyboards.
This completes the confusion. :-)



> > > 2. In /boot/loader.conf, have these lines added:
> > >     ukbd_load="YES"
> > >     hint.kbdmux.0.disabled="1"
> > >     hint.atkbd.0.disabled="1"
> > >     hint.atkbdc.0.disabled="1"
> > 
> > I don't know if disabling the AT keyboard controller is useful here.
> > If no keyboard is attached, the device will stay present. But if an
> > USB keyboard is being used anyway, this should not matter.
> Well, just in case, I removed the two *atk* lines from
> /boot/loader.conf.  The USB keyboard is still not useable.

When the AT keyboard controller is present, the AT keyboard will
also be present, no matter if a keyboard is _actually_ connected
or not. So it will be ignored when no keyboard is connected, and
the USB keyboard _should_ be the "primary" keyboard (because it's
the only one present).

Typically, kbdmux is doing the magic here. It "parallels" all the
keyboards, and if the USB keyboard driver registers a USB keyboard,
it will be "in the mix" (or "in the mux"), even if it's the only
keyboard.

Manually selecting one keyboard in the absence of kbdmux should
have the same effect - this is how it was done on FreeBSD before
kbdmux and devd became available.



> > > 3. In /etc/rc.conf.local:
> > >     kbdcontrol -k /dev/ukbd0 < /dev/console
> > 
> > That should go to /etc/rc.local. Note that /etc/rc.conf.local is a
> > configuration file (in the style of /etc/rc.conf) that's being sourced
> > additionally; see "man rc" and "man rc.conf" for details.
> I've read it before and from what I understand /etc/rc.conf.local is
> meant for local configurations, instead of global configurations that
> should be placed in /etc/rc.conf.  Could see no problem in placing the
> above line in /etc/rc.conf.local, but moved it to /etc/rc.conf anyway.

This is sonehow an "OpenBSD-ism". There is a hierarchy in which
configuration files are being sourced:

	/etc/defaults/rc.conf
	/etc/rc.conf
	/etc/rc.conf.local

Note that they are sh-style files, so they are, in fact, valid
shell scripts and _can_ contain "executable code" (as opposite
to the "variable assignments" they usually contain).

In OpenBSD, all user system configuration goes to rc.conf.local,
while OS-provided (!) configuration is kept in rc.conf. In FreeBSD,
both files can be used, but it's common to add settings to rc.conf,
for example when you install CUPS (a 3rd party software package,
does not belong to the OS), and then add ``cupsd_enable="YES"''
to rc.conf - it's completely fine.

The even might be /usr/local/etc/rc.conf and /opt/etc/rc.conf,
if you add "source hooks" for them. :-)

Anyway: User added startup code should be added to /etc/rc.local
if you're fine with the point in time when the OS runs that code.
If you're doing something more... well, let's say "professional",
then write an entry in rc.d style and add it to /usr/local/etc/rc.d
to be executed. But for two or three commands, I'm too lazy and
use rc.local myself in a very professional manner. :-)



> > > 4. In /var/log/messages, there are these lines:
> > >     kernel: ukbd0: <USB Keyboard> on usbus0
> > >     kernel: kbd0 at ukbd0
> > > 
> > > 5. # ll /dev/uk*
> > >      crw-------  1 root  wheel  0x7f 15 Fev 22:39 /dev/ukbd0
> > > 
> > > 6. # ls -l /dev/kb*
> > >      lrwxr-xr-x  1 root  wheel  5 15 Fev 22:39 /dev/kbd0 -> ukbd0
> > 
> > For comparison: With an AT and a USB keyboard both operational,
> > the following results will be present:
> > 
> > % ll /dev/*kbd*
> > crw-------  1 root  wheel    0,  55 2016-02-17 19:30:58 /dev/atkbd0
> > lrwxr-xr-x  1 root  wheel         6 2016-02-17 19:30:58 /dev/kbd0@ -> atkbd0
> > lrwxr-xr-x  1 root  wheel         7 2016-02-17 19:30:58 /dev/kbd1@ -> kbdmux0
> > lrwxr-xr-x  1 root  wheel         5 2016-02-17 19:31:10 /dev/kbd2@ -> ukbd0
> > crw-------  1 root  wheel    0,  10 2016-02-17 19:30:58 /dev/kbdmux0
> > crw-------  1 root  wheel    0, 150 2016-02-17 19:31:10 /dev/ukbd0
> > 
> > In this case, kbdmux is active. If it was not, the both keyboards
> > should be identified as kbd0 (atkbd0) and kbd1 (ukbd0).
> 
> Mine (after commenting the two atk lines in /boot/loader.conf): 
> # ll /dev/*kbd*
> crw-------  1 root  wheel  0x34 18 Fev 14:34 /dev/atkbd0
> lrwxr-xr-x  1 root  wheel     6 18 Fev 14:34 /dev/kbd0@ -> atkbd0
> lrwxr-xr-x  1 root  wheel     5 18 Fev 14:34 /dev/kbd1@ -> ukbd0
> crw-------  1 root  wheel  0x81 18 Fev 14:34 /dev/ukbd0

So the AT keyboard is still detected and instantiated, and you
need to manually switch from kbd0 (atkbd0) to kbd1 (ukbd0), or
let kbdmux "combine" both.



> > As you can see from your kernel message, the device has been picked
> > up and recognized correctly, and the required device links have been
> > established.
> Got some more information from /var/log/messages:
> # egrep -i -e 'kbd|keyb' messages
> Feb 18 14:34:58 leao kernel: module_register_init: MOD_LOAD (kbdmux,
> 0xffffffff805d4070, 0) error 6

This looks like a problem - kbdmux won't work for you. Why is this?



> Feb 18 14:34:58 leao kernel: atkbdc0: <Keyboard controller (i8042)>
> at port 0x60,0x64 on isa0

The onboard keyboard controller is still detected.



> Feb 18 14:34:58 leao kernel: atkbd0: <AT Keyboard> irq 1 on atkbdc0
> Feb 18 14:34:58 leao kernel: kbd0 at atkbd0
> Feb 18 14:34:58 leao kernel: atkbd0: [GIANT-LOCKED]

The non-existing AT keyboard is registered.



> Feb 18 14:34:58 leao kernel: ukbd0: <USB Keyboard> on usbus0
> Feb 18 14:34:58 leao kernel: kbd1 at ukbd0

The USB keyboard is being picked up correctly.



> Feb 18 14:34:58 leao kernel: uhid0: <USB Keyboard> on usbus0

Hmmm... Those might be additional keyboard features. Maybe it has
some "multimedia keys" that are not transmitted with the regular
keyboard datastream?

I have a 21" CRT with built-in USB (a USB hub primarily) that
also exhibits those "human interface device" features, but I'm
not sure what those are:

uhid0: <EIZO USB Monitor Function, class 0/0, rev 1.00/1.10, addr 3> on usbus1

Maybe the little screen set-up keys...



> It seems there's an error 6 loading kbdmux...
> My FreeBSD version is
> # uname -a
> FreeBSD leao 10.3-BETA1 FreeBSD 10.3-BETA1 #0 r295321: Fri Feb  5
> 17:02:27 WET 2016 

Yes, this error prevents you from using the "automatic" mechanism
that should solve your problem (as it does for me, I'm still on
FreeBSD 8 on my home system - "never touch a running system").

I still wonder why you get the "module_register_init: MOD_LOAD"
message. Do you use a module for kbdmux? It should be in the
kernel configuration file (GENERIC). If not - have you tried
building a custom kernel with "device kbdmux"? If you have world
and kernel version in sync, you don't need to "make buildworld"
and install it - "make kernel" is sufficient; see the comment
header of /usr/src/Makefile for the procedure.



> > > But I can't type anything in the (virtual) console.  I'm not
> > > considering X yet.
> > 
> > And you are _totally sure_ the keyboard works?
> Completely sure, when these setting are not in place, I can use the
> keyboard.  And with the settings, I can type my GELI password on boot
> and choose from the boot menu.

Okay, the question was just to make sure _everything_ works. :-)



> > > I don't understand what exactly is meant as example in the manual of
> > > kbdcontrol, so cannot find what is wrong with this.
> > > Would appreciate some help on this.
> > 
> > You have been using the correct command for switching to a specific
> > keyboard (as quoted above).
> 
> This is the only thing keeping me from using my workstation the way I
> need.  I hope there's some fix to this.

You have provided good diagnostic output. Maybe you should ask
the freebsd-kernel@ or freebsd-hackers@ mailing lists, by providing
the error messages quoted above and a short summary of your setting
and what you've already tried.



> Thanks for the ongoing help Polytropon!  Hope that you or somebody
> else can point me to the right correction.

I think there is something going on at kernel level which prevents
all subsequent "magic" from happening. I'm using a similar setup
here on FreeBSD 8 (atkbd detected, no keyboard attached; USB keyboard
detected, muxed, works in VTs and X).

At a result, you should get something like this:

% dmesg | grep kbd
kbd1 at kbdmux0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
ukbd0: <vendor 0x0430 Sun USB Keyboard, class 0/0, rev 2.00/1.05, addr 5> on usbus1
kbd2 at ukbd0

See the lines containing "kbdmux". Also note that there is no actual
AT keyboard involved. A FreeBSD 10 output should be comparable.



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20160219190659.88944fc4.freebsd>