Xserver errors

2014-02-05 Thread Bill Spitzak 

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 X windows show initially as completely black, including all the area 
for the shadows. The X application is responding to clicks and redrawing 
(tested by printing messages to stdout, which appear in the Wayland 
terminal), but the surface remains completely black. Moving the cursor 
around shows the cursor changes correctly when it hovers over the resize 
edges and corners.


In the most recent version of Wayland I can then resize the window and 
then it displays, but with several errors in the window borders and 
shadow, shown in the attached screen shot. This display updates but all 
changes are deferred until the next event (for instance if I push a 
button it does not redraw as pushed-in until I move the mouse and send a 
drag event). Again print statements reveal that my client is getting the 
expose event and drawing, it's just that the surface does not update, 
perhaps the commit has not been sent?


As nobody else seems to think there is a problem with Xserver, my best 
guess is that Xwayland is trying to use SHM but it has bugs, while EGL 
works? Another possibility is that Xwayland is broken under X11 
compostior but works on hardware backends? As I am unable to test either 
of these I cannot tell where the problem may lie.


If it is indeed either SHM or X11 compositor that is at fault, is this 
something I should work on trying to fix?
attachment: xevInXWaylandOnX11.png___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Xserver errors

2014-02-05 Thread Jasper St. Pierre 
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 spit...@gmail.com 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 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 X windows show initially as completely black, including all the area
 for the shadows. The X application is responding to clicks and redrawing
 (tested by printing messages to stdout, which appear in the Wayland
 terminal), but the surface remains completely black. Moving the cursor
 around shows the cursor changes correctly when it hovers over the resize
 edges and corners.

 In the most recent version of Wayland I can then resize the window and
 then it displays, but with several errors in the window borders and shadow,
 shown in the attached screen shot. This display updates but all changes are
 deferred until the next event (for instance if I push a button it does not
 redraw as pushed-in until I move the mouse and send a drag event). Again
 print statements reveal that my client is getting the expose event and
 drawing, it's just that the surface does not update, perhaps the commit has
 not been sent?

 As nobody else seems to think there is a problem with Xserver, my best
 guess is that Xwayland is trying to use SHM but it has bugs, while EGL
 works? Another possibility is that Xwayland is broken under X11 compostior
 but works on hardware backends? As I am unable to test either of these I
 cannot tell where the problem may lie.

 If it is indeed either SHM or X11 compositor that is at fault, is this
 something I should work on trying to fix?

 ___
 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: Xserver errors

2014-02-05 Thread Bill Spitzak 

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 weston. Weston I am using the main branch, 
and I configure and compile and install it with:


./autogen.sh --prefix=$HOME/install --disable-setuid-install 
--disable-colord

make
make install

xserver: I am using the xwayland-1.12 branch from 
git://anongit.freedesktop.org/xorg/xserver. Configure/make/install is:


./autogen.sh --prefix=$HOME/install
make
make install

Also I am compiling/installing xserver after xwayland, not sure if this 
is the correct order.


I am rather mystified as to why there is both an xserver and xwayland 
code in weston, any quick explanation would be appreciated.



Did you
build xf86-video-wayland as well?


No, only xf86-video-ati, xf86-video-intel, xf86-video-wlshm. I had to 
compile tons of stuff in order to get xserver to compile, which is 
really annoying. Most of it I suspect is never used.


If I add this, how do I tell the Xserver that it exists? Do I just have 
to install it, or do I have to recomfigure and recompile Xserver?


I am also dubious that this has anything to do with it, as my test 
applications are not using xv.



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Xserver errors

2014-02-05 Thread Jasper St. Pierre 
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 just be able to just install xf86-video-wayland
and have everything work.


On Wed, Feb 5, 2014 at 12:46 PM, Bill Spitzak spit...@gmail.com wrote:

 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 weston. Weston I am using the main branch, and
 I configure and compile and install it with:

 ./autogen.sh --prefix=$HOME/install --disable-setuid-install
 --disable-colord
 make
 make install

 xserver: I am using the xwayland-1.12 branch from git://
 anongit.freedesktop.org/xorg/xserver. Configure/make/install is:

 ./autogen.sh --prefix=$HOME/install
 make
 make install

 Also I am compiling/installing xserver after xwayland, not sure if this is
 the correct order.

 I am rather mystified as to why there is both an xserver and xwayland code
 in weston, any quick explanation would be appreciated.


  Did you
 build xf86-video-wayland as well?


 No, only xf86-video-ati, xf86-video-intel, xf86-video-wlshm. I had to
 compile tons of stuff in order to get xserver to compile, which is really
 annoying. Most of it I suspect is never used.

 If I add this, how do I tell the Xserver that it exists? Do I just have to
 install it, or do I have to recomfigure and recompile Xserver?

 I am also dubious that this has anything to do with it, as my test
 applications are not using xv.





-- 
  Jasper
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Xserver errors

2014-02-05 Thread Axel Davy 
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 Davy

Le 05/02/2014 18:46, Bill Spitzak a écrit :

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 weston. Weston I am using the main branch, 
and I configure and compile and install it with:


./autogen.sh --prefix=$HOME/install --disable-setuid-install 
--disable-colord

make
make install

xserver: I am using the xwayland-1.12 branch from 
git://anongit.freedesktop.org/xorg/xserver. Configure/make/install is:


./autogen.sh --prefix=$HOME/install
make
make install

Also I am compiling/installing xserver after xwayland, not sure if 
this is the correct order.


I am rather mystified as to why there is both an xserver and xwayland 
code in weston, any quick explanation would be appreciated.



Did you
build xf86-video-wayland as well?


No, only xf86-video-ati, xf86-video-intel, xf86-video-wlshm. I had to 
compile tons of stuff in order to get xserver to compile, which is 
really annoying. Most of it I suspect is never used.


If I add this, how do I tell the Xserver that it exists? Do I just 
have to install it, or do I have to recomfigure and recompile Xserver?


I am also dubious that this has anything to do with it, as my test 
applications are not using xv.



___
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

[PATCH v2 libinput 2/4] Move opening and closing the device fd into evdev.c

2014-02-05 Thread Peter Hutterer 
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: since we'd now fail getting the device node from
the invalid /tmp path, the open_func_count is 0.

Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Changes to v1:
- move open_restricted into evdev_device_create()

