eglTerminate kills Qt window on wayland when sharing the same display between interface and vout_window

Replying to [ticket:23572 Alexandre Janniaux]:

One solution is using refcounting through EGL_KHR_display_reference, but it's not supported everywhere, and especially not on open source MESA drivers.

Mesa is indeed open source. Thus if a patch had been sent to Mesa when the problem was uncovered, it would in all likelihood already be in Mesa releases now, long before VLC 4.0 ~~came~~comes out.

It would be hypocritical to blame anybody for not writing a patch, as I am equally aware and affected by the problem, but we have to be realistic here: The VLC bug tracker is not the place to handle Mesa issues, and I really don't like to leave third-party and/or impossible-to-fix bug reports open here.

Those are very minimalist and presumably agreeable requirements:

VLC MUST NOT destroy/release resources still in use.
VLC MUST NOT leak resources in more than constant amount per process lifetime.
VLC SHOULD NOT leak resources at all.
Existing VLC features MUST keep working if their implementation is well-defined.

Assuming that Wayland is used and EGL reference counting is unsupported, there simply are not a whole lot of known options that meet the requirements.

We absolutely cannot blindly skip EGL termination. That would cause leak a linear amount of EGL contexts when the XDG shell window provider is used. In fact, it is even worse: it would cause use after free, because the EGL context would survive the underlying Wayland display connection.

We can also not pragmatically determine if the EGL context is shared. We might know whether EGL is used by the window provider (in most but not all cases), and that the window provider will preserve the context long enough. But we will typically not know what parameters the EGL was instantiated with, and/or how EGL run-time front-end matches parameters.

I know how Mesa matched EGL context parameters a few months ago, but I cannot know what future versions of Mesa will do. And then, there are closed source EGL to consider as well. (In fact, it is likely that some non-Mesa EGL's silently provide reference counting because they originate in Android.)

In an embedded setup, the integrator can ensure that VLC and the GUI will share the context. But what do you propose for a desktop distribution? AFAICT, there are only three options:

Forbid window providers from using EGL (current state).
Forbid display with EGL when it is not known whether EGL would be shared.
Tolerate one leaked EGL context on top of the GUI display per VLC instance, and just hope that it will not lead to use-after-free when the GUI closes the Wayland display after the EGL context has been potentially leaked.

And none of those approaches solve this bug. The last one allows EGL, but it will likely trigger crashes sooner or later. Fixing Mesa seems unavoidable to me.

Mesa is indeed open source. Thus if a patch had been sent to Mesa when the problem was uncovered, it would in all likelihood already be in Mesa releases now, long before VLC 4.0 camecomes out.

IMHO, this has nothing to do here. I'm not a Mesa maintainer and don't want to contribute my free time to Mesa for now, and you can't ask me to fix another software.

It would be hypocritical to blame anybody for not writing a patch, as I am equally aware and affected by the problem, but we have to be realistic here: The VLC bug tracker is not the place to handle Mesa issues, and I really don't like to leave third-party and/or impossible-to-fix bug reports open here.

You're contradicting yourself and the discussion on the mailing list. You're telling yourself that we should forbid window providers from using EGL, but it's currently possible, there's currently no way to prevent using EGL with a Qt-based window of type Wayland, and it will still completely crush the UI after closing the display. Even fixing Mesa won't change the fact that previous version will crush the UI.

I'll rewrite my patches to fix that and take the discussion into account. This ticket is for tracking the discussion around that, and my work which is purely about VLC.

If you have any new points, please use the mailing list as trac is slow and not really suited for open discussion with everybody.

Replying to [comment:2 Alexandre Janniaux]:

Mesa is indeed open source. Thus if a patch had been sent to Mesa when the problem was uncovered, it would in all likelihood already be in Mesa releases now, long before VLC 4.0 camecomes out.

IMHO, this has nothing to do here. I'm not a Mesa maintainer and don't want to contribute my free time to Mesa for now, and you can't ask me to fix another software.

I'm not asking anybody to fix anything. You're the one who's asking the VLC developers to fix a problem that they cannot fix.

It would be hypocritical to blame anybody for not writing a patch, as I am equally aware and affected by the problem, but we have to be realistic here: The VLC bug tracker is not the place to handle Mesa issues, and I really don't like to leave third-party and/or impossible-to-fix bug reports open here.

You're contradicting yourself and the discussion on the mailing list.

No, I am not.

You're telling yourself that we should forbid window providers from using EGL,

So far, there have been 2 Wayland window provider plugins (of which only one remains in HEAD), neither of which ever used EGL. Futhermore Wayland is not yet exposed by LibVLC, so no applications could ever have used EGL+Wayland with LibVLC. Overall forbidding EGL is not breaking any existing feature or interface promise. It is also not causing any leaks or undefined behaviour.

but it's currently possible,

No. There is no code that can do that in the current VLC tree.

there's currently no way to prevent using EGL with a Qt-based window of type Wayland,

There is also nothing that prevents de-referencing a null pointer. It's all about conventions.

and it will still completely crush the UI after closing the display. Even fixing Mesa won't change the fact that previous version will crush the UI.

If Qt does not use reference counting and VLC does, Qt will be alone using the non-reference counted EGL context, and everything will work fine.

If you have any new points, please use the mailing list as trac is slow and not really suited for open discussion with everybody.

I don't have any new points, and you have not made any either.

Don't go filing bug reports if you don't want people to comment on them. Especially "notvlc" bugs.

I created the ticket with the Work status=started but I cannot assign this to myself. If it bother you, you can assign me, as I worked on this and said I'm still working on this.

I'm also a developer, VLC contributor, and spent quite a few time on this issue, so please believe I understand it and I created the ticket for a reason.

mentioned in issue #25531 (closed)

added Component::Video: Wayland Platform::GNU/Linux labels

mentioned in issue #26825 (closed)

marked this issue as related to #22156 (closed)

When calling eglTerminate then, it will kill both EGLDisplay.

I found this remark in the specs:

If contexts or surfaces associated with display is current to any thread, they are not released until they are no longer current as a result of eglMakeCurrent.

Doesn't this mean that the display connection remains as long as the contexts or surfaces are current to any thread?

eglTerminate kills Qt window on wayland when sharing the same display between interface and vout_window

Child items ...

Activity