Bug#1005191: ddcutil: requires undocumented manual setup to make it usable

[Samuel Henrique]

Package: ddcutil
X-Debbugs-Cc: samu...@debian.org
Version: 1.2.1-1
Severity: normal

Hello Sanford, thank you for working on ddcutil :)

I wanted to report on a few manual steps I had to take to make ddcutil
usable for me (I'm using it through gnome-display-brightness-ddcutil).

I would like to see the ddcutil package automate this setup, or at
least ask the user if they want this to be done (if there are any
security concerns). Alternatively there could also be better messaging
on what's needed so we don't risk leaving users in the dark about it.

First I had to load the kernel module for i2c-dev:
# echo "i2c-dev" /etc/modules-load.d/i2c-dev.conf

Then I had to copy the udev rule:
# cp /usr/share/ddcutil/data/45-ddcutil-i2c.rules /etc/udev/rules.d

So to summarize, anything that could be done to help users on these
two steps would be awesome.

Also, if by any chance you're looking for help, I would be happy to
sponsor your uploads, and/or co-maintain the package and move it to
salsa.

Thanks,

--
Samuel Henrique <samueloph>

[Sanford Rockowitz]

Samuel,

Thanks for your comments.

Questions like these have come up before.  In general, not wanting to be a bull in the proverbial system configuration china shop, I've hesitated to make system-wide changes.

On Debian, ddcutil requires i2c-tools. File DEBIAN/postinst in the i2c-tools .deb package creates group i2c if it does not already exist.  Package i2c-tools also installs file /lib/udev/rules.d/60-i2c-tools.rules, which assigns the /dev/i2c* devices to group i2c:

   SUBSYSTEM=="i2c-dev",KERNEL=="i2c-[0-9]*", GROUP="i2c", MODE="0660"

File 45-ddcutil-i2c.rules contains:
 
   KERNEL=="i2c-[0-9]*", GROUP="i2c", MODE="0660"

While more precise than ddcutil's rule the one in i2c-tools.rules file should make ddcutil's unnecessary.

What installation path did you take that required you to manually install 45-ddcutil-i2c-rules?

Ensuring that i2c-dev is either built into the kernel or explicitly loaded has been to me less clear.  Would creating /etc/modules-load.d/i2c-dev.conf as you suggest always be safe?  Presumably there would have to be checks as to whether i2c-dev is loaded by some other file in modules-load.d or is built into the kernel.

At the start of execution, ddcutil checks for i2c-dev.   If it's definitely missing ddcutil issues a message and terminates execution. Unfortunately, ddcutil can't always tell (there have been bug reports when the user's environment is non-vanilla), in which case there's only a warning message.

Bottom line, would forcing the load of i2c-dev always be safe?  Would it be considered tampering with the user's environment.  Should a modprobe.d file be created  if i2c-dev is built into the kernel?

Andrey Rahmatullin has been the sponsor for ddcutil.  He's been very helpful in getting ddcutil properly packaged, but he's not always been quick to respond.  I'm sure he wouldn't mind if you took over.   There's also new package ddcui which provides a GUI version of ddcutil, and which is in need of a sponsor.

As for maintaining ddcutil in salsa, my understanding is that packages there are debianized specifically for Debian.  The ddcutil repo is distribution neutral.  I have a collection of build scripts that build ddcutil for deb and rpm systems, submitting packages to launchpad, OBS (deb and rpm variants), and COPR.  Even within the deb family some files differ between Debian, launchpad, and OBS.  There's also a feedback loop where packages are built for the several targets before the distribution tarball is released.  So it seems to me that a salsa repo would just be another artifact to manage.  But again, I have only a superficial understanding of salsa.

Though things should of course just work without the user having to dig through buried documentation, the i2c-dev requirements are documented. See pages www.ddcutil.com/config and www.ddcutil.com/kernel_module.  The "ddcutil environment" command checks that the user environment is adequately set up and makes recommendations.  (With the --verbose option, it produces voluminous information that I use for remote diagnosis.)

Thank you for whatever help or guidance you can provide.

Sanford