RE: Using Soft Keys with Weston & Libinput

Hello Bill, Please watch this video for seeing the navigation device in action: https://www.youtube.com/watch?v=dUgW5M5ztww The entire screen is touch panel, and it is rectangular. But the compositor gets touch events only from the area of display. The location of soft keys, volume slider and

Re: [PATCH libinput 1/2] udev: fix ALPS firmware detection

On 09/02/16 03:12, Peter Hutterer wrote: > The firmware version is in id.version, not id.model which is always > PSMOUSE_ALPS for ALPS devices. > > The various fw versions are listed in /drivers/input/mouse/alps.h and > are all hex numbers. Version 8 is actually 0x800, change the match >

Re: [PATCH libinput 1/2] udev: fix ALPS firmware detection

Hi, On 09-02-16 03:12, Peter Hutterer wrote: The firmware version is in id.version, not id.model which is always PSMOUSE_ALPS for ALPS devices. The various fw versions are listed in /drivers/input/mouse/alps.h and are all hex numbers. Version 8 is actually 0x800, change the match accordingly.

Re: [PATCH weston v3] drm: port the drm backend to the new init api

On Mon, 8 Feb 2016 16:01:13 -0800 Bill Spitzak wrote: > I thought the purpose of this was so that compositors could pass to the > backend DRM configuration data supplied by the clients, therefore the api > that clients use to pass this information seemed pretty important. No,

Re: [PATCH weston v3] drm: port the drm backend to the new init api

On 9 February 2016 at 00:01, Bill Spitzak wrote: > I thought the purpose of this was so that compositors could pass to the > backend DRM configuration data supplied by the clients, therefore the api > that clients use to pass this information seemed pretty important. If you

Re: [PATCH weston v3] drm: port the drm backend to the new init api

I thought the purpose of this was so that compositors could pass to the backend DRM configuration data supplied by the clients, therefore the api that clients use to pass this information seemed pretty important. On Mon, Feb 8, 2016 at 1:53 PM, Daniel Stone wrote: > On

Re: [PATCH weston v3] drm: port the drm backend to the new init api

On Mon, Feb 8, 2016 at 2:02 AM, Pekka Paalanen wrote: > On Fri, 5 Feb 2016 21:03:20 +0100 > Benoit Gschwind wrote: > > > Hello, > > > > I will add my opinion as called for opinions. First I made a quick > > brainstorm following previous proposals about

Re: [PATCH weston v3] drm: port the drm backend to the new init api

On Tue, 9 Feb 2016 01:11:48 +0100 Benoit Gschwind wrote: > Hello, > > while I developing the option 2. I raise few questions because this > option explicit the fact that back-ends does not share the same API (at > less for the configuration). To resolve the issue I found

[RFC weston 5/5] x11: Move to libweston

From: Quentin Glidic Signed-off-by: Quentin Glidic --- Makefile.am | 2 +- {src => lib}/compositor-x11.c | 87 --- lib/libweston.c | 2 + lib/libweston.h

Re: [server-core] Add signal for creation of clients.

Hi, thanks, i think this was long overdue. I have a few comments below. 2016-02-04 11:59 GMT+02:00 : > Using display object, if a new client is created, emit a signal. > > In the server-side, we can get the destroy event of a client, The indentation is weird from

[RFC weston 1/5] libweston: Initial dummy library

From: Quentin Glidic Signed-off-by: Quentin Glidic --- Makefile.am | 13 - lib/libweston-internal.h | 14 ++ lib/libweston.c | 29 + lib/libweston.h | 17

[RFC weston 0/5] libweston: section+key=value backend config

From: Quentin Glidic Here is my draft for the key/value backend config idea. As I stated on IRC already, I think the key/value config is the nicer one. First two patches are quite independent from the backend config topic, but are needed to get the final config API

[RFC weston 3/5] libweston: Add config getters API

From: Quentin Glidic Signed-off-by: Quentin Glidic --- Makefile.am | 1 + lib/backend-config.c | 33 lib/libweston-internal.h | 10 lib/libweston.h | 11 src/compositor.c |

