get_*()-commands return absurdly high values for luminance and contrast while monitor OSD is open #294
Comments
|
Can you modify the script to print the code maximums as it iterates? When getting a VCP feature value the monitor returns a tuple of the current code and the maximum value. I'm curious what the maximum values will show. import time
from monitorcontrol import get_monitors
# Check monitors
while True:
for monitor in get_monitors():
with monitor:
try:
brightness = monitor.get_luminance()
contrast = monitor.get_contrast()
print(f'Brightness: {brightness}')
print(f'Contrast: {contrast}')
print(f'Max: {monitor.code_maximum}')
except:
print('Error occured during get-command')
time.sleep(0.25) |
|
Sure thing. The output looks like this: EDIT: I just realized, that |
|
🤦 sorry, I forgot the max value structure doesn't get updated on I'll add some logging for this in a couple weeks. I need to add more visibility around the Windows API calls.
That is definitely interesting. I'll poke around with my monitor when I'm back home. I've never tried using commands with the OSD open. |
|
Sorry for the late reply, this issue got buried under a mountain of other issues. I tried running commands with the OSD open on the acer monitors I have - no change in behavior. I've opened #305 to add logging - if you're still interested in this issue are you able to give that a go with the previous script? |
|
Yes, thanks. I updated the package to e0ae184 and ran the script from your last suggestion (with an added line break for clarity). That gave no additional output on the shell. Needed to change monitorcontrol/vcp/vcp_windows.py as follows: Now the output on the shell looks like this: Hope this helps. Didn't mark where I opened the OSD - should be pretty clear from the log 😉 |
|
That does help narrow it down, but sadly it narrows it down to a location that's hard to debug :( The Windows API is returning a value it shouldn't - which either means the monitor firmware is returning a value it shouldn't, or the underlying Windows API call is misinterpreting data sent by the monitor. This could be further narrowed down to firmware or Windows by running the same thing on Linux, but I suspect it is the hardware based on the symptoms. |
|
Not ideal, but also not surprising. At least this one is easy to work around (for my case) by rejecting anything outside of the valid range [0,100] for brightness & contrast and just repeating the request. Coming back to my initial post: Do you think it would be useful to check that range in monitorcontrol and throw an error if the Win API returns incorrect values, instead of forwarding them? |
|
The maximum legal value for a given code is defined by the monitor. I checked the MCCS, but did not find anything that would indicate the values you are seeing would be illegal for all monitors. There are other options for detecting this behavior, but I think the most elegant is probably checking it in application code. |
|
OK. In that case, I'll close this since there is nothing to fix in monitorcontrol itself. |
HP Omen 27u
DP
Discrete Radeon 6800
Win 10 Pro 64 bit
3.12.0
monitorcontrol --version):3.1.0
Steps to Reproduce
Create a very basic Python script, which asks for monitor brightness and contrast:
As discussed in #288, many get_*()-commands fail with an error, but that is not relevant for this bug. I kept the errors in the log, but they can be ignored. What is more interesting is the behaviour while interacting with the monitor OSD. Log looks like this:
The behaviour is repeatable and the value is always
43690for both,get_luminance()andget_contrast(). I am not sure, where this problem originates - it might be specific to my display, but that's difficult for me to check right now.That being said, those values should be far outside of the allowed value ranges for these parameters, right? If so, I feel like this should trigger an error regardless of the origin of the problem.
The text was updated successfully, but these errors were encountered: