search

rockowitz / ddcutil

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

DDC Communication on Linux Fails After Using ClickMonitorDDC or Dell Display Manager on Windows 10 #83

Open k-kolev opened 5 years ago

k-kolev commented 5 years ago

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:

I am having troubles with Dell P2314H monitor. I am not able to switch input sources from DVI to Display Port.

My configuration is as follows. Linux desktop running Fedora 29 with ddcutil 0.9.5 installed. I used the prebuild rpm for Fedora 28. Desktop video card is connected to monitor via DVI cable. On the other side I have 14’’ Dell Latitude 5591 laptop running Windows 10. It is connected via USB Type-c connector to a docking station. The docking station is connected to the Dell monitor via Display Port cable.

Now what I want is to switch easily from Linux to Windows and vice versa.

Windows -> Linux is working fine – I installed Dell Display Manager application, which accepts command line parameter for switching monitor input. I run the application with the appropriate parameter and exit which switches my monitor back to Linux flawlessly.

But Linux -> Windows is not working. To be precise it works one time only and after reboot. The command I use and run as root is: ddcutil setvcp 60 x0f. The first time it works but then nothing happens – no error, no message, nothing.

I am attaching the output of the interrogate command if you can identify something suspicious.

Help would be very appreciated. If you prefer other channel for communication like issue tracker for example or something else please let me know.

Have a good day 😊

k-kolev commented 5 years ago

Sanford:

First, thank you for taking the trouble to attach the interrogate output. It's voluminous, but critical for remote debugging.

What's most striking is that none of the DDC communication is working. Queries always return a DDC NULL response. Did you execute this after switching to Windows? What happens if you execute interrogate immediately after boot?

I wonder if Dell Display Manager is setting something in the monitor such that, even though it switches back to Linux, DDC is no longer responsive? To rule this out, try disabling Dell Display Manager and use ClickMonitorDDC or softMCCS on the Windows side.

Also, I believe the laptop has a HDMI connector. What happens if you use that to connect to the monitor instead of the docking station?

In general, I prefer to use the issue tracker for technical support questions, as that creates a shared knowledge base.

I'll be interested to see what you find. This is a peculiar problem.

Regards, Sanford

k-kolev commented 5 years ago

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

rockowitz commented 5 years ago

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 https://github.com/rockowitz/ddcutil/issues/83#issuecomment-486621470, or mute the thread https://github.com/notifications/unsubscribe-auth/ADMGY3RNKJURHDVYQAEFGZ3PSGDLJANCNFSM4HIL32OQ.

k-kolev commented 5 years ago

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 notifications@github.com 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 https://github.com/rockowitz/ddcutil/issues/83#issuecomment-486621470,

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 https://github.com/rockowitz/ddcutil/issues/83#issuecomment-487436413, or mute the thread https://github.com/notifications/unsubscribe-auth/AL5KPKGZ5QPE5UTIQY5VUG3PSZKXBANCNFSM4HIL32OQ .

k-kolev commented 5 years ago

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.

rockowitz commented 5 years ago

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 https://github.com/rockowitz/ddcutil/issues/83#issuecomment-490874033, or mute the thread https://github.com/notifications/unsubscribe-auth/ADMGY3W772QP5DIXB7THMPTPUQG5LANCNFSM4HIL32OQ.

rockowitz commented 5 years ago

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 https://github.com/rockowitz/ddcutil/issues/83#issuecomment-490874033, or mute the thread https://github.com/notifications/unsubscribe-auth/ADMGY3W772QP5DIXB7THMPTPUQG5LANCNFSM4HIL32OQ.

rockowitz commented 5 years ago

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 https://github.com/rockowitz/ddcutil/issues/83#issuecomment-490874033, or mute the thread https://github.com/notifications/unsubscribe-auth/ADMGY3W772QP5DIXB7THMPTPUQG5LANCNFSM4HIL32OQ.

k-kolev commented 5 years ago
  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: -- -- -- -- -- -- -- --

  1. While on Windows run ClickMonitorDDC_6_8.exe s DVI1 q

  2. 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: -- -- -- -- -- -- -- --

  1. Result: Diffing both outputs reports they are equivalent.
