libddcutil -3021 "DDCRC_INTERNAL_ERROR" #390
Comments
|
Try passing option --trcapi ddca_get_non_table_vcp_value to libddcutil by putting it config file ddcutilrc. This should give more detail as to what the internal error is. |
|
The return code is coming from ddc_validate_display_ref called from ddca_open_display3 via ddca_open_display2. Still investigating... it's because drm_connector is NULL. |
|
If I disable drm by adding --f12 to ~/.config/ddcutil/ddcutilrc, then the problem goes away. Maybe this nvidia 550 driver's DRM is not quite all there. |
|
What's the output of ddcutil det -v --f2? |
|
|
The log I attached might not contain anything useful. This is beginning to look like some driver weirdness. Yesterday I connected the monitor while the system was up. This morning I cold booted this morning and the issue no longer occurs. I'll see if I can cause the problem to reoccur. BTW, the beng is connected by DVI-DP, the previous Nvidia driver had issues with DVI-DP, so maybe that's a factor. |
|
I did a cold boot and then a hot-plug of the Beng, and the fault reoccurred. Log attached. Diff'ing the two logs shows that DRM doesn't appear to be properly initialized for the hotplugged monitor. Exact process.
|
|
It's the driver. I powered down an disconnected my HP DP-DP connected monitor. Same story on hotplugging. This is not a big issue for me, but it might be for anyone with a laptop that might routinely hotplug a monitor. |
|
Posted a query to forums.developer.nvidia.com: Driver 550.54 - no update to /sys/class/drm/… on hotplug of monitor Sometimes these kinds of post get no official response - but often things eventually get fixed. I figure it can't hurt to make some noise. |
|
I've seen this behaviour. On my deskstop system, I've found that if a monitor is removed the edid can still be there, and if a different monitor is connected the edid value is unchanged. I backed off on using the sysfs edid value instead of reading the edid directly - I may need to back off even more. A couple days ago I tried creating some test cases to demonstrate the behaviour for an intended amdgpu drm bug report, |
It appears that DRM is not all there yet. Perhaps it's not yet essential to desktop environment, so the imperfections are not making enough waves.
Generally ddcutil/libddcutil has been pretty solid. Having dodgy drivers undermine that experience is a shame. I'd prefer to back off to the point where users aren't bothered by these problems. Possibly some advanced options should default to off. Documentation could explain that an option may require specific GPUs and GPU-drivers. Perhaps even mentioning which GPUs and drivers are currently known to work well. |
|
As a first step, I've added some asserts, which along with valgrind should indicate where the g_path_get_basename() calls are failing and suggest where to look further. As you can see from the branch 2.1.5 git log I've also improved tracing which should help with the next step. |
|
So I should test with the latest code? Or is this something you are pursuing yourself? |
|
Yes, please test with the latest code. Until I can reliably recreate the problem here, all I can do is stare at the code. Thanks. |
|
Only the 2.1.5-dev branch has any recent commits, but they're not recent as in today. Am I not seeing things right? |
|
Doing too many things today .. I just pushed the changes. |
|
I'm not seeing anything interesting. So I'm seeing no assertions firing on a getvcp. And --trcapi ddca_get_non_table_vcp_value didn't log anything extra. |
|
So if you run the exact same steps that produced ddcutil-det-f2-problem.log, you get the same output as before with the GLib-CRITICAL msgs re g_path_get_basename, but no asserts in libddcutil. Is that correct? |
Accessing |
|
The assert failure in drm_common.c has been fixed. I came across a clue this afternoon as to why a test case for for the missing DRM information is elusive. See https://super-unix.com/unixlinux/linux-how-to-make-linux-detect-re-probe-monitors-with-intel-i915-driver/ and section "Force-probing a connector" in https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html |
|
Works here too. But I still get -3021 "DDCRC_INTERNAL_ERROR" if I do: |
|
It's a proof of concept hack, but try the following in your failure scenario:
If the above works, then ensure that ddcutil-service calls ddca_redetect_displays() at least once.
|
|
Yes, that works. The echo needs to be done as root, so another udev rule is probably required. After writing the status, as well as |
|
[Edited to correct - misread the output] With the latest code detect is still not correctly reporting the EDID for card-0-dp2, although --f2 causes a segmentation fault. |
|
Running with gdb and using where results in: |
|
The previous test of of a service GetVCP that failed in the first comment of this issue, now works: In doing these recent tests, I did as before. I plugged in and connected the Beng after the system was already up. One thing though, the status of the Beng is still disconnected: But if I have root do |
|
Note that |
|
A fix for the segfault in get_enum_value_name() has been pushed to branch 2.1.5-dev |
|
What happens now if you run through your test sequence with ddcutil detect -v --enable-try-get-edid-from-sysfs --f15 What is the output of cat /sys/class/drm/card0-DP-2/edid | parse-edid before and after the above command? |
|
Powered up PC, connected Beng, used nvidia-settings to enable the added Beng. Found that |
I plugged in my old beng monitor, it works fine with ddcutil-service+libddcutil-1.4 and with with ddcutil 2.1.5-dev command. But errors when I use ddcutil-service with libddcutil-2.1.5-dev it errors:
Detect is working fine:
I'll look into this more later, but I thought I let you know ASAP. It may have been happening with earlier version too, but I had Nvidia issues so I hadn't plugged in this monitor.
The text was updated successfully, but these errors were encountered: