Re: [RFC] libinput configuration interface

2014-02-06 Thread Eugen Friedrich
Hi together,
i would like to put some input from the embedded/ automotive perspective.

you can think about huge amount of different configurations for different
device types.
A lot of configuration in the initial post deals with behavior of buttons
and scrolling
areas of the touch panels.

The good approach could be a kind of general configuration of button and
scrolling areas of the touch panels
the button area could contain a position and dimension of the button in the
device coordinate system and the button code
the slider area could contain a position and dimension of the slider along
with the range.

Also the weston code contains calibration of the absolute values.
It would be good also to have a calibration possibilities in libinput.

What do you think?


2014-02-03 6:11 GMT+01:00 Alexander E. Patrakov :

> 2014-02-03 Peter Hutterer :
> > On Fri, Jan 31, 2014 at 08:26:54PM +0600, Alexander E. Patrakov wrote:
> >> Peter Hutterer wrote:
> >> > I've been thinking about how to add a device configuration interface
> to
> >> > libinput, and after getting feedback from Jonas and Benjamin, here's a
> >> > proposal (no code yet).
> >> >
> >> > First, I think the configuration should be feature-specific, not
> device
> >> > specific, so it is independent of a classification or capabilities of
> a
> >> > device. To the user it doesn't matter if we classify something as
> touchpad
> >> > or as mouse, if middle mouse button emulation works that's the only
> thing
> >> > that counts. At least for configuration purposes, this also avoids the
> >> > difficult task of classifying a device correctly. Those pesky HW
> >> > manufacturers do have a habit of coming up with devices that elude
> >> > previously agreed-on classification schemes, e.g. mice with touchpads
> on
> >> > them.
> >> >
> >> > Aside from setting an item, there should be calls to get the current
> value,
> >> > and a call to reset to the built-in defaults. And, since we're
> >> > feature-based, a call to check if the config item is possible for a
> device.
> >> > Which leads us the the following quartet for each item:
> >> >
> >> > int libinput_device_config_set_foo(device, value);
> >> > int libinput_device_config_get_foo(device, &value);
> >> > int libinput_device_config_reset_foo(device);
> >> > bool libinput_device_config_has_foo(device);
> >> >
> >> > And the actual configuration items I've come up with so far:
> >> > * {set|get|reset|has}_tap_single_finger_button
> >> > * tap_double_finger_button
> >> > * tap_triple_finger_button
> >> > * click_finger_single
> >> > * click_finger_double
> >> > * click_finger_triple
> >> > * twofinger_scroll_vertical
> >> > * twofinger_scroll_horizonal
> >> > * edge_scroll_vertical
> >> > * edge_scroll_horizontal
> >> > * disable_while_typing
> >> > * disable_touch (while pen is in use)
> >> >   these two could be merged into "disable while linked device is in
> use"
> >> > * softbutton_left
> >> > * softbutton_middle
> >> > * softbutton_right
> >> > * emulate_middle_button
> >> > * button_mapping
> >> > * emulate_wheel
> >> > * rotation
> >> > * palm_detection
> >> > * mode (relative/absolute)
> >> > * valid_area
> >> >   This is needed on tablets that have a different ratio than the
> monitor.
> >> >   Mapping them to the monitor results in uneven x/y movements, so the
> >> >   easiest approach here is to cut a portion of the tablet off to
> match the
> >> >   ratio.
> >> > * stylus_button_behaviour(some enum)
> >> >   Some tablets don't report proximity, the only way to get a
> right-button
> >> >   click is to hold the right button down and then tip with the stylus.
> >> >
> >> > Note that the above is not a 1:1 API mapping, e.g. tapping
> configuration
> >> > could be an API taking nfingers as argument as opposed to 3 different
> calls.
> >> > Likewise, they can take more than one value argument, e.g. middle
> button
> >> > emulation could take a boolean to enable it, and a timeout.
> >> >
> >> > This list excludes options we currently have in the X drivers to
> adjust for
> >> > hw-specific quirks. Such as defining which pressure makes up a tap,
> etc. I
> >> > really hope this is something we can work out based on the device.
> >> >
> >> > It also excludes configurations that I'd really like to hide away if
> >> > possible. For example, on the new T440-style touchpads the top part
> of it is
> >> > a set of buttons for the trackstick. There's nothing to be configured
> about
> >> > this, it should just work.
> >> >
> >> > Comments? Does this sound sane enough? Anything important I've missed?
> >>
> >> You missed our disagreement from August about whether finger movement
> in the
> >> softbutton area should move the pointer (I suggested that it shouldn't,
> you
> >> suggested that it should, and both of us had valid arguments, so it
> needs to
> >> be configurable). Also it was not clearly articulated then, but still, a
> >> potential disagreement/configuration point: what to do on a one-bu

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

2014-02-06 Thread Peter Hutterer
On Thu, Feb 06, 2014 at 10:23:57PM +0100, Jonas Ådahl wrote:
> On Thu, Feb 06, 2014 at 02:13:04PM +1000, Peter Hutterer wrote:
> > 
> > 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()
> 
> Why not just libinput_path_create()?

I wanted to make it explicit that all this call does is create the context,
as opposed to e.g. udev_create_... which adds devices too.

> >   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()
> 
> These API changes looks good to me, but should maybe suspend and resume
> behaviour be documented? Is it required to re-add devices after having
> resumed?

it's not required, the behaviour is that suspend/resume removes and re-adds
all devices, or fails if a device cannot be added. exactly the same behavour
as the udev seat. I'll expand on the suspend/resume documentation in a
separate patch.

> > 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).
> 
> So I guess you can't just add and then flush and process the queue right
> there, as the DEVICE_ADDED event will already have been queued when
> calling libinput_path_add_device()?

Not without doing some work to the server, the enable/disable bits are in a
quirky order and called from different places than the actual event
processing. So without auditing the call paths I can't guarantee that the
server is in the correct state for handling events when you get the first
couple of events. Returning the device pointer was the less-intrusive but
still somewhat-sensible approach :)

> We could also simply expose the devnode to the caller as well,
> caching and matching later is not very nice.

IMO we should do this anyway, otherwise we'd require the caller to use udev
and subsystem guessing* to match it up themselves. At least a devnode is
non-ambiguous.

Cheers,
   Peter

* probably not much of an issue since we don't deal with serial devices, so
we can assume subsystem is always "input"
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


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

2014-02-06 Thread Peter Hutterer
On Thu, Feb 06, 2014 at 10:11:34PM +0100, Jonas Ådahl wrote:
> On Thu, Feb 06, 2014 at 02:13:05PM +1000, Peter Hutterer wrote:
> > This enables us to prevent callers from calling backend-specific functions 
> > on
> > mismatching backends.
> 
> This can be done instead by comparing the backend interface pointer in
> struct libinput to the one defined in either path.c or udev-seat.c.
> 
> if (libinput->interface_backend != &interface_backend) {
>   log(...);
>   return NULL;
> }
> 
> I think doing it like that is preferred, since we should avoid
> per-backend logic in the front end anyway.

ok, no problem. amended locally, and that drops this patch completely and
replaces it with the above condition in 3/6.

Cheers,
   Peter

> > 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.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] Make touch event slots seat wide

2014-02-06 Thread Jonas Ådahl
Since a Wayland compositor have to represent all touch devices of a seat
as one virtual device, lets make that easier by making the slots of
touch events seat wide unique.

Signed-off-by: Jonas Ådahl 
---
 src/evdev.c| 24 +---
 src/evdev.h|  3 +++
 src/libinput-private.h |  1 +
 src/libinput.h |  4 ++--
 4 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index 2bc301b..80210fb 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -109,7 +109,9 @@ evdev_flush_pending_event(struct evdev_device *device, 
uint32_t time)
 {
int32_t cx, cy;
int slot;
+   uint32_t seat_slot;
struct libinput_device *base = &device->base;
+   struct libinput_seat *seat = base->seat;
 
slot = device->mt.slot;
 
@@ -128,9 +130,13 @@ evdev_flush_pending_event(struct evdev_device *device, 
uint32_t time)
if (!(device->seat_caps & EVDEV_DEVICE_TOUCH))
break;
 
+   seat_slot = ffs(~seat->slot_map) - 1;
+   device->mt.slots[slot].seat_slot = seat_slot;
+   seat->slot_map |= 1 << seat_slot;
+
touch_notify_touch(base,
   time,
-  slot,
+  seat_slot,
   li_fixed_from_int(device->mt.slots[slot].x),
   li_fixed_from_int(device->mt.slots[slot].y),
   LIBINPUT_TOUCH_TYPE_DOWN);
@@ -139,6 +145,8 @@ evdev_flush_pending_event(struct evdev_device *device, 
uint32_t time)
if (!(device->seat_caps & EVDEV_DEVICE_TOUCH))
break;
 
+   seat_slot = device->mt.slots[slot].seat_slot;
+
touch_notify_touch(base,
   time,
   slot,
@@ -150,9 +158,12 @@ evdev_flush_pending_event(struct evdev_device *device, 
uint32_t time)
if (!(device->seat_caps & EVDEV_DEVICE_TOUCH))
break;
 
+   seat_slot = device->mt.slots[slot].seat_slot;
+   seat->slot_map &= ~(1 << seat_slot);
+
touch_notify_touch(base,
   time,
-  slot,
+  seat_slot,
   0, 0,
   LIBINPUT_TOUCH_TYPE_UP);
break;
@@ -160,6 +171,10 @@ evdev_flush_pending_event(struct evdev_device *device, 
uint32_t time)
if (!(device->seat_caps & EVDEV_DEVICE_TOUCH))
break;
 
+   seat_slot = ffs(~seat->slot_map) - 1;
+   device->abs.seat_slot = seat_slot;
+   seat->slot_map |= 1 << seat_slot;
+
transform_absolute(device, &cx, &cy);
touch_notify_touch(base,
   time,
@@ -173,7 +188,7 @@ evdev_flush_pending_event(struct evdev_device *device, 
uint32_t time)
if (device->seat_caps & EVDEV_DEVICE_TOUCH) {
touch_notify_touch(base,
   time,
-  slot,
+  device->abs.seat_slot,
   li_fixed_from_int(cx),
   li_fixed_from_int(cy),
   LIBINPUT_TOUCH_TYPE_DOWN);
@@ -188,6 +203,9 @@ evdev_flush_pending_event(struct evdev_device *device, 
uint32_t time)
if (!(device->seat_caps & EVDEV_DEVICE_TOUCH))
break;
 
+   seat_slot = device->abs.seat_slot;
+   seat->slot_map &= ~(1 << seat_slot);
+
touch_notify_touch(base,
   time,
   0, 0, 0, LIBINPUT_TOUCH_TYPE_UP);
diff --git a/src/evdev.h b/src/evdev.h
index 37c32e5..b0feb28 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -64,6 +64,8 @@ struct evdev_device {
int min_x, max_x, min_y, max_y;
int32_t x, y;
 
+   uint32_t seat_slot;
+
int apply_calibration;
float calibration[6];
} abs;
@@ -71,6 +73,7 @@ struct evdev_device {
struct {
int slot;
struct {
+   uint32_t seat_slot;
int32_t x, y;
} slots[MAX_SLOTS];
} mt;
diff --git a/src/libinput-private.h b/src/libinput-private.h
index 0d7de90..2eea012 100644
--- a/src/libinput-private.h
+++ b/src/libinput-private.h
@@ -57,6 +57,7 @@ struct libinput_seat {
struct list devices_list;
void *user_data;
int refcount;
+   uint32_t slot_map;
char *physical_name;
char *logical_name;
libinput_sea

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

2014-02-06 Thread Jonas Ådahl
On Thu, Feb 06, 2014 at 02:13:04PM +1000, Peter Hutterer wrote:
> 
> 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()

Why not just libinput_path_create()?

>   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()

These API changes looks good to me, but should maybe suspend and resume
behaviour be documented? Is it required to re-add devices after having
resumed?

> 
> 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).

So I guess you can't just add and then flush and process the queue right
there, as the DEVICE_ADDED event will already have been queued when
calling libinput_path_add_device()?

We could also simply expose the devnode to the caller as well,
caching and matching later is not very nice.

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

Nice :)

> 
> 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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


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

2014-02-06 Thread Jonas Ådahl
On Thu, Feb 06, 2014 at 09:20:15AM +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. 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.

This good I think.

Jonas

> 
> Signed-off-by: Peter Hutterer 
> ---
> 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

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

2014-02-06 Thread Jonas Ådahl
On Thu, Feb 06, 2014 at 02:13:05PM +1000, Peter Hutterer wrote:
> This enables us to prevent callers from calling backend-specific functions on
> mismatching backends.

This can be done instead by comparing the backend interface pointer in
struct libinput to the one defined in either path.c or udev-seat.c.

if (libinput->interface_backend != &interface_backend) {
log(...);
return NULL;
}

I think doing it like that is preferred, since we should avoid
per-backend logic in the front end anyway.

Jonas

> 
> 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.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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


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

2014-02-06 Thread Yann E. MORIN
Emilio, All,

On 2014-02-03 16:57 +0100, poch...@gmail.com spake thusly:
> 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
> do.

I know it's already been applied, but just to confirm:

Tested-by: "Yann E. MORIN" 

Thank you! :-)

Regards,
Yann E. MORIN.

-- 
.-..--..
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN |  ___   |
| +33 223 225 172 `.---:  X  AGAINST  |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL|   v   conspiracy.  |
'--^---^--^'
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


Re: [PATCH weston 6/6] tests: Properly report skipped tests

2014-02-06 Thread Emilio Pozuelo Monfort
On 06/02/14 12:30, Emilio Pozuelo Monfort wrote:
> From: Emilio Pozuelo Monfort 
> 
> We were calling exit(0) when tests were skipped, which counted
> them as passed instead of skipped. Fix this by properly exiting
> with 77 (which is what automake expects for skipped tests) from
> the tests themselves, then returning 77 again from weston-test-runner
> if all the tests were skipped. Finally the weston-test.so module
> catches weston-test-runner's exit code and uses it as an exit code,
> which is what automake will see and use.
> 
> Signed-off-by: Emilio Pozuelo Monfort 
> ---
>  tests/weston-test-client-helper.c |  8 +---
>  tests/weston-test-runner.c| 41 
> ---
>  tests/weston-test.c   |  6 ++
>  3 files changed, 41 insertions(+), 14 deletions(-)
> 
> diff --git a/tests/weston-test-client-helper.c 
> b/tests/weston-test-client-helper.c
> index 399aa44..186b395 100644
> --- a/tests/weston-test-client-helper.c
> +++ b/tests/weston-test-client-helper.c
> @@ -505,9 +505,11 @@ skip(const char *fmt, ...)
>   vfprintf(stderr, fmt, argp);
>   va_end(argp);
>  
> - /* automake tests uses exit code 77, but we don't have a good
> -  * way to make weston exit with that from here. */
> - exit(0);
> + /* automake tests uses exit code 77. weston-test-runner will see
> +  * this and use it, and then weston-test's sigchld handler (in the
> +  * weston process) will use that as an exit status, which is what
> +  * automake will see in the end. */
> + exit(77);
>  }
>  
>  static void
> diff --git a/tests/weston-test-runner.c b/tests/weston-test-runner.c
> index 4274b39..6307566 100644
> --- a/tests/weston-test-runner.c
> +++ b/tests/weston-test-runner.c
> @@ -32,6 +32,8 @@
>  #include 
>  #include "weston-test-runner.h"
>  
> +#define SKIP 77
> +
>  extern const struct weston_test __start_test_section, __stop_test_section;
>  
>  static const struct weston_test *
> @@ -67,6 +69,7 @@ static int
>  exec_and_report_test(const struct weston_test *t, void *test_data, int 
> iteration)
>  {
>   int success = 0;
> + int skip = 0;
>   int hardfail = 0;
>   siginfo_t info;
>  
> @@ -91,6 +94,8 @@ exec_and_report_test(const struct weston_test *t, void 
> *test_data, int iteration
>   fprintf(stderr, "exit status %d", info.si_status);
>   if (info.si_status == EXIT_SUCCESS)
>   success = 1;
> + else if (info.si_status == SKIP)
> + skip = 1;
>   break;
>   case CLD_KILLED:
>   case CLD_DUMPED:
> @@ -106,7 +111,10 @@ exec_and_report_test(const struct weston_test *t, void 
> *test_data, int iteration
>   if (success && !hardfail) {
>   fprintf(stderr, ", pass.\n");
>   return 1;
> - } else { 
> + } else if (skip) {
> + fprintf(stderr, ", skip.\n");
> + return SKIP;
> + } else {
>   fprintf(stderr, ", fail.\n");
>   return 0;
>   }
> @@ -114,14 +122,17 @@ exec_and_report_test(const struct weston_test *t, void 
> *test_data, int iteration
>  
>  /* Returns number of tests and number of pass / fail in param args */
>  static int
> -iterate_test(const struct weston_test *t, int *passed)
> +iterate_test(const struct weston_test *t, int *passed, int *skipped)
>  {
> - int i;
> + int ret, i;
>   void *current_test_data = (void *) t->table_data;
>   for (i = 0; i < t->n_elements; ++i, current_test_data += 
> t->element_size)
>   {
> - if (exec_and_report_test(t, current_test_data, i))
> + ret = exec_and_report_test(t, current_test_data, i);
> + if (ret == 0)
>   ++(*passed);

Logic here is inversed, the check should be ret == 1. I'll send a fixed patch
tomorrow.

Emilio

> + else if (ret == SKIP)
> + ++(*skipped);
>   }
>  
>   return t->n_elements;
> @@ -132,6 +143,7 @@ int main(int argc, char *argv[])
>   const struct weston_test *t;
>   int total = 0;
>   int pass = 0;
> + int skip = 0;
>  
>   if (argc == 2) {
>   const char *testname = argv[1];
> @@ -149,19 +161,26 @@ int main(int argc, char *argv[])
>   exit(EXIT_FAILURE);
>   }
>  
> - int number_passed_in_test = 0;
> - total += iterate_test(t, &number_passed_in_test);
> + int number_passed_in_test = 0, number_skipped_in_test = 0;
> + total += iterate_test(t, &number_passed_in_test, 
> &number_skipped_in_test);
>   pass += number_passed_in_test;
> + skip += number_skipped_in_test;
>   } else {
>   for (t = &__start_test_section; t < &__stop_test_section; t++) {
> - int number_passed_in_test = 0;
> - total += iterate_test(t, &number_passed_in_test);
> + int number_

Re: [PATCH weston 0/6] Make the headless backend useful again

2014-02-06 Thread Pekka Paalanen
On Thu,  6 Feb 2014 12:30:30 +0100
Emilio Pozuelo Monfort  wrote:

> From: Emilio Pozuelo Monfort 
> 
> This fixes a few bugs in the headless backend, to the point where
> it can run the test suite, except for two issues:
> 
> - the buffer-count is skipped because mesa initialization fails,
>   more details in the patch commit message
> - I haven't been able to properly test the xwayland test as it
>   hangs here (with both headless and x11 backends), probably
>   because my xserver doesn't have xwayland support compiled in.
> 
> Finally the headless backend is used by default, with an easy way
> to use other backends if so desired. This will make it easier to
> have `make check' run in a CI environment, or for distro package
> builds.
> 
> Emilio Pozuelo Monfort (6):
>   compositor-headless: create input devices
>   noop-renderer: Set the buffer size on attach requests
>   noop-renderer: Read the shm buffer contents on attach
>   tests: Skip buffer-count if EGL initialization fails
>   tests: use the headless backend to run the test suite
>   tests: Properly report skipped tests
> 
>  src/compositor-headless.c | 30 
>  src/noop-renderer.c   | 27 ++
>  tests/buffer-count-test.c | 29 +--
>  tests/weston-test-client-helper.c |  8 +---
>  tests/weston-test-runner.c| 41 
> ---
>  tests/weston-test.c   |  6 ++
>  tests/weston-tests-env| 10 --
>  7 files changed, 117 insertions(+), 34 deletions(-)
> 

Hi,

I commented on a couple minor things, but otherwise this series looks
good. Didn't test yet, though.

Hmm, the buffer-count test... I think the EGL init in the test client
would not fail, if you built Mesa with --enable-gallium-egl and swrast
gallium driver (softpipe/llvmpipe). What would the test do then is a
good question, since the client would be using egl_gallium, and the
server just wl_shm.


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


[PATCH mesa 2/3] Add a DRI queryImage attribute to query the offset

2014-02-06 Thread Neil Roberts
This bumps the DRI image extension to version 9 and adds an attribute which
can be used with queryImage to get the image's offset within the buffer. This
will be used with eglCreateWaylandBufferFromImageWL in order to create a
buffer using an image which represents a plane of a planar buffer.
---
 include/GL/internal/dri_interface.h  | 1 +
 src/mesa/drivers/dri/i965/intel_screen.c | 8 +++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index 81f7e60..16ca55f 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -1085,6 +1085,7 @@ struct __DRIdri2ExtensionRec {
 #define __DRI_IMAGE_ATTRIB_FD   0x2007 /* available in versions
 * 7+. Each query will return a
 * new fd. */
+#define __DRI_IMAGE_ATTRIB_OFFSET   0x2008 /* available in versions 9+ */
 
 enum __DRIYUVColorSpace {
__DRI_YUV_COLOR_SPACE_UNDEFINED = 0,
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 7700a4e..cc10ddb 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -553,6 +553,12 @@ intel_query_image(__DRIimage *image, int attrib, int 
*value)
   if (drm_intel_bo_gem_export_to_prime(image->region->bo, value) == 0)
  return true;
   return false;
+   case __DRI_IMAGE_ATTRIB_OFFSET:
+  if (image->planar_format == NULL)
+ *value = image->offset;
+  else
+ *value = image->offsets[0];
+  return true;
   default:
   return false;
}
@@ -788,7 +794,7 @@ intel_from_planar(__DRIimage *parent, int plane, void 
*loaderPrivate)
 }
 
 static struct __DRIimageExtensionRec intelImageExtension = {
-.base = { __DRI_IMAGE, 8 },
+.base = { __DRI_IMAGE, 9 },
 
 .createImageFromName= intel_create_image_from_name,
 .createImageFromRenderbuffer= intel_create_image_from_renderbuffer,
-- 
1.8.5.3

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


[PATCH mesa 3/3] Adapt the EGL_WL_create_wayland_buffer_from_image extension for YUV

2014-02-06 Thread Neil Roberts
The eglCreateWaylandBufferFromImageWL function in the extension is modified so
that instead of just taking a single image it can now take a set of images.
Each EGLImage will represent a plane from a planar image. The overall format
for the combined set of images isn't stored in the EGLImages so instead of
trying to deduce it the function now also has a format parameter. This should
contain the EGLenum returned in the EGL_TEXTURE_FORMAT attribute retreived via
eglQueryWaylandBufferWL. The exact wl_drm_format value to use is deduced from
the EGL format and the size of the images. The number of images passed must
match the number of planes required by the texture format. The EGLImages must
all point to the same buffer and this is determined by checking the names of
the images. If any of these criteria fail then the function will report
EGL_BAD_MATCH.
---
 .../specs/WL_create_wayland_buffer_from_image.spec |  75 +--
 include/EGL/eglmesaext.h   |   4 +-
 src/egl/drivers/dri2/platform_wayland.c| 236 ++---
 src/egl/main/eglapi.c  |  25 ++-
 src/egl/main/eglapi.h  |   2 +-
 5 files changed, 283 insertions(+), 59 deletions(-)

diff --git a/docs/specs/WL_create_wayland_buffer_from_image.spec 
b/docs/specs/WL_create_wayland_buffer_from_image.spec
index aa5eb4d..6595f1a 100644
--- a/docs/specs/WL_create_wayland_buffer_from_image.spec
+++ b/docs/specs/WL_create_wayland_buffer_from_image.spec
@@ -22,7 +22,7 @@ Status
 
 Version
 
-Version 2, October 25, 2013
+Version 3, February 5, 2014
 
 Number
 
@@ -35,20 +35,22 @@ Dependencies
 
 EGL_KHR_base_image is required.
 
+EGL_WL_bind_wayland_display affects the definition of this extension.
+
 Overview
 
 This extension provides an entry point to create a wl_buffer which shares
-its contents with a given EGLImage. The expected use case for this is in a
-nested Wayland compositor which is using subsurfaces to present buffers
-from its clients. Using this extension it can attach the client buffers
-directly to the subsurface without having to blit the contents into an
-intermediate buffer. The compositing can then be done in the parent
-compositor.
-
-The nested compositor can create an EGLImage from a client buffer resource
-using the existing WL_bind_wayland_display extension. It should also be
-possible to create buffers using other types of images although there is
-no expected use case for that.
+its contents with a given set of EGLImages. The expected use case for this
+is in a nested Wayland compositor which is using subsurfaces to present
+buffers from its clients. Using this extension it can attach the client
+buffers directly to the subsurface without having to blit the contents
+into an intermediate buffer. The compositing can then be done in the
+parent compositor.
+
+The nested compositor can create the EGLImages from a client buffer
+resource using the existing WL_bind_wayland_display extension. It should
+also be possible to create buffers using other types of images although
+there is no expected use case for that.
 
 IP Status
 
@@ -57,7 +59,9 @@ IP Status
 New Procedures and Functions
 
 struct wl_buffer *eglCreateWaylandBufferFromImageWL(EGLDisplay dpy,
-EGLImageKHR image);
+EGLenum format,
+EGLImageKHR *images,
+EGLint n_images);
 
 New Tokens
 
@@ -68,27 +72,57 @@ Additions to the EGL 1.4 Specification:
 To create a client-side wl_buffer from an EGLImage call
 
   struct wl_buffer *eglCreateWaylandBufferFromImageWL(EGLDisplay dpy,
-  EGLImageKHR image);
+  EGLenum format,
+  EGLImageKHR *images,
+  EGLint n_images);
 
-The returned buffer will share the contents with the given EGLImage. Any
-updates to the image will also be updated in the wl_buffer. Typically the
-EGLImage will be generated in a nested Wayland compositor using a buffer
+The returned buffer will share the contents with the given EGLImages. Any
+updates to the images will also be updated in the wl_buffer. Typically the
+EGLImages will be generated in a nested Wayland compositor using a buffer
 resource from a client via the EGL_WL_bind_wayland_display extension.
 
+The number of images passed should match the number of planes required for
+the format given in the format parameter. For non-planar formats this will
+just be 1. Each image represents one plane within the buffer.
+
+The forma

[PATCH mesa 1/3] wayland: Keep track of the formats in a sorted array instead of flags

2014-02-06 Thread Neil Roberts
In order to support YUV formats in CreateWaylandBufferFromImageWL we need to
be able to check whether the compositor supports a larger number of formats so
storing them in flags is a bit awkard. Instead all of the formats are now
stored in a sorted array using wl_array. A binary search is used to check for
the format.
---
 src/egl/drivers/dri2/egl_dri2.h |  2 +-
 src/egl/drivers/dri2/platform_wayland.c | 85 -
 2 files changed, 64 insertions(+), 23 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index dfc5927..3f90582 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -131,7 +131,7 @@ struct dri2_egl_display
struct wl_drm*wl_drm;
struct wl_event_queue*wl_queue;
int  authenticated;
-   int  formats;
+   struct wl_array   formats;
uint32_t  capabilities;
 #endif
 
diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 50750a9..089ed62 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -41,12 +41,6 @@
 #include 
 #include "wayland-drm-client-protocol.h"
 
-enum wl_drm_format_flags {
-   HAS_ARGB = 1,
-   HAS_XRGB = 2,
-   HAS_RGB565 = 4,
-};
-
 static void
 sync_callback(void *data, struct wl_callback *callback, uint32_t serial)
 {
@@ -679,6 +673,31 @@ dri2_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *draw)
return dri2_swap_buffers_with_damage (drv, disp, draw, NULL, 0);
 }
 
+static EGLBoolean
+dri2_can_handle_format(struct dri2_egl_display *dri2_dpy,
+   enum wl_drm_format format)
+{
+   const enum wl_drm_format *formats;
+   int min, mid, max;
+
+   /* Binary search for the format */
+   min = 0;
+   max = dri2_dpy->formats.size / sizeof (enum wl_drm_format);
+   formats = dri2_dpy->formats.data;
+
+   while (max > min) {
+  mid = (max + min) / 2;
+  if (formats[mid] < format)
+ min = mid + 1;
+  else if (formats[mid] > format)
+ max = mid;
+  else
+ return EGL_TRUE;
+   }
+
+   return EGL_FALSE;
+}
+
 static struct wl_buffer *
 dri2_create_wayland_buffer_from_image_wl(_EGLDriver *drv,
  _EGLDisplay *disp,
@@ -695,12 +714,12 @@ dri2_create_wayland_buffer_from_image_wl(_EGLDriver *drv,
 
switch (format) {
case __DRI_IMAGE_FORMAT_ARGB:
-  if (!(dri2_dpy->formats & HAS_ARGB))
+  if (!dri2_can_handle_format(dri2_dpy, WL_DRM_FORMAT_ARGB))
  goto bad_format;
   wl_format = WL_DRM_FORMAT_ARGB;
   break;
case __DRI_IMAGE_FORMAT_XRGB:
-  if (!(dri2_dpy->formats & HAS_XRGB))
+  if (!dri2_can_handle_format(dri2_dpy, WL_DRM_FORMAT_XRGB))
  goto bad_format;
   wl_format = WL_DRM_FORMAT_XRGB;
   break;
@@ -794,6 +813,7 @@ dri2_terminate(_EGLDriver *drv, _EGLDisplay *disp)
wl_drm_destroy(dri2_dpy->wl_drm);
if (dri2_dpy->own_device)
   wl_display_disconnect(dri2_dpy->wl_dpy);
+   wl_array_release(&dri2_dpy->formats);
free(dri2_dpy);
disp->DriverData = NULL;
 
@@ -834,18 +854,36 @@ static void
 drm_handle_format(void *data, struct wl_drm *drm, uint32_t format)
 {
struct dri2_egl_display *dri2_dpy = data;
-
-   switch (format) {
-   case WL_DRM_FORMAT_ARGB:
-  dri2_dpy->formats |= HAS_ARGB;
-  break;
-   case WL_DRM_FORMAT_XRGB:
-  dri2_dpy->formats |= HAS_XRGB;
-  break;
-   case WL_DRM_FORMAT_RGB565:
-  dri2_dpy->formats |= HAS_RGB565;
-  break;
+   enum wl_drm_format *formats = dri2_dpy->formats.data;
+   int n_formats;
+   int min, mid, max;
+
+   n_formats = dri2_dpy->formats.size / sizeof (enum wl_drm_format);
+
+   /* Search for the insert position to keep the format array sorted */
+   min = 0;
+   max = n_formats;
+
+   while (max > min) {
+  mid = (max + min) / 2;
+  if (formats[mid] < format)
+ min = mid + 1;
+  else if (formats[mid] > format)
+ max = mid;
+  else
+ return;
}
+
+   if (wl_array_add(&dri2_dpy->formats, sizeof (enum wl_drm_format)) == NULL)
+  return;
+
+   formats = dri2_dpy->formats.data;
+
+   /* Move the subsequent formats out of the way */
+   memmove(formats + min + 1,
+   formats + min,
+   (n_formats - min) * sizeof *formats);
+   formats[min] = format;
 }
 
 static void
@@ -980,6 +1018,8 @@ dri2_initialize_wayland(_EGLDriver *drv, _EGLDisplay *disp)
if (!dri2_dpy)
   return _eglError(EGL_BAD_ALLOC, "eglInitialize");
 
+   wl_array_init(&dri2_dpy->formats);
+
disp->DriverData = (void *) dri2_dpy;
if (disp->PlatformDisplay == NULL) {
   dri2_dpy->wl_dpy = wl_display_connect(NULL);
@@ -1050,11 +1090,11 @@ dri2_initialize_wayland(_EGLDriver *drv, _EGLDisplay 
*disp)
types = EGL_WINDOW_BIT;
for (i = 0; dri2_dpy->driv

[PATCH mesa 0/3] Add YUV support for the subcompositor buffer passthrough

2014-02-06 Thread Neil Roberts
Hi,

I had a look at trying to get the
EGL_WL_create_wayland_buffer_from_image extension to support YUV
buffers. The main difficulty is that we don't get a single EGLimage
when using a planar buffer with the EGL_WL_bind_wayland_display
extension and instead we get a separate image for each plane. I've
just gone ahead and changed the eglCreateWaylandBufferFromImageWL
function to take an array of images instead of a single one. However,
I'm not sure what the policy is on changing this extension. Is it too
late now that the extension is in the 10.1 branch?

I also added an attribute to the DRIImage extension to query the
offset. This bumps the extension version to 9 and if we are changing
the version it might be a good idea to combine that with adding the
interface to create a sub-image in this patch:

https://github.com/bpeel/mesa/commit/217582b81d0d752636812b3ce386c768

On the other hand I don't really know what the policy is for updating
the DRIimage extension. Does it matter how many times we increase the
version?

Regards,
- Neil

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


Re: [PATCH weston 3/6] noop-renderer: Read the shm buffer contents on attach

2014-02-06 Thread Pekka Paalanen
On Thu,  6 Feb 2014 12:30:33 +0100
Emilio Pozuelo Monfort  wrote:

> From: Emilio Pozuelo Monfort 
> 
> The noop-renderer doesn't read buffer contents, which means bad
> buffers go undetected. Thus, read the buffer contents just for
> the purpose of triggering SIGBUS (and having the client killed).
> 
> Fixed bad-buffer test when run against the headless backend.
> 
> Signed-off-by: Emilio Pozuelo Monfort 
> ---
>  src/noop-renderer.c | 21 +++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/src/noop-renderer.c b/src/noop-renderer.c
> index cf1a7f2..5da0b20 100644
> --- a/src/noop-renderer.c
> +++ b/src/noop-renderer.c
> @@ -23,6 +23,7 @@
>  #include "config.h"
>  
>  #include 
> +#include 
>  
>  #include "compositor.h"
>  
> @@ -50,15 +51,31 @@ static void
>  noop_renderer_attach(struct weston_surface *es, struct weston_buffer *buffer)
>  {
>   struct wl_shm_buffer *shm_buffer;
> + uint8_t *data;
> + uint32_t size, width, height, stride;
>  
>   if (!buffer)
>   return;
>  
>   shm_buffer = wl_shm_buffer_get(buffer->resource);
>  
> + data = wl_shm_buffer_get_data(shm_buffer);
> + stride = wl_shm_buffer_get_stride(shm_buffer);
> + width = wl_shm_buffer_get_width(shm_buffer);
> + height = wl_shm_buffer_get_height(shm_buffer);
> + size = stride * height;
> +
> + /* Access the buffer data to make sure the buffer's client gets killed
> +  * if the buffer size is invalid. This makes the bad_buffer test pass.
> +  * This can be removed if we start reading the buffer contents
> +  * somewhere else, e.g. in repaint_output(). */
> + wl_shm_buffer_begin_access(shm_buffer);
> + memset(data, 0, size);
> + wl_shm_buffer_end_access(shm_buffer);
> +
>   buffer->shm_buffer = shm_buffer;
> - buffer->width = wl_shm_buffer_get_width(shm_buffer);
> - buffer->height = wl_shm_buffer_get_height(shm_buffer);
> + buffer->width = width;
> + buffer->height = height;
>  }
>  
>  static void

Hi,

heh, nice, although *writing* to the client's buffer here is very
naughty. ;-)

I'd prefer a reading loop here instead of memset.


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


Re: [PATCH weston 2/6] noop-renderer: Set the buffer size on attach requests

2014-02-06 Thread Pekka Paalanen
On Thu,  6 Feb 2014 12:30:32 +0100
Emilio Pozuelo Monfort  wrote:

> From: Emilio Pozuelo Monfort 
> 
> This lets the compositor know the size of the surface as calculated
> in weston_surface_set_size_from_buffer(), and fixes a couple of
> tests when using the headless backend.
> 
> Signed-off-by: Emilio Pozuelo Monfort 
> ---
>  src/noop-renderer.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/src/noop-renderer.c b/src/noop-renderer.c
> index ad750b5..cf1a7f2 100644
> --- a/src/noop-renderer.c
> +++ b/src/noop-renderer.c
> @@ -49,6 +49,16 @@ noop_renderer_flush_damage(struct weston_surface
> *surface) static void
>  noop_renderer_attach(struct weston_surface *es, struct weston_buffer
> *buffer) {
> + struct wl_shm_buffer *shm_buffer;
> +
> + if (!buffer)
> + return;
> +
> + shm_buffer = wl_shm_buffer_get(buffer->resource);
> +
> + buffer->shm_buffer = shm_buffer;
> + buffer->width = wl_shm_buffer_get_width(shm_buffer);
> + buffer->height = wl_shm_buffer_get_height(shm_buffer);
>  }
>  
>  static void

Hi,

if we ever manage to create non-wl_shm buffers and end up here,
wl_shm_buffer_get() will return NULL. It may become a problem if the
headless backend ever grows EGL support. But until then, I'm ok with
this.


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


[PATCH weston 6/6] tests: Properly report skipped tests

2014-02-06 Thread Emilio Pozuelo Monfort
From: Emilio Pozuelo Monfort 

We were calling exit(0) when tests were skipped, which counted
them as passed instead of skipped. Fix this by properly exiting
with 77 (which is what automake expects for skipped tests) from
the tests themselves, then returning 77 again from weston-test-runner
if all the tests were skipped. Finally the weston-test.so module
catches weston-test-runner's exit code and uses it as an exit code,
which is what automake will see and use.

Signed-off-by: Emilio Pozuelo Monfort 
---
 tests/weston-test-client-helper.c |  8 +---
 tests/weston-test-runner.c| 41 ---
 tests/weston-test.c   |  6 ++
 3 files changed, 41 insertions(+), 14 deletions(-)

diff --git a/tests/weston-test-client-helper.c 
b/tests/weston-test-client-helper.c
index 399aa44..186b395 100644
--- a/tests/weston-test-client-helper.c
+++ b/tests/weston-test-client-helper.c
@@ -505,9 +505,11 @@ skip(const char *fmt, ...)
vfprintf(stderr, fmt, argp);
va_end(argp);
 
-   /* automake tests uses exit code 77, but we don't have a good
-* way to make weston exit with that from here. */
-   exit(0);
+   /* automake tests uses exit code 77. weston-test-runner will see
+* this and use it, and then weston-test's sigchld handler (in the
+* weston process) will use that as an exit status, which is what
+* automake will see in the end. */
+   exit(77);
 }
 
 static void
diff --git a/tests/weston-test-runner.c b/tests/weston-test-runner.c
index 4274b39..6307566 100644
--- a/tests/weston-test-runner.c
+++ b/tests/weston-test-runner.c
@@ -32,6 +32,8 @@
 #include 
 #include "weston-test-runner.h"
 
+#define SKIP 77
+
 extern const struct weston_test __start_test_section, __stop_test_section;
 
 static const struct weston_test *
@@ -67,6 +69,7 @@ static int
 exec_and_report_test(const struct weston_test *t, void *test_data, int 
iteration)
 {
int success = 0;
+   int skip = 0;
int hardfail = 0;
siginfo_t info;
 
@@ -91,6 +94,8 @@ exec_and_report_test(const struct weston_test *t, void 
*test_data, int iteration
fprintf(stderr, "exit status %d", info.si_status);
if (info.si_status == EXIT_SUCCESS)
success = 1;
+   else if (info.si_status == SKIP)
+   skip = 1;
break;
case CLD_KILLED:
case CLD_DUMPED:
@@ -106,7 +111,10 @@ exec_and_report_test(const struct weston_test *t, void 
*test_data, int iteration
if (success && !hardfail) {
fprintf(stderr, ", pass.\n");
return 1;
-   } else { 
+   } else if (skip) {
+   fprintf(stderr, ", skip.\n");
+   return SKIP;
+   } else {
fprintf(stderr, ", fail.\n");
return 0;
}
@@ -114,14 +122,17 @@ exec_and_report_test(const struct weston_test *t, void 
*test_data, int iteration
 
 /* Returns number of tests and number of pass / fail in param args */
 static int
-iterate_test(const struct weston_test *t, int *passed)
+iterate_test(const struct weston_test *t, int *passed, int *skipped)
 {
-   int i;
+   int ret, i;
void *current_test_data = (void *) t->table_data;
for (i = 0; i < t->n_elements; ++i, current_test_data += 
t->element_size)
{
-   if (exec_and_report_test(t, current_test_data, i))
+   ret = exec_and_report_test(t, current_test_data, i);
+   if (ret == 0)
++(*passed);
+   else if (ret == SKIP)
+   ++(*skipped);
}
 
return t->n_elements;
@@ -132,6 +143,7 @@ int main(int argc, char *argv[])
const struct weston_test *t;
int total = 0;
int pass = 0;
+   int skip = 0;
 
if (argc == 2) {
const char *testname = argv[1];
@@ -149,19 +161,26 @@ int main(int argc, char *argv[])
exit(EXIT_FAILURE);
}
 
-   int number_passed_in_test = 0;
-   total += iterate_test(t, &number_passed_in_test);
+   int number_passed_in_test = 0, number_skipped_in_test = 0;
+   total += iterate_test(t, &number_passed_in_test, 
&number_skipped_in_test);
pass += number_passed_in_test;
+   skip += number_skipped_in_test;
} else {
for (t = &__start_test_section; t < &__stop_test_section; t++) {
-   int number_passed_in_test = 0;
-   total += iterate_test(t, &number_passed_in_test);
+   int number_passed_in_test = 0, number_skipped_in_test = 
0;
+   total += iterate_test(t, &number_passed_in_test, 
&number_skipped_in_test);
pass += number_passed_in_test;
+   skip += number_skipped_in_test;
}

[PATCH weston 0/6] Make the headless backend useful again

2014-02-06 Thread Emilio Pozuelo Monfort
From: Emilio Pozuelo Monfort 

This fixes a few bugs in the headless backend, to the point where
it can run the test suite, except for two issues:

- the buffer-count is skipped because mesa initialization fails,
  more details in the patch commit message
- I haven't been able to properly test the xwayland test as it
  hangs here (with both headless and x11 backends), probably
  because my xserver doesn't have xwayland support compiled in.

Finally the headless backend is used by default, with an easy way
to use other backends if so desired. This will make it easier to
have `make check' run in a CI environment, or for distro package
builds.

Emilio Pozuelo Monfort (6):
  compositor-headless: create input devices
  noop-renderer: Set the buffer size on attach requests
  noop-renderer: Read the shm buffer contents on attach
  tests: Skip buffer-count if EGL initialization fails
  tests: use the headless backend to run the test suite
  tests: Properly report skipped tests

 src/compositor-headless.c | 30 
 src/noop-renderer.c   | 27 ++
 tests/buffer-count-test.c | 29 +--
 tests/weston-test-client-helper.c |  8 +---
 tests/weston-test-runner.c| 41 ---
 tests/weston-test.c   |  6 ++
 tests/weston-tests-env| 10 --
 7 files changed, 117 insertions(+), 34 deletions(-)

-- 
1.8.5.3

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


[PATCH weston 4/6] tests: Skip buffer-count if EGL initialization fails

2014-02-06 Thread Emilio Pozuelo Monfort
From: Emilio Pozuelo Monfort 

That is the case when using the headless backend. In the future
we may be able to use the mesa null egl platform but for now let's
just skip it.

Signed-off-by: Emilio Pozuelo Monfort 
---
 tests/buffer-count-test.c | 29 +++--
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/tests/buffer-count-test.c b/tests/buffer-count-test.c
index c7ddeb6..dfc4673 100644
--- a/tests/buffer-count-test.c
+++ b/tests/buffer-count-test.c
@@ -31,6 +31,8 @@
 #include 
 #include 
 
+#define fail(msg) { fprintf(stderr, "%s failed\n", msg); return -1; }
+
 struct test_data {
struct client *client;
 
@@ -40,7 +42,7 @@ struct test_data {
EGLSurface egl_surface;
 };
 
-static void
+static int
 init_egl(struct test_data *test_data)
 {
struct wl_egl_window *native_window;
@@ -67,21 +69,24 @@ init_egl(struct test_data *test_data)
 
test_data->egl_dpy = eglGetDisplay((EGLNativeDisplayType)
   test_data->client->wl_display);
-   assert(test_data->egl_dpy);
+   if (!test_data->egl_dpy)
+   fail("eglGetDisplay");
 
-   ret = eglInitialize(test_data->egl_dpy, &major, &minor);
-   assert(ret == EGL_TRUE);
-   ret = eglBindAPI(EGL_OPENGL_ES_API);
-   assert(ret == EGL_TRUE);
+   if (eglInitialize(test_data->egl_dpy, &major, &minor) != EGL_TRUE)
+   fail("eglInitialize");
+   if (eglBindAPI(EGL_OPENGL_ES_API) != EGL_TRUE)
+   fail("eglBindAPI");
 
ret = eglChooseConfig(test_data->egl_dpy, config_attribs,
  &test_data->egl_conf, 1, &n);
-   assert(ret && n == 1);
+   if (!(ret && n == 1))
+   fail("eglChooseConfig");
 
test_data->egl_ctx = eglCreateContext(test_data->egl_dpy,
  test_data->egl_conf,
  EGL_NO_CONTEXT, context_attribs);
-   assert(test_data->egl_ctx);
+   if (!test_data->egl_ctx)
+   fail("eglCreateContext");
 
native_window =
wl_egl_window_create(surface->wl_surface,
@@ -95,7 +100,8 @@ init_egl(struct test_data *test_data)
 
ret = eglMakeCurrent(test_data->egl_dpy, test_data->egl_surface,
 test_data->egl_surface, test_data->egl_ctx);
-   assert(ret == EGL_TRUE);
+   if (ret != EGL_TRUE)
+   fail("eglMakeCurrent");
 
/* This test is specific to mesa 10.1 and later, which is the
 * first release that doesn't accidentally triple-buffer. */
@@ -108,6 +114,7 @@ init_egl(struct test_data *test_data)
if (major < 10 || (major == 10 && minor < 1))
skip("mesa version too old (%s)\n", str);
 
+   return 0;
 }
 
 TEST(test_buffer_count)
@@ -117,7 +124,9 @@ TEST(test_buffer_count)
int i;
 
test_data.client = client_create(10, 10, 10, 10);
-   init_egl(&test_data);
+   if (init_egl(&test_data) < 0)
+   skip("could not initialize egl, "
+"possibly using the headless backend\n");
 
/* This is meant to represent a typical game loop which is
 * expecting eglSwapBuffers to block and throttle the
-- 
1.8.5.3

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


[PATCH weston 1/6] compositor-headless: create input devices

2014-02-06 Thread Emilio Pozuelo Monfort
From: Emilio Pozuelo Monfort 

Fixes a segfault when using compositor-headless for the test suite
as many tests assume there are input devices and try to use them
through the wl_test interface.

Signed-off-by: Emilio Pozuelo Monfort 
---
 src/compositor-headless.c | 30 ++
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/src/compositor-headless.c b/src/compositor-headless.c
index 5a5c1e6..4ecb8d4 100644
--- a/src/compositor-headless.c
+++ b/src/compositor-headless.c
@@ -131,6 +131,25 @@ headless_compositor_create_output(struct 
headless_compositor *c,
return 0;
 }
 
+static int
+headless_input_create(struct headless_compositor *c)
+{
+   weston_seat_init(&c->fake_seat, &c->base, "default");
+
+   weston_seat_init_pointer(&c->fake_seat);
+
+   if (weston_seat_init_keyboard(&c->fake_seat, NULL) < 0)
+   return -1;
+
+   return 0;
+}
+
+static void
+headless_input_destroy(struct headless_compositor *c)
+{
+   weston_seat_release(&c->fake_seat);
+}
+
 static void
 headless_restore(struct weston_compositor *ec)
 {
@@ -141,7 +160,7 @@ headless_destroy(struct weston_compositor *ec)
 {
struct headless_compositor *c = (struct headless_compositor *) ec;
 
-   weston_seat_release(&c->fake_seat);
+   headless_input_destroy(c);
weston_compositor_shutdown(ec);
 
free(ec);
@@ -162,19 +181,22 @@ headless_compositor_create(struct wl_display *display,
if (weston_compositor_init(&c->base, display, argc, argv, config) < 0)
goto err_free;
 
-   weston_seat_init(&c->fake_seat, &c->base, "default");
+   if (headless_input_create(c) < 0)
+   goto err_compositor;
 
c->base.destroy = headless_destroy;
c->base.restore = headless_restore;
 
if (headless_compositor_create_output(c, width, height) < 0)
-   goto err_compositor;
+   goto err_input;
 
if (noop_renderer_init(&c->base) < 0)
-   goto err_compositor;
+   goto err_input;
 
return &c->base;
 
+err_input:
+   headless_input_destroy(c);
 err_compositor:
weston_compositor_shutdown(&c->base);
 err_free:
-- 
1.8.5.3

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


[PATCH weston 2/6] noop-renderer: Set the buffer size on attach requests

2014-02-06 Thread Emilio Pozuelo Monfort
From: Emilio Pozuelo Monfort 

This lets the compositor know the size of the surface as calculated
in weston_surface_set_size_from_buffer(), and fixes a couple of
tests when using the headless backend.

Signed-off-by: Emilio Pozuelo Monfort 
---
 src/noop-renderer.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/noop-renderer.c b/src/noop-renderer.c
index ad750b5..cf1a7f2 100644
--- a/src/noop-renderer.c
+++ b/src/noop-renderer.c
@@ -49,6 +49,16 @@ noop_renderer_flush_damage(struct weston_surface *surface)
 static void
 noop_renderer_attach(struct weston_surface *es, struct weston_buffer *buffer)
 {
+   struct wl_shm_buffer *shm_buffer;
+
+   if (!buffer)
+   return;
+
+   shm_buffer = wl_shm_buffer_get(buffer->resource);
+
+   buffer->shm_buffer = shm_buffer;
+   buffer->width = wl_shm_buffer_get_width(shm_buffer);
+   buffer->height = wl_shm_buffer_get_height(shm_buffer);
 }
 
 static void
-- 
1.8.5.3

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


[PATCH weston 5/6] tests: use the headless backend to run the test suite

2014-02-06 Thread Emilio Pozuelo Monfort
From: Emilio Pozuelo Monfort 

Other backends can be used by passing BACKEND=some-backend.so, e.g.

$ make check BACKEND=x11-backend.so

Signed-off-by: Emilio Pozuelo Monfort 
---
 tests/weston-tests-env | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/tests/weston-tests-env b/tests/weston-tests-env
index 04b91a9..9180053 100755
--- a/tests/weston-tests-env
+++ b/tests/weston-tests-env
@@ -17,14 +17,12 @@ OUTLOG="$LOGDIR/$1-log.txt"
 
 rm -f "$SERVERLOG"
 
-if test x$WAYLAND_DISPLAY != x; then
-   BACKEND=$abs_builddir/.libs/wayland-backend.so
-elif test x$DISPLAY != x; then
-   BACKEND=$abs_builddir/.libs/x11-backend.so
-else
-   BACKEND=$abs_builddir/.libs/wayland-backend.so
+if test -z "$BACKEND"; then
+   BACKEND=headless-backend.so
 fi
 
+BACKEND=$abs_builddir/.libs/$BACKEND
+
 case $TESTNAME in
*.la|*.so)
$WESTON --backend=$BACKEND \
-- 
1.8.5.3

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


[PATCH weston 3/6] noop-renderer: Read the shm buffer contents on attach

2014-02-06 Thread Emilio Pozuelo Monfort
From: Emilio Pozuelo Monfort 

The noop-renderer doesn't read buffer contents, which means bad
buffers go undetected. Thus, read the buffer contents just for
the purpose of triggering SIGBUS (and having the client killed).

Fixed bad-buffer test when run against the headless backend.

Signed-off-by: Emilio Pozuelo Monfort 
---
 src/noop-renderer.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/src/noop-renderer.c b/src/noop-renderer.c
index cf1a7f2..5da0b20 100644
--- a/src/noop-renderer.c
+++ b/src/noop-renderer.c
@@ -23,6 +23,7 @@
 #include "config.h"
 
 #include 
+#include 
 
 #include "compositor.h"
 
@@ -50,15 +51,31 @@ static void
 noop_renderer_attach(struct weston_surface *es, struct weston_buffer *buffer)
 {
struct wl_shm_buffer *shm_buffer;
+   uint8_t *data;
+   uint32_t size, width, height, stride;
 
if (!buffer)
return;
 
shm_buffer = wl_shm_buffer_get(buffer->resource);
 
+   data = wl_shm_buffer_get_data(shm_buffer);
+   stride = wl_shm_buffer_get_stride(shm_buffer);
+   width = wl_shm_buffer_get_width(shm_buffer);
+   height = wl_shm_buffer_get_height(shm_buffer);
+   size = stride * height;
+
+   /* Access the buffer data to make sure the buffer's client gets killed
+* if the buffer size is invalid. This makes the bad_buffer test pass.
+* This can be removed if we start reading the buffer contents
+* somewhere else, e.g. in repaint_output(). */
+   wl_shm_buffer_begin_access(shm_buffer);
+   memset(data, 0, size);
+   wl_shm_buffer_end_access(shm_buffer);
+
buffer->shm_buffer = shm_buffer;
-   buffer->width = wl_shm_buffer_get_width(shm_buffer);
-   buffer->height = wl_shm_buffer_get_height(shm_buffer);
+   buffer->width = width;
+   buffer->height = height;
 }
 
 static void
-- 
1.8.5.3

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


Re: Xserver errors

2014-02-06 Thread Bill Spitzak

Got it a little further, but now wayland does not run at all.

I was able to compile mesa with the following (adding 
--with-dri-drivers= --disable-dri3):


./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 \

  --with-dri-drivers= --disable-dri3

Then was able to compile xserver.

But now running wayland produces this:

Program received signal SIGSEGV, Segmentation fault.
0x71b940e8 in egl_g3d_get_proc_address (drv=,
procname=0x73ff6d55 "glEGLImageTargetTexture2DOES")
at common/egl_g3d.c:637

Full output:

Starting program: /home/spitzak/install/bin/weston
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Date: 2014-02-06 PST
[00:15:22.778] weston 1.4.0
   http://wayland.freedesktop.org/
   Bug reports to: 
https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.4.0
   Build: 1.4.0-59-gc94d622 compositor: Move view 
repositioning logic into shell (2014-02-05 17:36:00 -0800)
[00:15:22.778] OS: Linux, 3.2.0-58-generic, #88-Ubuntu SMP Tue Dec 3 
17:37:58 UTC 2013, x86_64

[00:15:22.778] warning: XDG_RUNTIME_DIR "/run/shm" is not configured
correctly.  Unix access mode must be 0700 (current mode is 777),
and must be owned by the user (current owner is UID 0).
Refer to your distribution on how to get it, or
http://www.freedesktop.org/wiki/Specifications/basedir-spec
on how to implement it.
[00:15:22.778] Using config file '/home/spitzak/.config/weston.ini'
[00:15:22.778] Loading module 
'/home/spitzak/install/lib/weston/x11-backend.so'

[00:15:23.047] initializing x11 backend
[00:15:23.048] Loading module 
'/home/spitzak/install/lib/weston/gl-renderer.so'

libEGL warning: DRI2: failed to authenticate
[New Thread 0x7fffef473700 (LWP 8319)]
[New Thread 0x7fffeec72700 (LWP 8320)]
[New Thread 0x7fffee471700 (LWP 8321)]
[New Thread 0x7fffedc70700 (LWP 8322)]
[00:15:24.400] Using gl renderer
[00:15:24.400] launching '/usr/libexec/weston-keyboard'
[00:15:24.401] compositor: executing '/usr/libexec/weston-keyboard' 
failed: No such file or directory

[00:15:24.410] XCB-XKB not available during build
[00:15:24.411] Chosen EGL config details:
   RGBA bits: 8 8 8 0
   swap interval range: 0 - 0
[00:15:24.420] EGL version: 1.4 (DRI2)
[00:15:24.420] EGL vendor: Mesa Project
[00:15:24.420] EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2 OpenGL_ES3
[00:15:24.420] EGL extensions: EGL_KHR_surfaceless_context
[00:15:24.420] GL version: OpenGL ES 3.0 Mesa 10.2.0-devel (git-57f94bf)
[00:15:24.420] GLSL version: OpenGL ES GLSL ES 3.0
[00:15:24.420] GL vendor: VMware, Inc.
[00:15:24.420] GL renderer: Gallium 0.4 on llvmpipe (LLVM 2.9, 128 bits)
[00:15:24.420] GL extensions: GL_EXT_blend_minmax GL_EXT_multi_draw_arrays
   GL_EXT_texture_format_BGRA
   GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24
   GL_OES_element_index_uint GL_OES_fbo_render_mipmap
   GL_OES_mapbuffer GL_OES_rgb8_rgba8 
GL_OES_standard_derivatives

   GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_npot
   GL_OES_EGL_image GL_OES_depth_texture
   GL_OES_packed_depth_stencil 
GL_EXT_texture_type_2_10_10_10_REV

   GL_OES_get_program_binary GL_APPLE_texture_max_level
   GL_EXT_discard_framebuffer GL_EXT_read_format_bgra
   GL_NV_fbo_color_attachments GL_OES_EGL_image_external
   GL_OES_vertex_array_object GL_EXT_texture_rg
   GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer
   GL_EXT_map_buffer_range GL_OES_depth_texture_cube_map
   GL_OES_surfaceless_context GL_EXT_color_buffer_float

Program received signal SIGSEGV, Segmentation fault.
0x71b940e8 in egl_g3d_get_proc_address (drv=,
procname=0x73ff6d55 "glEGLImageTargetTexture2DOES")
at common/egl_g3d.c:637
warning: Source file is more recent than executable.

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


Re: Fwd: [GSoC2014] Call for projects ideas and mentors

2014-02-06 Thread Alexander E. Patrakov
Martin Peres wrote:
> 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.org, x...@lists.x.org, nouveau
> 
> 
> 
> 
> Hi, fellow graphics stack developers,
> 
> Now that FOSDEM is over, it is time to think about the
> Google Summer of Code 2014!
> 
> If you would like to propose a project for the GSoC 2014, please
> write your proposals at [1], before the 14th of February, in order
> to increase our chances of being an accepted organization.
> 
> If you simply would potentially be interested in being a mentor,
> please also contact me as Google wants to have an estimate of
> the number of potential mentors we would have.

I think that a possible project for someone would be to implement the 
functionality in libinput (or possibly via uinput) where a fingerprint reader 
could act as a scroll wheel for the touchpad. This functionality is common on 
Windows laptops, but completely missing in the Linux input stack. Yes, 
alternative scroll methods exist, so this is low-priority.

One complication would be to ensure that the primary (authentication-related) 
functionality of the fingerprint reader is preserved.

Note: I am not a student, and won't qualify as a mentor, either. So this is 
just an abstract idea for somebody to pick up.

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