I need to get exclusive access of video adapters ddc i2c data and clock ports.

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.