Bug 1156

21:11 < zubzub> sgothel: I think the root cause of the bug is GLProfile's implementation when using EGL
21:12 < zubzub> it seems to revert to the default display or something
21:12 < zubzub> which causes an default egl abstract graphics device to be created
21:12 < zubzub> which causes eglGetDisplay(0) to be called
21:12 < zubzub> which is not supported under gbm/kms
21:13 < zubzub> which results in libEGL trying to connect to X
21:13 < zubzub> which obviously fails
21:13 < zubzub> it's hard to debug because I have to switch between vt's when doing a testrun :)
21:13 < zubzub> ie X can not display stuff once the kms/egl/jogl program is running]

22:21 <+sgothel> @Zuzub: right - EGLDrawableFactory's initialization might be the issue
22:21 <+sgothel> so we have to use that EGL/platform extension if available .. w/ the 'to be probed platform values'

I decided to write a gbm NEWT driver directly in the jogl project.

Progress here:
https://github.com/Zubnix/jogl

(In reply to Erik De Rijcke from comment #3)
> I decided to write a gbm NEWT driver directly in the jogl project.
> 
> Progress here:
> https://github.com/Zubnix/jogl

I missed your egl patches, thank you for working on it.
It is in your own master branch right?

AFAIK I picked some of your work earlier hmm.

Would you be willing to re-produce clean patches?
- No unrelated cleanup changes like imports swizzles etc
- To the point changes only

I can do that as well after merging though.

Foremost: Is it working and how can I test this?

Xerxes's email woke me up about your work:
> * KMS Cube is Mesa 3D example application that initialized EGL using GBM and
> KMS https://gitlab.freedesktop.org/mesa/kmscube/ This application work
> directly from console if you compile it and run it on a Raspberry Pi 4.
> 
> * JOGL do NOT contain support to initialize EGL using GBM/KMS, however some 
> attempts have already been made to implement support for GBM/KMS for other 
> linux systems:
> 
> https://jogamp.org/bugzilla/show_bug.cgi?id=1156 - Newt EGL/GBM (KMS) driver
> * https://github.com/Zubnix/jogl/commits/master <- proof of concept
>  implementation of NEWT GBM/KMS driver, try this 
> Back in 2018, i tried to make a GBM/KMS implementation: 
> my failed attempt is now archived here: 
> https://github.com/xranby/jogl/commits/KMS

I set this to 'in progress' for now as this use case is interesting very much.
Also: this is a new feature.

re 'guessGBM()' I assume you just copied that code from 'guessBroadcomVCIV()'?

Order for GNU/Linux (and other unices) IMHO is

1) Display Server (Vendor neutral)
1.1) running X11 display server (DISPLAY check enough?)
1.2) running WAYLAND display server (WAYLAND_DISPLAY check enough?)

2) Console Mode Vendor Neutral
2.1) GBM (how to check?)

3) Console Mode Vendor Specific
3.1) VCIV (how to check)

If we could at least determine (instead of guessing) (1) properly,
the default fallback would be (2).

Otherwise we have to use (1.1) as the default fallback
and simply rely on the user given determination via the property.

