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
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.
Cheap Mobile Phones
I just found this blog post. I'd like to clarify that I was entirely unaware of the prior work that you and Steven have done on the topic. All of what I've done was from reverse engineering Apple code. I certainly would not have had the bad manners to not contribute back to any parent work mine was based upon!
It's been awhile so I don't remember, but I find it incredible that I would have denied you this information… I had totally no idea that it had application outside of making a pretty picture for a ramdisk jailbreak. The only people who ever asked me about it wanted to create their own ramdisk jailbreaks. The only people who ever asked me about it had never contributed back to the xpwn project despite heavily using it in their own work. At the time, we were afraid of leaks to those who actually sell the jailbreak for profit, and this was just a cosmetic advantage that would help defeat them but would not hinder the community. If we had known there was an application outside of jailbreaking, I think this information would have been immediately released.
Perhaps I misremember and you did ask me and I did turn you away, in which case I definitely deserve the castigation. However, the point is moot since I did mean for the code to be easy to reverse. I daresay you benefitted from my research almost as easily if I had given you the C source…. I'd already lifted the key parts from CoreGraphics that made it work for you.