Re: Unable to build Weston (configure: error: wayland-scanner is needed to compile weston).
Hello. On 10/30/2013 01:48 PM, Artsiom Anikeyenka wrote: Any help on that? I'm not good at GNU build tools so it's hard to me to figure out the reason. I'll be working on that, but maybe meanwhile you'll give me a hint? Where do you install wayland after building? To me it seems the place where you install it to is not in you PATH for the bin folder. You might need something like this: export PATH=$PATH:$WLD/bin where $WLD is the path you install wayland in. regards Stefan Schmidt ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/7] xwayland: Remove unused call weston_wm_handle_configure_notify.
We get the child position but never use this information here. Just remove it.
Spotted by Christopher Michael.
Signed-off-by: Stefan Schmidt s.schm...@samsung.com
---
src/xwayland/window-manager.c |2 --
1 file changed, 2 deletions(-)
diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
index 2c1c9e0..ef59e6d 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -609,7 +609,6 @@ weston_wm_handle_configure_notify(struct weston_wm *wm,
xcb_generic_event_t *eve
xcb_configure_notify_event_t *configure_notify =
(xcb_configure_notify_event_t *) event;
struct weston_wm_window *window;
- int x, y;
wm_log(XCB_CONFIGURE_NOTIFY (window %d) %d,%d @ %dx%d\n,
configure_notify-window,
@@ -617,7 +616,6 @@ weston_wm_handle_configure_notify(struct weston_wm *wm,
xcb_generic_event_t *eve
configure_notify-width, configure_notify-height);
window = hash_table_lookup(wm-window_hash, configure_notify-window);
- weston_wm_window_get_child_position(window, x, y);
window-x = configure_notify-x;
window-y = configure_notify-y;
if (window-override_redirect) {
--
1.7.9.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 2/7] clients: Update .gitignore for weston-multi-resource
Signed-off-by: Stefan Schmidt s.schm...@samsung.com --- clients/.gitignore |1 + 1 file changed, 1 insertion(+) diff --git a/clients/.gitignore b/clients/.gitignore index aa5e53c..23959cc 100644 --- a/clients/.gitignore +++ b/clients/.gitignore @@ -41,6 +41,7 @@ weston-screensaver weston-screenshooter weston-tablet-shell weston-terminal +weston-multi-resource workspaces-client-protocol.h workspaces-protocol.c weston-simple-im -- 1.7.9.5 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/7] xwayland: Remove unused call weston_wm_handle_configure_notify.
Hello. Ignore the 7 in the patchset count its only these two patches. regards Stefan Schmidt ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] clients: Include and link against math lib for new multi-resource
Linking failed with missing ceil() here. Making sure that we include the header and add the missing -lm. Signed-off-by: Stefan Schmidt s.schm...@samsung.com --- clients/Makefile.am |2 +- clients/multi-resource.c |1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/clients/Makefile.am b/clients/Makefile.am index d4bee2a..4f9dc48 100644 --- a/clients/Makefile.am +++ b/clients/Makefile.am @@ -51,7 +51,7 @@ weston_multi_resource_SOURCES = multi-resource.c \ ../shared/os-compatibility.c\ ../shared/os-compatibility.h weston_multi_resource_CPPFLAGS = $(SIMPLE_CLIENT_CFLAGS) -weston_multi_resource_LDADD = $(SIMPLE_CLIENT_LIBS) +weston_multi_resource_LDADD = $(SIMPLE_CLIENT_LIBS) -lm endif if BUILD_SIMPLE_EGL_CLIENTS diff --git a/clients/multi-resource.c b/clients/multi-resource.c index 1c2e5c9..6f93618 100644 --- a/clients/multi-resource.c +++ b/clients/multi-resource.c @@ -35,6 +35,7 @@ #include time.h #include sys/poll.h #include float.h +#include math.h #include wayland-client.h #include ../shared/os-compatibility.h -- 1.7.9.5 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] input: Fix trailing whitspaces and indent.
Just some cosmetics to conform to the wayland coding style.
Signed-off-by: Stefan Schmidt s.schm...@samsung.com
---
src/input.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/input.c b/src/input.c
index 9c30460..fb5bfee 100644
--- a/src/input.c
+++ b/src/input.c
@@ -238,7 +238,7 @@ find_resource_for_surface(struct wl_list *list, struct
weston_surface *surface)
if (!surface-resource)
return NULL;
-
+
return wl_resource_find_for_client(list,
wl_resource_get_client(surface-resource));
}
@@ -344,7 +344,7 @@ weston_keyboard_create(void)
keyboard = zalloc(sizeof *keyboard);
if (keyboard == NULL)
- return NULL;
+ return NULL;
wl_list_init(keyboard-resource_list);
wl_array_init(keyboard-keys);
@@ -1350,7 +1350,7 @@ weston_compositor_xkb_init(struct weston_compositor *ec,
return 0;
}
-static void
+static void
weston_xkb_info_destroy(struct weston_xkb_info *xkb_info)
{
if (--xkb_info-ref_count 0)
@@ -1381,7 +1381,7 @@ weston_compositor_xkb_destroy(struct weston_compositor
*ec)
free((char *) ec-xkb_names.layout);
free((char *) ec-xkb_names.variant);
free((char *) ec-xkb_names.options);
-
+
if (ec-xkb_info)
weston_xkb_info_destroy(ec-xkb_info);
xkb_context_unref(ec-xkb_context);
@@ -1479,7 +1479,7 @@ weston_compositor_build_global_keymap(struct
weston_compositor *ec)
}
ec-xkb_info = weston_xkb_info_create(keymap);
- if (ec-xkb_info == NULL)
+ if (ec-xkb_info == NULL)
return -1;
return 0;
--
1.7.9.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 5/5] build: use EXEEXT_FOR_BUILD instead EXEEXT for wayland-scanner
Hello. On 09/05/2013 11:15 AM, marc.chal...@gmail.com wrote: From: mchalain marc.chal...@gmail.com AX_CC_FOR_BUILD set the EXEEXT_FOR_BUILD variable to define the application extention of build platform. This effectively makes patch #1 useless. Any special reason for still keeping it? If not I would suggest to merge #1 and #5 and reorder the series if needed. regards Stefan Schmidt src/Makefile.am |9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index 2921041..4b6e1dd 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -38,15 +38,16 @@ pkgconfig_DATA = wayland-client.pc wayland-server.pc AM_CPPFLAGS = $(FFI_CFLAGS) AM_CFLAGS = $(GCC_CFLAGS) CC_FOR_BUILD = @CC_FOR_BUILD@ +EXEEXT_FOR_BUILD = @EXEEXT_FOR_BUILD@ CCLD_FOR_BUILD = $(CC_FOR_BUILD) COMPILE_FOR_BUILD = $(CC_FOR_BUILD) protocoldir = $(top_srcdir)/protocol if ENABLE_SCANNER -wayland_scanner = $(top_builddir)/src/wayland-scanner$(EXEEXT) +wayland_scanner = $(top_builddir)/src/wayland-scanner$(EXEEXT_FOR_BUILD) else -wayland_scanner = wayland-scanner$(EXEEXT) +wayland_scanner = wayland-scanner$(EXEEXT_FOR_BUILD) endif include $(top_srcdir)/src/scanner.mk @@ -56,7 +57,7 @@ build-%.o : %.c $(AM_V_CC)$(COMPILE_FOR_BUILD) -MT $@ -MD -MP -MF $(DEPDIR)/build-$*.Tpo -c -o $@ $ $(AM_V_at)$(am__mv) $(DEPDIR)/build-$*.Tpo $(DEPDIR)/build-$*.Po -bin_PROGRAMS = wayland-scanner$(EXEEXT) +bin_PROGRAMS = wayland-scanner wayland_scanner_SOURCES = \ build-scanner.c \ @@ -65,7 +66,7 @@ wayland_scanner_SOURCES = \ wayland_scanner_LDADD = $(EXPAT_LIBS) wayland_scanner_LINK = $(CCLD_FOR_BUILD) -o $@ -$(BUILT_SOURCES) : wayland-scanner$(EXEEXT) +$(BUILT_SOURCES) : wayland-scanner$(EXEEXT_FOR_BUILD) scannerpkgconfigdir = $(datadir)/pkgconfig scannerpkgconfig_DATA = wayland-scanner.pc ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] autotools: Fix AC_PATH_PROG call
Hello. On 08/24/2013 07:36 PM, Quentin Glidic wrote: From: Quentin Glidic sardemff7+...@sardemff7.net Signed-off-by: Quentin Glidic sardemff7+...@sardemff7.net --- Sorry for the noise, this one is the good fix configure.ac | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 156237f..4be0e4a 100644 --- a/configure.ac +++ b/configure.ac @@ -424,8 +424,10 @@ if test x$have_lcms = xyes; then fi AM_CONDITIONAL(HAVE_LCMS, [test x$have_lcms = xyes]) -AC_PATH_PROG([wayland_scanner], [wayland-scanner], -[AC_MSG_ERROR(wayland-scanner is needed to compile weston)]) +AC_PATH_PROG([wayland_scanner], [wayland-scanner]) +if test x$wayland_scanner = x; then + AC_MSG_ERROR([wayland-scanner is needed to compile weston]) +fi AC_CONFIG_FILES([Makefile shared/Makefile This patch fixes the problem for me. Now able again to use latest wayland and weston. Thanks a lot. regards Stefan Schmidt ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Weston wayland-scanner detection problem
make[5]: Entering directory `/home/SERILOCAL/s.schmidt/Projects/wayland-efl/weston/src/xwayland' CC xwayland_la-window-manager.lo CC xwayland_la-selection.lo CC xwayland_la-launcher.lo CC xwayland_la-xserver-protocol.lo CC xwayland_la-hash.lo launcher.c: In function 'bind_xserver': launcher.c:168:31: error: 'xserver_interface' undeclared (first use in this function) launcher.c:168:31: note: each undeclared identifier is reported only once for each function it appears in launcher.c:178:2: warning: implicit declaration of function 'xserver_send_listen_socket' [-Wimplicit-function-declaration] launcher.c: In function 'module_init': launcher.c:383:29: error: 'xserver_interface' undeclared (first use in this function) make[5]: *** [xwayland_la-launcher.lo] Error 1 make[5]: *** Waiting for unfinished jobs window-manager.c: In function 'weston_wm_create': window-manager.c:1711:2: warning: implicit declaration of function 'xserver_send_client' [-Wimplicit-function-declaration] window-manager.c: At top level: window-manager.c:1962:14: error: variable 'xserver_implementation' has initializer but incomplete type window-manager.c:1964:1: warning: excess elements in struct initializer [enabled by default] window-manager.c:1964:1: warning: (near initialization for 'xserver_implementation') [enabled by default] make[5]: *** [xwayland_la-window-manager.lo] Error 1 make[5]: Leaving directory `/home/SERILOCAL/s.schmidt/Projects/wayland-efl/weston/src/xwayland' make[4]: *** [all] Error 2 make[4]: Leaving directory `/home/SERILOCAL/s.schmidt/Projects/wayland-efl/weston/src/xwayland' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/SERILOCAL/s.schmidt/Projects/wayland-efl/weston/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/SERILOCAL/s.schmidt/Projects/wayland-efl/weston/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/SERILOCAL/s.schmidt/Projects/wayland-efl/weston' make: *** [all] Error 2 regards Stefan Schmidt ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH v2] protocol: Extend wayland seat with interfaces for sensor inputs.
Hello. On 08/22/2013 11:45 PM, Bryce W. Harrington wrote: On Thu, Aug 22, 2013 at 09:46:28AM +0100, Stefan Schmidt wrote: Treating some specific sensors as input devices. In particular adding support for wl_compass, wl_gyroscope and wl_accelerometer here. Using these sensor as input for apps and games. Not covering any background apps or services with this protocol. We have requests to start and stop sensor event receiving as well as events to receive the different axis values for these sensors. V2: o Add units to event arguments o Define coordinate system o Be more verbose on security policy in compositor and add error event Signed-off-by: Stefan Schmidt s.schm...@samsung.com --- protocol/wayland.xml | 175 ++ 1 file changed, 175 insertions(+) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index d79..e35413c 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1251,6 +1251,9 @@ entry name=pointer value=1 summary=The seat has pointer devices/ entry name=keyboard value=2 summary=The seat has one or more keyboards/ entry name=touch value=4 summary=The seat has touch devices/ + entry name=compass value=8 summary=The seat has compass devices/ + entry name=gyroscope value=16 summary=The seat has gyroscope devices/ + entry name=accelerometer value=32 summary=The seat has accelerometer devices/ /enum event name=capabilities @@ -1297,6 +1300,63 @@ !-- Version 2 of additions -- +request name=get_compass since=2 + description summary=return compass object +The ID provided will be initialized to the wl_compass interface + for this seat. + +This request only takes effect if the seat has the compass +capability. If the seat has the capability but no object is +received it could be that the compositor security policy has +denied the sensor access for the client. In case of a security +policy error an error event will be send. sp. 'send' s/b 'sent' + /description + arg name=id type=new_id interface=wl_compass/ +/request + +request name=get_gyroscope since=2 + description summary=return gyroscope object +The ID provided will be initialized to the wl_gyroscope interface + for this seat. + +This request only takes effect if the seat has the gyroscope +capability. If the seat has the capability but no object is +received it could be that the compositor security policy has +denied the sensor access for the client. In case of a security +policy error an error event will be send. here too + /description + arg name=id type=new_id interface=wl_gyroscope/ +/request + +request name=get_accelerometer since=2 + description summary=return accelerometer object +The ID provided will be initialized to the wl_accelerometer interface + for this seat. + +This request only takes effect if the seat has the accelerometer +capability. If the seat has the capability but no object is +received it could be that the compositor security policy has +denied the sensor access for the client. In case of a security +policy error an error event will be send. here too + /description + arg name=id type=new_id interface=wl_accelerometer/ +/request + +event name=error + description summary=fatal error event + The error event is sent out when a fatal (non-recoverable) + error has occurred. The object_id argument is the object + where the error occurred, most often in response to a request + to that object. The code identifies the error and is defined + by the object interface. As such, each interface defines its + own set of error codes. The message is an brief description sp. 'an brief' s/b 'a brief' + of the error, for (debugging) convenience. + /description + arg name=object_id type=object/ + arg name=code type=uint/ + arg name=message type=string/ +/event + event name=name since=2 description summary=unique identifier for this seat In a multiseat configuration this can be used by the client to help @@ -1605,6 +1665,121 @@ /event /interface + interface name=wl_compass version=2 +description summary=compass sensor device + The wl_compass interface represents a compass + associated with a seat. +/description + +request name=start + description summary=Start receiving events + Sent to enable event receiving for the compass sensor. + /description +/request + +request name=stop + description summary=Stop receiving events + Sent to disable event receiving for the compass sensor. + + It stops event reporting to this client. Other clients might still + receive events
Re: [RFC PATCH v2] protocol: Extend wayland seat with interfaces for sensor inputs.
Hello. On 08/22/2013 04:07 PM, Jason Ekstrand wrote: Stefan, Thanks for working on this! You can thank me once I get this into a state where it gets accepted. ;) As one general comment (protocol comments below), we need to make sure that normal values are somewhere around 1 to 1000. The wl_fixed type provides 24 bits of integer and 8 bits of fractional precision. The units used below seemed reasonable to me. That said, I'm not 100% sure how this relates to the real world so it's worth a check. We should be fine but I made a node to check on this. On Thu, Aug 22, 2013 at 4:45 AM, Stefan Schmidt s.schm...@samsung.com mailto:s.schm...@samsung.com wrote: Hello. On 08/22/2013 09:46 AM, Stefan Schmidt wrote: Treating some specific sensors as input devices. In particular adding support for wl_compass, wl_gyroscope and wl_accelerometer here. Using these sensor as input for apps and games. Not covering any background apps or services with this protocol. We have requests to start and stop sensor event receiving as well as events to receive the different axis values for these sensors. V2: o Add units to event arguments o Define coordinate system o Be more verbose on security policy in compositor and add error event One thing I'm still missing is a way to handle more than one sensor per type for the future. Input devices like the wii-remote with nunchuk comes to mind. Having two separate accelerometers which still would be a the same seat but could not be aggregated. Yes, this is kind of an issue. There was some work recently on adding gamepad support and that faced similar issues. For reference, see http://lists.freedesktop.org/archives/wayland-devel/2013-May/009043.html and the ~42 replies. Will go through this when I'm back from vacation. Thanks for pointing it out. One option we have been pondering about was adding a simple uid when doing the get_compass, etc calls and re-use this uid later in the motion events to identify the correct sensor. When the compositor adds the various sensors clients would get a event for each and could keep track on how many compass sensors there are for example and call get_compass accordingly if it is interested in all of them. I don't know that there's any real benifit to having some uid traveling along with them rather than just getting multiple protocol objects. Protocol objects are cheap and libwayland will sort out the id for you. For instance, you could have an event get_compass to which the compositor replies with a series of compas events each of which contains a new wl_compass instance. That could fit my needs. Its a corner case but I want this proposal to at least allow for such things in the future. Anyone having a better/different idea on this? regards Stefan Schmidt PS: I'm on vacation next week. Will reply to review and comments the week after. Signed-off-by: Stefan Schmidt s.schm...@samsung.com mailto:s.schm...@samsung.com --- protocol/wayland.xml | 175 ++__ 1 file changed, 175 insertions(+) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index d79..e35413c 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1251,6 +1251,9 @@ entry name=pointer value=1 summary=The seat has pointer devices/ entry name=keyboard value=2 summary=The seat has one or more keyboards/ entry name=touch value=4 summary=The seat has touch devices/ + entry name=compass value=8 summary=The seat has compass devices/ + entry name=gyroscope value=16 summary=The seat has gyroscope devices/ + entry name=accelerometer value=32 summary=The seat has accelerometer devices/ /enum event name=capabilities @@ -1297,6 +1300,63 @@ !-- Version 2 of additions -- +request name=get_compass since=2 + description summary=return compass object +The ID provided will be initialized to the wl_compass interface + for this seat. + +This request only takes effect if the seat has the compass +capability. If the seat has the capability but no object is +received it could be that the compositor security policy has +denied the sensor access for the client. In case of a security +policy error an error event will be send. + /description + arg name=id type=new_id interface=wl_compass/ +/request + +request name
Re: [RFC PATCH v2] protocol: Extend wayland seat with interfaces for sensor inputs.
Hello. On 08/22/2013 09:20 PM, Bill Spitzak wrote: Jason Ekstrand wrote: One thing I'm still missing is a way to handle more than one sensor per type for the future. Input devices like the wii-remote with nunchuk comes to mind. Having two separate accelerometers which still would be a the same seat but could not be aggregated. Yes, this is kind of an issue. There was some work recently on adding gamepad support and that faced similar issues. For reference, see http://lists.freedesktop.org/archives/wayland-devel/2013-May/009043.html and the ~42 replies. It seems wrong to me that the count is split into two parts. For instance if there are two accelerometers: 1. The fact that it is non-zero is stored in a bit in the seat description This is meant as a capability not a number of devices. Its the same with keyboards and such. 2. Whether it is 1, 2, 3, etc is in a different undefined api. It depends from how you look at this. Getting all sensor objects available when requesting a sensor type gives the client the number as well as the possibility to deal with it. You want and explicit API to get the number of sensors and request them manually? There have also been some worry about running out of bits in the seat flags, too. Why not have an api that takes a seat and returns a big list of every device and every event that each device can produce. Yes that seems big but it is on the order of thousands and would be sent in one big block, not as thousands of messages. I think the type of device can be determined from the set of events it produces, though I guess you can also put a type id on the device. Hmm, an idea to think about. I guess you also want to have keyboard, pointer, touch, etc converted to this? regards Stefan Schmidt ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH v2] protocol: Extend wayland seat with interfaces for sensor inputs.
Hello. On 08/22/2013 10:43 PM, Lorn Potter wrote: Hi, I was told of this thread, perhaps I can make a few comments (sorry if it doesn't really follow the thread) [no knowing much about wayland protocol/api] first thoughts: * why no timestamp info? Arg, that is sitting uncommitted here and thus not made it into the patch. Each event now has arg name=time type=uint summary=Timestamp with millisecond granularity/ * why no rate info? (not all apps need/want the same speed) That was requested before. I left it out initially for a) simply the first proposal and b) not being sure all sensor subsystems offer this. As you did qtsensor maybe you can shed some light on this. What systems does qtsensor support and do all of them offer rate? * a magnetometer is not a compass, nor does it describe motion. - it seems your 'compass' is really just a magnetometer. A compass entails a sensor fusion of sorts to return heading information in degrees. It uses a magnetometer (calibrated - which mostly means hard and soft iron distortions removed), accelerometer (smoothed for jitter - used for 'leveling' the mag readings), and declination information from somewhere (mostly gps or a location lookup table). Compass could return magnetic north, true north in degrees from the y axis of the device. Agreed, compass is more than just the ambient magnetic field reading so this should be renamed. Most importantly, what is the justification for sending sensor data through wayland? Because of requests I heard allow clients like games to use some type of sensor as user input. We did not include the other sensors for exactly this reason. They are still available through a subsytsem on whatever platform you run. For the sensors that reflect user input in terms of moving the device people asked for getting these through the wayland protocol. I'm not expecting this to be the best solution for every app but they still can get their informations from the subsystem. Another thing to consider is you might want to handle axis' rotation when the device is rotated. Indeed. Other devices you might consider is like the leapmotion sensor. Interesting type. But unlikely that I would work on something like this without actually having access for testing it. So I will concentrate on the things I have. regards Stefan Schmidt ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[RFC PATCH v2] protocol: Extend wayland seat with interfaces for sensor inputs.
Treating some specific sensors as input devices. In particular adding support for wl_compass, wl_gyroscope and wl_accelerometer here. Using these sensor as input for apps and games. Not covering any background apps or services with this protocol. We have requests to start and stop sensor event receiving as well as events to receive the different axis values for these sensors. V2: o Add units to event arguments o Define coordinate system o Be more verbose on security policy in compositor and add error event Signed-off-by: Stefan Schmidt s.schm...@samsung.com --- protocol/wayland.xml | 175 ++ 1 file changed, 175 insertions(+) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index d79..e35413c 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1251,6 +1251,9 @@ entry name=pointer value=1 summary=The seat has pointer devices/ entry name=keyboard value=2 summary=The seat has one or more keyboards/ entry name=touch value=4 summary=The seat has touch devices/ + entry name=compass value=8 summary=The seat has compass devices/ + entry name=gyroscope value=16 summary=The seat has gyroscope devices/ + entry name=accelerometer value=32 summary=The seat has accelerometer devices/ /enum event name=capabilities @@ -1297,6 +1300,63 @@ !-- Version 2 of additions -- +request name=get_compass since=2 + description summary=return compass object +The ID provided will be initialized to the wl_compass interface + for this seat. + +This request only takes effect if the seat has the compass +capability. If the seat has the capability but no object is +received it could be that the compositor security policy has +denied the sensor access for the client. In case of a security +policy error an error event will be send. + /description + arg name=id type=new_id interface=wl_compass/ +/request + +request name=get_gyroscope since=2 + description summary=return gyroscope object +The ID provided will be initialized to the wl_gyroscope interface + for this seat. + +This request only takes effect if the seat has the gyroscope +capability. If the seat has the capability but no object is +received it could be that the compositor security policy has +denied the sensor access for the client. In case of a security +policy error an error event will be send. + /description + arg name=id type=new_id interface=wl_gyroscope/ +/request + +request name=get_accelerometer since=2 + description summary=return accelerometer object +The ID provided will be initialized to the wl_accelerometer interface + for this seat. + +This request only takes effect if the seat has the accelerometer +capability. If the seat has the capability but no object is +received it could be that the compositor security policy has +denied the sensor access for the client. In case of a security +policy error an error event will be send. + /description + arg name=id type=new_id interface=wl_accelerometer/ +/request + +event name=error + description summary=fatal error event + The error event is sent out when a fatal (non-recoverable) + error has occurred. The object_id argument is the object + where the error occurred, most often in response to a request + to that object. The code identifies the error and is defined + by the object interface. As such, each interface defines its + own set of error codes. The message is an brief description + of the error, for (debugging) convenience. + /description + arg name=object_id type=object/ + arg name=code type=uint/ + arg name=message type=string/ +/event + event name=name since=2 description summary=unique identifier for this seat In a multiseat configuration this can be used by the client to help @@ -1605,6 +1665,121 @@ /event /interface + interface name=wl_compass version=2 +description summary=compass sensor device + The wl_compass interface represents a compass + associated with a seat. +/description + +request name=start + description summary=Start receiving events + Sent to enable event receiving for the compass sensor. + /description +/request + +request name=stop + description summary=Stop receiving events + Sent to disable event receiving for the compass sensor. + + It stops event reporting to this client. Other clients might still + receive events. + /description +/request + +event name=motion + description summary=Motion event coming from the compass sensor + Updated sensor data available from compass + + Measurement of the ambient magnetic field in the X, Y
Re: [RFC PATCH v2] protocol: Extend wayland seat with interfaces for sensor inputs.
Hello. On 08/22/2013 09:46 AM, Stefan Schmidt wrote: Treating some specific sensors as input devices. In particular adding support for wl_compass, wl_gyroscope and wl_accelerometer here. Using these sensor as input for apps and games. Not covering any background apps or services with this protocol. We have requests to start and stop sensor event receiving as well as events to receive the different axis values for these sensors. V2: o Add units to event arguments o Define coordinate system o Be more verbose on security policy in compositor and add error event One thing I'm still missing is a way to handle more than one sensor per type for the future. Input devices like the wii-remote with nunchuk comes to mind. Having two separate accelerometers which still would be a the same seat but could not be aggregated. One option we have been pondering about was adding a simple uid when doing the get_compass, etc calls and re-use this uid later in the motion events to identify the correct sensor. When the compositor adds the various sensors clients would get a event for each and could keep track on how many compass sensors there are for example and call get_compass accordingly if it is interested in all of them. Its a corner case but I want this proposal to at least allow for such things in the future. Anyone having a better/different idea on this? regards Stefan Schmidt PS: I'm on vacation next week. Will reply to review and comments the week after. Signed-off-by: Stefan Schmidt s.schm...@samsung.com --- protocol/wayland.xml | 175 ++ 1 file changed, 175 insertions(+) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index d79..e35413c 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1251,6 +1251,9 @@ entry name=pointer value=1 summary=The seat has pointer devices/ entry name=keyboard value=2 summary=The seat has one or more keyboards/ entry name=touch value=4 summary=The seat has touch devices/ + entry name=compass value=8 summary=The seat has compass devices/ + entry name=gyroscope value=16 summary=The seat has gyroscope devices/ + entry name=accelerometer value=32 summary=The seat has accelerometer devices/ /enum event name=capabilities @@ -1297,6 +1300,63 @@ !-- Version 2 of additions -- +request name=get_compass since=2 + description summary=return compass object +The ID provided will be initialized to the wl_compass interface + for this seat. + +This request only takes effect if the seat has the compass +capability. If the seat has the capability but no object is +received it could be that the compositor security policy has +denied the sensor access for the client. In case of a security +policy error an error event will be send. + /description + arg name=id type=new_id interface=wl_compass/ +/request + +request name=get_gyroscope since=2 + description summary=return gyroscope object +The ID provided will be initialized to the wl_gyroscope interface + for this seat. + +This request only takes effect if the seat has the gyroscope +capability. If the seat has the capability but no object is +received it could be that the compositor security policy has +denied the sensor access for the client. In case of a security +policy error an error event will be send. + /description + arg name=id type=new_id interface=wl_gyroscope/ +/request + +request name=get_accelerometer since=2 + description summary=return accelerometer object +The ID provided will be initialized to the wl_accelerometer interface + for this seat. + +This request only takes effect if the seat has the accelerometer +capability. If the seat has the capability but no object is +received it could be that the compositor security policy has +denied the sensor access for the client. In case of a security +policy error an error event will be send. + /description + arg name=id type=new_id interface=wl_accelerometer/ +/request + +event name=error + description summary=fatal error event + The error event is sent out when a fatal (non-recoverable) + error has occurred. The object_id argument is the object + where the error occurred, most often in response to a request + to that object. The code identifies the error and is defined + by the object interface. As such, each interface defines its + own set of error codes. The message is an brief description + of the error, for (debugging) convenience. + /description + arg name=object_id type=object/ + arg name=code type=uint/ + arg name=message type=string/ +/event + event name=name since=2 description summary=unique identifier
Re: [RFC] protocol: Extend wayland seat with interfaces for sensor inputs.
Hello. Sorry for the late reply. Got sick in between. First of all thanks for taking the time to review this and provide feedback. On 08/12/2013 04:54 PM, David Herrmann wrote: On Thu, Aug 1, 2013 at 10:39 AM, Stefan Schmidt s.schm...@samsung.com wrote: Treating some specific sensors as input devices. In particular adding support for wl_compass, wl_gyroscope and wl_accelerometer here. We have requests to start and stop sensor event receiving as well as events to receive the different axis values for these sensors. Signed-off-by: Stefan Schmidt s.schm...@samsung.com --- protocol/wayland.xml | 123 ++ 1 file changed, 123 insertions(+) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 3cfa953..066a718 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1251,6 +1251,9 @@ entry name=pointer value=1 summary=The seat has pointer devices/ entry name=keyboard value=2 summary=The seat has one or more keyboards/ entry name=touch value=4 summary=The seat has touch devices/ + entry name=compass value=8 summary=The seat has compass devices/ + entry name=gyroscope value=16 summary=The seat has gyroscope devices/ + entry name=accelerometer value=32 summary=The seat has accelerometer devices/ If we add all kinds of devices here, we will very soon run out of space for 32bit bitfields (which I think wayland uses for uint). I don't have a solution, but we should keep this in mind. Lets hope for now we don't have more than 26 different device types coming up. /enum event name=capabilities @@ -1297,6 +1300,39 @@ !-- Version 2 of additions -- +request name=get_compass since=2 + description summary=return compass object +The ID provided will be initialized to the wl_compass interface + for this seat. + +This request only takes effect if the seat has the compass +capability. + /description + arg name=id type=new_id interface=wl_compass/ +/request + +request name=get_gyroscope since=2 + description summary=return gyroscope object +The ID provided will be initialized to the wl_gyroscope interface + for this seat. + +This request only takes effect if the seat has the gyroscope +capability. + /description + arg name=id type=new_id interface=wl_gyroscope/ +/request + +request name=get_accelerometer since=2 + description summary=return accelerometer object +The ID provided will be initialized to the wl_accelerometer interface + for this seat. + +This request only takes effect if the seat has the accelerometer +capability. + /description + arg name=id type=new_id interface=wl_accelerometer/ +/request + This interface limits each seat to one device of each. For keyboards or mouse we internally merge these into a single virtual device, but we cannot do this for accelerometers or gyros. We had a discussion about that recently, I am not sure about the conclusion, though. If there was one, please include it in the commit message. You answered that yourself below. We should allow to cope with more then one sensor device per type. I really want to avoid doing that right now though. Having the protocol to allow for it but not doing it right now. Besides, why are these devices bound to seats? Where are these devices supposed to be? An accelerometer can be attached to an input device, an HDD, a laptop, a tablet, ... If you look at this from a smartphone/tablet view, it is obvious. But for desktops it really isn't clear whose data an accelerometer device reports. Indeed phones and tablets are my main focus right now but it should work for desktops and laptops as well. It should be a sensor that is really meant for input though. An accelerometer inside your harddisk might be used for that (played games with it on an older Thinkpad) but is not the use case here. Neither are background apps or services. I would like to reduce this proposal to real input for apps and games. The wayland protocol should not define sensor access for the whole system. I guess these devices are meant to be attached to the input device that this seat/user uses. In this case it makes sense to allow only a single device and bind them to seats. But please clarify this in the description. No one cares if the description is 1000 words long, so feel free to be verbose. Next version will be more verbose. Means another chance to spot what I missed. :) event name=name since=2 description summary=unique identifier for this seat In a multiseat configuration this can be used by the client to help @@ -1605,6 +1641,93 @@ /event /interface + interface name=wl_compass version=2 +description summary=compass sensor device + The wl_compass interface represents a compass + associated
Re: [RFC] protocol: Extend wayland seat with interfaces for sensor inputs.
Hello. Sorry for the delay. Got sick in between. Thanks for taking the time to review this. On 08/12/2013 05:14 PM, Thomas Daede wrote: On Thu, Aug 1, 2013 at 3:39 AM, Stefan Schmidt s.schm...@samsung.com wrote: +event name=motion + description summary=Motion event coming from the compass sensor + Updated sensor data available from compass + /description + arg name=x type=fixed summary=x-axis/ + arg name=y type=fixed summary=y-axis/ + arg name=z type=fixed summary=z-axis/ +/event These events don't have any units, and there isn't any particular information about the sensor passed either. Is this supposed to be read out of band? Presuming the motion integration happens in the client. it's very important for a coordinate system to be defined between the accelerometer, gyroscope, and compass, and information like sensor bandwidth is also important. I added units as well as a coordinate system description now. Please see the attachment for the current version and let me know if that covers it. Going to send it out next week and would be happy about more feedback. :) Sensors that combine all three of the above with an integral IMU processor are also becoming more and more common - that's at least one more type that we will need. I definitely think the interface should be designed - the abstraction has to be somewhere, and I'd prefer it Did you miss to finish the sentence? My parser fails on it. :) here rather than every client accessing the devices directly - but I want to make sure that this is possible with all sorts of devices in the future. What exactly are you missing? I started small here on purpose. But based on some real needs this can be extended. Nothing set in stone. There a number of other devices that I'd like to see implemented in this manner - for example, 3D mice. In this case, unlike the motion sensors, window focus does matter. What would you propose to handle these? regards Stefan Schmidt From 77b19aeff0b1c65625a4aa3b41821c61afa9ea6e Mon Sep 17 00:00:00 2001 From: Stefan Schmidt s.schm...@samsung.com Date: Tue, 9 Jul 2013 15:36:41 +0100 Subject: [PATCH] protocol: Extend wayland seat with interfaces for sensor inputs. Treating some specific sensors as input devices. In particular adding support for wl_compass, wl_gyroscope and wl_accelerometer here. Using these sensor as input for apps and games. Not covering any background apps or services with this protocol. We have requests to start and stop sensor event receiving as well as events to receive the different axis values for these sensors. V2: o Add units to event arguments o Define coordinate system Signed-off-by: Stefan Schmidt s.schm...@samsung.com --- protocol/wayland.xml | 142 ++ 1 file changed, 142 insertions(+) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index d79..ee295a1 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1251,6 +1251,9 @@ entry name=pointer value=1 summary=The seat has pointer devices/ entry name=keyboard value=2 summary=The seat has one or more keyboards/ entry name=touch value=4 summary=The seat has touch devices/ + entry name=compass value=8 summary=The seat has compass devices/ + entry name=gyroscope value=16 summary=The seat has gyroscope devices/ + entry name=accelerometer value=32 summary=The seat has accelerometer devices/ /enum event name=capabilities @@ -1297,6 +1300,39 @@ !-- Version 2 of additions -- +request name=get_compass since=2 + description summary=return compass object +The ID provided will be initialized to the wl_compass interface + for this seat. + +This request only takes effect if the seat has the compass +capability. + /description + arg name=id type=new_id interface=wl_compass/ +/request + +request name=get_gyroscope since=2 + description summary=return gyroscope object +The ID provided will be initialized to the wl_gyroscope interface + for this seat. + +This request only takes effect if the seat has the gyroscope +capability. + /description + arg name=id type=new_id interface=wl_gyroscope/ +/request + +request name=get_accelerometer since=2 + description summary=return accelerometer object +The ID provided will be initialized to the wl_accelerometer interface + for this seat. + +This request only takes effect if the seat has the accelerometer +capability. + /description + arg name=id type=new_id interface=wl_accelerometer/ +/request + event name=name since=2 description summary=unique identifier for this seat In a multiseat configuration this can be used by the client to help @@ -1605,6 +1641,112 @@ /event /interface + interface name=wl_compass version=2 +description summary=compass sensor device
Re: [RFC] protocol: Extend wayland seat with interfaces for sensor inputs.
Hello. On 08/01/2013 09:39 AM, Stefan Schmidt wrote: Treating some specific sensors as input devices. In particular adding support for wl_compass, wl_gyroscope and wl_accelerometer here. We have requests to start and stop sensor event receiving as well as events to receive the different axis values for these sensors. Signed-off-by: Stefan Schmidt s.schm...@samsung.com To stir up some discussions on this I might elaborate a bit on it. This came up on a face to face meeting between soem Intel and Samsung folks. It is driven by the idea that some sensor are used, or at least can be used, as input devices for games or even normal operation. We started with many more sensors but brought it down to these three as they seem to make the most sense. I kept the proposal small regarding exposed requests and events to not over-engineer it from the beginning. Right now I'm working on integrating this in weston to see how feasible it is and have a reference implementation. Rob asked me to send this out early to get some early feedback regarding the protocol and so I did. Lets see if anyone has something to say about this. :) regards Stefan Schmidt protocol/wayland.xml | 123 ++ 1 file changed, 123 insertions(+) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 3cfa953..066a718 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1251,6 +1251,9 @@ entry name=pointer value=1 summary=The seat has pointer devices/ entry name=keyboard value=2 summary=The seat has one or more keyboards/ entry name=touch value=4 summary=The seat has touch devices/ + entry name=compass value=8 summary=The seat has compass devices/ + entry name=gyroscope value=16 summary=The seat has gyroscope devices/ + entry name=accelerometer value=32 summary=The seat has accelerometer devices/ /enum event name=capabilities @@ -1297,6 +1300,39 @@ !-- Version 2 of additions -- +request name=get_compass since=2 + description summary=return compass object +The ID provided will be initialized to the wl_compass interface + for this seat. + +This request only takes effect if the seat has the compass +capability. + /description + arg name=id type=new_id interface=wl_compass/ +/request + +request name=get_gyroscope since=2 + description summary=return gyroscope object +The ID provided will be initialized to the wl_gyroscope interface + for this seat. + +This request only takes effect if the seat has the gyroscope +capability. + /description + arg name=id type=new_id interface=wl_gyroscope/ +/request + +request name=get_accelerometer since=2 + description summary=return accelerometer object +The ID provided will be initialized to the wl_accelerometer interface + for this seat. + +This request only takes effect if the seat has the accelerometer +capability. + /description + arg name=id type=new_id interface=wl_accelerometer/ +/request + event name=name since=2 description summary=unique identifier for this seat In a multiseat configuration this can be used by the client to help @@ -1605,6 +1641,93 @@ /event /interface + interface name=wl_compass version=2 +description summary=compass sensor device + The wl_compass interface represents a compass + associated with a seat. +/description + +request name=start + description summary=Start receiving events + Sent to enable event receiving for the compass sensor. + /description +/request + +request name=stop + description summary=Stop receiving events + Sent to disable event receiving for the compass sensor. + /description +/request + +event name=motion + description summary=Motion event coming from the compass sensor + Updated sensor data available from compass + /description + arg name=x type=fixed summary=x-axis/ + arg name=y type=fixed summary=y-axis/ + arg name=z type=fixed summary=z-axis/ +/event + + /interface + + interface name=wl_gyroscope version=2 +description summary=gyroscope sensor device + The wl_gyroscope interface represents a gyroscope + associated with a seat. +/description + +request name=start + description summary=Start receiving events + Sent to enable event receiving for the gyroscope sensor. + /description +/request + +request name=stop + description summary=Stop receiving events + Sent to disable event receiving for the gyroscope sensor. + /description +/request + +event name=motion + description summary=Motion event coming from the gyroscope sensor + Updated sensor data available from gyroscope + /description + arg name=x type=fixed summary=x-axis
[PATCH] clients: Fix typo in simple-touch and simple-shm.
listenter - listener. Better fix it now before it spreads further.
Signed-off-by: Stefan Schmidt s.schm...@samsung.com
---
clients/simple-shm.c |4 ++--
clients/simple-touch.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/clients/simple-shm.c b/clients/simple-shm.c
index f187b10..98102eb 100644
--- a/clients/simple-shm.c
+++ b/clients/simple-shm.c
@@ -294,7 +294,7 @@ shm_format(void *data, struct wl_shm *wl_shm, uint32_t
format)
d-formats |= (1 format);
}
-struct wl_shm_listener shm_listenter = {
+struct wl_shm_listener shm_listener = {
shm_format
};
@@ -314,7 +314,7 @@ registry_handle_global(void *data, struct wl_registry
*registry,
} else if (strcmp(interface, wl_shm) == 0) {
d-shm = wl_registry_bind(registry,
id, wl_shm_interface, 1);
- wl_shm_add_listener(d-shm, shm_listenter, d);
+ wl_shm_add_listener(d-shm, shm_listener, d);
}
}
diff --git a/clients/simple-touch.c b/clients/simple-touch.c
index 534c77c..9e4c60a 100644
--- a/clients/simple-touch.c
+++ b/clients/simple-touch.c
@@ -95,7 +95,7 @@ shm_format(void *data, struct wl_shm *wl_shm, uint32_t format)
touch-has_argb = 1;
}
-struct wl_shm_listener shm_listenter = {
+struct wl_shm_listener shm_listener = {
shm_format
};
@@ -257,7 +257,7 @@ handle_global(void *data, struct wl_registry *registry,
} else if (strcmp(interface, wl_shm) == 0) {
touch-shm = wl_registry_bind(registry, name,
wl_shm_interface, 1);
- wl_shm_add_listener(touch-shm, shm_listenter, touch);
+ wl_shm_add_listener(touch-shm, shm_listener, touch);
} else if (strcmp(interface, wl_seat) == 0) {
touch-seat = wl_registry_bind(registry, name,
wl_seat_interface, 1);
--
1.7.9.5
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[RFC] protocol: Extend wayland seat with interfaces for sensor inputs.
Treating some specific sensors as input devices. In particular adding support for wl_compass, wl_gyroscope and wl_accelerometer here. We have requests to start and stop sensor event receiving as well as events to receive the different axis values for these sensors. Signed-off-by: Stefan Schmidt s.schm...@samsung.com --- protocol/wayland.xml | 123 ++ 1 file changed, 123 insertions(+) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 3cfa953..066a718 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1251,6 +1251,9 @@ entry name=pointer value=1 summary=The seat has pointer devices/ entry name=keyboard value=2 summary=The seat has one or more keyboards/ entry name=touch value=4 summary=The seat has touch devices/ + entry name=compass value=8 summary=The seat has compass devices/ + entry name=gyroscope value=16 summary=The seat has gyroscope devices/ + entry name=accelerometer value=32 summary=The seat has accelerometer devices/ /enum event name=capabilities @@ -1297,6 +1300,39 @@ !-- Version 2 of additions -- +request name=get_compass since=2 + description summary=return compass object +The ID provided will be initialized to the wl_compass interface + for this seat. + +This request only takes effect if the seat has the compass +capability. + /description + arg name=id type=new_id interface=wl_compass/ +/request + +request name=get_gyroscope since=2 + description summary=return gyroscope object +The ID provided will be initialized to the wl_gyroscope interface + for this seat. + +This request only takes effect if the seat has the gyroscope +capability. + /description + arg name=id type=new_id interface=wl_gyroscope/ +/request + +request name=get_accelerometer since=2 + description summary=return accelerometer object +The ID provided will be initialized to the wl_accelerometer interface + for this seat. + +This request only takes effect if the seat has the accelerometer +capability. + /description + arg name=id type=new_id interface=wl_accelerometer/ +/request + event name=name since=2 description summary=unique identifier for this seat In a multiseat configuration this can be used by the client to help @@ -1605,6 +1641,93 @@ /event /interface + interface name=wl_compass version=2 +description summary=compass sensor device + The wl_compass interface represents a compass + associated with a seat. +/description + +request name=start + description summary=Start receiving events + Sent to enable event receiving for the compass sensor. + /description +/request + +request name=stop + description summary=Stop receiving events + Sent to disable event receiving for the compass sensor. + /description +/request + +event name=motion + description summary=Motion event coming from the compass sensor + Updated sensor data available from compass + /description + arg name=x type=fixed summary=x-axis/ + arg name=y type=fixed summary=y-axis/ + arg name=z type=fixed summary=z-axis/ +/event + + /interface + + interface name=wl_gyroscope version=2 +description summary=gyroscope sensor device + The wl_gyroscope interface represents a gyroscope + associated with a seat. +/description + +request name=start + description summary=Start receiving events + Sent to enable event receiving for the gyroscope sensor. + /description +/request + +request name=stop + description summary=Stop receiving events + Sent to disable event receiving for the gyroscope sensor. + /description +/request + +event name=motion + description summary=Motion event coming from the gyroscope sensor + Updated sensor data available from gyroscope + /description + arg name=x type=fixed summary=x-axis/ + arg name=y type=fixed summary=y-axis/ + arg name=z type=fixed summary=z-axis/ +/event + + /interface + + interface name=wl_accelerometer version=2 +description summary=accelerometer sensor device + The wl_accelerometer interface represents a accelerometer + associated with a seat. +/description + +request name=start + description summary=Start receiving events + Sent to enable event receiving for the accelerometer sensor. + /description +/request + +request name=stop + description summary=Stop receiving events + Sent to disable event receiving for the accelerometer sensor. + /description +/request + +event name=motion + description summary=Motion event coming from the accelerometer sensor + Updated sensor data available from accelerometer
Re: Compiling weston now needs colord
Hello. On 05/30/2013 07:24 AM, Michael Hasselmann wrote: On Tue, 2013-05-28 at 22:16 -0700, Bill Spitzak wrote: Running autogen.sh in weston with --disable-colord works to avoid this, I suspect nothing I care about is lost this way. I ran into the very same problems. I would have preferred if such new dependencies were optional or if someone would explain what we will miss if we disable them. For colord, trying to build the latest required version from git just pulls in more dependencies that you also have to build from git (as Bill mentioned). It's kind of frustrating, even if weston is meant to be a playground and thus new dependencies have to be expected. Its not a hard dependency. Just pass --disable-colord and it will work without it just fine. I don't really have an opinion if this should be set to enabled by default or not. regards Stefan Schmidt ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
