Re: [RFC wayland-protocols] Color management protocol

Carsten Haitzler (The Rasterman) wrote: > On Sat, 17 Dec 2016 21:16:41 +1100 Graeme Gill said: >> That's not a typical situation though, but nothing special would be >> happening - a new profile may be installed by the user as well, >> in which case an application should re-render to accommodate

[PATCH libinput 13/13] filter: tweak the magic slowdown

Could be confirmation bias, but it feels better. Signed-off-by: Peter Hutterer --- src/filter.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/filter.c b/src/filter.c index ab503cf..d7a1515 100644 --- a/src/filter.c +++ b/src/filter.c @@ -40,7 +40,7 @@ * technically co

[PATCH libinput 11/13] filter: revamp the touchpad's acceleration code

The previous code had three main issues: * acceleration kicked in too early, so even slow movements were accelerated * acceleration kicked in too quickly, there was only a very narrow window where we would have less than the max acceleration factor * the max accel factor was too low for fast move

[PATCH libinput 10/13] tools: switch the ptraccel-debug printf to use mm/s

Signed-off-by: Peter Hutterer --- tools/ptraccel-debug.c | 28 1 file changed, 20 insertions(+), 8 deletions(-) diff --git a/tools/ptraccel-debug.c b/tools/ptraccel-debug.c index 4ecb7e8..4fcb45f 100644 --- a/tools/ptraccel-debug.c +++ b/tools/ptraccel-debug.c @@ -14

[PATCH libinput 02/13] filter: drop the dpi_factor in favor of direct calculation

This was badly since the factor was the ratio of "dpi:default dpi" Most devices don't need it, so storing it in all filters event though we only use it for some devices is confusing. Now that we have the dpi stored directlyconfusing. Now that we have the dpi stored directly we might as well use th

[PATCH libinput 06/13] filter: change the filter functions to take raw device coordinates

We used to normalize all deltas to equivalents of a 1000dpi mouse before passing it into the acceleration functions. This has a bunch of drawbacks, not least that we already have to un-normalize back into device units for a few devices already (trackpoints, tablet, low-dpi mice). Switch the filter

[PATCH libinput 09/13] filter: work the touchpad magic slowdown into the various parameters

We have everything separate from the mouse now, so having a magic slowdown isn't needed, we can work this into our parameters. So the acceleration function now uses everything adjusted, but the factor is still multiplied by the slowdown in the end. Signed-off-by: Peter Hutterer --- src/filter.c

[PATCH libinput 07/13] filter: drop the now-generic trackpoint and low-dpi filter functions

The profile is what is still special about those two, the filter itself does the same as the default filter (calculate velocity, calculate accel factor, apply to delta). Signed-off-by: Peter Hutterer --- src/filter.c | 80 ++-- 1 file chang

[PATCH 00/13] Revamp touchpad acceleration code

This patchset is a cleanup and revamp of the touchpad acceleration code. It doesn't give us perfect acceleration, but it goes from the current rather abysimal state to one that should at least be good enough most of the time. More tweaking will come, but meanwhile santa and whatnot. Right now, we

[PATCH libinput 08/13] filter: change touchpad accel code to use mm/s

That's something human brains can map to because mapping a touchpad to equivalent units of a 1000dpi mouse requires a lot of mental acrobatics. And I'm getting older and my physio told me acrobatics is more something for the youngens, possibly those on my lawn listening to terrible music, etc. The

[PATCH libinput 04/13] touchpad: init the device's dpi correctly

This has no real effect just yet because we don't use a touchpad's dpi anywhere in the touchpad code. Only the acceleration code wants it but all touchpads use the same acceleration method, and that one doesn't care about the dpi. Signed-off-by: Peter Hutterer --- src/evdev-mt-touchpad.c | 4 +++

[PATCH libinput 01/13] filter: store the raw dpi value in the filter

Currently unused, will be used in the future. Signed-off-by: Peter Hutterer --- src/filter.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/filter.c b/src/filter.c index 4b15c30..eecf4ca 100644 --- a/src/filter.c +++ b/src/filter.c @@ -154,6 +154,7 @@ struct pointer_accelerator {

[PATCH libinput 03/13] filter: duplicate pointer accel for touchpads

This duplicates the code so we can change it for touchpads without affecting mice. Signed-off-by: Peter Hutterer --- src/filter.c | 103 --- 1 file changed, 98 insertions(+), 5 deletions(-) diff --git a/src/filter.c b/src/filter.c index 06

[PATCH libinput 05/13] Add device_float_get_direction

With some upcoming changes we need this function for device float coordinates as well. Signed-off-by: Peter Hutterer --- src/libinput-private.h | 37 ++--- 1 file changed, 26 insertions(+), 11 deletions(-) diff --git a/src/libinput-private.h b/src/libinput-privat

Re: [RFC wayland-protocols] Color management protocol

On Sat, 17 Dec 2016 21:16:41 +1100 Graeme Gill said: > Carsten Haitzler (The Rasterman) wrote: > > On Tue, 13 Dec 2016 17:46:25 +1100 Graeme Gill > > said: > > > a display may not have a single native colorspace. it may be able to > > switch. embedded devices can do this as the display pane

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

On Sat, 19 Nov 2016 17:29:20 +0100 Niels Ole Salscheider said: > Signed-off-by: Niels Ole Salscheider > --- > Makefile.am| 1 + > unstable/color-management/README | 4 + > .../color-management-unstable-v1.xml | 136

Re: [RFC wayland-protocols] Color management protocol

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 in the design decisions of wayland and > are quite different to thes

Re: [RFC wayland-protocols] Color management protocol

Pekka Paalanen wrote: > On Wed, 14 Dec 2016 18:49:14 +1100 > Graeme Gill wrote: >> Please read my earlier posts. No (sane) compositor can implement CMM >> capabilities to a color critical applications requirements, >> so color management without any participation of a compositor >> is a core requ

Re: [RFC wayland-protocols] Color management protocol

On Sun, 18 Dec 2016 16:25:13 +0100 Niels Ole Salscheider said: > 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 in the design decisions of waylan

Re: [RFC wayland-protocols] Color management protocol

> as Pekka already pointed out there > are a few constraints that originate in the design decisions of wayland and > are quite different to [those] of X11. We can't change these constraints but > have to find a solution that works well with them: ... I'm more of a bystander to this discussion.

Re: [RFC wayland-protocols] Color management protocol

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 in the design decisions of wayland and are quite different to these of X11. We can't change these const

[PATCH weston v2 0/5] libweston common modules preparation

From: Quentin Glidic Here is the second take at my common modules series, or rather at the preparation work. The real feature will come in a second series, with README update, and a complete design explanation. This series is merely a split and reordering of the first two patches frome the ol

[PATCH weston v2 1/5] libweston: Properly namespace backends entrypoint

From: Quentin Glidic This prevents loading a backend as a simple module. This will avoid messing up with backends when we will introduce libweston common modules. Signed-off-by: Quentin Glidic --- libweston/compositor-drm.c | 4 ++-- libweston/compositor-fbdev.c| 4 ++-- libweston/com

[PATCH weston v2 5/5] weston: Add a specific option to load XWayland

From: Quentin Glidic Signed-off-by: Quentin Glidic --- compositor/main.c | 22 +- man/weston.ini.man | 7 +-- man/weston.man | 7 +-- tests/weston-tests-env | 7 --- weston.ini.in | 3 ++- 5 files changed, 33 insertions(+), 13 deleti

[PATCH weston v2 4/5] weston: Make the shell entrypoint specific

From: Quentin Glidic This avoids loading a shell as a module, so we are sure to have only one shell loaded at a time. Signed-off-by: Quentin Glidic --- compositor/main.c | 17 - compositor/weston.h | 3 +++ desktop-shell/shell.c

[PATCH weston v2 3/5] weston: Properly namespace modules entrypoint

From: Quentin Glidic Signed-off-by: Quentin Glidic --- compositor/cms-colord.c | 4 ++-- compositor/cms-static.c | 4 ++-- compositor/main.c | 27 +++ compositor/screen-share.c | 4 ++-- compositor/systemd-notify.c

[PATCH weston v2 2/5] libweston: Properly namespace modules entrypoint

From: Quentin Glidic Use different functions so we cannot load a libweston common module in weston directly or the other way around. Signed-off-by: Quentin Glidic --- compositor/cms-colord.c | 1 + compositor/systemd-notify.c | 1 + compositor/weston.h | 4 +