Actually we are defining databases to determine when a usb device is inherent part of the system or if it's a external device. Let's use the removable attribute of the port where it is connected to say that. That gives us the ability to not rely on a particular vendor only does external devices or to not having the need to be quirking input subsystem for that purpose that will become unreliable as more and more internal devices are connected over usb instead over ps2 or i2c buses. Eg. https://gitlab.freedesktop.org/libinput/libinput/-/commit/02b495e79022e64514015e1a3dea32997035dd4f?merge_request_iid=1389 Actually this has been seen as reliable in a small set of device from normal laptops, to detachable ones. The need to check maxchild is 0 is for detachable devices, pogo pin usbs are fixed, while we attach the keyboard|touchpad dock the input devices tend to be directly connected to that port and if the dock has more usbs tend to be a hub that then exposes removable as unknow. If we don't set maxchild 0 we will not only guess that the keyboard and touchpad are internal but also incorrectly other input devices like mice connected to the dock's usb ports. I have use a very generic name like INTEGRATION because is not actually used for any other thing and is used to determine not only over usb bus but for acpi, pci, platform actually. Also a remap to actual libinput variables is done for compatibility purposes. if it's possible to have only the INTEGRATION variable instead multiple ones will be done in the future but is actually unclear. This can also be used for example to achieve an actual feature that we lack in linux, when a device with accelerometers and cameras is rotated the video output is not, this tag the own device cameras as internal while external ones as external to be able to only do that for the internal ones. Note that this has nothing to do with the removable attribute found in usb storage devices where it's values can be 0 or 1. There is no conflict at all because the removable attribute we check is specifically the one found in usb port ones.
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS, and also repositories with packages built from the latest stable release
