mattanger / ckb-next

RGB Driver for Linux and OS X
http://forum.corsair.com/v3/showthread.php?t=133929
GNU General Public License v2.0
654 stars 76 forks source link

CMake Conversion #32

Closed mattanger closed 6 years ago

mattanger commented 7 years ago

@light2yellow and I are both working on the conversion from qmake to cmake. We'll be using this issue to track progress and note issues related to building with cmake.

tatokis commented 7 years ago

They meant that there was a patch in the rpm itself that forced /var/run during packaging.

Either way, /dev/input/ckb should be the right place, I suggest switching to that if no obvious issues are observed.

hevanaa commented 7 years ago

Thanks. OK, I will use /dev/input. I have no idea why the Suse rpm uses /var/run.

hevanaa commented 7 years ago

While talking about packaging. There are a few platform specific files in the source, like desktop file and systemd startup script.

In the Fedora rpm, I've also added a systemd preset file, an appdata.xml and a man page for ckb (see https://github.com/hevanaa/ckb-spec/tree/master/SOURCES). In my opinion at least the preset file and also the appdata file could belong to the source (they are Freedesktop standard and used in many linux distros). The man page could in theory be auto-generated and is of course not really necessary, just nice to have. Should I open a separate issue for adding these files?

Edit, need to think over this further. The systemd preset file, while working fine is not a good idea. The service should be started by an udev rule when the hardware is detected, not by the installation package.

Edit 2: Creating udev rules to start the service feels complicated, due to the amount of supported and not supported devices. I think I'm fine with the preset file and in addition explicitly starting the daemon during installation, even though it is not recommended by Fedora guidelines.

ghost commented 7 years ago

@hevanaa

In my opinion at least the preset file and also the appdata file could belong to the source (they are Freedesktop standard and used in many linux distros).

While true, freedesktop's page on presets tells us in the "Why?" section that different distros use different rules. I see no reason providing a generic preset when a local machine administrator can decide what is the best for him if he really needs the presets. Everyone else will benefit from a script enabling and starting the service automatically.

The systemd preset file, while working fine is not a good idea. The service should be started by an udev rule when the hardware is detected, not by the installation package.

Udev rules are not a good idea because with udev rules one cannot easily disable the daemon and not use ckb without uninstalling it, with the service one can easily do systemctl disable foo and it's done. It's not that udev rules are hard to write but the amount of issues containing "I disabled the service with systemctl disable but it still starts when I plug in the keyboard!" phrase.

even though it is not recommended by Fedora guidelines

That's the case. You can do anything what the guidelines encourage you to, but there still must me an easy and working solution for people who don't have packages. And the solution cannot follow the guidelines of a specific distribution. It can, however, follow the general guidelines but in this case presets are very distro-specific things. Moreover, there are scripts for OpenRC and upstart too, this tries to be as distro- and init-agnostic as possible.

hevanaa commented 7 years ago

@light2yellow Thanks for discussing these things. It is not always easy to know which is the best option when you can do things in many different ways. I will keep the distro-specific things downstream.