-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Picture-by-Picture #163
Comments
Looking for the same solution for the same monitor. I was hoping that one of the E? codes work but i can't read their values even some of them shown in the capabilities:
and
in addition to PBP i would be also interested to switch the USB KVM (Auto, USB-C, USB-Up). interestingly when using |
For me, the low bit of VCP e6 does indicate the PBP mode: With PBP mode enabled (ie, two inputs / split screen):
Without PBP mode (ie, one input):
"scan" and "capabilities" and report different sets of manufacturer specific codes:
Reading manufacturer specific codes:
Writing manufacturer specific codes:
|
@pjaitken I have, as they say, been admiring your problem, and trying to think of useful things to suggest. PBP is so beyond what was considered when MCCS was defined. You've looked in all the obvious places, and then some. Here are some observations and questions (many of which are undoubtedly obvious).
Regards, |
@bugrasan Most of my reply to @pjaitken is for you as well. The one thing I would add is that the watch command is problematic. The version in branch 1.0.0-dev better handles error conditions. In MCCS, feature x52 became a FIFO, meant to be read repeatedly until a value of x00 is returned. Branch 1.0.0-dev adds command line option **--x52-no-fifo, which forces watch to always use MCCS 2.0/2.1 behaviour, reading a single feature id from feature x52 and then checking feature x02 to see if there are more changed features. I'd appreciate it if you run ddcutil interrogate in the various monitor states and send the output, of course as attachments of some sort. Regards, |
Thanks @rockowitz. I've emailed you some "ddcutil interrogate" outputs. The hardware configuration is debian connected to the displayPort + HDMI-1 inputs, and macOS connected to HDMI-2. |
FWIW, SCAN:
Discrete getvcp queries:
Also, |
I'm not sure what to make of the feature x20 and x30 discrepancies. These features are in the Geometry section of the MCCS spec, which contains features like pincushion that apply only to CRTs. What these features mean for flat panels is unclear. A pixel offset? And yet, 2 of the 3 monitors in front of me list these features in their capabilities string. All 3 reply to getvcp requests for the features. And all 3 show show a similar deviation in the output of getvcp 20/getvcp 30 versus getvcp scan. The obvious suspect is some buffer corruption in ddcutil. But tracing at the lowest I2C level shows that the request packets are identical, while the response packets diverge. I've improved the tracing in branch 1.0.0-dev to make this easier to see. Use the command $ ddcutil getvcp 20 --verbose --trcfunc get_raw_value_for_feature_metadata, --trcfunc i2c_fileio_reader, --trcfunc_i2c_fileio_writer and similar commands for feature x30 and scan What's of interest are the i2c_fileio_writer() and i2c_fileio_reader() calls within get_raw_value_for_feature_metadata(). |
Re the x52 deviations, I would expect the value of feature x52 to vary based on the monitor's state. That the value of x52 is x00 for scan suggests that the read of feature x02 earlier in the scan returned either x01 (No new control values) or xff (No user controls are present). |
I see the same: different data returned by "scan" versus "getvcp". Here's the output of
Here are the outputs of
|
The earlier read of 0x02 returned 2.
|
Hi Paul, @pjaitken, If you're still trying to figure out the DDC command sequences and the Phillips control software runs on your Mac, I may have a solution. Recently I came across an inexpensive device called I2CDriver that can sniff I2C traffic. I also got lucky and found a DVI DDC breakout cable online on closeout for $22.50 plus shipping, which saved me from having to make the cable myself. I had to fiddle a bit to get from the connector on the cable, which is the header for a 10 pin ribbon cable, but I fished an old COM port ribbon cable out of the parts bin. I had to fiddle a bit to get things working - this is a tool for people who can figure things out on their own. I can now capture the I2C traffic, including ACKs and NACKs, in a CSV file. The next step will be to write a Python program that interprets the sequences of "READ, 8, ACK, WRITE 2" etc. as DDC commands. A couple things are worth pointing out. There are 4 leads from the I2CDriver device: SDA, SCL, GROUND, and 5v VCC. The last is irrelevant for sniffing the line and should be left disconnected. It exists to power a small device being driven from I2CDriver. Second, I2CDriver has 3 modes: command for controlling the attached device, monitor for watching bits go by on the line, and capture for collecting the traffic and writing it to a file. When in capture mode it doesn't look like anything is happening. Only when capture mode is terminated is output written to the log file. Regards, |
@bugrasan I found how to set/swap the PBP inputs: setvcp 0x60 controls the input source:
PBP mode has to be set manually through the menus. However, once in PBP mode, So to show $RIGHT and $LEFT outputs in PBP mode:
Other VCPs I discovered:
I did not find any VCPs relating to USB settings. |
I have a Philips 346P1CRH and tested the SmartControl tool that Philips offers (version 6.9.00 after it auto-updated) and PBP wasn't available for selection even though I had a laptop and my desktop machine attached to it. Does the Philips tool work for you to configure PBP? I had the monitor connected through USB as well as HDMI, to no avail. This seems to confirm that the lack of support is a problem with the monitor not offering the functionality through DDC/CI, rather than us not finding out how to enable it. I was personally interested in changing the aspect ratio to 16:9, but that's not available either. |
I was able to set PBP like this:
The values for 0x60 are:
|
So, not through the Philips tool, and you still need to enable PBP manually, right? |
I found that PBP mode had to be set manually through the menus. I'm not able to test with the Philips tool since I nolonger have the monitor. Be careful when writing to unknown VCPs. |
I'm looking for a way to change the Picture-by-Picture (PBP) input on a Philips 499P9. The PBP mode allows it to display two inputs side-by-side.
ddcutil reports the monitor as two displays on different I2C buses. When reading, the same values seem to be returned from both. Writing to either display or bus affects the monitor as a whole.
Writing to vcp 60 only changes the primary input. However when the inputs are changed manually, reading vcp 60 returns the value for the most-recently changed input - whether the primary or PBP.
When running from a single input, vcp e6 reports sl=0x01; for PBP it reports 0x00. Writing has no effect. There are a handful of other manufacturer vcp's, but they don't change when the inputs are changed and writing to them doesn't have any obvious effect.
"ddcutil watch" doesn't help: although vcp 2 reports "One or more new control values have been saved", vcp 52 always reports value 0x02 - even after writing 1 to vcp 2, which then reports "No new control values".
Thanks.
The text was updated successfully, but these errors were encountered: