[PATCH libinput 2/2] touchpad: enable palm detection on tablets' touchpads

Signed-off-by: Peter Hutterer --- src/evdev-mt-touchpad.c| 18 -- src/evdev.c| 8 src/evdev.h| 1 + udev/90-libinput-model-quirks.hwdb | 4 4 files changed, 25 insertions(+), 6

[PATCH libinput 1/2] touchpad: init touch size range based on the udev property

No need to hardcode Apple here, if we have a udev property for this, let's use it. Signed-off-by: Peter Hutterer --- src/evdev-mt-touchpad.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/src/evdev-mt-touchpad.c

[RFC weston] clients: Don't attach a buffer if mouse cursor surface is unchanged

Keep track of what cusor image buffer is attached to the cursor surface and avoid re-attaching it if we don't have to. This isn't just an obviously pointless optimization, it turns all of toy toolkit into a test case for handling this properly. Signed-off-by: Derek Foreman

Re: [PATH] core: implement a safe wl_signal_emit

On 2018-02-22 01:36 PM, Markus Ongyerth wrote: On 2018/2月/22 12:31, Derek Foreman wrote: On 2018-02-22 10:48 AM, Markus Ongyerth wrote: On 2018/2月/22 09:34, Derek Foreman wrote: On 2018-02-22 08:58 AM, Daniel Stone wrote: Hi, On 22 February 2018 at 14:14, Markus Ongyerth

[RFC wayland] server: Add special case destroy signal emitter

In the past much code (weston, efl/enlightenment, mutter) has freed structures containing wl_listeners from destroy handlers without first removing the listener from the signal. As the destroy notifier only fires once, this has largely gone unnoticed until recently. Other code does not (Qt,

Re: [PATH] core: implement a safe wl_signal_emit

On 2018/2月/22 12:31, Derek Foreman wrote: > On 2018-02-22 10:48 AM, Markus Ongyerth wrote: > > On 2018/2月/22 09:34, Derek Foreman wrote: > > > On 2018-02-22 08:58 AM, Daniel Stone wrote: > > > > Hi, > > > > > > > > On 22 February 2018 at 14:14, Markus Ongyerth wrote: > > > > > >

Re: [PATCH wayland v2 4/4] tests: add code, public-code and private-code tests

On 2018-02-22 05:55 AM, Pekka Paalanen wrote: On Thu, 22 Feb 2018 11:23:39 + Emil Velikov wrote: From: Emil Velikov First one is deprecated in favour of the second option. The latter is newly introduced and annotates the generated

Re: [PATH] core: implement a safe wl_signal_emit

On 2018/2月/22 04:53, Daniel Stone wrote: > Hi ongy, > > On 22 February 2018 at 16:03, Markus Ongyerth wrote: > > On 2018/2月/22 02:58, Daniel Stone wrote: > >> On 22 February 2018 at 14:14, Markus Ongyerth wrote: > >> > The code was buggy the whole time. Just

Re: [PATCH v2] touchpad: add wobbling detection

On 21.02.2018 03:33, Peter Hutterer wrote: It should work like it previously did; what bothers me however — shouldn't that be specific to a touch, but not touchpad? Couldn't that get triggered e.g. by 2-finger scrolling? (whatever that is, I dunno, touching with 2 finger doesn't scroll for me —

Re: [PATH] core: implement a safe wl_signal_emit

On 2018-02-22 10:48 AM, Markus Ongyerth wrote: On 2018/2月/22 09:34, Derek Foreman wrote: On 2018-02-22 08:58 AM, Daniel Stone wrote: Hi, On 22 February 2018 at 14:14, Markus Ongyerth wrote: It seems that this patch makes that assumption invalid, and we would need patches to

Re: [PATH] core: implement a safe wl_signal_emit

Hi ongy, On 22 February 2018 at 16:03, Markus Ongyerth wrote: > On 2018/2月/22 02:58, Daniel Stone wrote: >> On 22 February 2018 at 14:14, Markus Ongyerth wrote: >> > The code was buggy the whole time. Just because it was never triggered, >> > does >> > not imply

Re: [PATH] core: implement a safe wl_signal_emit

On 2018/2月/22 09:34, Derek Foreman wrote: > On 2018-02-22 08:58 AM, Daniel Stone wrote: > > Hi, > > > > On 22 February 2018 at 14:14, Markus Ongyerth wrote: > > > > It seems that this patch makes that assumption invalid, and we would > > > > need patches to weston, enlightenment,

Re: [RFC wayland-protocols] Add contribution guidelines for desktop extensions

Hi Pekka, On 22 February 2018 at 08:32, Pekka Paalanen wrote: > +Once there is sufficient cross-desktop support for a proposal, the Wayland > +maintainers can accept the extension into wayland-protocols. > + Might be worth defining "sufficient" in a bullet point somewhere.

Re: [PATH] core: implement a safe wl_signal_emit

On 2018/2月/22 02:58, Daniel Stone wrote: > Hi, > > On 22 February 2018 at 14:14, Markus Ongyerth wrote: > >> It seems that this patch makes that assumption invalid, and we would > >> need patches to weston, enlightenment, and mutter to prevent a > >> use-after-free during the

Re: [PATH] core: implement a safe wl_signal_emit

On 2018-02-22 08:58 AM, Daniel Stone wrote: Hi, On 22 February 2018 at 14:14, Markus Ongyerth wrote: It seems that this patch makes that assumption invalid, and we would need patches to weston, enlightenment, and mutter to prevent a use-after-free during the signal emit? Now

Re: [PATH] core: implement a safe wl_signal_emit

Hi, On 22 February 2018 at 14:14, Markus Ongyerth wrote: >> It seems that this patch makes that assumption invalid, and we would >> need patches to weston, enlightenment, and mutter to prevent a >> use-after-free during the signal emit? Now I'm seeing valgrind errors >> on E and

[PATCH weston] input: never set keyboard focus without wl_resource

From: Pekka Paalanen Do not attempt to set keyboard focus to a surface that has no wl_resource. The destroy listener hangs off the wl_resource, so if that is not present, nothing will clean up the pointer when the weston_surface gets destroyed and it goes stale.

[PATCH weston] compositor-wayland: handle wl_keyboard.enter(NULL)

From: Pekka Paalanen Destroying an output (wl_surface) can race against the parent compositor sending wl_keyboard.enter. When this race is lost, wayland-backend receives wl_keyboard.enter with a NULL wl_surface for the surface it just destroyed. Handle this case

[PATH] core: implement a safe wl_signal_emit

> Since a destroy signal inidicates the object is utterly dead, I don't think > it's unreasonable for users to have assumed that they don't have to clean up > their listener link. It's *never* going to fire again, so why should > anything need to be removed? This only implies that the signal

Re: [PATCH wayland v2 4/4] tests: add code, public-code and private-code tests

On Thu, 22 Feb 2018 11:23:39 + Emil Velikov wrote: > From: Emil Velikov > > First one is deprecated in favour of the second option. > > The latter is newly introduced and annotates the generated symbols > accordingly. > > v2: Don't

[PATCH wayland v2 4/4] tests: add code, public-code and private-code tests

From: Emil Velikov First one is deprecated in favour of the second option. The latter is newly introduced and annotates the generated symbols accordingly. v2: Don't introduce small-public-code.c - reuse small-code.c (Pekka) Cc: Pekka Paalanen

Re: [PATCH wayland 4/4] tests: add code, public-code and private-code tests

Hi Pekka, Thanks for having a look! On 22 February 2018 at 10:26, Pekka Paalanen wrote: >> +# The existing "code" must produce result identical to "public-code" >> +generate_and_compare "code" "small.xml" "small-public-code.c" >> +generate_and_compare "public-code"

Re: [RFC wayland-protocols] Add contribution guidelines for desktop extensions

[Using GMail, so this is going to be terrible for patch reviewing] On 22 February 2018 at 08:32, Pekka Paalanen wrote: > From: Pekka Paalanen > > I have the feeling that we would benefit from a documented process on > how to propose

Re: [PATCH wayland] tests: Test for use after free in resource destruction signals

On Wed, 21 Feb 2018 13:08:51 -0600 Derek Foreman wrote: > For years it's been common practice to free the object containing > the wl_listner inside resource destruction notifiers, but not > remove the listener from the list. > > That is: It's been safe to assume that the

Re: [PATCH wayland 4/4] tests: add code, public-code and private-code tests

On Fri, 16 Feb 2018 16:22:33 + Emil Velikov wrote: > From: Emil Velikov > > First one is deprecated in favour of the second option. > > The latter is newly introduced and annotates the generated symbols > accordingly. > >

Re: [PATCH wayland 3/4] scanner: make use of __has_attribute()

On Fri, 16 Feb 2018 16:22:32 + Emil Velikov wrote: > From: Emil Velikov > > A more generic way to evaluating various attributes, __has_attribute is > available with gcc, clang, even the Oracle/Sun compiler. > > Signed-off-by: Emil

Re: [PATCH wayland 2/4] build: use public-code when using the local wayland-scanner

On Fri, 16 Feb 2018 16:22:31 + Emil Velikov wrote: > From: Emil Velikov > > The core wayland interfaces are public, via the libwayland-server and > libwayland-client DSOs. Hence use "public-code" cmdline option, instead > of the

Re: [PATCH wayland 1/4] scanner: introduce "public-code" and "private-code"

On Fri, 16 Feb 2018 16:22:30 + Emil Velikov wrote: > From: Emil Velikov > > The options are used to indicate how the code will be used - will it be > public, as part of a DSO or private. > > In nearly every instance, people want to use

[RFC wayland-protocols] Add contribution guidelines for desktop extensions

From: Pekka Paalanen I have the feeling that we would benefit from a documented process on how to propose cross-desktop extensions. Right now, contributors may send a proposal to wayland-devel list only, be met with complete silence, and walk away frustrated. I

Re: [PATCH weston 1/2 v3] compositor-drm: Add support for DRM lease

On Wed, 21 Feb 2018 17:16:07 +0100 Philipp Zabel wrote: > Hi Marius, > > On Wed, 2018-02-21 at 16:49 +0200, Marius Vlad wrote: > > Signed-off-by: Marius Vlad > > --- > > Makefile.am| 2 + > > compositor/main.c |