Syphon Virtual Screen (again!)

[Andrea Cremaschi]

Hi,

I just baked a new version of Syphon Virtual Screen (build 5), hope that someone find it useful. This corrects a bug that prevented SVS to work on MBPs with dual GPU (thanks anome for the bugfix!).

https://rapidshare.com/files/3951236161/SyphonVirtualScreen.pkg

So, what is SVS?

“Syphon Virtual screen is a tool to share video output in applications that can go full-screen but are not yet Syphon-enabled (I use it with QLab, waiting for Qlab 3!)

The framebuffer it draws on is developed by Enno Welbers (here on GitHub: https://github.com/mkernel/EWProxyFramebuffer Thanks Enno!). It resides in CPU memory, so maybe it could not be the best solution for heavy video processing: every frame has to be uploaded to the GPU RAM to be published on a syphon server, and this is a (relatively) slow operation. The best would be having native Syphon support in the application you target of course, but if you’re here it means you can go that way.. But still it can be helpful to hijack an application video output that is not Syphon-enabled. As for now, this is the only solution with QLab, while we wait for a real support in the application. SVS has been reported to work flawless on a 2048×768 texture.”

All the code can be find here:
https://github.com/andreacremaschi/Syphon-virtual-screen

• This topic was modified 8 years, 8 months ago by Andrea Cremaschi.

[vade]

This is great work. Thank you so much for your support of Syphon and its ecosystem!

[Anome]

Great Andrea. Thanx Enno also, that helps me to find OpenGL direct instructions 🙂
It’s really using less CPU than my app test !

Now, time for me to prepare my tutorial QLab-to-Millumin !

[Andrea Cremaschi]

Thanks vade and anome!

Actually, anome bugfix broke the banks: the code has been improved again (thx fernLightning!) and CPU usage is under 4% on my machine. I think it’s the best we can hope to have for non-Syphon enabled applications for now.

https://rapidshare.com/files/3975409114/SyphonVirtualScreen.pkg

(link above is broken)

Happy video-output hijacking!

[vade]

Hey Andrea, there may be some faster ways to make this truly OpenGL accelerated. In 10.8, there is a new display capture API (CGDIsplayStream), and in preparation for 10.8, I’ve written a very fast screen capture plugin for Quartz Composer. I wonder if you can use the proxy frame buffer, but then grab the frames off of the GPU (if they ever get there? Im unsure?)

Anyway, its worth looking at:

https://github.com/v002/v002-Media-Tools/blob/master/v002%20Media%20Tools/v002_Screen_CapturePlugIn.m

[Anome]

Hello !

Installation is now ok for me (Snow Leopard and Lion).
Works great, almost no CPU use, but GPU is working. Anyway, something has to do the job 😉

Thanx Andrea, Vade and Bangnoise, because now it’s so easy to make QLab talks to other app.
Syphon Virtual Screen is so light and efficient !

@_Vade : the extension used by Andrea (EWProxyFramebuffer) is not using the GPU/OpenGL, rather the CPU to emulate the display, and copy the pixels. As far as I know …

[vade]

Yes, I understand that 🙂

However, the OS may be already making a surface out of it, and the new API is used for GPU to GPU screen capturing. What I am saying is this new API may be a faster path. Or not.

[Andrea Cremaschi]

@vade: thanks for the hint about CGDisplayStream, is there any reference about that? It may be worth trying. Even though handling with CoreGraphics brought me issues in the past, since I haven’t find a proper way to get the CGDisplayID of a given framebuffer/physical device.

[baby-rabbit]

These new APIs of 10.8 are well hidden.

[baby-rabbit]

Andrea – try the following:

CGDirectDisplayID display[32];
uint32_t displayCount = 0;
CGGetActiveDisplayList(32, display, &displayCount);
for(int i = 0; i < displayCount; i++) {
io_service_t service = CGDisplayIOServicePort(display[i]);
CFStringRef nameRef = IORegistryEntryCreateCFProperty(service, CFSTR("CFBundleIdentifier"), kCFAllocatorDefault, 0);
if(CFStringCompare(nameRef, CFSTR("info.ennowelbers.framebuffer"), 0)==0) {
// success! - display[i] is the display using the proxy framebuffer
}
}

[Andrea Cremaschi]

Yes, that will do, thank you! Too bad I can’t switch to 10.8 on my mac, or I’d be glad to test CGDisplayStream function myself: feel free to fork the project on github!

[baby-rabbit]

CGDisplayStream does indeed work very well, however on the virtual screen the performance is about the same as mapping the memory of the ewproxyframebuffer.

Driver monitor says that on this display (and the virtual display only) that the driver is busy uploading bytes to the IOSurface when using CGDisplayStream.  Furthermore, probing the display with CGLQueryRendererInfo() shows that only the software renderer is available.

So this is as Anome said earlier – the virtual display is not using the GPU directly – which  suggests that whatever API is used to access it to build IOSurfaces, is going to result in GPU/CPU bus traffic.

 

[vade]

Cool. My thought process was that potentially, the window server manages uploading that software screen to an offline GPU, thus the IOSurface backing would be on the GPU, not CPU.

Worth trying…

• This reply was modified 8 years, 7 months ago by vade.

[Andrea Cremaschi]

Ok so the next step further would be to write a real virtual screen simulator (not a virtual frame buffer as ewproxyfb is), that would make the GPU driver allocate a GPU memory front-buffer. But this is far beyond my reaches, and driver documentation is really poor, and I’m sooo satisfied with this last version of SVS 🙂
thx fernlightning, again!

[baby-rabbit]

The only similar osx project I’m aware of is http://code.google.com/p/ioproxyvideofamily/, but it looks like the same approach as ewproxyfb.

[Anome]

Hello.

I post this tutorial for QLab and Millumin, using Syphon Virtual Screen.
—> Videomapping, QLab and Millumin

Thank for your great job. Philippe

[eugenyo]

Hi Andrea! Thanks a lot for the SVS, it´s geat! I´ve used it to connect Q-lab with Madmapper, and it worked on the first attempt! Now a question about it! I nead to send an big image to madmapper to send it to 2 projectors over a Dualhead. Is there some posibillity to  use different resolution than the listed in the menu? I nead 2800 x 1050 for two SXGA+ projectors. Thanks a lot

Eugenio

[Andrea Cremaschi]

Hi Eugenio,
yes, it is possible to use a custom virtual screen size without even recompiling the framebuffer, but you have to edit the kext configuration.

Just do this:
– open the Terminal
– type “sudo su”, enter, type your password
– type “cd /System/Library/Extensions/EWSyphonProxyFramebuffer.kext/Contents/”
– type “nano Info.plist”
– search this section:
MaxResolution

height
1024
width
1280

and replace max height and width as you need to

– a little above this section you’ll find a list of available resolutions. Add yours:

height
2048
name
2048×768
width
768

– type “Ctrl+X” to save your editing

– now, back in terminal, you have to repair permissions for the driver you’ve just modified. Type:
“sudo chmod -R 755 /System/Library/Extensions/EWSyphonProxyFramebuffer.kext”
“sudo chown -R root:wheel /System/Library/Extensions/EWSyphonProxyFramebuffer.kext”

– delete the kext cache (“rmdir -R /System/Library/Caches/com.apple.kext.caches/Startup”);

– reboot

Let me know if everything went ok,
a.

[eugenyo]

Hi Andreas! Thanks a lot for the fast answer!!

My OS is in Spanish, so i asume it is cd /Sistema/Librería/Extensions…. but anyway there´s no folder or file called EWSyphonProxyFramebuffer.kext

There is one called EWProxyFramebuffer.kext but it tell me no such a file found. So i can not go further than the second line in the terminal! Any suggestion?

Thanks again!

Eugenio

[eugenyo]

I kept trying and i´ve noticed that it is the same if you put the route in English. Then i edited the EWProxyFramebuffer.kext and there is no resolution information, so definitivle theres not the right folder!

Thanks

E

 

[Author]

Posts