Unable to detect Cintiq CCH (DTH-A1300) despite get-edid returning information about it (that parse-edid can parse) #104
Labels
cintiq
monitor specific
problems with particular monitors
nvidia proprietary
proprietary Nvidia driver
Comments
|
Some more info, tracing the I2C-related group: |
|
For some comparison with get-edid's code:
ddcutil is also definitely not seeing that EDID signature, as it gets just a bunch of 00,ff,ff,ff,00 data. You can see the If the difference isn't in how the I2C bus is being accessed, what could be causing the device to return bad data in ddcutil but not get-edid? |
InconsolableCellist
changed the title
get-edid | parse-edid returning information about it
InconsolableCellist
changed the title
get-edid | parse-edid returning information about it
More system info |
|
So I saw in that latest command I found, the I put these in, rebooted, and now ddcutil works for my monitors! Hopefully my steps above are useful for someone. Still not sure why |
|
First, thank you for the thorough bug report and comparison and
analysis. It gives me something to work with.
Here's what I believe is going on. The original I2C bus speed is 100
kbit/sec (standard mode). There's also full speed (400 kbit/sec), fast
mode (1 mbit/sec) and high speed (3.2 mbit/sec).
Apparently, the proprietary Nvidia driver defaults to full speed (400
kbit/sec). Some (most?) monitors work properly at full speed. It
appears that your Cintiq monitor does not. Using the RMI2cSpeed=100
option slows the I2C bus to standard mode, allowing the Cintiq monitor
to work properly.
Whereas ddcutil reads the entire first 128 byte block of the EDID in one
call, read-edid uses 256 calls to read single bytes. This apparently
slows things down enough for your monitor to work. (Why 128 vs 256
bytes? The original EDID was a single 128 byte block. This was revised
to specify a second 128 block, and further revised to allow for multiple
second blocks, selected by writing to slave address x30. ddcutil is
interested only in the original 128 bytes.)
There is another way to slow things down, by increasing the duration of
host sleeps mandated by the DDC/CI protocol. This can be adjusted using
the recently added ddcutil option --sleep-multiplier.
I'd appreciate it if you'd do the following:
Disable the special nvidia driver options.
Try "ddcutil detect --sleep-multiplier 4". Does this solve the problem?
(Probably not, but it's worth checking.)
I've uploaded a version of ddcutil to branch 0.9.9-dev that reads the
EDID 1 byte at a time. Try running "ddcutil detect --trcfunc
i2c_get_raw_edid_by_fd". (--trcfunc will produce more targeted
diagnostics than --trace.) Does the EDID get read? (N. the full detect
command will likely fail during the feature reads that are part of
detection.) If the EDID read succeeds, I'll look into using single byte
reads more generally.
Regards,
Sanford
…On 2/1/20 6:32 PM, InconsolableCellist wrote:
So I saw in that latest command I found, the |ddcutil environment|
one, that it mentioned some parameters being required for the Nvidia
driver:
|$ cat /etc/X11/xorg.conf.d/90-nvidia_i2c.conf Section "Device" Driver
"nvidia" Identifier "Dev0" Option "RegistryDwords" "RMUseSwI2c=0x01;
RMI2cSpeed=100" # solves problem of i2c errors with nvidia driver #
per
https://devtalk.nvidia.com/default/topic/572292/-solved-does-gddccontrol-work-for-anyone-here-nvidia-i2c-monitor-display-ddc/#4309293
EndSection |
I put these in, rebooted, and now ddcutil works for my monitors!
Hopefully my steps above are useful for someone. Still not sure why
|get-edid| was able to access the device.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#104?email_source=notifications&email_token=ADMGY3Q4RQQEW7C6JFHSSCDRAYBCPA5CNFSM4KOVPI6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKRJNMY#issuecomment-581080755>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3S3UVMLU7ZK4EKOE2DRAYBCPANCNFSM4KOVPI6A>.
|
|
That sounds like a good theory with the timing issue! I've disabled the Xorg conf file and I'm first trying with the master branch (a9b4a20) I recompiled and tested with 0.9.9-dev and check this out: |
|
I should note too that the same situation was occurring with that third monitor, the DELL P2214H, which is an old 1080p monitor, from 2015 (the Cintiq 2013). I suppose the single-byte read is more compatible. I'm glad I was able to help diagnose this! I guess you have to put more of those |
|
On 2/2/20 6:40 PM, InconsolableCellist wrote:
I should note too that the same situation was occurring with that
third monitor, the DELL P2214H, which is an old 1080p monitor, from
2015 (the Cintiq 2013). I suppose the single-byte read is more
compatible. I'm glad I was able to help diagnose this! I guess you
have to put more of those |#ifdef SINGLE_BYTE_READ| blocks around, to
enable all the functionality? Or maybe it can be a runtime arg,
something like |--compatibility|. Or maybe just on by default?
Once the displays are detected, do getvcp and setvcp work? How about
capabilities, which requires multiple write/read cycles?
I have a Dell P2411h which often fails communication with DDC data
errors. The --sleep-multiplier option resolves the problem, but it will
be interesting to see if single byte reads do as well. Can you send me
the "ddcutil probe" output for this and the Cintiq monitor? It will be
interesting to see if they are using the same controller chip as my P2411h.
The iftested code in i2c_get_raw_edid_by_fd() is there for quick and
dirty testing. Now I have to figure out whether to always use single
byte reads, fall back to single byte reads if a multi-byte read fails,
or as you suggest use a command line option. I'd prefer to avoid the
latter, as it requires people to dig into the documentation. Given
that 90% of ddcutil's time is spend in DDC/CI protocol mandated sleeps
(unless shortened by a --sleep multiplier value less than 1 - I actually
have been able to get it down to as low as .2 for some monitors), single
byte reads shouldn't have a perceptible affect on elapsed execution
time. This needs to be measured. Harder to check for will the question
of whether there are situations where multi-byte reads work but multiple
single byte reads do not.
Thank you for bringing this case to my attention and helping to diagnose
it. I'm hoping the changes will significantly reduce the number of
problematic monitors.
Changing topics, your github userid suggests that you're a cellist. Is
that the case? If so, you may be amused to know that I manufacture
Rockstops. It's a small old family business that I maintain on the side.
Regards,
Sanford
… —
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#104?email_source=notifications&email_token=ADMGY3RDDVG3IV4DJM2BDMLRA5KVFA5CNFSM4KOVPI6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKSEIWQ#issuecomment-581190746>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3VRFFI4HIGEPSIRE7LRA5KVFANCNFSM4KOVPI6A>.
|
It appears that it doesn't: That's on both the Cintiq and Dell monitors. Probe also fails:
That's funny! Though I'm not actually a cellist, I just made a random name. That's cool though |
|
Your results are consistent with the fact that the single byte read
change was made only to the EDID reading on the I2C bus, not to DDC
communication. So the change needs to be more generally applied. Thanks.
…On 2/2/20 10:51 PM, InconsolableCellist wrote:
Once the displays are detected, do getvcp and setvcp work? How about
capabilities, which requires multiple write/read cycles?
It appears that it doesn't:
|$ sudo ./ddcutil -b 2 getvcp 12 DDC communication failed for monitor
on I2C bus /dev/i2c-2 $ sudo ./ddcutil -b 2 setvcp 12 50 DDC
communication failed for monitor on I2C bus /dev/i2c-2 |
That's on both the Cintiq and Dell monitors. Probe also fails:
|$ sudo ./ddcutil -b 2 probe DDC communication failed for monitor on
I2C bus /dev/i2c-2 |
|-detect| still lists the monitors though, same as above, but note
that it says "DDC communication failed," both before and now:
|$ sudo ./ddcutil detect Invalid display I2C bus: /dev/i2c-1 EDID
synopsis: Mfg id: DEL Model: DELL P2214H Serial number: KW14V51H0N3B
Manufacture year: 2015 EDID version: 1.3 DDC communication failed
Invalid display I2C bus: /dev/i2c-2 EDID synopsis: Mfg id: WAC Model:
Cintiq A1300 Serial number: 3IAH000034 Manufacture year: 2013 EDID
version: 1.3 DDC communication failed Display 1 I2C bus: /dev/i2c-3
EDID synopsis: Mfg id: SAM Model: U28E590 Serial number: HTPK416852
Manufacture year: 2018 EDID version: 1.4 VCP version: 2.0 |
Changing topics, your github userid suggests that you're a
cellist. Is that the case? If so, you may be amused to know that I
manufacture Rockstops. It's a small old family business that I
maintain on the side.
That's funny! Though I'm not actually a cellist, I just made a random
name. That's cool though
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#104?email_source=notifications&email_token=ADMGY3UWSQIXEAJIWAJUI73RA6IFXA5CNFSM4KOVPI6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKSMYSI#issuecomment-581225545>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3QHHBLTVAW5QHPAAW3RA6IFXANCNFSM4KOVPI6A>.
|
|
I've added code to further parameterize how I2C writes and reads are performed. The latest version of ddcutil on github contains some special code that exercises these variations (16 permutations) if the command "ddcutil detect --i1 1" is issued. I'd appreciate it if you could run this command both with and without the 90-nvidia_i2c.conf settings and send me the output. Running this command for several monitors here, what I observe is that all monitors return the EDID successfully no matter which variation is chosen. Some monitors work with single byte DDC reads but others do not. All monitors work with multi-byte DDC reads. It will be interesting to see how your system behaves. If anyone else besides InconsolableCellist runs the "ddcutil detect --i1 1" command I'd appreciate seeing the output. Also, let me know your video card and driver (or better yet send the output of "ddcutil environment --verbose". Please send the output as attachments if possible. --Sanford |
|
Sure. Here's the run without the 90-nvidia_i2c.conf: |
|
Here it is after restoring the nvidia conf and rebooting: |
|
and environment --verbose: |
|
Thanks for running the tests. Here are my takeaways. Everything works with the special Nvidia driver settings, and always works with the Samsung U238E590, so the question is whether ddcutil's I2C communication can be improved at the margin for problematic driver/monitor combinations.
This is at variance here with what I see here with 2 marginal monitors (Acer X35W and Dell P2411h) and the amdcpu driver. EDID reads succeed with all variants. However, I2C communication fails for multiple single byte reads and succeeds for a single muliti-byte read - the opposite of your result. These results suggest that EDID reading can be marginally improved using single byte reads. That would at least reduce the confusion caused by ddcutil not reporting a monitor that exists, whether or not DDC communication subsequently works. However, I would like to see the result of more tests before making any changes to the low level IO. Regards, |
rockowitz
added
monitor specific
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug description
I have a Cintiq A1300 device connected over HDMI, and it appears to be detected on the i2c bus by get-edid:
However, ddcutil won't detect it:
I pulled the latest code from git and compiled with all the options enabled (http://www.ddcutil.com/building/) and see similar behavior:
But still nothing from the other busses
If I try to force the issue by attempting to set the brightness (presumably), it also says no monitor is detected:
System information
Do you know what's going wrong? Thanks
The text was updated successfully, but these errors were encountered: