xfree86: move the xf86-input-mouse driver in-tree

[metux]

The driver is relatively simple, unlikely that we're getting anything substantial from xorg, and it's much faster to build in-tree.

Thus dropping the hassle of maintaining it internally by just moving it in-tree.
It can be disabled at build time via meson.

[b-aaz]

I still disagree with this move. The FreeBSD/Dragonfly build system of these entire ports are dependent on them being separate.
And now that they have finally been moved into the ports tree these sets of changes can put a spoke in the wheels of the porting process.

IDK, if it really does improve the developer experience to be worth it ,,, ,

[callmetango]

I think we should first find an agreement on Incorporating drivers into Xserver tree · X11Libre · Discussion #207 before creating more pull requests.

[metux]

I still disagree with this move. The FreeBSD/Dragonfly build system of these entire ports are dependent on them being separate.

I somewhat doubt that this little change makes so much trouble. For transition, the xf86-input-mouse package could become just a empty/meta-package depending on the Xserver itself (with proper build flags). This isn't a new situation, actually pretty common. And for binary packaging: the driver .so file can still can be split out into separate binary package.
That also is quite common.

I'm not going to merge this within 25.1 window (only few days left to release), deferring it to 25.2.

IDK, if it really does improve the developer experience to be worth it ,,, ,

It does. See my comment at https://github.com/orgs/X11Libre/discussions/207:

In order to move to a clean architecture and actually easily understandable architecture and API, as well as planned new features, we need to do a lot of changes that are currently API/ABI breaking, and so we would have to introduce lots of per-xserver-version specific hacks into the drivers again. When moving the drivers in-tree, we don't need that at all, and could trim down individual driver code even more (eg. move more common code to common places), w/o ever having to care about potential ABI breaks. (we only still need to be careful with those things needed by the proprietary nvidia driver - until we've got it replaced entirely).

Another problem is the huge version matrix: right now each driver existing in many versions, and there might be subtle dependencies between individual drivers's and Xserver's version. The matrix has as much dimensions as we have drivers (plus 1 for the Xserver). Moving all drivers in-tree reduces this to just one.

[cepelinas9000]

I still disagree with this move. The FreeBSD/Dragonfly build system of these entire ports are dependent on them being separate.

I'm not maintainer - it more to do with logistics and transition period, as maintainer wants to build that one driver and nothing more. After this move (moving driver to in-tree) the problem becomes: how to build it?, what configuration switches to use (it will be multiple PR's), how to separate only driver with it files (man, *.conf, etc..) for package.

@metux I always wondering, why these drivers cannot be included as git submodules? There a lot of sharp corner cases with meson or it is too much maintenance burden?

[metux]

I'm not maintainer - it more to do with logistics and transition period, as maintainer wants to build that one driver and nothing more.

This already isn't the case with several drivers (eg. modesetting) and extra modules (vgahw, int10, glx, ....), since they've never been splitted out.

I actually wonder why somebody insisting in compiling just this one driver separately, even though it already needs to be compiled against the matching Xserver version. It's pretty small (just 60kb on amd64).
Does he also insist doing that with kernel modules, gstreamer modules, various gdk/gtk backends, etc, etc ?

After this move (moving driver to in-tree) the problem becomes: how to build it?,

Automatically built along with the Xserver, just like with already in-tree driver (eg modesetting) and various other modules.

what configuration switches to use (it will be multiple PR's),

enabled by default, to disable it pass -Dxf86-input-mouse=false ... standard meson options (see meson_options.txt)

how to separate only driver with it files (man, *.conf, etc..) for package.

not sure how exactly that's one on BSD, but in .deb or .rpm world, just putting the these file names into the corresponding binary-package's file list.

@metux I always wondering, why these drivers cannot be included as git submodules? There a lot of sharp corner cases with meson or it is too much maintenance burden?

That would also be in-tree. But more complicated on our side as well as downstreams/distros (needs additionally care on clone/checkout, harder to mirror, extra commits in parent repo, etc, etc). Submodules only make sense if something's coming from another vendor and used inside several parent repos - neither one is the case here.

[artist4xlibre]

I did a build from branch pr/mouse-intree.
Also built xf86-input-libinput from git and installed both packages on a test system.

Then noticed what seems to be a discrepancy:

$ ls /usr/lib/xorg/modules/xlibre-25*/input
/usr/lib/xorg/modules/xlibre-25.0/input:
libinput_drv.so

/usr/lib/xorg/modules/xlibre-25/input:
inputtest_drv.so  mouse_drv.so

[cepelinas9000]

not sure how exactly that's one on BSD, but in .deb or .rpm world, just putting the these file names into the corresponding binary-package's file list.

Main complaint is about which one files? as tedious part is to keep file list up-to date.

I tried experiment with this, even meson have almost necessary functionality (install_tag parameter). for sample implementation see: cepelinas9000@2bd4dc0

You can install part of project with meson install --tags xf86-input-inputtest, meson install --tags xf86-video-modesetting or everything with meson install.

the problems i found (meson v1.8.1): configure_file ignores install_tag and by default configure_file have no any tag and cannot be installed separately (i mean with meson install --tags ...)

I think if xserver gain functionality only install files for specific drivers only. @callmetango @b-aaz and other maintainers would keep complains to minimum?

[artist4xlibre]

@cepelinas9000 All I had to do was adding the man page to the packaging; as file mouse_drv.so gets copied as part of the xorg/modules directory.
To check which files are required just check an existing separate package.

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[metux]

Note that about 1kLOC are only needed for the whole build stuff - and they'll be getting even much more when we're adding BSD driver builds to CI. For this particular driver it's about 1/8. For some other drivers, that ratio can even be much bigger.

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found