Jump to content

XRadeonFB


  • This topic is locked This topic is locked
70 replies to this topic

#61
joe75

joe75

    Renegade

  • Retired
  • 2,257 posts
  • Gender:Male
  • Location:Rochester, NY
Any good news to report, joblo :)

#62
BaselineAce

BaselineAce

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 256 posts
  • Gender:Male
  • Location:New York
Did this project die?

#63
joe75

joe75

    Renegade

  • Retired
  • 2,257 posts
  • Gender:Male
  • Location:Rochester, NY

Did this project die?

No
http://x86dev.org/forums/

#64
Korrupted

Korrupted

    Wandering Samurai

  • Retired
  • 1,623 posts
  • Location:Wandering the world over.
  • Interests:Mac<br />Laptops
The project was put on halt, so in a sense, yes, it is dead.

#65
chinak0

chinak0

    InsanelyMac Protégé

  • Just Joined
  • Pip
  • 1 posts
x850 pro (r481) qe/ci can work ?

#66
ole2

ole2

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 180 posts
  • Gender:Male
  • Location:Grenoble, France

The project was put on halt, so in a sense, yes, it is dead.


not exactly dead,
ole2 and slice are working on it now

#67
Korrupted

Korrupted

    Wandering Samurai

  • Retired
  • 1,623 posts
  • Location:Wandering the world over.
  • Interests:Mac<br />Laptops
Keep in mind I made that post a year ago :(

#68
ole2

ole2

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 180 posts
  • Gender:Male
  • Location:Grenoble, France
based on IOGraphics-191.5.tar.gz archive from Darwin

interesting fact was found from IONDRVFramebuffer.cpp:

IONDRVFramebuffer is no longer manage graphic card framebuffer directly,
instead it forwarding all requests/messages to appropriate display driver

for example IONDRVFramebuffer::setGammaTable
IOReturn IONDRVFramebuffer::setGammaTable( UInt32 channelCount, UInt32 dataCount, UInt32 dataWidth, void * data )

is sending cursor information to packager _doControl
IOReturn IONDRVFramebuffer::_doControl( IONDRVFramebuffer * self, UInt32 code, void * params )

which is sending command kIONDRVControlCommand type of kIONDRVImmediateIOCommandKind
to dispatcher doDriverIO
IOReturn IONDRVFramebuffer::doDriverIO( UInt32 commandID, void * contents, UInt32 commandCode, UInt32 commandKind )

which is retrieving display driver from NUB
ndrv = IOBootNDRV::fromRegistryEntry( nub );
and forwarding command to it's own dispatcher with same name doDriverIO
err = ndrv->doDriverIO( commandID, contents, commandCode, commandKind );

ndrv itself is a member of class IONDRVFramebuffer
class IONDRV * ndrv;

and, the only method ndrv->doDriverIO (IONDRV::doDriverIO) was found, is in
class IOBootNDRV : public IONDRV (inherited from IONDRV), but virtual one:

IOReturn IOBootNDRV::doDriverIO( UInt32 commandID, void * contents,
UInt32 commandCode, UInt32 commandKind )

which is doing actual command dispatching (depends on control or status)

switch (commandCode)
{
case kIONDRVInitializeCommand:
case kIONDRVOpenCommand:
ret = kIOReturnSuccess;
break;

case kIONDRVControlCommand:
ret = doControl( pb->code, pb->params );
break;
case kIONDRVStatusCommand:
ret = doStatus( pb->code, pb->params );
break;

default:
ret = kIOReturnUnsupported;
break;
}

which is sent then forward to doControl
IOReturn IOBootNDRV::doControl( UInt32 code, void * params )

which is handing orders (commands), example setting Gamma:

switch (code)
{
case cscSetEntries:
case cscSetGamma:
ret = kIOReturnSuccess;
break;

default:
ret = kIOReturnUnsupported;
break;
}

return (ret);

another dispatcher was found in same archive in another source IONDRV.cpp:

inside class IOPEFNDRV : public IONDRV

IOReturn IOPEFNDRV::doDriverIO( UInt32 commandID, void * contents,
UInt32 commandCode, UInt32 commandKind )

but following one does almost nothing with commands:

switch (commandCode)
{
case kIONDRVReplaceCommand:
case kIONDRVInitializeCommand:
err = _IONDRVLibrariesInitialize( (IOService *) contents );
if (kIOReturnSuccess != err)
break;
/* fall thru */

case kIONDRVFinalizeCommand:
case kIONDRVSupersededCommand:
initInfo.refNum = 0xffff & ((UInt32) this);
MAKE_REG_ENTRY((&initInfo.deviceEntry), contents)
contents = &initInfo;
break;

case kIONDRVControlCommand:
case kIONDRVStatusCommand:
case kIONDRVOpenCommand:
case kIONDRVCloseCommand:
case kIONDRVReadCommand:
case kIONDRVWriteCommand:
case kIONDRVKillIOCommand:

pb = (CntrlParam *) contents;
pb->qLink = 0;
pb->ioCRefNum = 0xffff & ((UInt32) this);
break;
}

most of the commands seems to be just ignored

my question is:

if class IOATYNDRV(or some other name) : public IONDRV inheritance with proper methods implementation, is all what we need for framebuffer functionality on osx86 with ATI chipset?

#69
papillon68

papillon68

    InsanelyMac Protégé

  • Members
  • PipPip
  • 92 posts
There is a test package to try ? I have an X600 Mobility that is running in software mode now ...

#70
dong

dong

    InsanelyMac Sage

  • Retired Developers
  • 366 posts
  • Gender:Male

not exactly dead,
ole2 and slice are working on it now

How is the IOATINDRV class going on now? I'm also looking into this and try to find a way to implement something like CallistoFB for my ATI X1400 mobility, but still struggling in understanding the source code yet.

#71
Slice

Slice

    InsanelyMacaholic

  • Local Moderators
  • 3,027 posts
  • Gender:Male
  • Location:Moscow
Joblo abandon the ship so I think it is better to close the thread and I begin new one.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy