[PATCH] Don't document an absent parameter.

[Bryce Harrington]

Quells a doxygen warning:

  src/wayland-server.c:790: warning: argument 'None' of command @param is
  not found in the argument list of wl_display::wl_display_create(void)

Signed-off-by: Bryce Harrington br...@osg.samsung.com
---
 src/wayland-server.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/wayland-server.c b/src/wayland-server.c
index 674aeca..ffe5233 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -787,7 +787,6 @@ bind_display(struct wl_client *client, struct wl_display 
*display)
 
 /** Create Wayland display object.
  *
- * \param None
  * \return The Wayland display object. Null if failed to create
  *
  * This creates the wl_display object.
-- 
1.9.1

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

Re: [PATCH Weston 1/1] desktop-shell: implement autolaunch

[Pekka Paalanen]

On Wed, 29 Oct 2014 20:01:33 +
Daniel Stone dan...@fooishbar.org wrote:

 Hi,
 
 On Wednesday, October 29, 2014, Pekka Paalanen 
 pekka.paala...@collabora.co.uk wrote:
 
  On Tue, 28 Oct 2014 16:46:24 +
  Daniel Stone dan...@fooishbar.org javascript:; wrote:
   On 24 October 2014 11:18, Pekka Paalanen pekka.paala...@collabora.co.uk
  javascript:;
   wrote:
  I think we all forgot a tiny detail here.
 
  weston_client_start() is a compositor internal function, while this
  patch is modifying weston-desktop-shell client.
 
 
 Egads, I'd completely missed that, and assumed it was compositor rather
 than shell.
 
 Any reason to have it like that? Compositor seems more natural to me ...

The compositor could do the autolaunch, but we also have the panel
launch buttons, that need to be executed in weston-desktop-shell. And
autolaunch and the panel launchers are very similar, but not too similar
to the in-weston launching.

But I see what you might be getting at: if weston-desktop-shell does
autolaunch, and it respawns, it will autolaunch everything again. Not
good.

So we'd probably need autolaunch in the server side indeed. Then we
could put the command line parsing into env/cmd/args in libshared to
share that with weston-desktop-shell. Keep all the respawn logic inside
the compositor and maybe refactor that into some shared weston core
code.

Below I'll attach what I had written earlier but not sent, because
then I realized the server vs. weston-desktop-shell thing. If we do
autolaunch in the server, the below more or less applies again.

**

Okay, if Fred or someone actually has time to do all that refactoring
and writing, it's cool. It's just more work than simply adding
autolaunch, which was the original goal here.

So, we need to cater for two different cases:
a) start a client with a pre-made connection (set WAYLAND_SOCKET), and
b) start a new arbitrary process (do not set WAYLAND_SOCKET).

By refactoring, both cases should then have customizable environment,
and maybe optional respawn with conditions to give up if the process
exits too often.

Custom environment may come from weston.ini in case of manual
and auto-launchers, or hardcoded in plugins (currently not done).

Respawn needs the following parameters:
- is respawn triggered by wl_client destruction or SIGCHLD
- when to give up
(- delay to respawn?)

If I understood right, you suggested that respawn would be limited to
observing the wl_client, which practically means purely case a). That
should work, I think.

Manual launchers (the panel buttons) should never support respawn.

As a detail, case a) function will also need a hook that delivers the
new wl_client to the calling code when respawn happens. Otherwise e.g.
shell.c would not get the new authorized connection if
weston-desktop-shell crashes. We will also need a way to stop
respawning, e.g. shell.c uses that during shutdown when it deliberately
disconnects weston-desktop-shell.

When to give up?

The current logic for weston-desktop-shell is that if it crashes during
the first 30 seconds from session start, respawn will not be attempted,
and weston is shut down instead. Later, if weston-desktop-shell crashes
more than 5 times within 30 seconds, it gives up but does not exit
Weston, since other clients may still work.

**

Do we want to support autolaunching anything else than Wayland clients
directly? If not, then case b) can be dropped, which would be nice.

Can the weston-desktop-shell respawn/shutdown logic be supported by a
generic respawn code, or is it too complicated to be worth it? Maybe
e.g. weston-keyboard has a less complicated respawn logic that could
share with autolaunch.

Details... up to the person writing the code. We can then see how it
looks like. I would just want to avoid designing a big and complicated
launching and respawning framework just to cater the need of one
special case (weston-desktop-shell). If we can do with a simple design
otherwise but force weston-desktop-shell logic still be separate, that
is fine. Simplicity should be the driving goal in the code design. ;-)


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

Re: Reusing wl_egl_window for multiple EGL surfaces

[Pekka Paalanen]

On Wed, 29 Oct 2014 08:48:12 -0700
Virtual Presence virtualpresence.u...@gmail.com wrote:

 Thank you for the detailed gyaan. I will look into the sub-surface
 protocol as an alternative. What I do as of now is have the 2 threads on a
 3 second timer where threadA renders triangle for 3 seconds then signals a
 mutex condition and wakes up threadB which renders gears for 3 seconds and
 so on and so on. I will also look into the option of reusing the wl_surface
 for multiple wl_egl_window. This seems closest to what i had in mind. I
 would also like to attach 3 second timer signal to the display FD and the
 custom queue i have setup for the 2 threads so that instead of having a
 dedicated timer logic I can blend the event handling into the Wayland
 model. I haven't been successful in doing this though. As an alternative I
 am looking into the option of writing a wl_timer protocol to provide the
 functionality. Any suggestions on how i can tie in the timer logic or any
 comments on having a dedicated wl_timer protocol? Thank you for all the
 help.

Don't do anything with protocol about timers, unless your only goal is
to learn how to define new protocols by a throw-away toy example.

Your client is already polling the wayland connection fd. You can just,
say, use timerfd API to create an fd for your timer needs, and simply
add that to the poll set. That is what
http://cgit.freedesktop.org/wayland/weston/tree/clients/window.c
already does (look for display_watch_fd), for instance.

Or use an event library that offers you everything in a portable
fashion. Or a real toolkit.


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

Re: [PATCH weston] xwayland: fix fullscreening

[Ryo Munakata]

On Wed, 29 Oct 2014 13:44:44 +0100
Marek Chalupa mchqwe...@gmail.com wrote:

 set_fullscreen has been sending configure before changing the state
 and xwayland windows added border to the fullscreen size.
 
 This fixes the bug:
 https://bugs.freedesktop.org/show_bug.cgi?id=83502
 
 Signed-off-by: Marek Chalupa mchqwe...@gmail.com
 ---
  desktop-shell/shell.c | 4 ++--
  xwayland/window-manager.c | 2 +-
  2 files changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
 index 9fafb39..8e3f79d 100644
 --- a/desktop-shell/shell.c
 +++ b/desktop-shell/shell.c
 @@ -2929,10 +2929,10 @@ shell_interface_set_fullscreen(struct shell_surface 
 *shsurf,
  struct weston_output *output)
  {
   surface_clear_next_states(shsurf);
 - set_fullscreen(shsurf, method, framerate, output);
 -
   shsurf-next_state.fullscreen = true;
   shsurf-state_changed = true;
 +
 + set_fullscreen(shsurf, method, framerate, output);
  }
  
  static int
 diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
 index 2902373..e7e5a7a 100644
 --- a/xwayland/window-manager.c
 +++ b/xwayland/window-manager.c
 @@ -2193,7 +2193,7 @@ send_configure(struct weston_surface *surface, int32_t 
 width, int32_t height)
   struct theme *t = window-wm-theme;
   int vborder, hborder;
  
 - if (window-decorate) {
 + if (window-decorate  !window-fullscreen) {
   hborder = 2 * t-width;
   vborder = t-titlebar_height + t-width;
   } else {
 -- 
 1.9.3

Hi, Marek.

This patch does fix the problem.

Reviewed-by: Ryo Munakata ryomnk...@gmail.com

Thank you.
-- 
Ryo Munakata ryomnk...@gmail.com
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[weston V2 1/2] Check for math (m) and real time (rt) libraries

[Javier Jardón]

---
 Makefile.am  | 19 +--
 configure.ac |  6 ++
 2 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 1e7cc81..1557953 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -44,7 +44,7 @@ weston_LDFLAGS = -export-dynamic
 weston_CPPFLAGS = $(AM_CPPFLAGS) -DIN_WESTON
 weston_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS) $(LIBUNWIND_CFLAGS)
 weston_LDADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \
-   $(DLOPEN_LIBS) -lm libshared.la
+   $(DLOPEN_LIBS) libshared.la
 
 weston_SOURCES =   \
src/git-version.h   \
@@ -211,7 +211,7 @@ drm_backend_la_LIBADD = \
$(COMPOSITOR_LIBS)  \
$(DRM_COMPOSITOR_LIBS)  \
$(INPUT_BACKEND_LIBS)   \
-   libshared.la -lrt   \
+   libshared.la\
libsession-helper.la
 drm_backend_la_CFLAGS =\
$(COMPOSITOR_CFLAGS)\
@@ -348,7 +348,7 @@ endif
 
 noinst_PROGRAMS += spring-tool
 spring_tool_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS)
-spring_tool_LDADD = $(COMPOSITOR_LIBS) -lm
+spring_tool_LDADD = $(COMPOSITOR_LIBS)
 spring_tool_SOURCES =  \
src/spring-tool.c   \
src/animation.c \
@@ -429,7 +429,7 @@ weston_presentation_shm_LDADD = $(SIMPLE_CLIENT_LIBS) 
libshared.la -lm
 
 weston_multi_resource_SOURCES = clients/multi-resource.c
 weston_multi_resource_CFLAGS = $(AM_CFLAGS) $(SIMPLE_CLIENT_CFLAGS)
-weston_multi_resource_LDADD = $(SIMPLE_CLIENT_LIBS) libshared.la -lm
+weston_multi_resource_LDADD = $(SIMPLE_CLIENT_LIBS) libshared.la
 endif
 
 if BUILD_SIMPLE_EGL_CLIENTS
@@ -439,7 +439,7 @@ nodist_weston_simple_egl_SOURCES =  \
protocol/xdg-shell-protocol.c   \
protocol/xdg-shell-client-protocol.h
 weston_simple_egl_CFLAGS = $(AM_CFLAGS) $(SIMPLE_EGL_CLIENT_CFLAGS)
-weston_simple_egl_LDADD = $(SIMPLE_EGL_CLIENT_LIBS) -lm
+weston_simple_egl_LDADD = $(SIMPLE_EGL_CLIENT_LIBS)
 endif
 
 noinst_LTLIBRARIES += libtoytoolkit.la
@@ -466,7 +466,7 @@ BUILT_SOURCES += $(nodist_libtoytoolkit_la_SOURCES)
 libtoytoolkit_la_LIBADD =  \
$(CLIENT_LIBS)  \
$(CAIRO_EGL_LIBS)   \
-   libshared-cairo.la -lrt -lm
+   libshared-cairo.la
 libtoytoolkit_la_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS) $(CAIRO_EGL_CFLAGS)
 
 weston_flower_SOURCES = clients/flower.c
@@ -520,7 +520,7 @@ weston_nested_LDADD = libtoytoolkit.la $(SERVER_LIBS)
 weston_nested_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
 
 weston_nested_client_SOURCES = clients/nested-client.c
-weston_nested_client_LDADD = $(SIMPLE_EGL_CLIENT_LIBS) -lm
+weston_nested_client_LDADD = $(SIMPLE_EGL_CLIENT_LIBS)
 weston_nested_client_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
 endif
 
@@ -560,7 +560,7 @@ weston_subsurfaces_CFLAGS = \
$(AM_CFLAGS)\
$(SIMPLE_EGL_CLIENT_CFLAGS) \
$(CLIENT_CFLAGS)
-weston_subsurfaces_LDADD = libtoytoolkit.la $(SIMPLE_EGL_CLIENT_LIBS) -lm
+weston_subsurfaces_LDADD = libtoytoolkit.la $(SIMPLE_EGL_CLIENT_LIBS)
 endif
 
 if HAVE_PANGO
@@ -916,7 +916,7 @@ vertex_clip_test_SOURCES =  \
tests/vertex-clip-test.c\
src/vertex-clipping.c   \
src/vertex-clipping.h
-vertex_clip_test_LDADD = libtest-runner.la -lm -lrt
+vertex_clip_test_LDADD = libtest-runner.la
 
 libtest_client_la_SOURCES =\
tests/weston-test-client-helper.c   \
@@ -984,7 +984,6 @@ matrix_test_SOURCES =   \
shared/matrix.c \
shared/matrix.h
 matrix_test_CPPFLAGS = -DUNIT_TEST
-matrix_test_LDADD = -lm -lrt
 
 if BUILD_SETBACKLIGHT
 noinst_PROGRAMS += setbacklight
diff --git a/configure.ac b/configure.ac
index 934..e78f6c8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -46,6 +46,12 @@ AC_CHECK_FUNC([dlopen], [],
   AC_CHECK_LIB([dl], [dlopen], DLOPEN_LIBS=-ldl))
 AC_SUBST(DLOPEN_LIBS)
 
+AC_SEARCH_LIBS([sqrt], [m], [],
+   [AC_MSG_FAILURE([Math library missing])])
+
+AC_SEARCH_LIBS([clock_gettime], [rt], [],
+   [AC_MSG_FAILURE([Real time library missing])])
+
 AC_CHECK_DECL(SFD_CLOEXEC,[],
  [AC_MSG_ERROR(SFD_CLOEXEC is needed to compile weston)],
  [[#include sys/signalfd.h]])
-- 
2.1.2

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

[weston V2 2/2] Use AC_SEARCH_LIBS instead of AC_CHECK_LIBS for dl, jpeg, pam

[Javier Jardón]

---
 Makefile.am  |  8 +++-
 configure.ac | 23 ++-
 2 files changed, 9 insertions(+), 22 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 1557953..077efbc 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -44,7 +44,7 @@ weston_LDFLAGS = -export-dynamic
 weston_CPPFLAGS = $(AM_CPPFLAGS) -DIN_WESTON
 weston_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS) $(LIBUNWIND_CFLAGS)
 weston_LDADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \
-   $(DLOPEN_LIBS) libshared.la
+   libshared.la
 
 weston_SOURCES =   \
src/git-version.h   \
@@ -130,10 +130,9 @@ weston_launch_SOURCES = src/weston-launch.c 
src/weston-launch.h
 weston_launch_CPPFLAGS = -DBINDIR='$(bindir)'
 weston_launch_CFLAGS=  \
$(GCC_CFLAGS)   \
-   $(PAM_CFLAGS)   \
$(SYSTEMD_LOGIN_CFLAGS) \
$(LIBDRM_CFLAGS)
-weston_launch_LDADD = $(PAM_LIBS) $(SYSTEMD_LOGIN_LIBS) $(LIBDRM_LIBS)
+weston_launch_LDADD = $(SYSTEMD_LOGIN_LIBS) $(LIBDRM_LIBS)
 
 if ENABLE_SETUID_INSTALL
 install-exec-hook:
@@ -818,8 +817,7 @@ libshared_cairo_la_LIBADD = \
$(PIXMAN_LIBS)  \
$(CAIRO_LIBS)   \
$(PNG_LIBS) \
-   $(WEBP_LIBS)\
-   $(JPEG_LIBS)
+   $(WEBP_LIBS)
 
 libshared_cairo_la_SOURCES =   \
$(libshared_la_SOURCES) \
diff --git a/configure.ac b/configure.ac
index e78f6c8..a1fd94a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -42,9 +42,8 @@ AC_ARG_VAR([WESTON_SHELL_CLIENT],
 
 PKG_PROG_PKG_CONFIG()
 
-AC_CHECK_FUNC([dlopen], [],
-  AC_CHECK_LIB([dl], [dlopen], DLOPEN_LIBS=-ldl))
-AC_SUBST(DLOPEN_LIBS)
+AC_SEARCH_LIBS([dlopen], [dl], [],
+   [AC_MSG_FAILURE([Dynamic linking loader missing])])
 
 AC_SEARCH_LIBS([sqrt], [m], [],
[AC_MSG_FAILURE([Math library missing])])
@@ -292,14 +291,8 @@ if test x$enable_vaapi_recorder != xno; then
 fi
 AM_CONDITIONAL(ENABLE_VAAPI_RECORDER, test x$have_libva = xyes)
 
-
-AC_CHECK_LIB([jpeg], [jpeg_CreateDecompress], have_jpeglib=yes)
-if test x$have_jpeglib = xyes; then
-  JPEG_LIBS=-ljpeg
-else
-  AC_ERROR([libjpeg not found])
-fi
-AC_SUBST(JPEG_LIBS)
+AC_SEARCH_LIBS([jpeg_CreateDecompress], [jpeg], [],
+   [AC_MSG_FAILURE([libjpeg not found])])
 
 PKG_CHECK_MODULES(CAIRO, [cairo])
 
@@ -366,12 +359,8 @@ AS_IF([test x$have_systemd_login_209 = xyes],
 AC_ARG_ENABLE(weston-launch, [  --enable-weston-launch],, 
enable_weston_launch=yes)
 AM_CONDITIONAL(BUILD_WESTON_LAUNCH, test x$enable_weston_launch == xyes)
 if test x$enable_weston_launch == xyes; then
-  AC_CHECK_LIB([pam], [pam_open_session], [have_pam=yes], [have_pam=no])
-  if test x$have_pam == xno; then
-AC_ERROR([weston-launch requires pam])
-  fi
-  PAM_LIBS=-lpam
-  AC_SUBST(PAM_LIBS)
+  AC_SEARCH_LIBS([pam_open_session], [pam], [],
+ [AC_MSG_FAILURE([weston-launch requires pam])])
 fi
 
 if test x$enable_egl = xyes; then
-- 
2.1.2

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

Re: [WESTON PATCH 2/2] compositor-drm: Watchdog timer implementation

[Frederic Plourde]

On 14-10-29 05:40 PM, Bill Spitzak wrote:

On 10/29/2014 12:19 PM, Frederic Plourde wrote:


Mhh... you mean something like :

static int
drm_output_watchdog_timer_create(struct drm_output *output)
{
 struct wl_event_loop *loop = NULL;
 struct weston_compositor *ec = output_base-compositor;

 loop = wl_display_get_event_loop(ec-wl_display);
 if (loop) {
 output-wdt-timer = wl_event_loop_add_timer(loop,
drm_output_watchdog_bark,
ec-watchdog_timer_timeout);
 blah..blah...


Yes that is what I meant.


If so, then I think I'd prefer to completely remove
'drm_output_watchdog_timer_create and inline it directly from
'create_output_for_connector', since it's not a very big function anyway
and we're not sure as of today that we're going to reuse this for
anything else.


Probably that is ok as well. The main problem is that it is impossible 
to inline the bark function so one part of the code is in a 
different place, which may mean it is clearer to put the reference to 
that function up next to it too.



what do you think ?
I'm usually not a big fan of static functions with hard-coded values,
but if you tell me it's better for clarity... I might be tempted, dunno.


Generally I don't think a generic function should be written until you 
have at least 2 instances where it is used.


I think you won me over... Let's pretend we're not going to use that for 
anything else for now.

patch v2 coming up next :)


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


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

[PATCH weston v2 2/2] compositor-drm: Watchdog timer implementation

[Frederic Plourde]

Weston will not repaint until previous update has been acked by
a page-flip event coming from the drm driver. However, some buggy drivers
won't return those events or will stop sending them at some point and
Weston output repaints will completely freeze. To ease developers' task in
testing their drivers, this patch makes compositor-drm use a watchdog timer
to detect cases where those page-flip events stop coming.

This watchdog timer (WDT) implementation is software only and includes
basic features usually found in a WDT. We simply exit Weston gracefully
with an exit code when the dog barks.

The watchdog timeout value can be set via weston.ini by adding a
watchdog-timer-timeout=SECONDS entry under a new [compositor-drm]
section. Setting this timeout to 0 disables the watchdog feature.

https://bugs.freedesktop.org/show_bug.cgi?id=83884
Signed-off-by: Frederic Plourde frederic.plou...@collabora.co.uk
---
 src/compositor-drm.c | 105 +++
 1 file changed, 105 insertions(+)

diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 07b83a7..45137cc 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -115,20 +115,22 @@ struct drm_compositor {
int cursors_are_broken;
 
int use_pixman;
 
uint32_t prev_state;
 
struct udev_input input;
 
uint32_t cursor_width;
uint32_t cursor_height;
+
+   uint32_t watchdog_timer_timeout;
 };
 
 struct drm_mode {
struct weston_mode base;
drmModeModeInfo mode_info;
 };
 
 struct drm_output;
 
 struct drm_fb {
@@ -176,20 +178,25 @@ struct drm_output {
struct drm_fb *current, *next;
struct backlight *backlight;
 
struct drm_fb *dumb[2];
pixman_image_t *image[2];
int current_image;
pixman_region32_t previous_damage;
 
struct vaapi_recorder *recorder;
struct wl_listener recorder_frame_listener;
+
+   struct watchdog_timer {
+   struct wl_event_source *timer;
+   uint32_t timeout;
+   } wdt;
 };
 
 /*
  * An output has a primary display plane plus zero or more sprites for
  * blending display contents.
  */
 struct drm_sprite {
struct wl_list link;
 
struct weston_plane plane;
@@ -215,20 +222,90 @@ struct drm_parameters {
int tty;
int use_pixman;
const char *seat_id;
 };
 
 static struct gl_renderer_interface *gl_renderer;
 
 static const char default_seat[] = seat0;
 
 static void
+drm_output_watchdog_timer_bark(void *output) {
+   /*
+   * Our watchdog just barked at us, means we're not receiving drm
+   * page flip events anymore for that output. Let's gracefully exit
+   * weston with a return value so devs can debug what's going on.
+   */
+   struct drm_output *out = (struct drm_output *) output;
+   struct weston_compositor *compositor =
+   (struct weston_compositor *) out-base.compositor;
+
+   weston_compositor_exit_with_code(compositor, EXIT_FAILURE);
+}
+
+/* Creates the watchdog timer. Note that timer is not armed by default */
+static int
+drm_output_watchdog_timer_create(struct drm_output *output)
+{
+   struct wl_event_loop *loop = NULL;
+   struct drm_compositor *ec =
+   (struct drm_compositor *) output-base.compositor;
+
+   loop = wl_display_get_event_loop(ec-base.wl_display);
+   if (loop) {
+   output-wdt.timer = wl_event_loop_add_timer(loop,
+ 
(wl_event_loop_timer_func_t)drm_output_watchdog_timer_bark,
+ output);
+
+   if (output-wdt.timer) {
+   output-wdt.timeout = ec-watchdog_timer_timeout;
+   return 0;
+   }
+   }
+
+   weston_log(creating drm watchdog timer failed: %m\n);
+   return -1;
+}
+
+/* Start/reset/arm the dog's timer. This can also be used to 'pat' the dog */
+static int
+drm_output_watchdog_timer_start(struct watchdog_timer *wdt)
+{
+   if (wdt-timer)
+   return wl_event_source_timer_update(wdt-timer, wdt-timeout);
+
+   weston_log(failed to start drm watchdog: %m\n);
+   return -1;
+}
+
+/* Disarms the watchdog */
+static int
+drm_output_watchdog_timer_stop(struct watchdog_timer *wdt)
+{
+   if (wdt-timer)
+   return wl_event_source_timer_update(wdt-timer, 0);
+
+   weston_log(failed to stop drm watchdog: %m\n);
+   return -1;
+}
+
+static void
+drm_output_watchdog_timer_destroy(struct watchdog_timer *wdt)
+{
+   if (wdt-timer) {
+   wl_event_source_remove(wdt-timer);
+   }
+
+   wdt-timer = NULL;
+}
+
+static void
 drm_output_set_cursor(struct drm_output *output);
 
 static int
 drm_sprite_crtc_supported(struct weston_output *output_base, uint32_t 
supported)
 {
struct weston_compositor *ec = output_base-compositor;
struct drm_compositor *c =(struct drm_compositor *) ec;
   

[PATCH weston v2 1/1] compositor: Add idle timeout option to weston.ini

[Frederic Plourde]

Weston's idle timeout can already be set via the '-i' command-line
option, but this patch lets users specify it also via weston.ini.
Note that the command-line option takes precedence over the .ini,
should the option be set by both.

This patch also Updates weston.ini man page with idle-timeout bits

https://bugs.freedesktop.org/show_bug.cgi?id=83921

Signed-off-by: Frederic Plourde frederic.plou...@collabora.co.uk
Reviewed-by: Bryce Harrington b.harring...@samsung.com
---
 man/weston.ini.man | 23 ---
 src/compositor.c   |  6 +-
 2 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/man/weston.ini.man b/man/weston.ini.man
index c05a221..a665ce1 100644
--- a/man/weston.ini.man
+++ b/man/weston.ini.man
@@ -62,21 +62,21 @@ Comment lines are ignored:
 .RS 4
 .nf
 .IR #comment
 .fi
 .RE
 .PP
 The section headers are:
 .PP
 .RS 4
 .nf
-.BR coreThe core modules
+.BR coreThe core modules and options
 .BR libinputInput device configuration
 .BR shell   Desktop customization
 .BR launcherAdd launcher to the panel
 .BR screensaver Screensaver selection
 .BR output  Output configuration
 .BR input-methodOnscreen keyboard input
 .BR keyboardKeyboard layouts
 .BR terminalTerminal application options
 .BR xwaylandXWayland options
 .BR screen-shareScreen sharing options
@@ -85,21 +85,21 @@ The section headers are:
 .PP
 Possible value types are string, signed and unsigned 32-bit
 integer, and boolean. Strings must not be quoted, do not support any
 escape sequences, and run till the end of the line. Integers can
 be given in decimal (e.g. 123), octal (e.g. 0173), and hexadecimal
 (e.g. 0x7b) form. Boolean values can be only 'true' or 'false'.
 .RE
 .SH CORE SECTION
 The
 .B core
-section is used to select the startup compositor modules.
+section is used to select the startup compositor modules and general options.
 .TP 7
 .BI shell= desktop-shell.so
 specifies a shell to load (string). This can be used to load your own
 implemented shell or one with Weston as default. Available shells
 in the
 .IR __weston_modules_dir__
 directory are:
 .PP
 .RS 10
 .nf
@@ -139,20 +139,37 @@ directory are:
 .fi
 .RE
 .BI gbm-format=format
 sets the GBM format used for the framebuffer for the GBM backend. Can be
 .B xrgb,
 .B xrgb2101010,
 .B rgb565.
 By default, xrgb is used.
 .RS
 .PP
+.RE
+.TP 7
+.BI idle-time=seconds
+sets Weston's idle timeout in seconds. This idle timeout is the time
+after which Weston will enter an inactive mode and screen will fade to
+black. Note that a screensaver may also start at this moment after fade-out
+(if enabled in the SCREENSAVER section below), but the current idle-time
+option has nothing to do with screensavers.
+
+.IR Important
+: This option may also be set via Weston's '-i' command
+line option and will take precedence over the current .ini option. This
+means that if both weston.ini and command line define this idle-timeout
+time, the one specified in the command-line will be used. On the other
+hand, if none of these sets the value, default idle timeout will be
+set to 300 seconds.
+.RS
 
 .SH LIBINPUT SECTION
 The
 .B libinput
 section is used to configure input devices when using the libinput input device
 backend.
 .PP
 Available configuration are:
 .TP 7
 .BI enable_tap= true
@@ -289,21 +306,21 @@ section is optional, as are all of the entries that may 
be specified in
 it.
 .TP 7
 .BI path= /usr/libexec/weston-screensaver
 This instructs the compositor to use the selected screensaver client on a given
 path (string). If this line is missing or commented out, the screensaver in
 .B weston(1)
 is disabled.
 .RE
 .TP 7
 .BI duration= 600
-The idle time in seconds until the screensaver disappears in order to save 
power
+The time in seconds until the screensaver disappears in order to save power
 (unsigned integer).
 .SH OUTPUT SECTION
 There can be multiple output sections, each corresponding to one output. It is
 currently only recognized by the drm and x11 backends.
 .TP 7
 .BI name= name
 sets a name for the output (string). The backend uses the name to
 identify the output. All X11 output names start with a letter X.  All
 Wayland output names start with the letters WL.  The available
 output names for DRM backend are listed in the
diff --git a/src/compositor.c b/src/compositor.c
index 4540911..015037f 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -4603,21 +4603,21 @@ int main(int argc, char *argv[])
*(*backend_init)(struct wl_display *display,
 int *argc, char *argv[],
 struct weston_config *config);
int i, fd;
char *backend = NULL;
char *shell = NULL;
char *modules = NULL;
char *option_modules = NULL;
char *log = NULL;
char *server_socket = NULL, *end;
-   int32_t idle_time = 300;
+   int32_t idle_time 

Re: [RFC PATCH v2 0/6] Initial per-surface color management

[Kai-Uwe Behrmann]

Am 29.10.2014 um 20:15 schrieb Niels Ole Salscheider:
 On Tuesday 28 October 2014, 15:45:18, Kai-Uwe Behrmann wrote:
 Am 27.10.2014 um 19:07 schrieb Niels Ole Salscheider:
 The support to mask the area of a surface so that its color space is not
 converted has been removed. Instead, the color profile of the main output
 of that surface can be attached if an application has a need to display
 uncorrected colors.
 I had a discussion regarding this with Zoxc on the IRC channel. Does it
 make sense to have a surface that is displayed uncorrected on multiple
 outputs with different output profiles?
 If so then this is not enough to detect that no color conversion should be
 applied at all.
 For measuring the colorimetric performance of outputs, for testing and
 scalability, it appears the easiest to have a colormanagement-off
 switch. On osX, without such switch, the mechanism to attach the monitor
 profile to the input image brings headache to developers and this
 workaround does not work reliably.
 Sure, I introduced the possibility to disable color correction of a surface 
 for these use-cases in my first proposal.
 But is it really enough to just not apply color corrections to a surface? Or 
 would this use-case require to deactivate color correction completely, as 
 argued by John Kåre Alsaker?

I can only guess what the motivation for a per output switch-off might be:
* graphic cards video lut handling
* compositing space triggering
* consistency with alpha blending behaviour for stacked transparent
surfaces with and without CM enabled
* effects on top of windows (sepia, etc.)

Some of the above mentioned mechanisms are not easy to integrate. So the
best is to have access to each mechanism by an separate API and let
applications handle them on need.

For compositing might arise the need to switch off the compositing
space. So a transparent widget on top of a graphics application will not
make the case to touch the rgb numbers, except for the blending areas of
course. Further the transparent widget can overlap in parts the CM-off
widget and normal areas at the same time. So the compositing of the
different areas has to be handled separately. Given that for different
outputs different colour conversions are needed, that feature appears
not that far stretched. The user experience will be relatively smooth.

In contrary, a global CM-off will have many side effects, which make
potentially a unwanted user experience for Yuv video, or other widgets,
which should not be affected on desktops. On handheld systems, that is
less of concern.

 In the latter case, it might be better to add another protocol that allows 
 such tools to temporarily deactivate any color conversions...

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

[PATCH libinput 3/4] evdev: add DPI to evdev calculations

[Derek Foreman]

Assume normal mice are 400DPI, and that all calculations should be
normalized to this before being fed into the filter.

There isn't yet a way to configure a device's DPI.
---
 src/evdev.c | 6 --
 src/evdev.h | 2 ++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index 341f7d8..8efa21a 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -42,6 +42,7 @@
 
 #define DEFAULT_AXIS_STEP_DISTANCE 10
 #define DEFAULT_MIDDLE_BUTTON_SCROLL_TIMEOUT 200
+#define DEFAULT_MOUSE_DPI 400
 
 enum evdev_key_type {
EVDEV_KEY_TYPE_NONE,
@@ -205,8 +206,8 @@ evdev_flush_pending_event(struct evdev_device *device, 
uint64_t time)
case EVDEV_NONE:
return;
case EVDEV_RELATIVE_MOTION:
-   motion.dx = device-rel.dx;
-   motion.dy = device-rel.dy;
+   motion.dx = device-rel.dx / ((double)device-dpi / 
DEFAULT_MOUSE_DPI);
+   motion.dy = device-rel.dy / ((double)device-dpi / 
DEFAULT_MOUSE_DPI);
device-rel.dx = 0;
device-rel.dy = 0;
 
@@ -1282,6 +1283,7 @@ evdev_device_create(struct libinput_seat *seat,
device-devname = libevdev_get_name(device-evdev);
device-scroll.threshold = 5.0; /* Default may be overridden */
device-scroll.direction = 0;
+   device-dpi = DEFAULT_MOUSE_DPI;
 
matrix_init_identity(device-abs.calibration);
matrix_init_identity(device-abs.usermatrix);
diff --git a/src/evdev.h b/src/evdev.h
index c0d6577..81dc140 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -135,6 +135,8 @@ struct evdev_device {
/* Checks if buttons are down and commits the setting */
void (*change_to_left_handed)(struct evdev_device *device);
} buttons;
+
+   int dpi;
 };
 
 #define EVDEV_UNHANDLED_DEVICE ((struct evdev_device *) 1)
-- 
2.1.1

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

[PATCH libinput 4/4] config: Allow setting non-default device DPI

[Derek Foreman]

This allows changing a device's DPI from the default 400
---
 src/evdev.c|  7 +++
 src/evdev.h|  3 +++
 src/libinput.c |  7 +++
 src/libinput.h | 22 ++
 4 files changed, 39 insertions(+)

diff --git a/src/evdev.c b/src/evdev.c
index 8efa21a..e267320 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1360,6 +1360,13 @@ evdev_device_get_id_vendor(struct evdev_device *device)
return libevdev_get_id_vendor(device-evdev);
 }
 
+enum libinput_config_status
+evdev_device_set_dpi(struct evdev_device *device, uint32_t dpi)
+{
+   device-dpi = dpi;
+   return LIBINPUT_CONFIG_STATUS_SUCCESS;
+}
+
 void
 evdev_device_set_default_calibration(struct evdev_device *device,
 const float calibration[6])
diff --git a/src/evdev.h b/src/evdev.h
index 81dc140..db462c6 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -309,4 +309,7 @@ evdev_to_left_handed(struct evdev_device *device,
return button;
 }
 
+enum libinput_config_status
+evdev_device_set_dpi(struct evdev_device *device, uint32_t dpi);
+
 #endif /* EVDEV_H */
diff --git a/src/libinput.c b/src/libinput.c
index 5780a92..88efae3 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -1501,3 +1501,10 @@ 
libinput_device_config_buttons_get_default_left_handed(struct libinput_device *d
 
return device-config.left_handed-get_default(device);
 }
+
+LIBINPUT_EXPORT enum libinput_config_status
+libinput_device_config_override_dpi(struct libinput_device *device,
+   uint32_t dpi)
+{
+   return evdev_device_set_dpi((struct evdev_device *) device, dpi);
+}
diff --git a/src/libinput.h b/src/libinput.h
index 9cc6f52..a721fc2 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -2007,6 +2007,28 @@ libinput_device_config_buttons_get_left_handed(struct 
libinput_device *device);
 int
 libinput_device_config_buttons_get_default_left_handed(struct libinput_device 
*device);
 
+
+/**
+ * @ingroup config
+ *
+ * Change the DPI setting of the device.
+ *
+ * Libinput assumes a normal mouse is 400DPI for some of its calculations.
+ * Ideally we would query mouse DPI from the device, but that isn't actually
+ * possible. To make things worse, some mice support multiple DPIs configured
+ * by a hardware switch, so even maintaining a database of mice becomes
+ * difficult. This function allows overriding the setting for mice we can't
+ * deal with any other way.
+ *
+ * @param device The device to configure
+ * @param dpi The device DPI
+ *
+ * @return A config status code
+ */
+enum libinput_config_status
+libinput_device_config_override_dpi(struct libinput_device *device,
+   uint32_t dpi);
+
 #ifdef __cplusplus
 }
 #endif
-- 
2.1.1

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

[PATCH libinput 1/4] filter: Fix typo

[Derek Foreman]

accelator - accelerator
---
 src/evdev.c  | 2 +-
 src/filter.c | 2 +-
 src/filter.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index dd2228b..341f7d8 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -981,7 +981,7 @@ int
 evdev_device_init_pointer_acceleration(struct evdev_device *device)
 {
device-pointer.filter =
-   create_pointer_accelator_filter(
+   create_pointer_accelerator_filter(
pointer_accel_profile_linear);
if (!device-pointer.filter)
return -1;
diff --git a/src/filter.c b/src/filter.c
index defbcae..205cd03 100644
--- a/src/filter.c
+++ b/src/filter.c
@@ -282,7 +282,7 @@ struct motion_filter_interface accelerator_interface = {
 };
 
 struct motion_filter *
-create_pointer_accelator_filter(accel_profile_func_t profile)
+create_pointer_accelerator_filter(accel_profile_func_t profile)
 {
struct pointer_accelerator *filter;
 
diff --git a/src/filter.h b/src/filter.h
index 1f53e81..0dc081b 100644
--- a/src/filter.h
+++ b/src/filter.h
@@ -53,7 +53,7 @@ typedef double (*accel_profile_func_t)(struct motion_filter 
*filter,
   uint64_t time);
 
 struct motion_filter *
-create_pointer_accelator_filter(accel_profile_func_t filter);
+create_pointer_accelerator_filter(accel_profile_func_t filter);
 
 
 /*
-- 
2.1.1

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

Python Project

[martins scun]

Hi everybody! I have a project for developing a Python based OS. Just for 
fun.It will use the Linux kernel and a python runtime to execute core modules 
and apps. Currently, I'm working on porting Wayland to python. If anybody's 
interested, I appreciate any help, specially from experienced devs. 
Thanks

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

[PATCH libinput 0/4] some acceleration fixes, mostly for high DPI mice

[Derek Foreman]

The acceleration filter currently isn't particularly pleased with gaming mice.

They generally have high DPI (can be over 8000 DPI) and can have high update
rates (1000+ per second).  This can result in the accel curve being biased
heavily towards the high points on the accel curve.

This patch set allows a way to normalize the deltas to 400DPI so when the
DPI setting of the mouse is correct, it should feel much the same as a
normal mouse.

This is, of course, only a partial solution.  Setting a reasonable default
is a massive problem that needs to be addressed in the future - for now
we just set it to 400 (which may actually not be that prevalent any more
but there doesn't seem to be such thing as a standard DPI mouse).

Derek Foreman (4):
  filter: Fix typo
  filter: perform speed computations with doubles
  evdev: add DPI to evdev calculations
  config: Allow setting non-default device DPI

 src/evdev.c| 15 ---
 src/evdev.h|  5 +
 src/filter.c   |  6 +++---
 src/filter.h   |  2 +-
 src/libinput.c |  7 +++
 src/libinput.h | 22 ++
 6 files changed, 50 insertions(+), 7 deletions(-)

-- 
2.1.1

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

Re: Reusing wl_egl_window for multiple EGL surfaces

[Virtual Presence]

I see, on the server side there are helpful APIs
like wl_event_loop_add_timer and wl_event_source_timer_update to integrate
timers into event loop but unfortunately not so on client side. I guess it
might not make sense for libwaylandclient to have such APIs but instead the
app/toolkits that implement the client part must have custom APIs coarsely
mirroring the server's functionality. From what i understand from the file
you pointed to it mainly does -
1) create main epoll_fd during setup
2) add display_fd to epoll_fd and the corresponding task handler and user
data
3) create and add timer_fd to the epoll_fd with its own task handler and
user_data

in main event loop of my simple app just keep performing epoll_wait like in
the file and invoke task handlers for generated events.

I will try to get this integrated into my app and post issues if any. Thank
you for all the help.

- VirtualPresence

On Thu, Oct 30, 2014 at 1:16 AM, Pekka Paalanen ppaala...@gmail.com wrote:

 On Wed, 29 Oct 2014 08:48:12 -0700
 Virtual Presence virtualpresence.u...@gmail.com wrote:

  Thank you for the detailed gyaan. I will look into the sub-surface
  protocol as an alternative. What I do as of now is have the 2 threads on
 a
  3 second timer where threadA renders triangle for 3 seconds then signals
 a
  mutex condition and wakes up threadB which renders gears for 3 seconds
 and
  so on and so on. I will also look into the option of reusing the
 wl_surface
  for multiple wl_egl_window. This seems closest to what i had in mind. I
  would also like to attach 3 second timer signal to the display FD and the
  custom queue i have setup for the 2 threads so that instead of having a
  dedicated timer logic I can blend the event handling into the Wayland
  model. I haven't been successful in doing this though. As an alternative
 I
  am looking into the option of writing a wl_timer protocol to provide the
  functionality. Any suggestions on how i can tie in the timer logic or any
  comments on having a dedicated wl_timer protocol? Thank you for all the
  help.

 Don't do anything with protocol about timers, unless your only goal is
 to learn how to define new protocols by a throw-away toy example.

 Your client is already polling the wayland connection fd. You can just,
 say, use timerfd API to create an fd for your timer needs, and simply
 add that to the poll set. That is what
 http://cgit.freedesktop.org/wayland/weston/tree/clients/window.c
 already does (look for display_watch_fd), for instance.

 Or use an event library that offers you everything in a portable
 fashion. Or a real toolkit.


 Thanks,
 pq

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

Re: [PATCH libinput v2] evdev: Log evdev event queue overflows

[Peter Hutterer]

On Wed, Oct 29, 2014 at 09:56:27AM -0500, Derek Foreman wrote:
 Log a message when the kernel event queue overflows and events are dropped.
 After 10 messages logging stops to avoid flooding the logs if the condition
 is persistent.

merged locally, thanks. but please sign off your patches to libinput. Can I
assume your s-o-b for this patch?

Cheers,
   Peter

 ---
  src/evdev.c | 11 +++
  src/evdev.h |  4 
  2 files changed, 15 insertions(+)
 
 diff --git a/src/evdev.c b/src/evdev.c
 index 1b4ce10..9026f5c 100644
 --- a/src/evdev.c
 +++ b/src/evdev.c
 @@ -924,6 +924,17 @@ evdev_device_dispatch(void *data)
   rc = libevdev_next_event(device-evdev,
LIBEVDEV_READ_FLAG_NORMAL, ev);
   if (rc == LIBEVDEV_READ_STATUS_SYNC) {
 + if (device-syn_drops_received  10) {
 + device-syn_drops_received++;
 + log_info(libinput, SYN_DROPPED event from 
 +  \%s\ - some input events have 
 +  been lost.\n, device-devname);
 + if (device-syn_drops_received == 10)
 + log_info(libinput, No longer logging 
 +  SYN_DROPPED events for 
 +  \%s\\n, device-devname);
 + }
 +
   /* send one more sync event so we handle all
  currently pending events before we sync up
  to the current state */
 diff --git a/src/evdev.h b/src/evdev.h
 index c0d6577..9e84623 100644
 --- a/src/evdev.h
 +++ b/src/evdev.h
 @@ -135,6 +135,10 @@ struct evdev_device {
   /* Checks if buttons are down and commits the setting */
   void (*change_to_left_handed)(struct evdev_device *device);
   } buttons;
 +
 + /* The number of times libevdev processes a SYN_DROPPED, so we can
 +  * stop logging them to avoid flooding the logs. */
 + int syn_drops_received;
  };
  
  #define EVDEV_UNHANDLED_DEVICE ((struct evdev_device *) 1)
 -- 
 2.1.1
 
 ___
 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 libinput v2] evdev: Log evdev event queue overflows

[Derek Foreman]

On 30/10/14 07:14 PM, Peter Hutterer wrote:
 On Wed, Oct 29, 2014 at 09:56:27AM -0500, Derek Foreman wrote:
 Log a message when the kernel event queue overflows and events are dropped.
 After 10 messages logging stops to avoid flooding the logs if the condition
 is persistent.
 
 merged locally, thanks. but please sign off your patches to libinput. Can I
 assume your s-o-b for this patch?

Yes, sorry, will do that from now on.

 Cheers,
Peter
 
 ---
  src/evdev.c | 11 +++
  src/evdev.h |  4 
  2 files changed, 15 insertions(+)

 diff --git a/src/evdev.c b/src/evdev.c
 index 1b4ce10..9026f5c 100644
 --- a/src/evdev.c
 +++ b/src/evdev.c
 @@ -924,6 +924,17 @@ evdev_device_dispatch(void *data)
  rc = libevdev_next_event(device-evdev,
   LIBEVDEV_READ_FLAG_NORMAL, ev);
  if (rc == LIBEVDEV_READ_STATUS_SYNC) {
 +if (device-syn_drops_received  10) {
 +device-syn_drops_received++;
 +log_info(libinput, SYN_DROPPED event from 
 + \%s\ - some input events have 
 + been lost.\n, device-devname);
 +if (device-syn_drops_received == 10)
 +log_info(libinput, No longer logging 
 + SYN_DROPPED events for 
 + \%s\\n, device-devname);
 +}
 +
  /* send one more sync event so we handle all
 currently pending events before we sync up
 to the current state */
 diff --git a/src/evdev.h b/src/evdev.h
 index c0d6577..9e84623 100644
 --- a/src/evdev.h
 +++ b/src/evdev.h
 @@ -135,6 +135,10 @@ struct evdev_device {
  /* Checks if buttons are down and commits the setting */
  void (*change_to_left_handed)(struct evdev_device *device);
  } buttons;
 +
 +/* The number of times libevdev processes a SYN_DROPPED, so we can
 + * stop logging them to avoid flooding the logs. */
 +int syn_drops_received;
  };
  
  #define EVDEV_UNHANDLED_DEVICE ((struct evdev_device *) 1)
 -- 
 2.1.1

 ___
 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: Python Project

[microcai]

在 2014年10月30日 星期四 21:36:15，martins scun 写道：
 Hi everybody! I have a project for developing a Python based OS. Just for
 fun.It will use the Linux kernel and a python runtime to execute core
 modules and apps. Currently, I'm working on porting Wayland to python. If
 anybody's interested, I appreciate any help, specially from experienced
 devs. Thanks

well, linux kernel is not python based. so, please write your own kernel with 
python!
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput 0/4] some acceleration fixes, mostly for high DPI mice

[Peter Hutterer]

On Thu, Oct 30, 2014 at 04:34:12PM -0500, Derek Foreman wrote:
 The acceleration filter currently isn't particularly pleased with gaming mice.
 
 They generally have high DPI (can be over 8000 DPI) and can have high update
 rates (1000+ per second).  This can result in the accel curve being biased
 heavily towards the high points on the accel curve.
 
 This patch set allows a way to normalize the deltas to 400DPI so when the
 DPI setting of the mouse is correct, it should feel much the same as a
 normal mouse.
 
 This is, of course, only a partial solution.  Setting a reasonable default
 is a massive problem that needs to be addressed in the future - for now
 we just set it to 400 (which may actually not be that prevalent any more
 but there doesn't seem to be such thing as a standard DPI mouse).

Thanks, I've pushed 1 to 3 (with added comments), not quite happy with
4 yet. As a configuration interface, it's mismatched with the usual quartett
of hooks that we provide for all other config options.

But I think providing a visible API may not be the right approach here
anyway. One idea I had here was to have this provided through udev, set
as something like:
LIBINPUT_MOUSE_DPI=400@80 # dpi @ poll rate

over time, the udev hwdb could add those settings, or we ship them as
extra rules, or users configure them themselves. this is unfortunately a
rather nasty task given the amount of HW out there, but I really can't think
of any other way (short of heuristics which will fail in too many ways).

Any ideas on feasability or better approaches welcome.

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