Re: How to release the weston_buffer after weston_view is destroyed.
I actually found the reason, in the function `weston_output_repaint`, the
frame_callbacks
only send the done events for surface which has view on the compositor's
view_list,
but this poses a dilemma, since I cannot either destroy or unmap the view
before the
output repainted.
Sichem
On Sat, Jul 28, 2018 at 8:15 PM, Sichem Zhou wrote:
> Dear Weston devs:
>
> Sorry for the bothering in when weston-5.0 is approaching, but I am stuck
> in the project for three days I need some one's help very much.
>
> I have a widget implementation of shell widgets that destroys the
> weston_view
> when pressed Esc. The widget is implemented in wayland EGL. Here is the
> view_destroy code.
>
> void
> twshell_close_ui_surface(struct weston_surface *wd_surface)
> {
> struct weston_view *view, *next;
> wd_surface->committed = NULL;
> wd_surface->committed_private = NULL;
> wl_list_for_each_safe(view, next, _surface->views,
> surface_link) {
> weston_view_destroy(view);
> }
> }
>
> The weston_view is destroyed but the the buffer in the last commit was not
> released and the done event was not sent to the widget. When I triggered
> the event to show widget again, the client was stuck in EGLSwapbuffer. I
> found out about this by using WAYLAND_DEBUG env variable, I hope to the
> way to release the buffer after umapping the weston view. Thanks very much.
>
> Regards,
> Sichem
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v4 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol
On Tue, 24 Jul 2018 15:10:29 +0200 Dorota Czaplejewicz wrote: > On Thu, 12 Jul 2018 18:15:32 -0400 > Simon Ser wrote: > > > Hi, > > > > Sorry for the delay. > > > > I'm not sure I like this new design. > > > > Finally, I'm not even sure this security mechanism belongs here. I think > > adding > > this mechanism to potentially all privileged protocols will result in > > duplicated > > code and "pollutes" protocols. Here are some other solutions: > > --- snip --- > > * Allow other clients to use this interface too, and use another protocol to > > manage authorizations. Basically the idea would be not to expose this > > interface, and require the client to request access to this privileged > > interface through an authorizer protocol. Someone already mentioned it, > > this > > is Orbital's approach [2]. This allows the compositor to spawn a dialog > > asking > > to the user "do you want to allow to create a virtual keyboard?". > > > > What do you think? > > > I'm in favor of option 3, which will be useful for other protocols as well, > which are not necessarily in position to be kept in a permanent privileged > process, e.g. screen recording. > > It would also make me happier as a protocol author, because the protocol > becomes more compact and easier to maintain without explicit managing. > Thinking a bit more about the topic, this patch with the authentication features removed would end up exactly the same as patch v3. Patch v3 is already implemented in wlroots too. Hereby I withdraw this update. Please refer to 20180622152045.10563-1-dorota.czaplejew...@puri.sm which can be read here: https://lists.freedesktop.org/archives/wayland-devel/2018-June/038629.html Regards, Dorota Czaplejewicz pgp9OHD4KwGO7.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
