[PATCH libinput] touchpad: add pressure ranges for cyapa touchpads

[Peter Hutterer]

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

Signed-off-by: Peter Hutterer 
---
 src/evdev-mt-touchpad.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index e2866df..924e4f0 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -2385,6 +2385,9 @@ tp_init_pressure(struct tp_dispatch *tp,
if (device->model_flags & EVDEV_MODEL_ELANTECH_TOUCHPAD) {
tp->pressure.high = 24;
tp->pressure.low = 10;
+   } else if (device->model_flags & EVDEV_MODEL_CYAPA) {
+   tp->pressure.high = 8;
+   tp->pressure.low = 6;
} else {
/* Approximately the synaptics defaults */
tp->pressure.high = abs->minimum + 0.12 * range;
-- 
2.9.3

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

Re: [PATCH wayland v2 3/4] wayland-util: build/ship as separate shared library

[Emil Velikov]

On 17 March 2017 at 13:24, Daniel Stone  wrote:
> Hi,
>
> On 17 March 2017 at 12:07, Emil Velikov  wrote:
>> On 17 March 2017 at 11:10, Pekka Paalanen  wrote:
>>> On Thu, 16 Mar 2017 15:32:46 +
>>> Emil Velikov  wrote:
  - managing the compat server/client DSO in any build system will be a pain
>>>
>>> How so? Whose build system?
>>>
>>> User projects do not necessarily need any changes, ever.
>>>
>>> Wayland's build we need to set up once.
>>>
>>> So, again very much the same as your proposal.
>>>
>> Not quite - I see three ways to handle the compat server/client DSO:
>>  - symlinks
>> Distros love these - I've seen cases where they just remove them.
>>
>>  - hardlinks
>> Love again - if you're lucky enough the distro will ship the same file
>> X times and/or the debug package will be broken.
>> We even had people who explicitly hack them into symlinks even if they
>> need to be hardlinks for legitimate reasons.
>
> These don't work for DSOs loaded through ld.so. :\ For modules it's
> fine, since you're only asking dlopen() to open a file and use that,
> whatever it may be. But if ld.so is trying to satisfy a DT_NEEDED for
> libwayland-client.so.1, it will open libwayland-client.so.1, see that
> its SONAME is libwayland.so.1, decide it does not satisfy the
> dependency, and ignore it. Maybe not the case everywhere, but at least
> on Debian jessie on armhf, older Mali binaries which shipped
> libEGL.so.1/libGLESv2.so.2/etc as symlinks to libmali.so, I had to
> create real ELF objects for each library, with a matching SONAME and a
> DT_NEEDED to libmali.so.
>
>>  - ld script, ALA libc.so/libpthread.so
>> Not sure how portable those across C runtime(s). No idea how well
>> dlopen/dlsym will work with these.
>>
>>  - symbol forwarding
>> It's a lot of fancy code and C runtime specific. You need reasonably
>> new glibc and even then there were some bugs - one GLVND dev had a bug
>> for 2+yo bug which did not get any input.
>>
>> Most/all of the above are doable, yet rather icky.
>
> So let's take libwayland.so off the table then, and come back to
> libwayland-util.so. Thanks for putting together your testcase, which I
> did try, but it doesn't actually work.
>
> Firstly, libwayland-server in this patchset gains a hard Requires on
> wayland-util, meaning that -lwayland-util explicitly finds its way
> into link lines. So, even if you're only using old ABI, if you build a
> binary against a post-split library, you cannot run it in an
> environment with a pre-split library. This is a dealbreaker for me,
> because it is an ABI change.
>
Thanks for testing !

Very valid point -  the way to address that is to bump the
-version-info, like it has been done [twice] already.
And if one is brave/silly enough to dlopen/dlsym the symbols out of
libwayland-client/server regardless of the details (which version/etc)
things will just work. Do experiment with the wl-dl-test program in
the repo.

>
> NAK from me.
>
> There are real issues this causes, and I'm still not in any way
> convinced of the rationale for making this rather dangerous change in
> the first place. Much like with the discussion on Mesa's symbol
> exports, in a vacuum you are correct: it should have been done this
> way in the first place. If there was a compelling rationale to change
> it, then we could have a discussion about the best thing to do.
>
> Right now, you have failed to convince people that the upsides of your
> change (which are entirely hypothetical AFAICT) are outweigh the
> downsides (actually breaking real-world users who exist and would be
> seriously pissed off). My NAK is for the downside (this breakage,
> another DSO to version), and given the risk of extremely subtle
> breakage given everyone's disparate toolchain versions and
> configurations, will stand until there is a well-established set of
> benefits for doing this which outweighs that risk.
>
> If you want to avoid sinking too much time into this, I suggest you
> work on polishing the rationale first.
>
Agreed, I could and should sell it out better.

There's a thing that I've been wondering - have you/Pekka/others had
"fun" experience fixing up after symbol collisions ?
I'm been "blessed" to spend days tracking both in-kernel and
userspaces instances. It's a lot harder track since it doesn't always
behave in the same way plus it's not something one expects.

Yes, the type of issue I'm thinking is 'hypothetical', but once you've
burnt a few times you don't listen to the people saying "it will never
happen".
At the same time, any issues that may arise are also hypothetical and
I greatly welcome _everyone_ to voice their concern so that I can
address it.

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

Re: [PATCH weston] man: move pageflip-timeout later

[Daniel Stone]

On 13 March 2017 at 13:25, Pekka Paalanen  wrote:
> The paragraph about pageflip-timeout was added in between the two
> paragraphs of idle-time, causing the paragraphs to be associated wrong.
>
> Move the pageflip-timeout paragraph to the end.

Reviewed and pushed:
To ssh://git.freedesktop.org/git/wayland/weston
   76091789..65e57c93  push -> master

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

Re: [weston v2] linux-dmabuf: align DMABUF exposed formats with EGL supported formats

[Vincent ABRIOU]

Hi Daniel,

Any feedback on this patch?

Thanks
Vincent

On 02/10/2017 03:30 PM, Vincent Abriou wrote:
> Expose to the DMABUF protocol the pixel formats already explicitly
> supported as fallback by gl-renderer in import_yuv_dmabuf function plus
> the standard RGB formats that all GPU supports:
> ARGB, XRGB, RGB565, YUYV, NV12, YUV420 and YUV444.
>
> Signed-off-by: Vincent Abriou 
> ---
> v2:
>  - Remove dependency with libdrm as suggested by Daniel Stone.
>To do so, the reuse of wl_shm enums is not possible because
>WL_SHM_FORMAT_ARGB (=0) and WL_SHM_FORMAT_XRGB (=1) do not
>match fourcc. So I had to directly use fourcc to describe the supported
>dmabuf formats.
>
>
>  libweston/linux-dmabuf.c | 29 ++---
>  1 file changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/libweston/linux-dmabuf.c b/libweston/linux-dmabuf.c
> index 7b29f08..748b664 100644
> --- a/libweston/linux-dmabuf.c
> +++ b/libweston/linux-dmabuf.c
> @@ -30,6 +30,29 @@
>  #include "compositor.h"
>  #include "linux-dmabuf.h"
>  #include "linux-dmabuf-unstable-v1-server-protocol.h"
> +#include "shared/helpers.h"
> +
> +/* linux-dmabuf should not be dependent from libdrm thus we need to define
> + * dmabuf formats using fourcc */
> +#define fourcc_code(a, b, c, d) ((uint32_t)(a) | ((uint32_t)(b) << 8) | \
> + ((uint32_t)(c) << 16) | ((uint32_t)(d) << 24))
> +
> +uint32_t dmabuf_formats[] = {
> + /* ARGB [31:0] A:R:G:B 8:8:8:8 little endian */
> + fourcc_code('A', 'R', '2', '4'),
> + /* XRGB [31:0] x:R:G:B 8:8:8:8 little endian */
> + fourcc_code('X', 'R', '2', '4'),
> + /* RGB565   [15:0] R:G:B 5:6:5 little endian*/
> + fourcc_code('R', 'G', '1', '6'),
> + /* YUYV [31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
> + fourcc_code('Y', 'U', 'Y', 'V'),
> + /* NV12 2x2 subsampled Cr:Cb plane*/
> + fourcc_code('N', 'V', '1', '2'),
> + /* YUV420   2x2 subsampled Cb (1) and Cr (2) planes*/
> + fourcc_code('Y', 'U', '1', '2'),
> + /* YUV444   non-subsampled Cb (1) and Cr (2) planes */
> + fourcc_code('Y', 'U', '2', '4'),
> +};
>
>  static void
>  linux_dmabuf_buffer_destroy(struct linux_dmabuf_buffer *buffer)
> @@ -423,6 +446,7 @@ bind_linux_dmabuf(struct wl_client *client,
>  {
>   struct weston_compositor *compositor = data;
>   struct wl_resource *resource;
> + unsigned int i;
>
>   resource = wl_resource_create(client, _linux_dmabuf_v1_interface,
> version, id);
> @@ -434,9 +458,8 @@ bind_linux_dmabuf(struct wl_client *client,
>   wl_resource_set_implementation(resource, _dmabuf_implementation,
>  compositor, NULL);
>
> - /* EGL_EXT_image_dma_buf_import does not provide a way to query the
> -  * supported pixel formats. */
> - /* XXX: send formats */
> + for (i = 0; i < ARRAY_LENGTH(dmabuf_formats); i++)
> + zwp_linux_dmabuf_v1_send_format(resource, dmabuf_formats[i]);
>  }
>
>  /** Advertise linux_dmabuf support
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel