Not to ruin anyone's dreams, but... to make this program work on IRIX, it would probably have to be rewritten.
Let's take a look at how this actually works.
Inside the display, there's a tiny serial EEPROM, which is directly connected to the I2C pins on the VGA/DVI connector (you can read the EDID data even when the monitor is off).
To read that EEPROM while the monitor is connected to a computer you need:
Problem #1: apart from the newer VPro (and maybe O2) hardware, I doubt any other SGI graphics cards connect the I2C pins to anything, so they're simply inaccessible.
Problem #2: accessing the I2C bus within IRIX.
Let's ignore the first problem (surely everyone has a VPro system somewhere
), but the second one is a bit more difficult.
Xsgi probably has some way of accessing that I2C bus (gfxinfo sometimes reports the correct monitor name and that info is stored inside the EEPROM inside the monitor), but there's probably an undocumented API for doing that.
Disassembling gfxinfo would probably be a good start -- we could then see if it just reads the data Xsgi prepares for it or if it actually accesses the I2C bus on its own.
If it does the latter, then it would be very simple to use that code to dump the entire EEPROM into a file and get the timings and everything from that later.
If everything is done within Xsgi, then this project is probably dead
It would be possible to write a dummy driver for the I2C bus on the VPro using the work some open source people did on reverse engineering it, then kill Xsgi, load that driver, run a program to read the entire EEPROM, then unload the driver and restart Xsgi. But does anyone actually have time to implement this?
Regardless, if we could access the timing data from within IRIX, it would be possible to make a program which automatically generates video formats based on the data from the monitor. That would be very cool
Let's take a look at how this actually works.
Inside the display, there's a tiny serial EEPROM, which is directly connected to the I2C pins on the VGA/DVI connector (you can read the EDID data even when the monitor is off).
To read that EEPROM while the monitor is connected to a computer you need:
- a graphics card, which has the I2C pins on the VGA/DVI port connected to its I2C bus
- a driver for accessing the I2C bus on the graphics card
Problem #1: apart from the newer VPro (and maybe O2) hardware, I doubt any other SGI graphics cards connect the I2C pins to anything, so they're simply inaccessible.
Problem #2: accessing the I2C bus within IRIX.
Let's ignore the first problem (surely everyone has a VPro system somewhere
), but the second one is a bit more difficult.
Xsgi probably has some way of accessing that I2C bus (gfxinfo sometimes reports the correct monitor name and that info is stored inside the EEPROM inside the monitor), but there's probably an undocumented API for doing that.
Disassembling gfxinfo would probably be a good start -- we could then see if it just reads the data Xsgi prepares for it or if it actually accesses the I2C bus on its own.
If it does the latter, then it would be very simple to use that code to dump the entire EEPROM into a file and get the timings and everything from that later.
If everything is done within Xsgi, then this project is probably dead
It would be possible to write a dummy driver for the I2C bus on the VPro using the work some open source people did on reverse engineering it, then kill Xsgi, load that driver, run a program to read the entire EEPROM, then unload the driver and restart Xsgi. But does anyone actually have time to implement this?
Regardless, if we could access the timing data from within IRIX, it would be possible to make a program which automatically generates video formats based on the data from the monitor. That would be very cool