[RFC weston 4/5] drm: Move backend to libweston

From: Quentin Glidic Signed-off-by: Quentin Glidic --- Makefile.am | 10 ++--- {src => lib}/compositor-drm.c | 87 +++ {src => lib}/libbacklight.c | 0 {src =>

[RFC weston 2/5] libweston: Move weston_load_module here

From: Quentin Glidic Signed-off-by: Quentin Glidic --- ivi-shell/ivi-layout.c | 3 ++- lib/libweston.c | 47 +++ lib/libweston.h | 2 ++ src/compositor-drm.c | 9

[PATCH] drm-backend-refactor-draft

From: Benoit Gschwind (blocage) Hello, To feed the discution here is my proposal, mostly derivated from giucam work. it's not intend to be merged as-is (several memory leak). It illustrate a specific configuration API and a generic backend load. Best regards ---

Re: [PATCH wayland] shm: add a note about shm pool base address changing

On Mon, 08 Feb 2016 12:23:58 -0600 Derek Foreman wrote: > On 05/02/16 08:50 AM, Derek Foreman wrote: > > On 05/02/16 07:25 AM, Pekka Paalanen wrote: > >> From: Pekka Paalanen > >> > >> Since shm_pool_resize() uses mremap(MREMAP_MAYMOVE),

Re: [PATCH weston v3] drm: port the drm backend to the new init api

Le 09/02/2016 11:38, Pekka Paalanen a écrit : On Tue, 9 Feb 2016 01:11:48 +0100 Benoit Gschwind wrote: Hello, while I developing the option 2. I raise few questions because this option explicit the fact that back-ends does not share the same API (at less for the

[RFC wayland 15/18] connection: support sending the contents of fds as bulk data

For network transparent operation we need to send fd contents over the wire for some fds (for example, keymaps). This adds functions to copy fd data into the network pipe without feeding it through the 4k ring buffer by writing it directly into the socket (after flushing ring buffer contents

[RFC wayland 10/18] scanner: Add the concept of "pre hooks"

A pre hook is a wayland library call made on the client side before the request is sent. Until now the wayland library has simply passed requests on without any knowledge of what they mean, and the receiving compositor has all the logic. For network transparency to be truly transparent, the

[RFC wayland 07/18] protocol: Add fd_static type

Some file descriptors, such as the ones for keymaps, are filled before they're sent and expected to be used with mmap(). Add a new fd_static type to make this more clear. This is preparation for being able to handle this data over a network. Signed-off-by: Derek Foreman

[RFC wayland 11/18] os: Add wl_os_read() and wl_os_write()

These handle EINTR and make sure the amount requested is read into the buffer. Signed-off-by: Derek Foreman --- src/wayland-os.c | 38 ++ src/wayland-os.h | 6 ++ 2 files changed, 44 insertions(+) diff --git a/src/wayland-os.c

[RFC wayland 12/18] os: Add a wl_os_socket_reuseaddr

When we have tcp/ip listening sockets we want them to be reusable so we don't get stuck with a timeout when restarting the compositor. Signed-off-by: Derek Foreman --- src/wayland-os.c | 8 src/wayland-os.h | 3 +++ 2 files changed, 11 insertions(+) diff --git

[RFC wayland 09/18] os: Add wl_os_resize_file()

We have a couple of callers of ftruncate and posix_fallocate around, with ifdef protecting the posix_fallocate calls. Combine all this into a single wl_os_resize_file(). Signed-off-by: Derek Foreman --- cursor/wayland-cursor.c | 10 +- src/wayland-os.c|

[RFC wayland 14/18] shm: properly resize remote buffers

When shm buffers are remote the server library will create empty fds for them. We need to handle resizing of that for both pool creation and resize (in a local connection this is done by the client app) Signed-off-by: Derek Foreman --- src/wayland-shm.c | 7 +++ 1

[RFC wayland 00/18] Wayland network transparency :)

I saw a presentation once where someone said that even the simplest implementation of wayland network transparency that just pushed the existing protocol over tcp/ip would still be better than X. Let's test that theory. Hint - application startup time is shockingly fast due to wayland's excellent

[RFC wayland 17/18] protocol: Add a wl_buffer.transmit

This is for sending buffer contents over the network to a compositor. A rectangle of data is sent in a terribly inefficient way. Signed-off-by: Derek Foreman --- protocol/wayland.xml | 18 +- src/wayland-shm.c| 40

[RFC wayland 18/18] protocol: Add hooks for network transparency

Add hooks to all the wl_buffer protocol and code to track damage in the client side library for uploading data that needs to pass over the network. Signed-off-by: Derek Foreman --- Makefile.am | 1 + protocol/wayland.xml | 20 ++-- src/network-client.c | 269

[RFC wayland 16/18] connection: Use bulk transfers for fd_static on remote connections

This copies the contents of keymaps over the network for remote connections. Any future user of fd_static should Just Work too. Signed-off-by: Derek Foreman --- src/connection.c | 60 ++- src/wayland-private.h | 2 ++

[RFC wayland 13/18] connections: Add remote sockets

This allows adding a tcp/ip socket and adds tracking of the remote status for clients and proxies Signed-off-by: Derek Foreman --- src/connection.c | 11 +++- src/wayland-client.c | 103 +--- src/wayland-private.h | 5 ++

[RFC wayland 03/18] os: make set_cloexec_or_close private instead of static

the cursor stuff has a copy of this, so let's share it. Signed-off-by: Derek Foreman --- src/wayland-os.c | 14 +++--- src/wayland-os.h | 3 +++ 2 files changed, 10 insertions(+), 7 deletions(-) diff --git a/src/wayland-os.c b/src/wayland-os.c index

[RFC wayland 04/18] cursor: use wl_os_set_cloexec_or_close instead of local copy

Signed-off-by: Derek Foreman --- cursor/os-compatibility.c | 26 +- 1 file changed, 1 insertion(+), 25 deletions(-) diff --git a/cursor/os-compatibility.c b/cursor/os-compatibility.c index 9791f97..6883a1d 100644 --- a/cursor/os-compatibility.c

[RFC wayland 08/18] protocol: Use new fd_static type for keymaps

Signed-off-by: Derek Foreman --- protocol/wayland.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 8739cd3..8713f43 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -2101,7 +2101,7 @@

[RFC wayland 05/18] os-compatability: Remove cursor's private os compat stuff entirely

Put the libcursor os-compatibility stuff in wayland-os.c instead. Signed-off-by: Derek Foreman --- Makefile.am | 4 +- cursor/os-compatibility.c | 127 -- cursor/os-compatibility.h | 34 -

[RFC wayland 02/18] os-compatability: Allow creation of 0 byte anonymous files

posix_fallocate will fail if passed a 0 size, but we don't actually need to call it if we have a 0 size, so return early. Signed-off-by: Derek Foreman --- cursor/os-compatibility.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/cursor/os-compatibility.c

[RFC wayland 01/18] shm: add getters for the fd and offset

From: Giulio Camuffo This allows to share the buffer data by mmapping the fd again. Reviewed-by: David FORT Signed-off-by: Derek Foreman --- src/wayland-server-core.h | 6 ++ src/wayland-shm.c |

[RFC wayland 06/18] client: Check remaining connection buffer status after each queue_event()

Currently we (correctly) assume that event_queue() consumes exactly the amount of connection data as the size returned. In a follow up patch I change that to allow bulk transfer of fd contents which may deplete the connection buffer (and read even more directly). In preparation for that, start

Re: [PATCH v3 weston] compositor-drm: update internal cursor plane location when disabling cursor

On Sat, Feb 06, 2016 at 11:24:34AM +0200, Pekka Paalanen wrote: > On Fri, 5 Feb 2016 15:55:20 -0600 > Derek Foreman wrote: > > > When the cursor plane is disabled the kernel can lose its location. > > If we don't update our internal idea of where the plane is at that

[PATCH wayland 2/2] shm: Defer wl_shm_pool_resize if a pool has external references

If a compositor is rendering in one thread while dispatching wayland events in another, a wl_shm_pool_resize() could change the memory mappings it's rendering from and cause a crash. Now we defer wl_shm_pool_resize() if the compositor has references on a pool, and perform the actual resize when

[PATCH wayland 1/2] shm: Split pool reference counting into external and internal references

This is a preliminary step towards deferring shm resize operations until after the compositor has released all external references on a pool. Signed-off-by: Derek Foreman --- src/wayland-shm.c | 31 +++ 1 file changed, 19 insertions(+), 12

Re: [PATCH weston 2/2] compositor-drm: the cursor plane only supports ARGB

On Fri, Feb 05, 2016 at 02:30:22PM +0200, Pekka Paalanen wrote: > On Thu, 3 Dec 2015 14:07:12 -0600 > Derek Foreman wrote: > > > Keep XRGB apps out of the cursor plane, only ARGB is supported. > > > > This prevents programs like weston-simple-shm from landing in the

Re: [PATCH libinput 1/2] udev: fix ALPS firmware detection

On Tue, Feb 09, 2016 at 11:49:33AM +0100, Emilio Pozuelo Monfort wrote: > On 09/02/16 03:12, Peter Hutterer wrote: > > The firmware version is in id.version, not id.model which is always > > PSMOUSE_ALPS for ALPS devices. > > > > The various fw versions are listed in /drivers/input/mouse/alps.h

[ANNOUNCE] wayland 1.9.93

This is the release candidate for the upcoming 1.10 release. Changes since the beta are just a few cosmetic fixups. As mentioned in the alpha release note, the upcoming 1.10 is a big release with a bunch of new functionality. Drag and drop actions are now added to the Wayland API, to

[ANNOUNCE] weston 1.9.93

Here's the release candidate for the upcoming 1.10 release. Changes included here versus the beta are several refinements and bugfixes. This release adds support into Weston for a number of recently added Wayland protocols. This includes the new drag and drop actions, new frame and axis

Re: [PATCH weston] compositor-x11: send pointer frame after axis event

On Mon, Feb 08, 2016 at 09:42:23AM +1000, Peter Hutterer wrote: > On Wed, Feb 03, 2016 at 02:03:00PM +0100, Marek Chalupa wrote: > > clients that implement pointer interface of version 5 > > wait for the frame event, so without it the scrolling > > does not work (GTK+ clients do not scroll now for

Re: [PATCH wayland] shm: add a note about shm pool base address changing

On 09/02/16 05:56 AM, Pekka Paalanen wrote: > On Mon, 08 Feb 2016 12:23:58 -0600 > Derek Foreman wrote: > >> On 05/02/16 08:50 AM, Derek Foreman wrote: >>> On 05/02/16 07:25 AM, Pekka Paalanen wrote: From: Pekka Paalanen

[PATCH libinput] tablet: sanitize button mask passing

We have a struct, use it. Better than passing arrays and array lengths around. Signed-off-by: Peter Hutterer --- src/evdev-tablet.c | 54 +- src/evdev-tablet.h | 2 +- 2 files changed, 22 insertions(+), 34

[ANNOUNCE] libinput 1.1.7

libinput 1.1.7 is now available. This release fixes an issue introduced by 1.1.6's new disable-while-typing handling. If dwt was disabled while a key was held down, the touchpad remained disabled due to a recurring timer. This is fixed now. The other change enables the touchpad motion hysteresis

Re: [RFC wayland 00/18] Wayland network transparency :)

https://cgit.freedesktop.org/~krh/weston/?h=remote :) On Tue, Feb 9, 2016 at 5:57 PM, Jason Ekstrand wrote: > On Tue, Feb 9, 2016 at 8:55 AM, Derek Foreman > wrote: >> >> I saw a presentation once where someone said that even the simplest >>

Re: Using Soft Keys with Weston & Libinput

In the attached picture, is there also a strip above the screen that is part of the touch screen? I would expect the touchpad hardware to be rectangular. There is also a faint image of a rectangle in the middle, is this something that lights up depending on the application?

Re: Using Soft Keys with Weston & Libinput

I'm just surprised that either the touch area is not a rectangle, or that you were able to cut a hole for the card reader through the rectangular touch panel. Then again I don't really know anything about the manufacturing of these. On Tue, Feb 9, 2016 at 12:02 AM, Ucan, Emre (ADITG/SW1) <

Re: [RFC wayland 00/18] Wayland network transparency :)

On Tue, Feb 9, 2016 at 8:55 AM, Derek Foreman wrote: > I saw a presentation once where someone said that even the simplest > implementation of wayland network transparency that just pushed the > existing protocol over tcp/ip would still be better than X. > > Let's test

Re: [RFC wayland 00/18] Wayland network transparency :)