(In reply to Sven Gothel from comment #4)

Xerxes further states:

I made some quick attempts at
merging the two implementaion attempts on top of the current jogl tree here, so that they can compile:
https://github.com/xranby/jogl/commits/gbm-kms

The way I test this code while it is in development is by first compiling gluegen and jogl.
cd gluegen/make
ant
cd ../../jogl/make
ant
cd ../..

and then I test the two implementations by running:

java -Dnativewindow.ws.name=".gbm" -cp gluegen/build/gluegen-rt.jar:jogl/build/jar/jogl-all.jar com.jogamp.newt.opengl.GLWindow

java -Dnativewindow.ws.name=".linux.kms" -cp gluegen/build/gluegen-rt.jar:jogl/build/jar/jogl-all.jar com.jogamp.newt.opengl.GLWindow

For reference https://www.khronos.org/registry/EGL/extensions/MESA/EGL_MESA_platform_gbm.txt

Commit 3e19c2267500c0c459e7dce8d2087387a56f3296 
Branch egl-gbm

Adding new classes DRMLib (gluegen of drm + gbm), DRMUtil and DRMMode GBMDummyUpstreamSurfaceHook 
to new package jogamp.nativewindow.drm, allowing full awareness of DRM + GBM within NativeWindow for JOGL + NEWT.

DRMMode replaces the previous native code of collecting drmMode* attributes: active connector, used mode, encoder etc
and also supports multiple active connectors.

DRMUtil handles the global static drmFd (file descriptor), currently only the GNU/Linux DRM device is supported.

GBMDummyUpstreamSurfaceHook provides a simple dummy GBM surface.

NativeWindow provides the new nativewindow_drm.so and nativewindow-os-drm.jar, 
which are included in most 'all' jar packages.

build property: setup.addNativeEGLGBM -> setup.addNativeDRMGBM

Changes NativeWindowFactory:
- TYPE_EGL_GBM -> TYPE_DRM_GBM while keeping the package ID of '.egl.gbm' for NEWT (using EGL)
- Initializing DRMUtil at initialization 

Changes EGLDrawableFactory:
- Using native GBM device for the default EGL display creation instead of EGL_DEFAULT_DISPLAY.
  This resolves issues as seen in Bug 1402, as well in cases w/o surfaceless support.

- GL profile mapping uses surfaceless when available for GBM, 
  otherwise uses createDummySurfaceImpl (dummy GBM surface via GBMDummyUpstreamSurfaceHook)

- createDummySurfaceImpl uses a dummy GBM surface via GBMDummyUpstreamSurfaceHook

- DesktopGL not available with GBM, see Bug 1401

NEWT's DRM + GBM + EGL Driver 
- Using DRMLib, DRMUtil and DRMMode, removed most native code but WindowDriver swapBuffer
- ScreenDriver uses DRMMode, however currently only first connected CRT.
- WindowDriver aligns position and size to screen, positions other than 0/0 causes DRM failure
- WindowDriver reconfigure n/a

NEWT TODO:
- DRM Cursor support (mouse pointer)
- Pointer event handling

commit f6cd403f3f554d37f63c498b4de956229b4c347a

Bug 1156: Using EGL.eglCreatePlatformWindowSurface(..) crashes on NVIDIA 430.40 on GNU/Linux X11

Note: Following commits from Erik were cherry picked
and subsequent code overhaul replaced with own code.

cd07cb251ae2df8e8cfd455a91cbe7d5394a77e0
f4281b5ee80d7674134bfee357695a98382884a3
e1d767a4063d2503f9099d24a570664f6acd1a34
df599b1c9b08da7335b2c6036c1c9f308ec56387

Also merged Xerxes commit 10d3ba66b725fb44dc2c646c9ddc9816a4d72777,
reverting the default return value to TYPE_X11
as changed by Erik in f4281b5ee80d7674134bfee357695a98382884a3

0d505c3e6dc75687b8bb2ff4f6df6680a084736f 
DRM/GBM Native test: Add Cursor

+++

bdbdcdc800294db3a84926b79503fc2e0e919128
LinuxKeyEventTracker: Fix 64bit InputEvent and attempt to only use keyboard event files
    
    The time structure on 64bit machines uses two 8 byte long values instead of two 4 bytes int values on 32bit machines.
    The insufficient read on 64bit machines caused an IllegalArgument exception.
    This fix considers 32 or 64 bit operation.
    
    Class renamed: LinuxEventDeviceTracker -> LinuxKeyEventTracker, as it tracks key events specifically.
    
    Now the EventDeviceManager tries to only use /dev/input/by-id/*-event-kbd keyboard event files,
    which reduces the handling on kbd event files only.

+++

381858b82c5197193ba2f490a8282149536a54f7
DRM/GBM: Add full PointerIcon (Cursor) Support
    
    DRM allows 64x64 pixel cursor images, using GBM_FORMAT_ARGB888 only.
    
    Notable: GBM_FORMAT_ARGB888 == PixelFormat.BGRA8888
    
    Having fixed mouse and keyboard input with previous commit,
    the demo com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT
    shows via key press
    - i -> pointer visible/invisible
    - c -> pointer icon change

My GNU/Linux x86_64 setup which fully works:
Debian 10.2

uname -a
Linux jogamp06 4.19.0-6-amd64 #1 SMP
Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux

libdrm: 2.4.97-1
mesa:(libgbm, gles2,...): 18.3.6-2
openjdk 11.0.5+10-1~deb10u1

+++

After adding /dev/input/by-path/*-event-kbd into the mix for Ubuntu,
it has been reported that other setup's are not yet working, namely:

1) x86_64 intel, ubuntu 18.4.3 lts (bionic):
    
- all test applications freeze if i press enter from console ,

    unexpected (both yesterday and today after the keyboard patches)

            - kmscube work ok when pressing enter multiple times...

            - jogamp triggers exception in swapbuffers when pressing enter
causing rendering to stop:


2) Debian 10.2 aarch64: everything working incl cursor but no rendering visible

- ES1 and ES2 applications opens display with 1929x1080 and 
  visible mouse-cursor mouse cursor can be moved, 
  but no opengl rendering, tty text log can still be seen, no exceptions, 
  ctrl-c is unable to kill application   
  JVM Shutdown message is seen then it is stuck

- kmscube work ok


3) Rasbian (?) armv6hf: ES1 and ES2 applications are unable to opens display
           unable to find any profiles

- ES1 and ES2 applications are unable to opens display 
  unable to find any profiles

- kmscube work ok

(In reply to Sven Gothel from comment #12)
> 3) Rasbian (?) armv6hf: ES1 and ES2 applications are unable to opens display
>            unable to find any profiles
I had was testing the wrong build, a missing header dependency on the test-machine prevented the right build to complete:

With the correct build using current master:

armv6hf on Raspberry Pi 3b+ using Raspbian and internal 7" TFT is working equally good compared to the x86_64 Intel Ubuntu system!
video: http://www.zafena.se/support/jogamp/2.4.0-test-armv6hf-gbm/armv6hf-raspbian-VC4-V3D-2.1-gbm.mp4

- ES1 and ES2 applications start and render ok, working mousepointer.
- kmscube work ok

The armv6hf Raspbian system reproduces the swapbuffer freeze on enter bug similar seen on the Ubuntu x86_64 system.
- all test applications freeze if i press enter from console ,
            - jogamp triggers exception in swapbuffers when pressing enter
causing rendering to stop:
            - jogamp triggers exception in swapbuffers when typing many caracters, look at video.  
            - kmscube ALSO stops when pressing enter multiple times. "User interrupted !" is printed to console.

armv6hf on Raspberry Pi 4 using Raspbian with HDMI (0) is rendering, same keyboard enter bug as Comment 13

aarch64 on Raspberry Pi 4 booted using Raspbian with 64bit kernel
config.txt: arm_64bit=1
https://www.raspberrypi.org/forums/viewtopic.php?t=250730
and then using an aarch64 Debian buster chroot with HDMI (0) is not working, mouse-pointer visible but no rendering. same bug as Comment 12 - 2)
- The process can not be stopped with ctrl-c
- The process can be removed with SIGKILL

FYI .. (related to crosscompile)

commit 617bb981ef3485edd1e0729934d223da07a72a6b

    Fix gluegen-cpptasks-base.xml for crosscompilation, failed due to unset supposedly detected mandatory new properties
    
    Move new detected build properties build.dynamiclibs, build.staticlibs and output.lib.type
    from gluegen.cpptasks.detect.os.1 to gluegen.cpptasks.detect.os.
    This enables setting these mandatory properties always, as gluegen.cpptasks.detect.os.1 gets overriden
    by custom cross-compilation configurations.
    
    Also moving the property dump from gluegen.cpptasks.detect.os.1 to gluegen.cpptasks.detect.os
    for same reasons.

57b4c7af3ef2007942886f60a128a872d9bcee63
LinuxKeyEventTracker: Add '/dev/input/by-path/*-event-kbd' and more documentation

20030fa36dfad924084aeaa130943165f51e8f0b
HowToBuild: Add GNU/Linux dependencies to libdrm and libgbm

(In reply to Sven Gothel from comment #12)
> 1) x86_64 intel, ubuntu 18.4.3 lts (bionic):
> - all test applications freeze if i press enter from console ,

Workaround for 1)
Using "openvt" to start the java application on a new virtual terminal workaround the freeze on enter bug. 
sudo openvt -- java ...

Updated our crosstools, i.e. Debian 10 aarch64 + arm-armhf 
sysroot libs to crosscompile

https://jogamp.org/cgit/crosstool-ng-projects.git/commit/

Resulting folder are used for crosscompilation, e.g. see GlueGen's
gluegen/make/scripts/make.gluegen.all.linux-aarch64-cross.sh
where TARGET_PLATFORM_USRROOT points to opt-linux-arm64-debian10.

Today's snapshot has been signed and hashed: https://jogamp.org/files/toolchain/20191130-linux-toolchain/

gluegen 617bb981ef3485edd1e0729934d223da07a72a6b
    Fix gluegen-cpptasks-base.xml for crosscompilation, failed due to unset supposedly detected mandatory new properties
    
    Move new detected build properties build.dynamiclibs, build.staticlibs and output.lib.type
    from gluegen.cpptasks.detect.os.1 to gluegen.cpptasks.detect.os.
    This enables setting these mandatory properties always, as gluegen.cpptasks.detect.os.1 gets overriden
    by custom cross-compilation configurations.
    
    Also moving the property dump from gluegen.cpptasks.detect.os.1 to gluegen.cpptasks.detect.os
    for same reasons.

453f80e38bcb0945e7eac27a5917dce9bdc6446b

    Bug 1156: LinuxKeyEventTracker, LinuxMouseTracker: Adding property to disable each
    
    LinuxKeyEventTracker also disable the eventX reading by default, but can be enabled via new property.
    
    The 'return bug' (crash due to underlying console) is indeed not occuring
    when using a VT w/o running console application underneath.
    
    As Xerxes showed, one may use chvt to a free known VT or openvt.

56045ef6f2b33509754fbff82affca94290ae6e0
Bug 1156: Remove verbose print in native CreatePointer.

+++

I have working test machines (operating on a free VT w/o TTY)
and using Debian 10
- x86_64, Intel
- aarch64 BCM (Raspberry) - "Normal" Debian image, not Raspbian

Sadly I could not reproduce Xerxes success on 
- arm7hf Raspbian (see comment 13)

But I am sure he will point me to it.

Closing this bug now, as the main functionality is supported as-is hereby.

Subsequent platform issues and enhancements should be tracked
in followup bug entries depending on this bug.

94dbf9b151bfa8590ea223f58dfe43d45dc0783d
    Bug 1156: LinuxKeyEventTracker, LinuxMouseTracker: Robostness (+NEWT fix)
    
    commit 453f80e38bcb0945e7eac27a5917dce9bdc6446b added disabling the tracker,
    however the NEWT usage didn't cover all mouse tracker null pointer.
    
    Further, let's initialize and spawn off the threads only at first getSingleton() call
    not at class initialization earlier.

See comment 21

The success video of a Raspberry Pi 4 starting JogAmp from console with monitor attached to HDMI 0.
Raspberry Pi 4, Raspbian buster armv6hf, video: http://www.zafena.se/support/jogamp/2.4.0-test-armv6hf-gbm/RaspberryPi4-JogAmp-2.4.0-HDMI0-console-test.mp4

54d34cb749dd877fffcbb2d33cc3707763b94b7e
Bug 1156, Bug 1406: NEWT DRM/GBM WindowDriver.surfaceSwap(): Pass swapInterval to optionally skip VSYNC if 0

78292f1098ef3a83c0426bd0e30b4e725805fa1a
Bug 1156: NEWT DRM/GBM PointerIcon: Use hotX/hotY drmModeSetCursor2(..), hence pass PointerIconImpl through

c80147e3112f3ac87e004c19819b820b42b737df
Bug 1156, Bug 1401: Disable DesktopGL on EGL w/ DRM/GBM earlier in initialization
    
    Was within hasOpenGLDesktopSupport(), but then DesktopGL libs would have been already loaded and looked-up.
    This is not necessary and only wastes resources and time.

6f750711fbcdf746451995e71165bbd119694269
Clarify drmModeSetCrtc(..)'s x/y parameter and earmark spanning across monitors    
drmModeSetCrtc(..)'s x/y parameter are the surface's offset to be scanned out from one CRT!

3e92d34de3672d7f5e401ed6181bb55a58bdf4b6

NEWT Window: Better handling of fixed console case: Not resizable and not repositionable.
    
    Our two fixed size and position console cases 'bcm.egl' and 'egl.gbm' (drm.gbm)
    only operate in a console like fullscreen mode.
    
    We should earmark and expose this behavior, as well as handle it by not waiting for a position / size
    and not attempting to change position and size.
    
    Reducing WindowImpl.minimumReconfigStateMask to bare minimum values:
      STATE_MASK_VISIBLE | STATE_MASK_FOCUSED;
    New WindowImpl.mutableSizePosReconfigStateMask extends WindowImpl.minimumReconfigStateMask, representing previous values:
      STATE_MASK_VISIBLE | STATE_MASK_FOCUSED | STATE_MASK_FULLSCREEN | STATE_MASK_RESIZABLE | STATE_MASK_REPOSITIONABLE;
    
    All WindowDriver implementations previously using WindowImpl.minimumReconfigStateMask
    are now using WindowImpl.mutableSizePosReconfigStateMask but the explicit console driver named above.
    
    I would have liked to add the STATE_BIT_FULLSCREEN  to the current stateMask to notify this semantics,
    however this would have lead to more code changes as our fullscreen mode assumes to be 'on top' of the normal mode.
    Here the normal mode is essentially fullscreen and no back/forth fullscreen setting is useful or allowed.
    Therefore, both fixed size & position console driver won't expose themselves as being in fullscreen mode.

606fbe8b3f4c420f1c4faecf4f49276e054543a0
NEWT WindowDriver: Handle case with requested CapabilitiesImmutable not being GLCapabilitiesImmutable

b91c680fb93a03720ff9fcb39cf052cfe8d40e76

    Bug 1156: Seperate DRM/GBM NEWT native library from main head NEWT native library
    
    DRM/GBM is enabled for Linux in general.
    Nativewindow's 'nativewindow_drm' DRM/GBM native library is already seperated.
    
    NEWT get its 'newt_drm' DRM/GBM native library.
    
    NEWT's main head native library is renamed from 'newt' -> 'newt_head'
    and is earmarked for further seperation similar to Nativewindow's.
    At least a 'newt_wayland' will probably followup when support is added.
    
    Goal is to remove DRM/GBM dependency for Linux X11 operation
    as well as removing X11 dependency for Linux DRM/GBM operation.

jogl 784dcfa2094f3fb235ca4b60395708a1f87c0b1b

    Bug 1156 Regression (Bug 1417): Probe whether 'eglGetPlatformDisplay(..)' is available before using
    
    commit f4281b5ee80d7674134bfee357695a98382884a3 for Bug 1156 (DRM/GBM)
    introduced the call to 'eglGetPlatformDisplay(..)' for known EGL-platforms.
    
    However, 'eglGetPlatformDisplay(..)' is only available for EGL versions >= 1.5
    or 'eglGetPlatformDisplayEXT(..)' if EGL extension 'EGL_EXT_platform_base' is available.
    
    This patch adds a singular EGL version probe and a secondary extension fallback test
    at first call using EGL_NO_DISPLAY on both EGL_VERSION and EGL_EXTENSION eglQueryString(..) calls.
    
    If 'eglGetPlatformDisplay*(..)' is not available, simply use 'eglGetDisplay(..)'.
    
    This regression also impacted Bug 1417 (Android bringup using current SDK + NDK),
    i.e. disabled most Android devices as their EGL version is often 1.4.