Some values of Dell S3422DWG state for PiP/PBP features are not visible

[Noctivivans]

Hi,
I am trying to figure out how to manage PiP (Picture in Picture) function in Dell S3422DWG. So far, I discovered that following variables are in use:

1. 0x60 - Input source for main output - available values (description available via ddcutil) are 0x0f, 0x11, 0x12;
2. 0xe8 - Input source for secondary output - available values (undocumented, found via trial/error) are 0x21 (DisplayPort), 0x12 (HDMI2), and 0x11 (HDMI1) - interesting thing is that you can set the same input for both outputs;
3. 0xe9 - PiP function, correct values I've found are 0x21 (upper right small sized display), 0x22 (upper right big sized display), and 0x23/0x24 (both enables split screen mode)

The problem is that I have no idea how to select other corners - when I move secondary output for other corners via monitor PiP menu, 0xe9 value seems to remain the same. However, when I rewrite value of 0xe9 to exact the same value, secondary output jumps back to upper right corner.

Step by step example:
PiP disabled:

Getting data for non-table VCP code 0xe9 - Manufacturer Specific:
Raw value: opcode=0xe9, mh=0x00, ml=0xff, sh=0x00, sl=0x00, max_val=255 (0x00ff), cur_val=0 (0x0000)
VCP code 0xe9 (Manufacturer Specific         ): mh=0x00, ml=0xff, sh=0x00, sl=0x00

PiP enabled, upper right corner:

Getting data for non-table VCP code 0xe9 - Manufacturer Specific:
Raw value: opcode=0xe9, mh=0x00, ml=0xff, sh=0x00, sl=0x21, max_val=255 (0x00ff), cur_val=33 (0x0021)
VCP code 0xe9 (Manufacturer Specific         ): mh=0x00, ml=0xff, sh=0x00, sl=0x21

PiP enabled, bottom right corner:

Getting data for non-table VCP code 0xe9 - Manufacturer Specific:
Raw value: opcode=0xe9, mh=0x00, ml=0xff, sh=0x00, sl=0x21, max_val=255 (0x00ff), cur_val=33 (0x0021)
VCP code 0xe9 (Manufacturer Specific         ): mh=0x00, ml=0xff, sh=0x00, sl=0x21

Writing 0x21 to 0xe9 variable:
ddcutil --sleep-multiplier .5 --noverify -d 1 setvcp 0xe9 0x21
(secondary output jumps back to upper right corner)

I've compared outputs of command ddcutil --disable-capabilities-cache probe --verbose for different PiP settings, and for corner mode no variables changes - only thing that is differ is some identifier at the beginning of output:

Scanning all VCP feature codes for display Display_Handle[i2c-5: fd=3 @0x56466c739810]             |    Scanning all VCP feature codes for display Display_Handle[i2c-5: fd=3 @0x562e89624810]

I am not sure if I am not using ddcutil properly, or some values are not being read/write properly via ddcutil (or both), all I know that monitor is capable to support PiP management from OS - I've checked official Dell app for Windows and it is able to manage PiP function properly.

interrogate.txt attached, please let me know if you need some additional info.

Thanks.

[rockowitz]

You've done an impressive degree of sleuthing.I've only a couple things to add.

Pay attention to the SH byte on feature x60. I briefly owned a Dell U4320, and found the SH byte could be non-zero. I didn't try to find out what that meant.

The definitive way to figure out what going on is to sniff the I2C bus when using the Dell Display Manager on a Windows system. I've found one relatively inexpensive way to do so. If you go this route, I can help to decipher the captured data.

If you don't mind, I'll put your information for the S3422DWG on www.ddcutil.com

Sanford

[Noctivivans]

You've done an impressive degree of sleuthing.I've only a couple things to add.

Thanks, I am a beginner in matter of I2C, so I simply set different settings manually via monitor buttons and read them via ddcutil :)

Pay attention to the SH byte on feature x60. I briefly owned a Dell U4320, and found the SH byte could be non-zero. I didn't try to find out what that meant.

I haven't figure out yet how to change other bits than the last one, how can I pass to ddcutil that I want to change other bit than SL one? I suspect that something is going on under the hood and some bits are being changed for short amount of time, and that may be the thing with 0xe9 register.

The definitive way to figure out what going on is to sniff the I2C bus when using the Dell Display Manager on a Windows system. I've found one relatively inexpensive way to do so. If you go this route, I can help to decipher the captured data.

This monitor has DP and HDMI ports only, any suggestions how can I connect device you mentioned in that case?

If you don't mind, I'll put your information for the S3422DWG on www.ddcutil.com

