iPhone’s framebuffer secrets revealed
For those who have been long time followers, you probably saw how much I hoped to be able to write to the iPhone and iPod Touch’s video framebuffer. My reasoning was that I would not need to use the taxing call to “setNeedsDisplay” to render all the UIKit elements down to the framebuffer, increasing the performance of my emulators and ports. This basically would skip the middleman that is Apple, and get me closer to something like /dev/fb of NIX.
Recently I was speaking to crash-x and others in saurik’s IRC about the framebuffer. It seems the devteam, in particular planetbeing, has been able to write to the framebuffer ever since redsn0w. Due to devteam’s strict privacy policy he was unable to make this public. At least that is what I hear was the case. This saddens me as it was Steven Troughton Smith and I’s work figuring out how to read the framebuffer for Veency’s use, that probably led to his discovery.
Either way, moments after crash-x and I dug into redsn0w, I had a working example for writing to the framebuffer. It’s not ideal for most people out there, and can’t be used for AppStore apps, but it’s the holy grail of blitting a fullscreen buffer of pixel data repeatedly. And this is exactly what emulators tend to do. What I found out however, is my emulators are set up to still require setNeedsDisplay to swap video buffers. This is not ideal for performance sake. Until setNeedsDisplay can be removed from the equation, I don’t see the following example of writing to the framebuffer too useful for a series of blits.
Here’s the code:
IOMobileFramebufferRef connect = NULL;
kern_return_t result;
CFMutableDictionaryRef dict;
CoreSurfaceBufferRef screenSurface = NULL;
unsigned char* screenbuffer;
// Probe possible framebuffers
io_service_t framebufferService = IOServiceGetMatchingService(kIOMasterPortDefault, IOServiceMatching("AppleH1CLCD"));
if (!framebufferService)
{
framebufferService = IOServiceGetMatchingService(kIOMasterPortDefault, IOServiceMatching("AppleM2CLCD"));;
}
if (!framebufferService)
{
NSLog(@"Nothing found to draw too!");
}
result = IOMobileFramebufferOpen(framebufferService, mach_task_self(), 0, &connect);
result = IOMobileFramebufferGetLayerDefaultSurface(connect, 0, &screenSurface);
CoreSurfaceBufferLock(screenSurface, 3);
// Add to a CALayer here if you want
//
// Get the framebuffer's address to be written to and store it in screenbuffer
screenbuffer = CoreSurfaceBufferGetBaseAddress(screenSurface);
CoreSurfaceBufferUnlock(screenSurface);
// write to screenbuffer like so
// draws a fully white screen
// The screen is 320x480 and seems each pixel is 4 bytes ARGB
memset(screenbuffer, 255, 320*480*4);
I’ll fiddle with this code some more to see if I can remove the need to setNeedsDisplay to swap buffers, and simply check if it will actually improve performance as well. Updates to come!
Thanks,
ZodTTD
whoohoo! Finally! Although I wonder how the dev team will think and react to this, you reverse-engineering their redsn0w tool, when they didn't want to tell you in the first place. Please, ensure there's no drama…
I actually dont understand why the dev team wouldent allow access of the information to you. Maybe for fear of leaking but that seems counter productive for the iPhone development groups. Isn't the whole point of being an open source to share information and help the iPhone be an over all better working platform. Or did they not want to release the information for fear of apple getting a hold of it. Seems utterly confusing to me. Wondering if somebody could explain their reasoning to me.
I don't think this will boost the N64 emulator, as it's going to make use of OpenGL ES. AFAIK there would be no way to re-route Open GL ES to this framebuffer.
This should really boost the N64 emulator right?
This is correct. OpenGL ES probably uses VRAM off the video hardware. But for non-OpenGL ES emulators, the majority of them, it could be a win.
The DevTeam is very close knit and by this decision seems to prefer security through obscurity. While they may be very public about what they do, how they do it is very much a secret now. I don't know their intentions for such. Perhaps ego driven, so they can see DevTeam news posted instead of Geohotz or Chronic's devs.
It's sad to see a team based on opening a device up become so determined to keep their information closed and a secret.
Nice to see increase!
Hey i have a question about the new snes version 6. I had the version before the new one came up and i went to cydia and it had an update for it and i got it but i didnt like it. It gave me rock and a 9 day trial when i use to have it free before. Can you please put up the old version back up i would appreciate it. Thank you