Auto-detect which i2c bus to use

[alexeightsix]

After upgrading from Fedora 40 to 41 the script has stopped working.

/home/alex/.cargo/bin/fury-renegade-rgb -b /dev/i2c-7 -2 -4 brightness --value 0
Error:
   0: Input/output error (os error 5)

Location:
   /home/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/fury-renegade-rgb-0.1.0/src/fury_commands.rs:103

Backtrace omitted.
Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                                ⋮ 3 frames hidden ⋮
   4: fury_renegade_rgb::main::ha8668f91e3426857
      at <unknown source file>:<unknown line>
   5: std::sys_common::backtrace::__rust_begin_short_backtrace::h8f9d9e1c84bf02d9
      at <unknown source file>:<unknown line>
   6: std::rt::lang_start::{{closure}}::hfcdb5f4f87b27fed
      at <unknown source file>:<unknown line>
   7: std::rt::lang_start_internal::hcee5ed89fc25829a
      at <unknown source file>:<unknown line>
   8: main<unknown>
      at <unknown source file>:<unknown line>
   9: __libc_start_call_main<unknown>
      at <unknown source file>:<unknown line>
  10: __libc_start_main_alias_1<unknown>
      at <unknown source file>:<unknown line>
  11: _start<unknown>
      at <unknown source file>:<unknown line>

I'm unsure what in the upgrade broke the binary. If you have any ideas let me know.

Thanks

[ARitz-Cracker]

These things have always been a little finicky to work with and to this day I have no idea why.

Are ya comfortable with re-building this project but with changing this line to io_err.raw_os_error() == Some(6) || io_err.raw_os_error() == Some(5)?

[ARitz-Cracker]

I also never really looked into how linux determines the order of i2c busses, have you confirmed that the Fedora upgrade didn't move your i2c bus files around?

[alexeightsix]

The command takes about 10 seconds to execute then crashes:

➜ debug (main) ✗ ./fury-renegade-rgb -b /dev/i2c-7 -2 -4 brightness --value 0
Error:
   0: Input/output error (os error 5)

Location:
   src/fury_commands.rs:103

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                                ⋮ 5 frames hidden ⋮
   6: <core::result::Result<T,F> as core::ops::try_trait::FromResidual<core::result::Result<core::convert::Infallible,E>>>::from_residual::hb71983b731e368a3
      at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/core/src/result.rs:1989
   7: fury_renegade_rgb::fury_commands::MultiRamController::write_to_all::hf0535fe8f7b3305e
      at /home/alex/tmp/fury-renegade-rgb/src/fury_commands.rs:103
   8: fury_renegade_rgb::fury_commands::MultiRamController::start_command::hf1e3f191d35e1e47
      at /home/alex/tmp/fury-renegade-rgb/src/fury_commands.rs:109
   9: fury_renegade_rgb::fury_commands::MultiRamController::set_brightness_percent::h43e29eed24fe03fe
      at /home/alex/tmp/fury-renegade-rgb/src/fury_commands.rs:158
  10: fury_renegade_rgb::main::hd23474b23c897a06
      at /home/alex/tmp/fury-renegade-rgb/src/main.rs:159
  11: core::ops::function::FnOnce::call_once::hcfe86e0d77531b74
      at /rustc/3f5fd8dd41153bc5fdca9427e9e05be2c767ba23/library/core/src/ops/function.rs:250
                                ⋮ 16 frames hidden ⋮

Run with COLORBT_SHOW_HIDDEN=1 environment variable to disable frame filtering.
Run with RUST_BACKTRACE=full to include source snippets.

I can always roll back the OS update and let you know of the issue still happens to be sure.

[alexeightsix]

I also never really looked into how linux determines the order of i2c busses, have you confirmed that the Fedora upgrade didn't move your i2c bus files around?

Not yet, I can dig into this and get back to you.

They seem to be in the same place

➜ /dev ls | grep i2c
i2c-0
i2c-1
i2c-2
i2c-3
i2c-4
i2c-5
i2c-6
i2c-7
i2c-8
i2c-9

[alexeightsix]

Small Update for anyone interested

It randomly started working again yesterday. The only changes I made (unintentionally) was unplugging my USB Mic (Blue Yeti) from my USB Switch/Hub directly into the Motherboards USB. I also unplugged my ethernet cable from a switch directly into the motherboard as well.

I can try plugging the mic/ethernet (not sure why ethernet would affect this though) if somebody is interested.

➜ kickstart (master) ✗ sudo /home/alex/.cargo/bin/fury-renegade-rgb -b /dev/i2c-7 -2 -4 brightness --value 0
➜ kickstart (master) ✗ echo $?
0

Thanks

[ARitz-Cracker]

Hey, being pinged on your comment reminded me that I did some additional research on this, basically:

• /dev/i2c-* can indeed be non-deterministic in some circumstances circumstances. Since you're on a rolling release distro related to RHEL, subtle changes to the way your system handles enumerating PnP devices wouldn't surprise me, especially since stuff like hot swappable PCIe devices are a common thing in enterprise environments and systemd has been a consistent trend of just doing whatever and expecting applications to cope or ask it what the hell it's thinking.
• Since /dev/i2c-1 works on my machine, I looked for it in the /sys folder.
• After doing ls -l /sys/class/i2c-dev/i2c-1/device, I noticed an interesting symlink device -> ../../0000:00:14.0, wich corresponds to the following entry on lspci...

00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 71)
        Subsystem: ASUSTeK Computer Inc. FCH SMBus Controller
        Flags: 66MHz, medium devsel, IOMMU group 11
        Kernel driver in use: piix4_smbus
        Kernel modules: i2c_piix4, sp5100_tco

...on my R9 7950X3D + ROG STRIX X670E-E GAMING WIFI. Which... provides 3 i2c busses, and on my system the RAM RGB controller is connected to the first one it provides.

At the very least, this should help in determining what i2c device you should use if it ever moves around again. I don't have time in the foreseeable future to know what the "proper" way of finding the correct i2c device is unfortunately. (Asking systemd via dbus? How should I probe the bus for the RAM w/o risking wiping your BIOS settings?) So I'll leave this issue open for now.

[ARitz-Cracker]

Additional notes:

• The i2c bus used by my ram did not change when moving from Ubuntu 22 to Debian 13.
• Didn't notice before, (is this a new feature?) but we can get the name of the i2c bus directly from sysfs

for f in ./*/name; do echo $f; cat $f; done;
./i2c-0/name
Synopsys DesignWare I2C adapter
./i2c-10/name
NVIDIA i2c adapter 7 at 1:00.0
./i2c-1/name
SMBus PIIX4 adapter port 0 at 0b00
./i2c-2/name
SMBus PIIX4 adapter port 2 at 0b00
./i2c-3/name
SMBus PIIX4 adapter port 1 at 0b20
./i2c-4/name
NVIDIA i2c adapter 1 at 1:00.0
./i2c-5/name
NVIDIA i2c adapter 2 at 1:00.0
./i2c-6/name
NVIDIA i2c adapter 3 at 1:00.0
./i2c-7/name
NVIDIA i2c adapter 4 at 1:00.0
./i2c-8/name
NVIDIA i2c adapter 5 at 1:00.0
./i2c-9/name
NVIDIA i2c adapter 6 at 1:00.0

additionally...

aritz@Unrelenter:/sys/class/i2c-dev$ ls -l
total 0
lrwxrwxrwx 1 root root 0 Aug 11 11:08 i2c-0 -> ../../devices/platform/AMDI0010:00/i2c-0/i2c-dev/i2c-0
lrwxrwxrwx 1 root root 0 Aug 11 11:08 i2c-1 -> ../../devices/pci0000:00/0000:00:14.0/i2c-1/i2c-dev/i2c-1
lrwxrwxrwx 1 root root 0 Aug 11 11:08 i2c-10 -> ../../devices/pci0000:00/0000:00:01.1/0000:01:00.0/i2c-10/i2c-dev/i2c-10
lrwxrwxrwx 1 root root 0 Aug 11 11:08 i2c-2 -> ../../devices/pci0000:00/0000:00:14.0/i2c-2/i2c-dev/i2c-2
lrwxrwxrwx 1 root root 0 Aug 11 11:08 i2c-3 -> ../../devices/pci0000:00/0000:00:14.0/i2c-3/i2c-dev/i2c-3
lrwxrwxrwx 1 root root 0 Aug 11 11:08 i2c-4 -> ../../devices/pci0000:00/0000:00:01.1/0000:01:00.0/i2c-4/i2c-dev/i2c-4
lrwxrwxrwx 1 root root 0 Aug 11 11:08 i2c-5 -> ../../devices/pci0000:00/0000:00:01.1/0000:01:00.0/i2c-5/i2c-dev/i2c-5
lrwxrwxrwx 1 root root 0 Aug 11 11:08 i2c-6 -> ../../devices/pci0000:00/0000:00:01.1/0000:01:00.0/i2c-6/i2c-dev/i2c-6
lrwxrwxrwx 1 root root 0 Aug 11 11:08 i2c-7 -> ../../devices/pci0000:00/0000:00:01.1/0000:01:00.0/i2c-7/i2c-dev/i2c-7
lrwxrwxrwx 1 root root 0 Aug 11 11:08 i2c-8 -> ../../devices/pci0000:00/0000:00:01.1/0000:01:00.0/i2c-8/i2c-dev/i2c-8
lrwxrwxrwx 1 root root 0 Aug 11 11:08 i2c-9 -> ../../devices/pci0000:00/0000:00:01.1/0000:01:00.0/i2c-9/i2c-dev/i2c-9

We can conclude, though again this is specific to my motherboard, that the i2c bus which the RGB controller connects to is a PCIe device with the lowest depth (not associated with a slot?), and to avoid the i2c bus that's part of the "platform". (Don't 100% know what a platform device is, but it seems to relate to things like ACPI, SoC stuff, or so-called "legacy" PC interconnects.