Fails to build from master or tarball on Ubuntu 14.04.4 LTS about ddcutil HOT 13 CLOSED

Chris,

Thanks so much for taking the trouble to send the detailed report. I
thought I had addressed the problem of undeclared NULL and different
i2c-dev.h versions, but apparently not. I'll try to build in a Ubuntu
14.04 environment and get back to you.

Sanford

On 03/19/2016 06:33 PM, Chris Dahms wrote:

Errors out during make

In file included from i2c/i2c_base_io.c:37:0:
/usr/include/linux/i2c-dev.h: In function 'i2c_smbus_write_quick':
/usr/include/linux/i2c-dev.h:176:55: error: 'NULL' undeclared (first
use in this function)
return i2c_smbus_access(file,value,0,I2C_SMBUS_QUICK,NULL);

Details of configure, make & packages installed in this gist
https://gist.github.com/zentrification/bc95b2c8c55e29c9aecf

Seems similar to this which I found by googling
http://comments.gmane.org/gmane.comp.monitoring.nut.devel/6731

Also, when trying to build master autogen.sh did not work correctly,
but this sequence did

autoreconf --install
./autogen.sh
./configure

Let me know if you need any more information, or would like me to try
anything out.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#1

from ddcutil.

Hi Chris,

I installed Ubuntu 14.04 in a VM and replicated your problems.

The NULL value problem had indeed been addressed, but the fix hadn't
been pushed to github. That, and other recent changes, have now been
pushed. The downloadable tarball, version 0.3.1, is in sync with the
github repository.

There were a couple problems with autogen. I've added the --install
option to autoreconf, and also ensured that there are empty m4 and
config directories in the repo.

