Display driver I2C communication help required.

NTDEV
1

Dear All,

I am in process of developing a display driver (PCI based) for Windows XP for a monitor calibration application and require your expert suggestion/comments for the same.

One simple way is to use undocumented API that supports DDC/CI without developing any driver. But this solution is very limited because the graphics display driver must support this undocumented API, but this is rarely done today.

So I plan to develop a display driver (PCI based) that communicates with video chips directly, and enable the I2C communication on graphic controllers. So my query is:

  1. Since almost every display driver vendor will have a different offset for SDA and SCL (I2C communication channel). So is there any way to find those offsets ??

  2. And incase, there is no general way, then we need to specify offsets for I2C for each display card ??

  3. Is there any way to hack/get these offsets through reverse engineering ??

Please comment.
Thanks and Regards,
RDH

2

Is I2C a required part of some video hardware interface?
I know what I2C is, and I’ve programmed a number of devices using I2C.

If I2C is a part of a video hardware interface, then look at the specs for
that defined interface, which will include addressing information, and use
that information to do what you need to do.

If I2C is not spec’d as a part of a standard video configuration interface,
I2C is not the solution to your problem, and I don’t think you realize what
you are up against. First, I2C is not on every chip, and even if it is on a
chip, it may not be the only option (e.g. SPI or a proprietary chip-to-chip
protocol may be used.) Second, I2C is a master/slave protocol, and while
there are I2C environments that are multi-master, the existing firmware has
to support that feature, and those are few and far between, and if the chip
you want to talk to is only a master, you will not be able to talk to that
chip over I2C.

About addressing:
Most IC’s that support I2C also have a few address lines that allow the user
of the chip to assign an address within a small range. Using Philips/NXP’s
SE95 as an example [E.g. Google for “se95” (It’s a temperature sensor) and
look at the datasheet for that part.]: It has a 7-bit address of 1001xxx,
where the xxx is defined by the address lines A2, A1, and A0. If an address
line is tied to ground, that address bit is 0, and if an address line is
tied to Vcc, that address bit is 1. To know what address to use with this
chip, you would look at the schematic to see how A2, A1, and A0 are
configured. You could also probe the chip to see how the address lines are
tied.

There are also I2C multiplexers that are used to either isolate a device or
to allow for multiple devices with the same address on the bus, and you have
to know if those are present, and how they are configured.

-Preston

On 2/20/07 5:44 AM, “xxxxx@gmail.com”
wrote:

> Dear All,
>
> I am in process of developing a display driver (PCI based) for Windows XP for
> a monitor calibration application and require your expert suggestion/comments
> for the same.
>
> One simple way is to use undocumented API that supports DDC/CI without
> developing any driver. But this solution is very limited because the graphics
> display driver must support this undocumented API, but this is rarely done
> today.
>
> So I plan to develop a display driver (PCI based) that communicates with
> video chips directly, and enable the I2C communication on graphic controllers.
> So my query is:
>
> 1) Since almost every display driver vendor will have a different offset for
> SDA and SCL (I2C communication channel). So is there any way to find those
> offsets ??
>
> 2) And incase, there is no general way, then we need to specify offsets for
> I2C for each display card ??
>
> 3) Is there any way to hack/get these offsets through reverse engineering ??
>
> Please comment.
> Thanks and Regards,
> RDH
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

3

Hi Preston,

Thanks a lot for your comments/suggestions. Below are my comments:
Is I2C a required part of some video hardware interface?

> I suppose ,YES.
At least there must be some mechanism in video display card so that it can enables the I2C communication.

Without this , how will display adaptor communicate with the monitor ??

We can

  1. get the instance of PCI device
  2. map the memory
  3. And if we now know the address of SDA/SCL in the mapped region, we can directly write/read. And this enables the i2c communication.

I have implemented the same and it works fine. But the issue in this approach is that we need to know the EXACT address and offset of SDA/SCL in the mapped region. And graphics card vendor donot share these specifications. So my query: “Is there any way to know these offsets” ??

And for different vendor’s these address and offset will be different. So how can we find these offsets.?

e.g is it possible to attach an upper filter driver on display driver and check what offsets are being passed to the graphics driver. And then use these addresses/offsets ?

Thanks and Regards,
rohit

4

Hi,
Yes using reverse engineering you can find the offsets of sda and scl lines.

You can put a “for loop” that will scan all the suspected offsets. At
each offset you n try to write a byte. Simultaneously you can connect a
oscilloscope . As each value is being written on to the offset , notice
the variations on the scope. If you find any successful variation on the
scope on the sda or sca line , then that offset is of interest to you.

This is simple but a successful way of finding offsets of different
graphics cards.

Note that offsets of particular vendor follow a specific pattern. So
easily you can predict the suspected offsets.

Thanks.

Preston Wilson wrote:

Is I2C a required part of some video hardware interface?
I know what I2C is, and I’ve programmed a number of devices using I2C.

If I2C is a part of a video hardware interface, then look at the specs for
that defined interface, which will include addressing information, and use
that information to do what you need to do.

If I2C is not spec’d as a part of a standard video configuration interface,
I2C is not the solution to your problem, and I don’t think you realize what
you are up against. First, I2C is not on every chip, and even if it is on a
chip, it may not be the only option (e.g. SPI or a proprietary chip-to-chip
protocol may be used.) Second, I2C is a master/slave protocol, and while
there are I2C environments that are multi-master, the existing firmware has
to support that feature, and those are few and far between, and if the chip
you want to talk to is only a master, you will not be able to talk to that
chip over I2C.

About addressing:
Most IC’s that support I2C also have a few address lines that allow the user
of the chip to assign an address within a small range. Using Philips/NXP’s
SE95 as an example [E.g. Google for “se95” (It’s a temperature sensor) and
look at the datasheet for that part.]: It has a 7-bit address of 1001xxx,
where the xxx is defined by the address lines A2, A1, and A0. If an address
line is tied to ground, that address bit is 0, and if an address line is
tied to Vcc, that address bit is 1. To know what address to use with this
chip, you would look at the schematic to see how A2, A1, and A0 are
configured. You could also probe the chip to see how the address lines are
tied.

There are also I2C multiplexers that are used to either isolate a device or
to allow for multiple devices with the same address on the bus, and you have
to know if those are present, and how they are configured.

-Preston

On 2/20/07 5:44 AM, “xxxxx@gmail.com”
> wrote:
>
>
>> Dear All,
>>
>> I am in process of developing a display driver (PCI based) for Windows XP for
>> a monitor calibration application and require your expert suggestion/comments
>> for the same.
>>
>> One simple way is to use undocumented API that supports DDC/CI without
>> developing any driver. But this solution is very limited because the graphics
>> display driver must support this undocumented API, but this is rarely done
>> today.
>>
>> So I plan to develop a display driver (PCI based) that communicates with
>> video chips directly, and enable the I2C communication on graphic controllers.
>> So my query is:
>>
>> 1) Since almost every display driver vendor will have a different offset for
>> SDA and SCL (I2C communication channel). So is there any way to find those
>> offsets ??
>>
>> 2) And incase, there is no general way, then we need to specify offsets for
>> I2C for each display card ??
>>
>> 3) Is there any way to hack/get these offsets through reverse engineering ??
>>
>> Please comment.
>> Thanks and Regards,
>> RDH
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>

–
Anshul Makkar
Sr. Associate Engineer
Globallogic
The leader in Outsourced Product Development
B-34/1, Sector 59
Noida, UP 201301
Phone : +91-120-4342258
Fax: 91-120-2585721
www.globallogic.com
Disclaimer :http://www.globallogic.com/email_disclaimer.txt

5

On Tue, Feb 20, 2007 at 10:08:46PM -0500, xxxxx@gmail.com wrote:

Thanks a lot for your comments/suggestions. Below are my comments:
Is I2C a required part of some video hardware interface?
>> I suppose ,YES.
At least there must be some mechanism in video display card so that it can
enables the I2C communication.

