Two conf files for laptop screen, "Failed to obtain capabilities" on each start, fixed manually

[nahoj]

Hey. I have a laptop screen which, as expected, doesn't support DDC/CI. Since 2.0, each time VDU Control started, I got a message "Failed to obtain capabilities for monitor -1 0." even after clicking on the 4th button to "Permanently discard this monitor".

There seems to me a mixup between 2 conf files named _0.conf and just .conf, both updated on each run. At first both files had an empty capabilities-override =.

When I went to the app Settings for this monitor (tab with an empty name), there was "Ignore VDU" in the "capabilities override" and upon saving it, it was written in .conf but with no change in behavior.

Then I copied the value to _0.conf and now I don't get the dialog and the Settings tab is named "_0".

[digitaltrails]

So you've got a successful workaround for the moment?

Thanks for reporting this. I don't have a laptop, but I will try and setup a simulation of a such a setup.

Is vdu_controls set to use the ddcutil command or the D-Bus ddcutil-service? I guess I should test both, but it would be good to know which one you're using.

It may be that "Ignore VDU" is generally broken, so I'll have a look at whether that might be the case too.

[nahoj]

Yes, it's fixed for me now. I use ddcutil-service.

My guess is either or both of 2 issues:

1. Not writing the conf file from the "Failed to obtain" dialog
2. The app can't decide whether the screen's name is the empty string or "_0".

[digitaltrails]

I don't think I've encountered a display numbered 0. It's possible that's tripping up some python logic where I should be explicitly testing for None. Perhaps 0 is being misinterpreted as None somewhere. That could cause both guesses.

[digitaltrails]

I hacked ddcutil-service to return a bogus VDU with similar data to your example.

I think I've fixed the issue by persisting the "Ignore VDU" straight away after it's selected. That's safer and looks more sensible from a user's point of view (no need to specifically save). It also seems to stay Ignored if the config file is saved from the GUI.

I've also changed vdu_controls to substitute "Unknown" for a blank model-name. That should ensure the filename makes some sense. There are two files, one for all VDU's of that model, and then also a model_serial_number config file specific to each VDU. That doesn't really work as planned if there is no serial number, but I don't think it does any harm.

Asking ddcutil-service to get VCP values for a bogus display seems to cause some looping issues in vdu_controls when assessing the restoration of Presets and comparing target brightness to ambient light. I've treated the symptom by stopping vdu_controls from querying values for ignored displays as it's a waste of time.

The detect() method of the ddcutil-service supports an parameter to include or exclude invalid displays. Perhaps I should only have vdu_controls work with valid displays, but they may lead to some problems working with real VDU's that implement DDC poorly.

I did think at one time that vdu_controls could also control laptops. Basically add a ddcutil wrapper layer that fakes up a capability definition to vdu_controls and translates VCP detect/getvcp/setvcp into whatever the laptop actually requires. It's on the back burner until I buy/need a laptop or someone else gets a bee in their bonnet.

[nahoj]

Yes, it now works as expected for me even starting with an empty config. Thanks :)

[digitaltrails]

Good news. Thanks for the feedback, this is not a hardware combo I can test, so the feedback is very helpful.