arcnmx / ddc-hi-rs

DDC/CI high level crate
MIT License
23 stars 8 forks source link

Feature: Get display using identifier #4

Closed ThalusA closed 2 years ago

ThalusA commented 2 years ago

Hi, is this possible to get a display using some kind of generated UUID? I'm struggling to make my code work using this way: https://github.com/ThalusA/ddc-enhanced-rs/blob/master/src/lib.rs The only problem is that when I get or set the brightness enhanced_display.inner_display.info.mccs_database.get or enhanced_display.inner_display.handle.get_vcp_feature seems to enter into some kind of deadlock state because it's just doing nothing and my program won't stop.

arcnmx commented 2 years ago

So, this crate only gives you a list of detected monitor objects. To work with a specific real display, you have to filter or sort them in some fashion that’s meaningful to your program. Generally this is done by looking at their display_info, which you can use directly or use the Query interface to do this for you.

You can query by display_info.id, which is effectively a generated unique identifier. However, note that this ID may or may not be stable across restarts depending on the backend used (I prefer to search based on some combination of manufacturer id, model, or serial when working with persistent config data).

As for a deadlock occurring when getting the brightness, could you try using the ddcset program with RUST_LOG=verbose set? (alternatively, you could enable logging in your own program to get the same result) It’s difficult to tell what’s wrong without having some additional info. It might help to get a log of println!("{:#?}", enhanced_display.inner_display.info) to tell which MCCS database version you’re using - if this is indeed an issue with MCCS rather than DDC it should be very simple to make a small reproduction test case. I'll try to take a look in the meantime if I get a chance to.

ThalusA commented 2 years ago

There is a problem, my two screen have the same identifier (I'm using Windows 11)

.\ddcset-win64.exe detect -c
Display on winapi:
        ID: Generic PnP Monitor
        Model: U28G2AE
        MCCS: 2.2
Display on winapi:
        ID: Generic PnP Monitor
        MCCS: 2.1

.\ddcset-win64.exe -l U28G2AE getvcp 10
Display on winapi:
        ID: Generic PnP Monitor
        Feature 0x10 = 70 / 100

However on an application such as HWInfo I get much more information about my screen, like it's Serial Number for example image Do you think it's normal, because I would love to have a way to identify which screen is which, or just differentiate them ?

ThalusA commented 2 years ago

I did changed my code and I'm still getting a thread 'main' has overflowed its stack while just getting brightness also :/ If you can give me advice I don't mind. PS: I looked at your code but I don't understand why your code works but not mine

arcnmx commented 2 years ago

There is a problem, my two screen have the same identifier

yes, the id really should not be assigned like this. There may be limited information for it to use, but even an index would be an improvement over that.

However on an application such as HWInfo I get much more information about my screen, like it's Serial Number for example

The current winapi backend does not know how to get the EDID, so the information it exposes is pretty limited.

I found a write-up on the various ways to obtain this data, which could be used to greatly improve that backend!

I did changed my code and I'm still getting a thread 'main' has overflowed its stack while just getting brightness also :/

if you can put together a simple reproduction case (a rust #[test] or example binary?), maybe then others could investigate or you could get a stack trace showing what the problem is?

EDIT: for reference, this seems to be the best source of info on the topic

ThalusA commented 2 years ago

Huh, WinAPI is so horrible. By the way here is the example binary https://github.com/ThalusA/testddc and here is the repository's current state https://github.com/ThalusA/ddc-enhanced-rs/blob/master/src/lib.rs I'm trying to get a backtrace by the way but windows won't give me one. I use the toolchain x86_64-pc-windows-gnu. And here's a screenshot of my test binary

image
arcnmx commented 2 years ago

By the way here is the example binary https://github.com/ThalusA/testddc and here is the repository's current state https://github.com/ThalusA/ddc-enhanced-rs/blob/master/src/lib.rs

Program received signal SIGSEGV, Segmentation fault.
0x000055555558255b in ddc_enhanced_rs::mccs::{impl#1}::from (code=ddc_enhanced_rs::mccs::ImageAdjustment::Luminance) at ddc-enhanced-rs/src/mccs.rs:190
190         code.into()
(gdb) bt
#0  0x000055555558255b in ddc_enhanced_rs::mccs::{impl#1}::from (code=ddc_enhanced_rs::mccs::ImageAdjustment::Luminance) at ddc-enhanced-rs/src/mccs.rs:190
#1  0x00005555555824f1 in core::convert::{impl#3}::into<ddc_enhanced_rs::mccs::ImageAdjustment, u8> (self=ddc_enhanced_rs::mccs::ImageAdjustment::Luminance)
    at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/convert/mod.rs:550
#2  0x0000555555582561 in ddc_enhanced_rs::mccs::{impl#1}::from (code=ddc_enhanced_rs::mccs::ImageAdjustment::Luminance) at ddc-enhanced-rs/src/mccs.rs:190
#3  0x00005555555824f1 in core::convert::{impl#3}::into<ddc_enhanced_rs::mccs::ImageAdjustment, u8> (self=ddc_enhanced_rs::mccs::ImageAdjustment::Luminance)
    at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/convert/mod.rs:550
...

Your From impls just call themselves. You're looking for code as u8

ThalusA commented 2 years ago

Thank you so much, it solved everything xD