[Mesa-dev] [PATCH RFC] egl/dri2: Add dri3 support to x11 platform

[Pekka Paalanen]

On Sat, 4 Jul 2015 11:18:18 +0800
Boyan Ding <boyan.j.ding at gmail.com> wrote:

> >> [snip]
> >>
> >> +/* FIXME: Is this right? Seems problematic for WL_bind_wayland_display */
> > What seems to be the problem ?
> >
> > Afaik xcb_dri3_open_reply_fds should return an FD which is ok (be that a
> > render_node device, or a master one with explicit auth).
> 
> The problem is that WL_bind_wayland_display don't work under dri3 on
> x11. I only found it yesterday that to get it work, we'll need to add a
> mechanism to pass fd instead of name of dri device in wl_drm protocol.
> 
> Previously, if a wayland client wants to use hardware accelerated EGL,
> it (with the help of libEGL in mesa) will bind to wl_drm object, and
> wl_drm will immediately send the name of dri device to the wayland
> client (actually also libEGL in mesa). After wayland platform code
> opens the device, it has to send the fd to the X server or drm to
> get authentication. Things are different with dri3, where a fd is
> directly sent to the client without the need to authenticate.
> 
> I propose the following addition in wl_drm protocol:
> 
> There are two kinds of wl_drm implementation. One is the current form.
> The other one, called "dri3-capable" (or whatever name), include wl_drm
> object built on dri3 directly or indirectly through wayland platform.
> 
> If a client binds to a "dri3-capable" wl_drm object, it will send a "device"
> event to the client with NULL or empty string (so a client who knows
> nothing about it can safely fail). If the client knows about dri3-capable
> wl_drm object, it will send a request named get_fd and wl_drm will
> respond it with an fd acquired with dri3. If the wl_drm object is not
> "dri3-capable" it will raise an error if it receives a get_fd request,
> so will a "dri3-capable" wl_drm object if it receives authenticate
> request.

Remember, that all protocol errors in Wayland are always fatal, and
cause the whole client to be disconnected. Also, on Wayland EGL simply
cannot have its private connection to the server, it *must* be shared
with the whole application because otherwise EGL cannot operate on
the app's wl_surfaces.

If you really wanted to go this route (it seems you already have a
better idea than this), just use the normal mechanism to extend the
current wl_drm interface, or invent a whole new interface. "Object
flavours" does not seem like a workable solution the way you describe,
if I understood what you had in mind.

Note, that the compositor and the app may be using different versions
of Mesa, which means they may be using different definitions of wl_drm.
Therefore, wl_drm must follow the same stable protocol rules as
everything else.


Thanks,
pq


> 
> So the following dri3_authenticate function is not needed. Let's not
> expose WL_bind_wayland_display for now, and its enablement
> should be separate patches.
>