libGL and snaps

[jamesh]

@ogra

This will rule out any proprietary BSP based graphics drivers on Ubuntu Core that have to be built directly along with the kernel (mali, vivante, SGX/pvr etc) which enforces a hard dependency between kernel and drivers/libs that snaps can not reflect.

Is there anything preventing you from adding a content interface slot to your kernel snap to keep the kernel space/user space parts in sync?

[greyback]

Can content-interfaces be auto-connected?

Is there a concept of “standard” content-interface names? To avoid different snaps implementing the same thing under different names “gl-libs” “gllibs” “opengl-libs” etc…

I know that the user can connect them anyway, but standardized naming would make auto-connecting easier, no?

[ogra]

@jamesh

Is there anything preventing you from adding a content interface slot to your kernel snap to keep the kernel space/user space parts in sync?

i’m not sure the kernel snap fully allows (content) interfaces atm, will have to try that …

[jdstrand]

@greyback

Can content-interfaces be auto-connected?

Yes, the base declaration allows auto-connecting content interfaces when the slot and plug sides are from the same publisher. Snap declarations can be used to expand that-- indeed, this is exactly what is happening with the gnome content snap.

[ogra]

I just had a quick conversation with @zyga-snapd who told me that overlaps between content interface and layouts are not possible.

This makes the plan to use a content interface for the GL libs extremely limiting … i.e. if you have some binary thats linked against a certain hardcoded library path (for example every raspbian based binary using GLES will have /opt/vc/lib hardcoded) it will not be possible to use a layout to re-map the libs you got from the content interface of a hardware snap or a kernel snap.