Re: Screen dimensions, top level surface positioning...

[Pekka Paalanen]

On Wed, 22 Nov 2017 10:07:47 +0800
Jonas Ådahl  wrote:

> On Wed, Nov 22, 2017 at 03:43:43AM +0200, Jari Vuomajoki wrote:
> > Hi Jasper,
> > 
> > Thank you very much for your very clear and comprehensible answer. I
> > understand the challenges you are addressing.
> > 
> > I want to build applications that can facilitate the screen layout to the
> > fullest and still collaborate with WM.
> > 
> > I don't really get the "fight" between WM and client. Maybe it is an
> > invitation for someone to build a really nice WM / compositor, satisfying
> > all needs.
> > 
> > However, stating it bluntly - Client side surface positioning relationship
> > to screen dimensions or multiple screen topology is a must.  
> 
> It is a must for a very specific subset of specalized clients that
> construct desktop environment components such as panels, launchers etc.
> For regular applications, complete control of positioning is generally
> only used to implement some functionality the compositor would be better
> at.
> 
> > 
> > I think it can be done without compromising the simplicity and clarity of
> > the protocol. Or is there something that I am not seeing?  
> 
> I don't know what type of client it is that you are trying to implement,
> but with the assumption made above, you'll have to look into extensions
> allowing you to achieve the outcome you are working towards.
> 
> However, you cannot rely on every desktop environment / compositor to
> support every use case that was possible on X11. This is to make it
> possible for highly integrated environments such to be implementable.
> 
> With that said, this does not stop any compositor to add protocols
> for "plug-n-play" kind of environments. One project which goal is to
> provide these types of protocols is wayland-wall:
> https://github.com/wayland-wall/wayland-wall
> 
> Now, you might be trying to implement something else, such as a splash
> screen or something. That is might something that hasn't had a protocol
> defined for it defined yet, but I would have to know what it is that you
> are doing to be able to comment on that.

Hi,

I agree with everything Jasper and Jonas have said, but I would like to
point out one more thing.

The discussion so far has been about desktops. We do not want to expose
a global coordinate system on desktops specifically, for all the reasons
said.

One detail why clients should not be able to position their floating
windows in absolute positions is that they cannot know what other
windows are on screen, therefore they cannot do positioning always
right. Also consider tiling window manager environments, VR
environments where the global space is actually 3D, not 2D, etc.
The HiDPI support where different outputs have different scaling
factors that the compositor automatically applies as necessary (a
feature that has been impossible on X11 so far) makes it harder to even
define a global coordinate system at the protocol level.

That is on desktops. Those are also reasons why the Wayland core
protocol does not have any kind of wl_surface positioning at all.

But, if what you are building is not a desktop, then the situation is
completely different. A custom non-desktop environment can and probably
should use a custom shell protocol extension that replaces the desktop
shell protocol extensions. Doing that, it can provide whatever you
want. The major drawback is that you need to add explicit protocol
support to all compositors and toolkits you want working with it.

An example of an alternate shell protocol implementation is Weston's
fullscreen-shell, which is tailored for a single exclusive application
controlling all outputs. You can achieve per-output absolute
positioning there by using sub-surfaces.


Thanks,
pq


pgpNkpU8Pwlb1.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v3 01/17] Add xdg-shell to stable/

[Jonas Ådahl]

On Wed, Nov 22, 2017 at 09:17:51AM +0200, Philipp Kerling wrote:
> Hi,
> 
> 2017-11-15 (水) の 19:19 +0800 に Jonas Ådahl さんは書きました:
> > Add a copy of xdg-shell unstable v6 to stable/xdg-shell/xdg-
> > shell.xml.
> > Folliwing this commit, it will go through a set of changes, before
> > being declared stable.
> I have a question here (before declaring it stable) that I hope was not
> addressed at some point already:
> On the one hand, the definitions of "set_fullscreen," "set_maximized,"
> "unset_fullscreen," and "unset_maximized" are worded such that the
> compositor is obliged to follow the client request and change the
> surface state, i.e. 1) the client can assume that the requested state
> transition takes place (if I'm not misreading it) and 2) a compositor
> that completely no-ops e.g. (un)set_fullscreen is technically in
> violation of the protocol. On the other hand, the definition of
> "set_minimized" is worded such that it is a request that might or might
> not be fulfilled.
> Is this intentional? What if a WM does not want to e.g. maximize a
> window for some reason? Or am I reading too much into it? :-)

It might be somewhat loosly worded, but the idea is that the compositor
is the one in control here. A compositor ignoring requests to
(un)maximize or (un)fullscreen etc are not technically in violation of
the protocol, as theoretically it can be implemented in a way that
allows the user or compositor to override any such request, or for
example even have a race condition where the user pressed "unmaximize"
then directly after a "maximize" keybinding.

It'll be visibly missbehaving if it ignores such requests, as pressing
the maximize button doesn't do anything, but with that said, a client
should not actually change the way it draws itself until it is
configured to do so via the configure event, so it is relatively
harmless.

To make it possible to not expose "maximize" functionality etc is
something that has been discussed (i.e. so that clients can adapt their
decorations to not include the maximize action), but it is not planned
to be part of the current proposed version.


Jonas

> 
> Best regards,
> Philipp
> 
> 
> > Signed-off-by: Jonas Ådahl 
> > ---
> >  stable/xdg-shell/README|5 +
> >  stable/xdg-shell/xdg-shell.xml | 1044
> > 
> >  2 files changed, 1049 insertions(+)
> >  create mode 100644 stable/xdg-shell/README
> >  create mode 100644 stable/xdg-shell/xdg-shell.xml
> > 
> > diff --git a/stable/xdg-shell/README b/stable/xdg-shell/README
> > new file mode 100644
> > index 000..2769abb
> > --- /dev/null
> > +++ b/stable/xdg-shell/README
> > @@ -0,0 +1,5 @@
> > +xdg shell protocol
> > +
> > +Maintainers:
> > +Jonas Ådahl 
> > +Mike Blumenkrantz 
> > diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-
> > shell.xml
> > new file mode 100644
> > index 000..1c0f924
> > --- /dev/null
> > +++ b/stable/xdg-shell/xdg-shell.xml
> > @@ -0,0 +1,1044 @@
> > +
> > +
> > +
> > +  
> > +Copyright © 2008-2013 Kristian Høgsberg
> > +Copyright © 2013  Rafael Antognolli
> > +Copyright © 2013  Jasper St. Pierre
> > +Copyright © 2010-2013 Intel Corporation
> > +
> > +Permission is hereby granted, free of charge, to any person
> > obtaining a
> > +copy of this software and associated documentation files (the
> > "Software"),
> > +to deal in the Software without restriction, including without
> > limitation
> > +the rights to use, copy, modify, merge, publish, distribute,
> > sublicense,
> > +and/or sell copies of the Software, and to permit persons to
> > whom the
> > +Software is furnished to do so, subject to the following
> > conditions:
> > +
> > +The above copyright notice and this permission notice (including
> > the next
> > +paragraph) shall be included in all copies or substantial
> > portions of the
> > +Software.
> > +
> > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > EXPRESS OR
> > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > MERCHANTABILITY,
> > +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO
> > EVENT SHALL
> > +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> > DAMAGES OR OTHER
> > +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> > ARISING
> > +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > OTHER
> > +DEALINGS IN THE SOFTWARE.
> > +  
> > +
> > +  
> > +
> > +  xdg_shell allows clients to turn a wl_surface into a "real
> > window"
> > +  which can be dragged, resized, stacked, and moved around by
> > the
> > +  user. Everything about this interface is suited towards
> > traditional
> > +  desktop environments.
> > +
> > +
> > +
> > +  
> > +   > +summary="xdg_shell was destroyed before children"/>
> > +   > +summary="the 

Re: [PATCH wayland-protocols v3 01/17] Add xdg-shell to stable/

[Philipp Kerling]

Hi,

2017-11-15 (水) の 19:19 +0800 に Jonas Ådahl さんは書きました:
> Add a copy of xdg-shell unstable v6 to stable/xdg-shell/xdg-
> shell.xml.
> Folliwing this commit, it will go through a set of changes, before
> being declared stable.
I have a question here (before declaring it stable) that I hope was not
addressed at some point already:
On the one hand, the definitions of "set_fullscreen," "set_maximized,"
"unset_fullscreen," and "unset_maximized" are worded such that the
compositor is obliged to follow the client request and change the
surface state, i.e. 1) the client can assume that the requested state
transition takes place (if I'm not misreading it) and 2) a compositor
that completely no-ops e.g. (un)set_fullscreen is technically in
violation of the protocol. On the other hand, the definition of
"set_minimized" is worded such that it is a request that might or might
not be fulfilled.
Is this intentional? What if a WM does not want to e.g. maximize a
window for some reason? Or am I reading too much into it? :-)

