Re: [PATCH 2/2] protocol: add state set functions for maximized and fullscreen.
On Fri, Nov 1, 2013 at 11:36 PM, Jasper St. Pierre wrote: > On Fri, Nov 1, 2013 at 11:58 PM, Jason Ekstrand > wrote: > > ... snip > >> >> Gregory, >> Thank you very much for your e-mail. I think that helps a lot. The lack >> of code is ok because I think Rafael is planning to start implementing as >> soon as things settle a bit. Sometimes protocol discussions can end up with >> a whole lot of hypotheticals and what you gave was a very clear concise >> discussion of the topic. >> >> If I am understanding you correctly, what we need are an "activate" >> request and "notify_active" and "notify_inactive" events. To support sloppy >> focus, clients should just always try to activate on wl_pointer.enter and >> let the compositor sort it out unless they have a good reason to do >> otherwise. For cases such as alt-tab, or another window closing, the >> compositor simply sends a notify_active. I think I'm ok with this. >> >> Two more questions that come to mind: >> >> 1) Will we ever need a deactivate request? Under the given scheme, no >> need comes immediately to mind. > > > No. Well, if we need it, let's add it later. > >> 2) Should the activate be associated with a particular seat. If you have >> multiple cursors, you can easily have multiple active windows so this seems >> perfectly reasonable. If this is the case, should this be part of wl_seat >> or should we keep it in xdg_shell? I'm a little afraid to clutter wl_seat >> unnecessarily but this is very quickly starting to look like a seat focus. > > > I don't think windows need to know which seat they're active on, only that > they're active on possibly one of them. From my eyes, there's nothing that > prevents the compositor to send "notify_active" to more than one window at > the same time for multiseat support. > > If I click on an unresponsive window A, we'll send a "click" event to that > window, but since it's unresponsive, it won't activate. I might then decide > to activate another window B, which will respond. When the window A becomes > responsive again, it will process the "click" event and decide to send an > "activate" request back. We need to make sure that this "rogue" client > doesn't steal the focus, so the compositor needs to record the serial for > the last "activate" event it got (sent by window B), and compare against it > when it gets an "activate" event, besides whatever policies it might have. > > But serials are seat-specific, so we need the "activate" request to relay > the seat back for the purposes of validating the timestamp. I don't think it > makes sense to expose the active window on wl_seat, though. I did not know that when I suggested using the serials. The button, key, and touch events all have timestamps, so if the notify_active event also has a timestamp, the timestamps can serve as the signature, just as they do on X. Using the timestamp should also make it easier to sort out rogue clients. Does Wayland have any of the issues that arise on X due to the latter being asynchronous? I believe I still have notes somewhere on dealing with those, though only for X, if they are necessary. It amounts to little more than the compositor watching the timestamps, but there were a few other needs for either clients or compostors which I cannot recall right now. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] protocol: add state set functions for maximized and fullscreen.
On Fri, Nov 1, 2013 at 10:58 PM, Jason Ekstrand wrote: > On Fri, Nov 1, 2013 at 8:36 PM, Gregory Merchan > wrote: >> >> On Thu, Oct 31, 2013 at 8:28 PM, Jason Ekstrand >> wrote: >> > On Thu, Oct 31, 2013 at 3:37 PM, Bill Spitzak wrote: >> >> >> >> Jason Ekstrand wrote: >> >> >> >>> Yes, in theory they could read the configuration of the compositor. >> >> >> >> >> >>> I really don't want to build this kind of inconsistency into the >> >>> system >> >>> and I don't see why it's justified. >> >> >> >> >> >> I think I see what you are getting at. I think a scheme that allows >> >> simple >> >> applications to obey the global setting without thinking, but still >> >> allows >> >> applications that have a good reason to do tricks with the focus, and >> >> also >> >> matches the raise proposal, is this: >> >> >> >> - The compositor sends an "I want you to activate" event, as you >> >> propose. >> >> - The client can respond to this with an "activate" request. Or it >> >> could >> >> send an "activate" request at other times if it wants. >> >> - The compositor responds to the "activate" request by either ignoring >> >> it >> >> or actually doing the activation. >> >> - The compositor sends an "activated" event that the client can respond >> >> to >> >> by redrawing to show the fact that they are activated. >> >> >> >> If a client just echoes the "I want you to activate" event then it will >> >> work as you expect. A client could also wait after the event until the >> >> mouse >> >> enters a correct location or clicks on the right thing. It could also >> >> try to >> >> generate spurious activates but the compositor may ignore them. >> >> >> > >> > I still don't understand why a client would want to not activate. I can >> > see >> > not wanting to raise, but why not activate? >> >> As Bill mentioned in a follow-up, drag sources would want to not activate. >> >> This can be handled more simply than described above, without a >> special "activate" system. I assume "activation" applies to a window, >> not a client. >> >> First, clients are responsible for requesting activation when it is >> appropriate. >> Second, the compositor always activates when it is appropriate. >> >> The complicated part is determining what is appropriate. >> >> There are 5 activation policies. For each policy, the compositor >> activates windows as needed for key traversal (e.g. Alt+Tab), task bar >> actions, when an active window goes away, viewport changes, etc. The >> compositor also activates windows when a request for activation has >> the correct signature. The policies are distinguished by special cases >> for activation or deactivation: >> >> 1. PointerRoot: Activates a window when the pointer enters it and >> deactivates it when the pointer leaves. >> 2. Sloppy: Activates a window when the pointer enters it. >> 3. Delayed sloppy: Activates a window when the pointer has been within >> for a short time. >> 4. Click-to-focus: Activates a window when it is clicked. >> 5. Windows/MacOS-style: Does not activate a window, except as it does >> for all policies. >> >> (I suppose a "Delayed PointerRoot" policy is possible, but I've never >> seen any discussion of it.) >> >> For each of these policies, another distinction may be made according >> to signature required to honor an activation request. The strictest >> form is to deny all requests, which is not possible on X11 because >> there is no redirection for focus changes. An often desired form for >> the correct signature, among X11 users, is that the request must come >> from a client which is already activated. For example, this allows an >> active program to activate a dialog, but prevents other programs from >> activating any windows. Unless I am mistaken, most attempts at "focus >> stealing prevention" have aimed at such a policy. I'm pretty sure I've >> seen at least one window manager that will fight with bad programs to >> enforce such a policy. On X11, the correct signature is always only >> that the timestamp is later than the last focus change timestamp, and >> this may be achieved by using CURRENT_TIME. Convention is relied upon >> to avoid chaos, that convention is that clients must always use a >> valid timestamp to set focus, and there are 4 sources of valid >> timestamps: 1) button events, 2) key events, 3) property change >> events, and 4) a window manager message. This last source exists to >> address the lack of a timestamp in the focus change event of the X >> protocol. I will refer to this as the "valid event" signature. >> >> Wayland is a different system and there are more options for the >> signature requirement. If I understand the protocol correctly, the >> serial field of pointer, keyboard, and touch events could be used as a >> signature. (Like X, wl_keyboard::enter does not have a time argument, >> so that is not an option.) The strictest form of these >> policies--denying all requests--can be achieved because the compositor >> is in control; it's like a w
Re: [PATCH 2/2] protocol: add state set functions for maximized and fullscreen.
On Fri, Nov 1, 2013 at 11:58 PM, Jason Ekstrand wrote: ... snip > Gregory, > Thank you very much for your e-mail. I think that helps a lot. The lack > of code is ok because I think Rafael is planning to start implementing as > soon as things settle a bit. Sometimes protocol discussions can end up > with a whole lot of hypotheticals and what you gave was a very clear > concise discussion of the topic. > > If I am understanding you correctly, what we need are an "activate" > request and "notify_active" and "notify_inactive" events. To support > sloppy focus, clients should just always try to activate on > wl_pointer.enter and let the compositor sort it out unless they have a good > reason to do otherwise. For cases such as alt-tab, or another window > closing, the compositor simply sends a notify_active. I think I'm ok with > this. > > Two more questions that come to mind: > > 1) Will we ever need a deactivate request? Under the given scheme, no > need comes immediately to mind. > No. Well, if we need it, let's add it later. 2) Should the activate be associated with a particular seat. If you have > multiple cursors, you can easily have multiple active windows so this seems > perfectly reasonable. If this is the case, should this be part of wl_seat > or should we keep it in xdg_shell? I'm a little afraid to clutter wl_seat > unnecessarily but this is very quickly starting to look like a seat focus. > I don't think windows need to know which seat they're active on, only that they're active on possibly one of them. From my eyes, there's nothing that prevents the compositor to send "notify_active" to more than one window at the same time for multiseat support. If I click on an unresponsive window A, we'll send a "click" event to that window, but since it's unresponsive, it won't activate. I might then decide to activate another window B, which will respond. When the window A becomes responsive again, it will process the "click" event and decide to send an "activate" request back. We need to make sure that this "rogue" client doesn't steal the focus, so the compositor needs to record the serial for the last "activate" event it got (sent by window B), and compare against it when it gets an "activate" event, besides whatever policies it might have. But serials are seat-specific, so we need the "activate" request to relay the seat back for the purposes of validating the timestamp. I don't think it makes sense to expose the active window on wl_seat, though. Once again, Gregory, Thanks for the explanation. I hope I'm following ok. > --Jason Ekstrand > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/2] protocol: add state set functions for maximized and fullscreen.
On Fri, Nov 1, 2013 at 8:36 PM, Gregory Merchan wrote: > On Thu, Oct 31, 2013 at 8:28 PM, Jason Ekstrand > wrote: > > On Thu, Oct 31, 2013 at 3:37 PM, Bill Spitzak wrote: > >> > >> Jason Ekstrand wrote: > >> > >>> Yes, in theory they could read the configuration of the compositor. > >> > >> > >>> I really don't want to build this kind of inconsistency into the system > >>> and I don't see why it's justified. > >> > >> > >> I think I see what you are getting at. I think a scheme that allows > simple > >> applications to obey the global setting without thinking, but still > allows > >> applications that have a good reason to do tricks with the focus, and > also > >> matches the raise proposal, is this: > >> > >> - The compositor sends an "I want you to activate" event, as you > propose. > >> - The client can respond to this with an "activate" request. Or it could > >> send an "activate" request at other times if it wants. > >> - The compositor responds to the "activate" request by either ignoring > it > >> or actually doing the activation. > >> - The compositor sends an "activated" event that the client can respond > to > >> by redrawing to show the fact that they are activated. > >> > >> If a client just echoes the "I want you to activate" event then it will > >> work as you expect. A client could also wait after the event until the > mouse > >> enters a correct location or clicks on the right thing. It could also > try to > >> generate spurious activates but the compositor may ignore them. > >> > > > > I still don't understand why a client would want to not activate. I can > see > > not wanting to raise, but why not activate? > > As Bill mentioned in a follow-up, drag sources would want to not activate. > > This can be handled more simply than described above, without a > special "activate" system. I assume "activation" applies to a window, > not a client. > > First, clients are responsible for requesting activation when it is > appropriate. > Second, the compositor always activates when it is appropriate. > > The complicated part is determining what is appropriate. > > There are 5 activation policies. For each policy, the compositor > activates windows as needed for key traversal (e.g. Alt+Tab), task bar > actions, when an active window goes away, viewport changes, etc. The > compositor also activates windows when a request for activation has > the correct signature. The policies are distinguished by special cases > for activation or deactivation: > > 1. PointerRoot: Activates a window when the pointer enters it and > deactivates it when the pointer leaves. > 2. Sloppy: Activates a window when the pointer enters it. > 3. Delayed sloppy: Activates a window when the pointer has been within > for a short time. > 4. Click-to-focus: Activates a window when it is clicked. > 5. Windows/MacOS-style: Does not activate a window, except as it does > for all policies. > > (I suppose a "Delayed PointerRoot" policy is possible, but I've never > seen any discussion of it.) > > For each of these policies, another distinction may be made according > to signature required to honor an activation request. The strictest > form is to deny all requests, which is not possible on X11 because > there is no redirection for focus changes. An often desired form for > the correct signature, among X11 users, is that the request must come > from a client which is already activated. For example, this allows an > active program to activate a dialog, but prevents other programs from > activating any windows. Unless I am mistaken, most attempts at "focus > stealing prevention" have aimed at such a policy. I'm pretty sure I've > seen at least one window manager that will fight with bad programs to > enforce such a policy. On X11, the correct signature is always only > that the timestamp is later than the last focus change timestamp, and > this may be achieved by using CURRENT_TIME. Convention is relied upon > to avoid chaos, that convention is that clients must always use a > valid timestamp to set focus, and there are 4 sources of valid > timestamps: 1) button events, 2) key events, 3) property change > events, and 4) a window manager message. This last source exists to > address the lack of a timestamp in the focus change event of the X > protocol. I will refer to this as the "valid event" signature. > > Wayland is a different system and there are more options for the > signature requirement. If I understand the protocol correctly, the > serial field of pointer, keyboard, and touch events could be used as a > signature. (Like X, wl_keyboard::enter does not have a time argument, > so that is not an option.) The strictest form of these > policies--denying all requests--can be achieved because the compositor > is in control; it's like a window manager and an X server combined in > that sense. The "must be active" signature can be implemented by > checking that the serial number came from an event sent to an active > client. The valid even
Re: [PATCH 2/2] protocol: add state set functions for maximized and fullscreen.
On Fri, Nov 1, 2013 at 8:36 PM, Gregory Merchan wrote: > On Thu, Oct 31, 2013 at 8:28 PM, Jason Ekstrand > wrote: > > On Thu, Oct 31, 2013 at 3:37 PM, Bill Spitzak wrote: > >> > >> Jason Ekstrand wrote: > >> > >>> Yes, in theory they could read the configuration of the compositor. > >> > >> > >>> I really don't want to build this kind of inconsistency into the system > >>> and I don't see why it's justified. > >> > >> > >> I think I see what you are getting at. I think a scheme that allows > simple > >> applications to obey the global setting without thinking, but still > allows > >> applications that have a good reason to do tricks with the focus, and > also > >> matches the raise proposal, is this: > >> > >> - The compositor sends an "I want you to activate" event, as you > propose. > >> - The client can respond to this with an "activate" request. Or it could > >> send an "activate" request at other times if it wants. > >> - The compositor responds to the "activate" request by either ignoring > it > >> or actually doing the activation. > >> - The compositor sends an "activated" event that the client can respond > to > >> by redrawing to show the fact that they are activated. > >> > >> If a client just echoes the "I want you to activate" event then it will > >> work as you expect. A client could also wait after the event until the > mouse > >> enters a correct location or clicks on the right thing. It could also > try to > >> generate spurious activates but the compositor may ignore them. > >> > > > > I still don't understand why a client would want to not activate. I can > see > > not wanting to raise, but why not activate? > > As Bill mentioned in a follow-up, drag sources would want to not activate. > > This can be handled more simply than described above, without a > special "activate" system. I assume "activation" applies to a window, > not a client. > > First, clients are responsible for requesting activation when it is > appropriate. > Second, the compositor always activates when it is appropriate. > > The complicated part is determining what is appropriate. > > There are 5 activation policies. For each policy, the compositor > activates windows as needed for key traversal (e.g. Alt+Tab), task bar > actions, when an active window goes away, viewport changes, etc. The > compositor also activates windows when a request for activation has > the correct signature. The policies are distinguished by special cases > for activation or deactivation: > > 1. PointerRoot: Activates a window when the pointer enters it and > deactivates it when the pointer leaves. > 2. Sloppy: Activates a window when the pointer enters it. > 3. Delayed sloppy: Activates a window when the pointer has been within > for a short time. > 4. Click-to-focus: Activates a window when it is clicked. > 5. Windows/MacOS-style: Does not activate a window, except as it does > for all policies. > > (I suppose a "Delayed PointerRoot" policy is possible, but I've never > seen any discussion of it.) > > For each of these policies, another distinction may be made according > to signature required to honor an activation request. The strictest > form is to deny all requests, which is not possible on X11 because > there is no redirection for focus changes. An often desired form for > the correct signature, among X11 users, is that the request must come > from a client which is already activated. For example, this allows an > active program to activate a dialog, but prevents other programs from > activating any windows. Unless I am mistaken, most attempts at "focus > stealing prevention" have aimed at such a policy. I'm pretty sure I've > seen at least one window manager that will fight with bad programs to > enforce such a policy. On X11, the correct signature is always only > that the timestamp is later than the last focus change timestamp, and > this may be achieved by using CURRENT_TIME. Convention is relied upon > to avoid chaos, that convention is that clients must always use a > valid timestamp to set focus, and there are 4 sources of valid > timestamps: 1) button events, 2) key events, 3) property change > events, and 4) a window manager message. This last source exists to > address the lack of a timestamp in the focus change event of the X > protocol. I will refer to this as the "valid event" signature. > > Wayland is a different system and there are more options for the > signature requirement. If I understand the protocol correctly, the > serial field of pointer, keyboard, and touch events could be used as a > signature. (Like X, wl_keyboard::enter does not have a time argument, > so that is not an option.) The strictest form of these > policies--denying all requests--can be achieved because the compositor > is in control; it's like a window manager and an X server combined in > that sense. The "must be active" signature can be implemented by > checking that the serial number came from an event sent to an active > client. The valid even
Re: [PATCH 2/2] protocol: add state set functions for maximized and fullscreen.
On Thu, Oct 31, 2013 at 8:28 PM, Jason Ekstrand wrote: > On Thu, Oct 31, 2013 at 3:37 PM, Bill Spitzak wrote: >> >> Jason Ekstrand wrote: >> >>> Yes, in theory they could read the configuration of the compositor. >> >> >>> I really don't want to build this kind of inconsistency into the system >>> and I don't see why it's justified. >> >> >> I think I see what you are getting at. I think a scheme that allows simple >> applications to obey the global setting without thinking, but still allows >> applications that have a good reason to do tricks with the focus, and also >> matches the raise proposal, is this: >> >> - The compositor sends an "I want you to activate" event, as you propose. >> - The client can respond to this with an "activate" request. Or it could >> send an "activate" request at other times if it wants. >> - The compositor responds to the "activate" request by either ignoring it >> or actually doing the activation. >> - The compositor sends an "activated" event that the client can respond to >> by redrawing to show the fact that they are activated. >> >> If a client just echoes the "I want you to activate" event then it will >> work as you expect. A client could also wait after the event until the mouse >> enters a correct location or clicks on the right thing. It could also try to >> generate spurious activates but the compositor may ignore them. >> > > I still don't understand why a client would want to not activate. I can see > not wanting to raise, but why not activate? As Bill mentioned in a follow-up, drag sources would want to not activate. This can be handled more simply than described above, without a special "activate" system. I assume "activation" applies to a window, not a client. First, clients are responsible for requesting activation when it is appropriate. Second, the compositor always activates when it is appropriate. The complicated part is determining what is appropriate. There are 5 activation policies. For each policy, the compositor activates windows as needed for key traversal (e.g. Alt+Tab), task bar actions, when an active window goes away, viewport changes, etc. The compositor also activates windows when a request for activation has the correct signature. The policies are distinguished by special cases for activation or deactivation: 1. PointerRoot: Activates a window when the pointer enters it and deactivates it when the pointer leaves. 2. Sloppy: Activates a window when the pointer enters it. 3. Delayed sloppy: Activates a window when the pointer has been within for a short time. 4. Click-to-focus: Activates a window when it is clicked. 5. Windows/MacOS-style: Does not activate a window, except as it does for all policies. (I suppose a "Delayed PointerRoot" policy is possible, but I've never seen any discussion of it.) For each of these policies, another distinction may be made according to signature required to honor an activation request. The strictest form is to deny all requests, which is not possible on X11 because there is no redirection for focus changes. An often desired form for the correct signature, among X11 users, is that the request must come from a client which is already activated. For example, this allows an active program to activate a dialog, but prevents other programs from activating any windows. Unless I am mistaken, most attempts at "focus stealing prevention" have aimed at such a policy. I'm pretty sure I've seen at least one window manager that will fight with bad programs to enforce such a policy. On X11, the correct signature is always only that the timestamp is later than the last focus change timestamp, and this may be achieved by using CURRENT_TIME. Convention is relied upon to avoid chaos, that convention is that clients must always use a valid timestamp to set focus, and there are 4 sources of valid timestamps: 1) button events, 2) key events, 3) property change events, and 4) a window manager message. This last source exists to address the lack of a timestamp in the focus change event of the X protocol. I will refer to this as the "valid event" signature. Wayland is a different system and there are more options for the signature requirement. If I understand the protocol correctly, the serial field of pointer, keyboard, and touch events could be used as a signature. (Like X, wl_keyboard::enter does not have a time argument, so that is not an option.) The strictest form of these policies--denying all requests--can be achieved because the compositor is in control; it's like a window manager and an X server combined in that sense. The "must be active" signature can be implemented by checking that the serial number came from an event sent to an active client. The valid event signature can be implemented by checking that the serial number came from a wl_pointer::button event, a wl_keyboard::key event, a wl_keyboard::enter event, or wl_touch::down event. The compositor is always in control, so clients can request activation as
Re: [PATCH 2/2] protocol: add state set functions for maximized and fullscreen.
Jason Ekstrand wrote: I still don't understand why a client would want to not activate. I can see not wanting to raise, but why not activate? The main one I see is you do not want attempts to drag an object to activate the drag-from client, since this may unmap the desired target of the drag since it belongs to the former active client. Dropping would activate the dropped-on client. I also feel like point-to-type could be helped by this, though I am unsure how. The main reason is that "sloppy focus" could be considered the desktop refusing to take focus when the cursor enters it. - Show in task bar (I'm not convinced this is ever wanted) Why not? Maybe we're missing each other on this one. By "show in task bar" I don't mean as a tray icon. I mean that it's toplevel and it shows up as an independently user-activateble window. What I meant was I don't know if it is ever wanted for non-toplevel surfaces to show in the taskbar. Thus the flag may not be needed since whether or not the surface has a parent controls this. If there is a desire for top-level surfaces that are not in the taskbar then a flag will be needed. If transient windows should be in the taskbar then the client could just do the raises itself, but it may be useful to have the flag then as well. *if* we decide to go with flags, I would recommend a set_relative_position request and an unset_relative_position. Attaching a buffer with a non-zero x and y would change the position but otherwise leave the lock intact. The xdg_shell.move request or anything similar would automatically release the lock. Does this seem reasonable? Another option would be to just set it at (0, 0) relative to the parent and use the next buffer attach to determine the position. Actually that (the 0,0 idea) sounds like a very good idea and in keeping with the design of the rest of Wayland. There will probably need to be scaling and other affine transforms as well, but these are needed for subsurfaces and top-level surfaces. In any case it would be cleaner if transforms were different requests rather than having to put the entire transform on the map call. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH mesa v4] wayland: Add support for eglSwapInterval
On 1 November 2013 02:35, Jason Ekstrand wrote: > On Thu, Oct 31, 2013 at 4:59 AM, Tomeu Vizoso wrote: >> >> On 31 October 2013 02:54, Jason Ekstrand wrote: >> > On Wed, Oct 30, 2013 at 3:59 AM, Tomeu Vizoso >> > wrote: >> >> >> >> On 30 October 2013 09:44, Neil Roberts wrote: >> >> > Tomeu Vizoso writes: >> >> > >> >> >> What I fail to see is why a single sync should be enough, as we >> >> >> don't >> >> >> know when the GPU will signal that it's done with the buffer that we >> >> >> are waiting to be released. >> >> > >> >> > You are right that we don't know when the GPU will release the >> >> > buffer. >> >> > However we are not waiting for that. >> >> >> >> Oh, sure, was saying that in the context of the RPi, there we don't >> >> want the client to have to create more than 2 buffers per surface. >> >> >> >> In that EGL, SwapBuffers blocks waiting for the GPU to signal that >> >> it's done rendering with the buffer that is to become the back buffer. >> >> With your patch for not queueing if no frame callbacks are installed, >> >> we don't need to send any sync requests. Without it, we would need to >> >> keep syncing until we get the release. >> >> >> >> I know that you have dealt with it in Mesa already but wanted to reply >> >> to Jason's comment, sorry for hijacking your thread :) >> >> >> >> This is the relevant part of the code: >> >> >> >> >> >> >> >> https://github.com/tomeuv/userland/commit/a4a7cb233af5e5b167a1cb6f928b7a6381380a56#diff-b1115e30ce4f2940df2cd98a85009ccaR2339 >> > >> > >> > Ok, you are in the crazy edge-case that I feared. However, I still >> > don't >> > think we need some buffer release protocol. Since the buffer releasing >> > issues are graphics-stack-dependent, shouldn't we push that off to the >> > graphics-stack-dependent backends? >> >> Works for the rpi backend, but wonder if the gl renderer may need >> something similar when running on top of a mobile GL stack. > > > This is a non-issue with the GL renderer. It makes the tacit assumption > that, upon return from eglSwapBuffers, it can safely release any buffers. > It is assumed that the underlying GL stack will either pass fences or block > to make this possible. I'm not 100% sure on the details; Daniel or Kristian > could tell you much more. Well, that's one more assumption that I don't know if Weston should be making. Guess it depends on whether we want to make our reference compositor work well only with stacks as sane as Mesa is, or if we want to have it work well also with the crappy GL implementations that all mobile hardware uses these days. Regards, Tomeu > The result is that the buffer releases here always happen in correspondence > to an attach or destroying a surface. The only time we should get these > crazy release times is when dealing with backends that are doing non-EGL > things with the underlying graphics stack. > >> >> >> > I've attached a patch that provides a >> > hook to let a component specify how it wants a given buffer to be >> > released >> > when it deferences it. Since RPi always wants its buffers back ASAP, >> > the >> > compositor can simply always post the event instead of queue. I'm going >> > to >> > reply to this e-mail with a patch that does just that. >> >> Looks good to me. >> >> > If you're concerned with the case where the buffer release would >> > otherwise >> > get flushed by a frame but no frame events (or other events for that >> > matter) >> > are coming to the client, then I would consider that a weston bug. We >> > should really find a way to ensure that buffers do get flushed >> > eventually so >> > clients don't starve(maybe once per frame). >> >> Nod. >> >> > I'm open to the possibility that this is a really bad idea. However, it >> > seems more sane than an extra request or extra EGL extensions. >> >> Thanks, >> >> Tomeu >> >> > --Jason Ekstrand >> > >> >> >> >> >> >> Regards, >> >> >> >> Tomeu >> >> >> >> > We are assuming that the GPU is >> >> > only going to hold on to at most 2 buffers. In the DRM / Mesa case it >> >> > needs to hold on to these because one will be used for scanout and >> >> > one >> >> > will be queued for the page flip. If we attach a third buffer then it >> >> > will be held by the compositor as a queue for the next flip. We are >> >> > assuming it won't have given this buffer to the GPU. Therefore if we >> >> > attach a fourth buffer it is easy for the compositor to immediately >> >> > release its lock on the third buffer and replace it with the fourth. >> >> > So >> >> > we can assume that the fourth attach will always generate an >> >> > immediate >> >> > release event. Sending a sync request will ensure that we always get >> >> > this release event. So if we have four buffer slots we can assume >> >> > that >> >> > one of the attaches will always generate an immediate release event. >> >> > >> >> > In the non-fullscreen case where we don't really need to wait for the >> >> > GPU, we only need 2 slots because the compositor wil
[PATCH xwayland] Set the view to NULL when unmapping an X11 window
Fixes a crash caused by accessing a deleted view in weston_wm_window_schedule_repaint. It can be easily reproduced by switching between menus in Firefox. Signed-off-by: Dima Ryazanov --- src/xwayland/window-manager.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c index b2776a0..5ee9480 100644 --- a/src/xwayland/window-manager.c +++ b/src/xwayland/window-manager.c @@ -902,6 +902,7 @@ weston_wm_handle_unmap_notify(struct weston_wm *wm, xcb_generic_event_t *event) wl_list_remove(&window->surface_destroy_listener.link); window->surface = NULL; window->shsurf = NULL; + window->view = NULL; xcb_unmap_window(wm->conn, window->frame_id); } @@ -2028,6 +2029,7 @@ surface_destroy(struct wl_listener *listener, void *data) Don't try to use it later. */ window->shsurf = NULL; window->surface = NULL; + window->view = NULL; } static struct weston_wm_window * -- 1.8.3.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Do any Web Layout Engines support Wayland yet?
Hi, I'm in the process of releasing a "demo" version of Chromium browser, aimed for developers only. You can follow the general development in here: https://01.org/ozone-wayland https://github.com/01org/ozone-wayland#introduction there's also Crosswalk application runtime based on Ozone-Wayland: https://lists.crosswalk-project.org/pipermail/crosswalk-dev/2013-October/000267.html you're welcome also to #ozone-wayland, so we can discuss more in there. Thanks! Tiago On 10/31/2013 11:30 PM, Stirling Westrup wrote: I am looking for any and all information on any Browsers that are native wayland clients (ie, not going through X) on Linux, and/or the web layout engines they are based on. Thanks in advance for any help. -- Stirling Westrup Programmer, Entrepreneur. https://www.linkedin.com/e/fpf/77228 http://www.linkedin.com/in/swestrup http://technaut.livejournal.com http://sourceforge.net/users/stirlingwestrup ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
