LWN.net's Journal
[Most Recent Entries]
[Calendar View]
Thursday, February 6th, 2020
| Time |
Event |
| 12:23a |
[$] LWN.net Weekly Edition for February 6, 2020
The LWN.net Weekly Edition for February 6, 2020 is available. | | 2:15p |
Security updates for Thursday
Security updates have been issued by CentOS (kernel-rt, qemu-kvm, spamassassin, and Xorg), Debian (ruby-rack-cors), Fedora (glibc), openSUSE (ImageMagick), Oracle (ipa, kernel, and qemu-kvm), SUSE (systemd), and Ubuntu (exiv2, mbedtls, and systemd). | | 6:13p |
[$] Better tools for kernel developers By many accounts, the kernel project uses outdated tooling, far behind the state of the art that Kids Today tend to favor. The kernel's workflow has worked well (enough) for years, but there are signs that it may not be sustainable indefinitely. As a result, there has been an ongoing conversation about improving the kernel's workflow, but little has changed so far. The posting
of a simple tool called get-lore-mboxis a sign that the rate of change may be about to increase. | | 8:13p |
Hutterer: User-specific XKB configuration - part 1 On his blog, Peter Hutterer writes about some changes that will allow users to start deploying their own rules to modify keyboard layouts without driving themselves crazy.
Many many moons ago before the Y2K bug was even in its larvae stage, the idea was that you could configure all of those because every UNIX tool had to be more flexible than your yoga teacher. I'm unsure to what extent this was actually ever the case but around 2007-ish the old keyboard driver got deprecated and the evdev driver made it's grand entrance. And one side-effect of that was that things broke. evdev uses different keycodes, so all those users that copy-pasted unnecessary XKB configuration into their xorg.conf now had broken keys because they were applying the wrong rules. After whacking enough moles that we got in trouble with the RSPCA [Royal Society for the Prevention of Cruelty to Animals] we started hardcoding the "evdev" ruleset everywhere. The xorg.conf option "XKBRules" became a noop and thus stopped breaking users' setups.
Except that it also stopped users from deploying their own rules files - something that probably didn't really matter anyway. This had some unintended side-effects though. First, to have a working custom XKB layout you basically had to get it merged upstream. Yes, you could edit the files locally but they'd just be overwritten next time you update the packages. Second, getting rid of hardcoded things is hard so we're stuck with the evdev ruleset for the forseeable future. This was the situation until, well, now.
|
|