Device or resource busy

[coquizen]

Clight version the issue has been seen with:

5.4.r14.ga386f97-1

Used distribution:

Manjaro (latest rolling release)

Hardware Dell 3007WFP (30" monitor from 2006)

Describe the bug I notice the following in journalctl: (i2c_set_addr ) set_addr(/dev/i2c-4,I2C_SLAVE,0x37) failed, error =EBUSY (i2c_set_addr ) addr = 0x37. filename = /dev/i2c-4, Returning EBUSY(-16): Device or resource busy

However, I know that I have to use the --force-slave-address when using ddcutil. Is there a way to inform clight to use the same flag?

ddcutil.log clight.log

[FedeDP]

Hi! Thanks for opening this request! I will investigate further; i already saw how this can be done, but i will ask ddcutil dev if there's a better way (yep my idea is quite a workaround)! By the way, moving to Clightd repository, where this does belong :) Thank you!

[FedeDP]

Hi! The latest Clightd master does now include the call to ddca_enable_force_slave_address :)
Note, however, that the API has been added to the unreleased yet ddcutil 1.2.1, thus you should wait for its release and eventually compile it (if your distro does not update it!).

[coquizen]

Ok thanks for the update... Looking forward to it.

[FedeDP]

Well it turns out, thanks to @rockowitz for pointing that out, that ddcutil already supports configuration files, thus you can achieve what you want in a ddcutil native manner :) Something like this, put in $HOME/.config/ddcutil/ddcutilrc should do the trick:

[libddcutil]
   ; And this is a comment.  Leading spaces in a line are ignored
   options: --force-slave-address

Consequently, i will indeed drop the code to use ddca_enable_force_slave_address as i don't like reinventing the wheel :) Let me know if this works fine!

[rockowitz]

@CaninoDev I'm the developer of ddcutil. I'm curious to know what program is causing the need for --force-slave-address in Clightd?

[coquizen]

My understanding is that clightd calls ddcutil, and for my system results in the above mentioned error. When I attempt to execute ddcutil via command line without —force-slave-address I receive the same errors.

Or am I misunderstanding your question?

[rockowitz]

Counter to our Unix intuition, even though the /dev/i2c device is opened RW, ddcutil does not have exclusive access to the I2C bus. Some other program can be using the bus as well. EBUSY indicates that an operation has failed because the bus is in use. Option **--force-slave-addres causes causes ddcutil to execute an ioctl() call using parm I2C_SLAVE_FORCE instead of I2_SLAVE, thereby seizing control of the bus.

So the question is what other programs are running that might conflict with ddcutil? The most common is some version of ddccontrol.

[coquizen]

AFAIK, I have no other such processes that could conflict with ddcutil. Unless, somehow, KDE conflicts with it.

[FedeDP]

If i remember correctly, kde uses ddcutil c api too, to manage external monitor backlight. But I use kde, on arch, and I don't see such an issue. Perhaps kde isn't built with ddc support on arch?

[rockowitz]

KDE PowerDevil optionally uses libddcutil. However, major distributions disable this option, as recommended by the developer. It needs to be rewritten. I doubt that it is the problem.

More likely is some other driver such as ddcci (project ddcci-driver-linux). If a user of the library is holding open a ddcci bus device (/dev/bus/ddcci/N), ddcutil will see the EBUSY error.

@CaninoDev Please run lsmod and submit the output as an attachment.

[coquizen]

lsmod.txt I also use KDE (Manjaro latest rolling release).

[rockowitz]

lsmod shows that drivers ddcci and ddcci-backlight are loaded. If some program has a /dev/bus/ddcci/N device open, that would block ddcutil. To find the program, you can use the command lsof | grep ddcci.

[coquizen]

Here is the result of that command:

lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
lsof: WARNING: can't stat() fuse.portal file system /run/user/1000/doc
      Output information may be incomplete.
clightd      2353                               root   43w      REG               0,23      4096      39277 /sys/devices/pci0000:00/0000:00:03.1/0000:07:00.0/i2c-4/4-0037/ddcci4/backlight/ddcci4/brightness
clightd      2353    2361 libusb_ev             root   43w      REG               0,23      4096      39277 /sys/devices/pci0000:00/0000:00:03.1/0000:07:00.0/i2c-4/4-0037/ddcci4/backlight/ddcci4/brightness

[rockowitz]

@FedeDP Not sure how to interpret the lsof output. Is libddcutil getting the EBUSY error because clightd has the i2c device open elsewhere?

[FedeDP]

Given the lsmod output above, i'd say he is using https://gitlab.com/ddcci-driver-linux/ddcci-driver-linux @rockowitz . ddcci and ddcci-backlight modules are from it, at least!

[rockowitz]

@FedeDP Yes, the open /sys file is for ddcci-driver-linux, but why is the command field clightd?

[FedeDP]

Uh no, clightd does only use libddcutil; does nothing on its own to talk with i2c devices.

[FedeDP]

Mmh perhaps clightd is setting backlight on all found backlight sys interfaces, and uses ddcutil for external monitor. At the same time, ddcci-backlight kernel module exports external monitors as sysfs paths, thus clightd uses them too (and sees them as internal monitors). I guess that is the reason!