DDC Communication on Linux Fails After Using ClickMonitorDDC or Dell Display Manager on Windows 10 #83
Comments
|
Sanford:
|
|
|
My best hunch, and it's just that, is that there's a problem in the
monitor's DDC implementation. More specifically, it may be that the DDC
input is not always being switched along with the video input. Is there
any chance you can substitute a different monitor in your setup, at
least for testing?
FYI, per the spec, and ignoring irrelevant cases, the meaning of the DDC
Null Message is "To tell the the host that the display does not have any
answer to give to the host (not ready or not expected).
Sanford
…On 4/25/19 6:43 AM, k-kolev wrote:
Hi, Sanford.
Thank you for your prompt reply.
I am a little bit closer to identifying the problem. I followed
your suggestion and installed ClickMonitorDDC on the Windows
laptop. The situation though was the same – I was able to switch
Linux -> Windows (DVI -> DisplayPort) but once I switched back
Windows -> Linux (DisplayPort -> DVI) I was not able to switch
back (DVI -> DisplayPort) to Windows. It didn’t matter whether I
use ClickMonitorDDC UI, ClickMonitorDDC command line
(C:\Work\ClickMonitorDDC\ClickMonitorDDC_6_8.exe s DVI1 q), Dell
Display Manager UI or Dell Display Manager command line
("C:\Program Files (x86)\Dell\Dell Display Manager\ddm.exe"
/SetActiveInput DVI1 /Exit).
What differs from configuration point of view since my initial
email from yesterday is that I installed ClickMonitorDDC on the
Windows laptop and configured i2c_dev module to run automatically
after reboot on the Fedora desktop.
Now the interesting part 😊 What I noticed is that when I use
ClickMonitorDDC ONCE and switch to Fedora (DVI), then use the OSD
to change input to DisplayPort and switch to Windows, then again
use the OSD to change back to Fedora (DVI) I am able to switch to
Windows (DisplayPort) via ddcutil as usual: ddcutil setvcp 60 0xf.
Then I generated two interrogate logs before and after switching
with ClickMonitorDDC (both logs are attached) and compared them.
What’s obvious is that after using ClickMonitorDDC for some reason
the communication on Fedora (DVI) fails. BUT if OSD buttons are
used ONCE communication is restored and switching works normally.
Behavior is the same if using Dell Display Manager.
So it should be something with the software under Windows that
breaks or blocks DDC communication on Fedora somehow. Or it may be
the monitor acting this way. I am just guessing.
I don’t have HDMI input on my Dell P2314H to check with that input
source though.
After I respond you here I will transfer our communication in the
issue tracker respecting your preference.
Greetings
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#83 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADMGY3RNKJURHDVYQAEFGZ3PSGDLJANCNFSM4HIL32OQ>.
|
|
I can easily substitute the current monitor for testing, that’s not a
problem. I am also very tempted to handle this problem, not to mention that
this would help much of my colleagues too.
As you mention the DDC input I wonder which cable is used for the DDC
communication? It may be the cable, though it sound very uncommon.
I am on vacation till the end of the week but once I am back next week I
will do a test with different monitor.
Cheers
…On Mon, 29 Apr 2019 at 5:14 rockowitz ***@***.***> wrote:
My best hunch, and it's just that, is that there's a problem in the
monitor's DDC implementation. More specifically, it may be that the DDC
input is not always being switched along with the video input. Is there
any chance you can substitute a different monitor in your setup, at
least for testing?
FYI, per the spec, and ignoring irrelevant cases, the meaning of the DDC
Null Message is "To tell the the host that the display does not have any
answer to give to the host (not ready or not expected).
Sanford
On 4/25/19 6:43 AM, k-kolev wrote:
>
> Hi, Sanford.
>
> Thank you for your prompt reply.
>
> I am a little bit closer to identifying the problem. I followed
> your suggestion and installed ClickMonitorDDC on the Windows
> laptop. The situation though was the same – I was able to switch
> Linux -> Windows (DVI -> DisplayPort) but once I switched back
> Windows -> Linux (DisplayPort -> DVI) I was not able to switch
> back (DVI -> DisplayPort) to Windows. It didn’t matter whether I
> use ClickMonitorDDC UI, ClickMonitorDDC command line
> (C:\Work\ClickMonitorDDC\ClickMonitorDDC_6_8.exe s DVI1 q), Dell
> Display Manager UI or Dell Display Manager command line
> ("C:\Program Files (x86)\Dell\Dell Display Manager\ddm.exe"
> /SetActiveInput DVI1 /Exit).
>
> What differs from configuration point of view since my initial
> email from yesterday is that I installed ClickMonitorDDC on the
> Windows laptop and configured i2c_dev module to run automatically
> after reboot on the Fedora desktop.
>
> Now the interesting part 😊 What I noticed is that when I use
> ClickMonitorDDC ONCE and switch to Fedora (DVI), then use the OSD
> to change input to DisplayPort and switch to Windows, then again
> use the OSD to change back to Fedora (DVI) I am able to switch to
> Windows (DisplayPort) via ddcutil as usual: ddcutil setvcp 60 0xf.
> Then I generated two interrogate logs before and after switching
> with ClickMonitorDDC (both logs are attached) and compared them.
> What’s obvious is that after using ClickMonitorDDC for some reason
> the communication on Fedora (DVI) fails. BUT if OSD buttons are
> used ONCE communication is restored and switching works normally.
> Behavior is the same if using Dell Display Manager.
> So it should be something with the software under Windows that
> breaks or blocks DDC communication on Fedora somehow. Or it may be
> the monitor acting this way. I am just guessing.
>
> I don’t have HDMI input on my Dell P2314H to check with that input
> source though.
>
> After I respond you here I will transfer our communication in the
> issue tracker respecting your preference.
>
> Greetings
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#83 (comment)>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/ADMGY3RNKJURHDVYQAEFGZ3PSGDLJANCNFSM4HIL32OQ
>.
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#83 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AL5KPKGZ5QPE5UTIQY5VUG3PSZKXBANCNFSM4HIL32OQ>
.
|
|
Today I tested with different monitor - Fujitsu E22W-6 LED with DDC/CI activated. Unfortunately the results are pretty the same. This time though I used VGA cable to connect the monitor to the laptop (Windows) because monitor has DVI and VGA only. Results are even worse - ddcutil is not able to establish communication with the monitor at all. Otherwise I am able to switch from Windows to Linux with ClickMonitorDDC. But this time since no DDC communication can be established I am not able to switch from Linux to Windows even after using OSD button to change monitor input. |
|
Please send the output of "sudo ddcutil environment --verbose" for the
alternate configuration.
Sanford
…On 5/9/19 8:00 AM, k-kolev wrote:
Today I tested with different monitor - Fujitsu E22W-6 LED with DDC/CI
activated. Unfortunately the results are pretty the same. This time
though I used VGA cable to connect the monitor to the laptop (Windows)
because monitor has DVI and VGA only.
Results are even worse - ddcutil is not able to establish
communication with the monitor at all. Otherwise I am able to switch
from Windows to Linux with ClickMonitorDDC. But this time since no DDC
communication can be established I am not able to switch from Linux to
Windows even after using OSD button to change monitor input.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#83 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADMGY3W772QP5DIXB7THMPTPUQG5LANCNFSM4HIL32OQ>.
|
|
Please ignore the previous message. I just saw the interrogate output
that was attached to the email that went directly to me.
Sanford
…On 5/9/19 8:00 AM, k-kolev wrote:
Today I tested with different monitor - Fujitsu E22W-6 LED with DDC/CI
activated. Unfortunately the results are pretty the same. This time
though I used VGA cable to connect the monitor to the laptop (Windows)
because monitor has DVI and VGA only.
Results are even worse - ddcutil is not able to establish
communication with the monitor at all. Otherwise I am able to switch
from Windows to Linux with ClickMonitorDDC. But this time since no DDC
communication can be established I am not able to switch from Linux to
Windows even after using OSD button to change monitor input.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#83 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADMGY3W772QP5DIXB7THMPTPUQG5LANCNFSM4HIL32OQ>.
|
|
The output of the interrogate command is baffling. At lines 348/351, in
the environment portion of interrogate, there's a simple test of reading
feature x10 that succeeds. But later communication fails. In
particular, in the probe portion of interrogate, we see that reads fail
with Linux errno ENXIO: No such device or address.
The only thing I can suggest at this point is to install program
i2cdetect, generally found in package i2c-tools. Then, assuming the
monitor is still at /dev/i2c-2, the command "i2cdetect -y 2" will show
whether slave address x37 is responsive. Run this command when ddcutil
works, and when it's not working.
Sanford
…On 5/9/19 8:00 AM, k-kolev wrote:
Today I tested with different monitor - Fujitsu E22W-6 LED with DDC/CI
activated. Unfortunately the results are pretty the same. This time
though I used VGA cable to connect the monitor to the laptop (Windows)
because monitor has DVI and VGA only.
Results are even worse - ddcutil is not able to establish
communication with the monitor at all. Otherwise I am able to switch
from Windows to Linux with ClickMonitorDDC. But this time since no DDC
communication can be established I am not able to switch from Linux to
Windows even after using OSD button to change monitor input.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#83 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADMGY3W772QP5DIXB7THMPTPUQG5LANCNFSM4HIL32OQ>.
|
|
|
Bottom line, i2cdetect shows slave address x37 (DDC) is responsive in
both cases. I'm out of ideas. That the problem happens with 2 different
monitors suggest it's not the monitor's DDC/C implementation. I could
blame the i915 driver, but that's just punting.
Sanford
…On 5/10/19 10:44 AM, k-kolev wrote:
1. Output of i2cdetect -y 2 when switching Linux -> Windows (DVI ->
DisplayPort) is working:
|0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- --
-- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- --
-- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- 37 --
-- 3a -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- 4a 4b -- -- --
-- 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- --
-- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- |
2.
While on Windows run |ClickMonitorDDC_6_8.exe s DVI1 q|
3.
Output of i2cdetect -y 2 after switched Windows -> Linux
(DisplayPort -> DVI) and switching back already fails:
|0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- --
-- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- --
-- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- 37 --
-- 3a -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- 4a 4b -- -- --
-- 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- --
-- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- |
4. Result: Diffing both outputs reports they are equivalent.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#83 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADMGY3RMJSG6CFNDGAQTY3TPUWC4ZANCNFSM4HIL32OQ>.
|
|
I have a Dell P2317H if it might be any help for testing. If I have auto select input source disabled, it switches the input, but the screen will just be blank instead of showing the output until I manually select an input again. If I have auto select input source enabled, it seems to switch perfectly, but then it is unable to connect to the monitor to switch it back again (DDC communication failed). |
|
Since you've posted on this thread, I gather that:
- you're trying to switch between Linux and a separate machine running
Windows
- ClickMonitorDDC (or alternative Windows program) successfully switches
the display from the Windows computer to Linux
- the problems occur when trying to switch from Linux to Windows
On 1/16/20 6:13 PM, Jonathan Haylett wrote:
I have a Dell P2317H if it might be any help for testing.
If I have auto select input source disabled, it switches the input,
but the screen will just be blank instead of showing the output until
I manually select an input again.
I think what you're saying is that the screen goes blank when you use
"ddcutil setvcp 60". You then use a front panel button to activate the
OSD, navigate to the Input Source menu, and choose the input for the
Windows system. At that point the output of the Windows system appears.
What does the OSD show as the input before you manually select the input?
What happens if you try using different connectors for the Linux and
Windows systems? DDC communication over DisplayPort can be problematic.
If I have auto select input source enabled, it seems to switch
perfectly, but then it is unable to connect to the monitor to switch
it back again.
I think what you're saying here is that with auto-select enabled, using
ddcutil successfully switches the input to the Windows system. At this
point, what does the OSD show as the selected input? However, ddcutil
cannot switch it back. This would not be unexpected. Some monitors
will respond to DDC/CI commands from any input. Other monitors will
only respond to DDC/CI commands from the currently selected input. Can
you use ClickMonitorDDC (or another Windows program) to switch back to
Linux?
Is Auto-Select actually an independent setting from VGA/DP/HDMI? When
multiple inputs are connected, what is the order of preference for input
source selection when you first turn on the monitor?
Please run "ddcutil environment --verbose" and send the output as an
attachment so that I can better understand your system.
… —
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#83?email_source=notifications&email_token=ADMGY3RZGXZ6ZIU3U22ZMXLQ6DSZ3A5CNFSM4HIL32O2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJF4KRQ#issuecomment-575391046>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3SEW3G4VCRFTELHXQ3Q6DSZ3ANCNFSM4HIL32OQ>.
|
For now this is just on Linux using ddcutil. I am preparing for the summer when Once I have built my new PC I will be able to do more testing with both Windows
Correct. It does not exactly look like the normal black, but more of a blueish black glow.
No Windows, but yes if I choose any input with the OSD it goes back to normal.
It shows the input that I told it to switch to using ddcutil. For example if I do
I have only used HDMI so far. This laptop I'm currently using only has HDMI and VGA.
Correct, it switches successfully to any output I tell it to (not specifically Windows).
It shows the newly selected input, which is the correct and expected behaviour.
That is understandable, and I can work with it. I only noted it as interesting
Will be testing that first thing when I have my new PC built. This monitor has
Not entirely sure what you mean, but I think you are asking if auto-select is If that is what you are asking, the answer is yes. It is a toggleable on/off
I will have to get back to you on this tomorrow as it is getting late here. |
|
If you're not switching between Linux and Windows, are you switching
between 2 Linux systems?
What is connected to each of the 3 monitor inputs, VGA, DisplayPort, and
HDMI?
…On 1/18/20 6:53 PM, Jonathan Haylett wrote:
Since you've posted on this thread, I gather that: - you're trying
to switch between Linux and a separate machine running Windows -
ClickMonitorDDC (or alternative Windows program) successfully
switches the display from the Windows computer to Linux - the
problems occur when trying to switch from Linux to Windows
For now this is just on Linux using ddcutil. I am preparing for the
summer when
I will doing a dual GPU PC build using PCIe passthrough to let a
Windows 10 VM
own one graphics card. I've found ddcutil while researching a way to
switch my
USB devices and monitor between the host and guest conveniently at the
same
time.
Once I have built my new PC I will be able to do more testing with
both Windows
and Linux.
I think what you're saying is that the screen goes blank when you
use "ddcutil setvcp 60".
Correct. It does not exactly look like the normal black, but more of a
blueish black glow.
You then use a front panel button to activate the OSD, navigate to
the Input Source menu, and choose the input for the Windows
system. At that point the output of the Windows system appears.
No Windows, but yes if I choose any input with the OSD it goes back to
normal.
What does the OSD show as the input before you manually select the
input?
It shows the input that I told it to switch to using ddcutil. For
example if I do
|ddcutil setvcp 60 0x01| it shows VGA as the selected input.
What happens if you try using different connectors for the Linux
and Windows systems? DDC communication over DisplayPort can be
problematic.
I have only used HDMI so far. This laptop I'm currently using only has
HDMI and VGA.
I think what you're saying here is that with auto-select enabled,
using ddcutil successfully switches the input to the Windows system.
Correct, it switches successfully to any output I tell it to (not
specifically Windows).
At this point, what does the OSD show as the selected input?
It shows the newly selected input, which is the correct and expected
behaviour.
This would not be unexpected. Some monitors will respond to
DDC/CI commands from any input. Other monitors will only respond
to DDC/CI commands from the currently selected input.
That is understandable, and I can work with it. I only noted it as
interesting
because I am able to switch back and forth when auto-select is
disabled, but of
course that's no good because it just gives me a blank screen. I
suspect it's
because it's failing to properly switch from the original input in
that scenario.
Can you use ClickMonitorDDC (or another Windows program) to switch
back to Linux?
Will be testing that first thing when I have my new PC built. This
monitor has
only 1xHDMI, 1xDP, and 1xVGA so I don't know how well that's going to go.
Is Auto-Select actually an independent setting from VGA/DP/HDMI?
Not entirely sure what you mean, but I think you are asking if
auto-select is
its own option and not the single use "Auto" that you select from the list
of "Auto, VGA, DP, HDMI".
If that is what you are asking, the answer is yes. It is a toggleable
on/off
option in the settings, and it makes it so the monitor will switch
input when a
new signal is detected.
When multiple inputs are connected, what is the order of
preference for input source selection when you first turn on the
monitor? Please run "ddcutil environment --verbose" and send the
output as an attachment so that I can better understand your system.
I will have to get back to you on this tomorrow as it is getting late
here.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#83?email_source=notifications&email_token=ADMGY3TQCIIYRR24SDZN52DQ6OJANA5CNFSM4HIL32O2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJKETYY#issuecomment-575949283>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3XM3VH2P4MWR46UYG3Q6OJANANCNFSM4HIL32OQ>.
|
|
Well, yes the VGA is connected to my Dell PowerEdge R210ii running Proxmox VE (based on Debian 10). The DisplayPort is not connected to anything. |
|
And to complete the answer from your earlier post, the HDMI input is
connected to the laptop. Correct?
Do you see similar behavior when running ddcutil from the Dell server as
from the laptop?
From your earlier post:
Q: What does the OSD show as the input before you manually select the
input?
A: It shows the input that I told it to switch to using ddcutil. For
example if I do
|ddcutil setvcp 60 0x01| it shows VGA as the selected input.
This indicates that the issue is in the monitor's DDC/CI
implementation. It registers the change, e.g. to VGA, but does not
properly implement it.
…On 1/19/20 8:00 AM, Jonathan Haylett wrote:
Well, yes the VGA is connected to my Dell PowerEdge R210ii running
Proxmox VE (based on Debian 10). The DisplayPort is not connected to
anything.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#83?email_source=notifications&email_token=ADMGY3V6NMXV5HYQPBAZFHLQ6RFHJA5CNFSM4HIL32O2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJKRSBQ#issuecomment-576002310>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3VS5ZIG5JRWB6B5WNLQ6RFHJANCNFSM4HIL32OQ>.
|
|
This is what happened when I ran With auto-select enabled, it again seems to work perfectly. Without auto-select, many weird things happen. Now that I'm trying ddcutil from two separate inputs, even weirder things can happen than before, and it's more inconsistent with what happens. For instance, the above refresh rate error did not happen on the second try. I also somehow got it into a state where it was showing the content of the HDMI input (offset to the right a bit) but it thought it was showing the VGA input. It does seem like a bug (probably in the monitor's implementation as you say) that everything goes haywire when auto-select is disabled. EDIT: And yes the HDMI input is connected to the laptop. |
|
Hello Sanford, I'm going to quote an earlier post in this issue (#83 (comment)): "... This would not be unexpected. Some monitors This is exactly what I am facing too, so I will not open a new topic just for this. I've done a bit more testing and you were right with your assumptions.
Long story short, is there anything I can do on Linux/ddcutil side while 'Monitor 1' is reported in this failed state, to force the change I want? A workaround (yet to be practically implemented) is to issue the switch back to DVI during shutdown (via a batch script or something similar) - which is the scenario I am facing. Thanks for your attention. Nikola |
|
I appreciate the clarity of your description. I would like to see the
output of "ddcutil environment --verbose". It can avoid lots of little
questions.
It may be worth trying to force ddcutil to send a sevtcp request for
feature x60 even though the i2c bus does not appear to support DDC.
As a first step, a quick questions and test.
1) Since ClickMonitorDDC works on the Windows side, it appears you're
using a dedicated card with a non-virtual driver in the Windows VM. Am
I correct? I also gather that there's only 1 monitor connected to the VM.
2) With the input source for Display 1 is set to the Windows VM, please
run the command "i2cdetect -y --bus <busno>", where <busno> is the
number of the I2C bus, and send the output. The question is whether
"37" appears at row 30, column 7.
Regards,
Sanford
…On 5/5/20 11:17 AM, mineturtle36 wrote:
Hello Sanford,
I'm going to quote an earlier post in this issue (#83 (comment)
<#83 (comment)>):
"... This would not be unexpected. Some monitors
will respond to DDC/CI commands from any input. Other monitors will
only respond to DDC/CI commands from the currently selected input. Can
you use ClickMonitorDDC (or another Windows program) to switch back to
Linux? ..."
This is exactly what I am facing too, so I will not open a new topic
just for this.
I've done a bit more testing and you were right with your assumptions.
1. 'ddcutil detect' reports Display 1 and Display 2 - as it should.
All good here.
2. I instruct ddcutil to switch Input Source from DVI (Linux
baremetal host) to HDMI (Windows 10 KVM). It works.
3. I run 'ddcutil detect' on Linux, and after the above is done -
ddcutil reports 'Invalid display - DDC communication failed' for
Display 1. Display 2 is unaffected.
>From this point I can not talk to Display 1 from Linux.
4. In Win10 I used ClickMonitorDDC to successfully issue a change
back to DVI and it works.
At this moment ddcutil is again seeing Display 1 properly.
Long story short, is there anything I can do on Linux/ddcutil side
while 'Monitor 1' is reported in this failed state, to force the
change I want?
A workaround (yet to be practically implemented) is to issue the
switch back to DVI during shutdown (via a batch script or something
similar) - which is the scenario I am facing.
Thanks for your attention.
Nikola
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#83 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3SAXFXOGTR6PTEUA5TRQAUXDANCNFSM4HIL32OQ>.
|
|
Right on the money with question 1. There are two BenQ monitors attached to one GPU (via DVI) on the baremetal Linux, and I'm passing though the second GPU from baremetal system to Windows VM. Once the VM is started, my physical peripherals (mouse+keyboard) get passed to the VM, and for now only one of the two monitors is dedicated as the VM display (via HDMI), as you correctly surmised. Question 2. EDIT: Found the workaround solution with a freeware software called ControlMyMonitor (for Windows). Made a batch file and slapped the shutdown command in the end. |
|
The important thing is that I2C slave address (x37) is responsive on
Linux even when the monitor has been switched to Windows and fails the
DDC communication check. It may be possible to force that DDC setvcp
request be sent to the monitor even when it doesn't appear to support DDC.
With the monitor you're calling Display1 set to the Windows VM, please
execute the following command and attach the output:
$ ddcutil detect -v --trcfile i2c_bus_core --trcfile i2c_execute
--trcfile ddc_displays --force-slave-address
Sanford
…On 5/5/20 4:37 PM, mineturtle36 wrote:
Outputs.zip
<https://github.com/rockowitz/ddcutil/files/4583454/Outputs.zip>
Right on the money with question 1.
There are two BenQ monitors attached to one GPU (via DVI) on the
baremetal Linux, and I'm passing though the second GPU from baremetal
system to Windows VM.
Once the VM is started, my physical peripherals (mouse+keyboard) get
passed to the VM, and for now only one of the two monitors is
dedicated as the VM display (via HDMI), as you correctly surmised.
Need to buy another HDMI cable to have a full two screen setup in VM.
And I also need to figure out how to return the peripherals back to
Host control while the VM is running - which is another can of worms
best used in another fishing pond.
Question 2.
Yes, 37 is there in both cases if I'm reading this right - but there
is one difference in another place - attaching the output before and
after (i.e. when ddcutil reports Display1 & when ddcutil reports
Invalid Display).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#83 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3RVXO35PV6CB7ZNYB3RQB2ITANCNFSM4HIL32OQ>.
|
|
Sure thing, here you go: |
|
I have hacked in an experimental change that may allow you to send a
setvcp x60 request to the monitor even if it fails the DDC communication
tests. The changes are in the current development branch, 0.9.9-dev, on
github.
You must specify the display using its bus number, e.g.
$setvcp --busno 5 setvcp 60 x0f
If that fails, add the --force-slave-address option.
If the display changes, but verification fails, it may be that the
verification is just happening too fast. Add the --noverify option ,
Let me know how it goes. When testing with a Dell U3011 monitor, setvcp
60 works even if the monitor input is switched to a different monitor,
even without the hack. The behavior really does vary by monitor.
When you are intending to send output, please include the options:
--verbose --trcfile i2c_bus_core --trcfile i2c_execute --trcfile
ddc_displays
Sanford
…On 5/5/20 7:13 PM, mineturtle36 wrote:
Sure thing, here you go:
Outputs_trc.zip
<https://github.com/rockowitz/ddcutil/files/4584103/Outputs_trc.zip>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#83 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3U3CAGTV5HFMZGXADDRQCMRHANCNFSM4HIL32OQ>.
|
|
No dice :( $ ddcutil setvcp --bus 2 60 0x11 $ ddcutil setvcp --bus 2 60 0x11 --force-slave-address Here's the requested verbose output: |
|
I owe you an apology. I left out the most important part. Option --f6
turns on the special code path. Without it everything behaves as normal.
Sanford
…On 5/7/20 10:23 AM, mineturtle36 wrote:
No dice :(
$ ddcutil setvcp --bus 2 60 0x11
DDC communication failed for monitor on I2C bus /dev/i2c-2
$ ddcutil setvcp --bus 2 60 0x11 --force-slave-address
DDC communication failed for monitor on I2C bus /dev/i2c-2
Here's the requested verbose output:
0.9.9.output.zip
<https://github.com/rockowitz/ddcutil/files/4593492/0.9.9.output.zip>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#83 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3WD3N4QBIM5B5ASFXDRQK76XANCNFSM4HIL32OQ>.
|
|
No worries Sanford. $ ddcutil setvcp --bus 2 60 0x11 --f6 --force-slave-address --noverify |
|
Thanks for running the test. Unfortunately, I'm out of options. What
the log shows is that, with the --f6 option, ddcutil ignores the checks
for DDC communication and writes a DDC Set VCP request packet to
/dev/i2c-2. The status code of the write is 0, indicating that
communication was successful, i.e. the monitor returned an ACK bit to
indicate receipt of the packet. The monitor simply isn't processing
the request.
…On 5/7/20 10:40 AM, mineturtle36 wrote:
No worries Sanford.
For a moment there I thought it worked, based on the received output -
but sadly, the monitor is still firmly in the clutches of the VM:
$ ddcutil setvcp --bus 2 60 0x11 --f6 --force-slave-address --noverify
Setting i2c_force_bus
(initial_checks_by_dh ) dh=Display_Handle[i2c: fd=3, busno=2], Forcing
DDC communication success.
0.9.9.output.2.zip
<https://github.com/rockowitz/ddcutil/files/4593609/0.9.9.output.2.zip>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#83 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3RDREUWHP4UJTODM6DRQLB45ANCNFSM4HIL32OQ>.
|
|
Well then, not much we can do since BenQ decided to not do a proper job on these monitors of mine. Just my luck. Last question: In the future when I'll be looking for a replacement - is there something in the declaration, specs, an online resource maybe - testing the proper functionality of DDC, anything of the sorts - so the future me can make an informed choice? Thank you for your support and take care! |
|
I wouldn't go as far as saying that BenQ decided to not do a proper
job. This really is a corner case. How a monitor should behave if it
receives a DDC request from a display that's not the currently active
input is simply not defined. Actually, my expectation was that monitors
respond only to DDC messages from the currently active input.
Unfortunately, because it's not part of the DDC/CI spec, I doubt you'd
see the behavior defined in any manufacturer's specs. The most you'll
see is "Support DDC/CI".
I hazard that displays by the same manufacturer are likely to behave
similarly, but even here there's probably variation depending on the DDC
chip manufacturer and firmware level.
I'm afraid the only way to know for certain is to actually test the
monitor, using ddcutil and/or one of the comparable Windows programs.
Sanford
…On 5/12/20 5:46 PM, mineturtle36 wrote:
Well then, not much we can do since BenQ decided to not do a proper
job on these monitors of mine. Just my luck.
No worries - I have a workaround I mentioned earlier - so not all is lost.
Last question: In the future when I'll be looking for a replacement -
is there something in the declaration, specs, an online resource maybe
- testing the proper functionality of DDC, anything of the sorts - so
the future me can make an informed choice?
Thank you for your support and take care!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#83 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3UWK3BX27W74ZQUUJDRRG7SFANCNFSM4HIL32OQ>.
|
I am transferring an email communication we had with Sanford Rockowitz in order to continue it here and share it publicly with the community.
Me:
The text was updated successfully, but these errors were encountered: