Click here to Skip to main content
15,508,050 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
See more:
I have found that for linux it is possible to use vga, hdmi and other video connector's ddc's i2c ports to program and communicate with periphial devices. I have also found that apparently no one has been able to do it for windows, with the exception to nicomsoft. Nicomsoft has software that I have verified can read the i2c ports and not just access edid registry. I have an accelerometer connected and when I run the software it can detect a device at it's address. So I know it is possible but I have no idea if it is possible to use windows to do it. I know windows video port driver can call the miniport driver and get pointers to i2c callback structure containing explicit controls of the clock and data lines. The problem is it does not seem to export any of these pointers to anything else, like a user api let alone another kernal mode driver. I have considered that it might be possible at a hardware level were I have found out the intrcacies of the hardware, I have even seen an example of a video miniport driver on this site. I have an amd laptop which uses the bolton fusion controller hub which has vga ddc i2c ports. If you search amd docs for bolton fch you can find the documentation. basically I know the hub's i2c ports physical pins which my guess are both strung out to the hdmi and vga port's on my lap top. I have alos looked up the hub's general pupose i/o registers and it appears that they correspond to the pins. For instance ddc_i2c_scline is gpin70 and the data gpin71. the gpio registers are numbered correspondingly except the decimal pin number is changed to hexidecimal for the register. I can find the memory offset. My question is now, can I call gdi's function to map video memory to the process virtual memory, then write to these registers, turning them on and off? It is difficult to tell just what perspective on the memory I will have. Also if this worked, it would not be platform independent and would only work for pc's with bolton fusion controller hubs. Nicomsoft's program seems to be platform independent so either it wrote drivers for all common hardwares or it is using windows video port driver somehow? I have been working on this for several months and if someone could please help it would be awsome. thanks.

Thank you for your reply. I am aware of nicomsoft's solution. That is also interesting the methods they used. I was looking into writing a hw specific driver for the amd bolton fusion hub controller. I looked at it and it appears to have 2 pins in parallel with all video peripheral's i2c edid pins. ie. vga, hdmi. So I was able to find data sheets for that hub controller on amd's site and it appears enough informataion is available to proceed. I think in normal operation, the chips firmware controls individual data and clock pulses and rather a buffer is given as an argument and it transmits. In order to gain exclusive control of the i2c lines it appears the same physical pins can act as tristate general purpose i/o. My solid state physics is a little rusty but it appears this means it can hold the line low, do nothing on it's end or try and leave it high. kinda like 1,0, and a listen state. It appears those registers are mapped to the systems memory at an default which is available in the data sheet, or it is computed by the firmware/bios if different. It appears there is enough information to have the driver compute it's value as amd gives the portion of bios source code or better yet their is a dedicated x86 op code for accessing this information, though I'm not sure how a driver would actually use the opcode. Then memory mapped io is easy cause a kernal mode driver can map it's memory to a physical memory location and hence control the i2c lines.

A second alternative and probably better method i think would be writing a lower filter driver for the video port or upper filter for the miniport. They could hook video miniport's I2CWriteClock() and data fumtions and then export them to a user mode driver, a dll, or directly somehow as int call and set up communication between user mode appllication and the driver. This method would be better because it would not be hardware dependent and would take advantage of microsofts driver model.

The problem now seems not in writing the drivers but how to actually implement them and install and run them. In the first method it seems the driver needs to be a bus driver right over acpi.sys the root level driver. This is because of plugnpay. PnP is the one to start a driver nothing else so then an existing driver would need to detect a class of hardware which invokes the driver, and there is no normal way to do this with out having the driver's inf essentially lie and say it is for existing class of hardware, this would essentially be a hack and would use say a usb to start a completely different driver. Also this has the added draw back that usb devices would not be able to load their real drivers.

So a bus driver is either detected by acpi.sys which I have no knowledge of even how to do that as acpi seems to be a really low level thing, so low that all kernal mode drivers are a child of as far as I even know. So then it needs to be a load on boot device, this would start the driver allways sometime after acpi is loaded. This is really a fitting way cause really the hardware is always there but there is perhapse a possibility of conflicting with actual edid reading but I dont think it is too likely as long as it doesnt access the memory mapped io until after a certain period.

Then there is the filter driver route which as I said is probably the best route to go though implementing actual hardware is kinda cool. But being as I am new to drivers at any level I have no idea how a filter driver is loaded.

Finally there is installing the driver which was already complicated with inf files and device class and id's but it has only gotten more complicated with the advent of driver signing and driver store. The driver either needs to be signed which apparently costs money and is done by third party, or sighned as a test driver which i dont know how to do. I have successfully installed a driver to the driver store by booting in test mode. Also there is problem of debugging it and I currently need to get a second test computer to avoid ruining the one containing source code. Also apparently this isnt just microsoft folk legend, drivers do apparently tend to mess things up when in development.

So thats where I at.
P.S. Sorry for poor punctuation, recently had hand injury at work and very reduced typing ability.
Share this answer
I'm using the Nicomsoft system since some years.
Great software, allows handling the DDC i2c port directly, but slowly goes to obsolete.
They written an kernel mode driver and an HW specific dll which handles the commonly used graphics chips individually.
ATI, nVidia, Intel, Sis, Matrox...
Unfortunately Nicomsoft abandoned the development/update the dll for the new chips in 2012, so they are not supported.
For example the Intel HD4400 inside the processors.
There is no standard method to access the i2c ports from an user app in Windows.
The video miniport driver is provided by the manufacturers, but i did not found a way to access the i2c functions from a c++ app.
Let me know if you got any solutions.
Share this answer

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900