Without this , how will display adaptor communicate with the monitor ??

I2C is not the only possible way to handle DDC.

We can

  1. get the instance of PCI device
  2. map the memory
  3. And if we now know the address of SDA/SCL in the mapped region, we can
    directly write/read. And this enables the i2c communication.

I have implemented the same and it works fine. But the issue in
this approach is that we need to know the EXACT address and offset of
SDA/SCL in the mapped region. And graphics card vendor donot share these
specifications. So my query: “Is there any way to know these offsets” ??

You are assuming that every graphics card puts this into memory space, and
that every graphics card handles SDA/SCL the same way. It’s quite possible
for the interface to be via I/O ports, and some graphics chips might have
a built-in UART whereas others require bit-pounding. There is just no
way for you to know this.

The ONLY reliable way to do this is to talk to the miniport.

e.g is it possible to attach an upper filter driver on display driver
and check what offsets are being passed to the graphics driver. And then
use these addresses/offsets ?

Here, you are assuming that the communication is being handled in the
display driver. It’s quite possible that the miniport does it directly,
in which case you wouldn’t be able to intercept it anyway.

Tim Roberts, xxxxx@probo.com
Providenza & Boeklheide, Inc.

6

Hi,

Please see my comments for Tim and Anshul below:

>You can put a “for loop” that will scan all the suspected offsets.

Yes, this is a possible way to suspect the offset. But once u find the offsets u need to also find the masking values. Which is again a hit-n-trial method.

>It’s quite possible for the interface to be via I/O ports, and some graphics chips might have
>a built-in UART whereas others require bit-pounding.
Yes, you are correct but at same time, but till date i worked on ATI, NVIDIA, Intel display card for DDC and found I2C communication enabled.

But I am facing the issue in following:
To be somewhat more specific: I have a NVIDIA GeForce 7300 GT card having dual DVI slot. I am successful in communicating with one DVI slot (port), but the same application failed to communicate with the other slot. I am doing the same by mapping the graphics card memory and then writing on particular SDA SCL Lines. ( i found the offets through RE).

So is it possible that one slot is using memory map and other slot using I/O Map ??

Thanks and Regards,
RDH

7

> But I am facing the issue in following:

To be somewhat more specific: I have a NVIDIA GeForce 7300 GT card having
dual DVI slot. I am successful in communicating with one DVI slot (port), but
the
same application failed to communicate with the other slot. I am doing the
same
by mapping the graphics card memory and then writing on particular SDA SCL
Lines. ( i found the offets through RE).

The I2C-related hardware interface between the card and the monitor is
standartized.

Nevertheless, the I2C-related interface between the card and the software
(its miniport driver) is not. It can be any. It can be IO port or BAR based,
thus having no “offsets” at all.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

8

Thanks Maxim,

>Nevertheless, the I2C-related interface between the card and the software (its miniport driver) is >>not. It can be any. It can be IO port or BAR based, thus having no “offsets” at all.

So is it possible to develop/write a generic driver for a DDC/CI (monitor calibration application )which can work for n number of different graphics card vendors ?

B/w can you/anybody please tell me how things work when we change display settings in Windows XP ( DisplayProperties->Settings). I suppose the calls route from this

application==>device_driver_of_graphics_driver==>display_device<<=>>I2C communication<==>Monitor.

Please comment.
Thanks and Regards,
RDH

9

> B/w can you/anybody please tell me how things work when we change display

settings in Windows XP ( DisplayProperties->Settings). I suppose the calls
route from this

application==>device_driver_of_graphics_driver==>display_device<<=>>I2C
communication<==>Monitor.

I2C is optional, and so mode change does not rely on I2C. The card just starts
to generate the Vsync and Hsync clocks to the monitor at another rate.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

10

Thanks all for your support!! I have been able

Is there any way to check/know the graphic card capabilties: which way it is enabling DDC/CI ?

Regards,
RDH