Simon Taylor wrote: > There's a simple framebuffer driver under GPL as part of their kernel > patch set. https://github.com/raspberrypi/linux/commits/rpi-patches > As far as the hardware accelerated features are concerned - that's not > quite as open. AFAIK the kernel-side (and thus GPL) part is just a > generic message pipe to the VideoCore - the actual GL/video decode/etc > implementations are probably not open. Eben (project lead) is keen to > open the GL stack if possible, but that's a call for Broadcom to make, > and I don't hold out a lot of hope. Yes, there is a discussion about it here: http://www.raspberrypi.org/forum/off-topic/linux-frame-buffer-driver JamesH wrote: "There is a memory mapped frame buffer accessible to the Arm which is used for the moment as the basic output device, no acceleration. The GPU also has access and uses this as a basic image to output. On top of that (or underneath – all images have a Z order) it can then composite the output from the decoder and the 3D engine (and any other bitmaps it wants, e.g. camera output) – at whatever resolution (autoscaled) and rotation (in 90deg steps)." The accelerated video driver sees not to be open source, but I wonder how the OpenRISC team is going to make a port to the Raspberry Pi. I know that they are already porting OpenRISC OS to the Raspberry Pi. Perhaps we could find some information about the drivers there. http://www.raspberrypi.org/forum/distributions/risc-os-on-raspberry-pi http://www.riscosopen.org/wiki/documentation/show/Raspberry%20Pi%20disc %20image%20proposals http://www.riscosopen.org/forum/forums/5/topics/783 Best wishes, Miroslav Stimac -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de