search

rockowitz / ddcutil

Control monitor settings using DDC/CI and USB
http://www.ddcutil.com
GNU General Public License v2.0
977 stars 40 forks source link

AOC AGON AG493UCX - Cannot switch to USB-C Source Input #314

Open Prydon9 opened 1 year ago

Prydon9 commented 1 year ago

Setup

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:

Feature: 60 (Input Source)   Values:    11: HDMI-1    12: HDMI-2    13: Unrecognized value    0f: DisplayPort-1    10: DisplayPort-2

As expected, when running ddcutil getvcp 60 --verbose on the Intel NUC (HDMI-1), the 0x11 interface is reported:

Processed feature definition file: /home/user/.local/share/ddcutil/AOC-AG493UG7R4-18736.mccs

Getting data for non-table VCP code 0x60 - Input Source: Raw value: opcode=0x60, mh=0x20, ml=0x0e, sh=0x00, sl=0x11, max_val=8206 (0x200e), cur_val=17 (0x0011) VCP code 0x60 (Input Source ): HDMI-1 (sl=0x11)

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 to HDMI-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 with 11, giving us the command ddcutil -b 3 setvcp 0x60 0x11 which we then run with ENTER.

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 the USB-C port, which I can only assume is the referenced Unrecognized Value reported earlier by ddcutil capabilities. However, nothing happens. No errors, the terminal simply returns to the next clean line ready for the next command input, and HDMI-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):

MFG_ID AOC MODEL AG493UG7R4 PRODUCT_CODE 18736 MCCS_VERSION 2.2 FEATURE_CODE 60 Input Source   ATTRS NC RW   VALUE 0x11 HDMI-1   VALUE 0x12 HDMI-2   VALUE 0x13 USB-C   VALUE 0x0f DisplayPort-1   VALUE 0x10 DisplayPort-2

After saving this file and running ddcutil getvcp 60 --verbose again to confirm that the file was processed, I first confirmed that switching to DP-1 is still possible, by running ddcutil -b 3 setvcp 0x60 0x0f again. The switch occurred successfully with no issues, as did switching back to HDMI-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 the AOC-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 the USB-C Source input. Once the source input had switched over, I ran the command, waited 10 seconds just in case, and then switched back to HDMI-1 to read the results, which are as follows:

Processed feature definition file: /home/user/.local/share/ddcutil/AOC-AG493UG7R4-18736.mccs

Getting data for non-table VCP code 0x60 - Input Source: Raw value: opcode=0x60, mh=0x20, ml=0x0e, sh=0x00, sl=0x02, max_val=8206 (0x200e), cur_val=2 (0x0002) VCP code 0x60 (Input Source ): Unrecognized value (sl=0x02)

Curious! The response seems to suggest that while the monitor was displaying the output of USB-C, the Input Source was not in fact 0x13, but 0x02.

After updating my AOC-AG493UG7R4-18736.mccs file to reflect this:

MFG_ID AOC MODEL AG493UG7R4 PRODUCT_CODE 18736 MCCS_VERSION 2.2 FEATURE_CODE 60 Input Source   ATTRS NC RW   VALUE 0x11 HDMI-1   VALUE 0x12 HDMI-2   VALUE 0x02 USB-C   VALUE 0x0f DisplayPort-1   VALUE 0x10 DisplayPort-2

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:

I then repeated the process of manually switching to USB-C and running the ddcutil getvcp 60 --verbose again, finally switching back to HDMI-1 to review the output, which now reads as follows:

Processed feature definition file: /home/user/.local/share/ddcutil/AOC-AG493UG7R4-18736.mccs

Getting data for non-table VCP code 0x60 - Input Source: Raw value: opcode=0x60, mh=0x20, ml=0x0e, sh=0x00, sl=0x02, max_val=8206 (0x200e), cur_val=2 (0x0002) VCP code 0x60 (Input Source ): USB-C (sl=0x02)

Note the change in the Input Source Name - no longer an Unrecognized Value, but USB-C - This is what leads me to believe that the changes to the AOC-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 as 0x02, 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:

Still works just fine! The commands are still accepted and executed as expected, switching the source input to HDMI-1 or DP-1 respectively. So I can still use ddcutil to switch AWAY FROM USB-C, I just can't seem to switch OVER TO USB-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

rockowitz commented 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.

Prydon9 commented 1 year ago

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.

Prydon9 commented 1 year ago

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.

rockowitz commented 1 year ago

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: @.***>