Bug 259410

Summary:	x11-servers/xorg-server does not have dependency for x11-drivers/xf86-input-evdev
Product:	Ports & Packages	Reporter:	Bob Frazier <bobf>
Component:	Individual Port(s)	Assignee:	freebsd-x11 (Nobody) <x11>
Status:	New ---
Severity:	Affects Many People	CC:	grahamperrin, zeising
Priority:	---	Flags:	bugzilla: maintainer-feedback? (x11)
Version:	Latest
Hardware:	Any
OS:	Any

Description Bob Frazier 2021-10-24 17:27:21 UTC

Recently I built ports from scratch using the 2021Q4 ports tree.  Since I also updated the kernel from 12.1 to 12.2 (STABLE) I was unaware of the automatic use of EVDEV within the kernel, and a (apparently) recent change to the xorg-server behavior to always make use of EVDEV (and never use the legacy devices).

As such I had not installed x11-drivers/xf86-input-evdev in a previous release.

The handbook did not seem to point out that the EVDEV driver needed to be installed (it did have some hints on sysctl vars and related things, which did not work for me since the driver was not there).  However, through some sleuthing, I figured it out and installed the EVDEV input driver manually.  Then X11 started working properly.

It occurs to me that there needs to be some kind of dependency for this device in kernels where the default kernel includes EVDEV support, since the xorg server will not work any more without it.  And as it is a single port dependency, ir probably would not hurt to make it an option that is (by default) on so that packages also load the driver.

uname information:  FreeBSD hack.SFT.local 12.2-STABLE FreeBSD 12.2-STABLE r370671 GENERIC  amd64

Ports collection:  2021Q4
(first time observed)

(sorry if it's a bit wordy, this is really a non-critical bug that may be better solved by adding information to the handbook)

Comment 1 Niclas Zeising freebsd_committer

2021-10-25 07:42:30 UTC

xf86-input-evdev should not be needed in the general case, it is enough to use xf86-input-libinput, which is inckuded in the default installation.

Was there a specific issue that was solved by installing xf86-input-evdev?

The drivers are pulled in in the xorg-drivers metaport.

Comment 2 Bob Frazier 2021-10-25 14:52:00 UTC

(In reply to Niclas Zeising from comment #1)

> Was there a specific issue that was solved by installing xf86-input-evdev?

yes.  when I upgraded the OS to 12.2-STABLE and then re-installed all ports using 2021Q4 the xorg-server would not recognize the keyboard or mouse any more.

I did notice that xorg-drivers had not been reconfigured and so the driver for xf86-input-evdev was not enabled in the config (I enabled it).  Whether this is the case for a totally fresh install I do not know, but it would seem to me that this information should at least be in the handbook since the default kernel now includes EVDEV but the previous ones did not.  The behavior changed and it was confusing to figure out how to fix it.

So if it is not possible (or is already the case) for xf86-input-evdev to be selected (or simply included) by default for kernels newer than 12.1 (or that specifically hae EVDEV compiled in) then there really needs to be something about this in the handbook to avoid this kind of confusion, am I right?

Comment 3 Niclas Zeising freebsd_committer

2021-10-26 09:14:26 UTC

(In reply to Bob Frazier from comment #2)

xf86-input-evdev is not needed for regular keyboard and mice, unless maybe if you have some special configuration in your xorg.conf files.  However, if you have custom options enabled in xorg-drivers, maybe xf86-input-libinput was not installed (if you are using ports or building your own packages).

Currently, xorg-drivers only pull in the following:
xf86-input-keyboard
xf86-input-mouse
These are used if you don't have evdev, but might need some configuration
xf86-input-libinput
should be used in the common scenario

xf86-video-scfb
xf86-video-vesa
These are used if you don't have any graphics driver installed, or the graphics driver fail to attach to the GPU hardware.

The default configuration you get if you are using the default package set from FreeBSD.org are working out of the box.

Comment 4 Bob Frazier 2021-10-28 18:31:10 UTC

(In reply to Niclas Zeising from comment #3)

I think you are right about this up to a point, since I never needed the evdev driver before.

What I see is a little different, however.  First, when you look at the server code and the Xorg log you can see a couple of things.

(log output)
[390208.315] (II) config/devd: EVDEV_SUPPORT is enabled, ignoring device kbdmux0
[390208.315] (II) config/devd: EVDEV_SUPPORT is enabled, ignoring device psm0
[390208.315] (II) config/devd: EVDEV_SUPPORT is enabled, ignoring device sysmouse

when you find those messages about EVDEV_SUPPORT in the X server code, you can see a FreeBSD patch being applied

patch-config_devd.c

in that patch it has this section:
+       /* Skip legacy interfaces if EVDEV_SUPPORT is compiled into kernel */
+       if (evdev_support && hwtype->is_hybrid) {
+               LogMessage(X_INFO, "config/devd: EVDEV_SUPPORT is enabled, ignoring device %s\n", dev_name);
+               return;
+       }

If I interpret this correctly, it seems that the latest FreeBSD patches deliberately avouid using kbdmux0, psm0, and sysmouse.  Since the previous version of Xorg Server used these (on this same system), I never had a problem NOT having the evdev driver.  But this new thing appears to have been added within the last couple of years (my last ports collection were from 2020, version 1.18.4_12 - I could not find this block of code in the patch file).

In any case, it was a behavior change, and could affect anyone doing an upgrade from an earlier version of xorg-server without already having the evdev driver installed.

Hopefully this clarifies things.  This is basically how I discovered what I needed to do, going through the same process (log, messages, patch file).  The log (when the problem existed) actually clued me in when it "could not find the driver" but I did not initially connect the dots for needing to install the evdev input driver.

(so that's why I suggested something about this in the handbook)