Sure, go ahead :)
I hope that we'll fully figure out how to manage monitor together - monitor itself is really nice, but I can't say that about Dell support :/ (I've tried to contact them to get I2C documentation, but with no success)

[rockowitz]

As you've described yourself as a "beginner" in this area, let me start with a bit of background. You're probably familiar with it, but making it explicit will simplify the salient comments.

getvcp transmits 4 bytes, named MH, ML, SH, SL. For a "continuous" feature, MH/ML are the high and low order bytes of a 2 byte maximum value, SH/SL are the high and low order bytes of the current value.

Non-continuous features whose value can be changed generally use only the SL byte for the current value.
Non-continuous features whose value cannot be changed use all 4 bytes in a feature specific way.

getvcp --verbose shows all 4 bytes individually. It also reports the MH/ML and SH/SL pairs as the maximum and current value, which makes sense only for continuous features.

As the Monitor Control Command Spec (MCCS) has evolved, more complicated usages have been defined, but the above is sufficient for our purposes.

getvcp x60 interprets only the SL byte, as per the MCCS spec. But using getvcp --verbose you can see the current SH byte value as well.

The value argument to setvcp is actually an unsigned short. Normally this is just a small number. However, it sets the SH byte as well as SL. For example setvcp x60 x0506 sets the high order byte to x05, and the low order byte to x06.

Re sniffing the line, for our purposes HDMI and DVI are the same in that they encode the video signal the same way and have explicit wires (named SCA and SCL) for transmitting I2C. So converting from one to the other is just a matter of inserting a DVI<->HDMI cable or adapter.

DP uses a different video encoding and transmits the I2C signal over its AUX channel. Its I2C signal is not sniffable using i2cdriver.

As I read the specs for your laptop, it has only mini-DP and type C connectors for video output. From our point of view, the type C connector behaves as a DP connector, so we can ignore it. The question is how to connect the mini-DP port on the laptop to the modified DVI cable. The answer, of course, is "it depends". For a detailed discussion, see DDC Over Displaport. The mini-DP output on your laptop probably implements Display Port Dual Mode, so a simple passive cable would suffice. The final Rube Goldberg chain of cables in your case would be:

laptop mini-DP port <->active or passive DP-DVI cable<->DVI sniffer cable<->DVI-HDMI cable<->monitor input

[Noctivivans]

Looks like specs from software point of view is quite different from hardware one - this laptop has DisplayPort (not mini), but during the tests I was using docking station which also had DisplayPort. I'll create new report because now I have new docking station (old one broke, and new one is little different - instead of one VGA and DisplayPort port it has two DisplayPort ports).

I am also wondering if DVI sniffer cable won't affect sniffing results due to DVI cable transfer speed - not directly, since (as you mentioned in documentation) I2C uses separate pins, but due to fact that this monitor requires HDMI 2.0 or DP 1.4 to handle native resolutions (I've checked on older DP/HDMI cables, and some modes were simply unavailable).

Another possibility comes to my mind - are software methods as the one mentioned here suitable for our purpose? I mean, if that won't catch the same data as hardware sniffer, or is it too slow/unreliable?

interrogate_new.txt

Edit:
I have another thought about hardware sniffing - since we need info what signals are being send by Dell application, I should connect sniffer to cable connected to Windows pc. Fortunately I can get another laptop with HDMI port and Windows installed, so that will simplify things, but question about DVI speed still remains valid (I hope that I'll be able to find codes for other features, not only for PiP/Pbp)

[rockowitz]

i915 implementation of i2c on docking stations is quite recent. It was useful for me to see how that is represented in /sys.

Video signal and I2C speed are independent. For DDC, i2c signalling is at the lowest defined i2c speed, 100 khz.

ftrace is a linux utility that, in this context, logs what the kernel writes to and reads from the i2c bus. It does not see what Windows writes to and reads from the i2c bus.

While the line being sniffed must be a Windows to monitor connection, there is no constraint on how the sniffer is implemented. In the case of i2cdriver, the device provides a USB connection for reporting what it has observed. The other end of the USB connection could be Linux system, a Windows system, or something else. It just needs a program that can read from and write to a USB device. See the i2cdriver documentation.

[Noctivivans]

Looks like that I have to make DVI DDC breakout cable by myself - 200$ delivery cost is way too much 😅
Same applies to I2CDriver - delivery is cheaper, but still, overall cost is too expensive. I'll try to reach local vendors if someone have equipment I need to do the sniffing.

[roconnor]

I've found some DDC commands for dell monitors at https://github.com/ScriptGod1337/kvm/blob/d81776dbbd821176195b0b2afe866ee814cdf234/src/kvmutil/kvmutil.py. In particular ddcutil setvcp 0xe7 0xff00 will swap the keyboard/mouse between PIP displays. However, I haven't found how to control the PIP quadrant. @Noctivivans If you do ever find out, I'd be interested. I'm also looking for those codes.