Diogo Galvao writes:
> On Thu, Nov 1, 2018 at 10:15 PM Diogo Galvao <diog...@gmail.com> wrote:
> > So the condition ((wsenc & kbdvar[i].val) == kbdvar[i].val) ends up
> > being true for KB_BR & KB_SF, therefore "fr" variant gets configured.
> > That bitmasking was introduced in revision 1.15 along with a bitmask for
> > choosing keyboard options:
> >
> > https://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/xserver/config/wscons.c#
> rev1.15
> >
> > I used this small patch to get back part of the old behavior:
Thanks for the bug report (and the reminder).
The code is indeed broken in the way you describe. However, you're also
correct that reverting it would re-break the case where multiple options
are set, like us.dvorak.swapctrlcaps.
I came up with the following diff. Please give it a try.
In my tests, the following kbd(8) settings are no longer marked "using
variant fr":
ua
pt
pt.apple
lt
la
br
tr
pl
si
lv
nl
is
ee
tr.nodead, nl.nodead, is.nodead, and ee.nodead become "variant nodeadkeys"
instead of "variant fr_nodeadkeys".
cf becomes "variant fr-legacy" instead of "variant fr".
cf.nodead becomes "variant fr-legacy" instead of "variant fr_nodeadkeys".
The remainder of the 54 keyboards listed by kbd -l for pc-xt/pc-at and
usb are unchanged.
All this seems like the result we want.
ok?
Index: xserver/config/wscons.c
===================================================================
RCS file: /cvs/xenocara/xserver/config/wscons.c,v
retrieving revision 1.22
diff -u -p -r1.22 wscons.c
--- xserver/config/wscons.c 30 Jul 2018 16:00:39 -0000 1.22
+++ xserver/config/wscons.c 3 Apr 2019 15:50:16 -0000
@@ -139,7 +139,9 @@ wscons_add_keyboard(void)
break;
}
for (i = 0; kbdvar[i].val; i++)
- if ((wsenc & kbdvar[i].val) == kbdvar[i].val) {
+ if ((wsenc & kbdvar[i].val) == kbdvar[i].val &&
+ (KB_ENCODING(wsenc) == KB_ENCODING(kbdvar[i].val) ||
+ !KB_ENCODING(kbdvar[i].val))) {
LogMessageVerb(X_INFO, 3, "wskbd: using variant %s\n",
kbdvar[i].name);
input_options = input_option_new(input_options,
