Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Niels Ole Salscheider wrote:

> Maybe I should reword it then. The intention of allowing to query the 
> blending 
> space was to tell applications the preferred color space of a surface. That 
> is, if they do any color management they should create surfaces with that 
> color space to minimize computing time.

Sounds overly complex for a first cut.

> Anyway, this preferred space should probably not be sRGB if the compositor 
> cares about accurate colors. This is because there are many monitors that 
> have 
> wider gamuts and you would clip the colors at that point.

See my previous suggestion - use a linearised light output display space
for compositing - it's simple, fast, and there are no gamut issues.

Graeme Gill.

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

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Carsten Haitzler (The Rasterman) wrote:

> well graeme disagrees and effectively thinks it should be. :)

I said no such thing!

Graeme Gill.

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

Re: [RFC wayland-protocols] Color management protocol

[Graeme Gill]

Carsten Haitzler (The Rasterman) wrote:
> On Fri, 9 Dec 2016 15:30:40 +1100 Graeme Gill  said:

>> I thought I'd explained this in the previous post ? - perhaps
>> I'm simply not understanding where you are coming from on this.
> 
> you didn't explain before if the point is for this to be mandatory or 
> optional.

I'm not sure exactly what you mean by "this".

I've suggested two color management extensions, one building on
the other. By being an extension, I assume that neither one is
mandatory, although "core" would be a dependence of "enhanced".

> above you basically say it has to be mandatory as applications will then fail
> to run (at least some set of them might).

That's not at all what I said. I said that applications have the
option of falling back to more basic approaches :-
enhance back to core, core back to none.

> when you add extra features like new colorspace support, people writing apps
> and toolkits nee to know what the expectation is. can they just assume it will
> work, or do they need to have a fallback path on their side.

I've not mentioned any new colorspace support, so I'm not
sure what you are talking about.

> compositor writers need to know too. if color management is mandatory then
> their compositor is basically broken until they add it.

Naturally a compositor that supports an extension, would
would have to implement it!

> i don't see a difference between enhanced and core.

Hmm. They are quite distinct.

 core: The application either implements its own CMM (lcms or
  ArgyllCMS icclib/imdi etc.), or uses a system provided CMM
  (i.e. ColorSync, WCS, AdobeCMM etc.).

 enchanced: The compositor implements some level of CMM itself,
  using one of the above libraries, GPU etc.

 core: The application requires information from the graphics
  system (via Wayland in this particular discussion), namely
  the profile for the display corresponding to each
  pixel region.

 enhanced: The compositor is provided with source colorspace
  profiles by the application.

 core: The application uses its CMM to transform source colorspaces
  to the display colorspaces, and sends the pixels to the graphics system.

 enhanced: The compositor uses its CMM to transform the pixels provided
  by the application in the provided source colorspaces to the display
  colorspaces.

> color management means:
> 
> 1. being able to report what colorspace is "default" on the display right now
> (and what may be able to be enabled possible at request).

I'm not sure what you mean by "enabled". A display colorspaces is just 
information
that is needed by the CMM, so it is either known and available to what needs
it, or not known or not available to what needs it.

> 2. being able to report what colorspaces are supported at all (either natively
> by the display or by emulation)

Not needed for core color management - all that is required is
to be able to send pixels in the native display space to the display.

> 3. the ability for a client to define a specific colorspace for a buffer. (the
> choice of the colorspace of the display itself should be left to the
> compositor).

Not needed for core color management - the application deals
with source color spaces internally.

To reiterate:

1) Core color management support is essential because you can't assume that
  a CMM implemented in the compostor has all the capabilities that every
  application requires - particularly if it is a color critical application.

2) Core color management support is essential to allow color management 
applications
  such as color profilers work. Without color profilers, there are no accurate
  color profiles for your display, and color critical applications won't be 
viable.

If you want Wayland to be on parity with existing systems (MSWin, OS X, X11),
then you need core color management support.

