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.
marco: update to 1.22.4
### marco 1.22.4
* update translations
* Revert "compositor: fix possible crash closing/destroying window"
* theme.c: Fix window control hidpi rendering for all themes.
* theme: Render window control buttons and icons as surfaces
### marco 1.22.3
* update translations
* frames: bump priority of style providers
* window: add _GTK_THEME_VARIANT to initial window properties
* frames: apply modified hack from Mutter/Metacity
* frames: avoid infinite loop on the variants GList
* frames: use style_updated instead of style_set
* Fixed moving windows to edges to work with CSD clients.
* window: Update allowed action hints
* build: Remove rationales.txt from EXTRA_DIST target
* Fix use of RBGA visual in frame.c when compositing is not in use
* drop old and obsolete rationales.txt
* boxes: Actually check for rectangle containment
textproc/py-genshi: Update to 0.7.3
Genshi 0.7 doesn't support Python 3.5+, but the port currently allows it
to be built with any Python version. This doesn't affect the build, but
produces a broken runtime, including for all Genshi dependents:
Genshi (0.7) tests:
2.7: Ran 854 tests in 3.623s - FAILED (failures=1)
3.5: Ran 858 tests in 3.607s - FAILED (failures=4, errors=34)
3.6: Ran 858 tests in 3.610s - FAILED (failures=4, errors=34)
3.7: Ran 858 tests in 3.313s - FAILED (failures=11, errors=91)
3.8: Ran 858 tests in 3.094s - FAILED (failures=32, errors=359)
Genshi added 3.5+ support in subsequent versions :
0.7.2: Add support for Python 3.8.
0.7.1: Add support for Python 3.5, 3.6 and 3.7
Given Genshi 0.7 -> 0.7.3 involves only additional Python version support
and bugfix-only changes, this change updates the port to 0.7.3, instead of
restricting (correctly) its use to USES=python:-3.4, and is intended to be
merged to the quarterly branch accordingly.
While I'm here:
[18 lines not shown]
kbd: remove kbdsw, store pointer to driver in each keyboard_t
The previous implementation relied on a kbdsw array that mirrored the global
keyboards array. This is fine, but also requires extra locking consideration
when accessing to ensure that it's not being resized as new keyboards are
The extra pointer costs little in a struct that there are relatively few of
on any given system, and simplifies locking requirements ever-so-slightly as
we only need to consider the locking requirements of whichever method is
__FreeBSD_version is bumped as any kbd modules will need rebuilt following
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 and make
Rather than pass the address of the packet information control block to
ipf_pcksum6(), directly pass the adddress of the mbuf to it. This reduces
one pointer dereference. ipf_pcksum6() doesn't use the packet information
control block except to obtain the mbuf address.
keyboard switch definitions: standardize on c99 initializers
A future change will provide default implementations for some of these where
it makes sense and most of them are already using the genkbd
implementation (e.g. get_fkeystr, diag).
kbd drivers: use kbdd_* indirection for diag invocation
These invocations were directly calling enkbd_diag(), rather than
indirection back through kbdd_diag/kbdsw. While they're functionally
equivent, invoking kbdd_diag where feasible (i.e. not in a diag
implementation) makes it easier to visually identify locking needs in these
vfs: allow tail call optimisation in vops in the common case
Most frequently used vops boil down to checking SDT probes, doing the call and
checking again. There is no vop_post/pre in their case but the check after the
call prevents tail call optimisation from taking place. Instead, check once
upfront. Kernels with debug or vops with non-empty vop_post still don't short
Reviewed by: kib
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D22739
mtx: eliminate recursion support from thread lock
Now that it is not used after schedlock changes got merged.
Note the unlock routine temporarily still checks for it on account of just using
regular spin unlock.
This is a prelude towards a general clean up.