| devilhorns | |
| raster | |
| bu5hm4n |
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>
| No Linters Available |
| No Unit Test Coverage |
| Buildable 17443 | |
| Build 11705: arc lint + arc unit |
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/
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 :) | |
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 | 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 :-)
| 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) | |
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
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.
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 ? :-)
Please reject / close / mark as invalid. No need to change the upstream. This is a local configuration issue to use EGL instead obsolete OpenGL. Thanks! :-)