On Sun, Mar 18, 2012 at 05:07:11PM -0400, dar...@chaosreigns.com wrote:
>
> I suppose E would be get Nouveau, the open source Nvidia driver, to work
> well enough that the proprietary driver is completely unnecessary. That
> seems very challenging, with the complete lack of help from Nvidia.
In
On 03/27/2012 06:35 PM, Thiago Macieira wrote:
[...]
1) prelink refused to work on ELF modules with text relocations,
which excluded the NVidia libs outright
I'm using the --reloc-only option, which works fine even on our non-PIC
x86 binaries.
Prelinking helps with load time processing, but
On terça-feira, 27 de março de 2012 18.00.55, Pierre-Loup A. Griffais wrote:
> Hi Thiago,
>
> Thanks for your interest in the NVIDIA driver; please allow me to try to
> clarify the situation. You're right that we're not building with -fPIC for
> performance reasons, but that only applies to the x86
On terça-feira, 27 de março de 2012 22.32.13, Damián Nohales wrote:
> El 27/03/12 19:24, Thiago Macieira escribió:
> > I guess the toolkits would simply forego drawing the decoration when it
> > detects that the window is maximised.
>
> But this behaviour is not shell dependent? for example, in KDE
El 27/03/12 19:24, Thiago Macieira escribió:
> On terça-feira, 27 de março de 2012 19.16.34, Damián Nohales wrote:
>> Hi there!
>>
>> I have a question, simply curiosity.
>>
>> I'm sure you noticed the behaviour of window decorations in case of
>> Unity shell. I mean, when a window is maximized, th
Thiago Macieira wrote:
Maybe a protocol that allow to compositor to tell clients to
enable/disable decorations drawing, compositor should to use this
protocol when a client surface is maximized/unmaximized and clients
adapt the GUI in the best way depending on the case.
I don't think that's ne
Hi Thiago,
Thanks for your interest in the NVIDIA driver; please allow me to try to clarify
the situation. You're right that we're not building with -fPIC for performance
reasons, but that only applies to the x86 platform. No text relocations should
be present in our x86_64 libraries thanks to
On terça-feira, 27 de março de 2012 19.16.34, Damián Nohales wrote:
> Hi there!
>
> I have a question, simply curiosity.
>
> I'm sure you noticed the behaviour of window decorations in case of
> Unity shell. I mean, when a window is maximized, the decorations begins
> to form part of the top panel
The maximized client should draw the entire top menubar as part of it's
window, which extends all the way to the top of the screen.
The compositor may place some extra items (widgets and status
indicators) atop the window. They will appear correct if the client does
draw a menubar of the corre
Hi there!
I have a question, simply curiosity.
I'm sure you noticed the behaviour of window decorations in case of
Unity shell. I mean, when a window is maximized, the decorations begins
to form part of the top panel, showing in a different way respect to the
window.
How developers would implem
In times where Weston and client shells are started at the same time, this
makes debugging much more effective. It's [S] for server and [C] for clients,
so now you will see something like this:
[4231274.870][C] -> wl_disp...@1.sync(new id 10)
[4231275.040][S] wl_drm@9.authenticate(27)
[4231275.18
A couple of fixes were made: Weston tablet-shell needed to use weston_layer,
so the compositor could rebuild the surface list correctly when repainting;
homescreen and locking are using the widget + window abstration of toytoolkit;
and widget_set_redraw_handler are being set for widgets redraw.
Al
Just like device_added, now the routines to close the compositor and vt switch
leave are using the same code to remove a device.
This patch also closes properly a mtdev device, bug spotted by Christopher
Michael.
Signed-off-by: Tiago Vignatti
---
src/evdev.c | 46 +
On 03/27/2012 07:56 PM, Christopher Michael wrote:
Hi All,
Attached is a patch which fixes not closing the mt device when removing
all devices.
When we call evdev_remove_devices we loop all input_devices and remove
them, however is existing code if the device is a multi-touch device
then mtdev_
On Tue, 27 Mar 2012 17:36:34 +0300
Ander Conselvan de Oliveira wrote:
> Hi,
>
> This series implements a vfunc for configuring a surface after an
> attach. The idea is that we don't want the shell to meddle with
> some surfaces such as drag surfaces, so the shell map() and
> configure() code is
Hi All,
Attached is a patch which fixes not closing the mt device when removing
all devices.
When we call evdev_remove_devices we loop all input_devices and remove
them, however is existing code if the device is a multi-touch device
then mtdev_close_delete was never called. The attached patc
On Mon, Mar 26, 2012 at 12:37:04PM -0400, Darxus wrote:
I just pushed branches of xserver and the intel driver rebased to work
on xserver 1.12. Do you want to see if those work for you (aside from
the problem of the windows currently not showing up)? We'll update
the branches to xwayland-1.12 on
I also pushed these patches to
g...@github.com:anderco/wayland.git surface-attach-vfuncs
and
g...@github.com:anderco/weston.git surface-attach-vfuncs
Cheers,
Ander
On 03/27/2012 05:36 PM, Ander Conselvan de Oliveira wrote:
Hi,
This series implements a vfunc for configuring a
---
src/compositor.c |1 -
src/compositor.h |1 -
src/shell.c | 11 +++
3 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/compositor.c b/src/compositor.c
index 097117a..36096be 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -222,7 +222,6 @@ weston_s
This allows us to move the logic that calls shell->map() or
shell->configure() into shell while allowing it to be overriden for
surfaces that should not be handle by the shell, such as drag icons.
This patch adds a pointer function called configure to weston_surface,
moves the currsent surface_con
surface_attach() does two things: sets up a new buffer as the contents
of the given surface and then calls into shell so it can setup the
position of the surface and map it if necessary. However we do not want
the shell to meddle with some internal surfaces such as drag surfaces.
The intention of
That way we can get rid of the call to
weston_compositor_update_drag_surfaces() on shell->map().
---
src/compositor.c | 16
src/compositor.h |2 ++
src/shell.c |2 --
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/src/compositor.c b/src/compositor.c
For shm buffers, es->pitch is set using the stride of the buffer. If
the shell happened to set the surface width to something different than
the buffer width, the contents of the surface would be cropped on the
width during redraw. However, for non-shm surfaces, es->pitch was set to
the surface wid
---
src/compositor.c | 13 ++---
src/compositor.h |3 +++
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/compositor.c b/src/compositor.c
index 353bf21..63bed72 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -425,14 +425,21 @@ weston_surface_update_transf
---
src/compositor.c | 25 +
src/compositor.h |3 +++
src/shell.c |2 +-
3 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/src/compositor.c b/src/compositor.c
index 3b2ebd4..353bf21 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -418,7
Let the compositor use a listener to be notified when a new drag icon
is set up.
---
src/data-device.c|5 +
src/wayland-server.c |2 ++
src/wayland-server.h |1 +
3 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/data-device.c b/src/data-device.c
index 57f31ca.
Hi,
This series implements a vfunc for configuring a surface after an
attach. The idea is that we don't want the shell to meddle with some
surfaces such as drag surfaces, so the shell map() and configure()
code is moved into shell and it sets the appropriate vfunc for a
surface in wl_shell_get_she
Hi Kristian,
Any comments about this one? Weston just crashed on me again because of
this bug.
Thanks,
Ander
On 03/02/2012 03:45 PM, Ander Conselvan de Oliveira wrote:
Add a client parameter to wl_input_device_start_pointer_focus(). If
it is non-nil, if that client terminates while the grab
28 matches
Mail list logo
