Juce on RaspberryPI with no Xlib

So my aim is to come up with GUI apps running on the RaspberryPI without an Xserver, basically using the GPU to the best extent possible.

I am finding the modules that implement the class "ComponentPeer" (under modules/juce_gui_basics/native/*Windowing.cpp).

So I am thinking on providing an RPI class implementation that provides access to the dispmanx and udev subsystems for keyboard/mouse input. Would that be enough to display all Juce widgets on the screen, or am I missing something that involves a far more complex code migration?




Juce uses an X11 Window for event handling (on standalones at least), so you'll need something else to drive your events.


At ROLI one of the things we're working on will involve a headless linux system so we'll certainly have to make sure this kind of thing can be done..

juce does not use X11 events for messages that are not related to X11 ( see juce_events/native/juce_linux_Messaging.cpp ), so it is pretty easy to run a juce app on a headless system.

What is the states of this Jules? I'm very interested in figuring out how to run my JUCE application fullscreen without needing an X server, desktop manager, etc on linux. 

That's not the same thing that this thread is talking about. JUCE already runs fine on a headless system (i.e. no display). Running a raw framebuffer display that's not via X Windows is a different question, and not something we currently support. It's a cool idea that people have asked for before, but it's a lot more work to implement, and not a priority for us right now.

I am currently after something similar.  Just started using Juce in fact.

I tried to run an OpenGL application freshly created with the Introjucer but I am getting a segmentation fault (backtrace below). 
With the OpenGL example app I am getting the same error.

Running a Raspberry pi 2 model b with the latest version of Raspbian

Anybody experiencing the same issue ? Any ideas ?


Also the animation app seems to work but it's very slow. Isn't the animation app using OpenGL as well for graphics ? 



Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7676a440 (LWP 702)]
0x76f1d200 in glXCreateContext () from /usr/lib/arm-linux-gnueabihf/libGL.so.1
(gdb) bt
#0  0x76f1d200 in glXCreateContext () from /usr/lib/arm-linux-gnueabihf/libGL.so.1
#1  0x002d2b1c in juce::OpenGLContext::CachedImage::runJob() ()
#2  0x000ee8a8 in juce::ThreadPool::runNextJob(juce::ThreadPool::ThreadPoolThread&) ()
#3  0x00118694 in juce::ThreadPool::ThreadPoolThread::run() ()
#4  0x001023f0 in juce::Thread::threadEntryPoint() ()
#5  0x00102520 in threadEntryProc ()
#6  0x76c1fe90 in start_thread (arg=0x7676a440, arg@entry=<error reading variable: Cannot access memory at address 0x75c438e>) at pthread_create.c:311
#7  0x76a0f128 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92 from /lib/arm-linux-gnueabihf/libc.so.6
/build/gdb-nrlhe3/gdb-7.7.1+dfsg/gdb/frame.c:472: internal-error: get_frame_id: Assertion `fi->this_id.p' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) the intern20abzq61
Please answer y or n.
/build/gdb-nrlhe3/gdb-7.7.1+dfsg/gdb/frame.c:472: internal-error: get_frame_id: Assertion `fi->this_id.p' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.