https://bugs.kde.org/show_bug.cgi?id=500951
--- Comment #4 from Sanfod Rockowitz <rockow...@minsoft.com> --- >From the tracebacks it looks like one of a couple things might be happening: A normal PowerDevil thread has opened a /dev/i2c device and is holding on to the open DDCA_Display_Handle. Meanwhile, a callback function is invoked and blocks waiting for the "normal" thread to close the open display handle. Generally speaking, display handles should be opened only briefly for executing a command, then closed. The cost of opening and closing a display handle is insignificant compared to writing to and reading from a /dev/i2c device. I had looked at clearing, as part of ddca_redetect() processing, all open display locks (internal object) held by display handles. The problem I encountered is that glib function g_mutex_unlock() can only be called from the thread that locked the mutex. If need be, I can look at implementing a more complex data structure to address this restriction. In general, it is safest that the callback function not invoke any API function that entails /dev/i2c IO. For example, ddcui's callback function simply emits a Qt signal that a display change event has occurred. I have made a small change to callback processing in branch 2.2.1-dev. Immediately prior to and after executing the callback function, events (of level NOTICE) are written to the system log. Along with libddcutil option "--trace-api" this should, if my hunch is correct, indicate how the failure occurs. -- You are receiving this mail because: You are watching all bug changes.
