Re: [RFC wayland-protocols] Add the color-management protocol

Carsten Haitzler (The Rasterman) wrote: > what if the display can do different color profiles for different regions? my > example is yuv colorspace. 601 vs 709 etc. actually can be assigned per hw > plane... they are different colorspaces ... :) It isn't a different color space though, just a

Re: [RFC wayland-protocols] Color management protocol

Jason Gerecke wrote: > On Mon, Dec 19, 2016 at 7:04 AM, James Feeney wrote: >> What is the design outline of that Wayland-protocol-free CMS? > > I can certainly see where you're coming from, as I too had similar > thoughts when getting my feet wet with with protocol design

Re: [RFC wayland-protocols] Color management protocol

Pekka Paalanen wrote: > could you keep the CC list intact, please. Sorry - no. I don't like getting spammed with multiple copies of the same email, so I don't do it to other people. >> Since Wayland doesn't currently implement any color management support, >> I'm not following how it can be a

Re: [PATCH wayland v2] doc: start documenting Xwayland

On Mon, Dec 05, 2016 at 03:52:19PM +0200, Pekka Paalanen wrote: > 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,

[PATCH] gestures: if fingers don't move, force a gesture by finger position

If the fingers rest on the touchpad without moving for a timeout, switch to pinch or swipe based on the finger position. We already did so for two-fingers switching to scrolling, now we also do so for 3 and 4 finger gestures. This gives us better reaction to small movements. Signed-off-by: Peter

Re: [PATCH v2 2/2] xdg-shell: Fold several client-side decoration requests into a generic request

On Mon, Dec 19, 2016 at 12:55:24PM -0500, Adam Goode wrote: > Compositors currently receive "move", "resize", and "show_window_menu" > requests from clients whose decorations have been interacted with. > Clients currently implement key- and mouse-binding policies to > determine which one of these

Re: [PATCH] xdg-shell: require popups to intersect with or be adjacent to parent surfaces

On Mon, Dec 19, 2016 at 11:56:38AM -0500, Mike Blumenkrantz wrote: > some restrictions must be placed on this or else it becomes legal for > the compositor to place popups in unexpected locations > > Signed-off-by: Mike Blumenkrantz Could be further specified further that

[PATCH libinput 4/4] touchpad: if an external touchpad and keyboard share a VID/PID assume dwt

This requires to expand the blacklisting to be a bit more specific so we don't initialize dwt config on devices that won't need it. https://bugs.freedesktop.org/show_bug.cgi?id=99140 Signed-off-by: Peter Hutterer --- src/evdev-mt-touchpad.c | 13 +-

[PATCH libinput 3/4] test: use the udev property to check for external/internal touchpads

Signed-off-by: Peter Hutterer --- test/device.c | 20 ++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/test/device.c b/test/device.c index f44a988..af39508 100644 --- a/test/device.c +++ b/test/device.c @@ -61,6 +61,22 @@

[PATCH libinput 1/4] test: don't set LITEST_VERBOSE during make check

I've never had the log output help me identify a bug during a test run. Now that we run all tests in the same binary the verbosity just leads to a massive file that makes it hard to find the actual failure. Turn off LITEST_VERBOSE by default but leave the parsing in for cases where it may come in

[PATCH libinput 2/4] test: mark the magic trackpad as external in udev

This should be handled by a udev rule in systemd/hwdb but that rule doesn't apply to virtual devices. Signed-off-by: Peter Hutterer --- test/litest-device-magic-trackpad.c | 11 +++ 1 file changed, 11 insertions(+) diff --git

Re: [RFC wayland-protocols] Color management protocol

Niels Ole Salscheider wrote: > Yes, exactly. But these are things that do not use the "normal" wayland > protocols but are initiated by the compositor. I'm not sure what you mean by that. Why should the compositor launch applications ? The user should launch applications they want to use in the

Re: [RFC wayland-protocols] Add the color-management protocol

On Mon, 19 Dec 2016 10:07:31 +0100 Niels Ole Salscheider said: > On Monday, 19 December 2016, 11:08:31 CET, Carsten Haitzler wrote: > > On Sat, 19 Nov 2016 17:29:20 +0100 Niels Ole Salscheider > > > > said: > > > Signed-off-by:

Re: Remote display with 3D acceleration using Wayland/Weston

On 12/19/16 2:48 AM, Pekka Paalanen wrote: > Hmm, indeed, maybe it would be possible if you are imposing your own > EGL middle-man library between the application and the real EGL library. > > That's definitely a idea to look into. I cannot say off-hand why it > would not work, so maybe it can

Re: [RFC wayland-protocols] Color management protocol

On Mon, Dec 19, 2016 at 7:04 AM, James Feeney wrote: > On 12/19/2016 03:04 AM, Pekka Paalanen wrote: >> We very deliberately avoid defining any "standard" Wayland interfaces >> for configuring a compositor, because every compositor is different. >> With X11, you had the one

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

Hi, Version 2 of the original patch is here (wayland-protocols): https://patchwork.freedesktop.org/series/16642/ Weston implementation (in progress): https://patchwork.freedesktop.org/series/17007/ Comments welcome! Adam On Mon, Dec 12, 2016 at 9:11 AM, Adam Goode

[PATCH 0/2] weston: Update weston server and clients to xdg-shell v7

This is a work in progress, but is good progress along the idea of xdg-shell communicating low-level decoration interaction events to the compositor, rather than every client needing to interpret window manipulation actions and bindings. It moves logic from clients/window.c and shared/frame.c

[PATCH 2/2] clients: Update weston clients to use unstable xdg-shell v7

This removes some of the decoration binding logic from clients. The compositor implements decoration bindings in v7. Clients now tell the compositor when clicks or touches happen on decorations, and the compositor decides what to do. Previously, all clients had to implement bindings for move,

[PATCH 1/2] libweston-desktop: Update weston-desktop to use unstable xdg-shell v7

This updated protocol allows compositors to have a richer set of actions in response to user initiated events, but requires compositors to implement the bindings for what was previously move, resize, and show_window_menu. Signed-off-by: Adam Goode --- COPYING

[PATCH v2 1/2] xdg-shell: Introduce protocol v7

There are no changes in this from v6 to v7, that will come next. Signed-off-by: Adam Goode --- Makefile.am |1 + unstable/xdg-shell/xdg-shell-unstable-v7.xml | 1041 ++ 2 files changed, 1042 insertions(+) create

[PATCH v2 2/2] xdg-shell: Fold several client-side decoration requests into a generic request

Compositors currently receive "move", "resize", and "show_window_menu" requests from clients whose decorations have been interacted with. Clients currently implement key- and mouse-binding policies to determine which one of these requests to send to the compositor in response to user action.

[PATCH v2 0/2] xdg-shell: Proposal to be more generic for decorations

This is a slight change from v1. I updated Makefile.am and changed the value for "titlebar" to match the enum in weston. v1 description: There were many different opinions and suggestions for how to allow for raise and lower to be bound to mouse clicks in titlebars. This is one possible way

[PATCH] configure: search for lib with clock_getres()

Like clock_gettime(), clock_getres() is in -lrt for glibc < 2.17. Add a check for it, like is done for clock_gettime(). Fixes: http://autobuild.buildroot.net/results/bce/bcecdbbce4a99eb1e9bfbf519857bf94d8952037/ Signed-off-by: "Yann E. MORIN" --- Makefile.am | 1

Re: [PATCH weston] compositor-drm: Ignore non-KMS devices

Hi, On 19 December 2016 at 16:53, Daniel Stone wrote: > Given that we can have render-only devices, or vgem in a class of its > own, ignore any non-KMS devices in compositor-drm's device selection. > For x86 platforms, this is mostly a non-issue since we look at the udev >

[PATCH] xdg-shell: require popups to intersect with or be adjacent to parent surfaces

some restrictions must be placed on this or else it becomes legal for the compositor to place popups in unexpected locations Signed-off-by: Mike Blumenkrantz --- unstable/xdg-shell/xdg-shell-unstable-v6.xml | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-)

Re: [RFC wayland-protocols] Color management protocol

On 12/19/2016 03:04 AM, Pekka Paalanen wrote: > We very deliberately avoid defining any "standard" Wayland interfaces > for configuring a compositor, because every compositor is different. > With X11, you had the one single X server implementation and no other. > On Wayland, every compositor is an

Issue in playing YouTube/TV app on Weston

Hi I am having an embedded SoC on which Wayland weston and work are ported. When I try to play YouTube/TV app on the browser , only audio is coming no video on the TV. I am using fbdev backend. In my hardware I don't have support for DRM backend. Please suggest me what could be the issue for

Re: Remote display with 3D acceleration using Wayland/Weston

On Mon, 19 Dec 2016 10:50:22 +0100 Christian Stroetmann wrote: > On19.Dec.2016 09:48, Pekka Paalanen wrote: > > Sorry for not realizing the "wrap libEGL.so" approach earlier. > > Yeah, and how does this look like when put in context with Waltham? It has nothing to do

Re: [RFC wayland-protocols] Color management protocol

Hi, could you keep the CC list intact, please. On Mon, 19 Dec 2016 12:37:14 +1100 Graeme Gill wrote: > Pekka Paalanen wrote: > > On Wed, 14 Dec 2016 18:49:14 +1100 > > Graeme Gill wrote: > > >> Please read my earlier posts. No (sane) compositor

Re: Remote display with 3D acceleration using Wayland/Weston

On19.Dec.2016 09:48, Pekka Paalanen wrote: On Fri, 16 Dec 2016 11:35:48 -0600 DRC wrote: On 12/16/16 3:06 AM, Pekka Paalanen wrote: I should probably tell a little more, because what I explained above is a simplification due to using a single path for all

Re: Remote display with 3D acceleration using Wayland/Weston

On19.Dec.2016 09:48, Pekka Paalanen wrote: On Fri, 16 Dec 2016 11:35:48 -0600 DRC wrote: On 12/16/16 3:06 AM, Pekka Paalanen wrote: I should probably tell a little more, because what I explained above is a simplification due to using a single path for all

Re: [RFC wayland-protocols] Add the color-management protocol

On Monday, 19 December 2016, 11:08:31 CET, Carsten Haitzler wrote: > On Sat, 19 Nov 2016 17:29:20 +0100 Niels Ole Salscheider > > said: > > Signed-off-by: Niels Ole Salscheider > > --- > > > > Makefile.am

Re: Remote display with 3D acceleration using Wayland/Weston

On Fri, 16 Dec 2016 11:35:48 -0600 DRC wrote: > On 12/16/16 3:06 AM, Pekka Paalanen wrote: > > I should probably tell a little more, because what I explained above is > > a simplification due to using a single path for all buffer types. > > ... > > Thanks

Re: [RFC wayland-protocols] Color management protocol

On Monday, 19 December 2016, 13:08:13 CET, Graeme Gill wrote: > Niels Ole Salscheider wrote: > > I feel like the discussion drifts off a bit. You (Graeme) obviously know > > much more about color management than I do. But as Pekka already pointed > > out there are a few constraints that originate

Re: [RFC wayland-protocols] Color management protocol

On Mon, 19 Dec 2016 17:01:50 +1100 Graeme Gill said: at this point i'm going to summarize this. this might be more helpful than continuing point by point rebuttals as i sense that there's something missing in this conversation: summary of what i think should be the