From: Giovanni Campagna
Fix the array name to actually compile, and fix the driver name
with the new upstream.
---
hw/xfree86/common/xf86AutoConfig.c | 2 +-
hw/xfree86/common/xf86Config.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/common
From: Giovanni Campagna
This makes sure that all defines in the public headers (in
particular XORG_WAYLAND) are visible to source files that
only include xorg-config.h
---
include/xorg-config.h.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/xorg-config.h.in b/include/xorg
From: Giovanni Campagna
Drop xf86InitialConfiguration, which just gets in the way
of the compositor doing its own output arrangement, and transform
wayland events into the appropriate low-level xf86 calls to
keep the screen size updated.
Kristian: after the rebase it was crashing for me too
Avoids a warning due to drmGetMaster and a crash with multimonitor,
caused by not having an intel_mode.
---
src/intel_driver.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/intel_driver.c b/src/intel_driver.c
index d1da72d..b7702e6 100644
--- a/src/intel_driver.c
+++ b/src/intel_dr
From: Giovanni Campagna
Drop xf86InitialConfiguration, which just gets in the way
of the compositor doing its own output arrangement, and transform
wayland events into the appropriate low-level xf86 calls to
keep the screen size updated.
---
hw/xfree86/xwayland/xwayland-output.c | 68
From: Giovanni Campagna
Certain global objects, such as outputs, can be destroyed during
the session. We must handle that and not crash.
---
hw/xfree86/xwayland/xwayland-drm.c | 7 ++
hw/xfree86/xwayland/xwayland-input.c | 7 ++
hw/xfree86/xwayland/xwayland-output.c | 40
From: Giovanni Campagna
If the window is using a 24 bit visual, we must request a buffer
format without alpha, or garbage is rendered.
---
hw/xfree86/xwayland/xwayland.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/hw/xfree86/xwayland/xwayland.c b/hw/xfree86/xwayland
Il giorno mer, 14/09/2011 alle 11.24 -0700, Bill Spitzak ha scritto:
> Giovanni Campagna wrote:
>
> > Why isn't transient for + window type (like _NET_WM_WINDOW_TYPE) enough?
>
> Because it does not allow *MULTIPLE* parents.
>
> In gimp if you have 2 image wind
Il giorno mer, 14/09/2011 alle 10.37 -0700, Bill Spitzak ha scritto:
>
> Giovanni Campagna wrote:
> > Il giorno lun, 12/09/2011 alle 13.18 -0700, Bill Spitzak ha scritto:
> >> There seems to be some confusion between negotiating the correct size
> >> and the d
Il giorno lun, 12/09/2011 alle 13.18 -0700, Bill Spitzak ha scritto:
> There seems to be some confusion between negotiating the correct size
> and the drawing of the frame. These are unrelated.
>
> I mostly agree with your ideas of negotiating the size with both a
> request from the client->comp
Il giorno mer, 14/09/2011 alle 21.56 +0800, Sam Spilsbury ha scritto:
> On Wed, Sep 14, 2011 at 12:13 PM, Bill Spitzak wrote:
> > Along with all the discussion about client-side decorations, there is also a
> > need for client-side window stacking and mapping.
> >
> > In current window managers it
Il giorno mar, 13/09/2011 alle 21.13 -0700, Bill Spitzak ha scritto:
> Along with all the discussion about client-side decorations, there is
> also a need for client-side window stacking and mapping.
>
> In current window managers it is almost impossible to make
> multiple-window complex applica
Il giorno ven, 09/09/2011 alle 10.55 -0700, Bill Spitzak ha scritto:
> Giovanni Campagna wrote:
>
> > Anyway, I'm not convinced that client-side decorations are technically
> > superior, therefore I'll start a new thread, to have a final discussion
> > with al
Il giorno gio, 08/09/2011 alle 16.55 -0700, Bill Spitzak ha scritto:
> Giovanni Campagna wrote:
>
> > Yes, but in the middle of this is policy. If the originator of a resize
> > is not the user, how the application can know that the new size is good?
> > We need some w
Il giorno ven, 09/09/2011 alle 09.30 +0200, Benjamin Franzke ha scritto:
> 2011/9/9 Giovanni Campagna :
> > Il giorno gio, 08/09/2011 alle 17.36 -0400, Matthias Clasen ha scritto:
> >> On Thu, 2011-09-08 at 22:35 +0200, Giovanni Campagna wrote:
> >>
> >> >
&
Il giorno gio, 08/09/2011 alle 17.36 -0400, Matthias Clasen ha scritto:
> On Thu, 2011-09-08 at 22:35 +0200, Giovanni Campagna wrote:
>
> >
> > Probably I forgot to mention, but at the Desktop Summit it was agreed
> > that client-side decorations won't happen, neith
Il giorno gio, 08/09/2011 alle 16.32 -0400, Kristian Høgsberg ha
scritto:
> 2011/9/8 Giovanni Campagna :
>>[...]
>>
> > I have nothing
> > against having GDK calling wl_egl_window_resize,
> > cairo_gl_surface_set_size, cogl_onscreen_update_size, etc. as part of
>
Il giorno gio, 08/09/2011 alle 12.45 -0700, Bill Spitzak ha scritto:
> Kristian Høgsberg wrote:
>
> >> You want a concrete example? Consider edge tiling: in that mode, the
> >> window is not resizable, and attempts to programmatically resize it
> >> should be cached and reapplied when the window i
Il giorno gio, 08/09/2011 alle 14.31 -0400, Kristian Høgsberg ha
scritto:
> 2011/9/7 Giovanni Campagna :
> > [...]
> >
> > You say it: "it's more important that clients always know exactly that
> > the buffer size of the EGLSurface they're rendering to
Il giorno mer, 07/09/2011 alle 14.07 -0400, Kristian Høgsberg ha
scritto:
> 2011/9/7 Giovanni Campagna :
> > Il giorno mar, 06/09/2011 alle 22.54 -0400, Kristian Høgsberg ha
> > scritto:
>>
>>[...]
>>
> >> Finally, wl_shell is far from complete. It'
Il giorno mer, 07/09/2011 alle 16.35 -0400, Kristian Høgsberg ha
scritto:
> On Wed, Sep 7, 2011 at 4:27 PM, Giovanni Campagna
> wrote:
> > Il giorno mer, 07/09/2011 alle 10.33 -0700, Bill Spitzak ha scritto:
> >> In Wayland the client allocates the buffer, not the composit
Il giorno mer, 07/09/2011 alle 14.07 -0400, Kristian Høgsberg ha
scritto:
> 2011/9/7 Giovanni Campagna :
> > Il giorno mar, 06/09/2011 alle 22.54 -0400, Kristian Høgsberg ha
> > scritto:
> >> 2011/9/6 Giovanni Campagna :
> >> > Il giorno mar, 06/09/2011 al
Il giorno mer, 07/09/2011 alle 10.33 -0700, Bill Spitzak ha scritto:
> In Wayland the client allocates the buffer, not the compositor.
>
> I think this is what is leading to the confusion here. The compositor
> has no say over how big the buffer is. Instead the client controls it
> and tells the
Il giorno mar, 06/09/2011 alle 22.54 -0400, Kristian Høgsberg ha
scritto:
> 2011/9/6 Giovanni Campagna :
> > Il giorno mar, 06/09/2011 alle 17.31 -0400, Kristian Høgsberg ha
> > scritto:
> ...
> >> Maybe you should introduce yourself and what you're working on
Il giorno mar, 06/09/2011 alle 23.30 -0400, Kristian Høgsberg ha
scritto:
> On Tue, Sep 6, 2011 at 6:39 PM, Giovanni Campagna
> wrote:
> > Il giorno mar, 06/09/2011 alle 15.27 -0700, Bill Spitzak ha scritto:
> >> Giovanni Campagna wrote:
> >>
> >> > Yo
Il giorno mar, 06/09/2011 alle 15.27 -0700, Bill Spitzak ha scritto:
> Giovanni Campagna wrote:
>
> > You can do instantaneous updates even if the size is determined by the
> > compositor, rather than the client: you just wait for the client to
> > prepare a new buffer bef
Il giorno mar, 06/09/2011 alle 17.31 -0400, Kristian Høgsberg ha
scritto:
> On Tue, Sep 6, 2011 at 5:19 PM, Giovanni Campagna
> wrote:
> > Il giorno mar, 06/09/2011 alle 13.11 -0700, Bill Spitzak ha scritto:
> >> I believe that unless the client has final say, and an unamb
Il giorno mar, 06/09/2011 alle 16.37 -0400, Kristian Høgsberg ha
scritto:
> On Tue, Sep 6, 2011 at 4:11 PM, Bill Spitzak wrote:
> > I believe that unless the client has final say, and an unambiguous method to
> > force a window to any dimension it wants, then Wayland is a failure. Please
> > do no
Il giorno mar, 06/09/2011 alle 13.11 -0700, Bill Spitzak ha scritto:
> I believe that unless the client has final say, and an unambiguous
> method to force a window to any dimension it wants, then Wayland is a
> failure. Please do not copy the asynchronous window management of X11!
>
> Here is w
Currently, moving and resizing a window works with two requests (move
and resize), that are only concerned with starting WM operations, and
one event (configure), which is only emitted if the WM itself is
resizing the window, and toolkits are allowed to ignore.
This results, at least in libtoytoolk
30 matches
Mail list logo