rockowitz commented 5 years ago

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: -- -- -- -- -- -- -- -- |

  1. Result: Diffing both outputs reports they are equivalent.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/83#issuecomment-491314426, or mute the thread https://github.com/notifications/unsubscribe-auth/ADMGY3RMJSG6CFNDGAQTY3TPUWC4ZANCNFSM4HIL32OQ.

JonnyHaystack commented 4 years ago

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).

rockowitz commented 4 years ago

Since you've posted on this thread, I gather that:

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 https://github.com/rockowitz/ddcutil/issues/83?email_source=notifications&email_token=ADMGY3RZGXZ6ZIU3U22ZMXLQ6DSZ3A5CNFSM4HIL32O2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJF4KRQ#issuecomment-575391046, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3SEW3G4VCRFTELHXQ3Q6DSZ3ANCNFSM4HIL32OQ.

JonnyHaystack commented 4 years ago

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.

rockowitz commented 4 years ago

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 https://github.com/rockowitz/ddcutil/issues/83?email_source=notifications&email_token=ADMGY3TQCIIYRR24SDZN52DQ6OJANA5CNFSM4HIL32O2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJKETYY#issuecomment-575949283, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3XM3VH2P4MWR46UYG3Q6OJANANCNFSM4HIL32OQ.

JonnyHaystack commented 4 years ago

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.

rockowitz commented 4 years ago

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 https://github.com/rockowitz/ddcutil/issues/83?email_source=notifications&email_token=ADMGY3V6NMXV5HYQPBAZFHLQ6RFHJA5CNFSM4HIL32O2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJKRSBQ#issuecomment-576002310, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3VS5ZIG5JRWB6B5WNLQ6RFHJANCNFSM4HIL32OQ.

JonnyHaystack commented 4 years ago

This is what happened when I ran ddcutil setvcp 60 0x11 from the dell server with auto-select disabled. image

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.

mineturtle36 commented 4 years ago

Hello Sanford,

I'm going to quote an earlier post in this issue (https://github.com/rockowitz/ddcutil/issues/83#issuecomment-575947279):

"... 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

rockowitz commented 4 years ago

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 ", where 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) https://github.com/rockowitz/ddcutil/issues/83#issuecomment-575947279):

"... 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 https://github.com/rockowitz/ddcutil/issues/83#issuecomment-624117481, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3SAXFXOGTR6PTEUA5TRQAUXDANCNFSM4HIL32OQ.

mineturtle36 commented 4 years ago

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).

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. This way when the script is executed, system first transfers Monitor back to DVI, and then the VM shuts down.

rockowitz commented 4 years ago

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 https://github.com/rockowitz/ddcutil/issues/83#issuecomment-624292715, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3RVXO35PV6CB7ZNYB3RQB2ITANCNFSM4HIL32OQ.

mineturtle36 commented 4 years ago

Sure thing, here you go: Outputs_trc.zip

rockowitz commented 4 years ago

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 https://github.com/rockowitz/ddcutil/issues/83#issuecomment-624354139, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3U3CAGTV5HFMZGXADDRQCMRHANCNFSM4HIL32OQ.

mineturtle36 commented 4 years ago

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

rockowitz commented 4 years ago

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 https://github.com/rockowitz/ddcutil/issues/83#issuecomment-625286535, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3WD3N4QBIM5B5ASFXDRQK76XANCNFSM4HIL32OQ.

mineturtle36 commented 4 years ago

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

rockowitz commented 4 years ago

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 https://github.com/rockowitz/ddcutil/issues/83#issuecomment-625296345, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3RDREUWHP4UJTODM6DRQLB45ANCNFSM4HIL32OQ.

mineturtle36 commented 4 years ago

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!

rockowitz commented 4 years ago

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 https://github.com/rockowitz/ddcutil/issues/83#issuecomment-627615488, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3UWK3BX27W74ZQUUJDRRG7SFANCNFSM4HIL32OQ.