Jump to content

ATI Framebuffer development

Slice

By Slice,
in ATI Framebuffer

 Share
466 posts in this topic

Recommended Posts

drlarsen77
drlarsen77
Posted
Posted
Did you compile RadeonPCI and RadeonDump to RowerPC codes?

They use OSWriteLittleEndian but you need BigEndian.

 

Ahh, that's a good point. I did recompile but I didn't modify the code for endianess. I had a look through the code and I changed Little Endian to Big Endian where I could find it, but it still doesn't work.

 

I think I probably missed something. I'm still really new to OS X programming and I've never had to deal with endianess before. Maybe if it's not too much trouble dong could modify RadeonPCI and RadeonDump to check for PPC? I don't want to make work for him though :unsure:.

Link to comment
Share on other sites
Slice
Slice
Posted
  • Author
Posted
Ahh, that's a good point. I did recompile but I didn't modify the code for endianess. I had a look through the code and I changed Little Endian to Big Endian where I could find it, but it still doesn't work.

 

I think I probably missed something. I'm still really new to OS X programming and I've never had to deal with endianess before. Maybe if it's not too much trouble dong could modify RadeonPCI and RadeonDump to check for PPC? I don't want to make work for him though ;).

But Dong make a work for you!

Don't know what exactly codes need to be rewritten. And we don't know what is the good address for PPC BIOS, how it constracted and so on. I think this task is far from our efforts.

 

I have some success. At last!!! :wacko:

Found a device of class RadeonPCI: IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/AGP@1/AGPGart/ATIM@5/RadeonPCI
it matched on name "display"
Detected ATI Radeon Mobility 9100 IGP (U3) 5835 (device id: 0x5835)
Start I2C dump
Legacy BIOS detected
Bios Connector table: 
Port0: DDCType-0x60, DACType-2, TMDSType-1, ConnectorType-CRT
Port4: DDCType-0x0, DACType-0, TMDSType-0, ConnectorType-LCD
Port5: DDCType-0x0, DACType-2, TMDSType-0, ConnectorType-STV
EDID for connector 0:
0x0000: 00FFFFFFFFFFFF004C2DB80137314148
0x0010: 251001030E221B782AAAA5A654549926
0x0020: 145054BFEF8081808140714F01010101
0x0030: 010101010101302A009851002A403070
0x0040: 1300520E1100001E000000FD00384B1E
0x0050: 510E000A202020202020000000FC0053
0x0060: 796E634D61737465720A2020000000FF
0x0070: 00484D454C3932383134320A20200041

Why? It is another outer monitor Samsung 740b. More modern. Old ViewSonic seems has differencies in DDC or non-DDC. Strange. It is professional. It has memory for video modes, menu and so on. :D

One note. I got EDID after hot plug, i.e. without reboot.

Link to comment
Share on other sites
dong
dong
Posted
Posted
Ahh, that's a good point. I did recompile but I didn't modify the code for endianess. I had a look through the code and I changed Little Endian to Big Endian where I could find it, but it still doesn't work.

 

I think I probably missed something. I'm still really new to OS X programming and I've never had to deal with endianess before. Maybe if it's not too much trouble dong could modify RadeonPCI and RadeonDump to check for PPC? I don't want to make work for him though ;) .

Only change endians won't work for real mac. I have found this:

Apple Nvidia cards have 128kb roms (64kb for BIOS and 64 kb for EFI), and only the first half is copied to 0xC0000.

 

To be a bit more precise: the card's romchip contains two contatenated PCI Option Roms, and the Option Rom PCIR structure contains an "indicator" byte which is equal to 0x80 if this is the last Option Rom, and 0x00 otherwise

 

And Apple ATI cards romchip seems to only contain a EFI Option Rom, and the machine's EFI Firmware contains somethingthat looks like a ATI BIOS Option Rom. So, in this case, what is present in 0xC0000 has absolutely nothing in common with what is in the romchip

Still no clue to get EDID for non-DDC LVDS, does it really come from driver? Or some unknown ROM area?

Link to comment
Share on other sites
drlarsen77
drlarsen77
Posted
Posted
Still no clue to get EDID for non-DDC LVDS, does it really come from driver? Or some unknown ROM area?

 

Perhaps a hint on this website:

http://didius.wordpress.com/2006/06/13/osx86/

It is absolutely important that you do not miss any characters in your EDID string, and that it is exactly 128 bytes long. Also have in mind that the above procedure is ONLY for non-Mobility owners, Mobility owners should not do this, your settings come from the BIOS.
Link to comment
Share on other sites
drlarsen77
drlarsen77
Posted
Posted

Well, here's something interesting (I think). I manually toggled bit 15 at 0x0054 which is RADEON_CRTC_CRT_ON. This enabled my attached CRT and now I have mirror mode! Still no EDID info coming from my CRT though.

 

Attached is my modified version of RadeonDump with register write routines enabled.

RadeonDumpDL.zip

Link to comment
Share on other sites
asstastic
asstastic
Posted
Posted

I'd like to help with testing again but I can't make any sense out of what files I need from the first post, etc.

 

If they are still needed I can test RadeonDump over s-video, vga and dvi with an x1600 mobility. It's good to know we can pull LVDS info from card BIOS, I was starting to get worried that the driver had hit a dead end. I think a good short term goal for the project would be to get internal displays working with resolution changing. From the looks of it the driver is almost there already.

Link to comment
Share on other sites
Bandes
Bandes
Posted
Posted

Hi guys, i ve been checking this topic for a while now, cause i am stuck too with my ati x1400 mobility in the realm of 1024x768 pixels..

 

Maybe this one helps, anyway its too high for my knowledge.

 

http://www.nvidia.com/page/mxm.html

 

MXM Software Specification

http://www.nvidia.com/object/IO_13291.html

 

"Function 2 – Return a Pointer to the EDID Structure for the Internal

Panel

This is a required function for systems containing an internal flat panel without an

EDID on DDC/Aux. This function allows the VBIOS to receive a pointer to the

EDID structure that should be used for the internal flat panel in the system. This is

required in cases where the panel being used does not have an EDID structure

which can be read through DDC/Aux lines. This structure resides in the SBIOS

ROM area or in another memory location that is accessible in real mode during

video POST."

Link to comment
Share on other sites
dong
dong
Posted
Posted

According to MXM specification, SBIOS is the motherboard BIOS. Don't know is it just for motherboard implemented MXM or any boards. From my understanding, it seems that "Function 2" is provided by MXM implementation.

Link to comment
Share on other sites
Slice
Slice
Posted
  • Author
Posted

Sorry for long absence. I just returning from trip to Italy, Napoli. And I had no time to work on the problem.

Continue.

 

Still no clue to get EDID for non-DDC LVDS, does it really come from driver? Or some unknown ROM area?

It is really puzzling idea about another ROM area. For example EFI or "driver,MacOS,PowerPC" etc. So why ATIRadeon8500.kext and 9700 is not perfectly working in hackintosh even if a card looks to be supported. Some ROM absent!

My solution - got with it!

I can get LVDS info from BIOS and construct good DisplayMode with the information. RadeonFX project do it!

And we already can use injected EDID. Choose good one!

 

I'd like to help with testing again but I can't make any sense out of what files I need from the first post, etc.

I make a part of the driver as well as Dong and we need to know how these parts work for another users. Take it and test!

If they are still needed I can test RadeonDump over s-video, vga and dvi with an x1600 mobility.

It could be some more informations for us

It's good to know we can pull LVDS info from card BIOS, I was starting to get worried that the driver had hit a dead end. I think a good short term goal for the project would be to get internal displays working with resolution changing. From the looks of it the driver is almost there already.

Why deadend? I see no problem! Yes, LVDS info is present in card BIOS even it is not EDID. Even for non-DDC LCD as I have.

My real problem is in huge number of codes needs to revised.

Hi guys, i ve been checking this topic for a while now, cause i am stuck too with my ati x1400 mobility in the realm of 1024x768 pixels..

 

Maybe this one helps, anyway its too high for my knowledge.

 

http://www.nvidia.com/page/mxm.html

 

MXM Software Specification

http://www.nvidia.com/object/IO_13291.html

As I understand MXM software got information from video driver so...

"Function 2 – Return a Pointer to the EDID Structure for the Internal

Panel

This is a required function for systems containing an internal flat panel without an

EDID on DDC/Aux. This function allows the VBIOS to receive a pointer to the

EDID structure that should be used for the internal flat panel in the system. This is

