Page MenuHomePhabricator

evas/drm/gl: Fix meson configuration.
AbandonedPublic

Authored by cederom on Dec 16 2020, 6:18 PM.

Details

Summary

This fixes build on FreeBSD when Wayland and DRM is enabled.
Details: https://phab.enlightenment.org/T8866

Signed-off-by: Tomasz 'CeDeROM' CEDRO <tomek@cedro.info>

evas/drm/gl: Fix missing includes location.

This fixes build on FreeBSD when Wayland and DRM is enabled.
Details: https://phab.enlightenment.org/T8866

Signed-off-by: Tomasz 'CeDeROM' CEDRO <tomek@cedro.info>

Diff Detail

Repository
rEFL core/efl
Branch
cederom-bsd-wayland-20201217
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 17443
Build 11705: arc lint + arc unit
cederom created this revision.Dec 16 2020, 6:18 PM

It seems that this patch has no reviewers specified. If you are unsure who can review your patch, please check this wiki page and see if anyone can be added: https://phab.enlightenment.org/w/maintainers_reviewers/

cederom requested review of this revision.Dec 16 2020, 6:18 PM

Hi! Thank you for the patch, there is one little thing, other than that, things do look good :)

src/modules/ecore_evas/engines/drm/meson.build
6

This should not be removed, you can just add gl_deps here :)

This comment was removed by devilhorns.
devilhorns requested changes to this revision.Wed, Jan 13, 8:51 PM

I'm not Sold on this one Yet....

I think it could be Better....

This revision now requires changes to proceed.Wed, Jan 13, 8:51 PM
cederom added a comment.EditedThu, Jan 14, 4:05 AM

Allright, thank you guys, now have a free moment, will try to build with engine_gl_drm added to gl_deps and see how that builds on FreeBSD :-)

When engine_gl_drm is present meson fails with error below and this is the reason I have removed it on FreeBSD. Any better solutions is welcome on how to make this engine_gl_drm known to meson :-)
src/modules/ecore_evas/engines/drm/meson.build:6:2: ERROR: Unknown variable "engine_gl_drm".

src/modules/ecore_evas/engines/drm/meson.build
6

When engine_gl_drm is present meson fails with error below and this is the reason I have removed it on FreeBSD. Any better solutions is welcome on how to make this engine_gl_drm known to meson :-)
src/modules/ecore_evas/engines/drm/meson.build:6:2: ERROR: Unknown variable "engine_gl_drm".

devilhorns added inline comments.Sun, Jan 17, 7:28 PM
src/modules/ecore_evas/engines/drm/meson.build
6

If the variable is unknown, then we need to trace where this variable is coming from .....

I don't quite understand how it builds on Linux but is Unknown on *bsd....Probably some Bsd thing, but not sure...

To remove engine_gl_drm deps is silly ... Let's try to find out why those are failing...

Sure thing :-) Maybe engine_gl_drm is some sort of Linux assumption not defined with find_package() or something like this (I was this recently in different software that I am porting). I am a bit multitasked recently, sorry, any hints from someone with bigger knowledge is highly welcome :-) Thanks :-)

vtorri added a subscriber: vtorri.Mon, Jan 18, 1:33 AM
vtorri added inline comments.
src/modules/ecore_evas/engines/drm/meson.build
6

src/modules/evas/engines/meson.build line 54 : var_name = 'engine_'+engine (if build is true, line 46)

@cederom can you give the meson command please ?

btw, replace -Dopengl=full with -Dopengl=es-egl

cederom added a comment.EditedMon, Jan 18, 2:00 AM

btw, replace -Dopengl=full with -Dopengl=es-egl

Yes this seems to be the cause of the problem - different defines for -Dopengl=full and -Dopengl=eg-gl (second one valid for drm+wayland?):

Build started at 2021-01-18T10:55:20.080994
Main binary: /usr/local/bin/python3.7
Build Options: -Dsystemd=false -Deeze=true -Dlibmount=false -Davahi=false -Defl-one=true -Dbuild-examples=true -Dfribidi=true -Dcrypto=openssl -Dgstreamer=true -Dharfbuzz=true -Dglib=false -Dlua-interpreter=luajit -Dnls=true -Dopengl=es-egl -Dphysics=true -Dpulseaudio=true -Dsdl=false -Dv4l2=true -Dvnc-server=false -Dwl=true -Ddrm=true -Decore-imf-loaders-disabler=ibus -Devas-loaders-disabler=json,jp2k,avif -Dbindings=cxx -Degl=true -Dprefix=/usr/local -Dinfodir=share/info -Dmandir=man -Dbuildtype=release -Dstrip=True
Python system: FreeBSD
The Meson build system

When opengl=es-gl no patch is even needed. I lack now some linux headers but this is totally unrelated problem, I am using new build machine :-)

src/modules/ecore_evas/engines/drm/meson.build
6

Thank you @vtorri :-) We have -Dopengl=full set to meson build. If you look at src/modules/evas/engines/meson.build line 23 and 28 then it seems drm requires es-gl not full opengl??

Yes this seems to be the cause of the problem - different defines for -Dopengl=full and -Dopengl=eg-gl (second one valid for drm+wayland?):

it seems so, es-egl is for drm + wayland according to this meson.build file.

When opengl=es-gl no patch is even needed. I lack now some linux headers but this is totally unrelated problem, I am using new build machine :-)

good.

Don't forget to close diff and task if they are fixed, and open new ones if there are problems. It's better to have fixes upstream rather than patches landing elsewhere

cederom added a comment.EditedMon, Jan 18, 2:11 AM

Thank you @vtorri :-)

Can anyone please tell why OpenGL-ES is a hard dependency for DRM/Wayland? Why we cannot use full OpenGL? :-)

Yes as you can see guys I am really pro upstream patching. I am amazed why no one did that before :-(

because our full opengl code was written with glx as the display system binding/abstraction. drm/wayland are not x. they don't have glx. egl is a portable binding that works across all of these. our gles code was written with egl as the binding as there is no glx one for it and thus is portable. if gl-es had been universal at the time when i wrote the gl and gles support.. i'd have just gone for egl + gles to save work and time and effort. it was not. egl+gles was universal on embedded systems. full opengl never existed universally there. glx+full opengl was universal on x11 desktops/laptops etc. - if they had any gl support. over time this changed. some embedded systems now can run a full gl implementation and ALL desktops/laptops now can also support egl+gles. so egl+gles is the universal "works everywhere" combination - works in x11, wayland and directly to drm/fb. i'd actually like to get rid of the glx/full gl code just to have less to maintain now as it's basically a historical artifact.

cederom abandoned this revision.Mon, Jan 18, 3:53 AM

Mystery solved by @raster and @vtorri =) No patch needed here, just a proper build configuration parameters. Thank you everyone! :-)

Just a last question to @raster - is it better / safer to switch to opengl=gl-es by default instead opengl=full even on x11 build or this es-gl should be impled only when wayland is selected ? :-)

@cederom what is the status of that diff ?