If we really get an fd open failure, we now get two error messages, but I'll
fix that up in a follow-up restructure.

 src/evdev.c | 18 +++---
 src/evdev.h |  3 +--
 src/path.c  | 14 +-
 src/udev-seat.c | 20 +---
 test/path.c |  2 +-
 5 files changed, 19 insertions(+), 38 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index 2bc301b..61ab083 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -600,12 +600,22 @@ evdev_configure_device(struct evdev_device *device)
 struct evdev_device *
 evdev_device_create(struct libinput_seat *seat,
const char *devnode,
-   const char *sysname,
-   int fd)
+   const char *sysname)
 {
struct libinput *libinput = seat-libinput;
struct evdev_device *device;
char devname[256] = unknown;
+   int fd;
+
+   /* Use non-blocking mode so that we can loop on read on
+* evdev_device_data() until all events on the fd are
+* read.  mtdev_get() also expects this. */
+   fd = open_restricted(libinput, devnode, O_RDWR | O_NONBLOCK);
+   if (fd  0) {
+   log_info(opening input device '%s' failed (%s).\n,
+devnode, strerror(-fd));
+   return NULL;
+   }
 
device = zalloc(sizeof *device);
if (device == NULL)
@@ -655,6 +665,8 @@ evdev_device_create(struct libinput_seat *seat,
return device;
 
 err:
+   if (fd = 0)
+   close_restricted(libinput, fd);
evdev_device_destroy(device);
return NULL;
 }
@@ -710,7 +722,7 @@ evdev_device_remove(struct evdev_device *device)
 
if (device-mtdev)
mtdev_close_delete(device-mtdev);
-   close(device-fd);
+   close_restricted(device-base.seat-libinput, device-fd);
list_remove(device-base.link);
 
notify_removed_device(device-base);
diff --git a/src/evdev.h b/src/evdev.h
index 37c32e5..3c9f93a 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -118,8 +118,7 @@ struct evdev_dispatch {
 struct evdev_device *
 evdev_device_create(struct libinput_seat *seat,
const char *devnode,
-   const char *sysname,
-   int fd);
+   const char *sysname);
 
 struct evdev_dispatch *
 evdev_touchpad_create(struct evdev_device *device);
diff --git a/src/path.c b/src/path.c
index 2893ad4..2254bbe 100644
--- a/src/path.c
+++ b/src/path.c
@@ -42,7 +42,6 @@ path_input_disable(struct libinput *libinput)
struct evdev_device *device = input-device;
 
if (device) {
-   close_restricted(libinput, device-fd);
evdev_device_remove(device);
input-device = NULL;
}
@@ -122,22 +121,13 @@ path_input_enable(struct libinput *libinput)
struct evdev_device *device;
const char *devnode = input-path;
char *sysname;
-   int fd;
char *seat_name, *seat_logical_name;
 
if (input-device)
return 0;
 
-   fd = open_restricted(libinput, devnode, O_RDWR|O_NONBLOCK);
-   if (fd  0) {
-   log_info(opening input device '%s' failed (%s).\n,
-devnode, strerror(-fd));
-   return -1;
-   }
-
if (path_get_udev_properties(devnode, sysname,
 seat_name, seat_logical_name) == -1) {
-   close_restricted(libinput, fd);
log_info(failed to obtain sysname for device '%s'.\n, 
devnode);
return -1;
}
@@ -146,16 +136,14 @@ path_input_enable(struct libinput *libinput)
free(seat_name);
free(seat_logical_name);
 
-   device = evdev_device_create(seat-base, devnode, sysname, fd);
+   device = evdev_device_create(seat-base, devnode, sysname);
free(sysname);
libinput_seat_unref(seat-base);
 
if (device == EVDEV_UNHANDLED_DEVICE) {
-   close_restricted(libinput, fd);
log_info(not using input device '%s'.\n, devnode);
return -1;
} else if (device == NULL) {
-   close_restricted(libinput, fd);
log_info(failed to create input device '%s'.\n, devnode);
return -1;
}
diff --git a/src/udev-seat.c b/src/udev-seat.c
index 5936511..957e762 100644
--- a/src/udev-seat.c
+++ b/src/udev-seat.c
@@ -44,13 +44,11 @@

[PATCH] input: Send leave and enter pair when the surface moves under the cursor

2014-02-05 Thread Kristian Høgsberg 
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.

https://bugs.freedesktop.org/show_bug.cgi?id=71927
---
 src/compositor.h |  1 +
 src/input.c  | 28 
 2 files changed, 17 insertions(+), 12 deletions(-)

We've discussed this in the past and I finally wrote the code.  It works as
expected and fixes the bug linked above where the cursor becomes stale when
we maximize a surface and the pointer ends up at a different position.

The one things missing from this patch is handling the implicit grab.  If
there's an implicit grab (a button pressed and held in the surface) we can
leave, but we always have to enter with 0 buttons pressed.  This means that
we have to wait for the buttons to be released before we send the enter.

Should be simple enough to do, but I wanted to send this out as an RFC to
see if we have consensus on the expected behavior.

Kristian

diff --git a/src/compositor.h b/src/compositor.h
index ced792f..b9fca91 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -328,6 +328,7 @@ struct weston_pointer {
uint32_t grab_time;
 
wl_fixed_t x, y;
+   wl_fixed_t sx, sy;
uint32_t button_count;
 
struct wl_listener output_destroy_listener;
diff --git a/src/input.c b/src/input.c
index e20c870..26afd65 100644
--- a/src/input.c
+++ b/src/input.c
@@ -157,7 +157,7 @@ default_grab_pointer_focus(struct weston_pointer_grab *grab)
   pointer-x, pointer-y,
   sx, sy);
 
-   if (pointer-focus != view)
+   if (pointer-focus != view || pointer-sx != sx || pointer-sy != sy)
weston_pointer_set_focus(pointer, view, sx, sy);
 }
 
@@ -166,18 +166,19 @@ default_grab_pointer_motion(struct weston_pointer_grab 
*grab, uint32_t time,
wl_fixed_t x, wl_fixed_t y)
 {
struct weston_pointer *pointer = grab-pointer;
-   wl_fixed_t sx, sy;
struct wl_list *resource_list;
struct wl_resource *resource;
 
+   if (pointer-focus)
+   weston_view_from_global_fixed(pointer-focus, x, y,
+ pointer-sx, pointer-sy);
+
weston_pointer_move(pointer, x, y);
 
-   if (pointer-focus)
-   weston_view_from_global_fixed(pointer-focus,
- pointer-x, pointer-y, sx, sy);
resource_list = pointer-focus_resource_list;
wl_resource_for_each(resource, resource_list) {
-   wl_pointer_send_motion(resource, time, sx, sy);
+   wl_pointer_send_motion(resource, time,
+  pointer-sx, pointer-sy);
}
 }
 
@@ -614,16 +615,17 @@ weston_pointer_set_focus(struct weston_pointer *pointer,
struct wl_display *display = pointer-seat-compositor-wl_display;
uint32_t serial;
struct wl_list *focus_resource_list;
-   int different_surface = 0;
+   int refocus = 0;
 
if ((!pointer-focus  view) ||
(pointer-focus  !view) ||
-   (pointer-focus  pointer-focus-surface != view-surface))
-   different_surface = 1;
+   (pointer-focus  pointer-focus-surface != view-surface) ||
+   pointer-sx != sx || pointer-sy != sy)
+   refocus = 1;
 
focus_resource_list = pointer-focus_resource_list;
 
-   if (!wl_list_empty(focus_resource_list)  different_surface) {
+   if (!wl_list_empty(focus_resource_list)  refocus) {
serial = wl_display_next_serial(display);
wl_resource_for_each(resource, focus_resource_list) {
wl_pointer_send_leave(resource, serial,
@@ -633,8 +635,7 @@ weston_pointer_set_focus(struct weston_pointer *pointer,
move_resources(pointer-resource_list, focus_resource_list);
}
 
-   if (find_resource_for_view(pointer-resource_list, view) 
-   different_surface) {
+   if (find_resource_for_view(pointer-resource_list, view)  refocus) {
struct wl_client *surface_client =
wl_resource_get_client(view-surface-resource);
 
@@ -672,6 +673,9 @@ weston_pointer_set_focus(struct weston_pointer *pointer,
 
pointer-focus = view;
pointer-focus_view_listener.notify = pointer_focus_view_destroyed;
+   pointer-sx = sx;
+   pointer-sy = sy;
+
wl_signal_emit(pointer-focus_signal, pointer);
 }
 
-- 
1.8.4.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] README: Fix typo; add link to testing docs

2014-02-05 Thread Kristian Høgsberg 
On Mon, Feb 03, 2014 at 09:37:06PM +, Bryce W. Harrington wrote:
 
 Signed-off-by: Bryce Harrington b.harring...@samsung.com

Thanks Bryce, committed.

Kristian

 ---
  README |5 -
  1 file changed, 4 insertions(+), 1 deletion(-)
 
 diff --git a/README b/README
 index b3be4c9..3821e5d 100644
 --- a/README
 +++ b/README
 @@ -11,5 +11,8 @@ shell.  Finally, weston also provides integration with the 
 Xorg server
  and can pull X clients into the Wayland desktop and act as a X window
  manager.
  
 -Refer to http://wayland.freedesktop.org/building.html for buiding
 +Refer to http://wayland.freedesktop.org/building.html for building
  weston and its dependencies.
 +
 +The test suite can be invoked via `make check`; see
 +http://wayland.freedesktop.org/testing.html for additional details.
 -- 
 1.7.9.5
 ___
 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

Re: [PATCH] Don't deref the sample pointer in the wl_container_of macro

2014-02-05 Thread Kristian Høgsberg 
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 doesn't actually cause the address to
 be read from so it shouldn't matter if the pointer is uninitialised.
 However this is probably technically invalid and could cause undefined
 behavior. Clang appears to take advantage of this undefined behavior
 and doesn't bother doing the subtraction. It also gives a warning when
 it does this.
 
 The documentation for wl_container_of implies that it should only be
 given an initialised pointer and if that is done then there is no
 problem with clang. However this is quite easy to forget and doesn't
 cause any problems or warnings with gcc so it's quite easy to
 accidentally break clang.
 
 To fix the problem this changes the macro to use pointer -
 offsetof(__typeof__(sample), member) so that it doesn't need to deref
 the sample pointer. This does however require that the __typeof__
 operator is supported by the compiler. In practice we probably only
 care about gcc and clang and both of these happily support the
 operator.
 
 The previous implementation was also using __typeof__ but it had a
 fallback path avoiding it when the operator isn't available. The
 fallback effectively has undefined behaviour and it is targetting
 unknown compilers so it is probably not a good idea to leave it in.
 Instead, this patch just removes it. If someone finds a compiler that
 doesn't have __typeof__ but does work with the old implementation then
 maybe they could add it back in as a special case.
 
 This patch removes the initialisation anywhere where the sample
 pointer was being unitialised before using wl_container_of. The
 documentation for the macro has also been updated to specify that this
 is OK.

Thanks, that's nice.  Patch applied.

Kristian
 ---
  src/wayland-server.c |  2 +-
  src/wayland-server.h |  2 +-
  src/wayland-util.h   | 30 +-
  3 files changed, 15 insertions(+), 19 deletions(-)
 
 diff --git a/src/wayland-server.c b/src/wayland-server.c
 index 489b99d..294497d 100644
 --- a/src/wayland-server.c
 +++ b/src/wayland-server.c
 @@ -571,7 +571,7 @@ wl_resource_get_link(struct wl_resource *resource)
  WL_EXPORT struct wl_resource *
  wl_resource_from_link(struct wl_list *link)
  {
 - struct wl_resource *resource = NULL;
 + struct wl_resource *resource;
  
   return wl_container_of(link, resource, link);
  }
 diff --git a/src/wayland-server.h b/src/wayland-server.h
 index 3fcaaf6..7fc5b47 100644
 --- a/src/wayland-server.h
 +++ b/src/wayland-server.h
 @@ -162,7 +162,7 @@ wl_client_post_no_memory(struct wl_client *client);
   * \code
   * void your_listener(struct wl_listener *listener, void *data)
   * {
 - *   struct your_data *data = NULL;
 + *   struct your_data *data;
   *
   *   your_data = wl_container_of(listener, data, your_member_name);
   * }
 diff --git a/src/wayland-util.h b/src/wayland-util.h
 index 68d91e2..57764d9 100644
 --- a/src/wayland-util.h
 +++ b/src/wayland-util.h
 @@ -135,7 +135,7 @@ void wl_list_insert_list(struct wl_list *list, struct 
 wl_list *other);
   *
   * void example_container_destroy(struct wl_listener *listener, void *data)
   * {
 - * struct example_container *ctr = NULL;
 + * struct example_container *ctr;
   *
   * ctr = wl_container_of(listener, ctr, destroy_listener);
   * \comment{destroy ctr...}
 @@ -144,44 +144,40 @@ void wl_list_insert_list(struct wl_list *list, struct 
 wl_list *other);
   *
   * \param ptr A valid pointer to the contained item.
   *
 - * \param sample A pointer to the type of content that the list item stores.
 - * Sample does not need be a valid pointer; a null pointer will suffice.
 + * \param sample A pointer to the type of content that the list item
 + * stores. Sample does not need be a valid pointer; a null or
 + * an uninitialised pointer will suffice.
   *
   * \param member The named location of ptr within the sample type.
   *
   * \return The container for the specified pointer.
   */
 -#ifdef __GNUC__
  #define wl_container_of(ptr, sample, member) \
 - (__typeof__(sample))((char *)(ptr)  -   \
 -  ((char *)(sample)-member - (char *)(sample)))
 -#else
 -#define wl_container_of(ptr, sample, member) \
 - (void *)((char *)(ptr)  -   \
 -  ((char *)(sample)-member - (char *)(sample)))
 -#endif
 + (__typeof__(sample))((char *)(ptr) -\
 +  offsetof(__typeof__(*sample), member))
 +/* If the above macro causes problems on your compiler you might be
 + * able to find an alternative name for the non-standard __typeof__
 + * operator and add a special case here */

Re: [PATCH weston] compositor-rpi: Fix input initialization

2014-02-05 Thread Kristian Høgsberg 
On Mon, Feb 03, 2014 at 04:57:27PM +0100, poch...@gmail.com wrote:
 From: Emilio Pozuelo Monfort emilio.pozu...@collabora.co.uk
 
 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
 do.

Thanks, applied.  We'll pick this one up for 1.4 too.

Kristian

 ---
  src/compositor-rpi.c | 19 ---
  1 file changed, 8 insertions(+), 11 deletions(-)
 
 diff --git a/src/compositor-rpi.c b/src/compositor-rpi.c
 index 399090d..e7c0e0d 100644
 --- a/src/compositor-rpi.c
 +++ b/src/compositor-rpi.c
 @@ -527,13 +527,6 @@ rpi_compositor_create(struct wl_display *display, int 
 *argc, char *argv[],
   weston_log(Dispmanx planes are %s buffered.\n,
  compositor-single_buffer ? single : double);
  
 - if (udev_input_init(compositor-input,
 - compositor-base,
 - compositor-udev, seat0) != 0) {
 - weston_log(Failed to initialize udev input.\n);
 - goto out_launcher;
 - }
 -
   for (key = KEY_F1; key  KEY_F9; key++)
   weston_compositor_add_key_binding(compositor-base, key,
 MODIFIER_CTRL | MODIFIER_ALT,
 @@ -549,19 +542,23 @@ rpi_compositor_create(struct wl_display *display, int 
 *argc, char *argv[],
   bcm_host_init();
  
   if (rpi_renderer_create(compositor-base, param-renderer)  0)
 - goto out_udev_input;
 + goto out_launcher;
  
   if (rpi_output_create(compositor, param-output_transform)  0)
   goto out_renderer;
  
 + if (udev_input_init(compositor-input,
 + compositor-base,
 + compositor-udev, seat0) != 0) {
 + weston_log(Failed to initialize udev input.\n);
 + goto out_renderer;
 + }
 +
   return compositor-base;
  
  out_renderer:
   compositor-base.renderer-destroy(compositor-base);
  
 -out_udev_input:
 - udev_input_destroy(compositor-input);
 -
  out_launcher:
   weston_launcher_destroy(compositor-base.launcher);
  
 -- 
 1.8.5.3
 
 ___
 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

Re: [PATCH weston v2] dim-layer: fix dimming for unfocused surfaces

2014-02-05 Thread Kristian Høgsberg 
On Thu, Jan 30, 2014 at 01:49:39PM +0100, poch...@gmail.com wrote:
 From: Emilio Pozuelo Monfort emilio.pozu...@collabora.co.uk
 
 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 changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
 index 30bd273..3087042 100644
 --- a/desktop-shell/shell.c
 +++ b/desktop-shell/shell.c
 @@ -4250,14 +4250,14 @@ activate(struct desktop_shell *shell, struct 
 weston_surface *es,
   else
   restore_all_output_modes(shell-compositor);
  
 + /* Update the surface’s layer. This brings it to the top of the stacking
 +  * order as appropriate. */
 + shell_surface_update_layer(shsurf);
 +
   if (shell-focus_animation_type != ANIMATION_NONE) {
   ws = get_current_workspace(shell);
   animate_focus_change(shell, ws, get_default_view(old_es), 
 get_default_view(es));
   }
 -
 - /* Update the surface’s layer. This brings it to the top of the stacking
 -  * order as appropriate. */
 - shell_surface_update_layer(shsurf);
  }
  
  /* no-op func for checking black surface */
 -- 
 1.8.5.3
 
 ___
 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

Re: [PATCH weston 3/4] compositor: Add a visibility switch to weston_layers

2014-02-05 Thread Kristian Høgsberg 
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 removing them from the compositor's layers list.
 
 Instead, add the function weston_layer_show(), which can control the
 visibility of a layer, while maintaining it in the layers list. That
 way, it is not necessary to remember the order between layers when
 making them visible again.
 
 This also has the side effect of causing views in a hidden workspace
 and in an output that has been moved (due to another being unplugged)
 to be moved correctly.

I'd like to see if we could make it even simpler than this; just have a
lock screen layer on top of all layers (except cursor) and then put move
the background image there and the lockscreen surface.  Leave everything in
place and don't switch visibilty, just rely on westons opaque surface
optimizations to avoid repainting and make sure to assign all seats
kb focus to the lock surface.

Kristian

 ---
  desktop-shell/input-panel.c |  6 ++---
  desktop-shell/shell.c   | 62 
 -
  src/compositor.c| 11 
  src/compositor.h|  4 +++
  4 files changed, 44 insertions(+), 39 deletions(-)
 
 diff --git a/desktop-shell/input-panel.c b/desktop-shell/input-panel.c
 index c08a403..5f0025b 100644
 --- a/desktop-shell/input-panel.c
 +++ b/desktop-shell/input-panel.c
 @@ -63,8 +63,7 @@ show_input_panels(struct wl_listener *listener, void *data)
   shell-showing_input_panels = true;
  
   if (!shell-locked)
 - wl_list_insert(shell-panel_layer.link,
 -shell-input_panel_layer.link);
 + weston_layer_show(shell-input_panel_layer, 1);
  
   wl_list_for_each_safe(ipsurf, next,
 shell-input_panel.surfaces, link) {
 @@ -93,8 +92,7 @@ hide_input_panels(struct wl_listener *listener, void *data)
  
   shell-showing_input_panels = false;
  
 - if (!shell-locked)
 - wl_list_remove(shell-input_panel_layer.link);
 + weston_layer_show(shell-input_panel_layer, 0);
  
   wl_list_for_each_safe(view, next,
 shell-input_panel_layer.view_list, layer_link)
 diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
 index ae06382..888e33b 100644
 --- a/desktop-shell/shell.c
 +++ b/desktop-shell/shell.c
 @@ -819,13 +819,13 @@ seat_destroyed(struct wl_listener *listener, void *data)
  }
  
  static struct workspace *
 -workspace_create(void)
 +workspace_create(struct desktop_shell *shell)
  {
   struct workspace *ws = malloc(sizeof *ws);
   if (ws == NULL)
   return NULL;
  
 - weston_layer_init(ws-layer, NULL);
 + weston_layer_init(ws-layer, shell-input_panel_layer.link);
  
   wl_list_init(ws-focus_list);
   wl_list_init(ws-seat_destroyed_listener.link);
 @@ -864,7 +864,7 @@ activate_workspace(struct desktop_shell *shell, unsigned 
 int index)
   struct workspace *ws;
  
   ws = get_workspace(shell, index);
 - wl_list_insert(shell-panel_layer.link, ws-layer.link);
 + weston_layer_show(ws-layer, 1);
  
   shell-workspaces.current = index;
  }
 @@ -994,7 +994,7 @@ finish_workspace_change_animation(struct desktop_shell 
 *shell,
   workspace_deactivate_transforms(to);
   shell-workspaces.anim_to = NULL;
  
 - wl_list_remove(shell-workspaces.anim_from-layer.link);
 + weston_layer_show(shell-workspaces.anim_from-layer, 0);
  }
  
  static void
 @@ -1076,7 +1076,7 @@ animate_workspace_change(struct desktop_shell *shell,
   wl_list_insert(output-animation_list,
  shell-workspaces.animation.link);
  
 - wl_list_insert(from-layer.link.prev, to-layer.link);
 + weston_layer_show(to-layer, 1);
  
   workspace_translate_in(to, 0);
  
 @@ -1090,8 +1090,8 @@ update_workspace(struct desktop_shell *shell, unsigned 
 int index,
struct workspace *from, struct workspace *to)
  {
   shell-workspaces.current = index;
 - wl_list_insert(from-layer.link, to-layer.link);
 - wl_list_remove(from-layer.link);
 + weston_layer_show(to-layer, 1);
 + weston_layer_show(from-layer, 0);
  }
  
  static void
 @@ -1241,9 +1241,6 @@ take_surface_to_workspace_by_seat(struct desktop_shell 
 *shell,
  
   if (shell-workspaces.anim_from == to 
   shell-workspaces.anim_to == from) {
 - wl_list_remove(to-layer.link);
 - wl_list_insert(from-layer.link.prev, to-layer.link);
 -
   reverse_workspace_change_animation(shell, index, from, to);
   broadcast_current_workspace_state(shell);
  
 @@ -3732,19 +3729,15 @@ resume_desktop(struct desktop_shell *shell)
  
   terminate_screensaver(shell);
  
 -

[PATCH] nested-client: Fix build error

2014-02-05 Thread Jason Ekstrand 
---
 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_client_LDADD = $(SIMPLE_EGL_CLIENT_LIBS) -lm
+weston_nested_client_CFLAGS = $(CLIENT_CFLAGS)
 endif
 
 weston_eventdemo_SOURCES = clients/eventdemo.c
-- 
1.8.5.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH libinput 3/6] path: add libinput_path_add_device() and libinput_path_remove_device()

2014-02-05 Thread Peter Hutterer 
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.

Returning the device is required by callers that have the event processing
separate from adding devices - by the time we have the DEVICE_ADDED event in
the queue we may have other events to process first. And the DEVICE_ADDED
event won't easily link to the path we gave it anyway, so it's hard to figure
out which DEVICE_ADDED event corresponds to the new device.

Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
 src/libinput.h |  45 +++
 src/path.c | 104 ++--
 test/path.c| 114 +
 3 files changed, 252 insertions(+), 11 deletions(-)

diff --git a/src/libinput.h b/src/libinput.h
index e2d83bf..e1d1ffb 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -729,6 +729,51 @@ libinput_create_from_path(const struct libinput_interface 
*interface,
 /**
  * @ingroup base
  *
+ * Add a device to a libinput context initialized with
+ * libinput_path_create_from_device(). If successful, the device will be
+ * added to the internal list and re-opened on libinput_resume(). The device
+ * can be removed with libinput_path_remove_device().
+ *
+ * If the device was successfully initialized, it is returned in the device
+ * argument. The lifetime of the returned device pointer is limited until
+ * the next linput_dispatch(), use libinput_device_ref() to keep a permanent
+ * reference.
+ *
+ * @param libinput A previously initialized libinput context
+ * @param path Path to an input device
+ * @return The newly initiated device on success, or NULL on failure.
+ *
+ * @note It is an application bug to call this function on a libinput
+ * context initialize with libinput_udev_create_for_seat().
+ */
+struct libinput_device *
+libinput_path_add_device(struct libinput *libinput,
+const char *path);
+
+/**
+ * @ingroup base
+ *
+ * Remove a device from a libinput context initialized with
+ * libinput_path_create_from_device() or added to such a context with
+ * libinput_path_add_device().
+ *
+ * Events already processed from this input device are kept in the queue,
+ * the LIBINPUT_EVENT_DEVICE_REMOVED event marks the end of events for this
+ * device.
+ *
+ * If no matching device exists, this function does nothing.
+ *
+ * @param device A libinput device
+ *
+ * @note It is an application bug to call this function on a libinput
+ * context initialize with libinput_udev_create_for_seat().
+ */
+void
+libinput_path_remove_device(struct libinput_device *device);
+
+/**
+ * @ingroup base
+ *
  * libinput keeps a single file descriptor for all events. Call into
  * libinput_dispatch() if any events become available on this fd.
  *
diff --git a/src/path.c b/src/path.c
index 32483df..a5b3338 100644
--- a/src/path.c
+++ b/src/path.c
@@ -22,6 +22,7 @@
 
 #include config.h
 
+#include errno.h
 #include fcntl.h
 #include string.h
 #include libudev.h
@@ -36,6 +37,31 @@ int path_input_process_event(struct libinput_event);
 static void path_seat_destroy(struct libinput_seat *seat);
 
 static void
+path_disable_device(struct libinput *libinput,
+   struct evdev_device *device)
+{
+   struct libinput_seat *seat = device-base.seat;
+   struct evdev_device *dev, *next;
+
+   list_for_each_safe(dev, next,
+  seat-devices_list, base.link) {
+   if (dev != device)
+   continue;
+
+   evdev_device_remove(device);
+   if (list_empty(seat-devices_list)) {
+   /* if the seat may be referenced by the
+  client, so make sure it's dropped from
+  the seat list now, to be freed whenever
+* the device is removed */
+   list_remove(seat-link);
+   list_init(seat-link);
+   }
+   break;
+   }
+}
+
+static void
 path_input_disable(struct libinput *libinput)
 {
struct path_input *input = (struct path_input*)libinput;
@@ -45,17 +71,8 @@ path_input_disable(struct libinput *libinput)
list_for_each_safe(seat, tmp, input-base.seat_list, base.link) {
libinput_seat_ref(seat-base);
list_for_each_safe(device, next,
-  seat-base.devices_list, base.link) {
-   evdev_device_remove(device);
-   if (list_empty(seat-base.devices_list)) {
-   /* if the seat may be referenced by the
-  client, so make sure it's dropped from
-  the seat list now, to be freed

[PATCH libinput 6/6] test: Add tests for adding/removing devices

2014-02-05 Thread Peter Hutterer 
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
 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_device)
 }
 END_TEST
 
+START_TEST(path_add_invalid_path)
+{
+   struct litest_device *dev = litest_current_device();
+   struct libinput *li = dev-libinput;
+   struct libinput_event *event;
+   struct libinput_device *device;
+
+   litest_drain_events(li);
+
+   device = libinput_path_add_device(li, /tmp/);
+   ck_assert(device == NULL);
+
+   libinput_dispatch(li);
+
+   while ((event = libinput_get_event(li)))
+   ck_abort();
+}
+END_TEST
+
 START_TEST(path_device_sysname)
 {
struct litest_device *dev = litest_current_device();
@@ -465,6 +484,300 @@ START_TEST(path_double_resume)
 }
 END_TEST
 
+START_TEST(path_add_device_suspend_resume)
+{
+   struct libinput *li;
+   struct libinput_device *device;
+   struct libinput_event *event;
+   struct libevdev *evdev;
+   struct libevdev_uinput *uinput1, *uinput2;
+   int rc;
+   int nevents;
+   void *userdata = rc;
+
+   evdev = libevdev_new();
+   ck_assert(evdev != NULL);
+
+   libevdev_set_name(evdev, test device);
+   libevdev_enable_event_code(evdev, EV_KEY, BTN_LEFT, NULL);
+   libevdev_enable_event_code(evdev, EV_KEY, BTN_RIGHT, NULL);
+   libevdev_enable_event_code(evdev, EV_REL, REL_X, NULL);
+   libevdev_enable_event_code(evdev, EV_REL, REL_Y, NULL);
+
+   rc = libevdev_uinput_create_from_device(evdev,
+   LIBEVDEV_UINPUT_OPEN_MANAGED,
+   uinput1);
+   ck_assert_int_eq(rc, 0);
+
+   libevdev_set_name(evdev, test device 2);
+   rc = libevdev_uinput_create_from_device(evdev,
+   LIBEVDEV_UINPUT_OPEN_MANAGED,
+   uinput2);
+   ck_assert_int_eq(rc, 0);
+
+   libevdev_free(evdev);
+
+   li = libinput_path_create_context(simple_interface, userdata);
+   ck_assert(li != NULL);
+
+   device = libinput_path_add_device(li,
+ libevdev_uinput_get_devnode(uinput1));
+   ck_assert(device != NULL);
+   device = libinput_path_add_device(li,
+ libevdev_uinput_get_devnode(uinput2));
+
+   libinput_dispatch(li);
+
+   nevents = 0;
+   while ((event = libinput_get_event(li))) {
+   enum libinput_event_type type;
+   type = libinput_event_get_type(event);
+   ck_assert_int_eq(type, LIBINPUT_EVENT_DEVICE_ADDED);
+   libinput_event_destroy(event);
+   nevents++;
+   }
+
+   ck_assert_int_eq(nevents, 2);
+
+
+   libinput_suspend(li);
+   libinput_dispatch(li);
+
+   nevents = 0;
+   while ((event = libinput_get_event(li))) {
+   enum libinput_event_type type;
+   type = libinput_event_get_type(event);
+   ck_assert_int_eq(type, LIBINPUT_EVENT_DEVICE_REMOVED);
+   libinput_event_destroy(event);
+   nevents++;
+   }
+
+   ck_assert_int_eq(nevents, 2);
+
+   libinput_resume(li);
+   libinput_dispatch(li);
+
+   nevents = 0;
+   while ((event = libinput_get_event(li))) {
+   enum libinput_event_type type;
+   type = libinput_event_get_type(event);
+   ck_assert_int_eq(type, LIBINPUT_EVENT_DEVICE_ADDED);
+   libinput_event_destroy(event);
+   nevents++;
+   }
+
+   ck_assert_int_eq(nevents, 2);
+
+   libevdev_uinput_destroy(uinput1);
+   libevdev_uinput_destroy(uinput2);
+   libinput_destroy(li);
+
+   open_func_count = 0;
+   close_func_count = 0;
+}
+END_TEST
+
+START_TEST(path_add_device_suspend_resume_fail)
+{
+   struct libinput *li;
+   struct libinput_device *device;
+   struct libinput_event *event;
+   struct libevdev *evdev;
+   struct libevdev_uinput *uinput1, *uinput2;
+   int rc;
+   int nevents;
+   void *userdata = rc;
+
+   evdev = libevdev_new();
+   ck_assert(evdev != NULL);
+
+   libevdev_set_name(evdev, test device);
+   libevdev_enable_event_code(evdev, EV_KEY, BTN_LEFT, NULL);
+   libevdev_enable_event_code(evdev, EV_KEY, BTN_RIGHT, NULL);
+   libevdev_enable_event_code(evdev, EV_REL, REL_X, NULL);
+   libevdev_enable_event_code(evdev, EV_REL, REL_Y, NULL);
+
+   rc = libevdev_uinput_create_from_device(evdev,
+   LIBEVDEV_UINPUT_OPEN_MANAGED,
+   uinput1);
+   ck_assert_int_eq(rc, 0);
+
+

[PATCH libinput 0/6] Add dynamic devices to the path backend

2014-02-05 Thread Peter Hutterer 

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 disabling
the touchpad while typing, or making the trackstick buttons on the Lenovo
T440s useful.

So for my little libinput-based xorg driver [1] I need to have a shared
context between the various devices added. The change looks bigger than it
is, it largely just replicates what the udev-seat backend already does
anyway.

Most notable there are a few API changes:
- libinput_create_from_path() has been removed, a caller should now use
  libinput_path_create_context(), then libinput_path_add_device()
  I found this to be nicer in the caller code than having
  libinput_path_create_from_device() and then adding devices.
- more devices can be added or removed with libinput_path_add_device and
  libinput_path_remove_device
- to ensure proper namespacing, libinput_create_from_udev is now
  libinput_udev_create_for_seat()

So far this looks flexible enough for the xorg drivers which have different
use-cases than in weston, specifically each device can be disabled and
enabled individually. I just call remove/add device when that happens.

What's not so nice is a shortcut in libinput_path_add_device(). Instead of
just succeeding and letting the caller handle the DEVICE_ADDED event, it
returns the struct libinput_device directly. At least within the xorg driver
context I found it too hard to work with the events (long description on
request) but the short summary is that I'd need to cache any events before
DEVICE_ADDED and use timers to re-trigger the read once I have the device,
aside from the problem of not being able to figure out which device is which
based on the events only (we don't expose the devnode to the caller).

On the positive side, the xorg driver seems to be working quite nicely
already, though it is rather featureless.

Cheers,
  Peter
 
[1] https://github.com/whot/xf86-input-libinput

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH libinput 1/6] Store the backend type in the interface

2014-02-05 Thread Peter Hutterer 
This enables us to prevent callers from calling backend-specific functions on
mismatching backends.

Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
 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.h b/src/libinput-private.h
index 0d7de90..ee5a17d 100644
--- a/src/libinput-private.h
+++ b/src/libinput-private.h
@@ -26,7 +26,13 @@
 #include libinput.h
 #include libinput-util.h
 
+enum libinput_backend_type {
+   BACKEND_UDEV,
+   BACKEND_PATH,
+};
+
 struct libinput_interface_backend {
+   enum libinput_backend_type backend_type;
int (*resume)(struct libinput *libinput);
void (*suspend)(struct libinput *libinput);
void (*destroy)(struct libinput *libinput);
diff --git a/src/path.c b/src/path.c
index de2ca49..4924b31 100644
--- a/src/path.c
+++ b/src/path.c
@@ -167,6 +167,7 @@ path_input_destroy(struct libinput *input)
 }
 
 static const struct libinput_interface_backend interface_backend = {
+   .backend_type = BACKEND_PATH,
.resume = path_input_enable,
.suspend = path_input_disable,
.destroy = path_input_destroy,
diff --git a/src/udev-seat.c b/src/udev-seat.c
index 957e762..b564c83 100644
--- a/src/udev-seat.c
+++ b/src/udev-seat.c
@@ -330,6 +330,7 @@ udev_seat_get_named(struct udev_input *input, const char 
*seat_name)
 }
 
 static const struct libinput_interface_backend interface_backend = {
+   .backend_type = BACKEND_UDEV,
.resume = udev_input_enable,
.suspend = udev_input_disable,
.destroy = udev_input_destroy,
-- 
1.8.4.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH libinput 2/6] path: modify backend to allow for more than one device

2014-02-05 Thread Peter Hutterer 
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 patch merely adds the infrastructure to support multiple devices for a
path backend. Follow-up patches add the function calls to add and remove
devices. This is needed by Xorg input drivers that still make use of the
server's device hotplug mechanisms but want to otherwise use libinput.

Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
 src/path.c | 120 +++--
 src/path.h |   6 +++-
 2 files changed, 99 insertions(+), 27 deletions(-)

diff --git a/src/path.c b/src/path.c
index 4924b31..32483df 100644
--- a/src/path.c
+++ b/src/path.c
@@ -39,11 +39,24 @@ static void
 path_input_disable(struct libinput *libinput)
 {
struct path_input *input = (struct path_input*)libinput;
-   struct evdev_device *device = input-device;
+   struct path_seat *seat, *tmp;
+   struct evdev_device *device, *next;
 
-   if (device) {
-   evdev_device_remove(device);
-   input-device = NULL;
+   list_for_each_safe(seat, tmp, input-base.seat_list, base.link) {
+   libinput_seat_ref(seat-base);
+   list_for_each_safe(device, next,
+  seat-base.devices_list, base.link) {
+   evdev_device_remove(device);
+   if (list_empty(seat-base.devices_list)) {
+   /* if the seat may be referenced by the
+  client, so make sure it's dropped from
+  the seat list now, to be freed whenever
+* the device is removed */
+   list_remove(seat-base.link);
+   list_init(seat-base.link);
+   }
+   }
+   libinput_seat_unref(seat-base);
}
 }
 
@@ -72,6 +85,22 @@ path_seat_create(struct path_input *input,
return seat;
 }
 
+static struct path_seat*
+path_seat_get_named(struct path_input *input,
+   const char *seat_name_physical,
+   const char *seat_name_logical)
+{
+   struct path_seat *seat;
+
+   list_for_each(seat, input-base.seat_list, base.link) {
+   if (strcmp(seat-base.physical_name, seat_name_physical) == 0 
+   strcmp(seat-base.logical_name, seat_name_logical) == 0)
+   return seat;
+   }
+
+   return NULL;
+}
+
 static int
 path_get_udev_properties(const char *path,
 char **sysname,
@@ -113,48 +142,64 @@ out:
return rc;
 }
 
-static int
-path_input_enable(struct libinput *libinput)
+static struct libinput_device *
+path_device_enable(struct path_input *input, const char *devnode)
 {
-   struct path_input *input = (struct path_input*)libinput;
struct path_seat *seat;
-   struct evdev_device *device;
-   const char *devnode = input-path;
+   struct evdev_device *device = NULL;
char *sysname;
char *seat_name, *seat_logical_name;
 
-   if (input-device)
-   return 0;
-
if (path_get_udev_properties(devnode, sysname,
 seat_name, seat_logical_name) == -1) {
log_info(failed to obtain sysname for device '%s'.\n, 
devnode);
-   return -1;
+   return NULL;
}
 
-   seat = path_seat_create(input, seat_name, seat_logical_name);
-   free(seat_name);
-   free(seat_logical_name);
+   seat = path_seat_get_named(input, seat_name, seat_logical_name);
 
-   if (!seat) {
-   log_info(failed to create seat for device '%s'.\n, devnode);
-   free(sysname);
-   return -1;
+   if (seat) {
+   libinput_seat_ref(seat-base);
+   } else {
+   seat = path_seat_create(input, seat_name, seat_logical_name);
+   if (!seat) {
+   log_info(failed to create seat for device '%s'.\n, 
devnode);
+   goto out;
+   }
}
 
device = evdev_device_create(seat-base, devnode, sysname);
-   free(sysname);
libinput_seat_unref(seat-base);
 
if (device == EVDEV_UNHANDLED_DEVICE) {
+   device = NULL;
log_info(not using input device '%s'.\n, devnode);
-   return -1;
+   goto out;
} else if (device == NULL) {
log_info(failed to create input device '%s'.\n, devnode);
-   return -1;
+   goto out;
}
 
-   input-device = device;
+out:
+   free(sysname);
+   free(seat_name);
+

Re: [PATCH] nested-client: Fix build error

2014-02-05 Thread Kristian Høgsberg 
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
 @@ -485,6 +485,7 @@ weston_nested_CFLAGS = $(CLIENT_CFLAGS)
  
  weston_nested_client_SOURCES = clients/nested-client.c
  weston_nested_client_LDADD = $(SIMPLE_EGL_CLIENT_LIBS) -lm
 +weston_nested_client_CFLAGS = $(CLIENT_CFLAGS)
  endif
  
  weston_eventdemo_SOURCES = clients/eventdemo.c
 -- 
 1.8.5.3
 
 ___
 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

Re: [PATCH wayland 3/3] Add a debug handler and use it to print out protocol debug messages

2014-02-05 Thread Kristian Høgsberg 
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 ja...@jlekstrand.net
 ---
  src/connection.c  | 54 
 ---
  src/wayland-client.c  |  6 ++
  src/wayland-client.h  |  1 +
  src/wayland-private.h |  2 ++
  src/wayland-server.c  |  6 ++
  src/wayland-server.h  |  1 +
  src/wayland-util.c| 19 ++
  7 files changed, 65 insertions(+), 24 deletions(-)
 
 diff --git a/src/connection.c b/src/connection.c
 index 1d8b61b..b7f02b4 100644
 --- a/src/connection.c
 +++ b/src/connection.c
 @@ -1088,67 +1088,73 @@ void
  wl_closure_print(struct wl_closure *closure, struct wl_object *target, int 
 send)
  {
   int i;
 + struct wl_array msg;
   struct argument_details arg;
   const char *signature = closure-message-signature;
   struct timespec tp;
   unsigned int time;
  
 + wl_array_init(msg);
 + wl_array_add(msg, 128); /* This should be big enough for most cases */
 + msg.size = 0;
 +
   clock_gettime(CLOCK_REALTIME, tp);
   time = (tp.tv_sec * 100L) + (tp.tv_nsec / 1000);
  
 - fprintf(stderr, [%10.3f] %s%s@%u.%s(,
 - time / 1000.0,
 - send ?  -  : ,
 - target-interface-name, target-id,
 - closure-message-name);
 + wl_array_printf(msg, [%10.3f] %s%s@%u.%s(,
 + time / 1000.0,
 + send ?  -  : ,
 + target-interface-name, target-id,
 + closure-message-name);

Could we just call wl_debug() instead and avoid building up a string?
The way you've written this, wl_debug() is always called with one complete
line of debug text, but do you actually need that?

Kristian

  
   for (i = 0; i  closure-count; i++) {
   signature = get_next_argument(signature, arg);
   if (i  0)
 - fprintf(stderr, , );
 + wl_array_printf(msg, , );
  
   switch (arg.type) {
   case 'u':
 - fprintf(stderr, %u, closure-args[i].u);
 + wl_array_printf(msg, %u, closure-args[i].u);
   break;
   case 'i':
 - fprintf(stderr, %d, closure-args[i].i);
 + wl_array_printf(msg, %d, closure-args[i].i);
   break;
   case 'f':
 - fprintf(stderr, %f,
 - wl_fixed_to_double(closure-args[i].f));
 + wl_array_printf(msg, %f,
 + wl_fixed_to_double(closure-args[i].f));
   break;
   case 's':
 - fprintf(stderr, \%s\, closure-args[i].s);
 + wl_array_printf(msg, \%s\, closure-args[i].s);
   break;
   case 'o':
   if (closure-args[i].o)
 - fprintf(stderr, %s@%u,
 - closure-args[i].o-interface-name,
 - closure-args[i].o-id);
 + wl_array_printf(msg, %s@%u,
 + 
 closure-args[i].o-interface-name,
 + closure-args[i].o-id);
   else
 - fprintf(stderr, nil);
 + wl_array_printf(msg, nil);
   break;
   case 'n':
 - fprintf(stderr, new id %s@,
 - (closure-message-types[i]) ?
 -  closure-message-types[i]-name :
 -   [unknown]);
 + wl_array_printf(msg, new id %s@,
 + (closure-message-types[i]) ?
 +  closure-message-types[i]-name :
 +  [unknown]);
   if (closure-args[i].n != 0)
 - fprintf(stderr, %u, closure-args[i].n);
 + wl_array_printf(msg, %u, closure-args[i].n);
   else
 - fprintf(stderr, nil);
 + wl_array_printf(msg, nil);
   break;
   case 'a':
 - fprintf(stderr, array);
 + wl_array_printf(msg, array);
   break;
   case 'h':
 - fprintf(stderr, fd %d, closure-args[i].h);
 + wl_array_printf(msg, fd %d, closure-args[i].h);
   break;
   }
   }
  
 - fprintf(stderr, )\n);
 + wl_debug(%s)\n, msg.data);
 + wl_array_release(msg);

Re: Xserver errors

2014-02-05 Thread Bill Spitzak 

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=wayland,x11,drm --enable-gbm --enable-shared-glapi 
--with-gallium-drivers=r300,r600,swrast,nouveau

...
configure: error: Package requirements (x11 xext xdamage xfixes x11-xcb 
xcb-glx = 1.8.1 xcb-dri2 = 1.8 xcb-dri3 xcb-present xcb-sync xshmfence 
= 1.1) were not met:


No package 'xcb-dri3' found
No package 'xcb-present' found
No package 'xcb-sync' found
No package 'xshmfence' found

I have no idea where those packages are found. Also not sure if maybe I 
am off course and don't need to compile mesa this way.



On 02/05/2014 10:00 AM, Jasper St. Pierre wrote:

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 just be able to just install xf86-video-wayland
and have everything work.


On Wed, Feb 5, 2014 at 12:46 PM, Bill Spitzak spit...@gmail.com
mailto:spit...@gmail.com wrote:

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 weston. Weston I am using the main
branch, and I configure and compile and install it with:

./autogen.sh --prefix=$HOME/install --disable-setuid-install
--disable-colord
make
make install

xserver: I am using the xwayland-1.12 branch from
git://anongit.freedesktop.org/__xorg/xserver
http://anongit.freedesktop.org/xorg/xserver.
Configure/make/install is:

./autogen.sh --prefix=$HOME/install
make
make install

Also I am compiling/installing xserver after xwayland, not sure if
this is the correct order.

I am rather mystified as to why there is both an xserver and
xwayland code in weston, any quick explanation would be appreciated.


Did you
build xf86-video-wayland as well?


No, only xf86-video-ati, xf86-video-intel, xf86-video-wlshm. I had
to compile tons of stuff in order to get xserver to compile, which
is really annoying. Most of it I suspect is never used.

If I add this, how do I tell the Xserver that it exists? Do I just
have to install it, or do I have to recomfigure and recompile Xserver?

I am also dubious that this has anything to do with it, as my test
applications are not using xv.





--
   Jasper


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel