Forum Replies Created
-
AuthorPosts
-
Andrea CremaschiParticipant
Hi boya,
sorry, no clues, I have never tried to make it work with FCPX. As it is working with qlab it should be correctly registered as a monitor, maybe it is not enough for fcpx to use it as a preview screen, some other requirement could be needed. “no problem in problem folder” is weird too, could you file an issue on github to keep track of it?
Just for curiosity, what are you trying to accomplish?Andrea CremaschiParticipantMe too..
If you can’t do without SVS check the instructions on how to use custom resolutions on the project homepage: https://github.com/andreacremaschi/Syphon-virtual-screenAndrea CremaschiParticipantDid you replace the “Syphon Virtual Screen” application in /Applications folder with the one provided in the .zip file?
Andrea CremaschiParticipanthi alfonso
don’t panic 🙂 and follow this link:
https://github.com/andreacremaschi/Syphon-virtual-screenUnder the section “Binary” you’ll find a link to the pkg.
hope this goes without issues, if you encounter some just tell me
ciao
a.Andrea CremaschiParticipantYep sorry, I did quite a mess in organizing the binaries deployment 🙂
Now I centralized the link to the binaries on the project’s page on github, in case I’d need to change it again (hope not). Please refer to that link for the latest version.To check if everything is ok with the Qlab/SVS part, why don’t you use Syphon Recorder? It will give you a list of all active Syphon servers on your machine.
Andrea CremaschiParticipantHi Eugenyo, happy it works.
yes, the “freeze after wake up” bug is a known one, I think it happens in the Proxy Framebuffer kext, but since it is related to proxy programming I haven’t found a clue on how to fix it. This is the bug tracking post:
https://github.com/andreacremaschi/Syphon-virtual-screen/issues?state=openAndrea CremaschiParticipantthis is the full path of the plist to edit:
/System/Library/Extensions/EWProxyFramebuffer.kext/Contents/Info.plistAndrea CremaschiParticipantHi 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:
MaxResolutionheight
1024
width
1280and 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.Andrea CremaschiParticipantOk 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!Andrea CremaschiParticipantYes, 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!
Andrea CremaschiParticipant@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.
Andrea CremaschiParticipantThanks 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!
Andrea CremaschiParticipantHi,
maybe SVS could be of some help for you all: http://v002.info/forums/topic/syphon-virtual-screen-again/a.
Andrea CremaschiParticipantcool! Some time ago I wrote a tool to pipe IIDC cameras to Syphon server using libiidc1394. Feel free to use the source code if you think it could be useful.
https://github.com/micrem73/SyphonIIDCServer/tree/master/SyphonIIDCServer
ac.- This reply was modified 8 years, 10 months ago by Andrea Cremaschi.
Andrea CremaschiParticipantlink broken, this works: https://rapidshare.com/files/3799395488/Syphon_virtual_screen.pkg
Andrea CremaschiParticipantOk, so here it is:
https://rapidshare.com/files/759792021/Syphon_virtual_screen.pkgI put all my code on a git repo: https://github.com/andreacremaschi/Syphon-virtual-screen/tree/90c64ee2983aaa99f5ecb2b1ce548e75e75bce2c
But the application won’t work without the EWProxyFramebuffer kext driver, that is included in the installer package.Again: since the frame buffer reside in system RAM and not in GPU RAM this is not the best solution for everyday Syphon work, but can be helpful to hijack an application video output that is not Syphon-enabled.
Have fun! 🙂Andrea CremaschiParticipantWell, QLab QC support is still weak.. In fact you can write a custom patch to modify the way a single video is composed. I used to put in this composer a syphon server, but with some issues – even stability issues, when the movie is stopped and played again in short time intervals.
What I am working on is a tool that emulate a fake monitor out, so that you can choose that monitor as the main output in QLab (and other applications), a “syphon virtual screen”. Then this output is piped to the GPU on a Syphon server for further video processing. Sort of what Soundflower does for audio, but for video..Andrea CremaschiParticipantWell, I suppose too that AVCaptureVideoDataOutputSampleBuffer would be faster than CGDisplayCreateImage when dealing with framebuffers residing on GPU.. Sadly I have to stick with the second because the open source virtual frame buffer I am dealing with is just a chunk of RAM memory, so an upload to a GPU texture is unavoidable. I am afraid that this means also that it won’t give us GPU acceleration when rendering to the virtual screen. But still it’s great when no other choice is possible (I plan to use it to enable Syphon output for QLab).
I’ll take a look to the private API you point out, it seems interesting..Andrea CremaschiParticipantIn CoreGraphics API I’ve found CGDisplayCreateImage that best fits the needs. This path implies a copy from the virtual device frame buffer to a new buffer in RAM, and an upload to GPU texture every timer tick. But ok, it works and it’s the best we can have.. until a tough IOKit programmer comes out.
Coming soon.- This reply was modified 8 years, 11 months ago by Andrea Cremaschi.
Andrea CremaschiParticipantBad news.. I wrote the developer, his code doesn’t deal with graphic memory but with a fake graphical framebuffer residing in RAM. 🙁
What next? Is there somebody in this forum able to read through NVidia open source driver code and to carry on this project?
http://opensource.apple.com/source/IOGraphics/IOGraphics-409/IONDRVSupport/ -
AuthorPosts