[PATCH] mesa.inc: add dispmanx support

[PATCH] mesa.inc: add dispmanx support

[Trevor Woerner]

On the RaspberryPi it is possible to run gles2 applications on top of dispmanx
without the need for x11/wayland/etc.

Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
 meta/recipes-graphics/mesa/mesa.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index a6652b0ddb..34cb3c35e2 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -51,7 +51,7 @@ inherit meson pkgconfig python3native gettext features_check
 
 BBCLASSEXTEND = "native nativesdk"
 
-ANY_OF_DISTRO_FEATURES_class-target = "opengl vulkan"
+ANY_OF_DISTRO_FEATURES_class-target = "opengl vulkan dispmanx"
 
 PLATFORMS ??= "${@bb.utils.filter('PACKAGECONFIG', 'x11 wayland', d)} \
                ${@bb.utils.contains('PACKAGECONFIG', 'gbm', 'drm', '', d)} \
-- 
2.28.0.497.g54e85e7af1

Re: [OE-core] [PATCH] mesa.inc: add dispmanx support

[Khem Raj]

On Thu, Dec 3, 2020 at 5:35 AM Trevor Woerner <twoerner@gmail.com> wrote:
>
> On the RaspberryPi it is possible to run gles2 applications on top of dispmanx
> without the need for x11/wayland/etc.
>
> Signed-off-by: Trevor Woerner <twoerner@gmail.com>
> ---
>  meta/recipes-graphics/mesa/mesa.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
> index a6652b0ddb..34cb3c35e2 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -51,7 +51,7 @@ inherit meson pkgconfig python3native gettext features_check
>
>  BBCLASSEXTEND = "native nativesdk"
>
> -ANY_OF_DISTRO_FEATURES_class-target = "opengl vulkan"
> +ANY_OF_DISTRO_FEATURES_class-target = "opengl vulkan dispmanx"
>

dispmanx is only supported by userland graphics and we do have a
machine feature knob for that
this addition seems not common enough to warrant inclusion in OE-Core.
I would suggest to keep it
in meta-raspberrypi via a bbappend using the machine feature check.

>  PLATFORMS ??= "${@bb.utils.filter('PACKAGECONFIG', 'x11 wayland', d)} \
>                 ${@bb.utils.contains('PACKAGECONFIG', 'gbm', 'drm', '', d)} \
> --
> 2.28.0.497.g54e85e7af1
>
>
> 
>

Re: [OE-core] [PATCH] mesa.inc: add dispmanx support

[Trevor Woerner]

