On Tue, 11 Feb 2014 16:34:13 +0100
Rui Matos wrote:
> Destroying a wl_buffer that is still attached to a wl_surface is
> undefined behavior according to the wayland protocol. We should delay
> the destruction until we get the release event.
> ---
>
> So, I'm not sure why there was this comment s
On Tue, 11 Feb 2014 12:03:41 -0800
Bill Spitzak wrote:
> I think in absolute time you are right, the "P" points do not move.
> Instead everything else would move left by .5, resulting in the same
> image I described with the vertical arrows always tilting to the right.
>
> The green decision l
On Mon, Feb 10, 2014 at 04:52:32PM +0100, Emilio Pozuelo Monfort wrote:
> From: Emilio Pozuelo Monfort
>
> Clients that need to be redrawn when the focus changes do that by
> listening to focus_changed and scheduling a redraw.
>
> This was causing unnecessary redraws in the clients, as could be
On Mon, Feb 10, 2014 at 12:15:11PM +0900, Nobuhiko Tanibata wrote:
> Add description of key:shell to CORE SECTION and move a example of
> desktop-shell from key:modules to key:shell.
> Add cms-colord.so to key:modules of CORE SECTION.
>
> Signed-off-by: Nobuhiko Tanibata
LGTM
Reviewed-by: Bryce
I would greatly prefer if the demo Wayland compositor did not enforce
"active on top". This assumption is causing endless grief, it makes drag
& drop impossible and overlapping windows useless.
A lower window that wants a popup or transient should end up with the
popup or transient above any h
sardemff7+wayl...@sardemff7.net wrote:
I was suggesting that one method of minimizing multiple surfaces
would be for the client to arrange them all as children of one of
them and then minimize the parent. The primary purpose is so the
compositor/taskbar knows all those windows are "related", for
I think in absolute time you are right, the "P" points do not move.
Instead everything else would move left by .5, resulting in the same
image I described with the vertical arrows always tilting to the right.
The green decision lines move left by .5 to align with the "P" points
since the decis
On 11 February 2014 16:44, Axel Davy wrote:
> I have pending changes to this part to implement XWayland present support.
>
> Instead a having the wl_buffer attached to a window, I attach it to a
> pixmap.
>
> Could you test with this branch, and tell if you encounter the problems you
> have?
>
> h
Hi,
I have pending changes to this part to implement XWayland present support.
Instead a having the wl_buffer attached to a window, I attach it to a
pixmap.
Could you test with this branch, and tell if you encounter the problems
you have?
https://github.com/axeldavy/xserver/tree/xwayland-d
Destroying a wl_buffer that is still attached to a wl_surface is
undefined behavior according to the wayland protocol. We should delay
the destruction until we get the release event.
---
So, I'm not sure why there was this comment saying that it was safe to
do this, perhaps it was in an old protoc
Hi all,
I thought I'd share this with you, so you can start experimenting with
the presentation feedback extension. The Weston branch at
http://cgit.collabora.com/git/user/pq/weston.git/log/?h=presentation-RFCv2-feedback
implements the presentation feedback part and should be fully usable.
The que
On 11/02/2014 02:23, Bill Spitzak wrote:
May not have explained it correctly. It sounded like you were not
going to allow dialogs to be minimized except as a side-effect of
minimizing the parent.
I was, but I am not any more.
I certainly want to allow this! And I certainly want to support
mi
From: Emilio Pozuelo Monfort
Hi,
These two patches fix bug #74831 in two different ways. One of them,
originally written by Philip, positions the popup on top of all other
surfaces in the layer. That means that you can still end up with the
parent surface behind a second parent (as the comment i
From: Philip Withnall
Always put them as the top-most layer in the layer list of their parent.
This ensures that, for example, the popup menu produced by
right-clicking on a surface (which is not currently at the top of the
stacking order in the current workspace) is displayed at the top of the
s
From: Emilio Pozuelo Monfort
This fixes the bug that commit da704d was trying to fix, where a
popup would appear on top of its parent but behind other windows.
https://bugs.freedesktop.org/show_bug.cgi?id=74831
Signed-off-by: Emilio Pozuelo Monfort
---
desktop-shell/shell.c | 3 +++
1 file ch
On 7 February 2014 22:21, Bill Spitzak wrote:
> Okay, recompiling the newest xserver and mesa, and removing the "gallium"
> driver from mesa, has helped a *little*.
>
> X windows now show their correct contents initially, and redraw immediately
> in response to events.
>
> However the graphics are
On Mon, 10 Feb 2014 12:20:00 -0800
Bill Spitzak wrote:
> Pekka Paalanen wrote:
>
> > This algorithm aims to start showing an update between t-T/2 and t+T/2,
> > which means that presentation may occur a little early or late, with
> > an "average" of zero. Another option would be to show the upda
On Mon, 10 Feb 2014 09:23:12 -0600
Jason Ekstrand wrote:
> On Mon, Feb 10, 2014 at 3:53 AM, Pekka Paalanen wrote:
>
> > On Sat, 8 Feb 2014 15:23:29 -0600
> > Jason Ekstrand wrote:
> >
> > > Pekka,
> > > First off, I think you've done a great job over-all. I think it will
> > both
> > > cover
18 matches
Mail list logo
