Udev rule for i2c device permission

[CromFr]

I'm using the following udev rule for setting rights for the i2c devices:

KERNEL=="i2c-[0-9]*", GROUP="i2c", MODE="0660", PROGRAM="/usr/bin/ddcutil --bus=%n capabilities"

where I replaced the i2c group with my user group.

This is very similar to the USB rule in http://www.ddcutil.com/i2c_permissions/, however I did not find any "quick" way to check if the i2c device is a ddc device (what chkusbmon does for usb), and I ended up querying all the capabilities (which is probably overkill).

Anyway you may find this interesting to add to the documentation ;)

[rockowitz]

I apologize for taking a few days to reply to your message.  Reviewing it turned out to reveal a bug in the --bus option in the development version of ddcutil. The udev rule in sample file 45-ddcutil-i2c.rules is essentially the same rule installed on some (but not all) distros by package i2c-tools. KERNEL=="i2c-[0-9]*", GROUP="i2c", MODE="0660" Creating a group containing only MCCS capable USB devices is important in the USB case because probing can confuse USB input devices such as keyboards.   See for example the recently reported  issue #84, Trackpoint Freezes After Getting Data From Monitor". Clearly, you're trying to create a group containing only DDC/CI capable i2c devices. What I would suggest is using a simpler ddcutil command to probe for ddc capable i2c devices:    PROGRAM=/usr/bin/ddcutil --bus=%n getvcp 10 In practical terms, I've yet to encounter a ddc capable display that does not support VCP feature x10 (Brightness) The use of capabilities in this context is problematic.  First, it entails the use of multiple write/read sequences to get the entire capabilities string.  Each of the write/read transactions, along with the meta-sequence, is subject to I2C retries.  So capabilities is a particularly expensive command, especially on a monitor with a poor DDC implementation.  getvcp will do the job more cheaply and reliably. Also, though you're not relying on the content of the capabilities string in this case, only on whether the command succeeds, it's worth bearing in mind that the capabilities string reported by a monitor often does not match its true capabilities.  It's just a hint, and ddcutil avoids using its output, insofar as possible. It would be possible to create a command similar to chkusbmon for ddc devices that exposes just the logic for testing whether an i2c device represents a ddc capable monitor, but I for now I believe using the getvcp command effectively does the job in your case. I'm reluctant to add yet another command to ddcutil.  If many others would also find a "chkddcmon" command useful, then of course I'd reconsider. Regards, Sanford

…

On 5/6/19 8:04 AM, Thibaut CHARLES wrote: I'm using the following udev rule for setting rights for the i2c devices: |KERNEL=="i2c-[0-9]*", GROUP="i2c", MODE="0660", PROGRAM="/usr/bin/ddcutil --bus=%n capabilities" | where I replaced the |i2c| group with my user group. This is very similar to the USB rule in http://www.ddcutil.com/i2c_permissions/, however I did not find any "quick" way to check if the i2c device is a ddc device (what chkusbmon does for usb), and I ended up querying all the capabilities (which is probably overkill). Anyway it may be interesting to add this rule to the documentation ;) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#85>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADMGY3UZVP72B2KARUVGLSDPUANEPANCNFSM4HK7NQBA>.

[CromFr]

Thank you so much for your very detailed response !

I originally used getvcp 0x10, but I was afraid I might end up with an unsupported display. I'll switch back to 0x10 following your advice.

Thank you for your work on ddcutil, it's now essential to me for switching multiple screen inputs between my host and VMs :)