What good does building Weston with EGL support but without gl-renderer do?

(In reply to Pekka Paalanen from comment #1)
> What good does building Weston with EGL support but without gl-renderer do?

Hi Pekka,

My use case is that I'm using the RPi renderer, with EGL/GLES2 client apps. From what I have observed, if I don't enable EGL support in Weston, then my client fails in `eglInitialize()`. Whereas if I enable EGL support in Weston, then it all works quite nicely (once my other patches are applied).

Of course, to get any of this to work I had to apply a derivative of this patchset to rpi-userland:

  https://github.com/raspberrypi/userland/pull/110

Which I pulled-in from here:

  https://github.com/Metrological/buildroot/tree/master/package/rpi-userland

It's a pity that these RPi-userland patches can't/won't be merged, but I understand that Mesa VC4 driver is what everyone is waiting for.

I'm quite new to Wayland, so it's entirely likely that I've misunderstood something, in which case please help cure my ignorance :)

You're right, using those proprietary libs is the only applicable use case for your request. Interesting to hear someone is still actually using them with Weston.

I don't have any fundamental objections here.

(In reply to Pekka Paalanen from comment #3)
> You're right, using those proprietary libs is the only applicable use case
> for your request. Interesting to hear someone is still actually using them
> with Weston.

Yes, very much so. AFAIK, Mesa VC4 driver is not fully ready yet, so this seems to be my best option right now for EGL/GLES2 clients. Having to patch RPi userland is a bit messy, but it does at least seem to be working.

> 
> I don't have any fundamental objections here.

Great. Thanks for taking a look.

http://patchwork.freedesktop.org/patch/58748/

(In reply to Pekka Paalanen from comment #3)
> You're right, using those proprietary libs is the only applicable use case
> for your request. Interesting to hear someone is still actually using them
> with Weston.

In theory, someone could also be using a proprietary driver on a non-RPi system (Mali, PVR/IMG, Vivante, NVIDIA) which doesn't support libdrm. That being said, I don't think requiring libdrm itself is too bad, as we don't require its functionality to be present. So I'd tend towards retaining the dependency.

(In reply to Daniel Stone from comment #6)
> (In reply to Pekka Paalanen from comment #3)
> > You're right, using those proprietary libs is the only applicable use case
> > for your request. Interesting to hear someone is still actually using them
> > with Weston.
> 
> In theory, someone could also be using a proprietary driver on a non-RPi
> system (Mali, PVR/IMG, Vivante, NVIDIA) which doesn't support libdrm. That
> being said, I don't think requiring libdrm itself is too bad, as we don't
> require its functionality to be present. So I'd tend towards retaining the
> dependency.

Hi Daniel, thanks for taking a look.

I see your point, but as I'm building for an embedded system I'd rather not add stuff I don't need (and can't use) into my buildroot. It's just another package to track and upgrade as needed.

The patch I'm proposing shouldn't change the default behaviour. It just gives the option to remove the libdrm dependency (and gl_renderer itself) if it's not actually needed.

libdrm is small enough, and our configuration options already bewildering enough, that I don't think this is much of an issue.

Beyond that, the recommended Raspberry Pi driver is now VC4 which will use libdrm, and even NVIDIA are providing KMS which requires libdrm. So at this point I don't think there's much use in avoiding it.