Not having any luck getting the new xserver compiled.
It seems to require a newer mesa (due to missing symbols like
__DRI_ATTRIB_FLOAT) but I can't get that to compile. Mesa configure
fails with this:
./autogen.sh --prefix=$WLD --enable-gles2 --disable-gallium-egl
--with-egl-platforms=waylan
On Wed, Dec 18, 2013 at 08:56:20PM -0600, Jason Ekstrand wrote:
> In order to keep from overloading the debug handler, we first squash the
> entire message into a string and call wl_debug once.
>
> Signed-off-by: Jason Ekstrand
> ---
> src/connection.c | 54
> --
On Wed, Feb 05, 2014 at 09:38:27PM -0600, Jason Ekstrand wrote:
> ---
> Makefile.am | 1 +
> 1 file changed, 1 insertion(+)
Thanks... I hope that's the last of it...
Kristian
> diff --git a/Makefile.am b/Makefile.am
> index 21b2b17..5e8556b 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -4
Creates an empty context that is not hooked up to a device. Callers can then
add and remove devices to this context using libinput_path_add_device() and
libinput_path_remove_device().
Signed-off-by: Peter Hutterer
---
src/libinput.h | 19 ++-
src/path.c | 29 +++
Maintain proper namespacing rename the backend-specific calls to
libinput__
Signed-off-by: Peter Hutterer
---
src/libinput.h | 10 +-
src/udev-seat.c | 8
test/udev.c | 28 ++--
tools/event-debug.c | 2 +-
4 files changed, 24 in
The previous path backend created a libinput context attached to a single
device. This is insufficient when we need to use cross-device functionality.
One example of this cross-device functionality include disabling a touchpad
while the trackstick is in use (Lenovo T440 and related models).
This p
This allows multiple devices to share a single libinput context. The new
function returns the newly added device immediately. Unlike the udev seat
where devices may or may not be added - over the lifetime of the seat - a
path-based backend knows immediately if device exists or doesn't exist.
Retur
Signed-off-by: Peter Hutterer
---
test/path.c | 317
1 file changed, 317 insertions(+)
diff --git a/test/path.c b/test/path.c
index 3aade76..59d3e5f 100644
--- a/test/path.c
+++ b/test/path.c
@@ -252,6 +252,25 @@ START_TEST(path_add_de
This patchset revamps the path backend to allow for more than one path-based
device per context. I thought the initial approach of having one context per
device is sufficient but there are a few use-cases that can really only be
solved by having libinput control all devices. A common example is di
This enables us to prevent callers from calling backend-specific functions on
mismatching backends.
Signed-off-by: Peter Hutterer
---
src/libinput-private.h | 6 ++
src/path.c | 1 +
src/udev-seat.c| 1 +
3 files changed, 8 insertions(+)
diff --git a/src/libinput-private
---
Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile.am b/Makefile.am
index 21b2b17..5e8556b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -485,6 +485,7 @@ weston_nested_CFLAGS = $(CLIENT_CFLAGS)
weston_nested_client_SOURCES = clients/nested-client.c
weston_nested_clien
On Wed, Jan 29, 2014 at 06:47:53PM +0200, Ander Conselvan de Oliveira wrote:
> Different parts of the shell, such as the workspace implementation,
> rely on making layers invisible to hide surfaces without discarding
> the order in which they appear. However, the layers are made
> invisible by remo
On Thu, Jan 30, 2014 at 01:49:39PM +0100, poch...@gmail.com wrote:
> From: Emilio Pozuelo Monfort
>
> Unfocusing a surface should dim it when dim-layer is enabled,
> but this got broken in commit 83ffd9.
Fix committed, thanks.
Kristian
> ---
> desktop-shell/shell.c | 8
> 1 file chan
On Mon, Feb 03, 2014 at 04:57:27PM +0100, poch...@gmail.com wrote:
> From: Emilio Pozuelo Monfort
>
> The input initialization code assumes the outputs have already
> been initialized; thus create the outputs first. This fixes a
> segfault upon startup. It is also what the drm and fbdev backends
On Tue, Feb 04, 2014 at 02:21:48PM +, Neil Roberts wrote:
> The previous implementation of the wl_container_of macro was
> dereferencing the sample pointer in order to get an address of the
> member to calculate the offset. Ideally this shouldn't cause any
> problems because the dereference doe
On Mon, Feb 03, 2014 at 09:37:06PM +, Bryce W. Harrington wrote:
>
> Signed-off-by: Bryce Harrington
Thanks Bryce, committed.
Kristian
> ---
> README |5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/README b/README
> index b3be4c9..3821e5d 100644
> --- a/RE
On Tue, Feb 04, 2014 at 09:36:38PM -0600, Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand
> ---
> No change from previous version. Just resending to keep things together.
Thanks Jason, both patches applied.
Kristian
>
> src/gl-renderer.c | 110
> +++
The client needs to know that the pointer is at a different position in
its surface. We can't send motion as that corresponds to the pointer
actually moving. Leaving the surface and entering at the new position
is a better semantic match and doesn't correspond to pointer motion
or user input.
ht
Re-send to include the wayland and mesa mailing lists.
Sorry for the noise
Original Message
Subject:[GSoC2014] Call for projects ideas and mentors
Date: Thu, 06 Feb 2014 01:03:05 +0100
From: Martin Peres
To: dri-de...@lists.freedesktop.org ,
xorg-de...@lists.x.or
evdev_device_remove() already calls close(device->fd). Move the
close_restricted call there to avoid one privileged call in the backend and
one in the device. And move the open_restricted() into the evdev device too to
reduce the duplicated code in the two backends.
Update to one of the tests: sin
On Tue, Feb 04, 2014 at 07:22:33AM +1000, Peter Hutterer wrote:
> evdev_device_remove() already calls close(device->fd). Move the
> close_restricted call there to avoid one privileged call in the backend and
> one in the device.
Now we have open_restricted in path.c, udev-seat.c, and close_restric
Your bug is likely to be coming from the combination old XWayland/
recent Weston.
Try with main xwayland branch and xf86-video-wayland (forget about the
outdated things you built)
Xwayland is divided in two parts: the Xwayland window manager (weston)
and ... Xwayland (in the Xserver)
Axel
You want to be using the "xwayland" branch of Xorg, not "xwayland-1.12".
That explains why everything was showing up black: xwayland-1.12 is almost
a year old, and Weston doesn't work with it anymore.
Make sure to build xf86-video-wayland, and uninstall xf86-video-wlshm.
wlshm is old. You should j
On 02/05/2014 09:21 AM, Jasper St. Pierre wrote:
What compositor are you using
The X11 compositor you get when you run wayland under X.
My X system is stock Ubuntu running Unity, though I suspect that has
little to do with it.
and how did you build Xwayland?
There is "xwayland" inside we
What compositor are you using, and how did you build Xwayland? Did you
build xf86-video-wayland as well?
On Wed, Feb 5, 2014 at 12:18 PM, Bill Spitzak wrote:
> I was wondering if my problem is not something anybody else is seeing.
>
> I have Wayland X11 compositor running. This is on an Nvidia
I was wondering if my problem is not something anybody else is seeing.
I have Wayland X11 compositor running. This is on an Nvidia card with
Nvidia drivers and therefore only SHM clients work. All other Wayland
apps either work correctly or they fail immediately because they require
EGL.
All
26 matches
Mail list logo
