Created attachment 139236 [details] powerdevil-nvidia-blob-ddc-fix.patch SUMMARY Powerdevil crashes and not properly work with nvidia blob provided i2c dcc/ci. It is looks like an old nvidia bug when ddcutils not realy like nvidia i2c. https://forums.developer.nvidia.com/t/gddccontrol-issues-with-nvidia-drivers-i2c-monitor-display-ddc-dp-hdmi-failing/30427 On boot powerdevil has not detected ddc/ci in system because ddca_get_non_table_vcp_value return error -3011(DDCRC_ALL_RESPONSES_NULL). If restart powerdevil manually, ddca_get_non_table_vcp_value return 0 and brightness control is actually is being provided, but plasma still does not "see" dbus provided services. I think it is another bug related to plasma. If restart plasmashell - brightness control come to be available. But if change brightness - powerdevil going to crash on ddcutil lib, due to bugs in second call of detect() function, that not close old display handlers and also not free resources of ddcutils lib. After crash powerdevil automatically restarts and after that cycles of hell brightness control start's to work properly. I'm prepare patch, that I'm testing now, for fix this bugs on powerdevil side. Algorithm is not the best, but it is must to work on most cases. Main idea - start detecting i2c bus that provided by nvidia blob, and introduce for this bus redetecting ddc/ci until errors come and errors count less then some magic number(for exclude potential dead loop). Also when set brightness, nvidia blob might return null response when brightness actually set, so I'm also add quirk for ignore null response and interpret this as "ok" result on blob. Now brightness control over nvidia i2c is usable. Applied patch for discussion, probably I will not push it to MR
> probably I will not push it to MR Why not?
As far as I understand, this bug is reproduced not on absolutely all nvidia GPUs(a bit strange), what side effect we will see on another hardware I don't know. If no one offers a better way and patches will keep working fine some time on my hardware, then may be MR will be good idea
ddcutil library is a sort of bugs. The only reason why dedicated ddcutil tool is work stable is because it's not running all time. It's starts, does some work and stops. In that case all works fine, but if this library is used by some daemon - random errors is occurs. I have tested my theory with loading this library dynamically(dlopen/dlsym/dlclose), so if stick with strategy of tool "open - use - close" -- all works fine. You probably may close this bug as "not a bug".
I am the developer of ddcutil. I have a few general comments, and a question. First, the ddcutil related code in PowerDevil is a proof-of-concept implementation, originally written to a pre 1.0 release of ddcutil. Its use of the current API is convoluted, and it doesn't handle multiple monitors. To be production quality it needs to be rewritten. Second, monitors vary in the quality of their DDC/CI implementation. Most are stable at the spec'd standard I2C bus speed of 100K and using the delays between operations mandated by the DDC/CI spec. Communication errors can sometimes be addressed by increasing the time ddcutil spends sleeping between DDC/CI operations (the "sleep-multiplier" value). Unfortunately, no video driver allows for tuning the speed of the I2C bus below the lowest spec'd value of 100K. Third, the DDC/CI implementation in the proprietary Nvidia driver (which is what I assume "Nvidia blob" refers to) is, shall we say, problematic. The special Nvidia settings (options nvidia NVreg_RegistryDwords=RMUseSwI2c=0x01;RMI2cSpeed=100) force the I2C bus speed to the standard 100K value. Apparently the Nvidia driver defaults to a higher speed. Some monitors will work at the higher speed, many will not, which would explain the "sometimes it makes a difference, sometimes it does not" behaviour of the special Nvidia settings. Also, ddcutil 1.3 simplified communication with driver i2c-dev by using its ioctl() interface exclusively, as opposed to the higher level file io write()/read() operations. The ioctl() and write()/read() interfaces invoke video driver operations using different functions in the driver API (for any driver). It turned out that, depending on how the Nvidia driver was built, it would reject calls to the function used for the file io interface. According to the i2c subsystem folks, this is because the Nvidia driver incorrectly interpreted a flag by which i2c-dev tells the video driver that i2c-dev is capable of DMA transfers to instead mean that DMA transfer is required. The net result for ddcutil is that a painfully large amount of code had to go back into release 1.4 to handle this special case. Regarding the problems of using libddcutil in a daemon, first I have to say that I haven't tried it. Building such a daemon is on the "sometime in the future" to do list. One issue is that there's no way to prevent different instances of applications, not just ddcutil, from using the I2C bus, and clobbering each other. The best that libddcutil can do at present is prevent different threads in the libddcutil instance from opening the same /dev/i2c bus. Beyond that issue of contention, it's not apparent to me why libddcutil should be unusable when used with dlopen() etc., and I'd like to understand what the problem is. zvova, please send me your test code. You can use either my email address (rockowitz@minsoft.com) or (even better) as an issue on the github bug tracker (https://github.com/rockowitz/ddcutil/issues).
>> it's not apparent to me why libddcutil should be unusable when used with dlopen() Vice versa. When libddcutil is used with dlopen/dlsym/dlclose - all works fine. It's important to dlclose the library. In that case library resources are freed at the dlclose moment, so the next dlopen will reinit the library and it is will work again some time.
There have been a ton of changes in how powerdevil interfaces with ddcutil over the years, particularly in Plasma 6.2 and later. Zvova, are you still seeing this issue in Plasma 6.3.5 or later with ddcutil 2.2.0 or later?
Following up on Nate's comment, I'd appreciate knowing if the problem persists with ddcutil 2.2.1-dev (built from ddcutil github branch 2.2.1-dev).
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.