D-Bus service for libddcutil VESA DDC Monitor Virtual Control Panel library
ddcutil-service is D-Bus service wrapper for libddcutil which implements the VESA DDC Monitor Control Command Set. In general, most things that can be controlled using a monitor's on-screen display can be controlled by this service.
-
1
derived packages
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout home:mchnz/ddcutil-service && cd $_
- Create Badge
Refresh
Refresh
Source Files
Filename | Size | Changed |
---|---|---|
ddcutil-service-1.0.12.tar.gz | 0000074168 72.4 KB | |
ddcutil-service.changes | 0000004904 4.79 KB | |
ddcutil-service.spec | 0000003719 3.63 KB |
Comments 10
This requires i2c-dev loaded which is not by default, and does nothing to ensure it does get loaded.
Apologies in advance if I may have my wires crossed, I haven't done any serious C coding in two decades. However...
Dddcutil-service doesn't directly refer to i2c-dev. I'm sure libddcutil-devel or libddcutil4 would use i2c, it's fundamental to DDC. I would not have thought I'd have to account for indirect requirements.
Is this a build requirement? I don't even have i2c-dev installed on my development machine (presumably that would be libi2c0-devel). Which is interesting, because I can build ddcutils (+libddcutil). Perhaps ddcutils is using its own i2c code, I can see its build has created a libi2c.la. Looking at ldd /usr/lib64/libddcutil.so, the output doesn't list libi2c.so, so I suspect ddcutil may well be building its own i2c library.
Puzzled.
i2c-dev is a kernel module that has to be loaded for the service to work. It's not a build requirement, it's a runtime requirement.
A program can generally link to libddcutil and work fine without i2c-dev loaded, it may be only one of many features it supports. ddcutil-service, on the other hand, only uses i2c-dev and fails completely without it, it's a hard requirement for it to work. Because of that libddcutil cannot take care of this requirement for ddcutil-service.
Also see the read-edid package in the hardware project.
I was in a hurry when I read these messages, but today I finally absorbed what you're saying.
The i2c-dev module is fundamental to getting ddcutil and libddcutil working. The ddcutil Installation help page concerning kernel modules states "Kernel module i2c-dev must be loaded. On some distributions, it is built into the Linux kernel. If not, it must be loaded explicitly.". ( https://www.ddcutil.com/kernel_module/ )
So both of ddcutil and libddcutil require i2c-dev.
Furthermore, access for non-root users will require either appropriate group-membership or an appropriate udev rule. OpenSUSE has a package ddcutil-i2c-udev-rules-1.4.1-2.4.noarch.
Somewhat unexpectedly, ddcutil-i2c-udev-rules requires libddcutil4. I would have thought it should be the other way around.
I would also expect ddcutil to require ddcutil-i2c-udev-rules. It cannot pull this dependency in indirectly via libddcutil because Ddcutil does not require libddcutil, I think ddcutil is built or coded as a separate stand alone implementation (I believe ddcutil predates the development of the libddcutil, plus I've encountered bugs in libddcutil that don't occur with the ddcutil command).
I would also expect ddcui, a GUI for which libddcutil was created, to also directly or indirectly require ddcutil-i2c-udev-rules.
In fact, nothing requires ddcutil-i2c-udev-rules-1.4.1-2.4.noarch. That may be because it's a recent addition - I suggested using udev rules to the author of ddcutil a while back.
I don't think it's ddcutil-service's responsibility to pull in the fundamentals needed for libddcutil.
Again, loading the i2c-dev module is fundamental for ddcutil-service, not libddcutil.
That's why libddcutil cannot take care of that requirement for ddcutil-service.
Adding runtime requirement to libddcutil4 is bogus, that should be generated automatically when linking to it.
Here is my interpretation of what I think you might be saying:
Although it's libddcutil that actually uses i2c-dev, it's only when a program uses libddutil that an actual runtime requirement for i2c-dev is manifested. As long as libddcutil is only installed and not used, it has no need for i2c-dev to be loaded. In general the responsibility for ensuring i2c-dev is load should fall on all programs that intend to actually use the library.
Ddcui is another program that uses libddcutil to access i2c-dev, I guess installing it should also do something to get i2c-dev loaded. Plus the command line tool ddcutil uses i2c-dev directly, so installing ddcutil should also do something to get i2c-dev loaded. I don't think either includes anything in the rpm spec to do so. I think the documentation for those programs leaves getting i2c-dev loaded as something the user needs to do manually. I guess you're saying this not an acceptable approach.
So am I correct in interpreting what you are saying?
If so, several programs need i2c-dev, should there be a common package that they can require?
(I see what you mean about adding requires-libddutil - rpm build figures this out automatically.)
It's more subtle than that. libddcutil always needs i2c-dev to really do something useful.
However, not every time libddcutil is installed it is intended to be used.
There are times when a program is built against libddcutil but there is no intent to use it.
There are programs that operate on a number of different devices, and libddcutil of one of multiple hardware-specific libraries they might use.
If ddcutil-service was running as root it could load the module.
It does not. Still the package can at least install a module-load.d file to load the module on next boot.
The service itself can also report and error when the module is not loaded.
Both of this is demonstrated in the SR.
Thanks for the detailed explanations.
We're now assuming if the ddcuitl-service is installed, there is an intent to use it. This is a fair bet, because this particular service isn't installed by default.
I see you've now allowed for the variaos packages that use i2c-dev to have their own conf file in /etc/modules-load.d/. Thanks.
I'll fold in all the changes.
I will revisit the mod_probe check. I will most likely change the C code to produce meaningful errors if the module isn't present or permissions are lacking. The service will always start, even if only to return detailed errors to the clients. The clients can present the errors to the end-user. I'm trying to avoid the user having to any detective work to find out why the service isn't working.
As well as adding
/usr/lib/modules-load.d/ddcutil-service.conf
, I'm also going to add a%post
to theddcutil-service.spec
that does amodprobe i2c-dev
. That should hopefully ensure the service works immediately after installation without the user having to use sudo or reboot. Plus it should ensure an install error if i2c-dev isn't available.I've added a runtime requirement of libddcutil4, I think that drags in everything needed.