Re: [PATCH] config-parser: Honor the XDG_CONFIG_DIRS environment variable

2013-05-12 Thread Othman, Ossama
I've revised the patch to build a list of possible filenames as Bill
suggested.  This time around I've included a patch for the man page, as
well.

Thanks!
-Ossama

---

Search for a given config file in the directories listed in
$XDG_CONFIG_DIRS if it wasn't found in $XDG_CONFIG_HOME or ~/.config.
This allows packages to install custom config files in
/etc/xdg/weston, for example, thus allowing them to avoid dealing with
home directories.

Signed-off-by: Ossama Othman ossama.oth...@intel.com
---
 man/weston.ini.man |   12 +++-
 shared/config-parser.c |  155
+---
 2 files changed, 142 insertions(+), 25 deletions(-)

diff --git a/man/weston.ini.man b/man/weston.ini.man
index 2287730..d37654a 100644
--- a/man/weston.ini.man
+++ b/man/weston.ini.man
@@ -24,7 +24,10 @@ server is started:
 .nf
 .BR $XDG_CONFIG_HOME/weston.ini(if $XDG_CONFIG_HOME is set)
 .BR $HOME/.config/weston.ini   (if $HOME is set)
-.BR current dir/weston.ini   (if both variables were not set)
+.B  weston/weston.ini in each
+.BR \ \ \ \ $XDG_CONFIG_DIR(if $XDG_CONFIG_DIRS is set)
+.BR /etc/xdg/weston/weston.ini (if $XDG_CONFIG_DIRS is not set)
+.BR current dir/weston.ini   (if no variables were set)
 .fi
 .RE
 .PP
@@ -32,7 +35,12 @@ where environment variable
 .B $HOME
 is the user's home directory, and
 .B $XDG_CONFIG_HOME
-is the user specific configuration directory.
+is the user specific configuration directory, and
+.B $XDG_CONFIG_DIRS
+is a colon
+.B ':'
+delimited listed of configuration base directories, such as
+.BR /etc/xdg-foo:/etc/xdg .
 .PP
 The
 .I weston.ini
diff --git a/shared/config-parser.c b/shared/config-parser.c
index 10ff86a..4ebd453 100644
--- a/shared/config-parser.c
+++ b/shared/config-parser.c
@@ -25,6 +25,7 @@
 #include stdlib.h
 #include assert.h
 #include ctype.h
+#include unistd.h

 #include config-parser.h