Best regards,
Philipp


> Signed-off-by: Jonas Ådahl 
> ---
>  stable/xdg-shell/README|5 +
>  stable/xdg-shell/xdg-shell.xml | 1044
> 
>  2 files changed, 1049 insertions(+)
>  create mode 100644 stable/xdg-shell/README
>  create mode 100644 stable/xdg-shell/xdg-shell.xml
> 
> diff --git a/stable/xdg-shell/README b/stable/xdg-shell/README
> new file mode 100644
> index 000..2769abb
> --- /dev/null
> +++ b/stable/xdg-shell/README
> @@ -0,0 +1,5 @@
> +xdg shell protocol
> +
> +Maintainers:
> +Jonas Ådahl 
> +Mike Blumenkrantz 
> diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-
> shell.xml
> new file mode 100644
> index 000..1c0f924
> --- /dev/null
> +++ b/stable/xdg-shell/xdg-shell.xml
> @@ -0,0 +1,1044 @@
> +
> +
> +
> +  
> +Copyright © 2008-2013 Kristian Høgsberg
> +Copyright © 2013  Rafael Antognolli
> +Copyright © 2013  Jasper St. Pierre
> +Copyright © 2010-2013 Intel Corporation
> +
> +Permission is hereby granted, free of charge, to any person
> obtaining a
> +copy of this software and associated documentation files (the
> "Software"),
> +to deal in the Software without restriction, including without
> limitation
> +the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> +and/or sell copies of the Software, and to permit persons to
> whom the
> +Software is furnished to do so, subject to the following
> conditions:
> +
> +The above copyright notice and this permission notice (including
> the next
> +paragraph) shall be included in all copies or substantial
> portions of the
> +Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO
> EVENT SHALL
> +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> DAMAGES OR OTHER
> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> ARISING
> +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> OTHER
> +DEALINGS IN THE SOFTWARE.
> +  
> +
> +  
> +
> +  xdg_shell allows clients to turn a wl_surface into a "real
> window"
> +  which can be dragged, resized, stacked, and moved around by
> the
> +  user. Everything about this interface is suited towards
> traditional
> +  desktop environments.
> +
> +
> +
> +  
> +   +  summary="xdg_shell was destroyed before children"/>
> +   +  summary="the client tried to map or destroy a non-
> topmost popup"/>
> +   +  summary="the client specified an invalid popup parent
> surface"/>
> +   +  summary="the client provided an invalid surface
> state"/>
> +   +  summary="the client provided an invalid positioner"/>
> +
> +
> +
> +  
> + Destroy this xdg_shell object.
> +
> + Destroying a bound xdg_shell object while there are surfaces
> + still alive created by this xdg_shell object instance is
> illegal
> + and will result in a protocol error.
> +  
> +
> +
> +
> +  
> + Create a positioner object. A positioner object is used to
> position
> + surfaces relative to some parent surface. See the interface
> description
> + and xdg_surface.get_popup for details.
> +  
> +  
> +
> +
> +
> +  
> + This creates an xdg_surface for the given surface. While
> xdg_surface
> + itself is not a role, the corresponding surface may only be
> assigned
> + a role extending xdg_surface, such as xdg_toplevel or
> xdg_popup.
> +
> + This creates an xdg_surface for the given surface. An
> xdg_surface is
> + used as basis to define a role to a given surface, such as
> xdg_toplevel
> + or xdg_popup. It 

Re: [PATCH weston 00/16] Tablet device support for weston

[Jason Gerecke]

Looks like the core files have been deleted but the stack traces are
still available. I've attached the logs from coredumpctl for review. I
won't have the ability to run Weston for the next few days, but I
could potentially get you coredumps after that.

Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one  /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours



On Thu, Nov 16, 2017 at 5:16 AM, Maniraj Devadoss (RBEI/ECF3)
 wrote:
> Hi Jason,
>
> I am trying to reproduce the issue. But in my environment I am facing some 
> issue with hid-replay (replay events are not received in weston). Can you 
> please provide coredumps or backtraces if possible.
>
> Best regards,
>
> Devadoss Maniraj
> RBEI/ECF3
>
> Tel. +91 80 6136-4382
>
>
> -Original Message-
> From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On 
> Behalf Of Jason Gerecke
> Sent: Tuesday, November 7, 2017 8:52 AM
> To: Bastian Farkas 
> Cc: wayland-devel@lists.freedesktop.org
> Subject: Re: [PATCH weston 00/16] Tablet device support for weston
>
> On Wed, Oct 25, 2017 at 4:12 AM, Bastian Farkas  
> wrote:
>> Hi,
>>
>> with Peter Hutterers permission I modified an outdated patchset from him 
>> that adds support for tablet devices to the weston compositor. Several minor 
>> changes were needed to get the patches working with a recent weston version.
>>
>> I only tested my patches with a virtual tablet device (using python-evdev).
>>
>> Best regards
>> Bastian Farkas
>>
>
> Hi Bastian,
>
> I tried testing out these patches, but they almost immediately fell flat on 
> their face. A pointer appears and moves around when I bring my pen into prox, 
> and disappears when it leaves prox. When I bring the pen into prox a second 
> time, however, weston either hangs or crashes.
> For what its worth, I did test this patchset the last time they were posted 
> to the list and didn't encounter this problem.
>
> I've attached a hid-replay log of my Intuos Pro which will hopefully let you 
> reproduce the issue yourself. I can try to provide coredumps or backtraces 
> instead if you'd prefer.
>
> Jason
> ---
> Now instead of four in the eights place / you’ve got three, ‘Cause you added 
> one  /
> (That is to say, eight) to the two, /
> But you can’t take seven from three,/
> So you look at the sixty-fours
>
>> Advanced Driver Information Technology GmbH Engineering System &
>> Architecture (ADITG/ESA) Robert-Bosch-Str. 200
>> 31139 Hildesheim
>> Germany
>>
>> Tel. +49 5121 49 6942
>> Fax +49 5121 49 6999
>> bfar...@de.adit-jv.com
>>
>> ADIT is a joint venture company of Robert Bosch GmbH/Robert Bosch Car
>> Multimedia GmbH and DENSO Corporation
>> Sitz: Hildesheim, Registergericht: Amtsgericht Hildesheim HRB 3438
>> Geschäftsführung: Wilhelm Grabow, Ken Yaguchi
>>
>> Bastian Farkas (3):
>>   tablet: Fixed compilation errors resulting from tablet patches.
>>   tablet: Fixing compilation issues in weston desktop-shell related to
>> tablet support patches.
>>   tablet: reordered changes in weston_seat struct to not break ABI
>> compatibility
>>
>> Lyude Paul (13):
>>   tablet: Add initial tablet support to weston
>>   tablet: add handling of tablet focus
>>   tablet: add weston grab interfaces for tablet tools
>>   tablet: hook up libinput tablet events
>>   tablet: handle tablet cursors in the compositor
>>   clients: add support for handling tablets
>>   client: Add tablet cursor support into libtoytoolkit
>>   client: Add support for tablet cursor motion to window frames in
>> libtoytoolkit
>>   tablet: Add support for moving windows around using the stylus
>>   tablet: Add tablet support to the top panel of the desktop shell
>>   tablet: Add binding to activate surfaces using the tablet tool
>>   tablet: Add demo application for tablets
>>   tablet: Remove tablet-specific tools on disconnect
>>
>>  .gitignore  |   1 +
>>  Makefile.am |  20 +-
>>  clients/desktop-shell.c |  56 +++
>>  clients/tablet.c| 254 
>>  clients/window.c| 686 +++
>>  clients/window.h|  93 +
>>  configure.ac|   2 +-
>>  desktop-shell/shell.c   | 289 +
>>  libweston/bindings.c|  39 +-
>>  libweston/compositor.c  |   8 +
>>  libweston/compositor.h  | 204 ++
>>  libweston/input.c   | 963 
>> 
>>  libweston/libinput-device.c | 340 
>>  libweston/libinput-device.h |   4 +-
>>  shared/cairo-util.h |   4 +
>>  shared/frame.c  |  38 ++
>>  16 files changed, 2994 insertions(+), 7 deletions(-)  create mode
>> 100644 clients/tablet.c
>>
>> --
>> 2.7.4
>>
>> ___

Re: [PATCH v3 wayland] client: Allow absolute paths in WAYLAND_DISPLAY

[Jonas Ådahl]