I can now install build from either the tarball or the a cloned git repo
in the Ubuntu 14.04 VM. (Unfortunately, as far as I can tell the I2C
bus is not emulated in VirtualBox, so while ddctool builds in the VM it
doesn't detect any monitors.)

Let me know if these changes allow you proceed.

By the way, what piqued your interest in ddctool?

Sanford

On 03/19/2016 06:33 PM, Chris Dahms wrote:

Errors out during make

In file included from i2c/i2c_base_io.c:37:0:
/usr/include/linux/i2c-dev.h: In function 'i2c_smbus_write_quick':
/usr/include/linux/i2c-dev.h:176:55: error: 'NULL' undeclared (first
use in this function)
return i2c_smbus_access(file,value,0,I2C_SMBUS_QUICK,NULL);

Details of configure, make & packages installed in this gist
https://gist.github.com/zentrification/bc95b2c8c55e29c9aecf

Seems similar to this which I found by googling
http://comments.gmane.org/gmane.comp.monitoring.nut.devel/6731

Also, when trying to build master autogen.sh did not work correctly,
but this sequence did

autoreconf --install
./autogen.sh
./configure

Let me know if you need any more information, or would like me to try
anything out.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#1

from ddcutil.

Just tested master, builds fine on my Ubuntu 14.04.4 setup now, thanks!

Your forum post on nvidia piqued my interest, you mentioned writing your own and I stumbled across your github

I recently switched from a NVS 510 to a GTX 970
ddccontrol worked fine w/ my NVS 510, and now fails to find anything with my GTX 970

Unfortunately I am still having the issues outlined in this post
https://devtalk.nvidia.com/default/topic/572292/linux/-solved-does-gddccontrol-work-for-anyone-here-nvidia-i2c-monitor-display-ddc/3

I threw the outputs of environment & interrogate passed to ddctool here
https://gist.github.com/zentrification/9e7e717270b36bbe2bc6

Any thoughts or suggestions appreciated

from ddcutil.

Chris,

First, as you came to ddctool through github, let me make sure you're
aware of the web site, www.ddctool.com. I'll update the Nvidia Driver
Settings page to reflect what you've found.

Your message is, in a word, depressing. I had started to develop
ddctool some time ago, then set it aside when I couldn't get it to work
on my GTX660ti, as that was a show stopper for my needs. Then I saw
the nvidia post you linked to, applied the changes, and voila ddctool
worked for me with the nvidia driver. So I resumed development.

The newest Nvidia card I have to test with is the GTX660ti, so I'd
appreciate any testing you can do. All I can suggest is playing with
the RMUseSwI2C, RMUseHwI2c and RMI2cSpeed values mentioned in the post.
Also, the NVAPI_I2C_SPEED values for the Windows Nvidia API listed at
http://docs.nvidia.com/gameworks/content/gameworkslibrary/coresdk/nvapi/group__i2capi.html
suggest that the valid speed values are 3,10,33,100,200, and 400khz.
However, constant NVAPI_I2C_SPEED_DEPRECATED hints as to why the speed
setting is undocumented.

The "interrogate" command is a superset of "environment", so there's no
need to run both. In addition to checking the environment, interrogate
collects maximal information about monitor capabilities (there's
incredible variation in how monitors implement the DDC and MCCS specs)
and errors detected (I2C is an inherently unreliable protocol, some
monitors require few retries, others a painful amount). If you can
conveniently run "ddctool interrogate" with the NVS510, I'd be
interested to see the output. But unless you're using a recent
professional level monitor with features like an internal LUT, I
wouldn't ask you to do a lot of card swapping.

Regards,
Sanford

On 03/21/2016 07:43 PM, Chris Dahms wrote:

Just tested master, builds fine on my Ubuntu 14.04.4 setup now, thanks!

Your forum post on nvidia piqued my interest, you mentioned writing
your own and I stumbled across your github

I recently switched from a NVS 510 to a GTX 970
ddccontrol worked fine w/ my NVS 510, and now fails to find anything
with my GTX 970

Unfortunately I am still having the issues outlined in this post
https://devtalk.nvidia.com/default/topic/572292/linux/-solved-does-gddccontrol-work-for-anyone-here-nvidia-i2c-monitor-display-ddc/3

I threw the outputs of environment & interrogate passed to ddctool here
https://gist.github.com/zentrification/9e7e717270b36bbe2bc6

Any thoughts or suggestions appreciated

—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
#1 (comment)

from ddcutil.

Chris,

I have a question and possible suggestion.

What monitor(s) are attached to the GTX 970? How are they connected?

If the monitor has a DisplayPort connection and you're not already using
it I suggest you try that.

In my own case, when I disabled the "RegistryDwords" option from
xorg.conf, my Dell U3011 connected via DisplayPort continued to work
with ddctool. But when the connection was changed to a DVI cable the
I2C communication problems returned.

Why this makes sense: I2C communication (EDID, MCCS) is bridged over
the DisplayPort AUX channel. This might avoid the I2C timing issues.

Sanford

On 03/21/2016 07:43 PM, Chris Dahms wrote:

Just tested master, builds fine on my Ubuntu 14.04.4 setup now, thanks!

Your forum post on nvidia piqued my interest, you mentioned writing
your own and I stumbled across your github

I recently switched from a NVS 510 to a GTX 970
ddccontrol worked fine w/ my NVS 510, and now fails to find anything
with my GTX 970

Unfortunately I am still having the issues outlined in this post
https://devtalk.nvidia.com/default/topic/572292/linux/-solved-does-gddccontrol-work-for-anyone-here-nvidia-i2c-monitor-display-ddc/3

I threw the outputs of environment & interrogate passed to ddctool here
https://gist.github.com/zentrification/9e7e717270b36bbe2bc6

Any thoughts or suggestions appreciated

—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
#1 (comment)

from ddcutil.

I have two of these hooked up via DisplayPort
https://www.asus.com/us/Monitors/PB287Q/

I also have two of these available to test with
http://www.dell.com/ed/business/p/dell-u2713hm/pd

I haven't had the time to shut down and swap back to my old NVS 510 to test out, I will try soon.

from ddcutil.

On 03/29/2016 04:17 PM, Chris Dahms wrote:

I have two of these hooked up via DisplayPort
https://www.asus.com/us/Monitors/PB287Q/

Well, so much for the hope that a DisplayPort connection might solve the
problem.

One thing that caught my eye in your "ddctool environment" output is
that no DDC capable displays were detected. On the system here with the
GTX660ti card, if I don't put the RegistryDwords option in xorg.conf,
displays are still detected - I then get errors communicating with the
monitor. So I'm starting to suspect something else is going on with
your system.

I've added some additional diagnostic output to "ddctool environment" to
report on the monitor probing, which may shed some light on why no
monitors are detected. Execute it with the --verbose option:

ddctool environment --verbose

(Note: There's no point in running "ddctool interrogate" unless monitors
are actually detected.)

I've updated the github repository, and also the downloadable tarball.
The OBS repos and Ubuntu PPAs have not been updated.

I also have two of these available to test with
http://www.dell.com/ed/business/p/dell-u2713hm/pd

It would be interesting to see if detection succeeds with one of these.

One further thing, which I'm sure you've checked, but I mention for
completeness. Might DDC/CI be disabled in the monitor's OSD?

I haven't had the time to shut down and swap back to my old NVS 510 to
test out, I will try soon.

Thanks, I very much appreciate your help testing ddctool. You have the
kind of system that pushes the edge cases.

Regards,
Sanford

—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
#1 (comment)

from ddcutil.

Just rebuild from source after pulling latest master
Output from ddctool environment --verbose
https://gist.github.com/zentrification/5b2c57a2d380d038826a3e91555ba625

Yeah I enabled DDC/CI in the on screen menus to get these monitors working with ddccontrol & my NVS 510. Just doubled checked to make sure it is enabled, and it is.

from ddcutil.

So ddctool can't even read the EDID (i2c bus address 0x50). Next step
is to see if another program is having any better luck. If any do,
I'll look to see what they're doing differently.

1. What is the output of

ddccontrol -p

(It's the "Detected monitors" section that's of interest.)

2. Not sure what I2C bus numbers are actually associated with the
   monitors (though ddccontrol may have shown that), so for each of busno =
   0..5 (or just the correct bus numbers if you know them), what is the
   output of:

   i2cdetect -y busno

Does adding the -a or -r option make a difference?

3. Try get-edid and parse-edid:

get-edid

will report potential buses (along with bytes for the first EDID it finds)

Then for each potential bus:

get-edid | parse-edid

4. nvidia-settings

Does the "Acquire EDID" button work for the monitors?

5. Any other way to probe for EDID that you can think of.

Thanks,
Sanford

On 03/30/2016 12:40 AM, Chris Dahms wrote:

Just rebuild from source after pulling latest master
Output from ddctool environment --verbose
https://gist.github.com/zentrification/5b2c57a2d380d038826a3e91555ba625

Yeah I enabled DDC/CI in the on screen menus to get these monitors
working with ddccontrol & my NVS 510. Just doubled checked to make
sure it is enabled, and it is.

—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
#1 (comment)

from ddcutil.

Gist with all info you requested
https://gist.github.com/zentrification/febb58d2ed43a5376c861a903d97b54e

i2cdetect and ddccontrol fail to find much

nvidia-settings was able to dump bin & txt edid's
edid-parse fails on both, but provides some info for the bin

from ddcutil.

I also just tried factory resetting one of my monitors to see if that would make a difference, but sadly it did not

from ddcutil.

On 03/30/2016 12:10 PM, Chris Dahms wrote:

Gist with all info you requested >
https://gist.github.com/zentrification/febb58d2ed43a5376c861a903d97b54e

i2cdetect and ddccontrol fail to find much

So ddctool, i2cdetect, and ddccontrol are all in the same boat. The
Nvidia driver creates the /dev/i2c devices, but no slave addresses are
detectable. (Recall that the EDID is at slave address 0x50, and DDC/CI
at slave address 0x37.)

nvidia-settings was able to dump bin & txt edid's >

As expected, nvidia-settings is getting the EDID from the driver
somehow. Looking through exported symbols, I see that
libnvidia-cfg.so.364.12 (and presumably other releases) exports symbols
nvCfgGetEDID and nvCfgGetEDIDData. These are not declared in any
nvidia header file. I don't see "i2c" (case-insensitive) in the
exported symbols of any Nvidia Linux library.

edid-parse fails on both, but provides some info for the bin >
Makes sense. The Asus monitors return a v1.4 EDID with a 256 byte data
block. parse-edid doesn't know how to handle it

Further thoughts:

1. Maybe the "silent" i2c bus is due to a bug in the i2c-over-aux
   facility of DisplayPort? Can you easily replace one of the DisplayPort
   connections with a DVI cable?

2. Try running:

xrandr --verbose

Are EDID blocks shown? If so, I'll drill down into the X11
implementation to see how X11 acquires the EDID. Perhaps that provides
a usable hook for DDC communication.

(I've added an equivalent check to the latest implementation of
"ddctool env -v" in the github repo and the tarball.)

3. Can you easily plug in one of the 27" Dell monitors? Any better results?

Sanford

— You are receiving this because you modified the open/close state. >
Reply to this email directly or view it on GitHub >
#1 (comment) >

from ddcutil.

Hi Chris,

Have you had a chance to perform any more tests? My sense is that the
problem is that Nvidia's driver does not properly support I2C on the GTX
970. I'd like to post to that effect on on Nvidia's site. But
without more detail I doubt there will be much response. Can we at
least rule out the monitor as the culprit by attaching one of your older
27" monitors to the new card? Of course, documenting that things work
with the older Quadro card would be great, but I appreciate that
swapping cards can open up a can of worms. Documenting success or
failure with i2cdetect is most important - it clearly shows that neither
the I2C address (x37) nor the EDID address (x50) are detected on the
bus. Of course, you're welcome to post on Nvidia's site as well.

Regards,
Sanford

On 03/30/2016 01:02 PM, Chris Dahms wrote:

I also just tried factory resetting one of my monitors to see if that
would make a difference, but sadly it did not

—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
#1 (comment)

from ddcutil.