required in cases where the panel being used does not have an EDID structure

which can be read through DDC/Aux lines. This structure resides in the SBIOS

ROM area or in another memory location that is accessible in real mode during

video POST."

So driver construct EDID and place it in some memory where the Function 2 can read it.

Not interesting for us.

 

I have huge delay with my driver trying to improve joblo's sources. It's impossible. It is better to write new driver based on clear Linux sources as Dong do. Hope they are more working.

Link to comment
Share on other sites
erudified
erudified
Posted
Posted

What do you guys think of creating an ATY_Caretta superclass and initializing LVDS there? Not sure about feasibility.

 

Oh, wow, Dong, YOU RULE!

 

I just built your kext, I looked over the source a bit last night, was skeptical that it'd build/run, but it built without even a warning! I'm typing this while using it.

 

Very well done!!

 

Here's the initial dmesg output from the driver:

 

RadeonHD: Mapped IO at 0x4c749000 (size 0x00010000)
RadeonHD: Mapped Fb at 0x5bec7000 (size 0x10000000)
RadeonHD: xf86Screens allocated and filled with IO, FB, BIOS contents
Detected an M54 on a Dell Inspiron 9400
FUNCTION: rhdMapMMIO
Mapped IO at 0x4c749000 (size 0x00010000)
FUNCTION: rhdMapFB
Mapped FB at 0x5bec7000 (size 0x10000000)
**************************************************
** Code has been built without AtomBIOS support **
** this may seriously affect the functionality ***
**              of this driver                 ***
**************************************************
FUNCTION: rhdGetVideoRamSize
VideoRAM: 131072 kBytes
FUNCTION: RHDI2CFunc
FUNCTION: rhdGetI2CPrescale
FUNCTION: rhdInitI2C
I2C clock prescale value: 0x7f37
I2C bus "RHD I2C line 0" initialized.
I2C clock prescale value: 0x7f37
I2C bus "RHD I2C line 1" initialized.
I2C clock prescale value: 0x7f37
I2C bus "RHD I2C line 2" initialized.
FUNCTION: RHDVGAInit
Detected VGA mode.
FUNCTION: RHDMCInit
FUNCTION: RHDCrtcsInit
FUNCTION: RHDPLLsInit
FUNCTION: RHDLUTsInit
FUNCTION: RHDConnectorsInit
ConnectorInfo from quirk table:
Connector[0] {RHD_CONNECTOR_PANEL, Panel, RHD_DDC_2, RHD_HPD_NONE, { RHD_OUTPUT_LVTMA, RHD_OUTPUT_NONE } }
Connector[1] {RHD_CONNECTOR_VGA, VGA, RHD_DDC_0, RHD_HPD_NONE, { RHD_OUTPUT_DACA, RHD_OUTPUT_NONE } }
Connector[2] {RHD_CONNECTOR_DVI, DVI-D, RHD_DDC_1, RHD_HPD_0, { RHD_OUTPUT_TMDSA, RHD_OUTPUT_NONE } }
FUNCTION: RHDHPDSave
FUNCTION: RHDHPDSet
RHDConnectorsInit: 0 (Panel) type 4, ddc 2, hpd 0
FUNCTION: RHDI2CFunc
FUNCTION: RHDLVTMAInit
Detected a 18bit dual link panel.
Printing LVDS paramaters:
MacroControl: 0x0C720407
TXClockPattern: 0x0063
PowerDigToDE: 0x001C
PowerDEToBL: 0x00F8
OffDelay: 0x01F4
PowerRefDiv: 0x0F9F
BlonRefDiv: 0x0000
FUNCTION: RHDOutputAdd
Attaching Output LVDS to Connector PANEL
RHDConnectorsInit: 1 (VGA) type 1, ddc 0, hpd 0
FUNCTION: RHDI2CFunc
FUNCTION: RHDDACAInit
FUNCTION: RHDOutputAdd
Attaching Output DAC A to Connector VGA 1
RHDConnectorsInit: 2 (DVI-D) type 2, ddc 1, hpd 1
FUNCTION: RHDI2CFunc
FUNCTION: RHDTMDSAInit
FUNCTION: RHDOutputAdd
Attaching Output TMDS A to Connector DVI-D 1
FUNCTION: RHDHPDRestore
FUNCTION: rhdModeLayoutSelect
FUNCTION: DACASense
DACSense: DAC: 0x00
FUNCTION: RHDHPDCheck
RHDHPDCheck returned: 1 mask: 1
FUNCTION: TMDSASense
TMDSASense: Disconnected
FUNCTION: RHDMonitorInit
I2C device "RHD I2C line 2:ddc2" registered at address 0xA0.
FUNCTION: rhd5xxWriteRead
FUNCTION: rhd5xxI2CSetupStatus
FUNCTION: rhd5xxWriteReadChunk
FUNCTION: rhd5xxI2CStatus
FUNCTION: rhd5xxWriteRead
FUNCTION: rhd5xxI2CSetupStatus
FUNCTION: rhd5xxWriteReadChunk
FUNCTION: rhd5xxI2CStatus
FUNCTION: rhd5xxWriteRead
FUNCTION: rhd5xxI2CSetupStatus
FUNCTION: rhd5xxWriteReadChunk
FUNCTION: rhd5xxI2CStatus
FUNCTION: rhd5xxWriteRead
FUNCTION: rhd5xxI2CSetupStatus
FUNCTION: rhd5xxWriteReadChunk
FUNCTION: rhd5xxI2CStatus
I2C device "RHD I2C line 2:ddc2" removed.
rhdMonitorPanel: No panel mode information found.
Unable to attach a monitor to connector "PANEL"
Failed to detect a connected monitor

 

Let's see what happens with some ATOMBIOS lovin', eh? :P Can't stress this enough man, thank you for the great work!

 

 

It's worth noting before I really mess with this that ATOMBIOS *will* compile cleanly, that's actually as far as I got with this last time I played with it ( http://erudified.com/MobilityFB.tar sometime last year ). You're much much farther along!

 

Also, you shouldn't bother even touching that MobilityFB project, it is infected with failure and will probably result in a heart attack :)

 

Okay, got it built with -DATOM_BIOS and -DATOM_BIOS_PARSER, just go rid of a few xf86drvmsg entries and outright deleted all the EASF_DESCRIPTOR nonsense (easf.h isn't in radeonhd and isn't used there, so {censored} it).

 

Okay, apparently don't have all the files built yet!

 

ld(): Undefined symbols:
_CailAllocateMemory
_CailReadFBData
_CailReadMC
_CailReadPLL
_CailReleaseMemory
_CailWriteFBData
_CailWriteMC
_CailWritePLL
_DelayMicroseconds
_DelayMilliseconds
_RHDAtomBiosFunc
_ReadIndReg32
_ReadPCIReg16
_ReadPCIReg32
_ReadPCIReg8
_ReadReg32
_ReadSysIOReg16
_ReadSysIOReg32
_ReadSysIOReg8
_WriteIndReg32
_WritePCIReg16
_WritePCIReg32
_WritePCIReg8
_WriteReg32
_WriteSysIOReg16
_WriteSysIOReg32
_WriteSysIOReg8
_rhdAtomDigTransmitterControl
kextload: kld_load_from_memory() failed for module /System/Library/Extensions/RadeonHD.kext/Contents/MacOS/RadeonHD

 

I'm sure ideally we'll want to replace all the ReadReg & WriteReg functions with OS X equivalents but I'm going for quick and dirty get the AtomBIOS parser in right now, those are probably going to end up being one-liner fixes throughout the code. We can do WriteMask etc, too with native OSX IOPCIDevice funcs iirc...

Link to comment
Share on other sites
dong
dong
Posted
Posted
What do you guys think of creating an ATY_Caretta superclass and initializing LVDS there? Not sure about feasibility.
This can't be done without knowledge of ATY_Caretta class implementation details.
I just built your kext, I looked over the source a bit last night, was skeptical that it'd build/run, but it built without even a warning! I'm typing this while using it.
This driver does limited thing beyond IONDRVSupport.kext

......
I2C device "RHD I2C line 2:ddc2" removed.
rhdMonitorPanel: No panel mode information found.
Unable to attach a monitor to connector "PANEL"
Failed to detect a connected monitor

This means the driver failed to get EDID via DDC for your LVDS, thats a bad news.

Let's see what happens with some ATOMBIOS lovin', eh? ;)
I'm not focus on ATOMBIOS ATM. Instead, I'm looking at the ASM code of Caretta, trying to find out the required steps needed for switch resolution.
Okay, got it built with -DATOM_BIOS and -DATOM_BIOS_PARSER, just go rid of a few xf86drvmsg entries and outright deleted all the EASF_DESCRIPTOR nonsense (easf.h isn't in radeonhd and isn't used there, so {censored} it).

 

