libddcutil monitor hotplug support

[FedeDP]

Hi! Is there any plan to support monitor hotplugging in libddcutil? I already saw ddc_watch_displays.c with dummy_display_change_handler; is there anything preventing an actual implementation?

Thank you very much for your effort and time!

[rockowitz]

Detecting display changes is just the first step. Data structures need to be updated, and these changes need to be made visible in the API. My plan is to use ddcui to better understand what needs to be done.

Can you describe your use case? Would it be sufficient for your client to reinitialize the display information if notified of a hotplug event, starting with a ddca_display_info_list2() call or must existing DDCA_Display_Handles remain valid?

[FedeDP]

Hi!

My use case is for https://github.com/FedeDP/Clightd; it exposes a Backlight dbus api to get/set backlight level, and when built with ddc support, it uses libddcutil. At the moment it is calling ddca_get_display_info_list2 everytime a call is received; and it is not catching hotplugged monitors anyway. Thus, as a quick solution, if ddca_get_display_info_list2 would detect monitors attached at runtime, it would already be great!

As a second note, i'd like to move to a new dbus API where i create a dbus object under Backlight path, for each detected monitor, eg:

• Backlight/intel_backlight
• Backlight/$mymonitorID

In this case, i would bind a DDCA_Display_Ref to each path; thus it would be great to have an "hotplug event" callback in the library, or something like that, to correctly add/remove dbus paths while they get plugged in/out.

Thanks for your time!

[FedeDP]

Hi @rockowitz! Seeing your new release had a ddca_redetect_displays(), i implemented a timeout oriented hotplug mechanism, ie: every 30s my application calls ddca_redetect_displays() to keep its own list updated.
It works great, thanks!

Fact is, i'm seeing quite some memleaks; i can share relevant valgrind output and code: Valgrind output: https://pastebin.com/awap2vFB Relevant code: https://pastebin.com/0vje9mLT

I see memory increasing steadily: started from 1Mb, it reached like 12M in a couple of days of uptime, no more than 12-13hrs of real usage, ie: laptop not suspended.

I right now tried setting 1s timeout (instead of 30s) and i can see memory usage growing up simply using kde systemmonitor.

Thank you very much by the way for your great work!

[rockowitz]

@FedeDP Hi Federico,

I believe I've plugged the memory leaks you've found. The changes are in the current development branch, 1.2.1-dev.

These are the first changes in upcoming release 1.2.1 that address a bug with significant impact. If there are no further problems I'll try to push out 1.2.1 this weekend.

Regards, Sanford

[FedeDP]

Hi @rockowitz ! Thanks for the quick response! It seems like most of them are now gone :) Unfortunately there is still one persisting, and its memory usage is growing quite fast: https://pastebin.com/V5k15eip

[rockowitz]

@FedeDP

After addressing your latest leak report, I spent much of yesterday on the hunt for memory leaks. Most of what's left is in initialization code. Let me know how it works for you.

[FedeDP]

Hi @rockowitz ! Thanks for your work! I noticed some more memleaks, thus i fixed them. I opened the https://github.com/rockowitz/ddcutil/pull/231 PR on top of 1.2.1-dev branch.

[FedeDP]

I merged the commits you pushed today in my branch; and now the only memleak that valgrind detects is about the pthread created in ddc_start_watch_displays() that lingers around.
No problem on that side though. Thanks for your hard work!