Open Prydon9 opened 1 year ago
Bear in mind that the monitor configuration file is just a way to make the getvcp text output accurate. It does not affect how ddcutil processes the setvcp command. Also, the capabilities string returned by the monitor can be inaccurate. Use it only as a hint for VCP features and values. ddcutil does not depend on the string, it just reports it. (Unfortunately, ddcui does have to take the capabilities string into account, but that is not relevant here.)
So the bottom line is that:
The only thing that isn't working is that monitor doesn't accept a command on its HDMI connector to switch its input.
There have been numerous reports, mostly the very wide Dell monitors, of feature x60 not working as expected, and users' attempt to figure out how to control them See for example the very long thread on issue #100. I imagine the monitor has a Windows app that communicates with the monitor in some proprietary way to control its input, manage PBP, etc.
You might try just using a range of values, e.g. setvcp x60 x01 ... setvcp x60 x30, to see if any of them have an effect. Also, it would be interesting to know if a Windows program such as ClickMonitorDDC, sending its commands over the Type-C connector, successfully changes the monitor input.
But I'm afraid that Type-C connectors and ultralarge monitors designed to display multiple inputs simultaneously just weren't around when the DDC/CI and MCCS specs were last updated, and its often the case that things don't work as one would with.
Thanks for the quick response!
Your summary is spot on except for:
The only thing that isn't working is that monitor doesn't accept a command on its HDMI connector to switch its input.
I think you meant to say "USB-C" rather than "HDMI" there - judging by the fact that you nailed everything else, unless I've misinterpreted you? And it's not so much that it doesn't accept a command ON the USB-C input (This I have not tested, as I have no way to connect my NUC via USB-C at the moment), it's that it doesn't accept any command that references the USB-C connector as part of the command.
Also:
If the monitor is set to the HDMI or DP input, sending a setvcp command to to switch to the other works. The monitor recognizes DDC/CI commands on its HDMI-1 connector even when it it taking its video input from DP-1.
We can say if the monitor is set to ANY input (even USB-C), rather than just HDMI-1 / DP-1. This makes total sense to me though, because we know that the DDC/CI commands are always received regardless of input, so it's just commands that specifically reference the USB-C input that fail (no need to reference USB-C in the command when switching away from USB-C, so no quirk in the monitors behaviour that relates to the active source, just the challenge of referencing the USB-C port itself).
Thank you for the advice, I'll investigate issue #100 shortly. I'll also endeavour to setup and test ClickMonitorDDC on the surface and report back with my findings. I was thinking about writing a script to iterate through all possible values one by one in the ddcutil -b 3 setvcp 0x60
command, but the wonderful world of monitors and DDC is quite new to me so I wasn't sure how sensible that would be. Do you forsee any risk associated with trying common/random/all values in this manner? If the risk is minimal I am happy to try that too.
Just a quick update in case anybody else is struggling with this monitor - I have found a temporary workaround that, while not perfect, at least negates the need to use the OSD and requires no additional software beyond ddcutil
:
You will require either a spare HDMI or DisplayPort input on the monitor (aka no cables plugged in on one port).
My monitor falls back to USB-C
as the default input source - even if I switch FROM HDMI-1
(with input) to say HDMI-2
(with no input), once the monitor fails to get a signal on HDMI-2
, it will force a second switch in an effort to display a valid source, and rather than revert to the last known good source (HDMI-1
), it instead falls back to the USB-C
input. While this takes a little longer than the flawless switch between two sources that are actually connected (in my case HDMI-1
& DP-1
), as you have to first wait for the monitor to switch to your unused port, determine no signal is present, and then wait the regular amount of time on top of that as it initiates and completes its second source switch to the fallback source, the additional time isn't catastrophic, and the end result is the desired state - switching to the USB-C
input via the use of ddcutil
.
This will at least tide me over for the time being with my day to day, but I am still committed to finding a more stable solution, as this isn't going to be feasible for users who need to utilise all 4 of the HDMI/DP input sources. But hopefully somebody finds this useful.
On 5/15/23 12:58, Prydon9 wrote:
Thanks for the quick response!
Your summary is spot on except for:
The only thing that isn't working is that monitor doesn't accept a command on its HDMI connector to switch its input.
I think you meant to say "USB-C" rather than "HDMI" there - judging by the fact that you nailed everything else, unless I've misinterpreted you?
To be more precise, when the monitor current input is the USB-C connector, which is connected to the Surface laptop, then attempting to issue a setvcp x60 command on the HDMI connector, which is connected to the NUC, fails. We don't, or at least didn't at that point, know how the monitor behaves when a change input command is received on the USB-C connector, i.e. from the Surface laptop. That requires Windows software such as ClickMonitorDDC.
Thank you for the advice, I'll investigate issue #100 https://github.com/rockowitz/ddcutil/issues/100 shortly. I'll also endeavour to setup and test ClickMonitorDDC on the surface and report back with my findings. I was thinking about writing a script to iterate through all possible values one by one in the |ddcutil -b 3 setvcp 0x60| command, but the wonderful world of monitors and DDC is quite new to me so I wasn't sure how sensible that would be. Do you forsee any risk associated with trying common/random/all values in this manner? If the risk is minimal I am happy to try that too.
I doubt there would be a problem with running through a range of x60 values. The few times serious problem have been reported is with experimentally setting features in the manufacturer reserved range on offbrand monitors. The choice of x30 as the upper bound for values to test was somewhat arbitrary; I just can't imagine anything greater than that being recognized.
— Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/314#issuecomment-1548217594, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3Q4FG74YU2F7PG26G3XGJOEHANCNFSM6AAAAAAYB4ZF7E. You are receiving this because you commented.Message ID: @.***>
Setup
1x AOC AGON AG493UCX Monitor (More specifically,
ddcutil detect
reports the model number asAG493UG7R4
) - This Monitor has 3 active source inputs: 1) Intel NUC (Running Debian 11) onHDMI-1
2) Desktop PC (Miscellaneous VM Outputs) onDP-1
3) Surface Laptop (Running Windows 10) onUSB-C
The monitor also has a second HDMI Port, and a Second DisplayPort, currently unused, for a total of 5 source inputs.Each of these systems is connected directly to the monitor using a single cable of matching output/input (NUC is HDMI to HDMI, PC is DP to DP, Laptop is USB-C to USB-C). There are no additional peripheral devices introducing complexity mid connection.
None of these devices have any additional monitors, with the exception of the laptop display built into the Microsoft Surface.
ddcutil
is only installed on 1 of these systems - The Intel NUC onHDMI-1
- Any commands listed below would only ever have been run on the Intel NUC, regardless of which input source was actively displayed at the time the command was run.Behaviour
Fortunately, the AG493UCX does seem to support accepting a
setvcp
command from a system that does not currently have focus on the monitor (As I gather not all monitors do this).ddcutil capabilities
reports the following for Feature 60:As expected, when running
ddcutil getvcp 60 --verbose
on the Intel NUC (HDMI-1
), the 0x11 interface is reported:As expected, running
ddcutil -b 3 setvcp 0x60 0x0f
immediately switches the monitor away from the Intel NUC (HDMI-1
) to the PC (DP-1
) source input.I can then type the following combination on the keyboard (which still has focus on the NUC, it has not followed the display to
DP-1
) to switch the monitor input source back toHDMI-1
, proving that the monitor will accept DDC/CI commands from a source that is not the current active input source:UP
BACKSPACE
BACKSPACE
1
1
ENTER
All we have done there, is recall the most recent terminal command (
ddcutil -b 3 setvcp 0x60 0x0f
), remove the last 2 characters (0f
), and replaced them with11
, giving us the commandddcutil -b 3 setvcp 0x60 0x11
which we then run withENTER
.As expected, switching back and forth between these 2 inputs is seamless.
Next, I try to run
ddcutil -b 3 setvcp 0x60 0x13
to switch to theUSB-C
port, which I can only assume is the referencedUnrecognized Value
reported earlier byddcutil capabilities
. However, nothing happens. No errors, the terminal simply returns to the next clean line ready for the next command input, andHDMI-1
remains the focus on the monitor with no interruption.I read in another issue report, that User Defined Features is a way to set unrecognized values, so I followed the instructions and gave it a try (You may notice in my above
ddcutil getvcp 60 --verbose
output, the file appears to be processed successfully). It took a bit of trial and error to get it working, but I now have reason to believe it is being processed correctly (more on that shortly), however I am not ruling out the possibility that I still haven't done this step correctly. The contents of this file are below (Filename:AOC-AG493UG7R4-18736.mccs
):After saving this file and running
ddcutil getvcp 60 --verbose
again to confirm that the file was processed, I first confirmed that switching toDP-1
is still possible, by runningddcutil -b 3 setvcp 0x60 0x0f
again. The switch occurred successfully with no issues, as did switching back toHDMI-1
the same as before. However,ddcutil -b 3 setvcp 0x60 0x13
still does not trigger a change. In other words, all behaviour remains identical to behaviour prior to introducing theAOC-AG493UG7R4-18736.mccs
file.I now prepared another
ddcutil getvcp 60 --verbose
command in the terminal on the NUC (HDMI-1
), and manually switched to theUSB-C
Source input. Once the source input had switched over, I ran the command, waited 10 seconds just in case, and then switched back toHDMI-1
to read the results, which are as follows:Curious! The response seems to suggest that while the monitor was displaying the output of
USB-C
, the Input Source was not in fact0x13
, but0x02
.After updating my
AOC-AG493UG7R4-18736.mccs
file to reflect this:I repeated the process of running
ddcutil getvcp 60 --verbose
to confirm the file was reported as processed again, But still running either of the following has no effect:ddcutil -b 3 setvcp 0x60 0x02
ddcutil -b 3 setvcp 0x60 0x13
(Note: I also went back and tried the reverse of runningddcutil -b 3 setvcp 0x60 0x02
while the value in the .mccs file was set to 0x13, just to be thorough. No change).I then repeated the process of manually switching to
USB-C
and running theddcutil getvcp 60 --verbose
again, finally switching back toHDMI-1
to review the output, which now reads as follows:Note the change in the Input Source Name - no longer an
Unrecognized Value
, butUSB-C
- This is what leads me to believe that the changes to theAOC-AG493UG7R4-18736.mccs
file are being picked up and taken into account - as that is where I have defined the name "USB-C".So it seems that ddcutil is recognising the
USB-C
port as0x02
, however it will not switch over to it. I have noted that 0x02 appears to be reserved for VGA Outputs, but I have not yet gone down that rabbit hole.Another thing I found interesting, is that even if the monitor is displaying the
USB-C
source, running either:ddcutil -b 3 setvcp 0x60 0x11
ddcutil -b 3 setvcp 0x60 0x0f
Still works just fine! The commands are still accepted and executed as expected, switching the source input to
HDMI-1
orDP-1
respectively. So I can still use ddcutil to switch AWAY FROMUSB-C
, I just can't seem to switch OVER TOUSB-C
.EDIT: I have noticed a lot of requests to run
ddcutil interrogate
when the monitor has focus on the input system issuing the command in response to issue tickets, so I have run that and attached the output below :)ddcutil_interrogate.txt