Posted by Xerxes Rånby on Jun 16, 2015; 6:06am
URL: https://forum.jogamp.org/JOGL-2-0-OpenGL-OpenGL-ES-backend-for-LibGDX-tp4027689p4034708.html

piotrekk wrote

> Thank you for patch, now application runs on RPi but i have a few problems
> with this:
>
> Application running in "window" mode looks like this:
 

Nice to see that you have your libgdx application running! Thank you for
documenting your effort with pictures.
I will start describe what you actually see in the pictures.

All OpenGL ES applications using the closed source Broadcom videocore driver
must use the Broadcom specific API named DispmanX to show graphics, this
includes all the OpenGL ES examples found in /opt/vc/src

OpenGL ES on Raspberry Pi using the Broadcom videocore driver is "special",
the window you see is not using X11 instead it is a DispmanX window. The
application can run from text console without starting X11.

The only manual available how DispmanX operate is the examples and headers
in the raspberrypi userland git:
example:
https://github.com/raspberrypi/userland/blob/d4aa617de3b196399bb8e2ce32e181768cb52179/host_applications/linux/apps/hello_pi/hello_triangle/triangle.c#L111-L171
header:
https://github.com/raspberrypi/userland/blob/d4aa617de3b196399bb8e2ce32e181768cb52179/interface/vmcs_host/vc_dispmanx.h
implementation:
https://github.com/raspberrypi/userland/blob/d4aa617de3b196399bb8e2ce32e181768cb52179/interface/vmcs_host/vc_vchi_dispmanx.c


There is an alternative free software driver for the raspberry pi that is
being created by Eric Anholt that will implement a full OpenGL X11 Glamour
Mesa3d driver,  if you manage to use Eric's new driver then you will have
better experience using your application inside X11. Erics driver do not use dispmanx
http://www.anholt.net/
http://anholt.livejournal.com/

piotrekk wrote

> And question is: is it possible to have a window border on RPi?

This needs to be implemented we have a documented the blueprints required
here:
https://jogamp.org/bugzilla/show_bug.cgi?id=626#c3

the main idea is to render offscreen and then use code similar to the example code on how to do efficient DMA GPU to CPU memory copy on the Pi to update the X11 window
https://github.com/shirro/pi-eglonx - "OpenGL ES rendering to X window"

alternative 2:
if you want NEWT to render window borders in textmode then we need to add it similar code to how we added the NEWT mousepointer. https://jogamp.org/bugzilla/show_bug.cgi?id=676
A new enhancement bugreport is required with a topic such as "Add support for native WindowBorder rendering (Rasp.-Pi. .. etc)"

alternative 3:
if you use Anholts driver then X11 will work and you will get a window border for free.

piotrekk wrote

> Application running in window, when you move a mouse cursor to the top of
> screen shows this glitches:
 

Nice effect :)
The "mousepointer" is a  dispmanx overlay.
The overlay looks to have an unexplainable offset in the other direction
-100 pixels in X to the left and +100 pixels in Y upward compared to the
whole screen.
When graphics is rendered outside the screen then you see this nice
demoeffect.
The question is what adds the offset?

piotrekk wrote

> Application running in fullscreen mode don't draw a texture:

 
>
> fullscreen mode i activate with this code at DesktopLauncher libgdx class:
/
> public class DesktopLauncher {
>         public static void main (String[] arg) {
>                 JoglApplicationConfiguration config = new
> JoglApplicationConfiguration();
>                 config.fullscreen = true;
>                 new JoglApplication(new MyGdxGame(), config);
>         }
> }
/
>
*
> And question is: what is wrong with my code?
*
>  

i think your code is correct

its possible that the image is outside the screen, the application is
designed to show much red, you should try with an example that render the
texture on the whole visible surface.

xranby wrote

piotrekk wrote

and last thing - Xerxes pax-britannica running in window mode, I think that is malfunctioning with cursor mapping in application



Greetings,

Peter

If you look closely in the picture you have two mousepointers
one white mousepointer between the PA and X in the game, this is our JOGL NEWT mousepointer!
and one black mousepointer below the game view, this is the X11 mousepointer.

If you run the game from "textmode" then you will only see the JOGL NEWT mousepointer.

We have to look into why the dispmanx surfaces are not aligned with the top left corner of the screen, it looks like the OpenGL ES window has an offset of +100 pixels in X to the right and -100 pixels in Y down.
The mousepointer dispmanx overlay looks to have a similar offset in the other direction -100 pixels in X to the left and +100 pixels in Y upward.

Can these offsets be caused by the "overscan" setings in the closed source broadcom driver?

I have tested to use
disable_overscan=1
in the /boot/config.txt
and the problem still persist thus I think I can rule out the overscan setting.
all demos in /opt/vc/src/hello_pi starts at the top left corner thus i have to examine the jogl code closer.

I will do some extra rounds of code review of the three commits inside JOGL that implement the RaspberryPi mousepointer.
1a0b3287870beca22b0a03aa604fc6a5574a962b
bf0e93260dbd6cb8b6ee0cd10d81341906e62da9
667eca532d3749b0f08e694f36624ff7f621a9c8
https://jogamp.org/bugzilla/show_bug.cgi?id=676