> the only difference is the set of colorspaces wanted by client and by 
> supported
> by compositor. core and enhanced are arbitrary labels.

No. See above.

> what matters is a
> common colorspace. right now in wayland it's all sRGB so everyone agrees (i'm
> ignoring yuv etc. buffer formats. just talking RGB ones).

That's not how CMM's work. The common color space is the profile connection
space, which is based on CIE XYZ.

> so the questions are:
> 
>   * if all of these above are missing: what happens?
>   * if the list of colorspaces natively supported by the screen does not have 
> a
> common set of colorspaces the client wants: what happens?
>   * if the list of all colorspaces (native or emulated) by the compositor does
> not have a common set with the client: what happens?

Only questions for enhanced color management, and since this isn't
required by color critical applications, a relaxed level of support
is likely to be useful.

> what i want to know if how mandatory will this be, as most users will never
> have a scenario where their display can do more than "dumb" sRGB and any
> compositor claiming to 

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

On Mon, 12 Dec 2016 17:57:08 +1100 Graeme Gill  said:

> Niels Ole Salscheider wrote:
> > Am Donnerstag, 8. Dezember 2016, 13:33:20 CET schrieb Graeme Gill:
> 
> Hi,
> 
> >> I'm not quite sure what you mean. Generally an application will have
> >> specific reasons for wanting to do it's own color management - for
> >> instance, perhaps it is previewing a CMYKOGlclm file, and wants to
> >> treat out of gamut mapping and black point mapping in a particular way,
> >> etc. I don't think the Wayland compositor is going to be expected to handle
> >> CMYKOGlclm etc. input rasters, never mind all the requirements of
> >> specialist application color management!
> > 
> > This is of course something that the client application has to do. It would 
> > query the main output for its surface, do the conversions to that color
> > space and then attach the output color space to the surface.
> 
> Right. So a protocol for querying the profile of each output for its surface
> is a base requirement.

i totally disagree. the compositor should simply provide available colorspaces
(and generally only provide those that hardware can do). what screen they apply
to is unimportant.

if the colorspace is native to that display or possible, the compositor will do
NO CONVERSION of your pixel data and display directly (and instead convert sRGB
data into that colorspace). if your surface spans 2 screens the compositor may
convert some to the colorspace of a monitor if it does not support that
colorspace. choose the colorspace (as a client) that matches your data best.
compositor will do a "best effort".

this way client doesnt need to know about outputs, which outputs it spans etc.
and compositor will pick up the pieces. let me give some more complex examples:

compositor has a mirroring mode where it can mirror a window across multiple
screens. some screens can or cannot do color management. what do you do now?
compositor may display your window in a pager that is duplicated across
multiple screens and thus the content of that window should be rendered
correctly. what happens when the colorspace changes on the fly (you recalbrate
the screen or output driving hardware). you expect applications to directly
control this and have to respond to this and redraw content all the time?

this can be far simpler:

1. list of supported colorspaces (bonus points if flags say if its able to be
native or is emulated).
2. colorspace attached to buffer by client.

that's it.

> > The compositor now must not touch the parts of the surface on the main
> > output (where the color spaces match). But it could still try to convert
> > from the color space of the main output to that of a secondary screen if
> > the surface covers two screens with different color profiles.
> 
> Not as a base requirement. The application needs to be able to
> do it's own color management, which means color managing for
> every output the surface goes to. So the base requirement
> has no rendering requirement for a composer - it's just
> about signalling the required information to the client application.
> 
> > But then again most people that work with professional applications would
> > not make them cover multiple screens, I guess.
> 
> People using color managed applications expect color management to work as
> best it can across multiple screens.
> 
> > Therefore I'm not opposed to adding 
> > a flag that indicates that the application wants to disable color
> > corrections completely for that surface, independent of the output.
> 
> This is only something that becomes a question at the next
> level, where there is an expectation that the composer
> has some degree of color management capability.
> 
> >> Which is not to say that compositor color management doesn't have its
> >> place - it is ideal for applications that just want to use "RGB", and
> >> not deal with specific display behavior.
> > 
> > Very simple applications would just keep the attached sRGB color space and 
> > maybe place images on subsurfaces with the embedded color space from the
> > image attached.
> 
> That works only in the case that the composer supports the image colorspaces.
> This may well be the case for some applications (i.e. web browsers), but
> I imagine it may not be desirable to insist that all composers supporting
> a color management capability, support a full range of colorspaces (N - color
> in general).
> 
> > Applications that care a bit more about color correction (but do not have 
> > professional needs) could convert all their colors to the blending color
> > space of the compositor. I'd expect this blending color space to be linear
> > if the compositor cares about good colors.
> 
> It's not clear to me that any application that is interested in good
> color would trust it to blending operations.
> 
> I'd also imagine that there is a class of applications wishing to get the
> compositor to deal with gross display differences (Wide gamut vs.
> sRGB-like for 

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

On Mon, 12 Dec 2016 18:18:21 +1100 Graeme Gill  said:

> Niels Ole Salscheider wrote:
> > Am Donnerstag, 8. Dezember 2016, 15:51:12 CET schrieb Graeme Gill:
> 
> >> Looking through the current Wayland color-management protocol
> >> proposal, I think it is missing a really fundamental thing -
> >> managing the output device color calibration state and color
> >> profile. I guess the assumption is that this is being done
> >> by colord, but my understanding is that colord is specific
> >> to Gnome based systems, and certainly depends on DBus, which
> >> Wayland does not. [ Please correct me if I've got any of this wrong. ]
> 
> > It is (currently) up to the compositor to decide how to implement this. The 
> > compositor could come with its own settings for the output color profiles
> > or query some other program. This might be colord, but it could also be 
> > kolormanager, or something else.
> 
> 1) This doesn't address how this information is communicated
>to a Wayland application.
> 
> 2) Expecting color management applications to deal with
>configuring the compositor in a platform dependent
>way, is expecting far too much. I for one am not
>about to add multiple platform dependent back
>ends (multiple flavors of Linux, BSD's, Android,
>etc.) to my tools to do this, and no other major
>platform expects it (i.e. none of MSWindows, OS X
>or X11 based systems have this requirement.)
> 
> The correct approach to avoiding such issues is simply
> to make both aspects Wayland (extension) protocols, so
> that Wayland color management and color sensitive applications
> have the potential to work across all Wayland systems,
> rather than being at best balkanized, or at worst, not
> supported.

"not supported" == sRGB (gamma). render appropriately. most displays are not
capable of wide gammuts so you'll HAVE to handle this case no matter what.
either compositor will fake it and reduce your colors down to sRGB, or your
apps produce sRGB by default and have code paths for extended colorspace
support *IF* it exists AND different colorspaces are natively supported by the
display hardware.


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

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

Re: [PATCH v4 wayland] wayland-server: log an error for events with wrong client objects

[Bryce Harrington]

On Mon, Dec 12, 2016 at 12:46:30PM -0800, Yong Bakos wrote:
> Hi Derek,
> 
> > On Dec 12, 2016, at 12:39 PM, Derek Foreman  wrote:
> > 
> > Check that all the objects in an event belong to the same client as
> > the resource posting it.  This prevents a compositor from accidentally
> > mixing client objects and posting an event that causes a client to
> > abort with a cryptic message.
> > 
> > Instead the client will now be disconnected as it is when the compositor
> > tries to send a null for a non-nullable object, and a log message
> > will be printed by the compositor.
> > 
> > Signed-off-by: Derek Foreman 
> 
> Reviewed-by: Yong Bakos 

Looks like a good approach to flag the potential issue.  And agreed,
logging an error is probably friendlier than forcing users to terminate
their server.

Reviewed-by: Bryce Harrington 
 
