New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Display redetection starting/Display redetection finished #391
Comments
From my point of view display redetection is a significant non-error event. Is has ddcutil log level DDCA_SYSLOG_NOTICE. You can prevent its being logged by passing DDCA_SYSLOG_WARNING to ddca_init2(). If you don't want to use libddcutil's display status callback facility, you could create a (relatively) simple loop in your own code that watches for display related hotplug events, and only call ddca_redetect_displays() when one occurs. |
Sounds like something I should do to lower the overheads, maybe I could then check more frequently. Is there some code in ddcutil I should look to for some guidance. I guess I need something that works without DRM because that's the only reason I'm polling, to support non-DRM/buggy-DRM systems. |
Look at src/ddc/ddc_watch_displays.c, particularly functions ddc_start_watch_displays(), ddc_stop_watch_displays(), and ddc_watch_displays_using_udev(). Most of what's there can be stripped out; handling DPMS events, the use of DRM to keep track of what has changed, the complex bookkeeping. What's important for you in ddc_watch_displays_using_udev() is the polling loop that every few seconds calls udev_monitor_receive_device(). If successful, test for a display hotplug event, do whatever you need to do to signal that redetection is necessary, then call udev_device_unref(). One thing you want to watch out for is the possibility of 2 hotplug events in immediate succession, one that disconnects a monitor and second that connects it. For your purposes you probably could get by with checking for multiple events within a couple seconds and only signal a hotplug event once in that case. |
Given the progress on #390, perhaps DRM is more reliable than I first thought. If almost all drivers now properly support connectivity detection via DRM, almost everyone will be covered by Perhaps it's now unnecessary for the service to do connectivity polling to support what may only be a small number of legacy cases (and those users might not even care about connectivity detection). I'll hold off on doing any more work on polling using detect. I suppose there is the issue that DPMS state change is not always correctly reported. I suspect this polling will have to continue. (The echo detect doesn't help with DPMS). |
My own attempt at udev code only works if I also I think I should just wait for libddcutil 2.1.x where x is the version that writes detect to /sys/class/drm/card0-DP-?/status. And I should leave my old poll-detect code as is for anyone using earlier versions of libddcutil or anyone stuck with non-DRM drivers. |
Writing "detect" to the sysfs status attribute was a quick check that I was on the right track. As you've noted, its not really a solution since it requires root. DRM can be instructed via its API to update the information it exposes in /sys, but that too seems to require root privileges. I'm working on querying DRM directly using its API. in hopes that information is always current. |
After much hacking around with querying drm directly, I found an unprivileged operation that forces edid data to be updated. From the documentation for function drmModeGetConnector() in xf86drmMode.h: "This will do a forced probe on the connector to retrieve remote information such as EDIDs from the display device," I've incorporated this function in a subsystem that queries DRM to get the EDID, sleep state, etc. For test purposes, try using the following options:
Is EDID read from sysfs always correct now? However, I'm coming to think that the overhead and complexity of ensuring that the EDID in sysfs is correct negates the performance improvement over just always reading the EDID directly from the monitor. But for now I'd like to be certain that I've addressed the problem of stale information in sysfs. |
I'm getting a -3014 from ddca_register_display_status_callback(). I suspect it's because all_sysfs_i2c_info_drm() isn't finding anything that satisfies |
info->adapter_class is always NULL.
|
Added name:
|
Status code DDCRC_INVALID_OPERATION (-3014) is returned by ddca_register_display_status_callback() when it appears that not all display drivers implement DRM, which is required when watching for display connection/disconnection. I'd need to fire up my test system with a Nvidia card to confirm, but I'm pretty sure that function all_sysfs_i2c_info_drm() used by ddca_resgister_display_status_callback(), is failing because of how the Nvidia driver populates sysfs. To confirm, the output of struct Sysfs_I2C_Info by option --f2 would have NULL for the adapter_path and adapter_class. There are actually several different functions that accumulated which test whether all display drivers implement DRM. If you execute **ddcutil det --trcfunc submaster_initializer you will see the results of all_displays_drm_using_drm_api()), check_all_video_adapters_implement_drm() as well as all_sysfs_i2c_info_drm(). Can you confirm that the first two functions return true while the third return false? |
After powering up the PC and then hot plugging the Beng:
|
I've replaced function all_sysfs_i2c_info_drm() with check_all_video_adapters_implement_drm() and pushed the changes to 2.1.5-dev, so ddca_register_display_status_callback() should now work. |
When ddcutil-service optionally uses polling for hotplug detection, two messages are logged to the journal for every call to
ddc_redetect_displays()
.Ideally I don't want detect to be logged unless something has gone wrong or I've increased the level of logging above the default.
But I accept that polling by detect is not a normal use-case (although I think the plasma widget ddcci_plasmoid also does polling, so that's two applications so far).
The text was updated successfully, but these errors were encountered: