HAL_MonitorLeadID change

I note that this is only supported by the IOMD HAL, and looks like it was just a quick decapitation action in the early HAL/kernel split. I guess since no other HALs support it probably says the split is a bit specific to IOMD.

I note there’s a bounty to support EDID, too.

So I was thinking about changing HAL_MonitorLeadID to do nothing on IOMD too, and instead implement (a minimal) HAL_Video_IICOp instead to return one of two fake EDID tables. The kernel can then inspect byte 0×14 bit 2 to decide if composite or separate syncs are desired.

This should then mean the other video drivers, which do implement HAL_Video_IICOp (or its GraphicsV equivalent), would gain sync detection and not slam the door shut on whoever claims the EDID bounty.

Sound reasonable? The only niggle is needing an official EDID manufacturer id assigning, though that’s probably not important right now.

That sounds a bit dodgy to me. Is it possible for a valid EDID response to only list the sync type and none of the other monitor parameters?

Is it possible for a valid EDID response to only list the sync type and none of the other monitor parameters?

My reading of table 2.2 of VESA EDID release A revision 2 is that the only mandatory fields are the EDID revision/version up until EDID 1.3 when there are 3×18 byte descriptors needed too.

Date wise EDID 1.3 didn’t come in until 1999 so IOMD class predates this (though of course it’s faking something on behalf of the monitor which might have been made post 1999).

Integrating EDID “nicely” looks quite a lot of work (configure plugins, SWIs, display manager, drivers) but it looks safe-ish for the kernel o inspect that one byte in the meantime.

My reading of table 2.2 of VESA EDID release A revision 2 is that the only mandatory fields are the EDID revision/version up until EDID 1.3 when there are 3×18 byte descriptors needed too.

The only useful doc I can track down is release A of the E-EDID standard (i.e. EDID 1.3). But based on my reading of that, it looks like you’re right – byte 0×14 is the first “useful” byte, and (without checking the VIDC docs!) it looks like bit 2 is the only bit which a VIDC20/IOMD machine would be able to act upon.

I was reading this though it is on a Taiwanese website in a directory called private, so might be an accidental publish.

Who/what uses GraphicsV IICOp? It’s a pretty icky API, but could be made less icky by allowing bits 16-23 to be the IIC base address, and moving bits 24-31 into R4 to match the proposed GraphicsV enhancements. How much would that break? Rejigging the NVidia & OMAP drivers doesn’t look too hard, are there any apps out there using it? I’m guessing not.

I was reading this though it is on a Taiwanese website in a directory called private, so might be an accidental publish.

Thanks – that’s one more document to add to the archive!

GraphicsV IICOp […] It’s a pretty icky API

Agreed.

but could be made less icky by allowing bits 16-23 to be the IIC base address, and moving bits 24-31 into R4 to match the proposed GraphicsV enhancements

That sounds good to me.

How much would that break? Rejigging the NVidia & OMAP drivers doesn’t look too hard, are there any apps out there using it? I’m guessing not.

AFAIK the only app that’s ever used the API is the “Decode EDID” tool that was used to generate some of the MDF’s in the Iyonix disc image. Since that tool seems to be lost to the sands of time I don’t think you’ve got too much to worry about by changing it.

OK – so I’ve had a go at de-ickyfying GraphicsV IICOp.

I’m not able to test the OMAP4 implementation, but since it was just a copy of the OMAP3 one I’m assuming it’ll be fine (since OMAP3 worked).

I’m not able to test the NVidia one, I ran out of fingers trying to keep track of the function calls so decided to just rewrite the top level IICRead one – so it’s possible that doesn’t work. If someone has a EDID capable monitor and an Iyonix (better still, with 2 heads) it might need some TLC.

The one other thing in this area I think is worth adding is to make the video drivers call OS_ScreenMode 255 (is that the right subreason?) with the barest minimal set of parameters. Then, in the kernel, use that to trigger the EDID read and update its monitor type and do MODE MODE. I figure this is better than my other two ideas (comparing the GraphicsV registrant for being non default after each and every module init, or listening for the module post init service call) since unfortunately at the point those two things are currently done the module chain hasn’t started.

I’m not able to test the NVidia one, I ran out of fingers trying to keep track of the function calls so decided to just rewrite the top level IICRead one – so it’s possible that doesn’t work. If someone has a EDID capable monitor and an Iyonix (better still, with 2 heads) it might need some TLC.

I’ll build a ROM and see what happens.

The one other thing in this area I think is worth adding is to make the video drivers call OS_ScreenMode 255 (is that the right subreason?)

I’m starting to have second thoughts about using OS_ScreenMode 255. Upon registration there’s no way for a driver to indicate whether it’s based around ROL’s VideoV or Castle’s GraphicsV, so it has no way of rejecting unsupported drivers. Plus the way that it returns a pointer to a VSync routine doesn’t fit into the way that GraphicsV currently does things. Maybe a new reason code should be used?

After a couple of minor fixes, the new GraphicsV IICOp now seems to be working properly in the NVidia module.

Plus after looking at the code I think I’ve just spotted why it’s so hideously slow – it’s clocking the bus at 1kHz instead of 100kHz! I guess I’ll fix that tomorrow, then.

Plus after looking at the code I think I’ve just spotted why it’s so hideously slow – it’s clocking the bus at 1kHz instead of 100kHz! I guess I’ll fix that tomorrow, then.

Beware – the IIC SDA line is open drain with a relatively high value of pull-up resistor. You may not be able to run it that fast. (I don’t know, I have no specific experience of reading monitor IDs.)

After a couple of minor fixes, the new GraphicsV IICOp now seems to be working properly in the NVidia module.

I’m mildly chuffed only minor changes were needed, I hope it didn’t have you scratching your head for too long.

I’m starting to have second thoughts about using OS_ScreenMode 255. Upon registration there’s no way for a driver to indicate whether it’s based around ROL’s VideoV or Castle’s GraphicsV

Oh, VideoV is radically different to GraphicsV? That’s a pity. If ROL are fading into insignificance maybe there’s no particular need to recycle OS_ScreenMode 255 then, there are plenty more reason codes to pick.
My short term desire is just for something to do “notify kernel I’m a graphics driver and I just claimed GraphicsV”, so if you can cook up a suitable SWI definition that doesn’t close any doors on the future proposed GraphicsV enhancements then I don’t mind implementing at least a skeleton version (eg. hardwired to max 1 driver/1 display/1 head).

Beware – the IIC SDA line is open drain with a relatively high value of pull-up resistor. You may not be able to run it that fast. (I don’t know, I have no specific experience of reading monitor IDs.)

100kHz seemed to work OK on the BeagleBoard when I first tested it there. I guess I should check the EDID/DDC specs and see what the minimum supported speed should be (definitely not 1kHz, I hope!)

I’m mildly chuffed only minor changes were needed, I hope it didn’t have you scratching your head for too long.

The main problem was trying to trace through the original code to work out what it was doing!

Oh, VideoV is radically different to GraphicsV?

Probably – there’s no documentation for VideoV, IIRC :( At the least, it uses a different vector number, so any driver written specifically for one won’t work with an OS which uses the other.

My short term desire is just for something to do “notify kernel I’m a graphics driver and I just claimed GraphicsV”, so if you can cook up a suitable SWI definition that doesn’t close any doors on the future proposed GraphicsV enhancements then I don’t mind implementing at least a skeleton version (eg. hardwired to max 1 driver/1 display/1 head).

I think a two-stage registration process will be best. First call allows the OS to return a driver number to the driver. Second call will be once the driver is ready and waiting on GraphicsV, allowing the kernel to do whatever it needs to do to activate the driver (query EDID to get monitor sync type, do MODE MODE, etc.)

Since ROL are using OS_ScreenMode 255 and down for their display driver reason codes, I guess it would make sense for us to use 256 and up:

OS_ScreenMode 256 – Register GraphicsV driver

In: R0 = reason code, R1 = flags (reserved)
Out: R0 = driver number

Call this from the module initialisation function to request a driver number from the OS (This way the module won’t yet be linked onto GraphicsV, so the GraphicsV handler doesn’t have to worry about ignoring calls that are received before the module knows its driver ID).

OS_ScreenMode 257 – Start GraphicsV driver

In: R0 = reason code, R1 = driver number

Call this in a callback after the module is initialised (to ensure driver is active on GraphicsV)

Since this is just a skeleton implementation of the API, you can probably just hardcode OS_ScreenMode 256 to return a driver number of 0, and not worry about implementing any other features that would be needed in the full system (deregistering drivers, handling multiple drivers, etc.)

see what the minimum supported speed should be (definitely not 1kHz, I hope!)

You mean maximum? :-)

I’m not sure there is a hard defined minimum speed for IIC (unless the spec has changed). Way back, when I was developing my teletext interface for DOS, bit banging the parallel port, I was single-stepping the IIC code in TurboC’s debugger, talking to the SAA5243 (EuroCCT chip), managing rather less than one bit per second, and it worked.

Using a later version of the code on a 1GHz PC failed until I added some artificial delays; thus was because it would have run too quickly for the old teletext chip.

Thus, it would seem to me, the limiting factor is how fast you can run it, not how slowly. The original spec is for 100kHz operation. That’s from ‘82 so I’d hope EDID/DDC could manage at least that.

You mean maximum?

Well, yes. The minimum maximum speed which monitors are supposed to support :)

OS_ScreenMode 256 – Register GraphicsV driver
OS_ScreenMode 257 – Start GraphicsV driver
Call this in a callback after the module is initialised (to ensure driver is active on GraphicsV)

Well that seems simple enough! Though why is a callback needed for 257 if the module doesn’t listen for service calls nor implement SWIs, isn’t just OS_Claim of GraphicsV enough? Or maybe you meant the general case where service calls/SWIs are implemented.

Sorry – my mistake. I was getting confused and thinking GraphicsV was a service call.

“Probably – there’s no documentation for VideoV, IIRC :( "

Hmmm. “No documentatation anyone will part with” probably sits closer to the truth.
Then again much of this hits maturity issues for the people concerned so its best left alone.

Just to say I have read the EDID info from a couple of monitors using the standard IICOp calls, so it seems work to standard bus speed.
Also both monitors used the standard EEPROM IIC address (and not &50 as the spec calls for).

not &50 as the spec calls for

I think that’s just that they’ve specified the 7 bit IIC address, rather than the 8 bits that go on the wire (7 addressing bits + the RnW direction bit), 0xA0/0xA1 is write/read from 0×50.

Good news – Willi and Steve managed to track down Will Ling, who wrote the “Decode EDID” tool. The source is now in CVS, although since it was an internal tool created by reverse-engineering an Excel spreadsheet it looks like it could do with a bit of TLC if it’s going to be used as the basis of a full EDID solution. It also looks like it only supports GTF timings, whereas other mode generators support more types (e.g. the Universal Modeline Calculator supports GTF, CVT, and reduced blanking timings). It’s also worth pointing out that the code doesn’t use GraphicsV to read the EDID data – the original code was supplied with a BASIC program that would dump the data to a file (It looks like it predates the addition of IIC support to the NVidia module).

I’ve now discovered the hard way that not all monitor manufacturers write-protect the EEPROM containing the EDID data. So to protect against people accidentally corrupting their EEPROMs, may I suggest that GraphicsV 14/HAL_VideoIICOp disallows writing to the EDID address? (Once I’ve managed to restore the data in both my monitors, that is…)

Also, it doesn’t help that the current implementations don’t implement writes properly anyway! For the OMAP HAL_VideoIICOp the second transfer block should have bit 1 of the first word set, to prevent a start bit/address byte being sent. And the NVidia implementation is hardcoded to always read data from the bus; I haven’t checked whether the RnW bit, and the insertion of a start bit/address byte, is hardcoded to match this or not.

(Once I’ve managed to restore the data in both my monitors, that is…)

LOL! Sorry… ;)