feat: openrazer-daemon

[dreamyukii]

Add openrazer-daemon for configuring razer devices

[NiHaiden]

I like the idea but I also think this is a niche usecase. Maybe we should do this like Bazzite and provide a ujust command so people who want it can install it.

[dreamyukii]

I think provide ootb experience for Razer devices is not niche usecase, this daemon also not only for keyboard and mouse but for other Razer devices like laptop.

I have idea for providing sysext instead of layering but its not possible since the daemon require dkms kernel module and it will increase sysext size

[renner0e]

There is already libratbag installed for logitech, asus and steelseries mice.
What's the harm in including Razer as well?

[etvt]

Very strangely, although this PR was not yet merged successfully, I already received the changes today in 41.20250110.1:

ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx:stable-daily
                   Digest: sha256:735b1380bc47745d5ec3b1f0d6d95fc8363bf8d04e48b95764318f6ccd9694e0
                  Version: 41.20250110.1 (2025-01-10T06:17:28Z)

Seemingly generated by this: c7467d9
But GitHub also warns "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository."

Is this normal?

Edit: it is also missing the updates from 41-20250110, for example the upgrade of the kernel:
kernel 6.11.11-300.fc41 -> 6.12.7-200.fc41

[etvt]

In addition, I see that the following new packages were installed:

Added:
  openrazer-daemon-3.9.0-1.2.noarch
  python3-daemonize-2.5.0-21.fc41.noarch
  python3-setproctitle-1.3.3-2.fc41.x86_64
  xautomation-1.09-11.fc41.x86_64

I was just wondering if xautomation is really necessary, and doesn't it introduce a vulnerability to the system, where apps could interact with X apps and take screenshots (more easily than before)?

[dreamyukii]

In addition, I see that the following new packages were installed:

Added:
  openrazer-daemon-3.9.0-1.2.noarch
  python3-daemonize-2.5.0-21.fc41.noarch
  python3-setproctitle-1.3.3-2.fc41.x86_64
  xautomation-1.09-11.fc41.x86_64

I was just wondering if xautomation is really necessary, and doesn't it introduce a vulnerability to the system, where apps could interact with X apps and take screenshots (more easily than before)?

xautomation is dependency of openrazer-daemon by default and i'm not sure if you can exclude this dependency, also it should not be able to take screenshot on Wayland session and can only listen to Xwayland app since this dependency require X server to be functional

[ledif]

Very strangely, although this PR was not yet merged successfully, I already received the changes today in 41.20250110.1:

ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx:stable-daily
                   Digest: sha256:735b1380bc47745d5ec3b1f0d6d95fc8363bf8d04e48b95764318f6ccd9694e0
                  Version: 41.20250110.1 (2025-01-10T06:17:28Z)

Seemingly generated by this: c7467d9 But GitHub also warns "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository."

Is this normal?

Edit: it is also missing the updates from 41-20250110, for example the upgrade of the kernel: kernel 6.11.11-300.fc41 -> 6.12.7-200.fc41

Thanks for reporting this. This seems to be unintended behavior related to how images are pushed to the registry when attempting to merge the PR even if the merge fails. I've created an issue to track this: #99.

[ledif]

I'm going to force merge this PR because the build failures are unrelated to this PR's changes.

[etvt]

I think this should have been aurora-groups.sh.

I have the following error now:

systemctl status aurora-groups.service
....
    Process: 3407 ExecStart=/usr/libexec/aurora-groups (code=exited, status=203/EXEC)
   Main PID: 3407 (code=exited, status=203/EXEC)

[etvt]

Edit: it is also missing the updates from 41-20250110, for example the upgrade of the kernel:
kernel 6.11.11-300.fc41 -> 6.12.7-200.fc41

I think I have received the latest kernel only because I used the rebase-helper and rebased to the fixed 20250110 date. Seemingly this rebased on the latest-41.20250110 version, which has the latest kernel. Shouldn't it rebase on the stable-daily-related versions instead?