https://bugs.kde.org/show_bug.cgi?id=523824
--- Comment #8 from [email protected] --- Putting some notes here, as I tried looking into things a bit more. As this is a lengthy follow up, also reiterating that the installed version of `ddcutil` is `2.2.7-1`, from the `ddcutil` package in the official ArchLinux `extra` repository. Additionally I am holding off system updates while this is being looked into (at least for the time being) As for the notes: - `ddcutil` was pointed out as being the root of the crash by TraceyC. - Trying to follow the backtrace myself, and learning surface level info about what HDMI EDID info is, I managed to query my monitor while its connected with `edid-decode` (from `read-edid` package) - This responds with full info! But the journal logged that `powerdevil` failed to get any? - Checking journal entries more, I see that before the segfault, it failed to read from `/dev/i2c-0`, but the display tablet was registered on `/dev/i2c-4`? - From looking at source code for `ddcutil`'s `2.2.7-release` branch on github, I wasn't able to really make sense of how the code was functioning in detail or where the exact issue may be. Comparing with `2.2.7-patched`, there are differences in `i2c_check_open_bus_alive()` definition in `i2c_bus_core.c`, which from my understanding of the traces is where the crash occurs, but I don't understand how those differences affect the actual program. That function was not modified going from `2.2.6-release` to `2.2.7-release`, interestingly. >From what I think I understand, ddcutil is not reading the correct display handle/pointer for some reason, thus causing the crash as it tries to read from an invalid pointer/handle. May be wrong, but that's what stands out to me first, given the C assert checks were removed in the patched branch (though whether or not that's the exact version I have on my system and in Arch package repos, I can't say for certain). I can maybe run some tests with the other tablet or random other monitors we have laying around. The wacom tablet is also a little unique, in that it has to be connected physically, then put into sleep mode, in order for it to actually be connected as a display for the main system. This is because the Wacom MobileStudioPro is also a full standalone computer as well, and so it must be put into sleep mode while connected to change into being a connected display by a parent system. This can be done directly via USB-C Thunderbolt 3, if the host system supports it (mine does not), or more commonly via an adapter that splits the signal to USB-A and either Mini-DisplayPort or HDMI. In my case I use HDMI. The observed issues happen with both an HDMI to DisplayPort (full) cable and normal HDMI to HDMI cable, both known to be good. EDID info is available via manual query with `edid-decode`, so I would imagine any hardware in between is also likely at fault. At leas tnot beyond it just being rather unique hardware and potentially not 100% supported by lower level utilities like this. Earlier in the journal from a more recent test, the kernel and amdgpu report an error getting EDID as well. Hopefully all this information and curious look at the codebase as well is more helpful info. Finally, I'm able to very reliably and easily reproduce the crash, as it happens every time I simply connect my tablet, and seemingly always in the exact same manner (or at least, pretty much identical crash info and logs). As such if there's anything I can do to get more detailed info beyond a stack trace that may assist in debugging and patching, please let me know! Should I also change the status from NEEDSINFO/WAITINGFORINFO back to REPORTED? I'm not sure if this is correct practice for bug reporting once the requested info is given, as I wasn't able to find any source about this, and its not explained on the KDE Wiki. If there's no other responses to this in a week, I'll do so just to be sure the report isnt automatically closed or anything. -- You are receiving this mail because: You are watching all bug changes.