On Tue, Nov 14, 2017 at 12:23:55PM -0600, Matt Hoosier wrote:
> From: Matt Hoosier 
> 
> In order to support system compositor instances, it is necessary to
> allow clients' wl_display_connect() to find the compositor's listening
> socket somewhere outside of XDG_RUNTIME_DIR. For a full account, see
> the discussion beginning here:
> 
> https://lists.freedesktop.org/archives/wayland-devel/2017-November/035664.html
> 
> This change adjusts the client-side connection logic so that, if
> WAYLAND_DISPLAY is formatted as an absolute pathname, the socket
> connection attempt is made to just $WAYLAND_DISPLAY rather than
> usual user-private location $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY.
> 
> This change is based on Davide Bettio's submission of the same concept
> at:
> 
> https://lists.freedesktop.org/archives/wayland-devel/2015-August/023838.html.
> 
> v3 changes:
> 
> * Added test case.
> * Clarified documentation to note that 'name' parameter to 
> wl_display_connect()
>   can also be an absolute path.
> 
> v2 changes:
> 
> * Added backward incompatibility note to wl_display_connect() manpage.
> * Rephased wl_display_connect() manpage changes to precisely match actual
>   changed behavior.
> * Added mention of new absolute path behavior in wl_display_connect()
>   doxygen comments.
> * Mentioned new absolute path interpretation of WAYLAND_DISPLAY in
>   protocol documentation.
> 
> Signed-off-by: Matt Hoosier 

This feature is

Acked-by: Jonas Ådahl 

but I have a few comments on the documentation below.

> ---
>  doc/man/wl_display_connect.xml|  22 ++--
>  doc/publican/sources/Protocol.xml |   5 +-
>  src/wayland-client.c  |  47 
>  tests/socket-test.c   | 109 
> ++
>  4 files changed, 168 insertions(+), 15 deletions(-)
> 
> diff --git a/doc/man/wl_display_connect.xml b/doc/man/wl_display_connect.xml
> index 7e6e05c..9c67612 100644
> --- a/doc/man/wl_display_connect.xml
> +++ b/doc/man/wl_display_connect.xml
> @@ -55,14 +55,30 @@
>  Description
>  wl_display_connect connects to a Wayland 
> socket
>that was previously opened by a Wayland server. The server socket 
> must
> -  be placed in XDG_RUNTIME_DIR for this function to
> -  find it. The name argument specifies the name of
> +  be placed in XDG_RUNTIME_DIR or exist at the 
> absolute
> +  path referred to by WAYLAND_DISPLAY or 
> name
> +  for this function to find it. The name argument 
> specifies the name of

nit1: This line looks like it should be split.

nit2: It's easy to miss the compatibility issues by not mentioning
anything about it here, so maybe refer to the section below here?
Something like

The server socket must be placed in XDG_RUNTIME_DIR
or, depending on version libwayland, exist at the absolute path
referred to by WAYLA... ...find it. See below for compatibility
issue details.

Otherwise, I think the new wording is a bit awkward:

>  wl_display_connect connects to a Wayland 
> socket
>that was previously opened by a Wayland server. The server socket 
> must
>be placed in XDG_RUNTIME_DIR or exist at the 
> absolute
>path referred to by WAYLAND_DISPLAY or 
> name
>for this function to find it.

This changes the meaning of "name" and WAYLAND_DISPLAY.

>The name argument specifies the name of
>the socket or NULL to use the default (which 
> is
>"wayland-0").

This refers to the old meaning where "name" is either NULL or the socket
*name*.

>The environment variable
>WAYLAND_DISPLAY replaces the default value.

It makes the the new documentation a bit confusing.


>the socket or NULL to use the default (which 
> is
>"wayland-0"). The environment variable
>WAYLAND_DISPLAY replaces the default value. If
>WAYLAND_SOCKET is set, this function behaves like
>wl_display_connect_to_fd with the 
> file-descriptor
> -  number taken from the environment variable.
> +  number taken from the environment variable. If
> +  WAYLAND_SOCKET is not set and 
> name
> +  is NULL and WAYLAND_DISPLAY
> +  is an absolute path, then the path stored in 
> WAYLAND_DISPLAY
> +  is used as the Wayland socket to which the connection is 
> attempted.

Isn't this change redundant? If the first change amendment the documentation
redefines the meaning of name and
WAYLAND_DISPLAY we don't need to repeat half of the semantics
here.

> +
> +Support for interpreting WAYLAND_DISPLAY as an
> +  absolute path is a change in behavior compared to
> +  wl_display_connect's behavior in versions
> +  1.14 and older of Wayland. It is no longer guaranteed in versions
> +  1.15 and higher that the 

Re: Screen dimensions, top level surface positioning...

[Jonas Ådahl]

On Wed, Nov 22, 2017 at 03:43:43AM +0200, Jari Vuomajoki wrote:
> Hi Jasper,
> 
> Thank you very much for your very clear and comprehensible answer. I
> understand the challenges you are addressing.
> 
> I want to build applications that can facilitate the screen layout to the
> fullest and still collaborate with WM.
> 
> I don't really get the "fight" between WM and client. Maybe it is an
> invitation for someone to build a really nice WM / compositor, satisfying
> all needs.
> 
> However, stating it bluntly - Client side surface positioning relationship
> to screen dimensions or multiple screen topology is a must.

It is a must for a very specific subset of specalized clients that
construct desktop environment components such as panels, launchers etc.
For regular applications, complete control of positioning is generally
only used to implement some functionality the compositor would be better
at.

> 
> I think it can be done without compromising the simplicity and clarity of
> the protocol. Or is there something that I am not seeing?

I don't know what type of client it is that you are trying to implement,
but with the assumption made above, you'll have to look into extensions
allowing you to achieve the outcome you are working towards.

However, you cannot rely on every desktop environment / compositor to
support every use case that was possible on X11. This is to make it
possible for highly integrated environments such to be implementable.

With that said, this does not stop any compositor to add protocols
for "plug-n-play" kind of environments. One project which goal is to
provide these types of protocols is wayland-wall:
https://github.com/wayland-wall/wayland-wall

Now, you might be trying to implement something else, such as a splash
screen or something. That is might something that hasn't had a protocol
defined for it defined yet, but I would have to know what it is that you
are doing to be able to comment on that.


Jonas


> 
> Thank you,
> Jari Vuomajoki
> 
> 
> On 21 November 2017 at 20:02, Jasper St. Pierre 
> wrote:
> 
> > Hi,
> >
> > There's a few reasons that Wayland not to report or allow clients to
> > choose absolute screen position.
> >
> > The biggest is that from our experience with X11, it's hard to even
> > *define* such a space. Laptops plug into external monitors and projectors.
> > People with differently sized monitors have gaps -- the space isn't as
> > cleanly defined as a large rectangle. In my experience working on X11 WMs,
> > clients often "fight" the WM over placement, preferring to request a
> > position which is now offscreen because the user undocked their computer.
> > Simply not defining a coordinate space to position windows in is easier
> > than defining one, with all the complexities and edge cases that arrive
> > from 30+ years of developments in computer interaction.
> >
> > One of Wayland's design goals is that where possible, compositors, not
> > clients, have the final say. While it can be more difficult to program for,
> > Wayland has concepts based around a relative positioning model. This allows
> > the compositor to place clients where it sees fit, and allows compositors
> > to more freely make constrainment choices so that menus don't get stuck
> > behind taskbar panels, or similar things.
> >
> > It certainly has made some things more complicated, so it might have been
> > an overreaction to the complexity we all faced with X11. Hopefully that
> > gives you some insight into why we chose not to expose positioning to the
> > client.
> >
> > On Tue, Nov 21, 2017 at 8:47 AM, Jari Vuomajoki 
> > wrote:
> >
> >> Hello!
> >>
> >> I have been getting to know the Wayland protocol from the client side for
> >> only couple of months... So bare with me if my questions sound immature.
> >>
> >> It took a while to get going, the documentation is there and it is
> >> informative enough to build a client. It could be a lot better though or
> >> maybe I didn't find a proper source for it. Doxygen documentation ended up
> >> being the most useful.
> >>
> >> Here is my list of questions and thoughts. Feel free to anwer or comment
> >> on any of them.
> >>
> >> I want to compose clients based on screen dimensions. I know there are
> >> fullscreen and maximized options. But I want to have total control of top
> >> level surface sizes and placements in the screen. Now talking about single
> >> screen, but this can be extented to multiple screens.
> >>
> >> This option is not part of the protocol. I can query the screen size
> >> through wl_output interface, so why I cannot position a surface in arbitary
> >> position? Why this option has been left out?
> >>
> >> I want to be able to manage the positions of all the top level shell
> >> surfaces of the client connection.
> >>
> >> Ok, so now I asked it in three different ways...
> >>
> >> I can naturally extend weston shell and implement this option, but it
> >> seems a bit 

Re: Screen dimensions, top level surface positioning...

[Jari Vuomajoki]

Hi Jasper,

Thank you very much for your very clear and comprehensible answer. I
understand the challenges you are addressing.

I want to build applications that can facilitate the screen layout to the
fullest and still collaborate with WM.

I don't really get the "fight" between WM and client. Maybe it is an
invitation for someone to build a really nice WM / compositor, satisfying
all needs.

However, stating it bluntly - Client side surface positioning relationship
to screen dimensions or multiple screen topology is a must.

I think it can be done without compromising the simplicity and clarity of
the protocol. Or is there something that I am not seeing?

Thank you,
Jari Vuomajoki


On 21 November 2017 at 20:02, Jasper St. Pierre 
wrote:

> Hi,
>
> There's a few reasons that Wayland not to report or allow clients to
> choose absolute screen position.
>
> The biggest is that from our experience with X11, it's hard to even
> *define* such a space. Laptops plug into external monitors and projectors.
> People with differently sized monitors have gaps -- the space isn't as
> cleanly defined as a large rectangle. In my experience working on X11 WMs,
> clients often "fight" the WM over placement, preferring to request a
> position which is now offscreen because the user undocked their computer.
> Simply not defining a coordinate space to position windows in is easier
> than defining one, with all the complexities and edge cases that arrive
> from 30+ years of developments in computer interaction.
>
> One of Wayland's design goals is that where possible, compositors, not
> clients, have the final say. While it can be more difficult to program for,
> Wayland has concepts based around a relative positioning model. This allows
> the compositor to place clients where it sees fit, and allows compositors
> to more freely make constrainment choices so that menus don't get stuck
> behind taskbar panels, or similar things.
>
> It certainly has made some things more complicated, so it might have been
> an overreaction to the complexity we all faced with X11. Hopefully that
> gives you some insight into why we chose not to expose positioning to the
> client.
>
> On Tue, Nov 21, 2017 at 8:47 AM, Jari Vuomajoki 
> wrote:
>
>> Hello!
>>
>> I have been getting to know the Wayland protocol from the client side for
>> only couple of months... So bare with me if my questions sound immature.
>>
>> It took a while to get going, the documentation is there and it is
>> informative enough to build a client. It could be a lot better though or
>> maybe I didn't find a proper source for it. Doxygen documentation ended up
>> being the most useful.
>>
>> Here is my list of questions and thoughts. Feel free to anwer or comment
>> on any of them.
>>
>> I want to compose clients based on screen dimensions. I know there are
>> fullscreen and maximized options. But I want to have total control of top
>> level surface sizes and placements in the screen. Now talking about single
>> screen, but this can be extented to multiple screens.
>>
>> This option is not part of the protocol. I can query the screen size
>> through wl_output interface, so why I cannot position a surface in arbitary
>> position? Why this option has been left out?
>>
>> I want to be able to manage the positions of all the top level shell
>> surfaces of the client connection.
>>
>> Ok, so now I asked it in three different ways...
>>
>> I can naturally extend weston shell and implement this option, but it
>> seems a bit overkill for such a simple option to have. What I am not
>> getting in the picture?
>>
>> Best Regards,
>> Jari Vuomajoki
>>
>> ___
>> wayland-devel mailing list
>> wayland-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>>
>
>
> --
>   Jasper
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Screen dimensions, top level surface positioning...

[Jasper St. Pierre]

Hi,

There's a few reasons that Wayland not to report or allow clients to choose
absolute screen position.

The biggest is that from our experience with X11, it's hard to even
*define* such a space. Laptops plug into external monitors and projectors.
People with differently sized monitors have gaps -- the space isn't as
cleanly defined as a large rectangle. In my experience working on X11 WMs,
clients often "fight" the WM over placement, preferring to request a
position which is now offscreen because the user undocked their computer.
Simply not defining a coordinate space to position windows in is easier
than defining one, with all the complexities and edge cases that arrive
from 30+ years of developments in computer interaction.

One of Wayland's design goals is that where possible, compositors, not
clients, have the final say. While it can be more difficult to program for,
Wayland has concepts based around a relative positioning model. This allows
the compositor to place clients where it sees fit, and allows compositors
to more freely make constrainment choices so that menus don't get stuck
behind taskbar panels, or similar things.

It certainly has made some things more complicated, so it might have been
an overreaction to the complexity we all faced with X11. Hopefully that
gives you some insight into why we chose not to expose positioning to the
client.

On Tue, Nov 21, 2017 at 8:47 AM, Jari Vuomajoki 
wrote:

> Hello!
>
> I have been getting to know the Wayland protocol from the client side for
> only couple of months... So bare with me if my questions sound immature.
>
> It took a while to get going, the documentation is there and it is
> informative enough to build a client. It could be a lot better though or
> maybe I didn't find a proper source for it. Doxygen documentation ended up
> being the most useful.
>
> Here is my list of questions and thoughts. Feel free to anwer or comment
> on any of them.
>
> I want to compose clients based on screen dimensions. I know there are
> fullscreen and maximized options. But I want to have total control of top
> level surface sizes and placements in the screen. Now talking about single
> screen, but this can be extented to multiple screens.
>
> This option is not part of the protocol. I can query the screen size
> through wl_output interface, so why I cannot position a surface in arbitary
> position? Why this option has been left out?
>
> I want to be able to manage the positions of all the top level shell
> surfaces of the client connection.
>
> Ok, so now I asked it in three different ways...
>
> I can naturally extend weston shell and implement this option, but it
> seems a bit overkill for such a simple option to have. What I am not
> getting in the picture?
>
> Best Regards,
> Jari Vuomajoki
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>


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

Re: Subscribed or not?

[Jari Vuomajoki]

Great, thanks!

On Nov 21, 2017 19:02, "Dima Ryazanov"  wrote:

> Looks like you're in. Welcome!
>
> On Tue, Nov 21, 2017 at 11:08 PM, Jari Vuomajoki 
> wrote:
>
>> Hello!
>>
>> I have now subscribed two times for the list, without getting any
>> confirmation...
>>
>> So am I in or not?
>>
>> Best Wishes,
>> Jari Vuomajoki
>>
>> ___
>> 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

Re: Subscribed or not?

[Dima Ryazanov]

Looks like you're in. Welcome!

On Tue, Nov 21, 2017 at 11:08 PM, Jari Vuomajoki 
wrote:

> Hello!
>
> I have now subscribed two times for the list, without getting any
> confirmation...
>
> So am I in or not?
>
> Best Wishes,
> Jari Vuomajoki
>
> ___
> 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

Screen dimensions, top level surface positioning...

[Jari Vuomajoki]

Hello!

I have been getting to know the Wayland protocol from the client side for
only couple of months... So bare with me if my questions sound immature.

It took a while to get going, the documentation is there and it is
informative enough to build a client. It could be a lot better though or
maybe I didn't find a proper source for it. Doxygen documentation ended up
being the most useful.

Here is my list of questions and thoughts. Feel free to anwer or comment on
any of them.

I want to compose clients based on screen dimensions. I know there are
fullscreen and maximized options. But I want to have total control of top
level surface sizes and placements in the screen. Now talking about single
screen, but this can be extented to multiple screens.

This option is not part of the protocol. I can query the screen size
through wl_output interface, so why I cannot position a surface in arbitary
position? Why this option has been left out?

I want to be able to manage the positions of all the top level shell
surfaces of the client connection.

Ok, so now I asked it in three different ways...

I can naturally extend weston shell and implement this option, but it seems
a bit overkill for such a simple option to have. What I am not getting in
the picture?

Best Regards,
Jari Vuomajoki
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland] protocol: Add high-resolution wl_touch timestamp event

[Alexandros Frantzis]

On Tue, Nov 21, 2017 at 10:52:00PM +0800, Jonas Ådahl wrote:
> On Tue, Nov 21, 2017 at 03:45:48PM +0200, Alexandros Frantzis wrote:
> > wl_touch events currently use a 32-bit timestamp with millisecond
> > resolution. In some cases, notably latency measurements, this resolution
> > is too coarse-grained to be useful.
> > 
> > This protocol update adds a wl_touch.timestamp event, which is emitted
> > just before an up, motion or down touch event. The timestamp event
> > contains a high-resolution, and ideally higher-accuracy, version of the
> > 'time' argument of the up/motion/down event that follows.
> > 
> > From a client implementation perspective clients can just ignore this event 
> > if
> > they don't care about the improved resolution. Clients that care just need 
> > to
> > keep track of the last timestamp event they receive and associate it with 
> > the
> > next up/motion/down event that arrives.
> > 
> > Some points for discussion:
> > 
> > 1. Should there be a request to explicitly enable/disable the timestamp 
> > event
> >(to reduce extra event overhead when improved timestamps are not needed)?
> 
> Is there any overhead though? Or are you assuming compositors compress
> events when it wouldn't be enabled, or that it'd some how take more
> effort to fetch higher resolution timestamps?