> yong
> 
> 
> > ---
> > src/wayland-server.c | 38 ++
> > 1 file changed, 38 insertions(+)
> > 
> > This started life as an assert, became an abort, and now it's a log
> > and disconnect.  Log and disconnect is already how we manage nullable
> > violation on the compositor side, so I'm hoping it won't be too
> > controversial.
> > 
> > For EFL clients the disconnect is recoverable under some circumstances with
> > our session recovery protocol, but the current client-abort()s behaviour
> > is not.
> > 
> > Changes from v1:
> > uses get_next_arguemnts and arg_count_for_signature instead of a bespoke
> > implementation.
> > 
> > Changes from v2:
> > Tests new_id objects as well
> > logs and disconnects instead of assert()/abort()
> > superficial changes to the log text
> > 
> > Changes from v3:
> > Actually printing the interface name and message name make this
> > useful for debugging - instead of actually less informative
> > than it was with a client side error.
> > 
> > diff --git a/src/wayland-server.c b/src/wayland-server.c
> > index 9d7d9c1..023d427 100644
> > --- a/src/wayland-server.c
> > +++ b/src/wayland-server.c
> > @@ -160,6 +160,36 @@ log_closure(struct wl_resource *resource,
> > }
> > }
> > 
> > +static bool
> > +verify_objects(struct wl_resource *resource, uint32_t opcode,
> > + union wl_argument *args)
> > +{
> > +   struct wl_object *object = >object;
> > +   const char *signature = object->interface->events[opcode].signature;
> > +   struct argument_details arg;
> > +   struct wl_resource *res;
> > +   int count, i;
> > +
> > +   count = arg_count_for_signature(signature);
> > +   for (i = 0; i < count; i++) {
> > +   signature = get_next_argument(signature, );
> > +   switch (arg.type) {
> > +   case 'n':
> > +   case 'o':
> > +   res = (struct wl_resource *) (args[i].o);
> > +   if (res && res->client != resource->client) {
> > +   wl_log("compositor bug: The compositor "
> > +  "tried to use an object from one "
> > +  "client in a '%s.%s' for a different "
> > +  "client.\n", object->interface->name,
> > +  object->interface->events[opcode].name);
> > +   return false;
> > +   }
> > +   }
> > +   }
> > +   return true;
> > +}
> > +
> > WL_EXPORT void
> > wl_resource_post_event_array(struct wl_resource *resource, uint32_t opcode,
> >  union wl_argument *args)
> > @@ -167,6 +197,10 @@ wl_resource_post_event_array(struct wl_resource 
> > *resource, uint32_t opcode,
> > struct wl_closure *closure;
> > struct wl_object *object = >object;
> > 
> > +   if (!verify_objects(resource, opcode, args)) {
> > +   resource->client->error = 1;
> > +   return;
> > +   }
> > closure = wl_closure_marshal(object, opcode, args,
> >  >interface->events[opcode]);
> > 
> > @@ -206,6 +240,10 @@ wl_resource_queue_event_array(struct wl_resource 
> > *resource, uint32_t opcode,
> > struct wl_closure *closure;
> > struct wl_object *object = >object;
> > 
> > +   if (!verify_objects(resource, opcode, args)) {
> > +   resource->client->error = 1;
> > +   return;
> > +   }
> > closure = wl_closure_marshal(object, opcode, args,
> >  >interface->events[opcode]);
> > 
> > -- 
> > 2.11.0
> > 
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list

Re: [PATCH v4 wayland] wayland-server: log an error for events with wrong client objects

[Yong Bakos]

Hi Derek,

> On Dec 12, 2016, at 12:39 PM, Derek Foreman  wrote:
> 
> Check that all the objects in an event belong to the same client as
> the resource posting it.  This prevents a compositor from accidentally
> mixing client objects and posting an event that causes a client to
> abort with a cryptic message.
> 
> Instead the client will now be disconnected as it is when the compositor
> tries to send a null for a non-nullable object, and a log message
> will be printed by the compositor.
> 
> Signed-off-by: Derek Foreman 

Reviewed-by: Yong Bakos 

yong


> ---
> src/wayland-server.c | 38 ++
> 1 file changed, 38 insertions(+)
> 
> This started life as an assert, became an abort, and now it's a log
> and disconnect.  Log and disconnect is already how we manage nullable
> violation on the compositor side, so I'm hoping it won't be too
> controversial.
> 
> For EFL clients the disconnect is recoverable under some circumstances with
> our session recovery protocol, but the current client-abort()s behaviour
> is not.
> 
> Changes from v1:
> uses get_next_arguemnts and arg_count_for_signature instead of a bespoke
> implementation.
> 
> Changes from v2:
> Tests new_id objects as well
> logs and disconnects instead of assert()/abort()
> superficial changes to the log text
> 
> Changes from v3:
> Actually printing the interface name and message name make this
> useful for debugging - instead of actually less informative
> than it was with a client side error.
> 
> diff --git a/src/wayland-server.c b/src/wayland-server.c
> index 9d7d9c1..023d427 100644
> --- a/src/wayland-server.c
> +++ b/src/wayland-server.c
> @@ -160,6 +160,36 @@ log_closure(struct wl_resource *resource,
>   }
> }
> 
> +static bool
> +verify_objects(struct wl_resource *resource, uint32_t opcode,
> +   union wl_argument *args)
> +{
> + struct wl_object *object = >object;
> + const char *signature = object->interface->events[opcode].signature;
> + struct argument_details arg;
> + struct wl_resource *res;
> + int count, i;
> +
> + count = arg_count_for_signature(signature);
> + for (i = 0; i < count; i++) {
> + signature = get_next_argument(signature, );
> + switch (arg.type) {
> + case 'n':
> + case 'o':
> + res = (struct wl_resource *) (args[i].o);
> + if (res && res->client != resource->client) {
> + wl_log("compositor bug: The compositor "
> +"tried to use an object from one "
> +"client in a '%s.%s' for a different "
> +"client.\n", object->interface->name,
> +object->interface->events[opcode].name);
> + return false;
> + }
> + }
> + }
> + return true;
> +}
> +
> WL_EXPORT void
> wl_resource_post_event_array(struct wl_resource *resource, uint32_t opcode,
>union wl_argument *args)
> @@ -167,6 +197,10 @@ wl_resource_post_event_array(struct wl_resource 
> *resource, uint32_t opcode,
>   struct wl_closure *closure;
>   struct wl_object *object = >object;
> 
> + if (!verify_objects(resource, opcode, args)) {
> + resource->client->error = 1;
> + return;
> + }
>   closure = wl_closure_marshal(object, opcode, args,
>>interface->events[opcode]);
> 
> @@ -206,6 +240,10 @@ wl_resource_queue_event_array(struct wl_resource 
> *resource, uint32_t opcode,
>   struct wl_closure *closure;
>   struct wl_object *object = >object;
> 
> + if (!verify_objects(resource, opcode, args)) {
> + resource->client->error = 1;
> + return;
> + }
>   closure = wl_closure_marshal(object, opcode, args,
>>interface->events[opcode]);
> 
> -- 
> 2.11.0
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[PATCH v3 wayland] wayland-server: log an error for events with wrong client objects

[Derek Foreman]

Check that all the objects in an event belong to the same client as
the resource posting it.  This prevents a compositor from accidentally
mixing client objects and posting an event that causes a client to
abort with a cryptic message.

Instead the client will now be disconnected as it is when the compositor
tries to send a null for a non-nullable object, and a log message
will be printed by the compositor.

Signed-off-by: Derek Foreman 
---

This started life as an assert, became an abort, and now it's a log
and disconnect.  Log and disconnect is already how we manage nullable
violation on the compositor side, so I'm hoping it won't be too
controversial.

For EFL clients the disconnect is recoverable under some circumstances with
our session recovery protocol, but the current client-abort()s behaviour
is not.

Changes from v1:
uses get_next_arguemnts and arg_count_for_signature instead of a bespoke
implementation.

Changes from v2:
Tests new_id objects as well
logs and disconnects instead of assert()/abort()
superficial changes to the log text



 src/wayland-server.c | 37 +
 1 file changed, 37 insertions(+)

diff --git a/src/wayland-server.c b/src/wayland-server.c
index 9d7d9c1..d9c7750 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -160,6 +160,35 @@ log_closure(struct wl_resource *resource,
}
 }
 
+static bool
+verify_objects(struct wl_resource *resource, uint32_t opcode,
+ union wl_argument *args)
+{
+   struct wl_object *object = >object;
+   const char *signature = object->interface->events[opcode].signature;
+   struct argument_details arg;
+   struct wl_resource *res;
+   int count, i;
+
+   count = arg_count_for_signature(signature);
+   for (i = 0; i < count; i++) {
+   signature = get_next_argument(signature, );
+   switch (arg.type) {
+   case 'n':
+   case 'o':
+   res = (struct wl_resource *) (args[i].o);
+   if (res && res->client != resource->client) {
+   wl_log("compositor bug: The compositor "
+  "tried to use an object from one "
+  "client in an event for a different "
+  "client.\n");
+   return false;
+   }
+   }
+   }
+   return true;
+}
+
 WL_EXPORT void
 wl_resource_post_event_array(struct wl_resource *resource, uint32_t opcode,
 union wl_argument *args)
@@ -167,6 +196,10 @@ wl_resource_post_event_array(struct wl_resource *resource, 
uint32_t opcode,
struct wl_closure *closure;
struct wl_object *object = >object;
 
+   if (!verify_objects(resource, opcode, args)) {
+   resource->client->error = 1;
+   return;
+   }
closure = wl_closure_marshal(object, opcode, args,
 >interface->events[opcode]);
 
@@ -206,6 +239,10 @@ wl_resource_queue_event_array(struct wl_resource 
*resource, uint32_t opcode,
struct wl_closure *closure;
struct wl_object *object = >object;
 
+   if (!verify_objects(resource, opcode, args)) {
+   resource->client->error = 1;
+   return;
+   }
closure = wl_closure_marshal(object, opcode, args,
 >interface->events[opcode]);
 
-- 
2.11.0

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

Problem With libwayland-cursor.so

[Ali]

Dear Wayland,

After I’ve read “Building Weston” doc I cross compiled the wayland and then I 
tried to run Weston by :
start-weston 

It complained:

[00:01:00.878] weston 1.0.3
   http://wayland.freedesktop.org/
   Bug reports to: 
https://bugs.freedesktop.org/enter_bug.cgi?product=weston
   Build:  
[00:01:00.878] OS: Linux, 3.0.35, #3 SMP PREEMPT Tue Nov 15 09:36:14 MST 2016, 
armv7l
[00:01:00.883] Loading module '/usr/lib/weston/gal2d-backend.so'
[00:01:01.031] input device unknown, /dev/input/mice ignored: unsupported 
device type
[00:01:01.191] Loading module '/usr/lib/weston/desktop-shell.so'
[00:01:01.199] libwayland: using socket /tmp_weston/wayland-0
[00:01:01.200] launching '/usr/libexec/weston-desktop-shell'
/usr/libexec/weston-desktop-shell: symbol lookup error: 
/usr/lib/libwayland-cursor.so.0: undefined symbol: wl_proxy_marshal_constructor
[00:01:01.338] libwayland: disconnect from client 0x360a0
[00:01:01.338] weston-desktop-shell died, respawning...
[00:01:01.338] launching '/usr/libexec/weston-desktop-shell'
/usr/libexec/weston-desktop-shell: symbol lookup error: 
/usr/lib/libwayland-cursor.so.0: undefined symbol: wl_proxy_marshal_constructor
[00:01:01.367] libwayland: disconnect from client 0x360a0
[00:01:01.367] weston-desktop-shell died, respawning...
[00:01:01.367] launching '/usr/libexec/weston-desktop-shell'
/usr/libexec/weston-desktop-shell: symbol lookup error: 
/usr/lib/libwayland-cursor.so.0: undefined symbol: wl_proxy_marshal_constructor
[00:01:01.396] libwayland: disconnect from client 0x3a1c0
[00:01:01.396] weston-desktop-shell died, respawning...
[00:01:01.396] launching '/usr/libexec/weston-desktop-shell'
/usr/libexec/weston-desktop-shell: symbol lookup error: 
/usr/lib/libwayland-cursor.so.0: undefined symbol: wl_proxy_marshal_constructor
[00:01:01.425] libwayland: disconnect from client 0x3a100
[00:01:01.425] weston-desktop-shell died, respawning...
[00:01:01.425] launching '/usr/libexec/weston-desktop-shell'
/usr/libexec/weston-desktop-shell: symbol lookup error: 
/usr/lib/libwayland-cursor.so.0: undefined symbol: wl_proxy_marshal_constructor
[00:01:01.453] libwayland: disconnect from client 0x3a100
[00:01:01.454] weston-desktop-shell died, respawning...
[00:01:01.454] launching '/usr/libexec/weston-desktop-shell'
/usr/libexec/weston-desktop-shell: symbol lookup error: 
/usr/lib/libwayland-cursor.so.0: undefined symbol: wl_proxy_marshal_constructor
[00:01:01.482] libwayland: disconnect from client 0x3a100
[00:01:01.482] weston-desktop-shell died, giving up.

What should I do?


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

Re: [PATCH libinput 1/2] touchpad: reduce the initial timeout for tapping after touch

[Hans de Goede]

Hi,

On 12-12-16 06:53, Peter Hutterer wrote:

This is the timeout before we decide "this is just a finger down, not a tap".
Until this timeout is hit a finger's movement is filtered. To allow for a more
responsive touchpad, we want that timeout as short as possible.

Event analysis from several users showed that 95% of the touches are less than
100ms long. Reducing the threshold should have almost no impact on most
tapping users but improves the reaction time of the pointer for normal
movements.

For a more details see:
http://who-t.blogspot.com/2016/12/libinput-touchpad-tap-analysis.html

Signed-off-by: Peter Hutterer 


Series looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans




---
 src/evdev-mt-touchpad-tap.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/evdev-mt-touchpad-tap.c b/src/evdev-mt-touchpad-tap.c
index cb4abf2..b65bac4 100644
--- a/src/evdev-mt-touchpad-tap.c
+++ b/src/evdev-mt-touchpad-tap.c
@@ -33,6 +33,7 @@

 #include "evdev-mt-touchpad.h"

+#define DEFAULT_TAP_INITIAL_TIMEOUT_PERIOD ms2us(100)
 #define DEFAULT_TAP_TIMEOUT_PERIOD ms2us(180)
 #define DEFAULT_DRAG_TIMEOUT_PERIOD ms2us(300)
 #define DEFAULT_TAP_MOVE_THRESHOLD TP_MM_TO_DPI_NORMALIZED(3)
@@ -127,6 +128,13 @@ tp_tap_notify(struct tp_dispatch *tp,
 }

 static void
+tp_tap_set_initial_timer(struct tp_dispatch *tp, uint64_t time)
+{
+   libinput_timer_set(>tap.timer,
+  time + DEFAULT_TAP_INITIAL_TIMEOUT_PERIOD);
+}
+
+static void
 tp_tap_set_timer(struct tp_dispatch *tp, uint64_t time)
 {
libinput_timer_set(>tap.timer, time + DEFAULT_TAP_TIMEOUT_PERIOD);
@@ -155,7 +163,7 @@ tp_tap_idle_handle_event(struct tp_dispatch *tp,
case TAP_EVENT_TOUCH:
tp->tap.state = TAP_STATE_TOUCH;
tp->tap.first_press_time = time;
-   tp_tap_set_timer(tp, time);
+   tp_tap_set_initial_timer(tp, time);
break;
case TAP_EVENT_RELEASE:
break;


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