Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 21 Mar 2020 21:09:23 +0700
From:      Eugene Grosbein <eugen@grosbein.net>
To:        Jan Beich <jbeich@FreeBSD.org>
Cc:        x11@FreeBSD.org
Subject:   Re: users of xorg, in particular on FreeBSD 11.3
Message-ID:  <12c44173-6e52-b3f6-d0ef-f03b4849ad88@grosbein.net>
In-Reply-To: <wo7e-2rrj-wny@FreeBSD.org>
References:  <fcad26a1-e678-3da1-3c4f-3781cb73650a@freebsd.org> <a78415f4-131a-8e25-ae22-a161eecf7493__46478.2214885176$1584748647$gmane$org@grosbein.net> <wo7e-2rrj-wny@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
21.03.2020 12:36, Jan Beich wrote:

>>> On FreeBSD 11.3, the default configuration still requires the legacy ruleset.
>>>
>>> If you are using FreeBSD 11.3, or if you are using
>>> xf86-input-keyboard on FreeBSD 12 or later, you need to change the
>>> ruleset used by x11/libxkbcommon.
>>>
>>> If you have issues with your keyboard, most notably arrow keys, and
>>> if /var/log/Xorg.*.log shows that the "kbd" or "keyboard" driver is
>>> being used, you need to switch to legacy rules by setting the
>>> environment variable XKB_DEFAULT_RULES to xorg.
>>>
>>> The easiest way to accomplish this is by adding it to your shell startup file.
>>>
>>> As an example, for users of [t]csh, put
>>>   setenv XKB_DEFAULT_RULES xorg
>>> in ~/.login
>>>
>>> For users of bourne type shells (sh, bash, ksh, zsh, ...) instead put
>>> export XKB_DEFAULT_RULES=xorg
>>> in ~/.profile
>>
>> Please consider improving x11/libxkbcommon so that it uses -Ddefault-rules=xorg
> 
> x11/libxkbcommon is also used by Wayland e.g., in x11-toolkits/gtk30.
> libinput as used by Wayland doesn't support anything but evdev.
> If one enabled evdev(4) on FreeBSD 11.* then Wayland may work after applying
> https://github.com/FreeBSDDesktop/kms-drm/pull/213
> 
>> if OSVERSION notes 11.x at build time, so there would be no breakage for us building xorg from ports.
> 
> Did you mean from binary packages? If someone builds xorg-server from
> ports it's probably due to non-default options.

Or because one builds some other application due to its non-default options
and xorg is built as dependency. Or any other reason field practice may impose,
one can't guess beforehand.

> However, the ports framework doesn't support checking ports options set in other ports
> e.g., dependencies.

Yes, and that's sad. So we may need another flavour or even distinct port
to depend on for distinct branches to avoid breakage. This is the whole idea
of Ports Collection existence, isn't it?





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12c44173-6e52-b3f6-d0ef-f03b4849ad88>