This is a race condition. Gentoo's minimal default configuration does not add unnecessary delays or dependencies to services, which means your display manager can start before the kernel input subsystem and udev have finished initializing the mouse device. Other distributions work around this implicitly through their own service configurations, but on Gentoo you have to handle it yourself.
The fix is to make the display manager wait for udev to finish settling before it starts. Systemd has a built-in service for exactly this purpose called systemd-udev-settle. It blocks until udev has finished processing all queued device events, which includes input devices like your mouse. You wire your display manager to it using a systemd drop-in file.
For SDDM, first create the drop-in directory:
mkdir -p /etc/systemd/system/sddm.service.d/
Then create the drop-in configuration file:
cat > /etc/systemd/system/sddm.service.d/wait-for-input.conf << 'EOF'
[Unit]
After=systemd-udev-settle.service
Wants=systemd-udev-settle.service
EOF
If you use LightDM instead, the steps are identical but with a different directory:
mkdir -p /etc/systemd/system/lightdm.service.d/
cat > /etc/systemd/system/lightdm.service.d/wait-for-input.conf << 'EOF'
[Unit]
After=systemd-udev-settle.service
Wants=systemd-udev-settle.service
EOF
After creating the file, reload the systemd daemon so it picks up the change:
systemctl daemon-reload
That is all. On the next reboot, systemd will start systemd-udev-settle before launching your display manager, and it will wait for all input devices to be fully registered before the login screen appears. The mouse will work on the very first try.
The reason this only affects Gentoo is that you compile and configure everything yourself. There is no distribution maintainer quietly patching service files or adding conservative boot ordering on your behalf. That level of control is what makes Gentoo great, but it also means issues like this surface in a way they simply would not on a more opinionated distribution.
If the problem persists after applying this fix, the next thing to investigate is whether your mouse and evdev drivers are compiled as kernel modules rather than built into the kernel, and whether INPUT_DEVICES is correctly set in your /etc/portage/make.conf.
