Observe MEMORY CHANGES on graphics card action..

NTDEV
1

Hi,
I am developing a monitor calibration application for Windows 2k,XP,
that shall perform following tasks:

a) Find the offsets SDA / SCL of the graphics card.
b) control these i2c lines
c) Use these i2c lines to fetch EDID and VCP capabilities from the monitor

The major objective is to develop a application that communicate (Set EDID

and other info) with monitor through graphics card capabilities.

I am able to communicate with monitor with help of get-edid source (

http://john.fremlin.de/programs/linux/read-edid/ )
Below is what is achieved:

get-edid uses VESA VBE 2 interrupt service routine requests to read EDID

structure from the graphics card. Internally, the interrupt 0x10 is sent from

the BIOS to the graphics card (along with some parameters). The graphics card

in turn communicates with the monitor hardware for the requested item (eg.edid

info) through DDC channel, i2c communication.

I took out the pin 12 and pin 15 of monitor and connected it with the graphics

card and oscilloscope. I see the changes in SDA/SCL lines in oscillscope on
do_vbe_ddc_service( SERVICE_READ_EDID, &regs ) call.

So, Can we also find the SDA / SCL offsets of the graphics card using the
above technique? For instance, is it possible to

a) Initially map the graphics card memory , say BEFORE_ACTION using a kernel

mode driver that maps the memory.
b) Pass 0x10 interrupt, or run get-edid
c) Now again map the memory, say AFTER_ACTION

Finally analysing the change of AFTER_ACTION and BEFORE_ACTION.This
might give the change in address, and these will possibly be the SDA
and SCL offset.

Is it the right approach?

The main objective is to observe the offsets that are changing.

Any pointers, suggestions will be of great help.

Please suggest.

Thanks,
RB.

2

Rodney Brooks wrote:

I am developing a monitor calibration application for Windows 2k,XP,

I still have a colorimeter here from my time at SuperMac. It looked
like a mouse, and attached to the monitor with a suction cup. We did
some very nice automatic calibration work there.

that shall perform following tasks:

a) Find the offsets SDA / SCL of the graphics card.
b) control these i2c lines
c) Use these i2c lines to fetch EDID and VCP capabilities from the monitor

Your task (a) is hopeless. However, the display miniport driver exports
services to send and receive I2C sequences. You could write yourself an
upper filter to sit on top of the miniport, and have it make those calls.

So, Can we also find the SDA / SCL offsets of the graphics card using the
above technique? For instance, is it possible to

a) Initially map the graphics card memory , say BEFORE_ACTION using a kernel
mode driver that maps the memory.
b) Pass 0x10 interrupt, or run get-edid
c) Now again map the memory, say AFTER_ACTION

Finally analysing the change of AFTER_ACTION and BEFORE_ACTION.This
might give the change in address, and these will possibly be the SDA
and SCL offset.

Is it the right approach?

No, it is a hopeless approach. Some chips map SDA and SCL directly as
two bits in a single register. Some chips use a UART, so that you write
I2C stuff as whole bytes. Some chips do not allow those registers to be
read, so you couldn’t detect them anyway.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

hi Tim Roberts,
Thanks for your reply, Please allow me to detail my main objective:

I am developing/plan to develop the applications like winI2c-ddc (http://www.nicomsoft.com/wini2cddc/) and softMCCS. (http://www.entechtaiwan.com/lib/softmccs.shtm). I am taking into account that the minimum requirement is that the DDC/CI capability must be supported.

Generally, new graphics card keep coming up each day, and there are almost changes in the SDA/SCL offset corresponding to each new model. Also these offsets are not mentioned anywhere.

So my main objective is develop an application (or a plan of actions) that finds out these offsets. For this I have mentioned the idea.

Can there be some way to design such kind of app? Plz suggest.

>the display miniport driver exports services to send and receive I2C sequences
Are you talking about the series of communication b/w monitor and CPU (graphic card) after boot time and before login through i2c??

Regards,
RB.

4

xxxxx@gmail.com wrote:

I am developing/plan to develop the applications like winI2c-ddc (http://www.nicomsoft.com/wini2cddc/) and softMCCS. (http://www.entechtaiwan.com/lib/softmccs.shtm). I am taking into account that the minimum requirement is that the DDC/CI capability must be supported.

Yes, I understood this. Did you notice that both of those products
enumerate the short list of graphics vendors that they support? It’s
possible that both of these companies simply reverse-engineered the
miniports from these manufacturers to figure out how to communicate.
Or, perhaps they are calling into the video BIOS.

Have you considered licensing one of those two solutions?

Generally, new graphics card keep coming up each day, and there are almost changes in the SDA/SCL offset corresponding to each new model. Also these offsets are not mentioned anywhere.

So my main objective is develop an application (or a plan of actions) that finds out these offsets. For this I have mentioned the idea.

Can there be some way to design such kind of app?

No. You can try disassembling the miniport, but you’ll never catch this
by dumping the registers, partly because you can’t possible know how
many registers there are.

>> the display miniport driver exports services to send and receive I2C sequences
>>
Are you talking about the series of communication b/w monitor and CPU (graphic card) after boot time and before login through i2c??

No. I’m saying there is a well defined set of APIs that the miniport
driver exposes, which allows the video port driver to do I2C transactions:
http://msdn2.microsoft.com/en-us/library/ms800235.aspx
http://msdn2.microsoft.com/en-us/library/aa479127.aspx
However, there’s no immediate way to access these from outside of the
port/miniport.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.