@@ -95,6 +96,9 @@ parse_config_file(const char *path,
  const struct config_section *current = NULL;
  int i;

+ if (path == NULL)
+ return -1;
+
  fp = fopen(path, r);
  if (fp == NULL) {
  fprintf(stderr, couldn't open %s\n, path);
@@ -151,37 +155,142 @@ parse_config_file(const char *path,
  return 0;
 }

-char *
-config_file_path(const char *name)
+struct config_info
 {
- const char dotconf[] = /.config/;
- const char *config_dir;
- const char *home_dir;
+ /* Array of config file paths. */
+ char **paths;
+
+ /* Number of elements in the paths array. */
+ size_t count;
+};
+
+static char *
+allocate_config_file_path(struct config_info *info, size_t path_size)
+{
+ char **paths;
  char *path;
- size_t size;
-
- config_dir = getenv(XDG_CONFIG_HOME);
- if (!config_dir) {
- home_dir = getenv(HOME);
- if (!home_dir) {
- fprintf(stderr, HOME is not set, using cwd.\n);
- return strdup(name);
+
+ if (!info)
+ return 0;
+
+ path = malloc(path_size);
+ if (path) {
+ paths = realloc(info-paths,
+ (info-count + 1) * sizeof(*(info-paths)));
+ if (paths) {
+ paths[info-count] = path;
+ info-paths = paths;
+ ++info-count;
+ } else {
+ free(path);
+ path = NULL;
  }
+ }
+
+ return path;
+}
+
+char *
+config_file_path(const char *name)
+{
+ const char *config_dir  = getenv(XDG_CONFIG_HOME);
+ const char *home_dir = getenv(HOME);
+ const char *config_dirs = getenv(XDG_CONFIG_DIRS);
+ static const char weston_dir[] = /weston/;
+ static const char cwd[] = ./;
+ static const int DEFAULT_DIR_COUNT = 5;
+ struct config_info info;
+ size_t name_len, size;
+ char *path, *dir, *saveptr, *tmp_dirs;
+ char **p;
+
+ info.count = 0;
+ info.paths = malloc(DEFAULT_DIR_COUNT * sizeof(char *));
+ if (info.paths == NULL)
+ return NULL;
+
+ name_len = strlen(name);

- size = strlen(home_dir) + sizeof dotconf + strlen(name);
- path = malloc(size);
- if (!path)
- return NULL;
+ /* Precedence is given to config files in the home directory,
+ * and then to directories listed in XDG_CONFIG_DIRS and
+ * finally to the current working directory. */

- snprintf(path, size, %s%s%s, home_dir, dotconf, name);
- return path;
+ /* $XDG_CONFIG_HOME */
+ if (config_dir) {
+ size = strlen(config_dir) + 1 + name_len + 1;
+ path = allocate_config_file_path(info, size);
+
+ if (path)
+ snprintf(path, size, %s/%s, config_dir, name);
  }

- size = strlen(config_dir) + 1 + strlen(name) + 1;
- path = malloc(size);
- if (!path)
+ /* $HOME/.config */
+ if (home_dir) {
+ static const char dotconf[] = /.config/;
+
+ size = strlen(home_dir) + sizeof dotconf + name_len;
+ path = allocate_config_file_path(info, size);
+
+ if (path)
+ snprintf(path, size, %s%s%s,
+ home_dir, dotconf, name);
+ }
+
+ /* For each $XDG_CONFIG_DIRS: weston/config_file */
+ if (!config_dirs)
+ config_dirs = /etc/xdg;  /* See XDG base dir spec. */
+
+ size = strlen(config_dirs) + 1;
+ tmp_dirs = malloc(size);
+ if (!tmp_dirs)
  return NULL;

- snprintf(path, size, %s/%s, config_dir, name);
+ /* strtok_r() modifies the first argument.  Avoid
+ * clobbering the process environment. */
+ strncpy(tmp_dirs, 

[PATCH weston] shell: Use relative layers for lock/unlock

2013-05-12 Thread Quentin Glidic
From: Quentin Glidic sardemff7+...@sardemff7.net

Signed-off-by: Quentin Glidic sardemff7+...@sardemff7.net
---
 src/shell.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/src/shell.c b/src/shell.c
index 135eaa5..456e911 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -2501,19 +2501,16 @@ resume_desktop(struct desktop_shell *shell)
 
terminate_screensaver(shell);
 
-   wl_list_remove(shell-lock_layer.link);
-   wl_list_insert(shell-compositor-cursor_layer.link,
+   wl_list_insert(shell-lock_layer.link,
   shell-fullscreen_layer.link);
+   wl_list_remove(shell-lock_layer.link);
wl_list_insert(shell-fullscreen_layer.link,
   shell-panel_layer.link);
-   if (shell-showing_input_panels) {
+   wl_list_insert(shell-panel_layer.link,
+  ws-layer.link);
+   if (shell-showing_input_panels)
wl_list_insert(shell-panel_layer.link,
   shell-input_panel_layer.link);
-   wl_list_insert(shell-input_panel_layer.link,
-  ws-layer.link);
-   } else {
-   wl_list_insert(shell-panel_layer.link, ws-layer.link);
-   }
 
restore_focus_state(shell, get_current_workspace(shell));
 
@@ -2983,12 +2980,12 @@ lock(struct desktop_shell *shell)
 * input events while we are locked. */
 
wl_list_remove(shell-panel_layer.link);
-   wl_list_remove(shell-fullscreen_layer.link);
if (shell-showing_input_panels)
wl_list_remove(shell-input_panel_layer.link);
wl_list_remove(ws-layer.link);
-   wl_list_insert(shell-compositor-cursor_layer.link,
+   wl_list_insert(shell-fullscreen_layer.link,
   shell-lock_layer.link);
+   wl_list_remove(shell-fullscreen_layer.link);
 
launch_screensaver(shell);
 
-- 
1.8.2.1

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


Re: [PATCH weston] shell: Use relative layers for lock/unlock

2013-05-12 Thread Quentin Glidic

Sorry, wrong patch. This one is part of a patch series I’ll send soon.

--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


[no subject]

2013-05-12 Thread Quentin Glidic
This patch series introduce the notification_daemon interface.
It is intended to be the standard Weston interface that all non-DE (and
probably Weston-based) compositors will have to support.

The current supported layouts are limited to the “bubbles list”, which
is the most common one. Other layout will be supported in the future.

The implementation is done as a separate module, making the feature
available to all Weston-based compositors directly.

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


[PATCH weston v4 1/4] shell: Use relative layers for lock/unlock

2013-05-12 Thread Quentin Glidic
From: Quentin Glidic sardemff7+...@sardemff7.net

Signed-off-by: Quentin Glidic sardemff7+...@sardemff7.net
---
 src/shell.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/src/shell.c b/src/shell.c
index 135eaa5..456e911 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -2501,19 +2501,16 @@ resume_desktop(struct desktop_shell *shell)
 
terminate_screensaver(shell);
 
-   wl_list_remove(shell-lock_layer.link);
-   wl_list_insert(shell-compositor-cursor_layer.link,
+   wl_list_insert(shell-lock_layer.link,
   shell-fullscreen_layer.link);
+   wl_list_remove(shell-lock_layer.link);
wl_list_insert(shell-fullscreen_layer.link,
   shell-panel_layer.link);
-   if (shell-showing_input_panels) {
+   wl_list_insert(shell-panel_layer.link,
+  ws-layer.link);
+   if (shell-showing_input_panels)
wl_list_insert(shell-panel_layer.link,
   shell-input_panel_layer.link);
-   wl_list_insert(shell-input_panel_layer.link,
-  ws-layer.link);
-   } else {
-   wl_list_insert(shell-panel_layer.link, ws-layer.link);
-   }
 
restore_focus_state(shell, get_current_workspace(shell));
 
@@ -2983,12 +2980,12 @@ lock(struct desktop_shell *shell)
 * input events while we are locked. */
 
wl_list_remove(shell-panel_layer.link);
-   wl_list_remove(shell-fullscreen_layer.link);
if (shell-showing_input_panels)
wl_list_remove(shell-input_panel_layer.link);
wl_list_remove(ws-layer.link);
-   wl_list_insert(shell-compositor-cursor_layer.link,
+   wl_list_insert(shell-fullscreen_layer.link,
   shell-lock_layer.link);
+   wl_list_remove(shell-fullscreen_layer.link);
 
launch_screensaver(shell);
 
-- 
1.8.2.1

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


[PATCH weston v4 2/4] protocol: Add notification_daemon interface

2013-05-12 Thread Quentin Glidic
From: Quentin Glidic sardemff7+...@sardemff7.net

Signed-off-by: Quentin Glidic sardemff7+...@sardemff7.net
---
 protocol/Makefile.am |  1 +
 protocol/notification-daemon.xml | 50 
 2 files changed, 51 insertions(+)
 create mode 100644 protocol/notification-daemon.xml

diff --git a/protocol/Makefile.am b/protocol/Makefile.am
index 8c1803c..4eb889f 100644
--- a/protocol/Makefile.am
+++ b/protocol/Makefile.am
@@ -6,4 +6,5 @@ EXTRA_DIST =\
text.xml\
input-method.xml\
workspaces.xml  \
+   notification-daemon.xml \
wayland-test.xml
diff --git a/protocol/notification-daemon.xml b/protocol/notification-daemon.xml
new file mode 100644
index 000..2cd9e69
--- /dev/null
+++ b/protocol/notification-daemon.xml
@@ -0,0 +1,50 @@
+?xml version=1.0 encoding=UTF-8?
+protocol name=notification_daemon
+  copyright
+Copyright © 2013 Quentin Sardem FF7 Glidic
+
+Permission to use, copy, modify, distribute, and sell this
+software and its documentation for any purpose is hereby granted
+without fee, provided that the above copyright notice appear in
+all copies and that both that copyright notice and this permission
+notice appear in supporting documentation, and that the name of
+the copyright holders not be used in advertising or publicity
+pertaining to distribution of the software without specific,
+written prior permission.  The copyright holders make no
+representations about the suitability of this software for any
+purpose.  It is provided as is without express or implied
+warranty.
+
+THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
+THIS SOFTWARE.
+  /copyright
+
+  interface name=notification_daemon version=1
+description summary=interface for implementing notification daemons
+Only one client can bind this interface at a time.
+
+Notification surfaces are special surfaces that the user should
+always be able to see. The compositor is in charge of displaying
+them to be visible without disturbing the user workflow.
+
+This interface must be bound by all notification daemons, ensuring
+   that only one can run at a time.
+/description
+
+request name=add_surface
+  description summary=add a notification surface
+This request is for daemons which use a list of surfaces.
+Other mechanisms can be used and are not necessarily part of the
+   wl_notification_daemon interface.
+  /description
+
+  arg name=surface type=object interface=wl_surface/
+/request
+  /interface
+/protocol
-- 
1.8.2.1

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


[PATCH weston v4 3/4] shell: Implement notification_daemon

2013-05-12 Thread Quentin Glidic
From: Quentin Glidic sardemff7+...@sardemff7.net

Implement the bubbles list style notifications.
Corner anchor, margin and order can be changed in the configuration.

Signed-off-by: Quentin Glidic sardemff7+...@sardemff7.net
---
 src/.gitignore|   2 +
 src/Makefile.am   |  17 +++
 src/notification-daemon.c | 266 ++
 weston.ini|   5 +
 4 files changed, 290 insertions(+)
 create mode 100644 src/notification-daemon.c

diff --git a/src/.gitignore b/src/.gitignore
index ee62b84..ce7f5ab 100644
--- a/src/.gitignore
+++ b/src/.gitignore
@@ -14,6 +14,8 @@ desktop-shell-protocol.c
 desktop-shell-server-protocol.h
 text-protocol.c
 text-server-protocol.h
+notification-daemon-protocol.c
+notification-daemon-server-protocol.h
 workspaces-protocol.c
 workspaces-server-protocol.h
 input-method-protocol.c
diff --git a/src/Makefile.am b/src/Makefile.am
index 73c2d0d..e342a1c 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -99,6 +99,7 @@ module_LTLIBRARIES =  \
$(desktop_shell)\
$(tablet_shell) \
$(cms_static)   \
+   $(notification_daemon)  \
$(x11_backend)  \
$(drm_backend)  \
$(wayland_backend)  \
@@ -267,6 +268,20 @@ cms_static_la_SOURCES =\
cms-helper.h
 endif
 
+notification_daemon = notification-daemon.la
+notification_daemon_la_SOURCES =   \
+   notification-daemon.c   \
+   notification-daemon-protocol.c  \
+   notification-daemon-server-protocol.h
+notification_daemon_la_CFLAGS = \
+   $(GCC_CFLAGS) \
+   $(COMPOSITOR_CFLAGS)
+notification_daemon_la_LDFLAGS = \
+   -module -avoid-version
+notification_daemon_la_LIBADD = \
+   $(COMPOSITOR_LIBS)  \
+   ../shared/libshared.la
+
 BUILT_SOURCES =\
screenshooter-server-protocol.h \
screenshooter-protocol.c\
@@ -280,6 +295,8 @@ BUILT_SOURCES = \
text-server-protocol.h  \
input-method-protocol.c \
input-method-server-protocol.h  \
+   notification-daemon-protocol.c  \
+   notification-daemon-server-protocol.h   \
workspaces-server-protocol.h\
workspaces-protocol.c   \
subsurface-server-protocol.h\
diff --git a/src/notification-daemon.c b/src/notification-daemon.c
new file mode 100644
index 000..ce77077
--- /dev/null
+++ b/src/notification-daemon.c
@@ -0,0 +1,266 @@
+/*
+ * Copyright © 2013 Quentin “Sardem FF7” Glidic
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and
+ * its documentation for any purpose is hereby granted without fee, provided
+ * that the above copyright notice appear in all copies and that both that
+ * copyright notice and this permission notice appear in supporting
+ * documentation, and that the name of the copyright holders not be used in
+ * advertising or publicity pertaining to distribution of the software
+ * without specific, written prior permission.  The copyright holders make
+ * no representations about the suitability of this software for any
+ * purpose.  It is provided as is without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+ * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+ * FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+ * SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
+ * RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
+ * CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include stdlib.h
+#include stdio.h
+#include stdbool.h
+#include string.h
+#include unistd.h
+#include linux/input.h
+#include assert.h
+#include signal.h
+#include math.h
+#include sys/types.h
+
+#include wayland-server.h
+#include compositor.h
+#include notification-daemon-server-protocol.h
+#include ../shared/config-parser.h
+
+#define DEFAULT_NOTIFICATIONS_MARGIN 20
+
+
+enum edge_anchor {
+   EDGE_TOP= 10,
+   EDGE_BOTTOM = 11,
+   EDGE_LEFT   = 12,
+   EDGE_RIGHT  = 13
+};
+
+enum corner_anchor {
+   CORNER_TOP_RIGHT= EDGE_TOP | EDGE_RIGHT,
+   CORNER_TOP_LEFT = EDGE_TOP | EDGE_LEFT,
+   CORNER_BOTTOM_RIGHT = EDGE_BOTTOM | EDGE_RIGHT,
+   CORNER_BOTTOM_LEFT  = EDGE_BOTTOM | EDGE_LEFT,
+};
+
+enum notifications_order {
+   ORDER_NEWEST_FIRST,
+   ORDER_OLDEST_FIRST
+};
+
+struct notification_daemon {
+   struct weston_compositor *compositor;
+
+   struct 

Re: [PATCH] config-parser: Honor the XDG_CONFIG_DIRS environment variable

2013-05-12 Thread Kristian Høgsberg
On Sun, May 12, 2013 at 11:54 AM, Kristian Høgsberg k...@bitplanet.net wrote:
 Hi Ossama,

 I think we can change the interface to int open_config_file(const char
 *), which looks up and opens the config file and returns the fd.  We
 can keep that in weston_compositor instead of the config_file path.
 The parse function can then fseek on the fd to reset to the beginning
 of the file.  Going forward, we'll do something like this:

   http://lists.freedesktop.org/archives/wayland-devel/2013-April/008333.html

 and store the weston_config object in weston_compositor object.  The
 config path patch here is somewhat orthogonal to that though.

 On Sun, May 12, 2013 at 2:20 AM, Othman, Ossama ossama.oth...@intel.com 
 wrote:
 I've revised the patch to build a list of possible filenames as Bill
 suggested.  This time around I've included a patch for the man page, as
 well.

 Thanks!
 -Ossama

 ---

 Search for a given config file in the directories listed in
 $XDG_CONFIG_DIRS if it wasn't found in $XDG_CONFIG_HOME or ~/.config.
 This allows packages to install custom config files in
 /etc/xdg/weston, for example, thus allowing them to avoid dealing with
 home directories.

 Signed-off-by: Ossama Othman ossama.oth...@intel.com
 ---
  man/weston.ini.man |   12 +++-
  shared/config-parser.c |  155
 +---
  2 files changed, 142 insertions(+), 25 deletions(-)

 diff --git a/man/weston.ini.man b/man/weston.ini.man
 index 2287730..d37654a 100644
 --- a/man/weston.ini.man
 +++ b/man/weston.ini.man
 @@ -24,7 +24,10 @@ server is started:
  .nf
  .BR $XDG_CONFIG_HOME/weston.ini(if $XDG_CONFIG_HOME is set)
  .BR $HOME/.config/weston.ini   (if $HOME is set)
 -.BR current dir/weston.ini   (if both variables were not set)
 +.B  weston/weston.ini in each
 +.BR \ \ \ \ $XDG_CONFIG_DIR(if $XDG_CONFIG_DIRS is set)
 +.BR /etc/xdg/weston/weston.ini (if $XDG_CONFIG_DIRS is not set)
 +.BR current dir/weston.ini   (if no variables were set)
  .fi
  .RE
  .PP
 @@ -32,7 +35,12 @@ where environment variable
  .B $HOME
  is the user's home directory, and
  .B $XDG_CONFIG_HOME
 -is the user specific configuration directory.
 +is the user specific configuration directory, and
 +.B $XDG_CONFIG_DIRS
 +is a colon
 +.B ':'
 +delimited listed of configuration base directories, such as
 +.BR /etc/xdg-foo:/etc/xdg .
  .PP
  The
  .I weston.ini
 diff --git a/shared/config-parser.c b/shared/config-parser.c
 index 10ff86a..4ebd453 100644
 --- a/shared/config-parser.c
 +++ b/shared/config-parser.c
 @@ -25,6 +25,7 @@
  #include stdlib.h
  #include assert.h
  #include ctype.h
 +#include unistd.h

  #include config-parser.h

 @@ -95,6 +96,9 @@ parse_config_file(const char *path,
   const struct config_section *current = NULL;
   int i;

 + if (path == NULL)
 + return -1;
 +
   fp = fopen(path, r);
   if (fp == NULL) {
   fprintf(stderr, couldn't open %s\n, path);
 @@ -151,37 +155,142 @@ parse_config_file(const char *path,
   return 0;
  }

 -char *
 -config_file_path(const char *name)
 +struct config_info
  {
 - const char dotconf[] = /.config/;
 - const char *config_dir;
 - const char *home_dir;
 + /* Array of config file paths. */
 + char **paths;
 +
 + /* Number of elements in the paths array. */
 + size_t count;
 +};
 +
 +static char *
 +allocate_config_file_path(struct config_info *info, size_t path_size)
 +{
 + char **paths;
   char *path;
 - size_t size;
 -
 - config_dir = getenv(XDG_CONFIG_HOME);
 - if (!config_dir) {
 - home_dir = getenv(HOME);
 - if (!home_dir) {
 - fprintf(stderr, HOME is not set, using cwd.\n);
 - return strdup(name);
 +
 + if (!info)
 + return 0;
 +
 + path = malloc(path_size);
 + if (path) {
 + paths = realloc(info-paths,
 + (info-count + 1) * sizeof(*(info-paths)));
 + if (paths) {
 + paths[info-count] = path;
 + info-paths = paths;
 + ++info-count;
 + } else {
 + free(path);
 + path = NULL;
   }
 + }
 +
 + return path;
 +}
 +
 +char *
 +config_file_path(const char *name)
 +{
 + const char *config_dir  = getenv(XDG_CONFIG_HOME);
 + const char *home_dir = getenv(HOME);
 + const char *config_dirs = getenv(XDG_CONFIG_DIRS);
 + static const char weston_dir[] = /weston/;
 + static const char cwd[] = ./;
 + static const int DEFAULT_DIR_COUNT = 5;
 + struct config_info info;
 + size_t name_len, size;
 + char *path, *dir, *saveptr, *tmp_dirs;
 + char **p;
 +
 + info.count = 0;
 + info.paths = malloc(DEFAULT_DIR_COUNT * sizeof(char *));
 + if (info.paths == NULL)
 + return NULL;

 I don't think this function should need any mallocs at all.  Basically
 we should be able to say something like

   char path[PATHMAX];

   snprintf(path, size, %s%s%s, home_dir, dotconf, name);
   fd = open(path);
   if (fd = 0)
 return fd;

   /* same for XDG_CONFIG_DIR */

 as for XDG_CONFIG_PATHS, I'd just scan through the string manually
 with strchrnul instead of bothering with copying and strtok_r:

   for (p = config_dirs, *p; p = next) {
 next = strchrnul(p, 

Re: [RFC] libinputmapper: Input device configuration for graphic-servers

2013-05-12 Thread Todd Showalter
On Sun, May 12, 2013 at 10:20 AM, David Herrmann dh.herrm...@gmail.com wrote:

 So what is the proposed solution?
 My recommendation is, that compositors still search for devices via
 udev and use device drivers like libxkbcommon. So linux evdev handling
 is still controlled by the compositor. However, I'd like to see
 something like my libinputmapper proposal being used for device
 detection and classification.

[8]

I could work with this.  Right now I'm somewhat tackling the whole
problem head-on; I've got a server with an inotify watch on /dev/input
that binds a udp port.  Connect to the udp port, get a stream of
events for all devices the server cares about (which in my case is
gamepads), with suitable remapping.

The idea isn't necessarily to do things precisely that way, it's
more a proof of concept tool; it's easy enough to replace the udp
socket with a fifo or just jack it in to something as a back-end.
Likewise, it could just be processing data streams rather than dealing
directly with /dev/input.  The remapping could also be sourced out to
your library.

I haven't had as much time to devote to it as I'd like, but I'm
hoping I can get the code up soon.

  Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


Re: Gamepad focus model (Re: Input and games.)

2013-05-12 Thread Peter Hutterer
On Fri, May 10, 2013 at 10:41:45AM +0300, Pekka Paalanen wrote:
 On Thu, 9 May 2013 16:44:09 +1000
 Peter Hutterer peter.hutte...@who-t.net wrote:
 
  On Mon, May 06, 2013 at 03:36:20PM +0300, Pekka Paalanen wrote:
  [...]
   I had a private chat with Daniel, and we came to an understanding,
   which I try to describe below. The interface names below are more like
   placeholders for now.
   
   Into wl_seat, we should add a capability bit for gamepad. When the bit
   is set, a client can send wl_seat::get_gamepad_manager request, which
   creates a new wl_gamepad_manager object. (Do we actually need a
   capability bit?)
   
   A wl_gamepad_manager will send an event for each physical gamepad (as
   it dynamically appears, if hotplugged later) associated with this
   particular wl_seat, creating a wl_gamepad object for each.
   
   A wl_gamepad object will send an event about the player id as the first
   thing, and also if it later changes.
  
  do you expect the player ID to be exposed on the protocol?
  what does it contain and who manages the association?
  is it related to any physical ID of the gamepad, and if not, can such ID be
  provided (if the device supports it)?
 
 I imagined the player ID to be sent explicitly in the protocol, with
 its very own event. The server would manage the association between
 physical devices and the player ID, according to built-in heuristics
 and user preferences.
 
 E.g. if one goes from 0 gamepads to 1 gamepad, it will always be player
 1; or maybe take the first player slot that does not have a gamepad,
 unless we identify the device as the same that was recently unplugged
 in which case take the player slot that it used to have. Or something,
 with user preferences, and some UI to fix the association in the rare
 case when the heuristics choose wrong.
 
 Recognizing a gamepad could be done via physical identification, if one
 is available, or by usb port/hub, or whatever platform specific way.
 The clients would not have to care, they would only work with unique
 player IDs, which are integers created in sequence starting from 1 (or
 0).

first - I agree with player ID being assigned to a gamepad for the simple
reason of giving all clients a baseline.

I think that phys information should be exposed in some way. use-case here
is a specific controller that is always owned by the same human player. the
game could then associate this automatically with the player.
this could be a later addition to the protocol though, because right now I
have no idea how to do this sensibly.

 Using integers starting from 1 makes it trivial for the server to
 update the player ID display on the gamepads, if they have one.
 
 The server could also implement a global UI to reassing gamepads. For
 instance, press the famous home button for 5 secs on any gamepad, get
 some gamepad controllable GUI to reassing them, or maybe just a request
 to press the home button again on each gamepad in sequence.

this UI could also handle the seat assignment, see below.

 Doing all this client side would mean we need to find a way to
 communicate all the device and platform specific hints for the gamepad
 assignment heuristics somehow, and each client instance would have its
 own gamepad assignments.
 
  is the player ID not better represented through a wl_seat? - if you're
  playing a full-screen game, both seats can safely have the same focus,
  otherwise, players can play games independently.
  plus, if both players have a separate seat, they can use their keyboard
  independently for data entry.
 
 Those were exactly my thoughts in the beginning, however during the way
 long email thread, I got convinced otherwise for now. There are a few
 issues that come mind:
 - how to know, when one seat should follow the keyboard(?) focus of
   another seat?

I wonder when this is necessary. unless I'm misunderstanding something this
should only be of concern when both users want to change games (or otherwise
between clients)?

 - a client still needs to map seats into players; how? does it need an
   UI to fix it in case a user is not happy with the result?

well, tbh if you're planning for multiple seats at some point you'll need a
UI to handle it anyway. whether this is for ptr/kbd seats or gamepads, it
comes down to the same. but even with the proposal above you still need some
UI anyway.

also, afaict this is what some game consoles have, e.g. the Wii associates
your controller with your Me.

Cheers,
   Peter

 Also, allowing multiple gamepads in one seat does not exclude the seat
 approach. A server could still assign every gamepad to a different
 seat, provided it had some way to solve the focus assignment.
 
 In any case, I think the player ID assigned to each gamepad by the
 server is useful, since it would solve the seat-player mapping, too.
 Although, in a strict one gamepad per seat setting it would be better
 suited as a seat event than a gamepad event, perhaps.

 
 
 Thanks,
 pq
 
   If a 

Re: [PATCH] config-parser: Honor the XDG_CONFIG_DIRS environment variable

2013-05-12 Thread Othman, Ossama
Hi Kristian,

On Sun, May 12, 2013 at 8:54 AM, Kristian Høgsberg k...@bitplanet.netwrote:

 I think we can change the interface to int open_config_file(const char
 *), which looks up and opens the config file and returns the fd.  We
 can keep that in weston_compositor instead of the config_file path.
 The parse function can then fseek on the fd to reset to the beginning
 of the file.  Going forward, we'll do something like this:


 http://lists.freedesktop.org/archives/wayland-devel/2013-April/008333.html


Nice set of changes!


 and store the weston_config object in weston_compositor object.  The
 config path patch here is somewhat orthogonal to that though.

 On Sun, May 12, 2013 at 2:20 AM, Othman, Ossama ossama.oth...@intel.com
 wrote:

...

  + info.count = 0;
  + info.paths = malloc(DEFAULT_DIR_COUNT * sizeof(char *));
  + if (info.paths == NULL)
  + return NULL;

 I don't think this function should need any mallocs at all.


Agreed.  I was a bit too loose with the malloc()s.  :)

Basically
 we should be able to say something like

   char path[PATHMAX];

   snprintf(path, size, %s%s%s, home_dir, dotconf, name);
   fd = open(path);
   if (fd = 0)
 return fd;

   /* same for XDG_CONFIG_DIR */

 as for XDG_CONFIG_PATHS, I'd just scan through the string manually
 with strchrnul instead of bothering with copying and strtok_r:

   for (p = config_dirs, *p; p = next) {
 next = strchrnul(p, ':');
 snprintf(path, size, %s/weston/%s, p next - p, name);
 fd = open(path);


That is indeed much better.  Since your new parser is pending would you
like me to hold off submitting a reworked patch that incorporates your
suggestions?

Thanks to both you and Bill for the excellent feedback!
-Ossama
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel