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 co
Carsten Haitzler (The Rasterman) wrote:
> wouldn't it be best not to explicitly ask for an output colorspace and just
> provide the colorspace of your buffer and let the compositor decide? e.g. if
> your window is on top, or it's the largest one, or it's focused,then the
> compositor MAY switch th
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/listinf
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
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 m
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 -
> >> m
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 clien
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 cryp
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
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
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
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 u
12 matches
Mail list logo