My first reaction was that this is the wrong way to do it, but looking at it a bit I am thinking it really is correct. This avoids the need for a "proxy compositor" running on the client machine that does the remote communication. That may be a big selling point since that compositor is a whole

Re: [PATCH v4 wayland-protocols] text: Create second version of text input protocol

On Mon, Feb 8, 2016 at 7:38 AM, Rui Tiago Cação Matos wrote: > > > + > > + > > + Sets the cursor outline as a rectangle relative to the surface. > > + > > + Allows the compositor to put a window with word suggestions near > the > > + cursor. > >

Re: [PATCH v4 wayland-protocols] text: Create second version of text input protocol

Yes that is exactly what I expect. The input method may, if it wants, clamp the region to the surface, or even to the input area of the surface. It does not have to put it disconnected from the visible area like you are showing, though it can if it wants. On Mon, Feb 8, 2016 at 10:42 AM, Rui

[PATCH libinput 4/6] test: tablet pad tests

Signed-off-by: Peter Hutterer --- test/Makefile.am | 7 + test/litest-device-wacom-intuos3-pad.c | 107 + test/litest-device-wacom-intuos5-pad.c | 112 ++ test/litest-int.h | 16 ++ test/litest.c

[PATCH libinput 1/6] Add the LIBINPUT_DEVICE_CAP_TABLET_PAD capability and matching interface

This interface handles the buttons on the physical tablet itself, including the touch ring and the strip. Signed-off-by: Peter Hutterer --- doc/tablet-support.dox | 12 +- src/libinput-private.h | 18 +++ src/libinput.c | 276

[PATCH libinput 3/6] pad: implement wacom pad support

Signed-off-by: Peter Hutterer --- src/Makefile.am| 1 + src/evdev-tablet-pad.c | 536 + src/evdev-tablet-pad.h | 66 ++ src/evdev.c| 28 +-- src/evdev.h| 14 ++ src/libinput.c

[PATCH 0/6] Add a tablet pad interface

This patchset adds a new interface, the "tablet pad" interface for the physical tablet bit of Wacom tablets. The already-merged tablet interface only covers the tools, not the buttons and rings/strips on the tablet. Originally this was intended to become the buttonset interface as a generic

[PATCH libinput 2/6] doc: add a graphic illustrating pad vs tool support

Signed-off-by: Peter Hutterer --- doc/svg/tablet-interfaces.svg | 325 ++ doc/tablet-support.dox| 2 + 2 files changed, 327 insertions(+) create mode 100644 doc/svg/tablet-interfaces.svg diff --git

[PATCH libinput 6/6] pad: add support for left-handed configurations

Signed-off-by: Peter Hutterer --- src/evdev-tablet-pad.c | 55 ++- test/pad.c | 115 + 2 files changed, 168 insertions(+), 2 deletions(-) diff --git a/src/evdev-tablet-pad.c

[PATCH libinput 5/6] tablet: move the libwacom check for left-handed-ness into a helper function

Signed-off-by: Peter Hutterer --- src/evdev-tablet.c | 38 +- src/evdev.c| 52 src/evdev.h| 3 +++ 3 files changed, 56 insertions(+), 37 deletions(-) diff --git

Re: [RFC wayland 10/18] scanner: Add the concept of "pre hooks"

On Tue, 09 Feb 2016 10:55:57 -0600 Derek Foreman wrote: > A pre hook is a wayland library call made on the client side before the > request is sent. > > Until now the wayland library has simply passed requests on without any > knowledge of what they mean, and the