Add support for detecting older monitors in filtering logic.

[eastack]

My monitor might be too old and no devices are listed, but I can control the monitor brightness using ddcutil and a small tool I wrote myself. By bypassing the find_parent_drm_device method in the LinuxDdcDeviceEnumerator implementation and changing the contents of read_edid in LinuxDdcDevice to a constant, I can control the monitor brightness normally. The main issue on my machine now is that after retrieving the DRM device in the find_parent_drm_device function, the content read from edid_path is empty. The file exists but has no content, which might be causing a series of subsequent problems. I really like your library. Are you planning to maintain it long-term? I think this library has great potential if someone can maintain it, but I don't have much knowledge in this area.

[ju6ge]

Hi @eastack,

thanks for the compliment on my implementation of this. I do intend to improve this code over time. But my time is limited.

To the Issue at hand: Firstly the detection logic for monitors and the corresponding i2c bus is quite complex. There are multiple reasons for this. The main reason for this is: An i2c-dev may not have a parent device that is a drm device, at least not from the perspective of udev. This is even more annoying when using a docking station, in this case fake i2c channels may be found. I have to manually match the edid read from i2c, to the edid that is detected for the display by the linux drm driver stack. So if I am understanding you correctly, the edid from the drm device in your case is empty, thus the edid read from i2c can not be matched against a display device, thus leading to a situation where it is not considered a ddc channel corresponding to an attached display.

To actually get to the point where with this library I had to dig through the ddcutil source code and understand how they are doing their Phantom Device detection and reimplement that. I also had to manually check where devices in my system where "mounted". So I don't really know how to help you since it not possible for me to test with your monitor.

I can try and answer your questions regarding the codebase. And help debug the situation. If we can correctly determine what is happening exactly, the detection logic can be adjusted to take this into account.

1. Firstly what graphics driver are you using? The follow up to this is, how does your Monitor get named, and where is its information with in /sys/class/drm listed and what files exist in that directory.
2. Where does the corresponding i2c channel get mounted.
3. Lastly what does udev tell you about the device?

Kind regards, ju6ge

[eastack]

Thank you for your reply. I actually don't even know how to answer these questions. I have almost no knowledge in this area. Still, thank you for responding. I will close this issue. If I have time, I will study this topic further.

[ju6ge]

Hey,

i just add some example code on how to use a raw i2c device like a Monitor ;) https://github.com/ju6ge/libmonitor/blob/d3126b2be783c57365d8e2fe6d34e703814d43a8/examples/via-i2c-dev.rs#L1-L62

Maybe this is a better workaround for your monitor. That way you do not need to rely on the complex detection logic. But you would still need do know the i2c dev number of you monitor. But you probably can figure that out from ddcutil anyway ;)

[ju6ge]

@eastack

I also stumbled upon some inconsistencies on the monitors I use. So after some experimentation and testing I have improved the receive_edid function that queries edid data via i2c. I think it should be more reliable now.

If you have some time it would be great if you could test it and give me feedback if your monitor is detected now :crossed_fingers:. I already released a new patch release vor libmonitor 0.1.2.

Kind regards ju6ge