[-- Attachment #1: Type: text/plain, Size: 937 bytes --]

On Thu, Dec 3, 2020 at 2:01 PM Khem Raj <raj.khem@gmail.com> wrote:

> On Thu, Dec 3, 2020 at 5:35 AM Trevor Woerner <twoerner@gmail.com> wrote:
> > -ANY_OF_DISTRO_FEATURES_class-target = "opengl vulkan"
> > +ANY_OF_DISTRO_FEATURES_class-target = "opengl vulkan dispmanx"
> >
>
> dispmanx is only supported by userland graphics and we do have a
> machine feature knob for that
> this addition seems not common enough to warrant inclusion in OE-Core.
> I would suggest to keep it
> in meta-raspberrypi via a bbappend using the machine feature check


I agree with you 100%, and I resisted the idea of a new DISTRO_FEATURE too.
However… Adding "dispmanx" as a new DISTRO_FEATURE here was done almost
entirely in order to support the changes I made to
meta-openembedded's meta-oe/recipes-benchmarks/glmark2. I don't think that
the kind of changes needed over there are possible to do in a bbappend in a
BSP layer (?).

[-- Attachment #2: Type: text/html, Size: 1331 bytes --]

Re: [OE-core] [PATCH] mesa.inc: add dispmanx support

[Phil Blundell]

[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]

If we're talking about OpenGLES applications, wouldn't you already have opengl in DISTRO_FEATURES?

I'm not sure it makes a lot of sense to introduce a check for dispmanx to oe-core if nothing in oe-core ever defines that feature. 

p. 



On 3 December 2020 13:35:26 GMT, Trevor Woerner <twoerner@gmail.com> wrote:
>On the RaspberryPi it is possible to run gles2 applications on top of
>dispmanx
>without the need for x11/wayland/etc.
>
>Signed-off-by: Trevor Woerner <twoerner@gmail.com>
>---
> meta/recipes-graphics/mesa/mesa.inc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/meta/recipes-graphics/mesa/mesa.inc
>b/meta/recipes-graphics/mesa/mesa.inc
>index a6652b0ddb..34cb3c35e2 100644
>--- a/meta/recipes-graphics/mesa/mesa.inc
>+++ b/meta/recipes-graphics/mesa/mesa.inc
>@@ -51,7 +51,7 @@ inherit meson pkgconfig python3native gettext
>features_check
> 
> BBCLASSEXTEND = "native nativesdk"
> 
>-ANY_OF_DISTRO_FEATURES_class-target = "opengl vulkan"
>+ANY_OF_DISTRO_FEATURES_class-target = "opengl vulkan dispmanx"
> 
>PLATFORMS ??= "${@bb.utils.filter('PACKAGECONFIG', 'x11 wayland', d)} \
>          ${@bb.utils.contains('PACKAGECONFIG', 'gbm', 'drm', '', d)} \
>-- 
>2.28.0.497.g54e85e7af1

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 1587 bytes --]

Re: [OE-core] [PATCH] mesa.inc: add dispmanx support

[Trevor Woerner]

[-- Attachment #1: Type: text/plain, Size: 3382 bytes --]

On Thu, Dec 3, 2020 at 5:25 PM Phil Blundell <pb@pbcl.net> wrote:

> If we're talking about OpenGLES applications, wouldn't you already have
> opengl in DISTRO_FEATURES?
>

Not necessarily.

Adding opengl to DISTRO_FEATURES really means "enable a bunch of
PACKAGECONFIGs all over the place because I need x11 and mesa with all the
bells and whistles". These things are not necessary to build and run apps
based on dispmanx. With this patch and my patch to meta-openembedded I'm
able to build "core-image-minimal" with no x11/wayland, no window managers,
with "userland" and with "glmark2". Here is my package list:

  1 base-files_3.0.14-r89_raspberrypi3.ipk
  2 base-passwd_3.5.29-r0_cortexa7t2hf-neon-vfpv4.ipk
  3 bash_5.0-r0_cortexa7t2hf-neon-vfpv4.ipk
  4 busybox_1.32.0-r0_cortexa7t2hf-neon-vfpv4.ipk
  5 busybox-syslog_1.32.0-r0_cortexa7t2hf-neon-vfpv4.ipk
  6 busybox-udhcpc_1.32.0-r0_cortexa7t2hf-neon-vfpv4.ipk
  7 eudev_3.2.9-r0_cortexa7t2hf-neon-vfpv4.ipk
  8 glmark2_2020.11+0+784aca755a-r0_cortexa7t2hf-neon-vfpv4.ipk
  9 init-ifupdown_1.0-r7_raspberrypi3.ipk
 10 initscripts-functions_1.0-r155_cortexa7t2hf-neon-vfpv4.ipk
 11 initscripts_1.0-r155_cortexa7t2hf-neon-vfpv4.ipk
 12 init-system-helpers-service_1.58-r0_cortexa7t2hf-neon-vfpv4.ipk
 13 kbd_2.3.0-r0_cortexa7t2hf-neon-vfpv4.ipk
 14 kernel-5.4.79-v7_1:5.4.79+git0+5d52d9eea9_9797f1a493-r0_raspberrypi3.ipk
 15
kernel-module-i2c-bcm2708-5.4.79-v7_1:5.4.79+git0+5d52d9eea9_9797f1a493-r0_raspberrypi3.ipk
 16
kernel-module-i2c-dev-5.4.79-v7_1:5.4.79+git0+5d52d9eea9_9797f1a493-r0_raspberrypi3.ipk
 17 keymaps_1.0-r31_raspberrypi3.ipk
 18 ldconfig_2.32-r0_cortexa7t2hf-neon-vfpv4.ipk
 19 libblkid1_2.36-r0_cortexa7t2hf-neon-vfpv4.ipk
 20 libc6_2.32-r0_cortexa7t2hf-neon-vfpv4.ipk
 21 libgcc1_10.2.0-r0_cortexa7t2hf-neon-vfpv4.ipk
 22 libjpeg62_1:2.0.6-r0_cortexa7t2hf-neon-vfpv4.ipk
 23 libkmod2_27-r0_cortexa7t2hf-neon-vfpv4.ipk
 24 libpng16-16_1.6.37-r0_cortexa7t2hf-neon-vfpv4.ipk
 25 libstdc++6_10.2.0-r0_cortexa7t2hf-neon-vfpv4.ipk
 26 libtinfo5_6.2-r0_cortexa7t2hf-neon-vfpv4.ipk
 27 libz1_1.2.11-r0_cortexa7t2hf-neon-vfpv4.ipk
 28 modutils-initscripts_1.0-r7_cortexa7t2hf-neon-vfpv4.ipk
 29 ncurses-terminfo-base_6.2-r0_cortexa7t2hf-neon-vfpv4.ipk
 30 netbase_1:6.1-r0_cortexa7t2hf-neon-vfpv4.ipk
 31 packagegroup-core-boot_1.0-r17_raspberrypi3.ipk
 32 run-postinsts_1.0-r10_all.ipk
 33 sysvinit-inittab_2.88dsf-r10_raspberrypi3.ipk
 34 sysvinit-pidof_2.97-r0_cortexa7t2hf-neon-vfpv4.ipk
 35 sysvinit_2.97-r0_cortexa7t2hf-neon-vfpv4.ipk
 36 update-alternatives-opkg_0.4.3-r0_cortexa7t2hf-neon-vfpv4.ipk
 37 update-rc.d_0.8-r0_all.ipk
 38 userland_20201027-r0_cortexa7t2hf-neon-vfpv4.ipk

In my case my DISTRO_FEATURES include "x11" and this new "dispmanx".
"userland" also includes a bunch of dispmanx test programs such as
hello_tiger.bin that work as well.





> I'm not sure it makes a lot of sense to introduce a check for dispmanx to
> oe-core if nothing in oe-core ever defines that feature.
>

As I mentioned to Khem, I added this patch in order to support the changes
I made to the recipe for glmark2 in meta-openembedded. If those can be done
in a bbappend in the BSP layer then I'd be happy to re-asses, but I don't
think they can.

Maybe a better question is: does adding this DISTRO_FEATURE hurt anything
in oe-core?

[-- Attachment #2: Type: text/html, Size: 4165 bytes --]

Re: [OE-core] [PATCH] mesa.inc: add dispmanx support

[Phil Blundell]

On Thu, Dec 03, 2020 at 05:35:23PM -0500, Trevor Woerner wrote:
> On Thu, Dec 3, 2020 at 5:25 PM Phil Blundell <pb@pbcl.net> wrote:
> 
> > If we're talking about OpenGLES applications, wouldn't you already have
> > opengl in DISTRO_FEATURES?
> >
> 
> Not necessarily.
> 
> Adding opengl to DISTRO_FEATURES really means "enable a bunch of
> PACKAGECONFIGs all over the place because I need x11 and mesa with all the
> bells and whistles".

It sounds like there are a few things that have gone wrong here then.
Firstly, "opengl" in DISTRO_FEATURES isn't supposed to imply anything
about x11.  If it does, that's just a bug.  It should indeed enable opengl
support in other recipes, though.  Can you give an example of the sort
of thing that's getting enabled there that you don't want?

But secondly, thinking about it again, there's no reason for mesa itself
to require opengl in DISTRO_FEATURES anyway.  Mesa itself is what provides
the GL API so it clearly doesn't depend on it.  I think that existing
DISTRO_FEATURE check in mesa is just bogus and should be removed entirely.

> As I mentioned to Khem, I added this patch in order to support the changes
> I made to the recipe for glmark2 in meta-openembedded. If those can be done
> in a bbappend in the BSP layer then I'd be happy to re-asses, but I don't
> think they can.

It's a bit hard to say anything intelligent about that without knowing what
the changes are.  Can you summarise what the issue is?

> Maybe a better question is: does adding this DISTRO_FEATURE hurt anything
> in oe-core?

Clearly it doesn't actually break anything, but it's going to be a bit of
a maintenance burden because it won't be very obvious to anybody else
working on the recipes what it's supposed to mean.

p.

Re: [OE-core] [PATCH] mesa.inc: add dispmanx support

[Trevor Woerner]

On Fri 2020-12-04 @ 11:51:41 AM, Phil Blundell wrote:
> On Thu, Dec 03, 2020 at 05:35:23PM -0500, Trevor Woerner wrote:
> > On Thu, Dec 3, 2020 at 5:25 PM Phil Blundell <pb@pbcl.net> wrote:
> > 
> > > If we're talking about OpenGLES applications, wouldn't you already have
> > > opengl in DISTRO_FEATURES?
> > >
> > 
> > Not necessarily.
> > 
> > Adding opengl to DISTRO_FEATURES really means "enable a bunch of
> > PACKAGECONFIGs all over the place because I need x11 and mesa with all the
> > bells and whistles".
> 
> It sounds like there are a few things that have gone wrong here then.
> Firstly, "opengl" in DISTRO_FEATURES isn't supposed to imply anything
> about x11.  If it does, that's just a bug. 

I have this bad habit of saying something specific when I actually mean to use
something as an example, sorry. I meant to say "if, for example, i'm building
an image for x11, and want opengl support…". As far as I can tell enabling
opengl in DISTRO_FEATURES doesn't imply x11 in any way, sorry :-)

> It should indeed enable opengl
> support in other recipes, though.  Can you give an example of the sort
> of thing that's getting enabled there that you don't want?

I am seeing an issue, but after quite a bit of testing and checking, I now
realize that the issue I was seeing is because of something a BSP layer is
doing and is not related to anything in core.

> But secondly, thinking about it again, there's no reason for mesa itself
> to require opengl in DISTRO_FEATURES anyway.  Mesa itself is what provides
> the GL API so it clearly doesn't depend on it.  I think that existing
> DISTRO_FEATURE check in mesa is just bogus and should be removed entirely.

Excellent, I agree.

If I understand it correctly, mesa can PROVIDE more than just the GL
interface; it can, for example, PROVIDE gbm which is useful for situations
where GL is provided via a binary (such as in my case with Raspberry Pi's
userland).

I'll send a patch.

Best regards,
	Trevor