Bug 1156 - Newt EGL/GBM (KMS) driver
Summary: Newt EGL/GBM (KMS) driver
Status: IN_PROGRESS
Alias: None
Product: Jogl
Classification: JogAmp
Component: embedded (show other bugs)
Version: 2.4.1
Hardware: embedded_all linux
: --- major
Assignee: Sven Gothel
URL:
Depends on:
Blocks:
 
Reported: 2015-04-24 14:11 CEST by Erik De Rijcke
Modified: 2019-09-10 18:14 CEST (History)
1 user (show)

See Also:
Type: FEATURE
SCM Refs:
Workaround: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Erik De Rijcke 2015-04-24 14:11:27 CEST
Hi, 

I'm writing a poc NEWT driver that uses KMS. 

I managed to setup a display but somehow newt does not find a valid gl profile (it finds nothing). I have no idea why this is. This is the output that I get: http://hastebin.com/raw/tinojegadi


I base myself on this C project: https://github.com/robclark/kmscube/blob/master/kmscube.c

My code can be found here: 
https://github.com/Zubnix/kmscube-jogl

and can be run with this oneliner (outside of X as it uses KMS!): 
mvn clean package assembly:assembly && java -Dnativewindow.ws.name=com.github.zubnix.kmscube.kmsdriver -Dnewt.debug=all -jar target/kmscube-jogl-1.0-SNAPSHOT-static.jar 

Does anyone have an idea what's going on? To me it looks like it tries to contact X for some bizarre reason...
Comment 1 Erik De Rijcke 2015-04-24 14:19:41 CEST
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]
Comment 2 Erik De Rijcke 2015-04-24 14:20:38 CEST
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'
Comment 3 Erik De Rijcke 2015-05-12 22:34:01 CEST
I decided to write a gbm NEWT driver directly in the jogl project.

Progress here:
https://github.com/Zubnix/jogl
Comment 4 Sven Gothel 2019-09-10 18:02:35 CEST
(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.
Comment 5 Sven Gothel 2019-09-10 18:13:51 CEST
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.