I am more concerned with the potential overhead of sending, receiving
and handling two events instead of one for each touch event (timestamp
followed by up/down/motion). I don't know if the overhead is important
enough to be a real concern, but I know it's not zero.

The issue is somewhat mitigated at the moment since if a client doesn't
care about the new timestamp the wl_touch version number will probably
be < 7, so no event will be sent at all. However, if we add new features
in versions > 7 and a client needs them, they will also get the
timestamp events, which they may not care about.


> > +
> > +
> > +
> > +  
> > +The timestamp event is sent just before a wl_touch.up, 
> > wl_touch.motion
> > +or wl_touch.down event and provides a high-resolution version of 
> > the
> > +time argument of the event that follows.
> > +
> > +The timestamp provided by this event is at least as accurate
> > +as the timestamp provided by the wl_touch event that follows.
> > +  
> > +   > +   summary="high 32 bits of the seconds part of the timestamp"/>
> > +   > +   summary="low 32 bits of the seconds part of the timestamp"/>
> > +   > +   summary="nanoseconds part of the timestamp"/>
> 
> Is nano-seconds really necessary? FWIW, you'll only get timestamps with
> up to micro seconds granularity from libinput, and protocol wise it'd be
> a simple usec_hi::u32, usec_lo::u32 pair, and in code it could be passed
> around as a uint64_t (as is done in libinput).
>
> ALso, tv_nsec as a 32 bit uint doesn't seem enough. In struct timesec
> tv_nsec is 64 bit.

I chose this scheme for two reasons:

1. Primarily to be consistent with how other events carry high-resolution
   timestamp information. In particular I copied the scheme from
   wp_presentation.presented.

2. Secondarily because it ~matches timespec, which is a standard posix
   type.

In this scheme, nanoseconds being 32 bits is fine for normalized
representations of timespec, i.e, where nsec is always < 10^9 (1 sec),
and I think this was the rationale for using 32 bits for it (but I will
let Pekka answer authoritatively).

I am not overly attached to this scheme, but there is some precedence
for it in existing protocols, and I would rather we didn't introduce yet
another scheme, unless it's one that we decide that we want to try to
standardize on, or at least recommend, for future high-res
timestamps.

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

Subscribed or not?

[Jari Vuomajoki]

Hello!

I have now subscribed two times for the list, without getting any
confirmation...

So am I in or not?

Best Wishes,
Jari Vuomajoki
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland] protocol: Add high-resolution wl_touch timestamp event

[Jonas Ådahl]

On Tue, Nov 21, 2017 at 03:45:48PM +0200, Alexandros Frantzis wrote:
> wl_touch events currently use a 32-bit timestamp with millisecond
> resolution. In some cases, notably latency measurements, this resolution
> is too coarse-grained to be useful.
> 
> This protocol update adds a wl_touch.timestamp event, which is emitted
> just before an up, motion or down touch event. The timestamp event
> contains a high-resolution, and ideally higher-accuracy, version of the
> 'time' argument of the up/motion/down event that follows.
> 
> From a client implementation perspective clients can just ignore this event if
> they don't care about the improved resolution. Clients that care just need to
> keep track of the last timestamp event they receive and associate it with the
> next up/motion/down event that arrives.
> 
> Some points for discussion:
> 
> 1. Should there be a request to explicitly enable/disable the timestamp event
>(to reduce extra event overhead when improved timestamps are not needed)?

Is there any overhead though? Or are you assuming compositors compress
events when it wouldn't be enabled, or that it'd some how take more
effort to fetch higher resolution timestamps?

> 
> 2. Should we introduce similar timestamp events for keyboard and pointer?

Not too sure about that. We considered using micro seconds for the
relative pointer protocol[0], but eventually decided not to. Maybe that was
the wrong decision anyhow.

> 
> 3. Should this be a separate protocol instead of a core update (being separate
>would also take care of point (1))?

Not too sure. It's trivial to add it as an extension, but it's also
trivial to add it to wayland.xml. I guess if (1) is actually useful it'd
be better to make it an extension.

> 
> A proof of concept implementation for weston can be found at:
> 
> https://git.collabora.com/cgit/user/alf/weston.git/log/?h=wl-touch-v7
> 
> Note that the weston implementation depends on a patchset that changes weston
> to use higher resolution timestamps internally. The patchset been submitted
> for review at:
> 
> https://lists.freedesktop.org/archives/wayland-devel/2017-November/035851.html
> 
> Signed-off-by: Alexandros Frantzis 
> ---
>  protocol/wayland.xml | 27 +++
>  1 file changed, 23 insertions(+), 4 deletions(-)
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index aabc7ae..b01811e 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -1657,7 +1657,7 @@
>  
> 
>  
> -  
> +  
>  
>A seat is a group of keyboards, pointer and touch devices. This
>object is published as a global during start up, or when such a
> @@ -1766,7 +1766,7 @@
>  
>
>  
> -  
> +  
>  
>The wl_pointer interface represents one or more input devices,
>such as mice, which control the pointer location and pointer_focus
> @@ -2089,7 +2089,7 @@
>  
>
>  
> -  
> +  
>  
>The wl_keyboard interface represents one or more keyboards
>associated with a seat.
> @@ -2200,7 +2200,7 @@
>  
>
>  
> -  
> +  
>  
>The wl_touch interface represents a touchscreen
>associated with a seat.
> @@ -2342,6 +2342,25 @@
>
>
>  
> +
> +
> +
> +
> +  
> +The timestamp event is sent just before a wl_touch.up, 
> wl_touch.motion
> +or wl_touch.down event and provides a high-resolution version of the
> +time argument of the event that follows.
> +
> +The timestamp provided by this event is at least as accurate
> +as the timestamp provided by the wl_touch event that follows.
> +  
> +   +   summary="high 32 bits of the seconds part of the timestamp"/>
> +   +   summary="low 32 bits of the seconds part of the timestamp"/>
> +   +   summary="nanoseconds part of the timestamp"/>

Is nano-seconds really necessary? FWIW, you'll only get timestamps with
up to micro seconds granularity from libinput, and protocol wise it'd be
a simple usec_hi::u32, usec_lo::u32 pair, and in code it could be passed
around as a uint64_t (as is done in libinput).

ALso, tv_nsec as a 32 bit uint doesn't seem enough. In struct timesec
tv_nsec is 64 bit.


Jonas


[0] 
https://lists.freedesktop.org/archives/wayland-devel/2015-November/025497.html

> +
>
>  
>
> -- 
> 2.14.1
> 
> ___
> 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 xserver] xwayland: Give up “cleanly“ on Wayland socket errors

[Olivier Fourdan]

Xwayland is a pretty standard Wayland client, we want to be able to
capture core dumps on crashes.

Yet using "-core" causes any FatalError() to generate a core dump,
meaning that we would get a core file for all Wayland server crashes,
which would generate a lot of false positives.

Instead of using FatalError() on Wayland socket errors, give up cleanly
to avoid dumping core files when "-core" is used.

See also: https://bugzilla.gnome.org/show_bug.cgi?id=790502
 and: https://bugzilla.gnome.org/show_bug.cgi?id=789086

Signed-off-by: Olivier Fourdan 
---
 v2: Replace previous patch reinstalling default signal handlers.

 hw/xwayland/xwayland.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index 81e669cae..81fe5b2c7 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -73,6 +73,22 @@ ddxBeforeReset(void)
 }
 #endif
 
+ _X_NORETURN
+static void _X_ATTRIBUTE_PRINTF(1, 2)
+xwl_give_up(const char *f, ...)
+{
+va_list args;
+
+va_start(args, f);
+VErrorFSigSafe(f, args);
+va_end(args);
+
+CloseWellKnownConnections();
+OsCleanup(TRUE);
+fflush(stderr);
+exit(1);
+}
+
 void
 ddxUseMsg(void)
 {
@@ -722,13 +738,13 @@ xwl_read_events (struct xwl_screen *xwl_screen)
 
 ret = wl_display_read_events(xwl_screen->display);
 if (ret == -1)
-FatalError("failed to read Wayland events: %s\n", strerror(errno));
+xwl_give_up("failed to read Wayland events: %s\n", strerror(errno));
 
 xwl_screen->prepare_read = 0;
 
 ret = wl_display_dispatch_pending(xwl_screen->display);
 if (ret == -1)
-FatalError("failed to dispatch Wayland events: %s\n", strerror(errno));
+xwl_give_up("failed to dispatch Wayland events: %s\n", 
strerror(errno));
 }
 
 static int
@@ -755,7 +771,7 @@ xwl_dispatch_events (struct xwl_screen *xwl_screen)
wl_display_prepare_read(xwl_screen->display) == -1) {
 ret = wl_display_dispatch_pending(xwl_screen->display);
 if (ret == -1)
-FatalError("failed to dispatch Wayland events: %s\n",
+xwl_give_up("failed to dispatch Wayland events: %s\n",
strerror(errno));
 }
 
@@ -764,13 +780,13 @@ xwl_dispatch_events (struct xwl_screen *xwl_screen)
 pollout:
 ready = xwl_display_pollout(xwl_screen, 5);
 if (ready == -1 && errno != EINTR)
-FatalError("error polling on XWayland fd: %s\n", strerror(errno));
+xwl_give_up("error polling on XWayland fd: %s\n", strerror(errno));
 
 if (ready > 0)
 ret = wl_display_flush(xwl_screen->display);
 
 if (ret == -1 && errno != EAGAIN)
-FatalError("failed to write to XWayland fd: %s\n", strerror(errno));
+xwl_give_up("failed to write to XWayland fd: %s\n", strerror(errno));
 
 xwl_screen->wait_flush = (ready == 0 || ready == -1 || ret == -1);
 }
-- 
2.14.3

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

[RFC wayland] protocol: Add high-resolution wl_touch timestamp event

[Alexandros Frantzis]

wl_touch events currently use a 32-bit timestamp with millisecond
resolution. In some cases, notably latency measurements, this resolution
is too coarse-grained to be useful.

This protocol update adds a wl_touch.timestamp event, which is emitted
just before an up, motion or down touch event. The timestamp event
contains a high-resolution, and ideally higher-accuracy, version of the
'time' argument of the up/motion/down event that follows.

From a client implementation perspective clients can just ignore this event if
they don't care about the improved resolution. Clients that care just need to
keep track of the last timestamp event they receive and associate it with the
next up/motion/down event that arrives.

Some points for discussion:

1. Should there be a request to explicitly enable/disable the timestamp event
   (to reduce extra event overhead when improved timestamps are not needed)?

2. Should we introduce similar timestamp events for keyboard and pointer?

3. Should this be a separate protocol instead of a core update (being separate
   would also take care of point (1))?

A proof of concept implementation for weston can be found at:

https://git.collabora.com/cgit/user/alf/weston.git/log/?h=wl-touch-v7

Note that the weston implementation depends on a patchset that changes weston
to use higher resolution timestamps internally. The patchset been submitted
for review at:

https://lists.freedesktop.org/archives/wayland-devel/2017-November/035851.html

Signed-off-by: Alexandros Frantzis 
---
 protocol/wayland.xml | 27 +++
 1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index aabc7ae..b01811e 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -1657,7 +1657,7 @@
 

 
-  
+  
 
   A seat is a group of keyboards, pointer and touch devices. This
   object is published as a global during start up, or when such a
@@ -1766,7 +1766,7 @@
 
   
 
-  
+  
 
   The wl_pointer interface represents one or more input devices,
   such as mice, which control the pointer location and pointer_focus
@@ -2089,7 +2089,7 @@
 
   
 
-  
+  
 
   The wl_keyboard interface represents one or more keyboards
   associated with a seat.
@@ -2200,7 +2200,7 @@
 
   
 
-  
+  
 
   The wl_touch interface represents a touchscreen
   associated with a seat.
@@ -2342,6 +2342,25 @@
   
   
 
+
+
+
+
+  
+The timestamp event is sent just before a wl_touch.up, wl_touch.motion
+or wl_touch.down event and provides a high-resolution version of the
+time argument of the event that follows.
+
+The timestamp provided by this event is at least as accurate
+as the timestamp provided by the wl_touch event that follows.
+  
+  
+  
+  
+
   
 
   
-- 
2.14.1

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

RE: [PATCH weston] ivi-shell: Fix incorrect use of logical instead of bitwise operator

[Ucan, Emre (ADITG/ESB)]

Hi,

Thank you for the patch. It looks good to me.

Reviewed-by: Emre Ucan 

Best regards

Emre Ucan
Engineering Software Base (ADITG/ESB)

Tel. +49 5121 49 6937

> -Original Message-
> From: wayland-devel [mailto:wayland-devel-
> boun...@lists.freedesktop.org] On Behalf Of Alexandros Frantzis
> Sent: Freitag, 17. November 2017 12:39
> To: wayland-devel@lists.freedesktop.org
> Subject: [PATCH weston] ivi-shell: Fix incorrect use of logical instead of
> bitwise operator
> 
> Fix the code to use the correct bitwise AND operator '&', instead of the
> currently used logical AND operator '&&', to check the value of a bit
> flag in a bit mask.
> 
> This problem was reported as a warning when building with clang.
> ---
>  ivi-shell/ivi-layout.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
> index 87adde32..394179b8 100644
> --- a/ivi-shell/ivi-layout.c
> +++ b/ivi-shell/ivi-layout.c
> @@ -617,7 +617,7 @@ commit_changes(struct ivi_layout *layout)
>   * the weston_view below this ivi_view. Otherwise
> content
>   * of this ivi_view will stay visible.
>   */
> - if ((ivilayer->prop.event_mask | ivisurf-
> >prop.event_mask) &&
> + if ((ivilayer->prop.event_mask | ivisurf-
> >prop.event_mask) &
>   IVI_NOTIFICATION_VISIBILITY)
>   weston_view_damage_below(ivi_view-
> >view);
> 
> --
> 2.14.1
> 
> ___
> 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

Re: Fragment Shader of FP16 produces incorrect image drawing.

[Pekka Paalanen]

On Tue, 21 Nov 2017 17:08:51 +0900
YoungJun Jo  wrote:

> Hi,
> 
> The uploaded image was not capture using the camera or mobile phone.
> I captured image using the screenshot program.
> So that's not related display signals or illusion or the human vision.
> The triangle error is shown in the top-right area when you see the image
> with the original image state of 100% without scaling, that is 1280*720
> size.
> Download image and open with your program, do not resize.
> 
> As mentioned in the previous mail, changing the logic to from GL_LINEAR
> to GL_NEAREST in *draw_view()* function, the incorrect drawing
> of the triangle has disappeared. I have done the tests using pixman render,
> so all RGB data values ​​are exactly the same.
> I would like to know that this is related to the GPU's fragment shader fp16
> constraint.
> 
> I linked the original image, error image and my analysis as shown below.
> original-image
> 
> error-image
> 
> analysis excel file
> 
> 
> If you think that this issue is not related to weston, you can ignore it:-)

Hi,

ok, now I see: the "triangle" is a red herring, irrelevant.

The actual problem are the pixel values and the difference cannot (on
my devices at least) be seen with a naked eye. When I inspected the
error-image in Gimp, the pixel channel values indeed differ from 0 or
255.

This is a renderer problem, as far as I can see. The renderers are
supposed to use linear texture interpolation only when the image is
transformed, and use nearest when it is only translated. I suppose the
detection of pure translation might not be perfect.

I'm not sure what you mean by testing on Pixman-renderer, because the
GL_* things are never used there. They are different renderers, they
interpolate and sample with different code. They are supposed to
produce the same output, but with OpenGL I don't think that can ever be
strictly true.

But yes, it makes sense now. How to fix it, I'm not sure.

As said, Weston does not do math with texcoords in the fragment shaders,
it just uses the interpolated coordinates from the vertex shader
directly. The vertex shared does not compute with the texcoords either.
If the issue is really caused by the coordinate interpolation on the
fragment shader inputs, I wouldn't know what to do. It seems Jasper had
some idea.

If fixing it is as simple as changing "precision mediump" to "highp", I
suppose we'd be happy to take that patch.


Thanks,
pq


pgpWrHFCcnJbV.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Fragment Shader of FP16 produces incorrect image drawing.

[Jasper St. Pierre]

Hi,

If you're worried about FP16 interpolation accuracy (which, as the vendor
states, only gets you 10 bits of accuracy, so only 1024 different values --
definitely not big enough to drive a maximized window at normal desktop
resolutions), you can try using normalized GL_SHORT texture coordinates
instead. I don't know if the hardware you have supports fixed-point
interpolation for vertex attributes, you would need to ask your vendor
about that. You can also try changing the "precision mediump"s in
gl-renderer.c to "precision highp"s. I would hope a decent GPU would
support at least FP32.

Anything else would require extensive changes to either use texelFetch or
rectangle textures, both of which are things you likely don't want to do.

On Tue, Nov 21, 2017 at 12:08 AM, YoungJun Jo  wrote:

> Hi,
>
> The uploaded image was not capture using the camera or mobile phone.
> I captured image using the screenshot program.
> So that's not related display signals or illusion or the human vision.
> The triangle error is shown in the top-right area when you see the image
> with the original image state of 100% without scaling, that is 1280*720
> size.
> Download image and open with your program, do not resize.
>
> As mentioned in the previous mail, changing the logic to from GL_LINEAR
> to GL_NEAREST in *draw_view()* function, the incorrect drawing
> of the triangle has disappeared. I have done the tests using pixman
> render,
> so all RGB data values ​​are exactly the same.
> I would like to know that this is related to the GPU's fragment shader
> fp16 constraint.
>
> I linked the original image, error image and my analysis as shown below.
> original-image
> 
> error-image
> 
> analysis excel file
> 
>
> If you think that this issue is not related to weston, you can ignore it:-)
>
> Regards,
> yj
>
> 2017-11-20 20:30 GMT+09:00 Christian Stroetmann :
>
>> Am 20.11.2017 09:08, schrieb Pekka Paalanen:
>>
>>> On Sat, 18 Nov 2017 20:42:44 +0900
>>> YoungJun Jo  wrote:
>>>
>>> Hi pq,

 Thank you for your response.

 However, weston_matrix *is* using float instead of double. Is that the
> problem?
>
 No. according to your analysis, it does not seem to be the cause of the
 this
 problem.

 During animations and any transformations that apply scaling, it is
> expected that the result has some sampling artifacts. The gl-renderer
> also has some logic to switch between GL_NEAREST and GL_LINEAR
> interpolation. What kind of animation is it that triggers the problem
> for you?
>
 When I trace it in gl-renderer, the problem occurs in GL_LINEAR filter.
 After changing the logic to GL_NEAREST instead of the GL_LINEAR,
 the incorrect drawing of the triangle has disappeared.
 It seems that there is a problem when interpolation is performed
 because of fp16 limitation.

 In the attached picture, I see not only the triangle you speak of, but
> also a color difference at the topmost horizontal bar. Could you share
> the original full-resolution captures in the web instead of an
> attachment?
>
 The error of the color difference seems to be in the form of a triangle.
 Please refer to the following link for the captured image.
 cycleline-error.png
 

 Hi,
>>>
>>> that is a very interesting image indeed. Is this really the captured
>>> image with the rendering problem?
>>>
>>> If I look at it at 100% or 700% scaling in firefox, I cannot see
>>> anything wrong in it.
>>>
>>> However, if I look at it at 300% and scroll it sideways, I do see the
>>> strange triangle of the top row, and I also see another vertical "edge"
>>> on the same row somewhat past the midpoint. I don't see them if the
>>> image stationary.
>>>
>>> If I look at it at 200% and squint, I can vaguely see the triangle and
>>> the "edge".
>>>
>>> I also tried 'xmag' of the area where I do see the triangle, and the
>>> magnification does not have it.
>>>
>>> Therefore, I don't think this is a misrendering but some other effect
>>> in the display signal, the monitor device, or even human vision.
>>>
>>> I don't know what to do about it.
>>>
>>>
>>> Thanks,
>>> pq
>>>
>>> Regards,
 yj

 2017-11-17 18:56 GMT+09:00 Pekka Paalanen:

 On Fri, 17 Nov 2017 17:30:47 +0900
> YoungJun Jo  wrote:
>
> Dear all,
>>
>> In the weston environment, there is a problem when displaying a
>> specific
>> image using the GPU(Fragment Shader(FS) only supports FP16).
>> In fact, I think it's not common case to 

Re: [PATCH wayland-protocols v3 18/17] xdg-shell: Soften fullscreen geometry requirements

[Jonas Ådahl]

On Tue, Nov 21, 2017 at 08:16:09AM +, Arnaud Vrac wrote:
> On Tue, Nov 21, 2017 at 5:54 AM Jonas Ådahl  wrote:
> 
> > Having a strict requirement on clients obeying the configured window
> > geometry for fullscreen toplevel surfaces might have the side effect of
> > making it harder or impossible to implement various hardware
> > optimizations on certain system configurations. By softening
> > requirements on the geometry while loosely defining the border fill, we
> > remove that restriction.
> >
> > Clients that still want total control of the surrounding area can
> > still for example prepare the attached buffers to match the configured
> > surface size, or use subsurfaces in combination with wp_viewporter to
> > make up a surface matching the fullscreen window geometry dimensions.
> >
> > Signed-off-by: Jonas Ådahl 
> > ---
> >  stable/xdg-shell/xdg-shell.xml | 18 ++
> >  1 file changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/stable/xdg-shell/xdg-shell.xml
> > b/stable/xdg-shell/xdg-shell.xml
> > index 34e3a20..dc70c7a 100644
> > --- a/stable/xdg-shell/xdg-shell.xml
> > +++ b/stable/xdg-shell/xdg-shell.xml
> > @@ -728,8 +728,11 @@
> >
> >
> > 
> > - The surface is fullscreen. The window geometry specified in the
> > configure
> > - event must be obeyed by the client.
> > + The surface is fullscreen. The window geometry specified in the
> > + configure event is a maximum; the client cannot resize beyond
> > it. For
> > + a surface to cover the whole fullscreened area, the geometry
> > + dimensions must be obeyed by the client. For more details, see
> > + xdg_toplevel.set_fullscreen.
> > 
> >
> >
> > @@ -888,7 +891,7 @@
> >
> > After requesting that the surface should be fullscreened, the
> > compositor will respond by emitting a configure event with the
> > -   "fullscreen" state and the required window geometry. The client
> > must
> > +   "fullscreen" state and the fullscreen window geometry. The client
> > must
> > also acknowledge the configure when committing the new content (see
> > ack_configure).
> >
> > @@ -899,7 +902,14 @@
> >
> > If the surface doesn't cover the whole output, the compositor will
> > position the surface in the center of the output and compensate
> > with
> > -   black borders filling the rest of the output.
> > +   with border fill covering the rest of the output. The content of
> > the
> > +   border fill is undefined, but should be assumed to be in some way
> > that
> > +   attempts to blend into the surrounding area (e.g. solid black).
> > +
> > +   If the fullscreened surface is not opaque, the compositor must make
> > +   sure that other screen content not part of the same surface tree
> > (made
> > +   up of subsurfaces, popups or similarly coupled surfaces) are not
> > +   visible below the fullscreened surface.
> >
> > > allow-null="true"/>
> >  
> > --
> > 2.14.2
> >
> 
> Very nice, thanks. The patch to on libweston-desktop to match this wording
> is pretty simple, I'll push it if needed when libweston-desktop supports
> the stable xdg-shell protocol.
> 
> Reviewed-by: Arnaud Vrac 

Thanks a lot! Added tag locally so far.


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

Re: [PATCH wayland-protocols v3 01/17] Add xdg-shell to stable/

[Jonas Ådahl]

On Wed, Nov 15, 2017 at 01:01:14PM +, David Edmundson wrote:
> Looks good to me!
> 
> Reviewed-by: David Edmundson 

Thanks, appreciated! Added tag locally so far.


Jonas

> ___
> 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

Re: [PATCH xserver] xwayland: Restore default signal handlers

[Olivier Fourdan]

Hi all,

(sorry for top posting here, I just mean to keep the patch at th end).

I think this patch raise the question of the intended use of FatalError() in 
the Xserver.

 - as an exit() on error:
   port out of range, host not on supported network type, unknown host, etc.
   screen init failed, invalid configuration, 
   
 - as a abort() / assert()
   memory allocation failures, fork failure, GLSL compilation failures, 

 - and in Xwayland for socket issues

For /some/ it would make sense to (optionally, with "-core") generate a core 
dump (things liek memory allocation, GLSL, shaders isses, etc.), for other not 
so much (Wayland socket errors, wrong configuration or command line options).

So, which is the intended use of FatalError() and do we have an equivalent for 
those cases where it's not the intended use?

Cheers,
Olivier

   
- Original Message -
> Xwayland is a pretty standard Wayland client, we want to be able to
> capture core dumps on crashes.
> 
> Yet using "-core" in the command line is not what we want, because that
> causes any FatalError() to generate a core dump, meaning that we would
> get a core file for all Wayland server crashes, which would generate a
> lot of false positives.
> 
> Besides, for most case, the xorg_backtrace() generated is not sufficient
> and rather ineffective compared to a regular debugger session.
> 
> Restore the default signal handlers for Xwayland so that the usual
> signals (SIGSEGV, SIGABRT, SIGILL, etc.) will possibly generate a core
> file (depending on the OS configuration of course).
> 
> See also: https://bugzilla.gnome.org/show_bug.cgi?id=790502
>  and: https://bugzilla.gnome.org/show_bug.cgi?id=789086
> 
> Signed-off-by: Olivier Fourdan 
> ---
>  hw/xwayland/xwayland.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
> index 81e669cae..f327db748 100644
> --- a/hw/xwayland/xwayland.c
> +++ b/hw/xwayland/xwayland.c
> @@ -845,6 +845,22 @@ wm_selection_callback(CallbackListPtr *p, void *data,
> void *arg)
>  DeleteCallback(, wm_selection_callback, xwl_screen);
>  }
>  
> +static void
> +reset_default_signals (void)
> +{
> +OsSignal(SIGSEGV, SIG_DFL);
> +OsSignal(SIGABRT, SIG_DFL);
> +OsSignal(SIGILL, SIG_DFL);
> +#ifdef SIGEMT
> +OsSignal(SIGEMT, SIG_DFL);
> +#endif
> +OsSignal(SIGFPE, SIG_DFL);
> +OsSignal(SIGBUS, SIG_DFL);
> +OsSignal(SIGSYS, SIG_DFL);
> +OsSignal(SIGXCPU, SIG_DFL);
> +OsSignal(SIGXFSZ, SIG_DFL);
> +}
> +
>  static Bool
>  xwl_screen_init(ScreenPtr pScreen, int argc, char **argv)
>  {
> @@ -853,6 +869,9 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char **argv)
>  Pixel red_mask, blue_mask, green_mask;
>  int ret, bpc, green_bpc, i;
>  
> +/* For Xwayland, we want to be able to capture core files on crashes */
> +reset_default_signals();
> +
>  xwl_screen = calloc(1, sizeof *xwl_screen);
>  if (xwl_screen == NULL)
>  return FALSE;
> --
> 2.14.3
> 
> ___
> xorg-de...@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v3 18/17] xdg-shell: Soften fullscreen geometry requirements

[Arnaud Vrac]

On Tue, Nov 21, 2017 at 5:54 AM Jonas Ådahl  wrote:

> Having a strict requirement on clients obeying the configured window
> geometry for fullscreen toplevel surfaces might have the side effect of
> making it harder or impossible to implement various hardware
> optimizations on certain system configurations. By softening
> requirements on the geometry while loosely defining the border fill, we
> remove that restriction.
>
> Clients that still want total control of the surrounding area can
> still for example prepare the attached buffers to match the configured
> surface size, or use subsurfaces in combination with wp_viewporter to
> make up a surface matching the fullscreen window geometry dimensions.
>
> Signed-off-by: Jonas Ådahl 
> ---
>  stable/xdg-shell/xdg-shell.xml | 18 ++
>  1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/stable/xdg-shell/xdg-shell.xml
> b/stable/xdg-shell/xdg-shell.xml
> index 34e3a20..dc70c7a 100644
> --- a/stable/xdg-shell/xdg-shell.xml
> +++ b/stable/xdg-shell/xdg-shell.xml
> @@ -728,8 +728,11 @@
>
>
> 
> - The surface is fullscreen. The window geometry specified in the
> configure
> - event must be obeyed by the client.
> + The surface is fullscreen. The window geometry specified in the
> + configure event is a maximum; the client cannot resize beyond
> it. For
> + a surface to cover the whole fullscreened area, the geometry
> + dimensions must be obeyed by the client. For more details, see
> + xdg_toplevel.set_fullscreen.
> 
>
>
> @@ -888,7 +891,7 @@
>
> After requesting that the surface should be fullscreened, the
> compositor will respond by emitting a configure event with the
> -   "fullscreen" state and the required window geometry. The client
> must
> +   "fullscreen" state and the fullscreen window geometry. The client
> must
> also acknowledge the configure when committing the new content (see
> ack_configure).
>
> @@ -899,7 +902,14 @@
>
> If the surface doesn't cover the whole output, the compositor will
> position the surface in the center of the output and compensate
> with
> -   black borders filling the rest of the output.
> +   with border fill covering the rest of the output. The content of
> the
> +   border fill is undefined, but should be assumed to be in some way
> that
> +   attempts to blend into the surrounding area (e.g. solid black).
> +
> +   If the fullscreened surface is not opaque, the compositor must make
> +   sure that other screen content not part of the same surface tree
> (made
> +   up of subsurfaces, popups or similarly coupled surfaces) are not
> +   visible below the fullscreened surface.
>
> allow-null="true"/>
>  
> --
> 2.14.2
>

Very nice, thanks. The patch to on libweston-desktop to match this wording
is pretty simple, I'll push it if needed when libweston-desktop supports
the stable xdg-shell protocol.

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

Re: Fragment Shader of FP16 produces incorrect image drawing.

[YoungJun Jo]

Hi,

The uploaded image was not capture using the camera or mobile phone.
I captured image using the screenshot program.
So that's not related display signals or illusion or the human vision.
The triangle error is shown in the top-right area when you see the image
with the original image state of 100% without scaling, that is 1280*720
size.
Download image and open with your program, do not resize.

As mentioned in the previous mail, changing the logic to from GL_LINEAR
to GL_NEAREST in *draw_view()* function, the incorrect drawing
of the triangle has disappeared. I have done the tests using pixman render,
so all RGB data values ​​are exactly the same.
I would like to know that this is related to the GPU's fragment shader fp16
constraint.

I linked the original image, error image and my analysis as shown below.
original-image

error-image

analysis excel file


If you think that this issue is not related to weston, you can ignore it:-)

Regards,
yj

2017-11-20 20:30 GMT+09:00 Christian Stroetmann :

> Am 20.11.2017 09:08, schrieb Pekka Paalanen:
>
>> On Sat, 18 Nov 2017 20:42:44 +0900
>> YoungJun Jo  wrote:
>>
>> Hi pq,
>>>
>>> Thank you for your response.
>>>
>>> However, weston_matrix *is* using float instead of double. Is that the
 problem?

>>> No. according to your analysis, it does not seem to be the cause of the
>>> this
>>> problem.
>>>
>>> During animations and any transformations that apply scaling, it is
 expected that the result has some sampling artifacts. The gl-renderer
 also has some logic to switch between GL_NEAREST and GL_LINEAR
 interpolation. What kind of animation is it that triggers the problem
 for you?

>>> When I trace it in gl-renderer, the problem occurs in GL_LINEAR filter.
>>> After changing the logic to GL_NEAREST instead of the GL_LINEAR,
>>> the incorrect drawing of the triangle has disappeared.
>>> It seems that there is a problem when interpolation is performed
>>> because of fp16 limitation.
>>>
>>> In the attached picture, I see not only the triangle you speak of, but
 also a color difference at the topmost horizontal bar. Could you share
 the original full-resolution captures in the web instead of an
 attachment?

>>> The error of the color difference seems to be in the form of a triangle.
>>> Please refer to the following link for the captured image.
>>> cycleline-error.png
>>> 
>>>
>>> Hi,
>>
>> that is a very interesting image indeed. Is this really the captured
>> image with the rendering problem?
>>
>> If I look at it at 100% or 700% scaling in firefox, I cannot see
>> anything wrong in it.
>>
>> However, if I look at it at 300% and scroll it sideways, I do see the
>> strange triangle of the top row, and I also see another vertical "edge"
>> on the same row somewhat past the midpoint. I don't see them if the
>> image stationary.
>>
>> If I look at it at 200% and squint, I can vaguely see the triangle and
>> the "edge".
>>
>> I also tried 'xmag' of the area where I do see the triangle, and the
>> magnification does not have it.
>>
>> Therefore, I don't think this is a misrendering but some other effect
>> in the display signal, the monitor device, or even human vision.
>>
>> I don't know what to do about it.
>>
>>
>> Thanks,
>> pq
>>
>> Regards,
>>> yj
>>>
>>> 2017-11-17 18:56 GMT+09:00 Pekka Paalanen:
>>>
>>> On Fri, 17 Nov 2017 17:30:47 +0900
 YoungJun Jo  wrote:

 Dear all,
>
> In the weston environment, there is a problem when displaying a
> specific
> image using the GPU(Fragment Shader(FS) only supports FP16).
> In fact, I think it's not common case to use a GPU with FS of FP16
> constraints in a desktop environment, so I was worried about asking
> question.
>
> The specific image which the error occurs is an image with black
> vertical
> lines and white vertical lines arranged at 1 pixel intervals.
> I modified the weston-image code to display fullscreen to better
> observe
> where the error occurred.
>
> When I display the image on the screen, I get a triangle-shaped wrong
> drawing during the time of the fade animation in the top-right part.
> (Please refer to attachment 'cycleline-error.png')
>
> First, I contacted the GPU vendor about this issue and got the
> following
> answer:
> ---
> I'm pretty sure the issue is that your texture coordinates are being
> converted to fp16 because arithmetic is being performed on them before
>
 they

> are used. For fp16 values above the 0.5 limit on the texture