The genkbd version of these remains exposed for stable branches, but
keyboard drivers that just want to use the defaults can simply not provide
their own. There shouldn't be any unset in the wild.

r355796:
kbd: provide default implementations of get_fkeystr/diag

Most keyboard drivers are using the genkbd implementations as it is;
formally use them for any that aren't set.

r355797:
chrome_kb: remove default get_fkeystr/diag implementations

This file was missed in r355796, but no harm would have come from this.

r355799:
kbd: patch linker set methods, too

This is needed after r355796. Some double-registration of kbd drivers needs
to be sorted out, then this sysinit will simply add these drivers into the
normal list and kill off any other bits in the driver that are aware of the
linker set, for simplicity.

evdev: Use console lock as evdev lock for all supported keyboard drivers.

Now evdev part of keyboard drivers does not take any locks if corresponding
input/eventN device node is not opened by userland consumers.

Do not assert console lock inside evdev to handle the cases when keyboard
driver is called from some special single-threaded context like shutdown
thread.

MFC r339824:

evdev: disable evdev if it is invoked from KDB or panic context

This allow to prevent deadlock on entering KDB if one of evdev locks is
already taken by userspace process.

Also this change discards all but LED console events produced by KDB as
unrelated to userspace.

Move evdev_ev_kbd_event() helper from evdev to kbd.c as otherwise evdev
unconditionally requires all keyboard and console stuff to be compiled
into the kernel. This dependency happens as evdev_ev_kbd_event() helper
references kbdsw global variable defined in kbd.c through use of
kbdd_ioctl() macro.

While here make all keyboard drivers respect evdev_rcpt_mask while setting
typematic rate and LEDs with evdev interface.

Requested by:	Milan Obuch <bsd@dino.sk>
Reviewed by:	hselasky, gonzo
Differential Revision:	https://reviews.freebsd.org/D16614

opt_compat.h is mentioned in nearly 180 files. In-progress network
driver compabibility improvements may add over 100 more so this is
closer to "just about everywhere" than "only some files" per the
guidance in sys/conf/options.

Keep COMPAT_LINUX32 in opt_compat.h as it is confined to a subset of
sys/compat/linux/*.c.  A fake _COMPAT_LINUX option ensure opt_compat.h
is created on all architectures.

Move COMPAT_LINUXKPI to opt_dontuse.h as it is only used to control the
set of compiled files.

Reviewed by:	kib, cem, jhb, jtl
Sponsored by:	DARPA, AFRL
Differential Revision:	https://reviews.freebsd.org/D14941

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

To enable event sourcing from kbdmux(4) kern.evdev.rcpt_mask value
should have bit 1 set (this is default)

Submitted by:	Vladimir Kondratiev <wulf@cicgroup.ru>
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D8437

this, and sc will soon depend on it again.

The on/off request is passed without modification to lower layers,
so the bug was smaller in this layer than in in lower layers (the
sequence on;on;off left polling off when it should be on, but the
sequence on;on;off;on;off...  doesn't allow the interrupt handler
to eat the input after an "off" that should't turn off polled mode,
provided lower layers don't have the bug, since this layer is virtual.

The bug was small in lower layers too.  Normally everything is Giant
locked for keyboards, and this locks out the interrupt handler in
on;on;off;on;off... sequences.  However, PR 211884 says that fixing
this bug in ukbd in r303765 apparently causes the eating-by-interrupt
behaviour that the fix is to prevent.

Discussed with: emax

PR:		153459
Submitted by:	swell.k@gmail.com

The change would appease the static analyzers but it is pretty much a
no-op. I need to trust static analyzers much less, especially for the
kernel.

Requested by:	jkim

This is a fix to the previous attempt in r281889, which some (most?)
keyboards.

Discussed with:	emaste, jkim

Found by:	clang static analyzer
CID:		1007072
CID:		1007073
CID:		1007074