Controlling Your Monitor with OSX: DDC Panel
- Thread starter SJ_UnderWater
- Start date
- Status
- Joined
- Dec 3, 2010
- Messages
- 460
- Motherboard
- Gigabyte GA-H55M-S2V
- CPU
- Intel i3-530
- Graphics
- HIS HD 6570
- Mac
- Mobile Phone
until someone with NVidia steps through the source and identifies the specific command which causes the freeze, I can't really do anything. Certainly syspolicyd isn't the issue, which just scans quarantined (newly-downloaded) files when they are opened.
- Joined
- Feb 1, 2012
- Messages
- 267
- Motherboard
- Gigabyte Z77X-UD5H
- CPU
- Intel Core i7 3770k
- Graphics
- Asus GTX 780 DC2
- Mac
- Classic Mac
- Mobile Phone
Just downloaded your latest update and it works great with my other two screens that are 1.3 but its doing the same with my 1.4 with the screen not setting the values i'm sending. To be honest I'm not sure if DDC/CL can be used on this screen since there is no option to turn it on or off in the menu as i have with my 2 dells that do work. Anybody else have a 1.4 screen to test with?
- Joined
- Dec 3, 2010
- Messages
- 460
- Motherboard
- Gigabyte GA-H55M-S2V
- CPU
- Intel i3-530
- Graphics
- HIS HD 6570
- Mac
- Mobile Phone
a couple of users have tested it on 1.4 and provided me with the results, but if you don't have a DDC/CI menu option, you probably don't have write-access as you presumed.
- Joined
- Feb 1, 2012
- Messages
- 267
- Motherboard
- Gigabyte Z77X-UD5H
- CPU
- Intel Core i7 3770k
- Graphics
- Asus GTX 780 DC2
- Mac
- Classic Mac
- Mobile Phone
That makes me sad, as the menu on this monitor is a pain to use but for the price i payed i can't complain that much.
- Joined
- Mar 24, 2011
- Messages
- 1,009
- Motherboard
- ASUS Z10PE-D8 WS
- CPU
- 2x E5-2683 v3
- Graphics
- W9100
Works great on my 1.4 display over DP but I don't have no option to disable DDC, never even knew you could.
- Joined
- Dec 3, 2010
- Messages
- 460
- Motherboard
- Gigabyte GA-H55M-S2V
- CPU
- Intel i3-530
- Graphics
- HIS HD 6570
- Mac
- Mobile Phone
Updated to v1.4
- App now responds to volume hotkeys
- Joined
- Dec 3, 2010
- Messages
- 460
- Motherboard
- Gigabyte GA-H55M-S2V
- CPU
- Intel i3-530
- Graphics
- HIS HD 6570
- Mac
- Mobile Phone
my point was there's more going on, on other threads, that's how KVO works; when the notification transaction is complete ("did" change) another thread is spawned on -observe which then reads the EDID and generates the DDC objects which are what cause the KP.
at any rate, it doesn't matter anymore, PJALM very graciously set up an NVidia MacPro for me to test remotely, and we managed to get it working on NVidia. There are definitely some more features to add, namely enumerating the I2C interfaces in IOReg to get their data before making requests, but that shouldn't matter much right now. Interestingly, NVidia cards support a second, private communications flag which I can't find anywhere in the documentation. At the very least it helps identify NVidia cards within the app.
The biggest issue is NVidia seems to interpret minReplyDelay differently; where a value of 30 * kMillisecondScale is appropriate for ATI/AMD and doesn't require running the same request several times, 30 is a more appropriate value for NVidia, and 0 still returns a garbage response. If true, this means that DDC Panel never actually KPed an NVidia machine, the kernel was simply waiting 1000 * 1000 times longer for the DDC/CI reply.
Timing is very important for I2C buses as I've been reading, so a "good" value here is critical. If the reply is taken too early, the data will be garbage and fail to checksum, too long and it may mimic a Kernel Panic. Running several successful requests in series is the only real test. Feel free to try different values and report back.
I've also started polishing the app, removing unnecessary entries, and following code guidelines.
--edit
For reference, I tried a very large delay on my AMD 6570 and the result was very much like a KP, except for the time() output i placed around the request call. 30 * kSecondScale does produce a 30sec delay per-request (calculated using time()), and during the delay there was no activity except my CPU fan spun up. In fact, there appears to be a gap in my system log.
at any rate, it doesn't matter anymore, PJALM very graciously set up an NVidia MacPro for me to test remotely, and we managed to get it working on NVidia. There are definitely some more features to add, namely enumerating the I2C interfaces in IOReg to get their data before making requests, but that shouldn't matter much right now. Interestingly, NVidia cards support a second, private communications flag which I can't find anywhere in the documentation. At the very least it helps identify NVidia cards within the app.
The biggest issue is NVidia seems to interpret minReplyDelay differently; where a value of 30 * kMillisecondScale is appropriate for ATI/AMD and doesn't require running the same request several times, 30 is a more appropriate value for NVidia, and 0 still returns a garbage response. If true, this means that DDC Panel never actually KPed an NVidia machine, the kernel was simply waiting 1000 * 1000 times longer for the DDC/CI reply.
Timing is very important for I2C buses as I've been reading, so a "good" value here is critical. If the reply is taken too early, the data will be garbage and fail to checksum, too long and it may mimic a Kernel Panic. Running several successful requests in series is the only real test. Feel free to try different values and report back.
I've also started polishing the app, removing unnecessary entries, and following code guidelines.
--edit
For reference, I tried a very large delay on my AMD 6570 and the result was very much like a KP, except for the time() output i placed around the request call. 30 * kSecondScale does produce a 30sec delay per-request (calculated using time()), and during the delay there was no activity except my CPU fan spun up. In fact, there appears to be a gap in my system log.
- Joined
- Dec 3, 2010
- Messages
- 460
- Motherboard
- Gigabyte GA-H55M-S2V
- CPU
- Intel i3-530
- Graphics
- HIS HD 6570
- Mac
- Mobile Phone
Updated to v1.5
- General cleanup
- Removal of unnecessary notifications
- Unboxing of some primitives
- Better integer choices
- Move to subAddressing
- Experimental NVidia support
- Reading I2C to determine delay mode
- Joined
- Jul 25, 2012
- Messages
- 16
- Motherboard
- x
- CPU
- x
- Graphics
- x
- Mac
- Classic Mac
- Mobile Phone
Great work on the experimental NVidia update! I've gotten v1.5 it to work with my 15" Retina Macbook Pro + Dell U2312HM
Here are a few quirks I've noticed.
- App doesn't detect external monitor unless external monitor is set as primary display [with dock]
- Brightness slider is a little bit buggy and doesn't always work.
- Contrast doesn't update with current value when changed.
Other than that, it's pretty awesome. I can't wait to see your finished product. Would be really cool to have a menu bar item that has preset settings and quick adjustment sliders.
Here are a few quirks I've noticed.
- App doesn't detect external monitor unless external monitor is set as primary display [with dock]
- Brightness slider is a little bit buggy and doesn't always work.
- Contrast doesn't update with current value when changed.
Other than that, it's pretty awesome. I can't wait to see your finished product. Would be really cool to have a menu bar item that has preset settings and quick adjustment sliders.
- Status