Juce on RaspberryPI with no Xlib

Linux
1

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?

Thanks!

Albert

 

2

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

 

3

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..

4

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.

5

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. 

6

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.

7

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 ? 

thanks

 

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.