How to handle DRM crtc_id, connector_id greater than 31

To whom it may concern: We have encountered a Weston hotplug issue with DRM backend where the hotplug of HDMI connector caused unexpected Weston exit recently. The root cause of the problem is that the DRM connector id of the HDMI display exceeds 31, but the corresponding active bitmap variable

[RFE wayland] protocol: add axis_source.wheel_tilt

Signed-off-by: Peter Hutterer --- This is missing the various version bumps, it's just an RFE at this point. We have a bit of a problem with the axis sources in the wayland protocol in that they're sent but not really explained well in the protocol. So to match the rest

[RFE weston] Support the new wheel tilt axis source

Signed-off-by: Peter Hutterer --- Also just an RFE, it's missing the various version requirements (libinput doesn't have a tag for this yet). Not much we can do in weston but treat it effectively the same as the wheel rotation. clients/eventdemo.c | 3 +++

Re: Create cross wayland-scanner for toolchain or cross-development environment

On Fri, 2 Dec 2016 17:06:29 + Emil Velikov wrote: > On 2 December 2016 at 14:55, Pekka Paalanen wrote: > > On Fri, 8 Jul 2016 11:29:16 +0100 > > Emil Velikov wrote: > > > >> Hi all, > >> > >> Jumping the gun a bit,

Re: Recommended dev setup?

On Sat, 3 Dec 2016 14:48:53 +1100 David Piper wrote: > I'll be pushing along in Ubuntu for now but I thought I should throw the > question out here - what is the best dev loop for working with Wayland? > Should I be using Ubuntu or should I look for an OS that supports

Re: Create cross wayland-scanner for toolchain or cross-development environment

Hi guys, This is no versioning question. I think when the host,target is not equal to build (I mean configure options --build,--taget,--host) we can compile two scanners: 1) scanner built by cross compiler and has original name (wayland-scanner) 2) scanner built by BUILD_CC and has complex name,

Re: [PATCH weston] xdg-shell: Add NULL checks for resources that may have gone away.

On Sat, 3 Dec 2016 21:21:44 -0800 Dima Ryazanov wrote: > This should fix some (fairly rare) crashes where the client goes away at > exactly > the wrong moment, e.g.: > - Weston sends a message to the client > - Message causes the client to crash for whatever reason > - Weston

Re: Create cross wayland-scanner for toolchain or cross-development environment

On Mon, 5 Dec 2016 14:13:23 +0300 Andrew Kosteltsev wrote: > Hi guys, > > This is no versioning question. I think when the host,target is not equal > to build (I mean configure options --build,--taget,--host) we can compile > two scanners: Sorry, indeed, this thread was

Re: [PATCH libinput] touchpad: sync BTN_TOOL_FINGER state on init

Hi, On 05-12-16 05:00, Peter Hutterer wrote: The Elantech touchpad on my Asus Vivobook doesn't release BTN_TOOL_FINGER on up. If the touchpad was used before libinput initializes, the kernel filters the event because its state is already set. We never receive it and keep ignoring all events

Re: [PATCH weston v2 2/2] compositor: allow to control the vt switching

2016-11-25 15:10 GMT+01:00 Pekka Paalanen : > On Wed, 29 Jun 2016 11:57:12 +0200 > Giulio Camuffo wrote: > >> A compositor may want to control the vt switching, for example to >> ensure to have a lock screen before it. To enable that add a vfunc >>

[PATCH wayland v2] doc: start documenting Xwayland

From: Pekka Paalanen This is a rough intro to what Xwayland is and does, with just one implementation detail so far (Window identification). I paid no attention to formatting details, those can be polished in follow-ups. I just want the prose out. I also just

Re: [PATCH weston v3] libweston: Position layers in an absolute way

2016-07-11 11:29 GMT+02:00 Quentin Glidic : > From: Quentin Glidic > > Currently, layers’ order depends on the module loading order and it does > not survive runtime modifications (like shell locking/unlocking). > With this patch,

Re: [PATCH weston v2 2/2] compositor: allow to control the vt switching

On Mon, 5 Dec 2016 14:45:49 +0100 Giulio Camuffo wrote: > 2016-11-25 15:10 GMT+01:00 Pekka Paalanen : > > On Wed, 29 Jun 2016 11:57:12 +0200 > > Giulio Camuffo wrote: > > > >> A compositor may want to control the vt

[PATCH weston v4] libweston: Position layers in an absolute way

From: Quentin Glidic Currently, layers’ order depends on the module loading order and it does not survive runtime modifications (like shell locking/unlocking). With this patch, modules can safely add their own layer at the expected position in the stack, with runtime

[PATCH weston v3 1/2] launcher: don't try to switch to weston's vt

Signed-off-by: Giulio Camuffo Reviewed-by: Pekka Paalanen --- v3: changed the summary to say "weston's vt" instead of "current vt" libweston/launcher-direct.c| 12 libweston/launcher-impl.h | 2 ++

[PATCH weston v3 2/2] compositor: allow to control the vt switching

A compositor may want to control the vt switching, for example to ensure to have a lock screen before it. To enable that add a vfunc that will be called when CTRL+ALT+FN is pressed. The default behavior is to do the switching, but the user can change it by using the new

Re: Create cross wayland-scanner for toolchain or cross-development environment

Ok. At least I can use USE_HOST_SCANNER variable or continue to patch Wayland Makefiles. That is not a problem for me. Best Regards, Andrey K. On Mon, Dec 5, 2016 at 3:23 PM, Pekka Paalanen wrote: > On Mon, 5 Dec 2016 14:13:23 +0300 > Andrew Kosteltsev

[PATCH wayland] server: use a safer signal type for the wl_resource destruction signals

wl_list_for_each_safe, which is used by wl_signal_emit is not really safe. If a signal has two listeners, and the first one removes and re-inits the second one, it would enter an infinite loop, which was hit in weston on resource destruction, which emits a signal. This commit adds a new version of

Re: [PATCH weston v3] libweston: Position layers in an absolute way

On Mon, 11 Jul 2016 11:29:40 +0200 Quentin Glidic wrote: > From: Quentin Glidic > > Currently, layers’ order depends on the module loading order and it does > not survive runtime modifications (like shell locking/unlocking). > With

Re: [RFC PATCH 0/8] Meson build system

Hi, On 5 December 2016 at 00:05, Peter Hutterer wrote: > On Fri, Dec 02, 2016 at 07:39:02PM +, Emil Velikov wrote: >> IIRC some have the philosophical reasoning alike "thou shall not need >> anything but autofoo and dependencies explicitly required" while >> others

Re: [PATCH weston v3] libweston: Position layers in an absolute way

On 05/12/2016 16:29, Pekka Paalanen wrote: On Mon, 11 Jul 2016 11:29:40 +0200 Quentin Glidic wrote: From: Quentin Glidic Currently, layers’ order depends on the module loading order and it does not survive runtime modifications

Re: [PATCH weston v3] libweston: Position layers in an absolute way

On Mon, 5 Dec 2016 16:48:38 +0100 Quentin Glidic wrote: > On 05/12/2016 16:29, Pekka Paalanen wrote: > > On Mon, 11 Jul 2016 11:29:40 +0200 > > Quentin Glidic wrote: > > > >> From: Quentin Glidic >

Re: Proposal to add 'raise' and 'lower' to xdg-shell in wayland-protocols

To echo Jonas's comments, I'm also strongly opposed to adding window stacking manipulation to the xdg-shell protocol. It's already a mess handling windows which try to raise/focus themselves in X11, this is not an issue I want to handle under Wayland. EFL also has functionality in the toolkit for

Re: [Mesa-dev] [PATCH mesa] add EGL_TEXTURE_EXTERNAL_WL to WL_bind_wayland_display spec

Hi, On 10 June 2014 at 15:46, Rob Clark wrote: > On Mon, Jun 9, 2014 at 5:53 AM, Pekka Paalanen wrote: >> On Thu, 16 Aug 2012 17:28:19 -0500 Rob Clark wrote: >>> From: Rob Clark >> >> it looks like this patch never