Okay, apparently don't have all the files built yet!

I expected that, all the ATOMBIOS codes has not been touched before this. Play fun with it. :)
Link to comment
Share on other sites
erudified
erudified
Posted
Posted
This can't be done without knowledge of ATY_Caretta class implementation details.

 

*nods* I was thinking it may be possible to have some sort of catch-all function that'd just pass to super::funcname() but it'd probably be too hairy, plus I think your porting effort is dangerously close to working!

 

I'm not focus on ATOMBIOS ATM. Instead, I'm looking at the ASM code of Caretta, trying to find out the required steps needed for switch resolution.

 

Is there any way I can help with this? It seems like it'd be easier to check out the RadeonHD source to see what's going on for modesetting, or is it a question of what calls what and how (seems likely)?

 

I can give you some debugger output from RadeonHD running on my X1400 in Linux if that'd be at all helpful. Let me know if there's anything I can do!

Link to comment
Share on other sites
dong
dong
Posted
Posted
It seems like it'd be easier to check out the RadeonHD source to see what's going on for modesetting, or is it a question of what calls what and how (seems likely)?
The modesetting is initiated in rhd_cursor.c. You need check original RadeonHD source as it is not included in my code. Seems it only calls switch_resolution function and this function already works in my code, I think something specific to osX is missing in linux code, thats why I resort to Caretta.
I can give you some debugger output from RadeonHD running on my X1400 in Linux if that'd be at all helpful. Let me know if there's anything I can do!
It should help, I appreciate that.
Link to comment
Share on other sites
Never Mind
Never Mind
Posted
Posted

Hiya Slice, hiya all!

 

Been away for a while again |-)

 

Great progress here!

 

Is this already something that I can test as well?

 

I see in the TODO list a :4. Trace GA connection to make AGP working

 

so does this mean I cannot test this yet with my ATI X800 PRO AGP?

 

Let me know, would love to test!

 

Regards, N.M.

Link to comment
Share on other sites
Slice
Slice
Posted
  • Author
Posted
The modesetting is initiated in rhd_cursor.c.

Look into rhd_randr.c

/* SwitchMode: Legacy: Set one mode */
Bool
RHDRandrSwitchMode(ScrnInfoPtr pScrn, DisplayModePtr mode)
{
return xf86SetSingleMode(pScrn, mode, RR_Rotate_0);
}

And so on.

More clear in RadeonXF project

void
legacy_output_mode_set(xf86OutputPtr output, DisplayModePtr mode,
	  DisplayModePtr adjusted_mode)
{

I see RadeonXF contains twice more codes then RadeonHD. Look!

You need check original RadeonHD source as it is not included in my code. Seems it only calls switch_resolution function and this function already works in my code, I think something specific to osX is missing in linux code, thats why I resort to Caretta.

All specific for OSX already contains in IOGraphics project. But I think RadeonHD really is not complete as I didn't find functions that is called inside.

 

Is this already something that I can test as well?

We upload many things. If you test something it would be cool.

I see in the TODO list a :4. Trace GA connection to make AGP working

so does this mean I cannot test this yet with my ATI X800 PRO AGP?

It is too early to say something about 4. because we at 2.

But all AGP card must work in PCI mode.

Link to comment
Share on other sites
dong
dong
Posted
Posted

Sorry that I did not remember clearly. It's actually xf86Cursor.c that execute the switchMode for XServer. You need download xfree86 source to check. Anyway, the corresponding code is pasted here:

/*
* xf86SwitchMode --
*    This is called by both keyboard processing and the VidMode extension to
*    set a new mode.
*/

Bool
xf86SwitchMode(ScreenPtr pScreen, DisplayModePtr mode)
{
 ScrnInfoPtr pScr = XF86SCRNINFO(pScreen);
 ScreenPtr   pCursorScreen;
 Bool        Switched;
 int         px, py;

 if (!pScr->vtSema || !mode || !pScr->SwitchMode)
   return FALSE;

#ifdef XFreeXDGA
 if (DGAActive(pScr->scrnIndex))
   return FALSE;
#endif

 if (mode == pScr->currentMode)
   return TRUE;

 if (mode->HDisplay > pScreen->width || mode->VDisplay > pScreen->height)
   return FALSE;

 pCursorScreen = miPointerCurrentScreen();
 if (pScreen == pCursorScreen)
   miPointerPosition(&px, &py);

 xf86EnterServerState(SETUP);
 Switched = (*pScr->SwitchMode)(pScr->scrnIndex, mode, 0);
 xf86EnterServerState(OPERATING);
 if (Switched) {
   pScr->currentMode = mode;

   /*
    * Adjust frame for new display size.
    */
   if (pScreen == pCursorScreen)
     pScr->frameX0 = px - (mode->HDisplay / 2) + 1;
   else
     pScr->frameX0 = (pScr->frameX0 + pScr->frameX1 + 1 - mode->HDisplay) / 2;

   if (pScr->frameX0 < 0)
     pScr->frameX0 = 0;

   pScr->frameX1 = pScr->frameX0 + mode->HDisplay - 1;
   if (pScr->frameX1 >= pScr->virtualX) {
     pScr->frameX0 = pScr->virtualX - mode->HDisplay;
     pScr->frameX1 = pScr->virtualX - 1;
   }

   if (pScreen == pCursorScreen)
     pScr->frameY0 = py - (mode->VDisplay / 2) + 1;
   else
     pScr->frameY0 = (pScr->frameY0 + pScr->frameY1 + 1 - mode->VDisplay) / 2;

   if (pScr->frameY0 < 0)
     pScr->frameY0 = 0;

   pScr->frameY1 = pScr->frameY0 + mode->VDisplay - 1;
   if (pScr->frameY1 >= pScr->virtualY) {
     pScr->frameY0 = pScr->virtualY - mode->VDisplay;
     pScr->frameY1 = pScr->virtualY - 1;
   }
 }

 if (pScr->AdjustFrame)
   (*pScr->AdjustFrame)(pScr->scrnIndex, pScr->frameX0, pScr->frameY0, 0);

 if (pScreen == pCursorScreen)
   xf86WarpCursor(pScreen, px, py);

 return Switched;
}

It looks to me that nothing special is done in addition to calling *pScr->SwitchMode, which is initialized in RadeonHD's rhd_driver.c. Yes, there is one thing I did not port yet, that is clear FB access (in xf86EnterServerState) before switchMode, is this the problem?

Link to comment
Share on other sites
Slice
Slice
Posted
  • Author
Posted
Sorry that I did not remember clearly. It's actually xf86Cursor.c that execute the switchMode for XServer. You need download xfree86 source to check.

Link please!

It looks to me that nothing special is done in addition to calling *pScr->SwitchMode, which is initialized in RadeonHD's rhd_driver.c. Yes, there is one thing I did not port yet, that is clear FB access (in xf86EnterServerState) before switchMode, is this the problem?

ServerState? I don't thing so. I think it is for X11 base applications. May be I am wrong.

I thought having VideoMode we can adjust Radeon registers (crtc, dac, tmds ...) and thats all. But I don't know yet if it is performed by server mode :)

The only thing we need to inform MacOS what we do filling csc command so Set as Get. I know that Linux codes much more complex - it is another operating system :)

 

About FB access - it's my next task. I want to play with Framebuffer physical address that may be a key for RSxxx chips (shared memory access).

Link to comment
Share on other sites
Slice
Slice
Posted
  • Author
Posted

I notice some strange problem in porting Linux sources to MacOSX.

in Linux DisplayModeRec doesn't contain BitsPerPixel. It is property of ScreenInfo. So we can't switch modes with different bpp on the same screen?

What to do? Use always 32?

 

In MacOS I see member

IOIndex IONDRVFramebuffer::mapDepthIndex(

IODisplayModeID modeID, IOIndex depth, bool fromDepthMode )

What is it?

 

EDITED

in IOGraphics

struct IODisplayModeInformation {
UInt32			nominalWidth;
UInt32			nominalHeight;
IOFixed1616			refreshRate;
IOIndex			maxDepthIndex;
UInt32			flags;
UInt32			reserved[ 4 ];
};
typedef struct IODisplayModeInformation IODisplayModeInformation;

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...