Re: [PATCH wayland-protocols] Add the wl_drm protocol

[Pekka Paalanen]

On Tue, 14 Nov 2017 11:23:22 +
Emil Velikov  wrote:

> On 14 November 2017 at 08:18, Pekka Paalanen  wrote:
> > On Mon, 13 Nov 2017 16:27:24 +
> > Emil Velikov  wrote:
> >  
> >> On 13 November 2017 at 14:52, Emil Velikov  
> >> wrote:  
> >> > On 13 November 2017 at 14:21, Daniel Stone  wrote: 
> >> >  
> >> >> Hi Emil,
> >> >>
> >> >> On 2 November 2017 at 17:09, Emil Velikov  
> >> >> wrote:  
> >> >>> Import latest version (v2) of the protocol from Mesa.
> >> >>>
> >> >>> From the README:
> >> >>>
> >> >>> Warning!
> >> >>> The goal is to share the protocol file across Mesa and other low-level
> >> >>> components graphics stack such as libva and Xwayland. File is moved to
> >> >>> wayland-protocols for sharing purposes _only_.
> >> >>>
> >> >>> The protocol is _not_ for public use. Furthermore Mesa and others 
> >> >>> consider
> >> >>> the protocol as deprecated over wl_dmabuf.  
> >> >>
> >> >> I suspect the sheer fact that we've recently added it as a stable
> >> >> published protocol would be enough for people to ignore that
> >> >> objection.
> >> >>
> >> >> I have to say that I'm still against this one, for a few reasons.
> >> >>
> >> >> Firstly, yes, VA-API got it wrong: there's no way it should be using
> >> >> unpublished private protocol. Luckily, newer versions of VA-API and
> >> >> the GStreamer integration now have both proper dmabuf integration as
> >> >> well as the notion of simply exporting buffers rather than trying to
> >> >> be a presentation _and_ decoding layer in one, so using a VA-API
> >> >> decoder piped to waylandsink is enough to get it working without
> >> >> wl_drm ever being used. Happy days. (Xwayland is in the same boat:
> >> >> lfrb's patches mean it can use dmabuf instead.)
> >> >>
> >> >> Secondly, apart from VA-API, it's not used generically. It gets
> >> >> published as a side effect of Mesa calling eglBindWaylandDisplayWL(),
> >> >> and the Mesa client code (both in libEGL.so, though the two versions
> >> >> can indeed get out of sync) uses it. Compositors don't explicitly
> >> >> advertise it, and again for the most part clients don't use it.
> >> >>
> >> >> What I worry is that, if we publish it, clients _will_ come to use it
> >> >> despite the warnings, and Mesa will never be able to stop advertising
> >> >> it. Having it be private/unpublished protocol is an implementation
> >> >> detail, but with a published protocol doc, the fact Mesa advertises it
> >> >> will come to be seen as ABI instead. I really, really, don't want to
> >> >> paint ourselves into that corner: wl_drm has always been an awkward
> >> >> special case, but I'd much prefer to kill it off than enshrine its
> >> >> position.
> >> >>
> >> >> There is one gap which zwp_linux_dmabuf_v1 doesn't fill, which is
> >> >> passing a device handle for the composition GPU, as well as maybe
> >> >> another for the scanout device. That would give the allocator enough
> >> >> information to determine correct buffer placement and so on. But if we
> >> >> ignore placement as we do today, just having format + modifiers would
> >> >> be enough for both EGL/Vulkan and VA-API clients which were aware of
> >> >> modifiers to work properly. Drivers without modifiers would still need
> >> >> the GPU device passed down so they can decide which magic tiling mode
> >> >> to use, but that'll go as they get converted over.
> >> >>
> >> >> I'd much prefer to see wl_drm go completely unused where possible on
> >> >> the client side first, then work out a transition plan for Mesa
> >> >> deprecating it, then we can say with a straight face that we're not
> >> >> publishing it because we expect it to disappear.
> >> >>  
> >> > Thanks for the elaborate answer Dan.
> >> >
> >> > Being the more paranoid person (me thinks), I doubt anyone outside of
> >> > existing users will use wl_drm.
> >

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

[Pekka Paalanen]

On Fri, 10 Nov 2017 11:19:49 -0600
Matt Hoosier  wrote:

> Hi,
> 
> On Fri, Nov 10, 2017 at 5:37 AM, Pekka Paalanen  wrote:
> > On Thu,  9 Nov 2017 09:36:29 -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.
> >>   

> >>  doc/man/wl_display_connect.xml | 11 ---
> >>  src/wayland-client.c   | 34 +++---
> >>  2 files changed, 31 insertions(+), 14 deletions(-)

> > One more thing to make this change perfect would be to add a test in
> > the test suite to check that an absolute path works. It could live in
> > socket-test.c maybe.  
> 
> Writing the actual test wasn't very hard. But I ran aground on the
> memory-leak checker. There are implicit allocations done by setenv()
> calls in the individual test case to set $WAYLAND_DISPLAY to hold the
> absolute path needed by the impending call to wl_display_connect(). I
> couldn't find any guaranteed way to reclaim that memory -- unsetenv()
> doesn't do the job.
> 
> If you have any thoughts on ways to get around this, I can add the test in.

Hi Matt,

I believe we just have to let that leak then. Looks like we have
DISABLE_LEAK_CHECKS macro which you could use with a comment pointing
to setenv.


Thanks,
pq


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

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

[Pekka Paalanen]

On Fri, 10 Nov 2017 11:20:42 -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.
> 
> 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 
> ---
>  doc/man/wl_display_connect.xml| 22 +---
>  doc/publican/sources/Protocol.xml |  5 -
>  src/wayland-client.c  | 43 
> +--
>  3 files changed, 55 insertions(+), 15 deletions(-)
> 
> diff --git a/doc/man/wl_display_connect.xml b/doc/man/wl_display_connect.xml
> index 7e6e05c..7bdfc46 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 for this 
> function
> +  to find it. The name argument specifies the 
> name of
>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.
> +
> +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 Wayland socket chosen is equivalent to
> +  manually constructing a socket pathname by concatenating
> +  XDG_RUNTIME_DIR and WAYLAND_DISPLAY.
> +  Manual construction of the socket path must account for the
> +  possibility that WAYLAND_DISPLAY contains an 
> absolute
> +  path.

Hi Matt,

this is a bit verbose, but it is correct. 'name' argument could now be
absolute as well.

>  
>  wl_display_connect_to_fd connects to a Wayland
>socket with an explicit file-descriptor. The file-descriptor is 
> passed
> diff --git a/doc/publican/sources/Protocol.xml 
> b/doc/publican/sources/Protocol.xml
> index ba6b5f1..dbfed06 100644
> --- a/doc/publican/sources/Protocol.xml
> +++ b/doc/publican/sources/Protocol.xml
> @@ -94,7 +94,10 @@
>The protocol is sent over a UNIX domain stream socket, where the 
> endpoint
>usually is named wayland-0
>(although it can be changed via WAYLAND_DISPLAY
> -  in the environment).
> +  in the environment). In the reference implementation, a client whose
> +  WAYLAND_DISPLAY is formatted as an absolute path
> +  connects to that path as the endpoint, otherwise the implementation
> +  searches in XDG_RUNTIME_DIR for the endpoint.
>  
>  
>Every message is structured as 32-bit words; values are represented in 
> the
> diff --git a/src/wayland-client.c b/src/wayland-client.c
> index 3d7361e..d90cbfb 100644
> --- a/src/wayland-client.c
> +++ b/src/wayland-client.c

The code here is good.

> @@ -994,6 +1009,12 @@ wl_display_connect_to_fd(int fd)
>   * its value will be replaced with the WAYLAND_DISPLAY environment
>   * variable if it is set, otherwise display "wayland-0" will be used.
>   *
> + * If \c name is \c NULL and the WAYLAND_DISPLA

Re: Wayland Message Behaviour

[Pekka Paalanen]

On Wed, 15 Nov 2017 15:47:32 +
"Turner, LewisX"  wrote:

> Hi Derek and pq,
> 
> Thanks for the further suggestions and comments.
> 
> The idea around multiple threads is a likely candidate. We have added
> a thread and the flush is coming from the extra thread.
> 
> There seems to be two obvious approaches to solving the issue:
> 1) Create a new queue for our new thread and just flush the new queue.
> 2) Signal back to the main thread to request that the queue is
> flushed.
> 
> Do you have any advice/opinion on which approach might be better? Are
> there any examples of taking either approach?

Hi,

this is about server-side, yes?

There are no such queues server-side, so option 1 is impossible.

Option 2 sounds like you would still be sending Wayland events from
multiple threads. That is not reliable.

I cannot see any way to share Wayland library objects between threads
unless you explicitly add full locking around all libwayland-server
calls. I would guess that will be painful, and it is also impossible,
because your component is not the only one doing those calls, you would
have to patch everything used on the server side.

Multiple threads have never been supported in libwayland-server. There
is literally no locking whatsoever to prevent threads from corrupting
objects by simultaneous access. I cannot stress this enough. The only
solution I can see, if you must have multiple threads, is to architect
your program so that all libwayland-server objects (wl_display,
wl_client, wl_resource, wl_event_loop, etc.) are only ever accessed
from a single thread.


Thanks,
pq


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

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

[Pekka Paalanen]

On Tue, 14 Nov 2017 12:23:55 -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 

Hi Matt,

this patch looks very good. I have made some very small comments below,
but I'm confident that those fixed or discussed this patch will be:

Reviewed-by: Pekka Paalanen 

Everyone else, especially those in the CC, I would like to ask you to
give your explicit Acked-by for this patch to record the community
acceptance in the git history.

Matt, could you hold off sending v4 for a while so that you can collect
all the Reviewed-by's and Acked-by's that will arrive, but I am also
fine collecting them myself if you want this sooner out of your hands.

> ---
>  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
>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.
> +
> +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 Wayland socket chosen is equivalent to
> +  manually constructing a socket pathname by concatenating
> +  XDG_RUNTIME_DIR and WAYLAND_DISPLAY.
> +  Manual construction of the socket path must account for the
> +  possibility that WAYLAND_DISPLAY contains an 
> absolute
> +  path.
>  
>  wl_display_connect_to_fd connects to a Wayland
>socket with an explicit file-descriptor. The file-descriptor is 
> passed
> diff --git a/doc/publican/sources/Protocol.xml 
> b/doc/publican/sources/Protocol.xml
> index ba6b5f1..dbfed06 100644
> --- a/doc/publican/sources/Protocol.xml
> +++ b/doc/publican/sources/Protocol.

Re: Fragment Shader of FP16 produces incorrect image drawing.

[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 coordinate the
> fp16 "increment" between values is 2^-11, or about 0.000488. For a texture
> which is 1024 pixels wide this give an sample point accuracy of only +-
> half a pixel width which is insufficient for accurate sampling (especially
> when using GL_LINEAR filtering).
> Short answer: don't do maths on texture coordinates in the fragment shader.
> ---
> Based on the above answer, I would like to confirm whether the exception
> handling is appropriate for animation in the condition that FS is FP16 in
> weston's gl-renderer.
> In addition, I have found one way to prevent such incorrect rendering.
> When i remove the *weston_matrix_init(&animation->transform.matrix)* in
> *weston_view_animation_create()* function;, The error does not occur and
> the animation effect is shown.
> In Android(I do not know if it is appropriate to compare), since there is
> no matrix operation during animation, wrong drawing does not occur.
> So I would like to know whether the matrix operation in weston animation is
> necessary or can be removed.
> Or is there another good way to avoid the above precision errors?
> 
> My debugging and analysis may be wrong, so I would appreciate any feedback.

Hi,

weston's vertex or fragment shaders do not do any computations on the
texture coordinates, so I am confused about saying it's about the
shaders.

Commenting out a call to weston_matrix_init() does not prevent the
matrix from being used. It will only cause the matrix to be used
uninitialized.

However, weston_matrix *is* using float instead of double. Is that the
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?

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?


Thanks,
pq


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

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

[Pekka Paalanen]

On Sat, 18 Nov 2017 07:36:58 -0600
Matt Hoosier  wrote:

> On Fri, Nov 17, 2017 at 2:22 AM, Pekka Paalanen  wrote:
> > On Tue, 14 Nov 2017 12:23:55 -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   
> >
> > Hi Matt,
> >
> > this patch looks very good. I have made some very small comments below,
> > but I'm confident that those fixed or discussed this patch will be:
> >
> > Reviewed-by: Pekka Paalanen 
> >
> > Everyone else, especially those in the CC, I would like to ask you to
> > give your explicit Acked-by for this patch to record the community
> > acceptance in the git history.
> >
> > Matt, could you hold off sending v4 for a while so that you can collect
> > all the Reviewed-by's and Acked-by's that will arrive, but I am also
> > fine collecting them myself if you want this sooner out of your hands.  
> 
> Thanks, Pekka.
> 
> Yeah, I can wait a while to submit v4. I'll make the small changes you
> requested in your comments below, and add your r-b. I'm a little
> unclear on how I'll know when enough time has elapsed in your opinion
> to judge that all the ack's and r-b's that are likely to eventually
> arrive, have done so.

Hi Matt,

let's see what happens in a week.


Thanks,
pq


pgp6nCN3dqUd0.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.

[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
> <https://www.dropbox.com/s/k0u0bh8vn9vybee/cycleline-error.png?dl=0>
> 

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 coordinate  
> > the  
> > > fp16 "increment" between values is 2^-11, or about 0.000488. For a  
> > texture  
> > > which is 1024 pixels wide this give an sample point accuracy of only +-
> > > half a pixel width which is insufficient for accurate sampling  
> > (especially  
> > > when using GL_LINEAR filtering).
> > > Short answer: don't do maths on texture coordinates in the fragment  
> > shader.  
> > > ---
> > > Based on the above answer, I would like to confirm whether the exception
> > > handling is appropriate for animation in the condition that FS is FP16 in
> > > weston's gl-renderer.
> > > In addition, I have found one way to prevent such incorrect rendering.
> > > When i remove the *weston_matrix_init(&animation->transform.matrix)* in
> > > *weston_view_animation_create()* function;, The error does not occur and
> > > the animation effect is shown.
> > > In Android(I do not know if it is appropriate t

Re: VNC or RDP in Weston

[Pekka Paalanen]

On Tue, 21 Nov 2017 06:37:32 +
"Keskinarkaus, Teemu"  wrote:

> Hi,
> 
> Just inquiring what is the state of the Wayland VNC and/or RDP
> support?
> 
> We have i.MX6 based HW and atm. it's using Weston 1.11.x which I
> assume is way too old for VNC/RDP? Or is there backport for that?
> 
> We are also working on Weston 2.0, but I haven't really been able to
> find if the VNC/RDP support is there (and working) and/or how to
> configure/use it.  Is it there and is it working and how to use it
> and/or is there any documentation how to do it?
> 

Hi,

Weston has never had VNC support, but the RDP backend is quite long
lived by now.

David, another call for those instructions on how to setup and test the
RDP-backend. ;-)


Thanks,
pq


pgp1rkS7bitN3.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.

[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: 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: [RFC wayland] protocol: Add high-resolution wl_touch timestamp event

[Pekka Paalanen]

On Tue, 21 Nov 2017 18:20:08 +0200
Alexandros Frantzis  wrote:

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

Hi,

I would say that the overhead in insignificant. The overhead is 8 bytes of
data, and a dispatch.

> 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).

Correct.

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

Right. We're talking about input events, "surely millisecond precision
is enough" - and it wasn't. Surely microsecond precision is enough?
Well, for all we can imagine today, but...

I see no harm in going full timespec.


Thanks,
pq


pgpU3NW_zKYtS.pgp
Description: OpenPGP digital signature
___
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

[Pekka Paalanen]

On Tue, 21 Nov 2017 15:45:48 +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)?

Hi,

I would tend to believe it makes no difference. Motion events could be
fairly high rate in theory, so would be good to hear if anyone thinks
otherwise, but I think it's harmless.

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

No, unless someone actually has a use for them. That brings the
question, why are you only interested in touch timestamps and not
keyboard and pointer?

Why are keyboard and pointer latency not interesting to you?

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

That's a good question. I don't think I have obvious technical reasons
to pick one approach over the other. I can think of benefits for it
being a separate extension, though:

- The overhead you mentioned, making this optional.

- If a compositor actually cannot get any more precise timestamps than
  the core protocol already delivers, then it could avoid sending
  useless events. Vice versa, having the extension advertised would
  give clients the promise that there could be more precise timestamps
  available.

- Extensibility. Say, maybe in the future we want input timestamps in a
  specific clock domain. That could be nicely added if this is a
  separate extension, and less so if this was a core augmentation.

However, if precise input timestamps were a separate extension, we
would need to think if different wl_seats could have a different clock
domain. That could be the case with remote input, but OTOH remote input
should be converted into a local clock if possible.

I would slightly lean on a separate extension that is worded such that
the timestamp events are (subscribed) per wl_seat. It depends a little
bit on whether we want keyboard and pointer timestamps as well.

IOW, a client would maintain a timestamp field for each wl_seat, so
that different seats could, if necessary, have different clock domains.
This is currently somewhat undefined in the core protocol, but I think
it would be reasonable.

> 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

I took a quick peek and the implementation looks exactly like I would expect.

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

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

[Pekka Paalanen]

On Tue, 21 Nov 2017 12:04:55 +
"Ucan, Emre (ADITG/ESB)"  wrote:

> Hi,
> 
> Thank you for the patch. It looks good to me.
> 
> Reviewed-by: Emre Ucan 

Pushed:
   71c4f70e..0343c6ac  master -> master

Thanks,
pq


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

Re: [PATCH weston 04/12] libweston: Use struct timespec for the output presentation timestamp

[Pekka Paalanen]

On Thu, 16 Nov 2017 18:20:53 +0200
Alexandros Frantzis  wrote:

> Store the output presentation timestamp as struct timespec.
> 
> This commit is part of a larger effort to transition the Weston codebase
> to struct timespec.
> 
> Signed-off-by: Alexandros Frantzis 
> ---
>  libweston/compositor.c| 12 ++--
>  libweston/compositor.h|  2 +-
>  libweston/screenshooter.c |  3 ++-
>  3 files changed, 9 insertions(+), 8 deletions(-)

Patches 1-4 are:
Reviewed-by: Pekka Paalanen 

Thanks,
pq


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

Re: [PATCH weston 05/12] libweston: Use struct timespec for motion events

[Pekka Paalanen]

On Thu, 16 Nov 2017 18:20:54 +0200
Alexandros Frantzis  wrote:

> Change code related to motion events to use struct timespec to represent
> time.
> 
> This commit is part of a larger effort to transition the Weston codebase
> to struct timespec.
> 
> Signed-off-by: Alexandros Frantzis 
> ---
>  compositor/screen-share.c  |  6 +-
>  desktop-shell/exposay.c|  3 ++-
>  desktop-shell/shell.c  | 12 
>  ivi-shell/hmi-controller.c |  3 ++-
>  libweston-desktop/seat.c   |  2 +-
>  libweston/compositor-rdp.c | 10 +++---
>  libweston/compositor-wayland.c |  5 -
>  libweston/compositor-x11.c |  6 --
>  libweston/compositor.h | 12 +++-
>  libweston/data-device.c|  8 ++--
>  libweston/input.c  | 30 ++
>  libweston/libinput-device.c| 19 ++-
>  tests/weston-test.c|  6 +-
>  13 files changed, 79 insertions(+), 43 deletions(-)
> 


> diff --git a/libweston/libinput-device.c b/libweston/libinput-device.c
> index b1d269db..b1087ba5 100644
> --- a/libweston/libinput-device.c
> +++ b/libweston/libinput-device.c
> @@ -39,6 +39,7 @@
>  #include "compositor.h"
>  #include "libinput-device.h"
>  #include "shared/helpers.h"
> +#include "shared/timespec-util.h"
>  
>  void
>  evdev_led_update(struct evdev_device *device, enum weston_led weston_leds)
> @@ -86,26 +87,25 @@ handle_pointer_motion(struct libinput_device 
> *libinput_device,
>   struct evdev_device *device =
>   libinput_device_get_user_data(libinput_device);
>   struct weston_pointer_motion_event event = { 0 };
> - uint64_t time_usec =
> - libinput_event_pointer_get_time_usec(pointer_event);
> + struct timespec time;
>   double dx_unaccel, dy_unaccel;
>  
> + timespec_from_usec(&time,
> +libinput_event_pointer_get_time_usec(pointer_event));
>   dx_unaccel = libinput_event_pointer_get_dx_unaccelerated(pointer_event);
>   dy_unaccel = libinput_event_pointer_get_dy_unaccelerated(pointer_event);
>  
>   event = (struct weston_pointer_motion_event) {
>   .mask = WESTON_POINTER_MOTION_REL |
>   WESTON_POINTER_MOTION_REL_UNACCEL,
> - .time_usec = time_usec,
> + .time = time,
>   .dx = libinput_event_pointer_get_dx(pointer_event),
>   .dy = libinput_event_pointer_get_dy(pointer_event),
>   .dx_unaccel = dx_unaccel,
>   .dy_unaccel = dy_unaccel,
>   };
>  
> - notify_motion(device->seat,
> -   libinput_event_pointer_get_time(pointer_event),
> -   &event);
> + notify_motion(device->seat, &time, &event);
>  
>   return true;
>  }
> @@ -118,14 +118,15 @@ handle_pointer_motion_absolute(
>   struct evdev_device *device =
>   libinput_device_get_user_data(libinput_device);
>   struct weston_output *output = device->output;
> - uint32_t time;
> + struct timespec time;
>   double x, y;
>   uint32_t width, height;
>  
>   if (!output)
>   return false;
>  
> - time = libinput_event_pointer_get_time(pointer_event);
> + timespec_from_usec(&time,
> +libinput_event_pointer_get_time(pointer_event));

Hi,

I think the time here was msec, not usec. Libinput documentation does
not say what the unit for libinput_event_pointer_get_time() is, but
since there also exists libinput_event_pointer_get_time_usec(), I
believe the former returns milliseconds.

>   width = device->output->current_mode->width;
>   height = device->output->current_mode->height;
>  
> @@ -135,7 +136,7 @@ handle_pointer_motion_absolute(
> height);
>  
>   weston_output_transform_coordinate(device->output, x, y, &x, &y);
> - notify_motion_absolute(device->seat, time, x, y);
> + notify_motion_absolute(device->seat, &time, x, y);
>  
>   return true;
>  }

That was the only problem I could see in this patch, everything else
looks good.


Thanks,
pq


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

Re: [PATCH weston 12/12] libweston: Use struct timespec for compositor time

[Pekka Paalanen]

On Thu, 16 Nov 2017 18:21:01 +0200
Alexandros Frantzis  wrote:

> Change weston_compositor_get_time to return the current compositor time
> as a struct timespec. Also, use clock_gettime (with CLOCK_REALTIME) to
> get the time, since it's equivalent to the currently used gettimeofday
> call, but returns the data directly in a struct timespec.
> 
> This commit is part of a larger effort to transition the Weston codebase
> to struct timespec.
> 
> Signed-off-by: Alexandros Frantzis 
> ---
>  compositor/text-backend.c  | 11 +++
>  desktop-shell/shell.c  |  8 
>  desktop-shell/shell.h  |  2 +-
>  libweston/compositor-rdp.c | 10 +-
>  libweston/compositor-x11.c | 21 ++---
>  libweston/compositor.c | 10 +++---
>  libweston/compositor.h |  4 ++--
>  7 files changed, 32 insertions(+), 34 deletions(-)

Hi,

patches 6-12 are:
Reviewed-by: Pekka Paalanen 

I think it would be fine to send v2 of just patch 5, and then I can
land all this on Monday.


Thanks,
pq


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

Re: [PATCH weston 01/12] shared: Add timespec_is_zero helper

[Pekka Paalanen]

On Fri, 24 Nov 2017 18:36:43 +
Emil Velikov  wrote:

> Hi Alexandros,
> 
> On 16 November 2017 at 16:20, Alexandros Frantzis
>  wrote:
> 
> > +ZUC_TEST(timespec_test, timespec_is_zero)
> > +{
> > +   struct timespec zero = { 0 };
> > +   struct timespec non_zero_sec = { 1, 0 };
> > +   struct timespec non_zero_nsec = { 0, 1 };
> > +  
> The standard (be that POSIX or C99) does not guarantee the layout of
> the struct. Hence the above approach may work, but it's a bad idea.
> Personally I'm a fan of C99 designated initializers, although one
> could set the tv_sec and tv_nsec individually.
> 
> Same comment applies through the rest of the series.

That's actually a very good point, I missed it!

Alexandros, can you revise, please?


Thanks,
pq


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

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

[Pekka Paalanen]

On Fri, 24 Nov 2017 18:40:13 +0200
Jari Vuomajoki  wrote:

> Hi Everyone!
> 
> Thank you all for clear answers. I can understand the problematic of
> providing parallel solutions for several graphics environments...
> 
> ...so here is the use-case I am puzzled with:
> 
> I am implementing a desktop application consisting of several windows. I
> can create proper implementation using the existing client API. However
> there is one scenario that falls out of the possibilities.
> 
> Let's say that the environment is a desktop computer with single screen.
> The workflow consists using several applications with some applications
> having several top-level windows and jumping between them using shortcuts,
> jumping between applications as well as application windows. Composers
> usually have uniform solution jumping between applications and application
> windows that can be associated with shortcuts, expose-style layout
> solutions, other gestures...
> 
> At this point everything works well with current Wayland client API. But if
> a client wants to organize it's top-level windows in more suitable ways
> like organizing windows side by side, creating a grid or organizing them in
> a special purpose custom layout... it is no longer possible with top level
> windows. This is only possible for sub-surfaces, therefore breaking the
> integration with the shortcuts and exposure with the composer/WM.
> 
> I think this kind of scenario is relatively common: One screen, multiple
> applications with multiple windows.
> 
> Of course a solution is implementing composer or shell, but this breaks
> compatibility across composers/WMs.

Hi Jari,

yes, you are right, there is currently no solution to do that as far as
I know. Introducing one means adding a protocol extension that can e.g.
position top-levels relative to other top-levels of the same client. If
the compositor knows that this window should be side-by-side on the
right of that window for instance, it can reposition both such that
they both fit on the screen. If fitting on the screen is impossible,
the compositor can choose to break the proposed positioning to ensure
the windows are still accessible to the user, or propose resizing to
the app.

A protocol extension necessarily means adding an implementation in all
compositors and all toolkits.

An alternative solution could be application session save/restore
protocol feature, that would allow the app to recall old top-level
window positions, without exposing any global coordinate system, and
automatically adapting to cases where e.g. some screens have
disappeared but the windows should still be accessible.

I don't know if either feature have been worked on, at least I don't
remember seeing any proposals to wayland-protocols.

These are just two examples of many use cases which require protocol
extensions, but which may have not been worked on yet.


Thanks,
pq


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

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

[Pekka Paalanen]

On Sat, 25 Nov 2017 08:11:43 -0600
Matt Hoosier  wrote:

> Hi Jonas, Pekka,
> 
> I have no objection to making the tweaks that Jonas mentions, but I'm
> wary of messing with the form of this patch that Pekka already
> stamped. Pekka, am I going to lose your consent as given in v3 if I
> make changes along the lines Jonas requests?

Hi Matt,

you can downgrade my Reviewed-by to Acked-by in this case. I think
doing the changes Jonas suggested are good, but I cannot give R-b
without seeing the actual words. I'll just re-review then.


Thanks,
pq

> On Tue, Nov 21, 2017 at 10:00 PM, Jonas Ådahl  wrote:
> > 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.  
> 
> Can you be more specific? The implementation does allow 'name' now to
> encode an absolute path, so I agree that it changes the meaning in
> that sense. What else did you mean? The bit saying 'the server socket
> must be placed in XDG_RUNTIME_DIR' is recycled language that already
> existed before this change.
> 
> >  
> >>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 

Re: [PATCH weston 00/12] libweston: Use struct timespec for time values

[Pekka Paalanen]

On Thu, 16 Nov 2017 18:20:49 +0200
Alexandros Frantzis  wrote:

> This patchset changes libweston to consistently use struct timespec for time
> values.
> 
> struct timespec is the standard way to represent time on Linux and allows for
> an improved range and accuracy compared to the millisecond based uint32_t
> values currently used in throughout the codebase. This change provides to 
> users
> of libweston timestamps with higher accuracy, and will also allow libweston to
> more easily support future wayland interfaces that may require such
> high-accuracy timestamps.
> 
> Note that this patchset breaks the libweston ABI, so we will need to bump the
> ABI version at some point.
> 
> Patches (1) and (2) add more functionality to the timespec utilities to 
> support
> the new uses cases introduced in the commits that follow.
> 
> Patches (3) to (12) gradually transition libweston to use struct timespec.  To
> make the changes more reviewable, each patch deals with only a specific aspect
> of the codebase. In order to limit the scope of each commit, some commits
> include temporary time value conversions to accommodate existing internal 
> APIs.
> These temporary conversions are later removed as the internal APIs are
> also changed to used struct timespec.
> 
> Alexandros Frantzis (12):
>   shared: Add timespec_is_zero helper
>   shared: Add helpers to convert between various time units and timespec
>   libweston: Use struct timespec for animations
>   libweston: Use struct timespec for the output presentation timestamp
>   libweston: Use struct timespec for motion events
>   libweston: Use struct timespec for button events
>   libweston: Use struct timespec for axis events
>   libweston: Use struct timespec for key events
>   libweston: Use struct timespec for touch down events
>   libweston: Use struct timespec for touch up events
>   libweston: Use struct timespec for touch motion events
>   libweston: Use struct timespec for compositor time
> 
>  compositor/screen-share.c |  24 +--
>  compositor/text-backend.c |  24 +--
>  compositor/weston-screenshooter.c |   6 +-
>  desktop-shell/exposay.c   |  14 ++--
>  desktop-shell/shell.c | 134 
> +-
>  desktop-shell/shell.h |   4 +-
>  ivi-shell/hmi-controller.c|  18 +++--
>  ivi-shell/ivi-shell.c |   8 ++-
>  libweston-desktop/seat.c  |  23 ---
>  libweston/animation.c |  29 +
>  libweston/bindings.c  |  32 +
>  libweston/compositor-drm.c|  16 ++---
>  libweston/compositor-rdp.c|  22 +--
>  libweston/compositor-wayland.c|  42 +---
>  libweston/compositor-x11.c|  45 +++--
>  libweston/compositor.c|  24 +++
>  libweston/compositor.h|  99 
>  libweston/data-device.c   |  34 ++
>  libweston/gl-renderer.c   |   6 +-
>  libweston/input.c | 117 -
>  libweston/launcher-util.c |   2 +-
>  libweston/libinput-device.c   |  59 ++---
>  libweston/pixman-renderer.c   |   4 +-
>  libweston/screenshooter.c |   3 +-
>  libweston/spring-tool.c   |  13 ++--
>  libweston/zoom.c  |   7 +-
>  shared/timespec-util.h|  59 +
>  tests/surface-screenshot.c|   4 +-
>  tests/timespec-test.c |  83 +++
>  tests/weston-test.c   |  17 -
>  30 files changed, 647 insertions(+), 325 deletions(-)
> 

Hi,

I have picked the v2 versions of patches 1 and 5, and pushed it all
with my R-b:
   0343c6ac..409b01fd  master -> master

I also augmented patch 3 to bump the libweston major for this series.


Thanks,
pq


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

Re: [PATCH weston v3 01/36] weston: arm SEGV handler earlier

[Pekka Paalanen]

On Tue, 31 Oct 2017 12:41:08 +
Daniel Stone  wrote:

> On 31 October 2017 at 12:31, Quentin Glidic
>  wrote:
> > On 10/31/17 12:48 PM, Pekka Paalanen wrote:  
> >> It is useful to print the backtrace regardless of whether we have a
> >> compositor and a backend initialized yet. Move catch_signals() to the
> >> earliest point in main() and protect the SEGV handler from dereferencing
> >> NULL when we don't yet have a compositor or a backend.
> >>
> >> The SEGV handler uses weston_log(), so cannot move catch_signals() any
> >> earlier.
> >>
> >> Signed-off-by: Pekka Paalanen   
> >
> > Sounds good:
> > Reviewed-by: Quentin Glidic   
> 
> Reviewed-by: Daniel Stone 

Pushed this one:
   409b01fd..3baf9ce7  master -> master


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

Re: [PATCH weston 1/3] weston-launch: quit if -t without -u

[Pekka Paalanen]

On Thu, 2 Nov 2017 09:53:41 +0200
Pekka Paalanen  wrote:

> On Wed, 1 Nov 2017 15:37:53 +0100
> Quentin Glidic  wrote:
> 
> > On 11/1/17 3:24 PM, Pekka Paalanen wrote:  
> > > From: Pekka Paalanen 
> > > 
> > > setup_tty() function uses the tty argument for choosing the tty/VT only
> > > if wl->new_user (the -u option) is given. If the tty option is given
> > > without -u, it will only be used for misleading error messages.
> > > 
> > > To make it clear to the user that -t without -u does not work the way
> > > one might think, let weston-launch exit with an error in that case.
> > > 
> > > Signed-off-by: Pekka Paalanen 
> > > ---
> > >   libweston/weston-launch.c | 3 +++
> > >   1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/libweston/weston-launch.c b/libweston/weston-launch.c
> > > index aa7e0711..bc50de74 100644
> > > --- a/libweston/weston-launch.c
> > > +++ b/libweston/weston-launch.c
> > > @@ -722,6 +722,9 @@ main(int argc, char *argv[])
> > >   if ((argc - optind) > (MAX_ARGV_SIZE - 6))
> > >   error(1, E2BIG, "Too many arguments to pass to weston");
> > >   
> > > + if (tty && !wl.new_user)
> > > + error(1, 0, "tty option requires -u option as well.");
> > 
> > Nit: maybe EINVAL?
> > And maybe "-t/--tty … -u/--user", at least use the same format to make 
> > it clearer?  
> 
> The error message of the first form is:
> 
> weston-launch: tty option requires -u option as well.
> 
> the error message of the second form is:
> 
> weston-launch: -t/--tty option requires -u/--user option as well: Invalid 
> argument
> 
> I don't think the "Invalid argument" makes it better, and almost all
> the other uses of error() that do not stem of a library or system call
> failure use 0 already. Therefore I'll settle for:
> 
> weston-launch: -t/--tty option requires -u/--user option as well
> 
> The E2BIG case shown in the patch context seems to be the exception to
> how error() is being used in weston-launch.c.
> 
> > Anyway, this one is:
> > Reviewed-by: Quentin Glidic   
> 
> Let me know if your R-b still stands with
> 
>   error(1, 0, "-t/--tty option requires -u/--user option as well");
> 

The three patches pushed:
   3baf9ce7..1a2adfed  master -> master


Thanks,
pq


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

Re: [PATCH weston] weston: add wait-for-debugger option

[Pekka Paalanen]

On Thu, 2 Nov 2017 06:31:28 +
"Ray, Ian (GE Healthcare)"  wrote:

> On 01/11/2017, 16.24, "wayland-devel on behalf of Pekka Paalanen" 
>  ppaala...@gmail.com> wrote:
> > 
> > From: Pekka Paalanen 
> > 
> > When you need to start Weston via weston-launch, systemd unit, or any
> > other runner, it is annoying to try to get in with a debugger,
> > especially if the thing you are interested in happens at start-up. To
> > make it easy, a new option is introduced.
> > 
> > The new option, implemented both as a command line option and a
> > weston.ini option, raises SIGSTOP early in the start-up, before the
> > weston_compositor has been created. This allows one to attach a debugger
> > at a known point in execution, and resume execution with SIGCONT.
> > 
> > Signed-off-by: Pekka Paalanen   
> 
> Reviewed-by: Ian Ray 

Pushed:
   3baf9ce7..1a2adfed  master -> master


Thanks,
pq


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

Re: [PATCH weston 2/2] man: mention logind for launching

[Pekka Paalanen]

On Tue, 31 Oct 2017 11:53:15 +0200
Pekka Paalanen  wrote:

> From: Pekka Paalanen 
> 
> Logind has been long supported as means to launch Weston without
> weston-launch. It's good to note it in the manual.
> 
> Signed-off-by: Pekka Paalanen 
> ---
>  man/weston.man | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/man/weston.man b/man/weston.man
> index face2298..d19c2d4b 100644
> --- a/man/weston.man
> +++ b/man/weston.man
> @@ -20,9 +20,12 @@ shell.
>  When weston is started as the first windowing system (i.e. not under X nor
>  under another Wayland server), it should be done with the command
>  .B weston-launch
> -to set up proper privileged access to devices.
> +to set up proper privileged access to devices. If your system supports
> +the logind D-Bus API and the support has been built into weston as well,
> +it is possible to start weston with just
> +.BR weston .
>  
> -Weston also supports X clients via 
> +Weston also supports X clients via
>  .BR XWayland ", see below."
>  .
>  .\" ***
> @@ -106,7 +109,7 @@ Load
>  .I backend.so
>  instead of the default backend. The file is searched for in
>  .IR "__weston_modules_dir__" ,
> -or you can pass an absolute path. The default backend is 
> +or you can pass an absolute path. The default backend is
>  .I __weston_native_backend__
>  unless the environment suggests otherwise, see
>  .IR DISPLAY " and " WAYLAND_DISPLAY .


Thanks to Quentin for IRC R-b, both patches are now pushed:
   1a2adfed..68f8e47a  master -> master


Thanks,
pq


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

[PATCH weston] doc/systemd: system service example

[Pekka Paalanen]

From: Pekka Paalanen 

There are many bad and even worse attempts to make Weston run as a
systemd service, and very few good ones. Let's add a good one as an
example in upstream: does not use weston-launch, does not run weston as
root, does not need wrapper scripts, and relies on logind and PAM.

This example has been composed from a couple of real-world Weston unit
files used in production. It has not been used verbatim, but it has been
briefly tested on one Yocto-based system.

The service file is not installed by the build. It would likely need
small adjustments for each distribution or system to be deplyed on.

The session-c1.scope workaround refers to a systemd bug that has been
said to be hard to reproduce, but the details have been lost in time.

Fixes: https://phabricator.freedesktop.org/T63

Cc: martyn.we...@collabora.co.uk
Cc: fabien.lahoud...@collabora.co.uk
Cc: matt.hoos...@gmail.com
Cc: sjoerd.sim...@collabora.co.uk
Signed-off-by: Pekka Paalanen 

---

Hi all,

I have cross-posted this patch to systemd-devel with the hope that
someone would recall details about the systemd or PAM plugin race that
prompted the session-c1.scope workaround. I belive Martyn spoke about it
in person with Lennart, but as far as Martyn recalls, there is no record
of the issue. Enabling session lingering was mentioned as another
workaround.
---
 doc/systemd/README | 45 +++
 doc/systemd/weston.service | 66 ++
 2 files changed, 111 insertions(+)
 create mode 100644 doc/systemd/README
 create mode 100644 doc/systemd/weston.service

diff --git a/doc/systemd/README b/doc/systemd/README
new file mode 100644
index ..2aa3aa9a
--- /dev/null
+++ b/doc/systemd/README
@@ -0,0 +1,45 @@
+   Systemd integration examples
+
+These examples rely on Weston's logind and systemd support. Weston needs to be
+built with options: --enable-dbus --enable-systemd-login 
--enable-systemd-notify
+
+Furthermore, Weston needs to be configured to load systemd-notify.so plugin.
+This can be done on the Weston command line:
+
+$ weston --modules=systemd-notify.so
+
+or in weston.ini:
+
+[core]
+modules=systemd-notify.so
+
+The plugin implements the systemd service notification protocol, watchdog
+protocol, and also allows socket activation and configuring listening sockets
+via systemd.
+
+
+   weston.service
+
+An example on how to run Weston as a system service. It starts a full user
+session of the named user on the given virtual terminal.
+
+This is useful for running a login manager or for dedicated systems that do not
+have personal user accounts and do not need the user to log in.
+
+You should very least customize the user, but likely also the tty and
+and the weston command line. See 'systemctl edit' command for an easy way to
+do that per-system if you don't edit the service file before installing it.
+
+This approach has an issue that in one system was worked around with the
+"After=session-c1.scope" directive. The details have been forgotten, but
+enabling session lingering was mentioned as another workaround. It might
+perhaps have something to do with multiple system units triggering the setup
+of a user session. It would be much better to start Weston as a systemd user
+service instead to avoid the issue completely.
+
+
+TODO: add an example of socket activation and defining sockets with systemd
+
+TODO: talk about starting Weston as a systemd user service, as that would
+often be more appropriate than as a system service. The user can still be
+automatically logged in. Presumably the auto-login service can allocate the VT.
diff --git a/doc/systemd/weston.service b/doc/systemd/weston.service
new file mode 100644
index ..80d242a6
--- /dev/null
+++ b/doc/systemd/weston.service
@@ -0,0 +1,66 @@
+# This is a system unit for launching Weston with auto-login as the
+# user configured here.
+#
+# Weston must be built with systemd support, and your weston.ini must load
+# the plugin systemd-notify.so.
+
+[Unit]
+Description=Weston, a Wayland compositor, as a system service
+Documentation=man:weston(1) man:weston.ini(5)
+Documentation=http://wayland.freedesktop.org/
+
+# Make sure we are started after logins are permitted.
+After=systemd-user-sessions.service
+
+# If Plymouth is used, we want to start when it is on its way out.
+After=plymouth-quit-wait.service
+
+# D-Bus is necessary for contacting logind. Logind is required.
+Wants=dbus.socket
+After=dbus.socket
+
+# This scope is created by pam_systemd when logging in as the user.
+# This directive is a workaround to a systemd bug, where the setup of the
+# user session by PAM has some race condition, possibly leading to a failure.
+# See README for more details.
+After=session-c1.scope
+
+# Since we are part of the graphical session, make sure we are started before
+# it is complete.
+Before=graphical.target
+
+# Prevent starting on syste

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

[Pekka Paalanen]

On Tue, 28 Nov 2017 14:16:32 +
Daniel Stone  wrote:

> Hi,
> 
> On 24 November 2017 at 11:59, Pekka Paalanen  wrote:
> > On Tue, 21 Nov 2017 15:45:48 +0200
> > Alexandros Frantzis  wrote:  
> >> 2. Should we introduce similar timestamp events for keyboard and pointer?  
> >
> > No, unless someone actually has a use for them. That brings the
> > question, why are you only interested in touch timestamps and not
> > keyboard and pointer?
> >
> > Why are keyboard and pointer latency not interesting to you?  
> 
> I would very much suggest doing so, yeah. Having timestamps for
> high-frequency/resolution mice seems like a real need. Given the need
> to correllate the event streams (e.g. 'is someone holding down Ctrl
> whilst I scroll?'), it makes it easier for clients if we have
> comparable timestamps between the two.

Right, let's have them for all the timestamped core input events, not
only touch.


Thanks,
pq


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

libwayland-cursor heap overflow fix

[Pekka Paalanen]

Hi all,

I would like to bring to your attention a patch I have just merged into
wayland master:

https://cgit.freedesktop.org/wayland/wayland/commit/?id=5d201df72f3d4f4cb8b8f75f980169b03507da38

commit 5d201df72f3d4f4cb8b8f75f980169b03507da38
Author: Tobias Stoeckmann 
Date:   Tue Nov 28 21:38:07 2017 +0100

cursor: Fix heap overflows when parsing malicious files.

It is possible to trigger heap overflows due to an integer overflow
while parsing images.

The integer overflow occurs because the chosen limit 0x1 for
dimensions is too large for 32 bit systems, because each pixel takes
4 bytes. Properly chosen values allow an overflow which in turn will
lead to less allocated memory than needed for subsequent reads.

See also: 
https://cgit.freedesktop.org/xorg/lib/libXcursor/commit/?id=4794b5dd34688158fb51a2943032569d3780c4b8
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=103961

Signed-off-by: Tobias Stoeckmann 
[Pekka: add link to the corresponding libXcursor commit]
Signed-off-by: Pekka Paalanen 

This fix is not yet in any release, so would be nice if distributions
cherry-picked this into what they ship, the pick should be trivial for
any release so far.

The issue has existed in libwayland-cursor ever since it was
introduced, before wayland 1.0.0 release.


Thanks,
pq


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

Re: [systemd-devel] [PATCH weston] doc/systemd: system service example

[Pekka Paalanen]

On Wed, 29 Nov 2017 09:32:02 +0100
Jérémy Rosen  wrote:

> I had a quick glance but didn't actually test...

> 2) you probably want to add Alias=display-manager.service, so it can 
> pull it other graphical services

Hi,

that sounds like a good idea.


Thanks,
pq

(adding back all the CCs)

> On 28/11/2017 11:14, Pekka Paalanen wrote:
> > From: Pekka Paalanen 
> >
> > There are many bad and even worse attempts to make Weston run as a
> > systemd service, and very few good ones. Let's add a good one as an
> > example in upstream: does not use weston-launch, does not run weston as
> > root, does not need wrapper scripts, and relies on logind and PAM.
> >
> > This example has been composed from a couple of real-world Weston unit
> > files used in production. It has not been used verbatim, but it has been
> > briefly tested on one Yocto-based system.
> >
> > The service file is not installed by the build. It would likely need
> > small adjustments for each distribution or system to be deplyed on.
> >
> > The session-c1.scope workaround refers to a systemd bug that has been
> > said to be hard to reproduce, but the details have been lost in time.
> >
> > Fixes: https://phabricator.freedesktop.org/T63
> >
> > Cc: martyn.we...@collabora.co.uk
> > Cc: fabien.lahoud...@collabora.co.uk
> > Cc: matt.hoos...@gmail.com
> > Cc: sjoerd.sim...@collabora.co.uk
> > Signed-off-by: Pekka Paalanen 
> >
> > ---
> >
> > Hi all,
> >
> > I have cross-posted this patch to systemd-devel with the hope that
> > someone would recall details about the systemd or PAM plugin race that
> > prompted the session-c1.scope workaround. I belive Martyn spoke about it
> > in person with Lennart, but as far as Martyn recalls, there is no record
> > of the issue. Enabling session lingering was mentioned as another
> > workaround.
> > ---
> >   doc/systemd/README | 45 +++
> >   doc/systemd/weston.service | 66 
> > ++
> >   2 files changed, 111 insertions(+)
> >   create mode 100644 doc/systemd/README
> >   create mode 100644 doc/systemd/weston.service
> >
> > diff --git a/doc/systemd/README b/doc/systemd/README
> > new file mode 100644
> > index ..2aa3aa9a
> > --- /dev/null
> > +++ b/doc/systemd/README
> > @@ -0,0 +1,45 @@
> > +   Systemd integration examples
> > +
> > +These examples rely on Weston's logind and systemd support. Weston needs 
> > to be
> > +built with options: --enable-dbus --enable-systemd-login 
> > --enable-systemd-notify
> > +
> > +Furthermore, Weston needs to be configured to load systemd-notify.so 
> > plugin.
> > +This can be done on the Weston command line:
> > +
> > +$ weston --modules=systemd-notify.so
> > +
> > +or in weston.ini:
> > +
> > +[core]
> > +modules=systemd-notify.so
> > +
> > +The plugin implements the systemd service notification protocol, watchdog
> > +protocol, and also allows socket activation and configuring listening 
> > sockets
> > +via systemd.
> > +
> > +
> > +   weston.service
> > +
> > +An example on how to run Weston as a system service. It starts a full user
> > +session of the named user on the given virtual terminal.
> > +
> > +This is useful for running a login manager or for dedicated systems that 
> > do not
> > +have personal user accounts and do not need the user to log in.
> > +
> > +You should very least customize the user, but likely also the tty and
> > +and the weston command line. See 'systemctl edit' command for an easy way 
> > to
> > +do that per-system if you don't edit the service file before installing it.
> > +
> > +This approach has an issue that in one system was worked around with the
> > +"After=session-c1.scope" directive. The details have been forgotten, but
> > +enabling session lingering was mentioned as another workaround. It might
> > +perhaps have something to do with multiple system units triggering the 
> > setup
> > +of a user session. It would be much better to start Weston as a systemd 
> > user
> > +service instead to avoid the issue completely.
> > +
> > +
> > +TODO: add an example of socket activation and defining sockets with systemd
> > +
> > +TODO: talk about starting Weston as a systemd user service, as that would
> > +often be more appropriate than as a system service. The user can still be
> > +automatic

Re: [PATCH RFC xserver] xwayland: List all wl_output::mode(s) in xrandr

[Pekka Paalanen]

On Wed, 29 Nov 2017 15:26:58 +0100
Olivier Fourdan  wrote:

> Xwayland would only list the current wl_output mode in xrandr, even
> though multiple modes might be advertised by the Wayland compositor.
> 
> List all available modes listed by the Wayland compositor using
> wl_output::mode in XrandR.
> 
> Signed-off-by: Olivier Fourdan 
> ---
>  Note: this works best with weston which lists multiple modes, unlike
>gnome-shell/mutter which advertises only the current mode in
>wl_output::mode.
> 
>  hw/xwayland/xwayland-output.c | 87 
> ---
>  hw/xwayland/xwayland.h| 12 ++
>  2 files changed, 93 insertions(+), 6 deletions(-)

Hi Olivier,

do you also plan to let Xwayland change the mode? If not, what's the
benefit of this?

My naive guess is that if apps or users don't see multiple modes in the
list, they are less likely to attempt to change it via RandR.


Thanks,
pq


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

Re: [PATCH RFC xserver] xwayland: List all wl_output::mode(s) in xrandr

[Pekka Paalanen]

On Wed, 29 Nov 2017 10:18:47 -0500 (EST)
Olivier Fourdan  wrote:

> Hi Pekka,
> 
> > do you also plan to let Xwayland change the mode? If not, what's the
> > benefit of this?  
> 
> Yeah, sorry, I didn't give all the details on why this RFC patch, my bad.
> 
> Basically, in downstream RH bug 1289714 [1], Robert Mader (cc'ed) is
> running some proof of concept to see how he can improve the support
> for older games in Xwayland.

Ooh, exciting! I had a quick glimpse through the thread.

> So this patch here is mostly a follow-up on my comment 15 in that bug
> [2], where I was arguing that Xwayland should not add fake modes by
> itself but use whatever the Wayland compositor advertises.

Right, however, I would ask this: if Xwayland will not be able to
actually set the modes, does it make a difference if the modes listed
are real or artificial?

I'm more curious than trying to argue against the patch, mind.

> > My naive guess is that if apps or users don't see multiple modes in
> > the list, they are less likely to attempt to change it via RandR.  
> 
> No, I don't plan to let users change the modes via xrandr, but from
> bug 1289714 it seems that listing available modes helps some games
> (not sure why, I don't play games), even though input transformation
> is broken.

Does it actually break the input transformation? Well, depends on how
you handle the RandR mode change, I suppose.

> There is a lot more for this, this patch here is just a first (small)
> step (thus the RFC) to use the available modes listed by the Wayland
> compositor rather than faking arbitrary modes in Xwayland, and since
> I didn't reckon this patch would break anything, I posted that to the
> ML for more feedback.

Yes, letting Xwayland pretend successful mode switches is an
interesting topic.

I saw the input transformation fixup patch that seems special-case the
fullscreen window. If there is a X11 window on top of the fullscreen
window, that would still get wrong input coordinates, would it not?

An idea comes to mind: what if you'd make RandR mode changes change the
scaling of *all* Xwayland wl_surfaces?

Say, xwl_screen size is 1600x1200, RandR "sets" 800x600, and suddenly
all Xwayland wl_surfaces start using wp_viewport to set 2x up-scaling?
I.e. X11 window size that is 800x600 will produce a 800x600 wl_buffer,
but wp_viewport makes the wl_surface 1600x1200. I think visually that
should match pretty close what an actual mode change would have done,
for all X11 windows on the Wayland desktop.

Obviously now X11 and Wayland windows are at different scale, but since
for X11 the scaling by video mode is global (per Xwayland instance)
anyway, it kind of... fits?

To a Wayland compositor this would look like a small buffer upscaled to
fill the screen, which, if implemented in a compositor, could even
trigger a real video mode switch automatically based on which window is
active and on top.

Fixing up the input should be a little easier I imagine, because all
X11 windows have the same scaling factor, which means the X11
coordinate space can stay consistent for all X11 objects... right?

One thing I didn't think is how the XWM could cope with this scaling,
does it mess up some window relative to window positioning.

Crazy? I'll let you decide. :-)

> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1289714
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1289714#c15


Thanks,
pq


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

Re: [PATCH RFC xserver] xwayland: List all wl_output::mode(s) in xrandr

[Pekka Paalanen]

On Thu, 30 Nov 2017 04:14:08 -0500 (EST)
Olivier Fourdan  wrote:

> Hi Pekka,
> 
> > > [...]
> > > 
> > > Basically, in downstream RH bug 1289714 [1], Robert Mader (cc'ed) is
> > > running some proof of concept to see how he can improve the support
> > > for older games in Xwayland.  
> > 
> > Ooh, exciting! I had a quick glimpse through the thread.
> >   
> > > So this patch here is mostly a follow-up on my comment 15 in that bug
> > > [2], where I was arguing that Xwayland should not add fake modes by
> > > itself but use whatever the Wayland compositor advertises.  
> > 
> > Right, however, I would ask this: if Xwayland will not be able to
> > actually set the modes, does it make a difference if the modes
> > listed are real or artificial?  
> 
> No difference, I reckon, fake or real doesn't matter, but I'd rather
> let the compositor decide.

That's a reasonable justification.

> My point being solely that Xwayland should not decide to come up with
> and force fake modes all by itself if the compositor doesn't know how
> to deal with those.

That somewhat depends on whether the compositor actually has to deal
with anything. But, getting the mode list from the compositor is safer.

If a game needs a specific mode, the Wayland compositor should arrange
it.

> > I'm more curious than trying to argue against the patch, mind.
> >   
> > > > My naive guess is that if apps or users don't see multiple
> > > > modes in the list, they are less likely to attempt to change it
> > > > via RandR.  
> > > 
> > > No, I don't plan to let users change the modes via xrandr, but
> > > from bug 1289714 it seems that listing available modes helps some
> > > games (not sure why, I don't play games), even though input
> > > transformation is broken.  
> > 
> > Does it actually break the input transformation? Well, depends on
> > how you handle the RandR mode change, I suppose.
> >   
> > > There is a lot more for this, this patch here is just a first
> > > (small) step (thus the RFC) to use the available modes listed by
> > > the Wayland compositor rather than faking arbitrary modes in
> > > Xwayland, and since I didn't reckon this patch would break
> > > anything, I posted that to the ML for more feedback.  
> > 
> > Yes, letting Xwayland pretend successful mode switches is an
> > interesting topic.
> > 
> > I saw the input transformation fixup patch that seems special-case
> > the fullscreen window. If there is a X11 window on top of the
> > fullscreen window, that would still get wrong input coordinates,
> > would it not?  
> 
> Yeah that's one of the corner case, I'm sure there are a lot more.

Just asked this in IRC as well: why is the input fixup patch to
Xwayland necessary at all?

If mutter decides to scale up something on its own, it should not
change how the Wayland client sees input, because input is defined in
surface-local coordinates. Is it a mutter bug?

> > An idea comes to mind: what if you'd make RandR mode changes change
> > the scaling of *all* Xwayland wl_surfaces?
> > 
> > Say, xwl_screen size is 1600x1200, RandR "sets" 800x600, and
> > suddenly all Xwayland wl_surfaces start using wp_viewport to set 2x
> > up-scaling? I.e. X11 window size that is 800x600 will produce a
> > 800x600 wl_buffer, but wp_viewport makes the wl_surface 1600x1200.
> > I think visually that should match pretty close what an actual mode
> > change would have done, for all X11 windows on the Wayland desktop.
> > 
> > Obviously now X11 and Wayland windows are at different scale, but
> > since for X11 the scaling by video mode is global (per Xwayland
> > instance) anyway, it kind of... fits?  
> 
> Now, I think this is a very interesting idea, also because randr
> isn't per client, even less per window (thus matching a surface to
> the X11 client issuing the randr request might not be trivial in
> xwl_randr_set_config()).
> 
> So making the scaling global would solve that problem.

While having lunch, I remembered something that makes it non-ideal:
there can be multiple RandR outputs, but the mode switch is per RandR
output, not global.


Thanks,
pq


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

Re: [systemd-devel] [PATCH weston] doc/systemd: system service example

[Pekka Paalanen]

On Wed, 29 Nov 2017 19:05:07 +0100
Lennart Poettering  wrote:

> On Di, 28.11.17 12:14, Pekka Paalanen (ppaala...@gmail.com) wrote:
> 
> > +
> > +[Unit]
> > +Description=Weston, a Wayland compositor, as a system service
> > +Documentation=man:weston(1) man:weston.ini(5)
> > +Documentation=http://wayland.freedesktop.org/
> > +
> > +# Make sure we are started after logins are permitted.
> > +After=systemd-user-sessions.service
> > +
> > +# If Plymouth is used, we want to start when it is on its way out.
> > +After=plymouth-quit-wait.service
> > +
> > +# D-Bus is necessary for contacting logind. Logind is required.
> > +Wants=dbus.socket
> > +After=dbus.socket
> > +
> > +# This scope is created by pam_systemd when logging in as the user.
> > +# This directive is a workaround to a systemd bug, where the setup of the
> > +# user session by PAM has some race condition, possibly leading to a 
> > failure.
> > +# See README for more details.
> > +After=session-c1.scope  
> 
> Hmm, what is this about?
> 
> This is racy, as the session ID is not really reliably predictable,
> and is synthesized in different contexts in different ways, for
> example depnding on whether audit is enabled in the kernel it might be
> session-1.scope rather than session-c1.scope.

Hi Lennart,

this is the bit Martyn talked you in person some time ago, maybe Martyn
could refresh your memory?

Yes, I am definitely not happy about this directive, but it serves as
the reminder of the issue Martyn was debugging a long time ago, and
this was the workaround chosen for the particular project at that time.
I guessed it's not portable.

I have it here so it would trigger the discussion, in the hopes that
someone could recall the details of the fundamental problem. I heard it
was deemed to be a hard-to-reproduce systemd bug, but I have no other
details.

If we could determine the bug doesn't exist anymore, that would be
awesome and I could just drop this.

> > +# Set up a full user session for the user, required by Weston.
> > +PAMName=login  
> 
> Piggy-backing on "login" is a bad idea. "login" is a text tool, and
> thus the PAM rules for it usually pull in some TTY specific PAM
> modules. YOu shoudl really use your own PAM fragment here, and
> configure only the bits you need.

Ok. Is there any guide or example I could point people to, so that they
can write their own stuff correctly? Any example I could put into
Weston docs?

Personally I have no understanding of what PAM does. I just copied
weston-launch (setuid-root helper for non-systemd systems) that also
uses "login" for PAM name if it was asked to create a new session(?).


Thanks,
pq


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

Re: [systemd-devel] [PATCH weston] doc/systemd: system service example

[Pekka Paalanen]

On Thu, 30 Nov 2017 13:29:22 +0100
Lennart Poettering  wrote:

> On Do, 30.11.17 12:09, Pekka Paalanen (ppaala...@gmail.com) wrote:
> 
> > > Hmm, what is this about?
> > > 
> > > This is racy, as the session ID is not really reliably predictable,
> > > and is synthesized in different contexts in different ways, for
> > > example depnding on whether audit is enabled in the kernel it might be
> > > session-1.scope rather than session-c1.scope.  
> > 
> > Hi Lennart,
> > 
> > this is the bit Martyn talked you in person some time ago, maybe Martyn
> > could refresh your memory?  
> 
> Oh, did we? I don't remember, sorry!

Hi Lennart,

no worries. I don't remember what I did early this week...

> > > Piggy-backing on "login" is a bad idea. "login" is a text tool, and
> > > thus the PAM rules for it usually pull in some TTY specific PAM
> > > modules. YOu shoudl really use your own PAM fragment here, and
> > > configure only the bits you need.  
> > 
> > Ok. Is there any guide or example I could point people to, so that they
> > can write their own stuff correctly? Any example I could put into
> > Weston docs?  
> 
> Unfortunately PAM is awful and highly distro-specific. It's not really
> possible to write PAM snippets that work generically on all
> distros. Sorry. The distros even patch PAM differently, so that
> slightly difference constructs are available...

That's the feeling I already got. Following Mantas' suggestion and
commenting it line by line like I did for the service unit is probably
the best we could do then.


Thanks,
pq


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

Re: [PATCH weston 2/2] clients/editor: Toggle panel visibility on click

[Pekka Paalanen]

On Mon, 27 Nov 2017 10:32:01 -0600
Joshua Watt  wrote:

> On Sat, 2017-06-24 at 16:03 -0500, Joshua Watt wrote:
> > If the --click-to-show option is specified, clicking an input field
> > will toggle
> > the input panel visiblity
> > 
> > Signed-off-by: Joshua Watt 
> > ---
> >  clients/editor.c | 13 +++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)

> 
> Could someone please Ack and commit this (or give more feedback)?

Hi,

sorry for the delay, both patches are pushed:
   68f8e47a..8093fd5d  master -> master


Thanks,
pq


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

Re: [systemd-devel] [PATCH weston] doc/systemd: system service example

[Pekka Paalanen]

On Thu, 30 Nov 2017 11:16:19 +
Martyn Welch  wrote:

> On Thu, 2017-11-30 at 12:09 +0200, Pekka Paalanen wrote:
> > On Wed, 29 Nov 2017 19:05:07 +0100
> > Lennart Poettering  wrote:
> >   
> > > On Di, 28.11.17 12:14, Pekka Paalanen (ppaala...@gmail.com) wrote:
> > >   
> > > > +
> > > > +[Unit]
> > > > +Description=Weston, a Wayland compositor, as a system service
> > > > +Documentation=man:weston(1) man:weston.ini(5)
> > > > +Documentation=http://wayland.freedesktop.org/
> > > > +
> > > > +# Make sure we are started after logins are permitted.
> > > > +After=systemd-user-sessions.service
> > > > +
> > > > +# If Plymouth is used, we want to start when it is on its way out.
> > > > +After=plymouth-quit-wait.service
> > > > +
> > > > +# D-Bus is necessary for contacting logind. Logind is required.
> > > > +Wants=dbus.socket
> > > > +After=dbus.socket
> > > > +
> > > > +# This scope is created by pam_systemd when logging in as the user.
> > > > +# This directive is a workaround to a systemd bug, where the setup of 
> > > > the
> > > > +# user session by PAM has some race condition, possibly leading to a 
> > > > failure.
> > > > +# See README for more details.
> > > > +After=session-c1.scope
> > > 
> > > Hmm, what is this about?
> > > 
> > > This is racy, as the session ID is not really reliably predictable,
> > > and is synthesized in different contexts in different ways, for
> > > example depnding on whether audit is enabled in the kernel it might be
> > > session-1.scope rather than session-c1.scope.  

> > If we could determine the bug doesn't exist anymore, that would be
> > awesome and I could just drop this.

Hi Lennart,

taking a step back, the session-c1.scope directive is definitely not
wanted and we should drop it. We should also use a custom PAM name
setup. If we do that, is the service file otherwise good for
guaranteeing:

- a full user session setup (I presume we want it), specifically
  XDG_RUNTIME_DIR being set up

- running exclusively on a VT that is made current

- access to DRM and input devices via logind

so that all these are already in place by the time the Weston process
is started?

As you can see from Martyn below, the first issue that prevented Weston
from running was that XDG_RUNTIME_DIR was not set. Furthermore, this
failure did not occur always, sometimes things just worked as we
expected.

> 
> First off, apologies if I explained this badly when I attempted to
> explain the issue at FOSDEM, I'm still not convinced I truly understand
> what's happening here, but let's give it another go...
> 
> Testing of the product in the project mentioned by Pekka revealed that
> we would sometimes see Weston fail to boot. IIRC, in the order of 2 in
> 10 times when switching from an initial charging state (that the device
> would boot into when power was applied to the device without the power
> button being pressed) and the normal running state (when the power
> button was then pressed). The charging state is pretty much a small
> subset of the normal running state. From memory, the "xuser" session is
> not created in that state. The filtered logs that I was given:
> 
> 2017-01-05T14:08:19.41+00:00 XXX systemd-logind[315]: New seat
> seat0.
> 2017-01-05T14:08:19.672756+00:00 XXX systemd-logind[315]: Watching
> system buttons on /dev/input/event0 (power-gpio-keys)
> 2017-01-05T14:08:20.176354+00:00 XXX systemd[1]: Starting User Manager
> for UID 1000...
> 2017-01-05T14:08:20.394955+00:00 XXX systemd[1]: Starting Weston...
> 2017-01-05T14:08:21.867999+00:00 XXX systemd-logind[315]: New session c1
> of user xuser.
> 2017-01-05T14:08:21.915400+00:00 XXX systemd-logind[315]: Watching
> system buttons on /dev/input/event0 (power-gpio-keys)
> 2017-01-05T14:08:46.279480+00:00 XXX weston[403]: [14:08:46.157] fatal:
> environment variable XDG_RUNTIME_DIR is not set.
> 2017-01-05T14:08:46.421821+00:00 XXX systemd[1]: Failed to start Weston.
> 2017-01-05T14:08:46.471701+00:00 XXX systemd-logind[315]: Removed
> session c1.
> 2017-01-05T14:08:47.424030+00:00 XXX systemd[1]: Started User Manager
> for UID 1000.
> 2017-01-05T14:08:47.469949+00:00 XXX systemd-logind[315]: Failed to stop
> user service: Transaction is destructive.
> 2017-01-05T14:08:47.540518+00:00 XXX systemd-logind[315]: Failed to stop
> user slice: Transaction is destructive.
> 
> Debugging suggested that XDG_RUNTIME_DIR was not being created when it
> failed. There are 2 processes setting a PAM

Re: [PATCH wayland] connection: Print the content of arrays in closures

[Pekka Paalanen]

On Fri, 1 Dec 2017 17:08:15 +
Daniel Stone  wrote:

> Hi,
> 
> On 10 July 2017 at 19:28, Emmanuel Gil Peyrot
>  wrote:
> > The current behaviour when WAYLAND_DEBUG is set is to print “array”,
> > which is quite unhelpful.
> >
> > This patch prints a list of the bytes present in the array.  It doesn’t
> > try to interpret it as uint32_t or anything, leaving that to the reader
> > because this information isn’t present in the protocol description.  
> 
> To be honest, I'm not really wild about this one. All the array users
> I know of (key/button, xdg surface states) are uint32_t. I'd prefer to
> add a pretty-printing hint to the protocol - this could specify how to
> interpret arrays, and also scratch my long-standing itch of printing
> uints with %x rather than %u when it makes sense to ...

Hi,

just a side note, if you start working on that, do also think of
bindings for (strongly) typed languages. ISTR requests to add type
information so that better bindings could be generated, and the
problem was where to stop defining the type system. I'm pretty sure if
printing hints are added, people will use them for bindings, whether we
wanted or not.


Thanks,
pq


pgpsDmJfJbwAS.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] protocol: Add deprecation note about wl_shell

[Pekka Paalanen]

On Sat,  2 Dec 2017 10:57:45 +0800
Jonas Ådahl  wrote:

> Now that xdg_shell is stable and much better defined than wl_shell we
> can finally deprecate wl_shell and guide users towards xdg_shell
> instead.
> 
> Signed-off-by: Jonas Ådahl 
> ---

Hi,

Acked-by: Pekka Paalanen 

> 
> Eventually we can consider adding deprecation attributes the
>  XML nodes that'll turn into compiler warnings, but this is
> at least a start moving away from wl_shell. I imagine the wl_shell users
> today (SDL, GLFW at least) to hopefully migrate soon, but keep the
> wl_shell as a fallback for the time being while compositors add support
> for xdg_shell. So we probably don't want to add compiler warnings for
> them just yet.

I would imagine compositors wanting to keep the support for a long
time, so maybe the warnings would be just in the client header?

OTOH, ISTR problems with having deprecation warnings in
system-installed headers, compilers ignoring them...


Thanks,
pq


>  protocol/wayland.xml | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index aabc7ae..77d991e 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -976,6 +976,9 @@
>  
>It allows clients to associate a wl_shell_surface with
>a basic surface.
> +
> +  Note! This protocol is deprecated and not intended for production use.
> +  For desktop-style user interfaces, use xdg_shell.
>  
>  
>  



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

Re: Can I copy-paste Wayland generated header in my own library header?

[Pekka Paalanen]

On Sat, 02 Dec 2017 09:39:33 -0500
ferreiradaselva  wrote:

> Good morning.
> 
> I'm writing a cross-platform window framework, like GLFW, but
> containing only two files (a source and a header).
> 
> I would like to copy and paste the content of the xdg-shell.h
> generated with wayland-scanner into my header (swfw.h), between
> #ifdef/#endif, so if the user compiles for Wayland, the user won't
> need to generate the xdg-shell.h.
> 
> My framework is under ZLIB, and Wayland is under MIT. I would like to
> know from the team: does it affect the license of my framework by
> copying and pasting the header to make my lib easier to use? And, if
> does, any recommendations about what to do?
> 
> This is sort of how it would look like:
> 
> #ifndef MY_LIB
> #define MY_LIB
> 
> #ifdef USE_WAYLAND_BACKEND
> /* The whole xdg-shell.h header is pasted here */
> 
> struct window {
> struct wl_surface *surface;
> struct wl_buffer *buffer;
> ...
> };
> 
> struct context {
> struct wl_display *display;
> struct wl_compositor *compositor;
> struct wl_seat *seat;
> struct wl_pointer *pointer;
> struct wl_keyboard *keyboard;
> ...
> };
> #endif /* USE_WAYLAND_BACKEND */
> 
> /* Other backends */
> 
> #endif /* MY_LIB */

Hi,

first, IANAL, of course.

The copyrights header you get in the generated headers and code comes
from the XML files. It is the license of the XML protocol
specification. I'm not sure if it applies to the generated code or not,
I'd like to think it does, but I don't see much difference given how
they are meant to be used.

Personally I would have no problem whatsoever for you to do what you
want. Also the MIT license is very liberal, and you might want to read
the dissection here:
https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html

I would add annotations in your files to clearly document which parts
are verbatim/modified copies of the generated stuff, and from where and
how they were generated - perhaps generating and piecing together the
files could be part of your project's build from source even if your
distributables are just more source. I would also keep the (generated)
license blurbs with notes on which part of the file they apply to.

I don't know ZLIB license, or why you picked that instead of MIT, for
instance.

Since the whole purpose of wayland-protocols is that you take the XML
file, run it through wayland-scanner, and include the compiled product
of that in your program binaries, there is no intention to change or
affect *your* license. Even totally closed source proprietary programs
are just fine using anything generated by wayland-scanner from
wayland-protocols.

I also see no reason to even attempt to forbid e.g. modifications to
the generated code or even the XML itself.

---

Mind, that while libwayland-client tries hard to maintain backwards
compatiblity, it is not guaranteeing forward compatibility. Code
generated with a newer wayland-scanner may not work with an older
libwayland-client. This has been necessary to fix bugs.

We encourage all projects to run wayland-scanner as part of their build
and match the wayland-scanner with the libwayland version they require
minimum, instead of storing the generated code in VCS. That way
distributions can choose a more recent libwayland minimum version with
any bug fixes in the generated code.


Thanks,
pq


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

Re: Can I copy-paste Wayland generated header in my own library header?

[Pekka Paalanen]

On Mon, 04 Dec 2017 05:59:02 -0500
ferreiradaselva  wrote:

> >From: ppaala...@gmail.com
> >To: ferreiradaselva 
> >
> > Hi,
> >
> > first, IANAL, of course.

> > I don't know ZLIB license, or why you picked that instead of MIT, for
> > instance.
> >
> > Since the whole purpose of wayland-protocols is that you take the XML
> > file, run it through wayland-scanner, and include the compiled product
> > of that in your program binaries, there is no intention to change or
> > affect your license. Even totally closed source proprietary programs
> > are just fine using anything generated by wayland-scanner from
> > wayland-protocols.
> >
> > I also see no reason to even attempt to forbid e.g. modifications to
> > the generated code or even the XML itself.  
> 
> 
> Both ZLIB and MIT are very similar, and with similar popularity, the
> difference is that ZLIB is a bit more clear, and more permissive,
> since it doesn't state that "The above copyright notice and this
> permission notice shall be included in all copies or substantial
> portions of the Software." This statement in MIT mean that a user
> making an application must state somewhere that they are using such
> library under MIT. I already state in repository that Wayland is
> used, but the end-user *likely* won't do that (for whatever reason).
> Does the Wayland development community feel like that's a problem?

In my personal opinion, it is not a problem in this case.


Thanks,
pq


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

Re: [systemd-devel] [PATCH weston] doc/systemd: system service example

[Pekka Paalanen]

On Fri, 1 Dec 2017 18:25:35 +0100
Lennart Poettering  wrote:

> On Fr, 01.12.17 13:42, Pekka Paalanen (ppaala...@gmail.com) wrote:
> 
> > > > > This is racy, as the session ID is not really reliably predictable,
> > > > > and is synthesized in different contexts in different ways, for
> > > > > example depnding on whether audit is enabled in the kernel it might be
> > > > > session-1.scope rather than session-c1.scope.
> >   
> > > > If we could determine the bug doesn't exist anymore, that would be
> > > > awesome and I could just drop this.  
> > 
> > Hi Lennart,
> > 
> > taking a step back, the session-c1.scope directive is definitely not
> > wanted and we should drop it. We should also use a custom PAM name
> > setup. If we do that, is the service file otherwise good for
> > guaranteeing:
> > 
> > - a full user session setup (I presume we want it), specifically
> >   XDG_RUNTIME_DIR being set up
> > 
> > - running exclusively on a VT that is made current  
> 
> This really depends on how weston sets up a VT. I really don't know
> Weston and what it does. 

Weston doesn't set up the VT, we rely on the systemd unit directives to
set it up.

Weston calls sd_pid_get_session(getpid()), sd_session_get_seat(), and wants
sd_session_get_vt() to succeed and give a VT number. Then it connects
to logind, wants TakeControl to succeed, and calls Activate. It uses
TakeDevice to open the DRM KMS device and input devices. I think that's
the start-up sequence, it also listens on signals from logind etc.

> > - access to DRM and input devices via logind  
> 
> So, I can't comment on Weston really.

No worries, that was more of a general question about whether the
example unit file was making any unwarranted assumptions.

> Here are brief (and possibly slightly out-of-date, but probably not)
> notes on how to write display managers with logind:
> 
> https://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/

Thanks, I had a quick read through. We expect the systemd unit to also
set up PAM, Weston itself does not touch PAM.

> > so that all these are already in place by the time the Weston process
> > is started?
> > 
> > As you can see from Martyn below, the first issue that prevented Weston
> > from running was that XDG_RUNTIME_DIR was not set. Furthermore, this
> > failure did not occur always, sometimes things just worked as we
> > expected.  
> 
> So, as long as weston runs from a PAM enabled service (and its PAM
> snippet pulls in pam_systemd) all should be good and race-free: as the
> PAM session is set up XDG_RUNTIME_DIR will be made available and the
> systemd --user instance is invoked in the background.

This is exactly what we attempted with the User and PAMName directive,
and it turned out to be racy somehow.

> What currently is not supported is to run things independently of any
> session, i.e. run weston as systemd --user service with nothing that
> creates a session in the first place. In that case XDG_RUNTIME_DIR
> will not be set up, and no devices are made available to weston...

Weston never was a --user service.

As far as I know, there was also nothing that would manually attempt to
start user@.service, the only trigger for that were the User and PAMName
directives in the system weston.service.

> > > > > > +# Set up a full user session for the user, required by Weston.
> > > > > > +PAMName=login  
> > > > > 
> > > > > Piggy-backing on "login" is a bad idea. "login" is a text tool, and
> > > > > thus the PAM rules for it usually pull in some TTY specific PAM
> > > > > modules. YOu shoudl really use your own PAM fragment here, and
> > > > > configure only the bits you need.
> > > > 
> > > 
> > > Oh, so could it just be that we needed something other than
> > > "PAMName=login"?  
> > 
> > What are they key bits in the PAM configuration we must have, and are
> > there any often used bits we must not have to avoid the race Martyn
> > describes?  
> 
> well, pam_systemd needs to be pulled in from it, that's the most
> important thing. A PAM snippet that pulls in pam_systemd means you get
> a session allcoated in logind, which in turn sets up XDG_RUNTIME_DIR
> for you.

Yes, it was, but apparently somewhere in the PAM stack or something it
calls there was a race, which sometimes let Weston to start before
XDG_RUNTIME_DIR environment variable was set, causing weston to fail.

We all here were quite baffled on what could even be racing, unless it
is p

Re: Wayland talk at FOSDEM

[Pekka Paalanen]

On Tue, 05 Dec 2017 16:46:41 +0200
Philipp Kerling  wrote:

> Hey everyone,
> 
> I've been thinking about submitting a Wayland-themed talk to the FOSDEM
> graphics devroom [1] and wanted to check with the community if anyone
> else has considered this or another Wayland topic and whether you think
> it would be a good idea™.
> 
> What I would want to talk about is a beginner's introduction to Wayland
> from the client perspective. I think that resources on this (and on
> Wayland in general to be honest) are quite scarce and that I could pass
> on some of the knowledge I have gained by implementing native Wayland
> support in Kodi this way.

Hi,

that sounds like a good idea.

> This would include stuff such as:
>  * Wayland architecture
> * Comparison with X
> * Security architecture
> * Limitations: What is not possible with Wayland (currently)

Please underline that many things are wanted and the only reason they
are not there yet is because they have not been worked on enough to
produce a Waylandish solution and reach a concensus, not because they
are somehow "banned". :-)

In some cases, the Waylandish solution to produce an end-user feature
may be very different from what has traditionally been done. In some
other cases, a solution might be better or already exist outside of
Wayland.

> * Difference between core and extension protocols

This is a bit hazy to me as well, depending on at what level you are
looking to use Wayland. Only wl_display, wl_registry and wl_callback
interfaces are not extensions, strictly speaking. What extensions are
mandatory depends on the target environment. Technically, e.g.
wl_compositor is an extension and not mandatory, but it's hard to find
a use case without it.

So it kind of depends on your definition of "Wayland". Purely IPC? A
graphical output protocol? A windowing protocol with input? A desktop
window system protocol?

Maybe giving a definition for "Wayland" would be a good way to start?

> * Global registry
> * Relevant documentation and resources
>  * Why you should not be writing a Wayland client yourself (aka use
>toolkits if possible)

+1

>  * Relevant compositors to test on and how to use nested mode
>  * Basic client programming
> * Protocols needed to get a surface on screen (wl_compositor,
>   wl_surface, wl_shm, wl_shm_pool, wl_shell, wl_shell_surface)

Mind that wl_shell is finally officially deprecated with the
stabilization of xdg-shell.

> * Seats and input
>* Keyboard: wl_keyboard and libxkbcommon
>* Mouse: wl_pointer and libwayland-cursor for cursor handling
> * xdg_wm_base
> * Window decorations
> * EGL
> 
> Possible extensions/replacement topics:
>  * Bindings (just mention: C++, D, Java, Rust)
>  * Vulkan (I think EGL is more relevant at the moment)
>  * Some more extension protocols such as pointer-constraints and
>relative-pointer (relevant e.g. for games)
>  * Subcompositing
>  * ...
> 
> I would not include:
>  * Details of libwayland API (e.g. proxy wrappers)

I suppose one detail might be worth mentioning: client projects are
expected to run wayland-scanner (or equivalent) as part of their
builds. The only exception are the interfaces in wayland.xml, but
it may be a surprise to realize that wayland.xml is the exception, not
the rule.

>  * Every extension protocol or even core protocol object just for
>completeness
>  * Historical baggage such as xdg_shell v5
>  * EGL/Mesa internals
> 
> I'd love to hear any comments/suggestions you might have and generally
> what kind of topics people would be interested in.
> 
> [1] 
> https://lists.freedesktop.org/archives/wayland-devel/2017-November/035880.html


Thanks,
pq


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

Re: Making weston (or maybe libinput) ignore an input device

[Pekka Paalanen]

On Tue, 5 Dec 2017 13:57:39 -0600
Matt Hoosier  wrote:

> Hi all,
> 
> The thing I'd like to arrange is for a device which is otherwise a
> valid keyboard, not to get automatically vacuumed up into the Weston
> DRM backend's usage of libinput.
> 
> Nowadays, Weston has delegated most of its former firsthand extraction
> of UDev properties to libinput. Nothing exists (that I found) in
> Weston's immediate sources to cause an input device reported through
> the libinput UDev seats to be ignored. I also had a quick stroll
> through libinput to look for some kind of sensitivity to a UDev
> property with that effect, but didn't spot anything likely.
> 
> Is there a best way to do this? The best thing I could think of was to
> try to add a late-running UDev rule that subtracts out the
> ID_INPUT_KEYBOARD=1 property, so that libinput won't know what to do
> with the device. But that seems like a fragile solution -- some
> package unknown to me could come along and install an even-later
> running rule that messages that arrangement up.

Hi Matt,

you could try assigning that device to a different physical seat with
the ID_SEAT property:
https://wayland.freedesktop.org/libinput/doc/latest/udev_config.html

There is also LIBINPUT_IGNORE_DEVICE mentioned on that page.

Some talk about physical vs. logical (wl_seat) seats:
https://wayland.freedesktop.org/libinput/doc/latest/seats.html

A compositor usually handles only one physical seat, and Weston in
particular does so.


Thanks,
pq


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

Re: Wayland talk at FOSDEM

[Pekka Paalanen]

On Thu, 07 Dec 2017 23:56:49 +0200
Philipp Kerling  wrote:

> Hi Pekka,
> 
> 2017-12-07 (木) の 09:56 +0200 に Pekka Paalanen さんは書きました:
> > On Tue, 05 Dec 2017 16:46:41 +0200
> > Philipp Kerling  wrote:
> >   
> > > Hey everyone,
> > > 
> > > I've been thinking about submitting a Wayland-themed talk to the
> > > FOSDEM
> > > graphics devroom [1] and wanted to check with the community if
> > > anyone
> > > else has considered this or another Wayland topic and whether you
> > > think
> > > it would be a good idea™.
> > > 
> > > What I would want to talk about is a beginner's introduction to
> > > Wayland
> > > from the client perspective. I think that resources on this (and on
> > > Wayland in general to be honest) are quite scarce and that I could
> > > pass
> > > on some of the knowledge I have gained by implementing native
> > > Wayland
> > > support in Kodi this way.  
> > 
> > Hi,
> > 
> > that sounds like a good idea.  
> Thanks!
> 
> >   
> > > This would include stuff such as:
> > >  * Wayland architecture
> > > * Comparison with X
> > > * Security architecture
> > > * Limitations: What is not possible with Wayland (currently)  
> > 
> > Please underline that many things are wanted and the only reason they
> > are not there yet is because they have not been worked on enough to
> > produce a Waylandish solution and reach a concensus, not because they
> > are somehow "banned". :-)  
> Good point since you hear from time to time that Wayland "forbids"
> this-and-that and therefore is evil ... I'll definitely keep it in
> mind. Even so, I guess it is a quite safe bet to e.g. say that
> accessing the buffer contents of all other applications without any
> user authentication will not be a feature of mainstream Wayland
> compositors anytime soon.

Hi Philipp

Yes. There are some more or less banned things, but I would tend to
think that they are a minority in numbers. "Without user permission" is
the main problem for most of the popular features that are not yet
standardised - the features are good, necessary and supportable, but
the main issue is how to expose them without compromising security and
without annoying users or asking users questions they cannot reliably
answer.

I believe it is actually quite likely that the solution to the
authentication problem is mostly outside of the scope of Wayland
protocol, but we would still need a working example in some environment
to be able to comfortably promote "privileged interfaces".

> > In some cases, the Waylandish solution to produce an end-user feature
> > may be very different from what has traditionally been done. In some
> > other cases, a solution might be better or already exist outside of
> > Wayland.  
> Yes, the problem lies mostly in the expectation that things will work
> just like they did with X.
> 
> >   
> > > * Difference between core and extension protocols  
> > 
> > This is a bit hazy to me as well, depending on at what level you are
> > looking to use Wayland. Only wl_display, wl_registry and wl_callback
> > interfaces are not extensions, strictly speaking. What extensions are
> > mandatory depends on the target environment. Technically, e.g.
> > wl_compositor is an extension and not mandatory, but it's hard to
> > find
> > a use case without it.  
> I'd have argued that the wayland.xml shipped with wayland is the "core"
> protocol and wayland-protocols + all other stuff are "extensions." Is
> that a reasonable assumption or should I be more careful about the
> wording here? In any case, I guess it makes sense to mention that
> Wayland is not only built for traditional desktop environments, even if
> that is what I'll be focusing on in the talk.

The split is not so clear. The most obvious example of the contrary is
wl_shell extension which is in wayland.xml, but is not considered
"core". E.g. IVI environment using Wayland does not use it.

wl_shell is a "shell extension", which is a category of Wayland
extensions. With Wayland core protocol and wl_compositor, you cannot
actually show a window. A shell extension is necessary to tell the
compositor what it should do with a wl_surface, i.e. assign the
wl_surface a role. Wayland.xml does have some interfaces which can be
considered core and assign surface roles, but they are not enough to
have a working application. An example of such role is the pointer
cursor.

The other global interfaces (advertised through wl_registry) in
wayland.xml are

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

[Pekka Paalanen]

On Mon, 27 Nov 2017 08:54:54 -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.
> 
> v4 changes:
> 
> * Improved internal comments and some boundary-condition
>   error checks in test case.
> * Refer to compositor as "Wayland server" rather than "Wayland
>   display" in wl_display_connect() doxygen comments.
> * Remove redundant descriptions of parameter-interpretation
>   mechanics from wl_display_connect() manpage. Reworked things
>   to make it clear that 'name' and $WAYLAND_DISLAY are each
>   capable of encoding absolute server socket paths.
> * Remove callout to reference implementation behavior in protocol
>   documented. In its place there is now a simple statement that
>   implementations can optionally support absolute socket paths.
> 
> 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 
> Acked-by: Pekka Paalanen 
> Acked-by: Jonas Ådahl 
> ---
>  doc/man/wl_display_connect.xml|  32 +--
>  doc/publican/sources/Protocol.xml |   5 +-
>  src/wayland-client.c  |  47 
>  tests/socket-test.c   | 109 
> ++
>  4 files changed, 177 insertions(+), 16 deletions(-)

Hi Matt,

this patch is:

Reviewed-by: Pekka Paalanen 

The wording in the man page sounds little like WAYLAND_DISPLAY
accepting an absolute path is a side-effect rather than an intentional
feature, but it doesn't matter.

Everyone,

if there are no objections, I will push this patch on Wednesday, that
is in two days. If you want your R-b or Acks recorded that are not
already in the above, please send them explicitly.


Thanks,
pq

> 
> diff --git a/doc/man/wl_display_connect.xml b/doc/man/wl_display_connect.xml
> index 7e6e05c..dab4ddb 100644
> --- a/doc/man/wl_display_connect.xml
> +++ b/doc/man/wl_display_connect.xml
> @@ -55,15 +55,39 @@
>  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 when 
> WAYLAND_DISPLAY
> +   (or name, see below) is a simple name, for this
> +   function to find it. The server socket is also allowed to exist at an
> +   arbitrary path; usage details follow. See below for compatibility 
> issue
> +   details.
> +
> +The name argument specifies the name of
>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
> +  WAYLAND_DISPLAY replaces the default value.
> +
> +   If name is an absolute path, then that path is used
> +   as the Wayland socket to which the connection is attempted. Note that
> +   in combination with the default-value behavior described above, this
> +   implies that setting WAYLAND_DISPLAY to an absolute
> +   path will implicitly cause name to take on that
> +   absolute path if name is NULL.
> +
> +  If WAYLAND_SOCKET is set, this function behaves like
>wl_display_connect_to_fd with the 
> file-descriptor
>number taken from the environment variable

Re: [PATCH wayland-protocols] unstable: Add input-timestamps protocol

[Pekka Paalanen]

On Tue, 5 Dec 2017 18:20:35 +0200
Alexandros Frantzis  wrote:

> On Tue, Dec 05, 2017 at 06:07:02PM +0200, Alexandros Frantzis wrote:
> > wl_pointer, wl_keyboard and wl_touch events currently use a 32-bit
> > timestamp with millisecond resolution. In some cases, notably latency
> > measurements, this resolution is too coarse to be useful.
> > 
> > This protocol provides additional high-resolution timestamps events,
> > which are emitted before the corresponding input event. Each timestamp
> > event contains a high-resolution, and ideally higher-accuracy, version
> > of the 'time' argument of the first subsequent supported input event.
> > 
> > Clients that care about high-resolution timestamps just need to keep
> > track of the last timestamp event they receive and associate it with the
> > next supported input event that arrives.
> >   
> 
> Hi all,
> 
> a few additional discussion notes (some copied from the RFC discussion):
> 
> 1. Supported pointer/keyboard/touch events
> 
>At the moment the protocol is phrased to be forward-compatible with
>new pointer/keyboard/touch events. For example, for touch:
> 
>"represents a subscription to high-resolution timestamp events for
>for all wl_touch events that carry a timestamp."
> 
>This guards against making input-timestamps protocol updates for new
>input events (unless we add a new input category), and is easy to
>implement in practice.
> 
> 2. Timestamp accuracy guarantee
> 
>Currently: "The timestamp provided by this event ... is at least as
>accurate as the associated input event timestamp."
> 
>In a previous discussion it was suggested that an option would be for
>the server to advertise support for this protocol only if it can
>provide better (than millisecond) accuracy. My concern with such an
>approach is that there may be cases where only some input objects can
>provide high-accuracy timestamps, so the guarantee may not be
>globally applicable.

Hi Alf,

I think that would still fall under "can", which is different from
"guaranteed" better accuracy timestamp. But there is no need to discuss
this in the protocol spec at all. Each compositor can make its decision
whether to expose this extension or not.

Clients should not make any assumptions about the accuracy based on the
presence of the extension. That's the important bit.

> 3. Clocks domains
> 
>The high-resolution timestamps are guaranteed to be in the same clock
>domain as the input event timestamps (for which the clock domain is
>currently unspecified).
> 
> 4. Support for input events from unstable protocols (e.g. tablet)
>
>I opted not to include support for input events from unstable
>protocols. The rationale is that this protocol was created in order
>to fix the deficiencies (for certain use cases) of protocols that we
>are unable to change due to compatibility restrictions. Unstable
>protocols are not subject to such restrictions and can therefore be
>updated to use high-resolution timestamps instead of relying on an
>external protocol to provide such functionality.

A very good point.

> 5. Frame event timestamps
> 
>It was suggested that this protocol could provide timestamps for
>frame events which currently don't carry one in the core protocol. In
>this proposal I have chosen to maintain consistency with the way
>timestamps are emitted in the core protocol, i.e., emit timestamp
>events only for input events that already carry a timestamp. Adding a
>frame timestamp when one is not already present would also further
>complicate client implementations that need to support falling back
>to the normal timestamps when this protocol is not present.

I don't think the two are conflicting goals.

We could have the high precision timestamp event emitted at least (and
preferably only) once per each event sequence ending in a frame event
that contains at least one event that carries a low precision timestamp.

The diagonal scrolling was used as the (rare) example where an actual
reduction in the number of events could be seen. Currently the core
protocol provides a low precision timestamp redundantly multiple times
(two exis events) when one would be enough. By definition the
timestamps on the axis events are the same.

> A proof of concept implementation for weston can be found at:
> 
> https://gitlab.collabora.com/alf/weston/commits/zwp-input-timestamps


Thanks,
pq


pgpNkz4MMSyP9.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] unstable: Add input-timestamps protocol

[Pekka Paalanen]

ver that the client will no longer be using this
> +protocol object. Existing objects created by this object are not
> +affected.
> +  
> +
> +
> +
> +  
> +Creates a new input timestamps object that represents a subscription
> +to high-resolution timestamp events for all wl_keyboard events that
> +carry a timestamp.
> +
> +If the associated wl_keyboard object is invalidated, either through
> +client action (e.g. release) or server-side changes, the input
> +timestamps object becomes inert and the client should destroy it
> +by calling zwp_input_timestamps_v1.destroy.
> +  
> +  
> +   +   summary="the wl_keyboard object for which to get timestamp 
> events"/>
> +
> +
> +
> +  
> +Creates a new input timestamps object that represents a subscription
> +to high-resolution timestamp events for all wl_pointer events that
> +carry a timestamp.
> +
> +If the associated wl_pointer object is invalidated, either through
> +client action (e.g. release) or server-side changes, the input
> +timestamps object becomes inert and the client should destroy it
> +by calling zwp_input_timestamps_v1.destroy.
> +  
> +  
> +   +   summary="the wl_pointer object for which to get timestamp 
> events"/>
> +
> +
> +
> +  
> +Creates a new input timestamps object that represents a subscription
> +to high-resolution timestamp events for all wl_touch events that
> +carry a timestamp.
> +
> +If the associated wl_touch object becomes invalid, either through
> +client action (e.g. release) or server-side changes, the input
> +timestamps object becomes inert and the client should destroy it
> +by calling zwp_input_timestamps_v1.destroy.
> +  
> +  
> +   +   summary="the wl_touch object for which to get timestamp events"/>
> +
> +  
> +
> +  
> +
> +  Provides high-resolution timestamp events for a set of subscribed input
> +  events. The set of subscribed input events is determined by the
> +  zwp_input_timestamps_manager_v1 request used to create this object.
> +
> +
> +
> +  
> +Informs the server that the client will no longer be using this
> +protocol object. After the server processes the request, no more
> +timestamp events will be emitted.

This could be said simply:
"Cancel the subscription to the high-resolution timestamps."

It's fine either way.

> +  
> +
> +
> +
> +  
> +The timestamp event is associated with the first subsequent input 
> event

+ carrying a timestamp

> +which belongs to the set of input events this object is subscribed 
> to.

This is a bit hard to write down precisely. How about:

"The timestamp event is associated with the first subsequent input event
group (as defined in the respective input interface, e.g.
wl_pointer.frame) or single input event that already carries a
timestamp with less precision than this timestamp event."

I inferred from Peter's wording that we want to require a new event for
a new input event/group even if the timestamp would be the same.
Therefore "the first" and "single".

> +
> +The timestamp provided by this event is a high-resolution version of
> +    the timestamp argument of the associated input event. The provided

"..of the associated input event(s)." would perhaps cover the above
change in wording?

> +timestamp is in the same clock domain and is at least as accurate as
> +the associated input event timestamp.
> +  
> +   +   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"/>
> +
> +  
> +
> +

That wording in one paragraph is the only thing I could hook onto,
otherwise this looks excellent. You have:

Reviewed-by: Pekka Paalanen 

regardless of whether the changes I proposed are done or not. I wonder
what Peter would think of my wording.


Thanks,
pq


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

Re: [PATCH v2] configure.ac: use AC_HEADER_MAJOR to detect major()/minor()

[Pekka Paalanen]

On Wed, 31 May 2017 22:17:50 +0100
Sergei Trofimovich  wrote:

> This change slightly updates c4d7f66c12853b9575366dd9f4a7960ec5694934
> which added  inclusion.
> 
> Autoconf has AC_HEADER_MAJOR to find out which header defines
> reqiured macros:
> 
> https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Particular-Headers.html
> 
> This change should increase portability across other libcs.
> 
> Bug: https://bugs.gentoo.org/610652
> Signed-off-by: Sergei Trofimovich 
> ---
> Change since v1:
> - rebased on top of current master
> - dedented nested '#include'
>  configure.ac   | 1 +
>  libweston/launcher-direct.c| 9 -
>  libweston/launcher-logind.c| 9 -
>  libweston/launcher-weston-launch.c | 8 +++-
>  libweston/weston-launch.c  | 9 -
>  5 files changed, 32 insertions(+), 4 deletions(-)

Hi,

I'm on Gentoo with sys-libs/glibc-2.25-r9:2.2 and I am now getting a
bunch of warnings like this:

/home/pq/git/weston/libweston/weston-launch.c: In function ‘handle_open’:
/home/pq/git/weston/libweston/weston-launch.c:333:13: warning: In the GNU C 
Library, "major" is defined
 by . For historical compatibility, it is
 currently defined by  as well, but we plan to
 remove this soon. To use "major", include 
 directly. If you did not intend to use a system-defined macro
 "major", you should undefine it after including .
  if (major(s.st_rdev) != INPUT_MAJOR &&


Reverting this patch makes the warnings go away.

What's the right fix here?

In config.h I have:

/* Define to 1 if `major', `minor', and `makedev' are declared in .
   */
/* #undef MAJOR_IN_MKDEV */

/* Define to 1 if `major', `minor', and `makedev' are declared in
   . */
/* #undef MAJOR_IN_SYSMACROS */

I'm not sure what I needed to do get even that far, maybe wipe my
out-of-tree build dir. Even then, I cannot find any evidence of
configure actually running the tests. I always start a new build dir by
running autogen.sh.


Thanks,
pq

> 
> diff --git a/configure.ac b/configure.ac
> index db757f20..ff89c3a4 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -34,6 +34,7 @@ AC_CONFIG_MACRO_DIR([m4])
>  
>  AC_USE_SYSTEM_EXTENSIONS
>  AC_SYS_LARGEFILE
> +AC_HEADER_MAJOR
>  
>  AM_INIT_AUTOMAKE([1.11 parallel-tests foreign no-dist-gzip dist-xz 
> color-tests subdir-objects])
>  
> diff --git a/libweston/launcher-direct.c b/libweston/launcher-direct.c
> index a5d3ee53..b4ca609a 100644
> --- a/libweston/launcher-direct.c
> +++ b/libweston/launcher-direct.c
> @@ -33,7 +33,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -47,6 +46,14 @@
>  #define KDSKBMUTE0x4B51
>  #endif
>  
> +/* major()/minor() */
> +#ifdef MAJOR_IN_MKDEV
> +#include 
> +#endif
> +#ifdef MAJOR_IN_SYSMACROS
> +#include 
> +#endif
> +
>  #ifdef BUILD_DRM_COMPOSITOR
>  
>  #include 
> diff --git a/libweston/launcher-logind.c b/libweston/launcher-logind.c
> index f10a2831..3c23d000 100644
> --- a/libweston/launcher-logind.c
> +++ b/libweston/launcher-logind.c
> @@ -35,7 +35,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  
> @@ -45,6 +44,14 @@
>  
>  #define DRM_MAJOR 226
>  
> +/* major()/minor() */
> +#ifdef MAJOR_IN_MKDEV
> +#include 
> +#endif
> +#ifdef MAJOR_IN_SYSMACROS
> +#include 
> +#endif
> +
>  struct launcher_logind {
>   struct weston_launcher base;
>   struct weston_compositor *compositor;
> diff --git a/libweston/launcher-weston-launch.c 
> b/libweston/launcher-weston-launch.c
> index 97da18c5..3d3b4d2f 100644
> --- a/libweston/launcher-weston-launch.c
> +++ b/libweston/launcher-weston-launch.c
> @@ -34,7 +34,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -75,6 +74,13 @@ drmSetMaster(int drm_fd)
>  
>  #endif
>  
> +/* major()/minor() */
> +#ifdef MAJOR_IN_MKDEV
> +#include 
> +#endif
> +#ifdef MAJOR_IN_SYSMACROS
> +#include 
> +#endif
>  
>  union cmsg_data { unsigned char b[4]; int fd; };
>  
> diff --git a/libweston/weston-launch.c b/libweston/weston-launch.c
> index aa7e0711..a15f053e 100644
> --- a/libweston/weston-launch.c
> +++ b/libweston/weston-launch.c
> @@ -42,7 +42,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -93,6 +92,14 @@ drmSetMaster(int drm_fd)
>  
>  #endif
>  
> +/* major()/minor() */
> +#ifdef MAJOR_IN_MKDEV
> +#include 
> +#endif
> +#ifdef MAJOR_IN_SYSMACROS
> +#include 
> +#endif
> +
>  struct weston_launch {
>   struct pam_conv pc;
>   pam_handle_t *ph;



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

Re: [PATCH v2] configure.ac: use AC_HEADER_MAJOR to detect major()/minor()

[Pekka Paalanen]

On Mon, 11 Dec 2017 16:16:47 +0200
Pekka Paalanen  wrote:

> On Wed, 31 May 2017 22:17:50 +0100
> Sergei Trofimovich  wrote:
> 
> > This change slightly updates c4d7f66c12853b9575366dd9f4a7960ec5694934
> > which added  inclusion.
> > 
> > Autoconf has AC_HEADER_MAJOR to find out which header defines
> > reqiured macros:
> > 
> > https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Particular-Headers.html
> > 
> > This change should increase portability across other libcs.
> > 
> > Bug: https://bugs.gentoo.org/610652
> > Signed-off-by: Sergei Trofimovich 
> > ---
> > Change since v1:
> > - rebased on top of current master
> > - dedented nested '#include'
> >  configure.ac   | 1 +
> >  libweston/launcher-direct.c| 9 -
> >  libweston/launcher-logind.c| 9 -
> >  libweston/launcher-weston-launch.c | 8 +++-
> >  libweston/weston-launch.c  | 9 -
> >  5 files changed, 32 insertions(+), 4 deletions(-)  
> 
> Hi,
> 
> I'm on Gentoo with sys-libs/glibc-2.25-r9:2.2 and I am now getting a
> bunch of warnings like this:
> 
> /home/pq/git/weston/libweston/weston-launch.c: In function ‘handle_open’:
> /home/pq/git/weston/libweston/weston-launch.c:333:13: warning: In the GNU C 
> Library, "major" is defined
>  by . For historical compatibility, it is
>  currently defined by  as well, but we plan to
>  remove this soon. To use "major", include 
>  directly. If you did not intend to use a system-defined macro
>  "major", you should undefine it after including .
>   if (major(s.st_rdev) != INPUT_MAJOR &&
> 
> 
> Reverting this patch makes the warnings go away.
> 
> What's the right fix here?
> 
> In config.h I have:
> 
> /* Define to 1 if `major', `minor', and `makedev' are declared in .
>*/
> /* #undef MAJOR_IN_MKDEV */
> 
> /* Define to 1 if `major', `minor', and `makedev' are declared in
>. */
> /* #undef MAJOR_IN_SYSMACROS */
> 
> I'm not sure what I needed to do get even that far, maybe wipe my
> out-of-tree build dir. Even then, I cannot find any evidence of
> configure actually running the tests. I always start a new build dir by
> running autogen.sh.

Hi,

there is an email thread of the problem from a slightly different point
of view:
https://lists.gnu.org/archive/html/autoconf/2016-09/msg0.html

If we keep the code as is, the warning will not go away until glibc
actually drops the things from sys/types.h and distros ship it.
Apparently there is a workaround one could make with config.site:
https://lists.gnu.org/archive/html/autoconf/2016-09/msg00013.html

Or we could wait for a new autoconf release and require it, but the
discussion happened in 2016 and at least Gentoo does not have a
autoconf 2.70 yet. Or we could ship a fixed AC_HEADER_MAJOR.

Or we could just revert this patch until something in the above changes
or we have migrated to Meson.

Proposals?

The warnings are quite annoying. I would be for reverting the patch.


Thanks,
pq

> > 
> > diff --git a/configure.ac b/configure.ac
> > index db757f20..ff89c3a4 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -34,6 +34,7 @@ AC_CONFIG_MACRO_DIR([m4])
> >  
> >  AC_USE_SYSTEM_EXTENSIONS
> >  AC_SYS_LARGEFILE
> > +AC_HEADER_MAJOR
> >  
> >  AM_INIT_AUTOMAKE([1.11 parallel-tests foreign no-dist-gzip dist-xz 
> > color-tests subdir-objects])
> >  
> > diff --git a/libweston/launcher-direct.c b/libweston/launcher-direct.c
> > index a5d3ee53..b4ca609a 100644
> > --- a/libweston/launcher-direct.c
> > +++ b/libweston/launcher-direct.c
> > @@ -33,7 +33,6 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -47,6 +46,14 @@
> >  #define KDSKBMUTE  0x4B51
> >  #endif
> >  
> > +/* major()/minor() */
> > +#ifdef MAJOR_IN_MKDEV
> > +#include 
> > +#endif
> > +#ifdef MAJOR_IN_SYSMACROS
> > +#include 
> > +#endif
> > +
> >  #ifdef BUILD_DRM_COMPOSITOR
> >  
> >  #include 
> > diff --git a/libweston/launcher-logind.c b/libweston/launcher-logind.c
> > index f10a2831..3c23d000 100644
> > --- a/libweston/launcher-logind.c
> > +++ b/libweston/launcher-logind.c
> > @@ -35,7 +35,6 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> >  #include 
> >  #include 
> >  
> > @@ -45,6 +44,14 @@
> >  
> >  #define DRM_MAJOR 226
&

Re: [PATCH weston 1/8] shared: Add timespec_normalize helper

[Pekka Paalanen]

On Mon,  4 Dec 2017 15:34:01 +0200
Alexandros Frantzis  wrote:

> Add a helper function to normalize struct timespec values so that the
> nanoseconds part is less than 1 second and has the same sign as the
> seconds part (if the seconds part is not 0).
> 
> Normalization is required to ensure we can safely convert timespec
> values to wayland protocol data, i.e, to tv_sec_hi, tv_sec_lo,
> tv_sec_nsec triplets, and will be used in upcoming commits.
> 
> Signed-off-by: Alexandros Frantzis 
> ---
>  shared/timespec-util.h | 28 ++
>  tests/timespec-test.c  | 65 
> ++
>  2 files changed, 93 insertions(+)
> 
> diff --git a/shared/timespec-util.h b/shared/timespec-util.h
> index f9736c27..a10edf5b 100644
> --- a/shared/timespec-util.h
> +++ b/shared/timespec-util.h
> @@ -33,6 +33,34 @@
>  
>  #define NSEC_PER_SEC 10
>  
> +/* Normalize a timespec
> + *
> + * \param r[out] normalized timespec
> + * \param a[in] timespec to normalize
> + *
> + * Normalize a timespec so that tv_nsec is less than 1 second
> + * and has the same sign as tv_sec (if tv_sec is non-zero).

Hi,

why does it need to have the same sign?
E.g. timespec_sub() ensures nsec is non-negative, as do the add
functions.

Otherwise this is fine, but I would also have the protocol spec forbid
non-normalized timespec values like the presentation-timing extension
does.


Thanks,
pq

> + *
> + */
> +static inline void
> +timespec_normalize(struct timespec *r, const struct timespec *a)
> +{
> + if (a->tv_nsec >= NSEC_PER_SEC || a->tv_nsec <= -NSEC_PER_SEC) {
> + r->tv_sec = a->tv_sec + a->tv_nsec / NSEC_PER_SEC;
> + r->tv_nsec = a->tv_nsec % NSEC_PER_SEC;
> + } else {
> + *r = *a;
> + }
> +
> + if (r->tv_sec > 0 && r->tv_nsec < 0) {
> + r->tv_sec -= 1;
> + r->tv_nsec += NSEC_PER_SEC;
> + } else if (r->tv_sec < 0 && r->tv_nsec > 0) {
> + r->tv_sec += 1;
> + r->tv_nsec -= NSEC_PER_SEC;
> + }
> +}
> +
>  /* Subtract timespecs
>   *
>   * \param r[out] result: a - b
> diff --git a/tests/timespec-test.c b/tests/timespec-test.c
> index f127bcee..8c2296d1 100644
> --- a/tests/timespec-test.c
> +++ b/tests/timespec-test.c
> @@ -38,6 +38,71 @@
>  #include "shared/helpers.h"
>  #include "zunitc/zunitc.h"
>  
> +ZUC_TEST(timespec_test, timespec_normalize)
> +{
> + struct timespec a, r;
> +
> + a.tv_sec = 0;
> + a.tv_nsec = 0;
> + timespec_normalize(&r, &a);
> + ZUC_ASSERT_EQ(r.tv_sec, 0);
> + ZUC_ASSERT_EQ(r.tv_nsec, 0);
> +
> + a.tv_sec = 1;
> + a.tv_nsec = NSEC_PER_SEC - 1;
> + timespec_normalize(&r, &a);
> + ZUC_ASSERT_EQ(r.tv_sec, 1);
> + ZUC_ASSERT_EQ(r.tv_nsec, NSEC_PER_SEC - 1);
> +
> + a.tv_sec = 1;
> + a.tv_nsec = NSEC_PER_SEC;
> + timespec_normalize(&r, &a);
> + ZUC_ASSERT_EQ(r.tv_sec, 2);
> + ZUC_ASSERT_EQ(r.tv_nsec, 0);
> +
> + a.tv_sec = 1;
> + a.tv_nsec = NSEC_PER_SEC + 1;
> + timespec_normalize(&r, &a);
> + ZUC_ASSERT_EQ(r.tv_sec, 2);
> + ZUC_ASSERT_EQ(r.tv_nsec, 1);
> +
> + a.tv_sec = -1;
> + a.tv_nsec = -NSEC_PER_SEC;
> + timespec_normalize(&r, &a);
> + ZUC_ASSERT_EQ(r.tv_sec, -2);
> + ZUC_ASSERT_EQ(r.tv_nsec, 0);
> +
> + a.tv_sec = -1;
> + a.tv_nsec = -(NSEC_PER_SEC + 1);
> + timespec_normalize(&r, &a);
> + ZUC_ASSERT_EQ(r.tv_sec, -2);
> + ZUC_ASSERT_EQ(r.tv_nsec, -1);
> +
> + a.tv_sec = -3;
> + a.tv_nsec = NSEC_PER_SEC + 1;
> + timespec_normalize(&r, &a);
> + ZUC_ASSERT_EQ(r.tv_sec, -1);
> + ZUC_ASSERT_EQ(r.tv_nsec, -(NSEC_PER_SEC - 1));
> +
> + a.tv_sec = 3;
> + a.tv_nsec = -(NSEC_PER_SEC + 1);
> + timespec_normalize(&r, &a);
> + ZUC_ASSERT_EQ(r.tv_sec, 1);
> + ZUC_ASSERT_EQ(r.tv_nsec, NSEC_PER_SEC - 1);
> +
> + a.tv_sec = -1;
> + a.tv_nsec = 2 * NSEC_PER_SEC + 1;
> + timespec_normalize(&r, &a);
> + ZUC_ASSERT_EQ(r.tv_sec, 1);
> + ZUC_ASSERT_EQ(r.tv_nsec, 1);
> +
> + a.tv_sec = 1;
> + a.tv_nsec = -(2 * NSEC_PER_SEC + 1);
> + timespec_normalize(&r, &a);
> + ZUC_ASSERT_EQ(r.tv_sec, -1);
> + ZUC_ASSERT_EQ(r.tv_nsec, -1);
> +}
> +
>  ZUC_TEST(timespec_test, timespec_sub)
>  {
>   struct timespec a, b, r;



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

Re: [PATCH weston 2/8] shared: Add helpers to convert between protocol data and timespec

[Pekka Paalanen]

On Mon,  4 Dec 2017 15:34:02 +0200
Alexandros Frantzis  wrote:

> Add helpers to safely convert between struct timespec values and
> tv_sec_hi, tv_sec_lo, tv_nsec triplets used for sending high-resolution
> timestamp data over the wayland protocol. Replace existing conversion
> code with the helper functions.
> 
> Signed-off-by: Alexandros Frantzis 
> ---
>  clients/presentation-shm.c |  9 +--
>  libweston/compositor.c |  9 ---
>  shared/timespec-util.h | 39 +++
>  tests/presentation-test.c  |  9 +--
>  tests/timespec-test.c  | 66 
> ++
>  5 files changed, 112 insertions(+), 20 deletions(-)

Hi,

I have questions below that will have implications to the protocol
extension spec as well. I would like to require the time values in
protocol to be normalized.

> 
> diff --git a/clients/presentation-shm.c b/clients/presentation-shm.c
> index c9fb66cc..d6a939e5 100644
> --- a/clients/presentation-shm.c
> +++ b/clients/presentation-shm.c
> @@ -39,6 +39,7 @@
>  #include 
>  #include "shared/helpers.h"
>  #include "shared/zalloc.h"
> +#include "shared/timespec-util.h"
>  #include "shared/os-compatibility.h"
>  #include "presentation-time-client-protocol.h"
>  
> @@ -383,14 +384,6 @@ timespec_to_ms(const struct timespec *ts)
>   return (uint32_t)ts->tv_sec * 1000 + ts->tv_nsec / 100;
>  }
>  
> -static void
> -timespec_from_proto(struct timespec *tm, uint32_t tv_sec_hi,
> - uint32_t tv_sec_lo, uint32_t tv_nsec)
> -{
> - tm->tv_sec = ((uint64_t)tv_sec_hi << 32) + tv_sec_lo;
> - tm->tv_nsec = tv_nsec;
> -}
> -
>  static int
>  timespec_diff_to_usec(const struct timespec *a, const struct timespec *b)
>  {
> diff --git a/libweston/compositor.c b/libweston/compositor.c
> index 7d7a17ed..083664fd 100644
> --- a/libweston/compositor.c
> +++ b/libweston/compositor.c
> @@ -341,7 +341,9 @@ weston_presentation_feedback_present(
>  {
>   struct wl_client *client = wl_resource_get_client(feedback->resource);
>   struct wl_resource *o;
> - uint64_t secs;
> + uint32_t tv_sec_hi;
> + uint32_t tv_sec_lo;
> + uint32_t tv_nsec;

A suggestion: how about introducing

struct timespec_proto {
uint32_t sec_hi;
uint32_t sec_lo;
uint32_t nsec;
};

and using that in timespec_to_proto()?

(Not useful for timespec_from_proto() because the three variables are
already declared.)

>  
>   wl_resource_for_each(o, &output->resource_list) {
>   if (wl_resource_get_client(o) != client)
> @@ -350,10 +352,9 @@ weston_presentation_feedback_present(
>   wp_presentation_feedback_send_sync_output(feedback->resource, 
> o);
>   }
>  
> - secs = ts->tv_sec;
> + timespec_to_proto(ts, &tv_sec_hi, &tv_sec_lo, &tv_nsec);
>   wp_presentation_feedback_send_presented(feedback->resource,
> - secs >> 32, secs & 0x,
> - ts->tv_nsec,
> + tv_sec_hi, tv_sec_lo, tv_nsec,
>   refresh_nsec,
>   seq >> 32, seq & 0x,
>   flags | feedback->psf_flags);
> diff --git a/shared/timespec-util.h b/shared/timespec-util.h
> index a10edf5b..c734accd 100644
> --- a/shared/timespec-util.h
> +++ b/shared/timespec-util.h
> @@ -175,6 +175,30 @@ timespec_to_usec(const struct timespec *a)
>   return (int64_t)a->tv_sec * 100 + a->tv_nsec / 1000;
>  }
>  
> +/* Convert timespec to protocol data
> + *
> + * \param a timespec
> + * \param tv_sec_hi[out] the high bytes of the seconds part
> + * \param tv_sec_lo[out] the low bytes of the seconds part
> + * \param tv_nsec[out] the nanoseconds part
> + *
> + * The timespec is normalized before being converted to protocol data.
> + */
> +static inline void
> +timespec_to_proto(const struct timespec *a, uint32_t *tv_sec_hi,
> +  uint32_t *tv_sec_lo, uint32_t *tv_nsec)
> +{
> + struct timespec r;
> +
> + timespec_normalize(&r, a);
> +
> + /* We check the size of tv_sec, so that we shift only if the size
> +  * is 64-bits, in order to avoid sign extension on 32-bit systems. */
> + *tv_sec_hi = sizeof(r.tv_sec) == 8 ? (int64_t)r.tv_sec >> 32 : 0;

How about just casting tv_sec to uint64_t before shifting and masking
it to 32-bit pieces? I think that would be more obvious to read.

I think it would be better to assert() that the timespec is already:

- normalized, because otherwise nsec might overflow in a computation,
  and

- non-negative, because the protocol cannot carry negative
  timestamps.

> + *tv_sec_lo = r.tv_sec;
> + *tv_nsec = r.tv_nsec;
> +}
> +
>  /* Convert nanoseconds to timespec
>   *
>   * \param a timespec
> @@ -209,6 +233,21 @@ timespec_from_msec(struct timespec *a, int64_t b)
>   timespec_from_ns

Re: [PATCH weston 3/8] tests: Move wl_pointer tests to their own file

[Pekka Paalanen]

On Mon,  4 Dec 2017 15:34:03 +0200
Alexandros Frantzis  wrote:

> Move wl_pointer tests from event-test.c to their own pointer-test.c
> file. This move makes the test organization clearer and more consistent,
> and will make addition of further pointer tests easier.
> 
> Signed-off-by: Alexandros Frantzis 
> ---
>  Makefile.am  |   8 +-
>  tests/button-test.c  |  61 --
>  tests/event-test.c   | 256 -
>  tests/pointer-test.c | 318 
> +++
>  4 files changed, 322 insertions(+), 321 deletions(-)
>  delete mode 100644 tests/button-test.c
>  create mode 100644 tests/pointer-test.c

Hi,

this patch R-b me and pushed:
   fbf165f5..5d6acf85  master -> master


Thanks,
pq


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

Re: Providing shared buffer for applications within Smack environment

[Pekka Paalanen]

On Tue, 12 Dec 2017 11:00:23 +0100
José Bollo  wrote:

> Hi all,
> 
> While working for AGL [1], I want to allow applications to receive the
> buffers allocated by WESTON. The use of the surfaces/buffers
> allocated by Weston is difficult when Smack is activated.

Hi,

why do you need to make Weston allocate buffers? Why should those
buffers be accounted to Weston rather than a client that needs them?

E.g. Weston's screenshooting currently has the client allocate buffers,
pass them to Weston, and Weston writes into them, then sends an event
to say they are done.

There are valid use cases, I'm sure, just checking for the obvious.

> When these buffers are created, they are tagged with the smack security
> label that depends on the security label of the service WESTON and of
> the security label of the directory XDG_RUNTIME_DIR when Smack
> transmutation allows it (see [2]).
> 
> For the sake of keeping things simple, I wanted to just tune how the
> buffers are created. But I had to reach the issue that XDG_RUNTIME_DIR
> is also used for socket end point and for lock, leading to a
> opposition of requirements on the objects created in XDG_RUNTIME_DIR:
> some of them are for sharing and some other have to be under control.

The use of XDG_RUNTIME_DIR for allocating buffers is actually not the
best way. I think nowadays we should move on to using shm_open()
instead of creating temporary files in XDG_RUNTIME_DIR.

> To achieve my goal I introduced a new environment variable intended for
> sharing objects. This drives to the patch below [3]. The variable is
> named XDG_RUNTIMESHARE_DIR here (but it can be changed because it is
> not XDG in fact +_o)

I would rather not introduce any such variable. shm_open() should do
just fine. The important point which XDG_RUNTIME_DIR does not really
guarantee is that the backing store for the allocation is not a
physical disk but RAM.

> I would really appreciate the feedbacks and ideas of fellow developers
> from here and there about what I did. Is it the right way to go? Can it
> be up-streamed? Is it a valuable proposal for XDG too?

I believe shm_open() is the right way. If you wanted to be even more
modern, there is memfd_create syscall, but I don't we can generally
assume it is always available yet.


Thanks,
pq

> 
> Best regards
> José Bollo
> 
> [1] www.automotivelinux.org
> [2] https://www.kernel.org/doc/Documentation/security/Smack.txt
> [3] patch below:
> ---
> diff --git a/shared/os-compatibility.c b/shared/os-compatibility.c
> index e19fb61b..7e93e818 100644
> --- a/shared/os-compatibility.c
> +++ b/shared/os-compatibility.c
> @@ -157,6 +157,7 @@ os_create_anonymous_file(off_t size)
>int fd;
>int ret;
>  
> +  if (!(path = getenv("XDG_RUNTIMESHARE_DIR")))
>path = getenv("XDG_RUNTIME_DIR");
>if (!path) {
>errno = ENOENT;
> ---


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

Re: [PATCH weston 1/8] shared: Add timespec_normalize helper

[Pekka Paalanen]

On Tue, 12 Dec 2017 12:36:39 +0200
Alexandros Frantzis  wrote:

> On Tue, Dec 12, 2017 at 11:50:49AM +0200, Pekka Paalanen wrote:
> > On Mon,  4 Dec 2017 15:34:01 +0200
> > Alexandros Frantzis  wrote:
> >   
> > > Add a helper function to normalize struct timespec values so that the
> > > nanoseconds part is less than 1 second and has the same sign as the
> > > seconds part (if the seconds part is not 0).
> > > 
> > > Normalization is required to ensure we can safely convert timespec
> > > values to wayland protocol data, i.e, to tv_sec_hi, tv_sec_lo,
> > > tv_sec_nsec triplets, and will be used in upcoming commits.
> > > 
> > > Signed-off-by: Alexandros Frantzis 
> > > ---
> > >  shared/timespec-util.h | 28 ++
> > >  tests/timespec-test.c  | 65 
> > > ++
> > >  2 files changed, 93 insertions(+)
> > > 
> > > diff --git a/shared/timespec-util.h b/shared/timespec-util.h
> > > index f9736c27..a10edf5b 100644
> > > --- a/shared/timespec-util.h
> > > +++ b/shared/timespec-util.h
> > > @@ -33,6 +33,34 @@
> > >  
> > >  #define NSEC_PER_SEC 10
> > >  
> > > +/* Normalize a timespec
> > > + *
> > > + * \param r[out] normalized timespec
> > > + * \param a[in] timespec to normalize
> > > + *
> > > + * Normalize a timespec so that tv_nsec is less than 1 second
> > > + * and has the same sign as tv_sec (if tv_sec is non-zero).  
> > 
> > Hi,  
> 
> Hi Pekka,
> 
> thanks for the review.
> 
> > why does it need to have the same sign?
> > E.g. timespec_sub() ensures nsec is non-negative, as do the add
> > functions.  
> 
> The goal was to make timespec_normalize more generally useful and
> independent of any current behavior. I didn't want to assume that the
> provided timespec would be produced necessarily by using the
> aforementioned functions that already provide the same-sign guarantee.

They don't provide the same-sign guarantee. They ensure nsec is
non-negative, regardless of the sign of sec.

The question here is, what is the normalized form?

We have not had use for negative time values in the protocol, and the
new proposal does not either, so protocol specs do not offer any
precendent. Computationally they could appear in programs, so the
definition of "normalized" for these helper functions will be purely
libweston-internal.

I'd go with non-negative instead of same-sign, because the existing
code is already like that. I'd like to hear about any better
justification one way or another, since I have little else. I believe
non-negative lead to simpler code.


Thanks,
pq


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

Re: Providing shared buffer for applications within Smack environment

[Pekka Paalanen]

On Tue, 12 Dec 2017 12:08:43 +0100
José Bollo  wrote:

> On Tue, 12 Dec 2017 12:44:46 +0200
> Pekka Paalanen  wrote:
> 
> > On Tue, 12 Dec 2017 11:00:23 +0100
> > José Bollo  wrote:
> >   
> > > Hi all,
> > > 
> > > While working for AGL [1], I want to allow applications to receive
> > > the buffers allocated by WESTON. The use of the surfaces/buffers
> > > allocated by Weston is difficult when Smack is activated.
> > 
> > Hi,
> > 
> > why do you need to make Weston allocate buffers? Why should those
> > buffers be accounted to Weston rather than a client that needs them?  
> 
> TBH, I've no idea of the how and the why but I know that at the end
> clients of the shell call this allocator and that if nothing is done,
> the file descriptor can't be passed to the client because of Smack
> label.
> 
> I can check the reason if you like but it will take some time. It is
> probably a window manager feature.

Hi,

I'm not too interested. If you can deliver the question for the
protocol extension designers to ponder on, that would be enough.

Usually we try to make the compositor take as little "blame" on behalf of
clients as possible. That includes all kinds of resource allocations
and processing.

> > E.g. Weston's screenshooting currently has the client allocate
> > buffers, pass them to Weston, and Weston writes into them, then sends
> > an event to say they are done.
> > 
> > There are valid use cases, I'm sure, just checking for the obvious.
> >   
> > > When these buffers are created, they are tagged with the smack
> > > security label that depends on the security label of the service
> > > WESTON and of the security label of the directory XDG_RUNTIME_DIR
> > > when Smack transmutation allows it (see [2]).
> > > 
> > > For the sake of keeping things simple, I wanted to just tune how the
> > > buffers are created. But I had to reach the issue that
> > > XDG_RUNTIME_DIR is also used for socket end point and for lock,
> > > leading to a opposition of requirements on the objects created in
> > > XDG_RUNTIME_DIR: some of them are for sharing and some other have
> > > to be under control.
> > 
> > The use of XDG_RUNTIME_DIR for allocating buffers is actually not the
> > best way. I think nowadays we should move on to using shm_open()
> > instead of creating temporary files in XDG_RUNTIME_DIR.  
> 
> From the Smack perspective, it probably means that the object is tagged
> with the label of the process. This has implications for Smacked
> systems.

I'm not too familiar with Smack. Would programs need to do something
special to be able to pass open file descriptors for other processes to
use? I can certainly understand protecting the content of
XDG_RUNTIME_DIR specifically, but what about in general, or for
shm_open() in particular? After all, shm_open() primarily meant for
inter-process sharing.

If this is something inherent to Smack, maybe we could have something
in upstream for it, but if it dependent on a particular Smack
configuration then I'm not sure it would make sense upstream.

> > I believe shm_open() is the right way. If you wanted to be even more
> > modern, there is memfd_create syscall, but I don't we can generally
> > assume it is always available yet.  
> 
> Does it really matter as you already provide a suitable solution? Go
> directly to memfd_create if its better.

memfd_create is a bit painful to use. I assume it still has no glibc
wrapper. It was introduced in Linux 3.17 and is specific to Linux.
OTOH, shm_open is a POSIX standard and we would need a shm_open path as
a fallback to memfd_open.


Thanks,
pq


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

Re: [PATCH weston 4/8] tests: Use separate test cases for pointer motion and button tests

[Pekka Paalanen]

On Mon,  4 Dec 2017 15:34:04 +0200
Alexandros Frantzis  wrote:

> Split pointer motion and pointer button tests so that each test case is
> more focused and self-contained.
> 
> Signed-off-by: Alexandros Frantzis 
> ---
>  tests/pointer-test.c | 36 +---
>  1 file changed, 25 insertions(+), 11 deletions(-)
> 
> diff --git a/tests/pointer-test.c b/tests/pointer-test.c
> index d0b85f5d..e0e700e0 100644
> --- a/tests/pointer-test.c
> +++ b/tests/pointer-test.c
> @@ -69,6 +69,17 @@ check_pointer_move(struct client *client, int x, int y)
>   check_pointer(client, x, y);
>  }
>  
> +static struct client *
> +create_client_with_pointer_focus(int x, int y, int w, int h)
> +{
> + struct client *cl = create_client_and_test_surface(x, y, w, h);
> + assert(cl);
> + /* Move the pointer inside the surface to ensure that the surface
> +  * has the pointer focus. */
> + check_pointer_move(cl, x, y);
> + return cl;
> +}
> +
>  TEST(test_pointer_top_left)
>  {
>   struct client *client;
> @@ -286,23 +297,26 @@ TEST(test_pointer_surface_move)
>   check_pointer(client, 50, 50);
>  }
>  
> -TEST(simple_pointer_button_test)
> +TEST(pointer_motion_events)
>  {
> - struct client *client;
> - struct pointer *pointer;
> -
> - client = create_client_and_test_surface(100, 100, 100, 100);
> - assert(client);
> -
> - pointer = client->input->pointer;
> -
> - assert(pointer->button == 0);
> - assert(pointer->state == 0);
> + struct client *client = create_client_with_pointer_focus(100, 100,
> +  100, 100);
> + struct pointer *pointer = client->input->pointer;
>  
>   weston_test_move_pointer(client->test->weston_test, 150, 150);
>   client_roundtrip(client);
>   assert(pointer->x == 50);
>   assert(pointer->y == 50);
> +}
> +
> +TEST(pointer_button_events)
> +{
> + struct client *client = create_client_with_pointer_focus(100, 100,
> +  100, 100);
> + struct pointer *pointer = client->input->pointer;
> +
> + assert(pointer->button == 0);
> + assert(pointer->state == 0);

Hi,

this changes the position where the surface is clicked, but I cannot
see that make a difference. Now we are just ensuring that 0,0 does
actually fall inside the surface, i.e. the exact top-left corner is
inside.

R-b me and pushed this one:
   5d6acf85..903e4450  master -> master


Thanks,
pq

>  
>   weston_test_send_button(client->test->weston_test, BTN_LEFT,
>   WL_POINTER_BUTTON_STATE_PRESSED);



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

Re: [PATCH weston 5/8] tests: Add checks for pointer motion and button event timestamps

[Pekka Paalanen]

On Mon,  4 Dec 2017 15:34:05 +0200
Alexandros Frantzis  wrote:

> Enhance the existing pointer motion and button event tests to
> additionally verify the event timestamps. This requires updating the
> weston-test protocol to support passing motion and button event
> timestamps.
> 
> Signed-off-by: Alexandros Frantzis 
> ---
>  protocol/weston-test.xml  |  6 ++
>  tests/internal-screenshot-test.c  |  2 +-
>  tests/pointer-test.c  | 45 
> ++-
>  tests/subsurface-shot-test.c  |  2 +-
>  tests/weston-test-client-helper.c |  2 ++
>  tests/weston-test-client-helper.h |  2 ++
>  tests/weston-test.c   |  6 --
>  7 files changed, 51 insertions(+), 14 deletions(-)
> 
> diff --git a/protocol/weston-test.xml b/protocol/weston-test.xml
> index 74a15214..ae3349ed 100644
> --- a/protocol/weston-test.xml
> +++ b/protocol/weston-test.xml
> @@ -40,10 +40,16 @@
>
>  
>  
> +  
> +  
> +  
>
>
>  
>  
> +  
> +  
> +  
>
>
>  

Hi Alf,

this patch looks good, just one idea below.

> diff --git a/tests/weston-test-client-helper.h 
> b/tests/weston-test-client-helper.h
> index a288af7e..08817242 100644
> --- a/tests/weston-test-client-helper.h
> +++ b/tests/weston-test-client-helper.h
> @@ -90,6 +90,8 @@ struct pointer {
>   int y;
>   uint32_t button;
>   uint32_t state;
> + uint32_t motion_time;
> + uint32_t button_time;

I assume these will either be replaced or complemented with the precise
timestamp values in the future. For that and also in general, it would
be nice to use names like motion_msec or motion_time_msec to carry the
units. Personally I've found it very easy to forget what they are
otherwise.

This applies to all patches in this series.

>  };
>  
>  struct keyboard {

Thanks,
pq


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

Re: [PATCH weston 2/8] shared: Add helpers to convert between protocol data and timespec

[Pekka Paalanen]

On Tue, 12 Dec 2017 14:43:11 +0200
Alexandros Frantzis  wrote:

> On Tue, Dec 12, 2017 at 12:09:59PM +0200, Pekka Paalanen wrote:
> > On Mon,  4 Dec 2017 15:34:02 +0200
> > Alexandros Frantzis  wrote:
> >   
> > > Add helpers to safely convert between struct timespec values and
> > > tv_sec_hi, tv_sec_lo, tv_nsec triplets used for sending high-resolution
> > > timestamp data over the wayland protocol. Replace existing conversion
> > > code with the helper functions.
> > > 
> > > Signed-off-by: Alexandros Frantzis 
> > > ---
> > >  clients/presentation-shm.c |  9 +--
> > >  libweston/compositor.c |  9 ---
> > >  shared/timespec-util.h | 39 +++
> > >  tests/presentation-test.c  |  9 +--
> > >  tests/timespec-test.c  | 66 
> > > ++
> > >  5 files changed, 112 insertions(+), 20 deletions(-)  
> > 
> > Hi,  
> 
> Hi,
> 
> > 
> > I have questions below that will have implications to the protocol
> > extension spec as well. I would like to require the time values in
> > protocol to be normalized.  
> 
> Ack.
> 
> > > 
> > > diff --git a/clients/presentation-shm.c b/clients/presentation-shm.c
> > > index c9fb66cc..d6a939e5 100644
> > > --- a/clients/presentation-shm.c
> > > +++ b/clients/presentation-shm.c
> > > @@ -39,6 +39,7 @@
> > >  #include 
> > >  #include "shared/helpers.h"
> > >  #include "shared/zalloc.h"
> > > +#include "shared/timespec-util.h"
> > >  #include "shared/os-compatibility.h"
> > >  #include "presentation-time-client-protocol.h"
> > >  
> > > @@ -383,14 +384,6 @@ timespec_to_ms(const struct timespec *ts)
> > >   return (uint32_t)ts->tv_sec * 1000 + ts->tv_nsec / 100;
> > >  }
> > >  
> > > -static void
> > > -timespec_from_proto(struct timespec *tm, uint32_t tv_sec_hi,
> > > - uint32_t tv_sec_lo, uint32_t tv_nsec)
> > > -{
> > > - tm->tv_sec = ((uint64_t)tv_sec_hi << 32) + tv_sec_lo;
> > > - tm->tv_nsec = tv_nsec;
> > > -}
> > > -
> > >  static int
> > >  timespec_diff_to_usec(const struct timespec *a, const struct timespec *b)
> > >  {
> > > diff --git a/libweston/compositor.c b/libweston/compositor.c
> > > index 7d7a17ed..083664fd 100644
> > > --- a/libweston/compositor.c
> > > +++ b/libweston/compositor.c
> > > @@ -341,7 +341,9 @@ weston_presentation_feedback_present(
> > >  {
> > >   struct wl_client *client = wl_resource_get_client(feedback->resource);
> > >   struct wl_resource *o;
> > > - uint64_t secs;
> > > + uint32_t tv_sec_hi;
> > > + uint32_t tv_sec_lo;
> > > + uint32_t tv_nsec;  
> > 
> > A suggestion: how about introducing
> > 
> > struct timespec_proto {
> > uint32_t sec_hi;
> > uint32_t sec_lo;
> > uint32_t nsec;
> > };
> > 
> > and using that in timespec_to_proto()?
> > 
> > (Not useful for timespec_from_proto() because the three variables are
> > already declared.)  
> 
> I am not opposed to introducing a struct timespec_proto in general, but
> using it in only one of the two functions feels inconsistent.

Ok. I was thinking of saving in the number of local variables on every
call site of timespec_to_proto().

> > >   wl_resource_for_each(o, &output->resource_list) {
> > >   if (wl_resource_get_client(o) != client)
> > > @@ -350,10 +352,9 @@ weston_presentation_feedback_present(
> > >   wp_presentation_feedback_send_sync_output(feedback->resource, 
> > > o);
> > >   }
> > >  
> > > - secs = ts->tv_sec;
> > > + timespec_to_proto(ts, &tv_sec_hi, &tv_sec_lo, &tv_nsec);
> > >   wp_presentation_feedback_send_presented(feedback->resource,
> > > - secs >> 32, secs & 0x,
> > > - ts->tv_nsec,
> > > + tv_sec_hi, tv_sec_lo, tv_nsec,
> > >   refresh_nsec,
> > >   seq >> 32, seq & 0x,
> > >   flags | feedback->psf_flags);
> > > diff --git a/shared/timespec-util.h b/shared/timespec-util.h
> 

Re: [PATCH weston 6/8] tests: Add test for pointer axis events

[Pekka Paalanen]

On Mon,  4 Dec 2017 15:34:06 +0200
Alexandros Frantzis  wrote:

> Add test to verify the server correctly emits pointer axis events.  This
> requires updating the weston-test protocol with a new request for
> pointer axis events.
> 
> Signed-off-by: Alexandros Frantzis 
> ---
>  protocol/weston-test.xml  |  7 +++
>  tests/pointer-test.c  | 28 
>  tests/weston-test-client-helper.c | 13 -
>  tests/weston-test-client-helper.h |  4 
>  tests/weston-test.c   | 20 
>  5 files changed, 71 insertions(+), 1 deletion(-)

Hi,

looks good to me!


Thanks,
pq


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

Re: [PATCH weston 7/8] tests: Add test for keyboard key event timestamps

[Pekka Paalanen]

On Mon,  4 Dec 2017 15:34:07 +0200
Alexandros Frantzis  wrote:

> Add test to verify that the server correctly sets the timestamps of
> keyboard key events. This requires updating the weston-test protocol to
> support passing key event timestamps.
> 
> Signed-off-by: Alexandros Frantzis 
> ---
>  protocol/weston-test.xml  |  3 ++
>  tests/keyboard-test.c | 58 
> +++
>  tests/weston-test-client-helper.c |  1 +
>  tests/weston-test-client-helper.h |  1 +
>  tests/weston-test.c   |  3 +-
>  5 files changed, 53 insertions(+), 13 deletions(-)
> 
> diff --git a/protocol/weston-test.xml b/protocol/weston-test.xml
> index a4a7ad4e..37fa221f 100644
> --- a/protocol/weston-test.xml
> +++ b/protocol/weston-test.xml
> @@ -64,6 +64,9 @@
> allow-null="true"/>
>  
>  
> +  
> +  
> +  
>
>
>  
> diff --git a/tests/keyboard-test.c b/tests/keyboard-test.c
> index 6b4ba19d..df1940f8 100644
> --- a/tests/keyboard-test.c
> +++ b/tests/keyboard-test.c
> @@ -27,21 +27,45 @@
>  
>  #include 
>  
> +#include "shared/timespec-util.h"
>  #include "weston-test-client-helper.h"
>  
> +static const struct timespec t1 = { .tv_sec = 1, .tv_nsec = 101 };
> +static const struct timespec t2 = { .tv_sec = 2, .tv_nsec = 201 };
> +
> +static struct client *
> +create_client_with_keyboard_focus(void)
> +{
> + struct client *cl = create_client_and_test_surface(10, 10, 1, 1);
> + assert(cl);
> +
> + weston_test_activate_surface(cl->test->weston_test,
> +  cl->surface->wl_surface);
> + client_roundtrip(cl);
> +
> + return cl;
> +}
> +
> +static void
> +send_key(struct client *client, const struct timespec *time,
> +  uint32_t key, uint32_t state)
> +{
> + uint32_t tv_sec_hi, tv_sec_lo, tv_nsec;
> +
> + timespec_to_proto(time, &tv_sec_hi, &tv_sec_lo, &tv_nsec);
> + weston_test_send_key(client->test->weston_test, tv_sec_hi, tv_sec_lo,
> +  tv_nsec, key, state);
> + client_roundtrip(client);
> +}
> +
>  TEST(simple_keyboard_test)
>  {
> - struct client *client;
> - struct surface *expect_focus = NULL;
> - struct keyboard *keyboard;
> + struct client *client = create_client_with_keyboard_focus();
> + struct keyboard *keyboard = client->input->keyboard;
> + struct surface *expect_focus = client->surface;
>   uint32_t expect_key = 0;
>   uint32_t expect_state = 0;
>  
> - client = create_client_and_test_surface(10, 10, 1, 1);
> - assert(client);
> -
> - keyboard = client->input->keyboard;
> -
>   while (1) {
>   assert(keyboard->key == expect_key);
>   assert(keyboard->state == expect_state);
> @@ -49,8 +73,7 @@ TEST(simple_keyboard_test)
>  
>   if (keyboard->state == WL_KEYBOARD_KEY_STATE_PRESSED) {
>   expect_state = WL_KEYBOARD_KEY_STATE_RELEASED;
> - weston_test_send_key(client->test->weston_test,
> -  expect_key, expect_state);
> + send_key(client, &t1, expect_key, expect_state);
>   } else if (keyboard->focus) {
>   expect_focus = NULL;
>   weston_test_activate_surface(
> @@ -62,8 +85,7 @@ TEST(simple_keyboard_test)
>   weston_test_activate_surface(
>   client->test->weston_test,
>   expect_focus->wl_surface);
> - weston_test_send_key(client->test->weston_test,
> -  expect_key, expect_state);
> + send_key(client, &t1, expect_key, expect_state);
>   } else {
>   break;
>   }
> @@ -71,3 +93,15 @@ TEST(simple_keyboard_test)
>   client_roundtrip(client);
>   }

The testing sequence in the while loop is changed. In two of the three
cases there is now a double-roundtrip. Before the test started with no
focus, now it starts with focus which means it first loses focus and
then continues on the old sequence.

Those are all subtle and apparently harmless changes, but also never
mentioned in the commit message.

I'd be more comfortable if you moved the existing roundtrip to the case
still needing it, avoiding the double-roundtrips, and justified the new
sequence in the commit message.

>  }
> +
> +TEST(keyboard_key_event_time)
> +{
> + struct client *client = create_client_with_keyboard_focus();
> + struct keyboard *keyboard = client->input->keyboard;
> +
> + send_key(client, &t1, 0, WL_KEYBOARD_KEY_STATE_PRESSED);
> + assert(keyboard->key_time == timespec_to_msec(&t1));
> +
> + send_key(client, &t2, 0, WL_KEYBOARD_KEY_STATE_RELEASED);
> + assert(keyboard->key_time == timespec_to_msec(&t2));

0 is defined a KEY_RESERVED, I think it would be better to use another
value just 

Re: [PATCH weston 8/8] tests: Add test for touch event timestamps

[Pekka Paalanen]

On Mon,  4 Dec 2017 15:34:08 +0200
Alexandros Frantzis  wrote:

> Add test to verify that the server correctly sets the timestamps of
> touch events. This requires updating the weston-test protocol with a new
> request for touch events.
> 
> Signed-off-by: Alexandros Frantzis 
> ---
>  Makefile.am   |  7 +++-
>  protocol/weston-test.xml  |  9 +
>  tests/touch-test.c| 71 
> +++
>  tests/weston-test-client-helper.c |  3 ++
>  tests/weston-test-client-helper.h |  3 ++
>  tests/weston-test.c   | 16 +
>  6 files changed, 108 insertions(+), 1 deletion(-)
>  create mode 100644 tests/touch-test.c

Looks good.

Thanks,
pq


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

Re: [PATCH weston 2/8] shared: Add helpers to convert between protocol data and timespec

[Pekka Paalanen]

On Tue, 12 Dec 2017 16:29:49 +0200
Alexandros Frantzis  wrote:

> On Tue, Dec 12, 2017 at 03:09:56PM +0200, Pekka Paalanen wrote:
> > On Tue, 12 Dec 2017 14:43:11 +0200
> > Alexandros Frantzis  wrote:
> >   
> > > On Tue, Dec 12, 2017 at 12:09:59PM +0200, Pekka Paalanen wrote:  
> > > > On Mon,  4 Dec 2017 15:34:02 +0200
> > > > Alexandros Frantzis  wrote:
> > > > 
> > > > > Add helpers to safely convert between struct timespec values and
> > > > > tv_sec_hi, tv_sec_lo, tv_nsec triplets used for sending 
> > > > > high-resolution
> > > > > timestamp data over the wayland protocol. Replace existing conversion
> > > > > code with the helper functions.
> > > > > 
> > > > > Signed-off-by: Alexandros Frantzis 
> > > > > ---
> > > > >  clients/presentation-shm.c |  9 +--
> > > > >  libweston/compositor.c |  9 ---
> > > > >  shared/timespec-util.h | 39 +++
> > > > >  tests/presentation-test.c  |  9 +--
> > > > >  tests/timespec-test.c  | 66 
> > > > > ++
> > > > >  5 files changed, 112 insertions(+), 20 deletions(-)

> > > > I think it would be better to assert() that the timespec is already:
> > > > 
> > > > - normalized, because otherwise nsec might overflow in a computation,
> > > >   and
> > > 
> > > If we make normalized input a pre-condition of timespec_to_proto, we are
> > > essentially moving the burden to the caller, which in most cases should
> > > call timespec_normalize themselves before calling timespec_to_proto. I
> > > am not sure if we should burden the callers with this and introduce the
> > > possibility of runtime errors.  
> > 
> > There would be no burden if we ensure our timestamps are always
> > normalized, which is a precondition for the timespec sub/add etc.
> > functions to operate without overflows. Therefore I'd push the
> > normalize calls to not just the callers but the sites where the
> > timestamps originate.  
> 
> I am concerned that we are making timespec_to_proto unnecessarily
> strict, and introducing more potential for runtime errors, but this is
> certainly a viable path. I will update timespec_to_proto to have this
> precondition.

I would say those are bugs deserving to be fixed, that's why assert()
exists and we use it heavily. :-)

So far we have been concentrating more on correctness and finding bugs,
rather than ensuring Weston will keep limping along no matter what.

> > > Also, I like the idea that the callers don't need to care about protocol
> > > encoding details, and just let timespec_to_proto do the conversion
> > > properly.  
> > 
> > I think there are two different "normalized" here. One is struct
> > timespec, another is what the protocol carries. Compared to struct
> > timespec, the protocol has an additional requirement of non-negativity.
> > I don't see that as leaking protocol encoding details - OTOH, we must
> > not even attempt to send values the protocol cannot carry.  
> 
> I think the difference it that passing a negative value is clearly an
> invalid value, i.e., a logic error, whereas an unnormalized valid value is
> actually a valid value with an unacceptable representation which we can
> fix.

That would be true, if our timespec helper functions would agree and
handle it. But rather than adding "fixups" on every turn, I'd prefer
ensuring we notice and fix anything that is off.

However, the major exception to that idea is any data that comes in
from "untrusted" sources like Wayland clients. That needs to be
sanitized so that clients cannot trigger compositor malfunction.


Thanks,
pq


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

Re: [PATCH v2] configure.ac: use AC_HEADER_MAJOR to detect major()/minor()

[Pekka Paalanen]

On Tue, 12 Dec 2017 15:41:52 +
Emil Velikov  wrote:

> On 12 December 2017 at 08:28, Pekka Paalanen  wrote:
> > On Mon, 11 Dec 2017 16:16:47 +0200
> > Pekka Paalanen  wrote:
> >  
> >> On Wed, 31 May 2017 22:17:50 +0100
> >> Sergei Trofimovich  wrote:
> >>  
> >> > This change slightly updates c4d7f66c12853b9575366dd9f4a7960ec5694934
> >> > which added  inclusion.
> >> >
> >> > Autoconf has AC_HEADER_MAJOR to find out which header defines
> >> > reqiured macros:
> >> > 
> >> > https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Particular-Headers.html
> >> >
> >> > This change should increase portability across other libcs.
> >> >
> >> > Bug: https://bugs.gentoo.org/610652
> >> > Signed-off-by: Sergei Trofimovich 
> >> > ---
> >> > Change since v1:
> >> > - rebased on top of current master
> >> > - dedented nested '#include'
> >> >  configure.ac   | 1 +
> >> >  libweston/launcher-direct.c| 9 -
> >> >  libweston/launcher-logind.c| 9 -
> >> >  libweston/launcher-weston-launch.c | 8 +++-
> >> >  libweston/weston-launch.c  | 9 -
> >> >  5 files changed, 32 insertions(+), 4 deletions(-)  
> >>
> >> Hi,
> >>
> >> I'm on Gentoo with sys-libs/glibc-2.25-r9:2.2 and I am now getting a
> >> bunch of warnings like this:
> >>
> >> /home/pq/git/weston/libweston/weston-launch.c: In function ‘handle_open’:
> >> /home/pq/git/weston/libweston/weston-launch.c:333:13: warning: In the GNU 
> >> C Library, "major" is defined
> >>  by . For historical compatibility, it is
> >>  currently defined by  as well, but we plan to
> >>  remove this soon. To use "major", include 
> >>  directly. If you did not intend to use a system-defined macro
> >>  "major", you should undefine it after including .
> >>   if (major(s.st_rdev) != INPUT_MAJOR &&
> >>
> >>
> >> Reverting this patch makes the warnings go away.
> >>
> >> What's the right fix here?
> >>
> >> In config.h I have:
> >>
> >> /* Define to 1 if `major', `minor', and `makedev' are declared in 
> >> .
> >>*/
> >> /* #undef MAJOR_IN_MKDEV */
> >>
> >> /* Define to 1 if `major', `minor', and `makedev' are declared in
> >>. */
> >> /* #undef MAJOR_IN_SYSMACROS */
> >>
> >> I'm not sure what I needed to do get even that far, maybe wipe my
> >> out-of-tree build dir. Even then, I cannot find any evidence of
> >> configure actually running the tests. I always start a new build dir by
> >> running autogen.sh.  
> >
> > Hi,
> >
> > there is an email thread of the problem from a slightly different point
> > of view:
> > https://lists.gnu.org/archive/html/autoconf/2016-09/msg0.html
> >
> > If we keep the code as is, the warning will not go away until glibc
> > actually drops the things from sys/types.h and distros ship it.
> > Apparently there is a workaround one could make with config.site:
> > https://lists.gnu.org/archive/html/autoconf/2016-09/msg00013.html
> >
> > Or we could wait for a new autoconf release and require it, but the
> > discussion happened in 2016 and at least Gentoo does not have a
> > autoconf 2.70 yet. Or we could ship a fixed AC_HEADER_MAJOR.
> >
> > Or we could just revert this patch until something in the above changes
> > or we have migrated to Meson.
> >  
> I wish the glibc people were a bit more diligent about the deprecation :-(
> Haven't looked at how Meson does it, but I would suspect it has a
> workaround similar to this [1].
> 
> -Emil
> [1] 
> https://cgit.freedesktop.org/mesa/drm/commit/?id=7040fea0280bad527ed4b3d5eee7d7bfbf303efc

Hi Emil,

the workaround taken in libdrm was discussed in that 2016 email thread,
concluding it is not a good idea, because autoconf compiler tests have
horrible code quality: they often provoke warnings anyway, which means
-Werror would cause false negatives in tests.

Maybe it's fine for AC_HEADER_MAJOR alone?


Thanks,
pq


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

Re: [PATCH] server: add wl_display_destroy_clients

[Pekka Paalanen]

On Mon, 11 Dec 2017 22:56:32 +0100
emersion  wrote:

> wl_display_destroy doesn't destroy clients, so client socket file
> descriptors are being kept open until the compositor process exits.
> 
> To maintain ABI compatibility, we cannot destroy clients in
> wl_display_destroy. Thus, a new wl_display_destroy_clients functions
> is added and should be called by compositors right before
> wl_display_destroy.
> 
> See https://patchwork.freedesktop.org/patch/128832/
> 
> Signed-off-by: emersion 

Hi,

thanks for this patch, this implements the idea I suggested in the
review comments of the earlier proposal.

Would be good to mention
https://bugs.freedesktop.org/show_bug.cgi?id=99142
in the commit message. Please wrap the commit message lines.

> ---
>  src/wayland-server-core.h |  3 +++
>  src/wayland-server.c  | 22 ++
>  2 files changed, 25 insertions(+)
> 
> diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h
> index fd458c5..2e725d9 100644
> --- a/src/wayland-server-core.h
> +++ b/src/wayland-server-core.h
> @@ -214,6 +214,9 @@ wl_display_run(struct wl_display *display);
>  void
>  wl_display_flush_clients(struct wl_display *display);
>  
> +void
> +wl_display_destroy_clients(struct wl_display *display);
> +
>  struct wl_client;
>  
>  typedef void (*wl_global_bind_func_t)(struct wl_client *client, void *data,
> diff --git a/src/wayland-server.c b/src/wayland-server.c
> index 82a3b01..7f24ef1 100644
> --- a/src/wayland-server.c
> +++ b/src/wayland-server.c
> @@ -1264,6 +1264,28 @@ wl_display_flush_clients(struct wl_display *display)
>   }
>  }
>  

Documentation is missing.

> +WL_EXPORT void
> +wl_display_destroy_clients(struct wl_display *display)
> +{
> + struct wl_list tmp_client_list;
> + struct wl_client *client, *next;
> +
> + // Move the whole client list to a temporary head because some new 
> clients
> + // might be added to the original head

Use old style C comments /* */ please.

> + wl_list_init(&tmp_client_list);
> + wl_list_insert_list(&tmp_client_list, &display->client_list);
> + wl_list_init(&display->client_list);

Very good.

> +
> + wl_list_for_each_safe(client, next, &tmp_client_list, link) {
> + wl_client_destroy(client);
> + }

I wonder if we should be even more paranoid here. This loop is not safe
if the callbacks from destroying this wl_client already destroy the
next wl_client. What would be guaranteed safe here is to loop while the
temporary list is not empty, and always taking the first entry. An
example is in wl_priv_signal_emit().

> +
> + if (!wl_list_empty(&display->client_list)) {
> + wl_log("wl_display_destroy_clients: cannot destroy all clients 
> because "
> +"new ones were created by destroy callbacks\n");
> + }

Good.

> +}
> +
>  static int
>  socket_data(int fd, uint32_t mask, void *data)
>  {

Thanks,
pq


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

Re: [PATCH v2] server: add wl_display_destroy_clients()

[Pekka Paalanen]

On Wed, 13 Dec 2017 11:51:19 +0100
emersion  wrote:

> Bug [1] reported that wl_display_destroy() doesn't destroy clients, so
> client socket file descriptors are being kept open until the compositor
> process exits.
> 
> Patch [2] proposed to destroy clients in wl_display_destroy(). The
> patch was not accepted because doing so changes the ABI.
> 
> Thus, a new wl_display_destroy_clients() function is added in this
> patch. It should be called by compositors right before
> wl_display_destroy().
> 
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=99142
> [2] https://patchwork.freedesktop.org/patch/128832/
> 
> Signed-off-by: emersion 
> ---
> v2: change commit message, add docs, use a safer approach when iterating
> over the client list
> 
>  src/wayland-server-core.h |  3 +++
>  src/wayland-server.c  | 38 ++
>  2 files changed, 41 insertions(+)
> 
> diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h
> index fd458c5..2e725d9 100644
> --- a/src/wayland-server-core.h
> +++ b/src/wayland-server-core.h
> @@ -214,6 +214,9 @@ wl_display_run(struct wl_display *display);
>  void
>  wl_display_flush_clients(struct wl_display *display);
> 
> +void
> +wl_display_destroy_clients(struct wl_display *display);
> +
>  struct wl_client;
> 
>  typedef void (*wl_global_bind_func_t)(struct wl_client *client, void *data,
> diff --git a/src/wayland-server.c b/src/wayland-server.c
> index 82a3b01..33df413 100644
> --- a/src/wayland-server.c
> +++ b/src/wayland-server.c
> @@ -1264,6 +1264,44 @@ wl_display_flush_clients(struct wl_display *display)
>   }
>  }
> 
> +/** Destroy all clients connected to the display
> + *
> + * \param display The display object
> + *
> + * This function should be called right before wl_display_destroy() to ensure
> + * all client resources are closed properly. Destroying a client from within
> + * wl_display_destroy_clients() is safe, but creating one will leak resources
> + * and raise a warning.
> + *
> + * \memberof wl_display
> + */
> +WL_EXPORT void
> +wl_display_destroy_clients(struct wl_display *display)
> +{
> + struct wl_list tmp_client_list, *pos;
> + struct wl_client *client;
> +
> + /* Move the whole client list to a temporary head because some new 
> clients
> +  * might be added to the original head. */
> + wl_list_init(&tmp_client_list);
> + wl_list_insert_list(&tmp_client_list, &display->client_list);
> + wl_list_init(&display->client_list);
> +
> + /* wl_list_for_each_safe isn't enough here: it fails if the next client 
> is
> +  * destroyed by the destroy handler of the current one. */
> + while (!wl_list_empty(&tmp_client_list)) {
> + pos = tmp_client_list.next;
> + client = wl_container_of(pos, client, link);
> +
> + wl_client_destroy(client);
> + }
> +
> + if (!wl_list_empty(&display->client_list)) {
> +     wl_log("wl_display_destroy_clients: cannot destroy all clients 
> because "
> +"new ones were created by destroy callbacks\n");
> + }
> +}
> +
>  static int
>  socket_data(int fd, uint32_t mask, void *data)
>  {

Hi,

very good!

Reviewed-by: Pekka Paalanen 

Do you have your compositor now calling this without issues?

It would be awesome to have a test in the libwayland test suite calling
this function and checking a client gets destroyed, especially as we
don't have Weston using this yet.


Thanks,
pq


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

Re: [PATCH v2] server: add wl_display_destroy_clients()

[Pekka Paalanen]

On Wed, 13 Dec 2017 06:59:10 -0500
Simon Ser  wrote:

> > Original Message 
> >Subject: Re: [PATCH v2] server: add wl_display_destroy_clients()
> >Local Time: December 13, 2017 12:11 PM
> >UTC Time: December 13, 2017 11:11 AM
> >From: ppaala...@gmail.com
> >To: emersion 
> >wayland-devel@lists.freedesktop.org
> >
> >On Wed, 13 Dec 2017 11:51:19 +0100
> > emersion cont...@emersion.fr wrote:  
> >>Bug [1] reported that wl_display_destroy() doesn't destroy clients, so
> >> client socket file descriptors are being kept open until the compositor
> >> process exits.
> >>Patch [2] proposed to destroy clients in wl_display_destroy(). The
> >> patch was not accepted because doing so changes the ABI.
> >>Thus, a new wl_display_destroy_clients() function is added in this
> >> patch. It should be called by compositors right before
> >> wl_display_destroy().
> >>[1] https://bugs.freedesktop.org/show_bug.cgi?id=99142
> >> [2] https://patchwork.freedesktop.org/patch/128832/
> >>Signed-off-by: emersion cont...@emersion.fr

Hi,

ah, your real name is Simon Ser? We need it in the Signed-off-by tag
for the tag to be valid, do you mind if I fix it while eventually landing
this patch?

The Linux kernel patch submission guidelines say it's required, nick
names won't do.

> >>
> >>v2: change commit message, add docs, use a safer approach when iterating
> >> over the client list
> >>src/wayland-server-core.h |  3 +++
> >> src/wayland-server.c  | 38 ++
> >> 2 files changed, 41 insertions(+)
> >>diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h
> >> index fd458c5..2e725d9 100644
> >> --- a/src/wayland-server-core.h
> >> +++ b/src/wayland-server-core.h
> >> @@ -214,6 +214,9 @@ wl_display_run(struct wl_display *display);
> >> void
> >> wl_display_flush_clients(struct wl_display *display);
> >>+void
> >> +wl_display_destroy_clients(struct wl_display *display);
> >> +
> >> struct wl_client;
> >>typedef void (*wl_global_bind_func_t)(struct wl_client *client, void *data,
> >> diff --git a/src/wayland-server.c b/src/wayland-server.c
> >> index 82a3b01..33df413 100644
> >> --- a/src/wayland-server.c
> >> +++ b/src/wayland-server.c
> >> @@ -1264,6 +1264,44 @@ wl_display_flush_clients(struct wl_display *display)
> >> }
> >> }
> >>+/** Destroy all clients connected to the display
> >> -  - 
> >> -  - \param display The display object
> >> -  - 
> >> -  - This function should be called right before wl_display_destroy() to 
> >> ensure
> >> -  - all client resources are closed properly. Destroying a client from 
> >> within
> >> -  - wl_display_destroy_clients() is safe, but creating one will leak 
> >> resources
> >> -  - and raise a warning.
> >> -  - 
> >> -  - \memberof wl_display
> >> - */
> >> +WL_EXPORT void
> >> +wl_display_destroy_clients(struct wl_display *display)
> >> +{
> >> - struct wl_list tmp_client_list, *pos;
> >> - struct wl_client *client;
> >> - 
> >> - /* Move the whole client list to a temporary head because some new 
> >> clients
> >> -  - might be added to the original head. */
> >> - wl_list_init(&tmp_client_list);
> >> - wl_list_insert_list(&tmp_client_list, &display->client_list);
> >> - wl_list_init(&display->client_list);
> >> - 
> >> - /* wl_list_for_each_safe isn't enough here: it fails if the next client 
> >> is
> >> -  - destroyed by the destroy handler of the current one. */
> >> - while (!wl_list_empty(&tmp_client_list)) {
> >> - pos = tmp_client_list.next;
> >>
> >> - client = wl_container_of(pos, client, link);
> >>
> >> - 
> >> - wl_client_destroy(client);
> >>
> >> - }
> >> - 
> >> - if (!wl_list_empty(&display->client_list)) {
> >> - wl_log("wl_display_destroy_clients: cannot destroy all clients because "
> >>
> >> - "new ones were created by destroy callbacks\n");
> >>
> >> - }
> >> +}
> >> - 
> >>static int
> >> socket_data(int fd, uint32_t mask, void *data)
> >> {  
> >
> > Hi,
> >
> > very good!
> >
> > Reviewed-by: Pekka Paalanen pekka.paala...@collabora.co.uk  
> 
> Thanks for your review!
> 
> > Do you have your compositor now calling this without issues?  
> 
> Yes! I've tested the new function and it works properly. Here's the patch:
> https://github.com/emersion/wlroots/commit/71d344cc616021a1d1ed6e075f8c7e0d15b0deb0

Cool.

> > It would be awesome to have a test in the libwayland test suite calling
> > this function and checking a client gets destroyed, especially as we
> > don't have Weston using this yet.  
> 
> I'll try to make another patch for this.

Appreciated.


Thanks,
pq


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

Re: Weston stuff: fractional HiDPI, FreeBSD, Rust

[Pekka Paalanen]

On Thu, 14 Dec 2017 03:05:59 +0300
Greg V  wrote:

> Hi everyone!
> 
> I've been hacking around, trying to make Weston more usable for myself…

Hi,

nice work!

Here are my initial thoughts of the ideas, but mind that I didn't look
at the code at all, so some questions might sound lazy.

> So far I've done:
> 
> - FreeBSD support: https://github.com/myfreeweb/weston/commit/5827840c8
> 2b9d0a302d5c54c514ca6f4238e12de

In theory I'd support this, but I'm sure we'll have some bikeshedding
on how to actually deal with the alternative code. I would also be
worried about testing, because most developers don't run any BSD and
changes would not be tested without a CI running something on a BSD.
And if testing would catch breakage on BSD, at least I wouldn't know
how to fix it.

> - memfd/anonymous shm in os_create_anonymous_file: https://github.com/m
> yfreeweb/weston/commit/24bbf0d9265478c406a23d8f1642a37daf43425f

Sounds nice.

> - static linking of backends and gl-renderer: https://github.com/myfree
> web/weston/commit/c9ed3f9683bd7fb99aa0e811348fbcec37674140 for language
> bindings (e.g. there's no good way to ship additional shared libraries
> when you're a Rust library, I don't think cargo supports that)

How does that generalize to plugins? Aside from the backends and the
renderer, there is the xwayland plugin. I think the rest are still
pratically Weston plugins rather than libweston plugins. Even that
creates quite a lot of combinations.

Do you mean that the Rust crate is shipping a statically linked
libweston, instead of linking to the system-installed libweston? Why?
What about everything libweston depends on, do you statically link all
that as well? And Mesa?

> - the Rust libweston bindings themselves https://github.com/myfreeweb/w
> eston-rs — incomplete/WIP, but a simple example compositor works! (see
> weston-rs/examples folder)

Is this something that would need to live with libweston or can it be a
separate project?

> - fractional DPI scaling! https://github.com/myfreeweb/weston/commit/d2
> 16493ae33659a98b9a9cbe77d4068b9462eea8 (additional downscaling after
> integer scaling)

I would guess users would welcome this feature, so sure, details to be
discussed.

> Please tell me if there's any interest in merging some of these changes
> into upstream weston!

Just a reminder that we are thin on review bandwidth as always. :-)

> //
> 
> The fractional scaling was surprisingly easy to implement, works
> perfectly with native Wayland apps and looks excellent on my 28" 4K
> monitor (140% scale).
> 
> However… Xwayland.
> 
> I saw a lot of discussion of multiple monitors with different DPIs and
> stuff. I only have one single monitor and I just want Firefox and
> Thunderbird to not be blurry.
> 
> So, Weston assumes that X11 clients are not DPI aware. (Personally, I
> haven't seen any clients that don't respect Xft.dpi in Xresources…)
> 
> I tried to change that, to make Weston assume they are DPI aware:
> 
> libweston-desktop/xwayland.c
> @@ -256,6 +257,10 @@ create_surface(struct weston_desktop_xwayland 
> +   wsurface->pending.buffer_viewport.buffer.scale = 2;
> +   wsurface->pending.buffer_viewport.changed = 1;
> 
> well… the resolution is correct, but everything becomes unusable :(
> Only rendering is properly scaled, mouse input is not! Mouse position
> appears to X11 clients as if they were not downscaled. So clicks go to
> wrong places and wrong areas get re-rendered in the compositor. And
> yeah, no more shadows in gtk3 apps, instead there's a black rectangle
> behind the window.
> 
> https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/xwayland-d
> ebug.png — the gl renderer's debug view shows the damage area on the
> button is not where it should be.
> 
> Apparently GNOME handles this correctly. I've tried looking at mutter
> source, haven't found anything useful.
> 
> How do I fix this?? Please help…

I suppose the hack is wrong. ;-)

It would be best for Xwayland server to set the buffer_scale
appropriately. It also changes the window coordinate systems which I
guess is why everything breaks. A buffer of 600x400 with buffer_scale=2
produces a wl_surface of 300x200. Input and damage communication
happens in the wl_surface coordinate space, so those need to be
adjusted as well. But that is only the Wayland side of it.

The X11 side has its own global coordinate system that X11 clients
expect to be consistent. When wl_surface size no longer matches the X11
Window size, something has to convert between the two, and at least XWM
in Weston and Xwayland would be involved. But it affects also things
like RandR advertised output sizes and the X11 SCREEN size. I don't
actually know if or how all that can be made to work. The X11
coordinate system needs to be consistent not only inside a top-level
window, but for the whole desktop, because X11 apps will position
arbitrary windows in absolute coordinates, without telling the server
what the geometric relationship is intended to be.

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

[Pekka Paalanen]

On Wed, 13 Dec 2017 08:19:46 -0600
Matt Hoosier  wrote:

> On Mon, Dec 11, 2017 at 2:03 AM, Pekka Paalanen  wrote:
> > On Mon, 27 Nov 2017 08:54:54 -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.
> >>
> >> v4 changes:
> >>
> >> * Improved internal comments and some boundary-condition
> >>   error checks in test case.
> >> * Refer to compositor as "Wayland server" rather than "Wayland
> >>   display" in wl_display_connect() doxygen comments.
> >> * Remove redundant descriptions of parameter-interpretation
> >>   mechanics from wl_display_connect() manpage. Reworked things
> >>   to make it clear that 'name' and $WAYLAND_DISLAY are each
> >>   capable of encoding absolute server socket paths.
> >> * Remove callout to reference implementation behavior in protocol
> >>   documented. In its place there is now a simple statement that
> >>   implementations can optionally support absolute socket paths.
> >>
> >> 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 
> >> Acked-by: Pekka Paalanen 
> >> Acked-by: Jonas Ådahl 
> >> ---
> >>  doc/man/wl_display_connect.xml|  32 +--
> >>  doc/publican/sources/Protocol.xml |   5 +-
> >>  src/wayland-client.c  |  47 
> >>  tests/socket-test.c   | 109 
> >> ++
> >>  4 files changed, 177 insertions(+), 16 deletions(-)  
> >
> > Hi Matt,
> >
> > this patch is:
> >
> > Reviewed-by: Pekka Paalanen 
> >
> > The wording in the man page sounds little like WAYLAND_DISPLAY
> > accepting an absolute path is a side-effect rather than an intentional
> > feature, but it doesn't matter.
> >
> > Everyone,
> >
> > if there are no objections, I will push this patch on Wednesday, that
> > is in two days. If you want your R-b or Acks recorded that are not
> > already in the above, please send them explicitly.
> >
> >
> > Thanks,
> > pq  
> 
> Hi Pekka,
> 
> Did you ever hear any objections to this one?

Nope, and it's pushed now:
   de24f4d..1b6521e  master -> master

I just forgot yesterday. :-)


Thanks,
pq


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

[PATCH weston v5 00/36] Head-based output configuration API a.k.a clone mode infrastructure

[Pekka Paalanen]

From: Pekka Paalanen 

Hi all,

this is v5 (to match the numbering of my public branches) of the libweston user
facing API and infrastructure for supporting shared-CRTC clone mode.

Previous submission with rationale:
https://lists.freedesktop.org/archives/wayland-devel/2017-October/035604.html

Design document:
https://phabricator.freedesktop.org/w/wayland/weston/atomic-output-config/

The goal:
https://phabricator.freedesktop.org/T7727

Changes in v5 compared to v3 are minor:
- "libweston: properly orphan wl_output resources" is new.
- Removal of wl_output global, when a head is detached from an enabled output.
- Print "Detected a monitor change" only for enabled heads.

You can find this series in the branch:
https://gitlab.collabora.com/pq/weston/commits/clonemode-user-API-5

I went through the same testing procedure as with v3, the previous submission.


However, the interesting bits are in the branch:
https://gitlab.collabora.com/pq/weston/commits/clonemode-4

As new things compared to clonemode-user-API-2, that one contains:
- support for configuring clone mode in weston.ini
- main.c implementation to configure a clode using the new API
- desktop-shell enhancements to avoid redundant panel and background surfaces
  in clone mode
- hooking up custom data to weston_output via a new user-side destroy signal
- naming outputs freely
- DRM-backend support for shared-CRTC clone mode
- video mode list merging in the DRM-backend

The shared-CRTC clone mode has been tested to work on an i.MX6 device.
Unfortunately it seems that PC hardware that would support it is becoming
scarce AFAIU.

Most of the patches in clonemode-4 depend on the atomic modesetting series and
can therefore be submitted only after that one.


Thanks,
pq

Pekka Paalanen (36):
  libweston: introduce weston_head
  libweston: move wl_output to weston_head
  libweston: use head in wl_output global
  libweston: make wl_output point to weston_head
  libweston: refactor weston_mode_switch_finish
  libweston: introduce weston_output::head_list
  libweston: properly orphan wl_output resources
  libweston: strdup head make, model, serial_number
  cms-colord: find a good head
  libweston: add name to weston_head
  libweston: add weston_head::connected
  libweston: add compositor list of heads
  libweston: add heads_changed hook
  libweston: new head-based output management API
  libweston: add weston_head destroy signal
  libweston: add weston_head_is_device_changed() API
  weston: move weston_output_enable() into callers
  weston: migrate headless to head-based output API
  weston: migrate x11 to head-based output API
  weston: migrate wayland to head-based output API
  weston: migrate fbdev to head-based output API
  weston: migrate RDP to head-based output API
  weston: migrate DRM to head-based output API
  libweston: change windowed_output_api output_create to create_head
  libweston: remove output_pending_signal
  libweston: stop auto-adding the implicit head
  libweston: assert make/model in weston_output_enable()
  libweston: assert current_mode in weston_output_enable()
  libweston: cancel idle_repaint on output destroy
  compositor-headless: migrate to head-based output API
  compositor-rdp: migrate to head-based output API
  compositor-fbdev: make re-enable less drastic
  compositor-fbdev: migrate to head-based output API
  compositor-x11: migrate to head-based output API
  compositor-wayland: strict surface create/destroy
  compositor-wayland: migrate to head-based output API

 compositor/cms-colord.c |  38 +-
 compositor/main.c   | 304 +---
 compositor/weston-screenshooter.c   |   2 +-
 desktop-shell/input-panel.c |   4 +-
 desktop-shell/shell.c   |   4 +-
 fullscreen-shell/fullscreen-shell.c |   4 +-
 ivi-shell/input-panel-ivi.c |   4 +-
 libweston-desktop/wl-shell.c|   2 +-
 libweston-desktop/xdg-shell-v5.c|   2 +-
 libweston-desktop/xdg-shell-v6.c|   2 +-
 libweston/compositor-drm.c  |  15 +-
 libweston/compositor-fbdev.c| 206 +---
 libweston/compositor-headless.c |  75 ++-
 libweston/compositor-rdp.c  |  64 ++-
 libweston/compositor-wayland.c  | 254 +++---
 libweston/compositor-x11.c  |  71 ++-
 libweston/compositor.c  | 948 +---
 libweston/compositor.h  | 182 ++-
 libweston/windowed-output-api.h |  23 +-
 tests/weston-test.c |   2 +-
 20 files changed, 1832 insertions(+), 374 deletions(-)

-- 
2.13.6

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

[PATCH weston v5 03/36] libweston: use head in wl_output global

[Pekka Paalanen]

From: Pekka Paalanen 

As a wl_output represents weston_head, use a weston_head pointer as the
wl_output global's user data.

Signed-off-by: Pekka Paalanen 
---
 libweston/compositor.c | 11 +++
 libweston/compositor.h |  2 ++
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index 9f1c6d83..5be9e91e 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -4315,10 +4315,10 @@ static void
 bind_output(struct wl_client *client,
void *data, uint32_t version, uint32_t id)
 {
-   struct weston_output *output = data;
+   struct weston_head *head = data;
+   struct weston_output *output = head->output;
struct weston_mode *mode;
struct wl_resource *resource;
-   struct weston_head *head = &output->head;
 
resource = wl_resource_create(client, &wl_output_interface,
  version, id);
@@ -4328,8 +4328,10 @@ bind_output(struct wl_client *client,
}
 
wl_list_insert(&head->resource_list, wl_resource_get_link(resource));
-   wl_resource_set_implementation(resource, &output_interface, data, 
unbind_resource);
+   wl_resource_set_implementation(resource, &output_interface, output,
+  unbind_resource);
 
+   assert(output);
wl_output_send_geometry(resource,
output->x,
output->y,
@@ -4634,9 +4636,10 @@ weston_compositor_add_output(struct weston_compositor 
*compositor,
output->enabled = true;
 
head = &output->head;
+   head->output = output;
head->global = wl_global_create(compositor->wl_display,
&wl_output_interface, 3,
-   output, bind_output);
+   head, bind_output);
 
wl_signal_emit(&compositor->output_created_signal, output);
 
diff --git a/libweston/compositor.h b/libweston/compositor.h
index 76b966ee..cc74bfc9 100644
--- a/libweston/compositor.h
+++ b/libweston/compositor.h
@@ -153,6 +153,8 @@ enum dpms_enum {
  * (windowed nested backends).
  */
 struct weston_head {
+   struct weston_output *output;   /**< the output driving this head */
+
struct wl_list resource_list;   /**< wl_output protocol objects */
struct wl_global *global;   /**< wl_output global */
 
-- 
2.13.6

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

[PATCH weston v5 02/36] libweston: move wl_output to weston_head

[Pekka Paalanen]

From: Pekka Paalanen 

The wl_output protocol interface exposes things like monitor make,
model, sub-pixel layout and physical dimensions. Obviously wl_output is
meant to represent a monitor.

The abstraction of a monitor is weston_head. Therefore move the wl_output
global and the bound resources list into weston_head.

When clone mode gets implemented in the future, this means that monitors
driven by the same CRTC will still be represented as separate wl_output
globals. This allows to accurately represent the hardware.

Clone mode that used separate, not frame-locked, CRTCs to drive two
monitors as clones would necessarily also be exposed as separate
wl_output since they have different timings.

Signed-off-by: Pekka Paalanen 
---
 libweston/compositor.c | 39 ---
 libweston/compositor.h |  5 +++--
 2 files changed, 27 insertions(+), 17 deletions(-)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index 04ac65d2..9f1c6d83 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -81,6 +81,7 @@ static void weston_mode_switch_finish(struct weston_output 
*output,
  int scale_changed)
 {
struct weston_seat *seat;
+   struct weston_head *head;
struct wl_resource *resource;
pixman_region32_t old_output_region;
int version;
@@ -129,8 +130,10 @@ static void weston_mode_switch_finish(struct weston_output 
*output,
if (!mode_changed && !scale_changed)
return;
 
+   head = &output->head;
+
/* notify clients of the changes */
-   wl_resource_for_each(resource, &output->resource_list) {
+   wl_resource_for_each(resource, &head->resource_list) {
if (mode_changed) {
wl_output_send_mode(resource,
output->current_mode->flags,
@@ -340,10 +343,12 @@ weston_presentation_feedback_present(
uint32_t flags)
 {
struct wl_client *client = wl_resource_get_client(feedback->resource);
+   struct weston_head *head;
struct wl_resource *o;
uint64_t secs;
 
-   wl_resource_for_each(o, &output->resource_list) {
+   head = &output->head;
+   wl_resource_for_each(o, &head->resource_list) {
if (wl_resource_get_client(o) != client)
continue;
 
@@ -921,7 +926,7 @@ weston_view_damage_below(struct weston_view *view)
 /** Send wl_surface.enter/leave events
  *
  * \param surface The surface.
- * \param output The entered/left output.
+ * \param head A head of the entered/left output.
  * \param enter True if entered.
  * \param left True if left.
  *
@@ -930,7 +935,7 @@ weston_view_damage_below(struct weston_view *view)
  */
 static void
 weston_surface_send_enter_leave(struct weston_surface *surface,
-   struct weston_output *output,
+   struct weston_head *head,
bool enter,
bool leave)
 {
@@ -940,7 +945,7 @@ weston_surface_send_enter_leave(struct weston_surface 
*surface,
assert(enter != leave);
 
client = wl_resource_get_client(surface->resource);
-   wl_resource_for_each(wloutput, &output->resource_list) {
+   wl_resource_for_each(wloutput, &head->resource_list) {
if (wl_resource_get_client(wloutput) != client)
continue;
 
@@ -980,7 +985,7 @@ weston_surface_update_output_mask(struct weston_surface 
*es, uint32_t mask)
if (!(output_bit & different))
continue;
 
-   weston_surface_send_enter_leave(es, output,
+   weston_surface_send_enter_leave(es, &output->head,
output_bit & entered,
output_bit & left);
}
@@ -4322,7 +4327,7 @@ bind_output(struct wl_client *client,
return;
}
 
-   wl_list_insert(&output->resource_list, wl_resource_get_link(resource));
+   wl_list_insert(&head->resource_list, wl_resource_get_link(resource));
wl_resource_set_implementation(resource, &output_interface, data, 
unbind_resource);
 
wl_output_send_geometry(resource,
@@ -4576,7 +4581,7 @@ weston_output_move(struct weston_output *output, int x, 
int y)
wl_signal_emit(&output->compositor->output_moved_signal, output);
 
/* Notify clients of the change for output position. */
-   wl_resource_for_each(resource, &output->resource_list) {
+   wl_resource_for_each(resource, &head->resource_list) {
wl_output_send_geometry(resource,
output->x,
output->y,
@@ -4610,6 +4615,7 @@ we

[PATCH weston v5 04/36] libweston: make wl_output point to weston_head

[Pekka Paalanen]

From: Pekka Paalanen 

The user data of a wl_resource representing a wl_output protocol object
used to be a pointer to weston_output. Now that weston_output is being
split, wl_output more accurately refers to weston_head which is a single
monitor.

Change the wl_output user data to point to weston_head.
weston_output_from_resource() is replaced with
weston_head_from_resource().

This change is not strictly necessary, but architecturally it is the
right thing to do. In the future there might appear the need to refer to
a specific head of a cloned pair, for instance.

Signed-off-by: Pekka Paalanen 
---
 compositor/weston-screenshooter.c   | 2 +-
 desktop-shell/input-panel.c | 4 +++-
 desktop-shell/shell.c   | 4 ++--
 fullscreen-shell/fullscreen-shell.c | 4 ++--
 ivi-shell/input-panel-ivi.c | 4 +++-
 libweston-desktop/wl-shell.c| 2 +-
 libweston-desktop/xdg-shell-v5.c| 2 +-
 libweston-desktop/xdg-shell-v6.c| 2 +-
 libweston/compositor.c  | 6 +++---
 libweston/compositor.h  | 4 ++--
 tests/weston-test.c | 2 +-
 11 files changed, 20 insertions(+), 16 deletions(-)

diff --git a/compositor/weston-screenshooter.c 
b/compositor/weston-screenshooter.c
index f0bc0e1e..70afed4a 100644
--- a/compositor/weston-screenshooter.c
+++ b/compositor/weston-screenshooter.c
@@ -66,7 +66,7 @@ screenshooter_shoot(struct wl_client *client,
struct wl_resource *buffer_resource)
 {
struct weston_output *output =
-   weston_output_from_resource(output_resource);
+   weston_head_from_resource(output_resource)->output;
struct weston_buffer *buffer =
weston_buffer_from_resource(buffer_resource);
 
diff --git a/desktop-shell/input-panel.c b/desktop-shell/input-panel.c
index e6b1541a..8292f20a 100644
--- a/desktop-shell/input-panel.c
+++ b/desktop-shell/input-panel.c
@@ -270,11 +270,13 @@ input_panel_surface_set_toplevel(struct wl_client *client,
struct input_panel_surface *input_panel_surface =
wl_resource_get_user_data(resource);
struct desktop_shell *shell = input_panel_surface->shell;
+   struct weston_head *head;
 
wl_list_insert(&shell->input_panel.surfaces,
   &input_panel_surface->link);
 
-   input_panel_surface->output = 
weston_output_from_resource(output_resource);
+   head = weston_head_from_resource(output_resource);
+   input_panel_surface->output = head->output;
input_panel_surface->panel = 0;
 }
 
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index a2a93e2f..40953990 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -2968,7 +2968,7 @@ desktop_shell_set_background(struct wl_client *client,
surface->committed = background_committed;
surface->committed_private = shell;
weston_surface_set_label_func(surface, background_get_label);
-   surface->output = weston_output_from_resource(output_resource);
+   surface->output = weston_head_from_resource(output_resource)->output;
view->output = surface->output;
weston_desktop_shell_send_configure(resource, 0,
surface_resource,
@@ -3053,7 +3053,7 @@ desktop_shell_set_panel(struct wl_client *client,
surface->committed = panel_committed;
surface->committed_private = shell;
weston_surface_set_label_func(surface, panel_get_label);
-   surface->output = weston_output_from_resource(output_resource);
+   surface->output = weston_head_from_resource(output_resource)->output;
view->output = surface->output;
weston_desktop_shell_send_configure(resource, 0,
surface_resource,
diff --git a/fullscreen-shell/fullscreen-shell.c 
b/fullscreen-shell/fullscreen-shell.c
index 6f4565a7..89884794 100644
--- a/fullscreen-shell/fullscreen-shell.c
+++ b/fullscreen-shell/fullscreen-shell.c
@@ -769,7 +769,7 @@ fullscreen_shell_present_surface(struct wl_client *client,
}
 
if (output_res) {
-   output = weston_output_from_resource(output_res);
+   output = weston_head_from_resource(output_res)->output;
fsout = fs_output_for_output(output);
fs_output_set_surface(fsout, surface, method, 0, 0);
} else {
@@ -813,7 +813,7 @@ fullscreen_shell_present_surface_for_mode(struct wl_client 
*client,
struct weston_seat *seat;
struct fs_output *fsout;
 
-   output = weston_output_from_resource(output_res);
+   output = weston_head_from_resource(output_res)->output;
fsout = fs_output_for_output(output);
 
if (surface_res == NULL) {
diff --git a/ivi-shell/input-panel-ivi.c b/ivi-shell/input-panel-ivi.c
index 0008a52d..219494dc 100644
--- a/ivi-shell/input-panel-ivi.c
+++ b/ivi-shell

[PATCH weston v5 05/36] libweston: refactor weston_mode_switch_finish

[Pekka Paalanen]

From: Pekka Paalanen 

Split out a new function. This is a pure refactoring, no change in
behaviour.

This helps a following patch that adds a loop over output->head_list.

Signed-off-by: Pekka Paalanen 
Reviewed-by: Quentin Glidic 
---
 libweston/compositor.c | 57 +++---
 1 file changed, 36 insertions(+), 21 deletions(-)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index 66453ea3..c668aa28 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -76,15 +76,45 @@ weston_output_transform_scale_init(struct weston_output 
*output,
 static void
 weston_compositor_build_view_list(struct weston_compositor *compositor);
 
-static void weston_mode_switch_finish(struct weston_output *output,
- int mode_changed,
- int scale_changed)
+/** Send wl_output events for mode and scale changes
+ *
+ * \param head Send on all resources bound to this head.
+ * \param mode_changed If true, send the current mode.
+ * \param scale_changed If true, send the current scale.
+ */
+static void
+weston_mode_switch_send_events(struct weston_head *head,
+  bool mode_changed, bool scale_changed)
+{
+   struct weston_output *output = head->output;
+   struct wl_resource *resource;
+   int version;
+
+   wl_resource_for_each(resource, &head->resource_list) {
+   if (mode_changed) {
+   wl_output_send_mode(resource,
+   output->current_mode->flags,
+   output->current_mode->width,
+   output->current_mode->height,
+   output->current_mode->refresh);
+   }
+
+   version = wl_resource_get_version(resource);
+   if (version >= WL_OUTPUT_SCALE_SINCE_VERSION && scale_changed)
+   wl_output_send_scale(resource, output->current_scale);
+
+   if (version >= WL_OUTPUT_DONE_SINCE_VERSION)
+   wl_output_send_done(resource);
+   }
+}
+
+static void
+weston_mode_switch_finish(struct weston_output *output,
+ int mode_changed, int scale_changed)
 {
struct weston_seat *seat;
struct weston_head *head;
-   struct wl_resource *resource;
pixman_region32_t old_output_region;
-   int version;
 
pixman_region32_init(&old_output_region);
pixman_region32_copy(&old_output_region, &output->region);
@@ -133,22 +163,7 @@ static void weston_mode_switch_finish(struct weston_output 
*output,
head = &output->head;
 
/* notify clients of the changes */
-   wl_resource_for_each(resource, &head->resource_list) {
-   if (mode_changed) {
-   wl_output_send_mode(resource,
-   output->current_mode->flags,
-   output->current_mode->width,
-   output->current_mode->height,
-   output->current_mode->refresh);
-   }
-
-   version = wl_resource_get_version(resource);
-   if (version >= WL_OUTPUT_SCALE_SINCE_VERSION && scale_changed)
-   wl_output_send_scale(resource, output->current_scale);
-
-   if (version >= WL_OUTPUT_DONE_SINCE_VERSION)
-   wl_output_send_done(resource);
-   }
+   weston_mode_switch_send_events(head, mode_changed, scale_changed);
 }
 
 
-- 
2.13.6

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

[PATCH weston v5 06/36] libweston: introduce weston_output::head_list

[Pekka Paalanen]

From: Pekka Paalanen 

The intention is that in the future backends will dynamically allocate
weston_heads based on the resources they have. The lifetime of a
weston_head will be independent of the lifetime of a weston_output it
may be attached to. Backends allocate objects derived from weston_head,
like they currently do for weston_output. Backend will choose when to
destroy a weston_head.

For clone mode, struct weston_output gains head_list member, which is
the list of attached heads that will all show the same framebuffer.
Since heads are growing out of weston_output, management functions are
added.

Detaching a head from an enabled output is allowed to accommodate
disappearing heads. Attaching a head to an enabled output is disallowed
because it may need hardware reconfiguration and testing, and so
requires a weston_output_enable() call.

As a temporary measure, we have one weston_head embedded in
weston_output, so that backends can be migrated individually to the new
allocation scheme.

Signed-off-by: Pekka Paalanen 
---
 libweston/compositor.c | 216 +++--
 libweston/compositor.h |   7 +-
 2 files changed, 181 insertions(+), 42 deletions(-)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index c668aa28..efa961dc 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -160,13 +160,12 @@ weston_mode_switch_finish(struct weston_output *output,
if (!mode_changed && !scale_changed)
return;
 
-   head = &output->head;
-
/* notify clients of the changes */
-   weston_mode_switch_send_events(head, mode_changed, scale_changed);
+   wl_list_for_each(head, &output->head_list, output_link)
+   weston_mode_switch_send_events(head,
+  mode_changed, scale_changed);
 }
 
-
 static void
 weston_compositor_reflow_outputs(struct weston_compositor *compositor,
struct weston_output *resized_output, int 
delta_width);
@@ -362,12 +361,13 @@ weston_presentation_feedback_present(
struct wl_resource *o;
uint64_t secs;
 
-   head = &output->head;
-   wl_resource_for_each(o, &head->resource_list) {
-   if (wl_resource_get_client(o) != client)
-   continue;
+   wl_list_for_each(head, &output->head_list, output_link) {
+   wl_resource_for_each(o, &head->resource_list) {
+   if (wl_resource_get_client(o) != client)
+   continue;
 
-   wp_presentation_feedback_send_sync_output(feedback->resource, 
o);
+   
wp_presentation_feedback_send_sync_output(feedback->resource, o);
+   }
}
 
secs = ts->tv_sec;
@@ -988,6 +988,7 @@ weston_surface_update_output_mask(struct weston_surface 
*es, uint32_t mask)
uint32_t left = es->output_mask & different;
uint32_t output_bit;
struct weston_output *output;
+   struct weston_head *head;
 
es->output_mask = mask;
if (es->resource == NULL)
@@ -1000,9 +1001,11 @@ weston_surface_update_output_mask(struct weston_surface 
*es, uint32_t mask)
if (!(output_bit & different))
continue;
 
-   weston_surface_send_enter_leave(es, &output->head,
-   output_bit & entered,
-   output_bit & left);
+   wl_list_for_each(head, &output->head_list, output_link) {
+   weston_surface_send_enter_leave(es, head,
+   output_bit & entered,
+   output_bit & left);
+   }
}
 }
 
@@ -4386,6 +4389,98 @@ weston_head_from_resource(struct wl_resource *resource)
return wl_resource_get_user_data(resource);
 }
 
+/** Initialize a pre-allocated weston_head
+ *
+ * \param head The head to initialize.
+ *
+ * The head will be safe to attach, detach and release.
+ *
+ * \memberof weston_head
+ * \internal
+ */
+static void
+weston_head_init(struct weston_head *head)
+{
+   /* Add some (in)sane defaults which can be used
+* for checking if an output was properly configured
+*/
+   memset(head, 0, sizeof *head);
+
+   wl_list_init(&head->output_link);
+   wl_list_init(&head->resource_list);
+}
+
+/** Attach a head to an inactive output
+ *
+ * \param output The output to attach to.
+ * \param head The head that is not yet attached.
+ * \return 0 on success, -1 on failure.
+ *
+ * Attaches the given head to the output. All heads of an output are clones
+ * and share the resolution and timings.
+ *
+ * Cloning heads this way uses less resources than creating an output for
+ * each

[PATCH weston v5 09/36] cms-colord: find a good head

[Pekka Paalanen]

From: Pekka Paalanen 

The 'head' member of 'struct weston_output' is going to go unused and
then disappear, so stop using it and find a head from the proper list.

However, this leaves a problem in cms-colord: if you have multiple
monitors driver with the same CRTC, what do you say to the color
management system? The monitors could be different, but all the color
LUTs etc. are in the CRTC and are shared, as is the framebuffer.

Do the simple hack here and just use whatever head happens to be the
first in the list.

Signed-off-by: Pekka Paalanen 
---
 compositor/cms-colord.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/compositor/cms-colord.c b/compositor/cms-colord.c
index f421773b..9061091b 100644
--- a/compositor/cms-colord.c
+++ b/compositor/cms-colord.c
@@ -102,10 +102,13 @@ edid_value_valid(const char *str)
 static gchar *
 get_output_id(struct cms_colord *cms, struct weston_output *o)
 {
-   struct weston_head *head = &o->head;
+   struct weston_head *head;
const gchar *tmp;
GString *device_id;
 
+   /* XXX: What to do with multiple heads? */
+   head = weston_output_get_first_head(o);
+
/* see 
https://github.com/hughsie/colord/blob/master/doc/device-and-profile-naming-spec.txt
 * for format and allowed values */
device_id = g_string_new("xrandr");
@@ -231,7 +234,7 @@ colord_notifier_output_destroy(struct wl_listener 
*listener, void *data)
 static void
 colord_output_created(struct cms_colord *cms, struct weston_output *o)
 {
-   struct weston_head *head = &o->head;
+   struct weston_head *head;
CdDevice *device;
const gchar *tmp;
gchar *device_id;
@@ -239,6 +242,9 @@ colord_output_created(struct cms_colord *cms, struct 
weston_output *o)
GHashTable *device_props;
struct cms_output *ocms;
 
+   /* XXX: What to do with multiple heads? */
+   head = weston_output_get_first_head(o);
+
/* create device */
device_id = get_output_id(cms, o);
weston_log("colord: output added %s\n", device_id);
-- 
2.13.6

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

[PATCH weston v5 07/36] libweston: properly orphan wl_output resources

[Pekka Paalanen]

From: Pekka Paalanen 

Remove the wl_resource in the head's resource list when we are
removing the wl_output global. We sent global removal events to clients,
the resources should become dummies until clients reap them. Reset user
data so that clients triying to use dummy objects don't hit e.g. a freed
head pointer.

This fixes a theoretical issue: if an enabled output is disabled and
then gets enabled again, mode changes and wl_surface.enter/leave would
still attempt to use the dummy objects. If a client destroyed a dummy
object, we don't have the destructor to remove it from the resource
list, and libweston would hit freed memory.

Signed-off-by: Pekka Paalanen 
---
 libweston/compositor.c | 32 
 1 file changed, 24 insertions(+), 8 deletions(-)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index efa961dc..d314f2d5 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -4374,6 +4374,28 @@ bind_output(struct wl_client *client,
wl_output_send_done(resource);
 }
 
+/** Remove the global wl_output protocol object
+ *
+ * \param head The head whose global to remove.
+ *
+ * Also orphans the wl_resources for this head (wl_output).
+ */
+static void
+weston_head_remove_global(struct weston_head *head)
+{
+   struct wl_resource *resource, *tmp;
+
+   if (head->global)
+   wl_global_destroy(head->global);
+   head->global = NULL;
+
+   wl_resource_for_each_safe(resource, tmp, &head->resource_list) {
+   unbind_resource(resource);
+   wl_resource_set_destructor(resource, NULL);
+   wl_resource_set_user_data(resource, NULL);
+   }
+}
+
 /** Get the backing object of wl_output
  *
  * \param resource A wl_output protocol object.
@@ -4823,7 +4845,6 @@ static void
 weston_compositor_remove_output(struct weston_output *output)
 {
struct weston_compositor *compositor = output->compositor;
-   struct wl_resource *resource;
struct weston_view *view;
struct weston_head *head;
 
@@ -4846,13 +4867,8 @@ weston_compositor_remove_output(struct weston_output 
*output)
wl_signal_emit(&compositor->output_destroyed_signal, output);
wl_signal_emit(&output->destroy_signal, output);
 
-   wl_list_for_each(head, &output->head_list, output_link) {
-   wl_global_destroy(head->global);
-   head->global = NULL;
-
-   wl_resource_for_each(resource, &head->resource_list)
-   wl_resource_set_destructor(resource, NULL);
-   }
+   wl_list_for_each(head, &output->head_list, output_link)
+   weston_head_remove_global(head);
 
compositor->output_id_pool &= ~(1u << output->id);
output->id = 0x; /* invalid */
-- 
2.13.6

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

[PATCH weston v5 08/36] libweston: strdup head make, model, serial_number

[Pekka Paalanen]

From: Pekka Paalanen 

Duplicate these strings to decouple their lifetime from whatever the
backends used. This should prevent hard to catch use after frees and
such problems in the future.

Signed-off-by: Pekka Paalanen 
Reviewed-by: Quentin Glidic 
---
 libweston/compositor.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index d314f2d5..1e62254a 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -4501,6 +4501,10 @@ static void
 weston_head_release(struct weston_head *head)
 {
weston_head_detach(head);
+
+   free(head->make);
+   free(head->model);
+   free(head->serial_number);
 }
 
 /** Store monitor make, model and serial number
@@ -4522,9 +4526,13 @@ weston_head_set_monitor_strings(struct weston_head *head,
const char *model,
const char *serialno)
 {
-   head->make = (char *)make;
-   head->model = (char *)model;
-   head->serial_number = (char *)serialno;
+   free(head->make);
+   free(head->model);
+   free(head->serial_number);
+
+   head->make = make ? strdup(make) : NULL;
+   head->model = model ? strdup(model) : NULL;
+   head->serial_number = serialno ? strdup(serialno) : NULL;
 }
 
 /** Store physical image size
-- 
2.13.6

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

[PATCH weston v5 01/36] libweston: introduce weston_head

[Pekka Paalanen]

From: Pekka Paalanen 

In order to support clone modes, libweston needs the concept of a head
that is separate from weston_output. While weston_output manages buffers
and the repaint state machine, weston_head will represent a single
monitor. In the future it will be possible to have a single
weston_output drive one or more weston_heads for a clone mode that
shares the framebuffers between all cloned heads.

All the fields that are obviously properties of the monitor are moved
from weston_output into weston_head.

As moving the fields requires one to touch all the backends for all the
assingments, introduce setter functions for them while we are here. The
setters are identical to the old assignments, for now.

As a temporary measure, weston_output embeds a single head. Also the
ugly casts in weston_head_set_monitor_strings() will be removed by a
follow-up patch.

Signed-off-by: Pekka Paalanen 
---
 compositor/cms-colord.c |  32 ++--
 libweston/compositor-drm.c  |  15 +++---
 libweston/compositor-fbdev.c|  12 +++--
 libweston/compositor-headless.c |   8 +--
 libweston/compositor-rdp.c  |   8 +--
 libweston/compositor-wayland.c  |  18 ---
 libweston/compositor-x11.c  |  13 +++--
 libweston/compositor.c  | 105 +++-
 libweston/compositor.h  |  38 +--
 9 files changed, 184 insertions(+), 65 deletions(-)

diff --git a/compositor/cms-colord.c b/compositor/cms-colord.c
index 0daa2a7e..f421773b 100644
--- a/compositor/cms-colord.c
+++ b/compositor/cms-colord.c
@@ -102,22 +102,23 @@ edid_value_valid(const char *str)
 static gchar *
 get_output_id(struct cms_colord *cms, struct weston_output *o)
 {
+   struct weston_head *head = &o->head;
const gchar *tmp;
GString *device_id;
 
/* see 
https://github.com/hughsie/colord/blob/master/doc/device-and-profile-naming-spec.txt
 * for format and allowed values */
device_id = g_string_new("xrandr");
-   if (edid_value_valid(o->make)) {
-   tmp = g_hash_table_lookup(cms->pnp_ids, o->make);
+   if (edid_value_valid(head->make)) {
+   tmp = g_hash_table_lookup(cms->pnp_ids, head->make);
if (tmp == NULL)
-   tmp = o->make;
+   tmp = head->make;
g_string_append_printf(device_id, "-%s", tmp);
}
-   if (edid_value_valid(o->model))
-   g_string_append_printf(device_id, "-%s", o->model);
-   if (edid_value_valid(o->serial_number))
-   g_string_append_printf(device_id, "-%s", o->serial_number);
+   if (edid_value_valid(head->model))
+   g_string_append_printf(device_id, "-%s", head->model);
+   if (edid_value_valid(head->serial_number))
+   g_string_append_printf(device_id, "-%s", head->serial_number);
 
/* no EDID data, so use fallback */
if (strcmp(device_id->str, "xrandr") == 0)
@@ -230,6 +231,7 @@ colord_notifier_output_destroy(struct wl_listener 
*listener, void *data)
 static void
 colord_output_created(struct cms_colord *cms, struct weston_output *o)
 {
+   struct weston_head *head = &o->head;
CdDevice *device;
const gchar *tmp;
gchar *device_id;
@@ -251,25 +253,25 @@ colord_output_created(struct cms_colord *cms, struct 
weston_output *o)
g_hash_table_insert (device_props,
 g_strdup(CD_DEVICE_PROPERTY_COLORSPACE),
 
g_strdup(cd_colorspace_to_string(CD_COLORSPACE_RGB)));
-   if (edid_value_valid(o->make)) {
-   tmp = g_hash_table_lookup(cms->pnp_ids, o->make);
+   if (edid_value_valid(head->make)) {
+   tmp = g_hash_table_lookup(cms->pnp_ids, head->make);
if (tmp == NULL)
-   tmp = o->make;
+   tmp = head->make;
g_hash_table_insert (device_props,
 g_strdup(CD_DEVICE_PROPERTY_VENDOR),
 g_strdup(tmp));
}
-   if (edid_value_valid(o->model)) {
+   if (edid_value_valid(head->model)) {
g_hash_table_insert (device_props,
 g_strdup(CD_DEVICE_PROPERTY_MODEL),
-g_strdup(o->model));
+g_strdup(head->model));
}
-   if (edid_value_valid(o->serial_number)) {
+   if (edid_value_valid(head->serial_number)) {
g_hash_table_insert (device_props,
 g_strdup(CD_DEVICE_PROPERTY_SERIAL),
-g_strdup(o->serial_number));
+g_strdup(head->serial_number));
  

[PATCH weston v5 10/36] libweston: add name to weston_head

[Pekka Paalanen]

From: Pekka Paalanen 

Heads need to be named, so they can be referenced in logs and
configuration sources.

When clone mode is implemented, output and head names may differ.

Signed-off-by: Pekka Paalanen 
---
 libweston/compositor.c | 10 --
 libweston/compositor.h |  2 ++
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index 1e62254a..b0d1629e 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -4414,14 +4414,18 @@ weston_head_from_resource(struct wl_resource *resource)
 /** Initialize a pre-allocated weston_head
  *
  * \param head The head to initialize.
+ * \param name The head name, e.g. the connector name or equivalent.
  *
  * The head will be safe to attach, detach and release.
  *
+ * The name is used in logs, and can be used by compositors as a configuration
+ * identifier.
+ *
  * \memberof weston_head
  * \internal
  */
 static void
-weston_head_init(struct weston_head *head)
+weston_head_init(struct weston_head *head, const char *name)
 {
/* Add some (in)sane defaults which can be used
 * for checking if an output was properly configured
@@ -4430,6 +4434,7 @@ weston_head_init(struct weston_head *head)
 
wl_list_init(&head->output_link);
wl_list_init(&head->resource_list);
+   head->name = strdup(name);
 }
 
 /** Attach a head to an inactive output
@@ -4505,6 +4510,7 @@ weston_head_release(struct weston_head *head)
free(head->make);
free(head->model);
free(head->serial_number);
+   free(head->name);
 }
 
 /** Store monitor make, model and serial number
@@ -4961,7 +4967,7 @@ weston_output_init(struct weston_output *output,
 
wl_list_init(&output->head_list);
 
-   weston_head_init(&output->head);
+   weston_head_init(&output->head, name);
 
/* Add some (in)sane defaults which can be used
 * for checking if an output was properly configured
diff --git a/libweston/compositor.h b/libweston/compositor.h
index 456adcc8..02b5fa32 100644
--- a/libweston/compositor.h
+++ b/libweston/compositor.h
@@ -166,6 +166,8 @@ struct weston_head {
char *serial_number;/**< monitor serial */
uint32_t subpixel;  /**< enum wl_output_subpixel */
bool connection_internal;   /**< embedded monitor (e.g. laptop) */
+
+   char *name; /**< head name, e.g. connector name */
 };
 
 struct weston_output {
-- 
2.13.6

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

[PATCH weston v5 11/36] libweston: add weston_head::connected

[Pekka Paalanen]

From: Pekka Paalanen 

Heads may be disconnected or connected and the compositor needs to be
able to know the state to know which heads to take into use.

Currently a single head is automatically created with an output, and
outputs are only ever created as connected and destroyed on
disconnection, so it suffices to set connected to true. In the future,
backends are expected to create heads for both connected and
disconnected connectors, so that a connector can be forced on without it
being actually connected.

Signed-off-by: Pekka Paalanen 
---
 libweston/compositor.c | 64 ++
 libweston/compositor.h | 10 
 2 files changed, 74 insertions(+)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index b0d1629e..349803e8 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -4597,6 +4597,69 @@ weston_head_set_internal(struct weston_head *head)
head->connection_internal = true;
 }
 
+/** Store connector status
+ *
+ * \param head The head to modify.
+ * \param connected Whether the head is connected.
+ *
+ * Connectors are created as disconnected. This function can be used to
+ * set the connector status.
+ *
+ * The status should be set to true when a physical connector is connected to
+ * a video sink device like a monitor and to false when the connector is
+ * disconnected. For nested backends, the connection status should reflect the
+ * connection to the parent display server.
+ *
+ * \memberof weston_head
+ * \internal
+ */
+WL_EXPORT void
+weston_head_set_connection_status(struct weston_head *head, bool connected)
+{
+   head->connected = connected;
+}
+
+/** Is the head currently connected?
+ *
+ * \param head The head to query.
+ * \return Connection status.
+ *
+ * Returns true if the head is physically connected to a monitor, or in
+ * case of a nested backend returns true when there is a connection to the
+ * parent display server.
+ *
+ * This is independent from the head being enabled.
+ *
+ * \sa weston_head_is_enabled
+ * \memberof weston_head
+ */
+WL_EXPORT bool
+weston_head_is_connected(struct weston_head *head)
+{
+   return head->connected;
+}
+
+/** Is the head currently enabled?
+ *
+ * \param head The head to query.
+ * \return Video status.
+ *
+ * Returns true if the head is currently transmitting a video stream.
+ *
+ * This is independent of the head being connected.
+ *
+ * \sa weston_head_is_connected
+ * \memberof weston_head
+ */
+WL_EXPORT bool
+weston_head_is_enabled(struct weston_head *head)
+{
+   if (!head->output)
+   return false;
+
+   return head->output->enabled;
+}
+
 /* Move other outputs when one is resized so the space remains contiguous. */
 static void
 weston_compositor_reflow_outputs(struct weston_compositor *compositor,
@@ -4968,6 +5031,7 @@ weston_output_init(struct weston_output *output,
wl_list_init(&output->head_list);
 
weston_head_init(&output->head, name);
+   weston_head_set_connection_status(&output->head, true);
 
/* Add some (in)sane defaults which can be used
 * for checking if an output was properly configured
diff --git a/libweston/compositor.h b/libweston/compositor.h
index 02b5fa32..d14dd6dc 100644
--- a/libweston/compositor.h
+++ b/libweston/compositor.h
@@ -168,6 +168,7 @@ struct weston_head {
bool connection_internal;   /**< embedded monitor (e.g. laptop) */
 
char *name; /**< head name, e.g. connector name */
+   bool connected; /**< is physically connected */
 };
 
 struct weston_output {
@@ -1966,8 +1967,17 @@ weston_head_set_subpixel(struct weston_head *head,
 enum wl_output_subpixel sp);
 
 void
+weston_head_set_connection_status(struct weston_head *head, bool connected);
+
+void
 weston_head_set_internal(struct weston_head *head);
 
+bool
+weston_head_is_connected(struct weston_head *head);
+
+bool
+weston_head_is_enabled(struct weston_head *head);
+
 void
 weston_output_set_scale(struct weston_output *output,
int32_t scale);
-- 
2.13.6

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

[PATCH weston v5 15/36] libweston: add weston_head destroy signal

[Pekka Paalanen]

From: Pekka Paalanen 

Add support for subscribing to weston_head destruction.

The primary use case for heads being destroyed arbitrarily is the
DRM-backend with MST connectors, which may disappear on unplug. It is
not just the connector becoming disconnected, it is the connector
actually disappearing.

The compositor needs to know about disappearing heads so that it has a
chance to clean up "orphaned" outputs which do get disabled but still
need destroying at run time. Shutdown would destroy them as well.

Signed-off-by: Pekka Paalanen 
---
 libweston/compositor.c | 45 +
 libweston/compositor.h |  9 +
 2 files changed, 54 insertions(+)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index a43ee277..86efcfad 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -4433,6 +4433,7 @@ weston_head_init(struct weston_head *head, const char 
*name)
memset(head, 0, sizeof *head);
 
wl_list_init(&head->compositor_link);
+   wl_signal_init(&head->destroy_signal);
wl_list_init(&head->output_link);
wl_list_init(&head->resource_list);
head->name = strdup(name);
@@ -4701,6 +4702,8 @@ weston_head_detach(struct weston_head *head)
 WL_EXPORT void
 weston_head_release(struct weston_head *head)
 {
+   wl_signal_emit(&head->destroy_signal, head);
+
weston_head_detach(head);
 
free(head->make);
@@ -4893,6 +4896,48 @@ weston_head_get_output(struct weston_head *head)
return head->output;
 }
 
+/** Add destroy callback for a head
+ *
+ * \param head The head to watch for.
+ * \param listener The listener to add. The \c notify member must be set.
+ *
+ * Heads may get destroyed for various reasons by the backends. If a head is
+ * attached to an output, the compositor should listen for head destruction
+ * and reconfigure or destroy the output if necessary.
+ *
+ * The destroy callbacks will be called on weston_head destruction before any
+ * automatic detaching from an associated weston_output and before any
+ * weston_head information is lost.
+ *
+ * The \c data argument to the notify callback is the weston_head being
+ * destroyed.
+ */
+WL_EXPORT void
+weston_head_add_destroy_listener(struct weston_head *head,
+struct wl_listener *listener)
+{
+   wl_signal_add(&head->destroy_signal, listener);
+}
+
+/** Look up destroy listener for a head
+ *
+ * \param head The head to query.
+ * \param notify The notify function used used for the added destroy listener.
+ * \return The listener, or NULL if not found.
+ *
+ * This looks up the previously added destroy listener struct based on the
+ * notify function it has. The listener can be used to access user data
+ * through \c container_of().
+ *
+ * \sa wl_signal_get()
+ */
+WL_EXPORT struct wl_listener *
+weston_head_get_destroy_listener(struct weston_head *head,
+wl_notify_func_t notify)
+{
+   return wl_signal_get(&head->destroy_signal, notify);
+}
+
 /* Move other outputs when one is resized so the space remains contiguous. */
 static void
 weston_compositor_reflow_outputs(struct weston_compositor *compositor,
diff --git a/libweston/compositor.h b/libweston/compositor.h
index f9d034c3..af61215e 100644
--- a/libweston/compositor.h
+++ b/libweston/compositor.h
@@ -155,6 +155,7 @@ enum dpms_enum {
 struct weston_head {
struct weston_compositor *compositor;   /**< owning compositor */
struct wl_list compositor_link; /**< in weston_compositor::head_list */
+   struct wl_signal destroy_signal;/**< destroy callbacks */
 
struct weston_output *output;   /**< the output driving this head */
struct wl_list output_link; /**< in weston_output::head_list */
@@ -2049,6 +2050,14 @@ weston_head_get_output(struct weston_head *head);
 void
 weston_head_detach(struct weston_head *head);
 
+void
+weston_head_add_destroy_listener(struct weston_head *head,
+struct wl_listener *listener);
+
+struct wl_listener *
+weston_head_get_destroy_listener(struct weston_head *head,
+wl_notify_func_t notify);
+
 struct weston_head *
 weston_compositor_iterate_heads(struct weston_compositor *compositor,
struct weston_head *iter);
-- 
2.13.6

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

[PATCH weston v5 14/36] libweston: new head-based output management API

[Pekka Paalanen]

From: Pekka Paalanen 

Introduce the API for users (compositors) to create an output from a
head, attach and detach heads, and destroy outputs created this way.
This also adds the backend-facing API to libweston.

In the new API design, a backend creates heads, and the compositor
chooses one or more heads (clone mode) to be driven by an output.
In the future backends will be converted to not create outputs directly
but only in the new create_output hook.

The user subscribes to a heads_changed hook and arranges heads into
outputs from there.

Adding the API this way will allow frontends (main.c) and backends to be
converted one by one. This adds compatiblity paths in
weston_compositor_create_output_with_head() and weston_output_destroy()
so that frontends can be converted first to call these, and then
backends can be converted one by one to the new design. Afterwards, the
compatibility paths will be removed along with weston_output::head.

Currently heads can be added to a disabled output only. This is less
than ideal for clone mode hotplug and should be improved on later.

v4: Remove the wl_output global on head detach if output is enabled.

Signed-off-by: Pekka Paalanen 
---
 libweston/compositor.c | 187 ++---
 libweston/compositor.h |  78 +
 2 files changed, 256 insertions(+), 9 deletions(-)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index 1d436522..a43ee277 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -4424,7 +4424,7 @@ weston_head_from_resource(struct wl_resource *resource)
  * \memberof weston_head
  * \internal
  */
-static void
+WL_EXPORT void
 weston_head_init(struct weston_head *head, const char *name)
 {
/* Add some (in)sane defaults which can be used
@@ -4483,7 +4483,7 @@ weston_compositor_schedule_heads_changed(struct 
weston_compositor *compositor)
  * \memberof weston_compositor
  * \internal
  */
-static void
+WL_EXPORT void
 weston_compositor_add_head(struct weston_compositor *compositor,
   struct weston_head *head)
 {
@@ -4564,6 +4564,52 @@ weston_compositor_iterate_heads(struct weston_compositor 
*compositor,
return container_of(node, struct weston_head, compositor_link);
 }
 
+/** Iterate over attached heads
+ *
+ * \param output The output whose heads to iterate.
+ * \param item The iterator, or NULL for start.
+ * \return The next attached head in the list.
+ *
+ * Returns all heads currently attached to the output.
+ *
+ * You can iterate over all heads as follows:
+ * \code
+ * struct weston_head *head = NULL;
+ *
+ * while ((head = weston_output_iterate_heads(output, head))) {
+ * ...
+ * }
+ * \endcode
+ *
+ *  If you cause \c iter to be removed from the list, you cannot use it to
+ * continue iterating. Removing any other item is safe.
+ *
+ * \memberof weston_compositor
+ */
+WL_EXPORT struct weston_head *
+weston_output_iterate_heads(struct weston_output *output,
+   struct weston_head *iter)
+{
+   struct wl_list *list = &output->head_list;
+   struct wl_list *node;
+
+   assert(output);
+   assert(!iter || iter->output == output);
+
+   if (iter)
+   node = iter->output_link.next;
+   else
+   node = list->next;
+
+   assert(node);
+   assert(!iter || node != &iter->output_link);
+
+   if (node == list)
+   return NULL;
+
+   return container_of(node, struct weston_head, output_link);
+}
+
 /** Attach a head to an inactive output
  *
  * \param output The output to attach to.
@@ -4583,7 +4629,7 @@ weston_compositor_iterate_heads(struct weston_compositor 
*compositor,
  *
  * \memberof weston_output
  */
-static int
+WL_EXPORT int
 weston_output_attach_head(struct weston_output *output,
  struct weston_head *head)
 {
@@ -4593,9 +4639,13 @@ weston_output_attach_head(struct weston_output *output,
if (!wl_list_empty(&head->output_link))
return -1;
 
-   /* XXX: no support for multi-head yet */
-   if (!wl_list_empty(&output->head_list))
+   if (output->attach_head) {
+   if (output->attach_head(output, head) < 0)
+   return -1;
+   } else if (!wl_list_empty(&output->head_list)) {
+   /* No support for clones in the legacy path. */
return -1;
+   }
 
head->output = output;
wl_list_insert(output->head_list.prev, &head->output_link);
@@ -4609,14 +4659,33 @@ weston_output_attach_head(struct weston_output *output,
  *
  * It is safe to detach a non-attached head.
  *
+ * If the head is attached to an enabled output and the output will be left
+ * with no heads, the output will be disabled.
+ *
  * \memberof weston_head
+ * \sa weston_output_disable
  */
-static void
+WL_EXPORT void
 weston_head_detach(struct weston_

[PATCH weston v5 13/36] libweston: add heads_changed hook

[Pekka Paalanen]

From: Pekka Paalanen 

Add a hook for compositors to get a callback when heads are added or
their connection status changes, to which compositors likely want to
react to by enabling or disabling outputs (API for that to be added
later).

As many head changes as possible should be coalesced into a single
heads_changed call. Therefore the callback is made from an idle task.
This anticipates a future atomic output configuration API, where the
global output configuration is tested and set atomically instead of one
by one.

weston_pending_output_coldplug() needs to manually execute the
heads_changed call so that initial outputs are created before any
plugins get their start-up idle tasks ran. This is especially important
for ivi-shell which does not support output hotplug, and for tests to
guarantee the expected outputs.

Signed-off-by: Pekka Paalanen 
---
 libweston/compositor.c | 79 +-
 libweston/compositor.h |  8 +
 2 files changed, 86 insertions(+), 1 deletion(-)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index 99299c9f..1d436522 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -4438,12 +4438,47 @@ weston_head_init(struct weston_head *head, const char 
*name)
head->name = strdup(name);
 }
 
+/** Idle task for calling heads_changed callback */
+static void
+weston_compositor_call_heads_changed(void *data)
+{
+   struct weston_compositor *compositor = data;
+
+   compositor->heads_changed_source = NULL;
+
+   if (!compositor->heads_changed)
+   return;
+
+   compositor->heads_changed(compositor);
+}
+
+/** Schedule a call on idle to heads_changed callback
+ *
+ * \param compositor The Compositor.
+ *
+ * \memberof weston_compositor
+ * \internal
+ */
+static void
+weston_compositor_schedule_heads_changed(struct weston_compositor *compositor)
+{
+   struct wl_event_loop *loop;
+
+   if (compositor->heads_changed_source)
+   return;
+
+   loop = wl_display_get_event_loop(compositor->wl_display);
+   compositor->heads_changed_source = wl_event_loop_add_idle(loop,
+   weston_compositor_call_heads_changed, compositor);
+}
+
 /** Register a new head
  *
  * \param compositor The compositor.
  * \param head The head to register, must not be already registered.
  *
- * This signals the core that a new head has become available.
+ * This signals the core that a new head has become available, leading to
+ * heads_changed hook being called later.
  *
  * \memberof weston_compositor
  * \internal
@@ -4457,6 +4492,30 @@ weston_compositor_add_head(struct weston_compositor 
*compositor,
 
wl_list_insert(compositor->head_list.prev, &head->compositor_link);
head->compositor = compositor;
+   weston_compositor_schedule_heads_changed(compositor);
+}
+
+/** Set the function to be called when heads change
+ *
+ * \param compositor The compositor.
+ * \param cb The function to call, or NULL for none.
+ *
+ * Setting the function overrides any previous setting.
+ *
+ * The callback function will be called after heads are added or their
+ * connection status has changed. Several changes may be accumulated into a
+ * single call. The user is expected to iterate over the existing heads and
+ * checking their status to find out what changed.
+ *
+ * \sa weston_compositor_iterate_heads, weston_head_is_connected,
+ * weston_head_is_enabled
+ * \memberof weston_compositor
+ */
+WL_EXPORT void
+weston_compositor_set_heads_changed_cb(struct weston_compositor *compositor,
+  weston_heads_changed_func_t cb)
+{
+   compositor->heads_changed = cb;
 }
 
 /** Iterate over available heads
@@ -4680,13 +4739,23 @@ weston_head_set_internal(struct weston_head *head)
  * disconnected. For nested backends, the connection status should reflect the
  * connection to the parent display server.
  *
+ * When the connection status changes, it schedules a call to the heads_changed
+ * hook.
+ *
+ * \sa weston_compositor_set_heads_changed_cb
  * \memberof weston_head
  * \internal
  */
 WL_EXPORT void
 weston_head_set_connection_status(struct weston_head *head, bool connected)
 {
+   if (head->connected == connected)
+   return;
+
head->connected = connected;
+
+   if (head->compositor)
+   weston_compositor_schedule_heads_changed(head->compositor);
 }
 
 /** Is the head currently connected?
@@ -5296,6 +5365,11 @@ weston_pending_output_coldplug(struct weston_compositor 
*compositor)
 
wl_list_for_each_safe(output, next, &compositor->pending_output_list, 
link)
wl_signal_emit(&compositor->output_pending_signal, output);
+
+   if (compositor->heads_changed_source) {
+   wl_event_source_remove(compositor->heads_changed_source);
+   weston_compositor_call_heads_changed(compo

[PATCH weston v5 20/36] weston: migrate wayland to head-based output API

[Pekka Paalanen]

From: Pekka Paalanen 

Migrate the Wayland frontend to use the new head-based output
configuration API: listen for heads_changed, and process all heads.

Signed-off-by: Pekka Paalanen 
---
 compositor/main.c | 27 ---
 1 file changed, 8 insertions(+), 19 deletions(-)

diff --git a/compositor/main.c b/compositor/main.c
index f8e84b09..6eb755e5 100644
--- a/compositor/main.c
+++ b/compositor/main.c
@@ -1751,19 +1751,9 @@ load_x11_backend(struct weston_compositor *c,
return 0;
 }
 
-static void
-wayland_backend_output_configure_hotplug(struct wl_listener *listener, void 
*data)
-{
-   struct weston_output *output = data;
-
-   /* This backend has all values hardcoded, so nothing can be configured 
here */
-   weston_output_enable(output);
-}
-
-static void
-wayland_backend_output_configure(struct wl_listener *listener, void *data)
+static int
+wayland_backend_output_configure(struct weston_output *output)
 {
-   struct weston_output *output = data;
struct wet_output_config defaults = {
.width = 1024,
.height = 640,
@@ -1771,10 +1761,7 @@ wayland_backend_output_configure(struct wl_listener 
*listener, void *data)
.transform = WL_OUTPUT_TRANSFORM_NORMAL
};
 
-   if (wet_configure_windowed_output_from_config(output, &defaults) < 0)
-   weston_log("Cannot configure output \"%s\".\n", output->name);
-
-   weston_output_enable(output);
+   return wet_configure_windowed_output_from_config(output, &defaults);
 }
 
 static int
@@ -1841,13 +1828,15 @@ load_wayland_backend(struct weston_compositor *c,
if (api == NULL) {
/* We will just assume if load_backend() finished cleanly and
 * windowed_output_api is not present that wayland backend is
-* started with --sprawl or runs on fullscreen-shell. */
-   wet_set_pending_output_handler(c, 
wayland_backend_output_configure_hotplug);
+* started with --sprawl or runs on fullscreen-shell.
+* In this case, all values are hardcoded, so nothing can be
+* configured; simply create and enable an output. */
+   wet_set_simple_head_configurator(c, NULL);
 
return 0;
}
 
-   wet_set_pending_output_handler(c, wayland_backend_output_configure);
+   wet_set_simple_head_configurator(c, wayland_backend_output_configure);
 
section = NULL;
while (weston_config_next_section(wc, §ion, §ion_name)) {
-- 
2.13.6

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

[PATCH weston v5 19/36] weston: migrate x11 to head-based output API

[Pekka Paalanen]

From: Pekka Paalanen 

Migrate the x11 frontend to use the new head-based output configuration
API: listen for heads_changed, and process all heads.

Signed-off-by: Pekka Paalanen 
---
 compositor/main.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/compositor/main.c b/compositor/main.c
index 0f822f7f..f8e84b09 100644
--- a/compositor/main.c
+++ b/compositor/main.c
@@ -1646,10 +1646,9 @@ out:
return ret;
 }
 
-static void
-x11_backend_output_configure(struct wl_listener *listener, void *data)
+static int
+x11_backend_output_configure(struct weston_output *output)
 {
-   struct weston_output *output = data;
struct wet_output_config defaults = {
.width = 1024,
.height = 600,
@@ -1657,10 +1656,7 @@ x11_backend_output_configure(struct wl_listener 
*listener, void *data)
.transform = WL_OUTPUT_TRANSFORM_NORMAL
};
 
-   if (wet_configure_windowed_output_from_config(output, &defaults) < 0)
-   weston_log("Cannot configure output \"%s\".\n", output->name);
-
-   weston_output_enable(output);
+   return wet_configure_windowed_output_from_config(output, &defaults);
 }
 
 static int
@@ -1696,6 +1692,8 @@ load_x11_backend(struct weston_compositor *c,
config.base.struct_version = WESTON_X11_BACKEND_CONFIG_VERSION;
config.base.struct_size = sizeof(struct weston_x11_backend_config);
 
+   wet_set_simple_head_configurator(c, x11_backend_output_configure);
+
/* load the actual backend and configure it */
ret = weston_compositor_load_backend(c, WESTON_BACKEND_X11,
 &config.base);
@@ -1703,8 +1701,6 @@ load_x11_backend(struct weston_compositor *c,
if (ret < 0)
return ret;
 
-   wet_set_pending_output_handler(c, x11_backend_output_configure);
-
api = weston_windowed_output_get_api(c);
 
if (!api) {
-- 
2.13.6

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

[PATCH weston v5 18/36] weston: migrate headless to head-based output API

[Pekka Paalanen]

From: Pekka Paalanen 

Migrate the headless frontend to use the new head-based output
configuration API: listen for heads_changed, and process all heads.

The simple_heads_changed() function is written to be able to cater for
all backends. The rest will be migrated individually.

The head destroy listeners are not exactly necessary, for headless
anyway, but this is an example excercising the API. Also
is_device_changed() check is mostly useful with DRM.

v3: Print "Detected a monitor change" only for enabled heads.

Signed-off-by: Pekka Paalanen 
---
 compositor/main.c | 197 +++---
 1 file changed, 187 insertions(+), 10 deletions(-)

diff --git a/compositor/main.c b/compositor/main.c
index 995e6f94..0f822f7f 100644
--- a/compositor/main.c
+++ b/compositor/main.c
@@ -74,11 +74,19 @@ struct wet_output_config {
uint32_t transform;
 };
 
+struct wet_compositor;
+
+struct wet_head_tracker {
+   struct wl_listener head_destroy_listener;
+};
+
 struct wet_compositor {
struct weston_config *config;
struct wet_output_config *parsed_options;
struct wl_listener pending_output_listener;
bool drm_use_current_mode;
+   int (*simple_output_configure)(struct weston_output *output);
+   bool init_failed;
 };
 
 static FILE *weston_logfile = NULL;
@@ -1125,6 +1133,177 @@ wet_configure_windowed_output_from_config(struct 
weston_output *output,
return 0;
 }
 
+static int
+count_remaining_heads(struct weston_output *output, struct weston_head *to_go)
+{
+   struct weston_head *iter = NULL;
+   int n = 0;
+
+   while ((iter = weston_output_iterate_heads(output, iter))) {
+   if (iter != to_go)
+   n++;
+   }
+
+   return n;
+}
+
+static void
+wet_head_tracker_destroy(struct wet_head_tracker *track)
+{
+   wl_list_remove(&track->head_destroy_listener.link);
+   free(track);
+}
+
+static void
+handle_head_destroy(struct wl_listener *listener, void *data)
+{
+   struct weston_head *head = data;
+   struct weston_output *output;
+   struct wet_head_tracker *track =
+   container_of(listener, struct wet_head_tracker,
+head_destroy_listener);
+
+   wet_head_tracker_destroy(track);
+
+   output = weston_head_get_output(head);
+
+   /* On shutdown path, the output might be already gone. */
+   if (!output)
+   return;
+
+   if (count_remaining_heads(output, head) > 0)
+   return;
+
+   weston_output_destroy(output);
+}
+
+static struct wet_head_tracker *
+wet_head_tracker_from_head(struct weston_head *head)
+{
+   struct wl_listener *lis;
+
+   lis = weston_head_get_destroy_listener(head, handle_head_destroy);
+   if (!lis)
+   return NULL;
+
+   return container_of(lis, struct wet_head_tracker,
+   head_destroy_listener);
+}
+
+/* Listen for head destroy signal.
+ *
+ * If a head is destroyed, we also destroy the associated output.
+ *
+ * Do not bother destroying the head trackers on shutdown, the backend will
+ * destroy the heads which calls our handler to destroy the trackers.
+ */
+static void
+wet_head_tracker_create(struct wet_compositor *compositor,
+   struct weston_head *head)
+{
+   struct wet_head_tracker *track;
+
+   track = zalloc(sizeof *track);
+   if (!track)
+   return;
+
+   track->head_destroy_listener.notify = handle_head_destroy;
+   weston_head_add_destroy_listener(head, &track->head_destroy_listener);
+}
+
+static void
+simple_head_enable(struct weston_compositor *compositor, struct weston_head 
*head)
+{
+   struct wet_compositor *wet = to_wet_compositor(compositor);
+   struct weston_output *output;
+   int ret = 0;
+
+   output = weston_compositor_create_output_with_head(compositor, head);
+   if (!output) {
+   weston_log("Could not create an output for head \"%s\".\n",
+  weston_head_get_name(head));
+   wet->init_failed = true;
+
+   return;
+   }
+
+   if (wet->simple_output_configure)
+   ret = wet->simple_output_configure(output);
+   if (ret < 0) {
+   weston_log("Cannot configure output \"%s\".\n",
+  weston_head_get_name(head));
+   weston_output_destroy(output);
+   wet->init_failed = true;
+
+   return;
+   }
+
+   if (weston_output_enable(output) < 0) {
+   weston_log("Enabling output \"%s\" failed.\n",
+  weston_head_get_name(head));
+   weston_output_destroy(output);
+   wet->init_failed = true;
+
+   return;
+   }
+
+   wet_head_tracker_create

[PATCH weston v5 17/36] weston: move weston_output_enable() into callers

[Pekka Paalanen]

From: Pekka Paalanen 

Move the call out of wet_configure_windowed_output_from_config() and
into its callers.

This allows to migrate each frontend one by one.

Signed-off-by: Pekka Paalanen 
---
 compositor/main.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/compositor/main.c b/compositor/main.c
index 32fb33e8..995e6f94 100644
--- a/compositor/main.c
+++ b/compositor/main.c
@@ -1122,8 +1122,6 @@ wet_configure_windowed_output_from_config(struct 
weston_output *output,
return -1;
}
 
-   weston_output_enable(output);
-
return 0;
 }
 
@@ -1266,6 +1264,8 @@ headless_backend_output_configure(struct wl_listener 
*listener, void *data)
 
if (wet_configure_windowed_output_from_config(output, &defaults) < 0)
weston_log("Cannot configure output \"%s\".\n", output->name);
+
+   weston_output_enable(output);
 }
 
 static int
@@ -1484,6 +1484,8 @@ x11_backend_output_configure(struct wl_listener 
*listener, void *data)
 
if (wet_configure_windowed_output_from_config(output, &defaults) < 0)
weston_log("Cannot configure output \"%s\".\n", output->name);
+
+   weston_output_enable(output);
 }
 
 static int
@@ -1600,6 +1602,8 @@ wayland_backend_output_configure(struct wl_listener 
*listener, void *data)
 
if (wet_configure_windowed_output_from_config(output, &defaults) < 0)
weston_log("Cannot configure output \"%s\".\n", output->name);
+
+   weston_output_enable(output);
 }
 
 static int
-- 
2.13.6

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

[PATCH weston v5 12/36] libweston: add compositor list of heads

[Pekka Paalanen]

From: Pekka Paalanen 

weston_compositor needs to maintain a list of all available heads, so
that a compositor can pick and choose which heads to take into or out of
use at arbitrary times. The heads may be on or off, and connected or
disconnected.

Signed-off-by: Pekka Paalanen 
---
 libweston/compositor.c | 75 ++
 libweston/compositor.h |  8 ++
 2 files changed, 83 insertions(+)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index 349803e8..99299c9f 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -4432,11 +4432,79 @@ weston_head_init(struct weston_head *head, const char 
*name)
 */
memset(head, 0, sizeof *head);
 
+   wl_list_init(&head->compositor_link);
wl_list_init(&head->output_link);
wl_list_init(&head->resource_list);
head->name = strdup(name);
 }
 
+/** Register a new head
+ *
+ * \param compositor The compositor.
+ * \param head The head to register, must not be already registered.
+ *
+ * This signals the core that a new head has become available.
+ *
+ * \memberof weston_compositor
+ * \internal
+ */
+static void
+weston_compositor_add_head(struct weston_compositor *compositor,
+  struct weston_head *head)
+{
+   assert(wl_list_empty(&head->compositor_link));
+   assert(head->name);
+
+   wl_list_insert(compositor->head_list.prev, &head->compositor_link);
+   head->compositor = compositor;
+}
+
+/** Iterate over available heads
+ *
+ * \param compositor The compositor.
+ * \param item The iterator, or NULL for start.
+ * \return The next available head in the list.
+ *
+ * Returns all available heads, regardless of being connected or enabled.
+ *
+ * You can iterate over all heads as follows:
+ * \code
+ * struct weston_head *head = NULL;
+ *
+ * while ((head = weston_compositor_iterate_heads(compositor, head))) {
+ * ...
+ * }
+ * \endcode
+ *
+ *  If you cause \c iter to be removed from the list, you cannot use it to
+ * continue iterating. Removing any other item is safe.
+ *
+ * \memberof weston_compositor
+ */
+WL_EXPORT struct weston_head *
+weston_compositor_iterate_heads(struct weston_compositor *compositor,
+   struct weston_head *iter)
+{
+   struct wl_list *list = &compositor->head_list;
+   struct wl_list *node;
+
+   assert(compositor);
+   assert(!iter || iter->compositor == compositor);
+
+   if (iter)
+   node = iter->compositor_link.next;
+   else
+   node = list->next;
+
+   assert(node);
+   assert(!iter || node != &iter->compositor_link);
+
+   if (node == list)
+   return NULL;
+
+   return container_of(node, struct weston_head, compositor_link);
+}
+
 /** Attach a head to an inactive output
  *
  * \param output The output to attach to.
@@ -4511,6 +4579,8 @@ weston_head_release(struct weston_head *head)
free(head->model);
free(head->serial_number);
free(head->name);
+
+   wl_list_remove(&head->compositor_link);
 }
 
 /** Store monitor make, model and serial number
@@ -5032,6 +5102,7 @@ weston_output_init(struct weston_output *output,
 
weston_head_init(&output->head, name);
weston_head_set_connection_status(&output->head, true);
+   weston_compositor_add_head(compositor, &output->head);
 
/* Add some (in)sane defaults which can be used
 * for checking if an output was properly configured
@@ -5657,6 +5728,7 @@ weston_compositor_create(struct wl_display *display, void 
*user_data)
wl_list_init(&ec->seat_list);
wl_list_init(&ec->pending_output_list);
wl_list_init(&ec->output_list);
+   wl_list_init(&ec->head_list);
wl_list_init(&ec->key_binding_list);
wl_list_init(&ec->modifier_binding_list);
wl_list_init(&ec->button_binding_list);
@@ -5932,6 +6004,9 @@ weston_compositor_destroy(struct weston_compositor 
*compositor)
if (compositor->backend)
compositor->backend->destroy(compositor);
 
+   /* The backend is responsible for destroying the heads. */
+   assert(wl_list_empty(&compositor->head_list));
+
weston_plugin_api_destroy_list(compositor);
 
free(compositor);
diff --git a/libweston/compositor.h b/libweston/compositor.h
index d14dd6dc..c08c144c 100644
--- a/libweston/compositor.h
+++ b/libweston/compositor.h
@@ -153,6 +153,9 @@ enum dpms_enum {
  * (windowed nested backends).
  */
 struct weston_head {
+   struct weston_compositor *compositor;   /**< owning compositor */
+   struct wl_list compositor_link; /**< in weston_compositor::head_list */
+
struct weston_output *output;   /**< the output driving this head */
struct wl_list o

[PATCH weston v5 16/36] libweston: add weston_head_is_device_changed() API

[Pekka Paalanen]

From: Pekka Paalanen 

Reacting to DRM hotplug events is racy. It is theoretically possible to
get hotplug events for a quick swap from one monitor to another and
process both only after the new monitor is connected. Hence it is
possible for display device information to change without going through
a disconnected state for the head.

To support such cases, add API to allow detecting it in the compositor.

Signed-off-by: Pekka Paalanen 
---
 libweston/compositor.c | 88 ++
 libweston/compositor.h |  7 
 2 files changed, 89 insertions(+), 6 deletions(-)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index 86efcfad..0d3e185b 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -4714,6 +4714,31 @@ weston_head_release(struct weston_head *head)
wl_list_remove(&head->compositor_link);
 }
 
+static void
+weston_head_condition_device_changed(struct weston_head *head, bool condition)
+{
+   if (!condition)
+   return;
+
+   head->device_changed = true;
+
+   if (head->compositor)
+   weston_compositor_schedule_heads_changed(head->compositor);
+}
+
+/** String non-equal comparison with NULLs being equal */
+static bool
+str_null_neq(const char *a, const char *b)
+{
+   if (!a && !b)
+   return false;
+
+   if (!!a != !!b)
+   return true;
+
+   return strcmp(a, b);
+}
+
 /** Store monitor make, model and serial number
  *
  * \param head The head to modify.
@@ -4724,6 +4749,8 @@ weston_head_release(struct weston_head *head)
  * \param serialno The monitor serial number, a made-up string, or NULL for
  * none.
  *
+ * This may set the device_changed flag.
+ *
  * \memberof weston_head
  * \internal
  */
@@ -4733,6 +4760,11 @@ weston_head_set_monitor_strings(struct weston_head *head,
const char *model,
const char *serialno)
 {
+   weston_head_condition_device_changed(head,
+   str_null_neq(head->make, make) ||
+   str_null_neq(head->model, model) ||
+   str_null_neq(head->serial_number, serialno));
+
free(head->make);
free(head->model);
free(head->serial_number);
@@ -4748,6 +4780,8 @@ weston_head_set_monitor_strings(struct weston_head *head,
  * \param mm_width Image area width in millimeters.
  * \param mm_height Image area height in millimeters.
  *
+ * This may set the device_changed flag.
+ *
  * \memberof weston_head
  * \internal
  */
@@ -4755,6 +4789,10 @@ WL_EXPORT void
 weston_head_set_physical_size(struct weston_head *head,
  int32_t mm_width, int32_t mm_height)
 {
+   weston_head_condition_device_changed(head,
+head->mm_width != mm_width ||
+head->mm_height != mm_height);
+
head->mm_width = mm_width;
head->mm_height = mm_height;
 }
@@ -4770,6 +4808,8 @@ weston_head_set_physical_size(struct weston_head *head,
  * - WL_OUTPUT_SUBPIXEL_VERTICAL_RGB,
  * - WL_OUTPUT_SUBPIXEL_VERTICAL_BGR
  *
+ * This may set the device_changed flag.
+ *
  * \memberof weston_head
  * \internal
  */
@@ -4777,6 +4817,8 @@ WL_EXPORT void
 weston_head_set_subpixel(struct weston_head *head,
 enum wl_output_subpixel sp)
 {
+   weston_head_condition_device_changed(head, head->subpixel != sp);
+
head->subpixel = sp;
 }
 
@@ -4812,7 +4854,7 @@ weston_head_set_internal(struct weston_head *head)
  * connection to the parent display server.
  *
  * When the connection status changes, it schedules a call to the heads_changed
- * hook.
+ * hook and sets the device_changed flag.
  *
  * \sa weston_compositor_set_heads_changed_cb
  * \memberof weston_head
@@ -4821,13 +4863,9 @@ weston_head_set_internal(struct weston_head *head)
 WL_EXPORT void
 weston_head_set_connection_status(struct weston_head *head, bool connected)
 {
-   if (head->connected == connected)
-   return;
+   weston_head_condition_device_changed(head, head->connected != 
connected);
 
head->connected = connected;
-
-   if (head->compositor)
-   weston_compositor_schedule_heads_changed(head->compositor);
 }
 
 /** Is the head currently connected?
@@ -4871,6 +4909,44 @@ weston_head_is_enabled(struct weston_head *head)
return head->output->enabled;
 }
 
+/** Has the device information changed?
+ *
+ * \param head The head to query.
+ * \return True if the device information has changed since last reset.
+ *
+ * The information about the connected display device, e.g. a monitor, may
+ * change without being disconnected in between. Changing information
+ * causes a call to the heads_changed hook.
+ *
+ * The information includes make, model, se

[PATCH weston v5 26/36] libweston: stop auto-adding the implicit head

[Pekka Paalanen]

From: Pekka Paalanen 

All frontends have been converted to the new head-based output
management API, which means that
weston_compositor_create_output_with_head() is calling
weston_output_attach_head(). We will never hit the implicit attach
anymore.

Therefore we can now require that an output has at least one head when
calling weston_output_enable(). An output without heads is useless.

The auto-add code is removed as dead.

Signed-off-by: Pekka Paalanen 
---
 libweston/compositor.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index a8df7e94..11b9bc4d 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -5427,7 +5427,7 @@ weston_compositor_add_pending_output(struct weston_output 
*output,
 /** Constructs a weston_output object that can be used by the compositor.
  *
  * \param output The weston_output object that needs to be enabled. Must not
- * be enabled already.
+ * be enabled already. Must have at least one head attached.
  *
  * Output coordinates are calculated and each new output is by default
  * assigned to the right of previous one.
@@ -5463,7 +5463,6 @@ weston_output_enable(struct weston_output *output)
struct weston_compositor *c = output->compositor;
struct weston_output *iterator;
int x = 0, y = 0;
-   int ret;
 
if (output->enabled) {
weston_log("Error: attempt to enable an enabled output '%s'\n",
@@ -5471,6 +5470,12 @@ weston_output_enable(struct weston_output *output)
return -1;
}
 
+   if (wl_list_empty(&output->head_list)) {
+   weston_log("Error: cannot enable output '%s' without heads.\n",
+  output->name);
+   return -1;
+   }
+
iterator = container_of(c->output_list.prev,
struct weston_output, link);
 
@@ -5499,12 +5504,6 @@ weston_output_enable(struct weston_output *output)
wl_list_init(&output->animation_list);
wl_list_init(&output->feedback_list);
 
-   /* XXX: Temporary until all backends are converted. */
-   if (wl_list_empty(&output->head_list)) {
-   ret = weston_output_attach_head(output, &output->head);
-   assert(ret == 0);
-   }
-
/* Enable the output (set up the crtc or create a
 * window representing the output, set up the
 * renderer, etc)
-- 
2.13.6

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

[PATCH weston v5 25/36] libweston: remove output_pending_signal

[Pekka Paalanen]

From: Pekka Paalanen 

The signal has been replaced with the heads_changed hook and is no
longer useful.

weston_pending_output_coldplug() is renamed to
weston_compositor_flush_heads_changed() for two reasons: it better
describes what it does now, and it serves as an obvious flag that
libweston ABI has been broken.

Signed-off-by: Pekka Paalanen 
---
 compositor/main.c  |  2 +-
 libweston/compositor.c | 17 +
 libweston/compositor.h |  3 +--
 3 files changed, 7 insertions(+), 15 deletions(-)

diff --git a/compositor/main.c b/compositor/main.c
index e47d7928..14c77107 100644
--- a/compositor/main.c
+++ b/compositor/main.c
@@ -2056,7 +2056,7 @@ int main(int argc, char *argv[])
goto out;
}
 
-   weston_pending_output_coldplug(ec);
+   weston_compositor_flush_heads_changed(ec);
if (user_data.init_failed)
goto out;
 
diff --git a/libweston/compositor.c b/libweston/compositor.c
index 0d3e185b..a8df7e94 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -5408,9 +5408,6 @@ weston_output_init(struct weston_output *output,
  * \param output The weston_output object to add
  * \param compositor The compositor instance.
  *
- * Also notifies the compositor that an output is pending for
- * configuration.
- *
  * The opposite of this operation is built into weston_output_release().
  *
  * \memberof weston_output
@@ -5425,7 +5422,6 @@ weston_compositor_add_pending_output(struct weston_output 
*output,
 
wl_list_remove(&output->link);
wl_list_insert(compositor->pending_output_list.prev, &output->link);
-   wl_signal_emit(&compositor->output_pending_signal, output);
 }
 
 /** Constructs a weston_output object that can be used by the compositor.
@@ -5572,18 +5568,16 @@ weston_output_disable(struct weston_output *output)
output->destroying = 0;
 }
 
-/** Emits a signal to indicate that there are outputs waiting to be configured.
+/** Forces a synchronous call to heads_changed hook
  *
  * \param compositor The compositor instance
+ *
+ * If there are new or changed heads, calls the heads_changed hook and
+ * returns after the hook returns.
  */
 WL_EXPORT void
-weston_pending_output_coldplug(struct weston_compositor *compositor)
+weston_compositor_flush_heads_changed(struct weston_compositor *compositor)
 {
-   struct weston_output *output, *next;
-
-   wl_list_for_each_safe(output, next, &compositor->pending_output_list, 
link)
-   wl_signal_emit(&compositor->output_pending_signal, output);
-
if (compositor->heads_changed_source) {
wl_event_source_remove(compositor->heads_changed_source);
weston_compositor_call_heads_changed(compositor);
@@ -6054,7 +6048,6 @@ weston_compositor_create(struct wl_display *display, void 
*user_data)
wl_signal_init(&ec->hide_input_panel_signal);
wl_signal_init(&ec->update_input_panel_signal);
wl_signal_init(&ec->seat_created_signal);
-   wl_signal_init(&ec->output_pending_signal);
wl_signal_init(&ec->output_created_signal);
wl_signal_init(&ec->output_destroyed_signal);
wl_signal_init(&ec->output_moved_signal);
diff --git a/libweston/compositor.h b/libweston/compositor.h
index 1a9aac7f..af681e51 100644
--- a/libweston/compositor.h
+++ b/libweston/compositor.h
@@ -952,7 +952,6 @@ struct weston_compositor {
struct wl_signal update_input_panel_signal;
 
struct wl_signal seat_created_signal;
-   struct wl_signal output_pending_signal;
struct wl_signal output_created_signal;
struct wl_signal output_destroyed_signal;
struct wl_signal output_moved_signal;
@@ -2112,7 +2111,7 @@ void
 weston_output_disable(struct weston_output *output);
 
 void
-weston_pending_output_coldplug(struct weston_compositor *compositor);
+weston_compositor_flush_heads_changed(struct weston_compositor *compositor);
 
 struct weston_head *
 weston_head_from_resource(struct wl_resource *resource);
-- 
2.13.6

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

[PATCH weston v5 30/36] compositor-headless: migrate to head-based output API

[Pekka Paalanen]

From: Pekka Paalanen 

Implement the head-based output API in this backend, and stop relying on
the implicit weston_output::head.

Signed-off-by: Pekka Paalanen 
---
 libweston/compositor-headless.c | 75 ++---
 1 file changed, 63 insertions(+), 12 deletions(-)

diff --git a/libweston/compositor-headless.c b/libweston/compositor-headless.c
index 8fbb83ff..3e30e6ac 100644
--- a/libweston/compositor-headless.c
+++ b/libweston/compositor-headless.c
@@ -48,6 +48,10 @@ struct headless_backend {
bool use_pixman;
 };
 
+struct headless_head {
+   struct weston_head base;
+};
+
 struct headless_output {
struct weston_output base;
 
@@ -57,6 +61,12 @@ struct headless_output {
pixman_image_t *image;
 };
 
+static inline struct headless_head *
+to_headless_head(struct weston_head *base)
+{
+   return container_of(base, struct headless_head, base);
+}
+
 static inline struct headless_output *
 to_headless_output(struct weston_output *base)
 {
@@ -185,7 +195,7 @@ headless_output_set_size(struct weston_output *base,
 int width, int height)
 {
struct headless_output *output = to_headless_output(base);
-   struct weston_head *head = &output->base.head;
+   struct weston_head *head;
int output_width, output_height;
 
/* We can only be called once. */
@@ -194,6 +204,14 @@ headless_output_set_size(struct weston_output *base,
/* Make sure we have scale set. */
assert(output->base.scale);
 
+   wl_list_for_each(head, &output->base.head_list, output_link) {
+   weston_head_set_monitor_strings(head, "weston", "headless",
+   NULL);
+
+   /* XXX: Calculate proper size. */
+   weston_head_set_physical_size(head, width, height);
+   }
+
output_width = width * output->base.scale;
output_height = height * output->base.scale;
 
@@ -206,11 +224,6 @@ headless_output_set_size(struct weston_output *base,
 
output->base.current_mode = &output->mode;
 
-   weston_head_set_monitor_strings(head, "weston", "headless", NULL);
-
-   /* XXX: Calculate proper size. */
-   weston_head_set_physical_size(head, width, height);
-
output->base.start_repaint_loop = headless_output_start_repaint_loop;
output->base.repaint = headless_output_repaint;
output->base.assign_planes = NULL;
@@ -221,9 +234,8 @@ headless_output_set_size(struct weston_output *base,
return 0;
 }
 
-static int
-headless_output_create(struct weston_compositor *compositor,
-  const char *name)
+static struct weston_output *
+headless_output_create(struct weston_compositor *compositor, const char *name)
 {
struct headless_output *output;
 
@@ -231,21 +243,55 @@ headless_output_create(struct weston_compositor 
*compositor,
assert(name);
 
output = zalloc(sizeof *output);
-   if (output == NULL)
-   return -1;
+   if (!output)
+   return NULL;
 
weston_output_init(&output->base, compositor, name);
 
output->base.destroy = headless_output_destroy;
output->base.disable = headless_output_disable;
output->base.enable = headless_output_enable;
+   output->base.attach_head = NULL;
 
weston_compositor_add_pending_output(&output->base, compositor);
 
+   return &output->base;
+}
+
+static int
+headless_head_create(struct weston_compositor *compositor,
+const char *name)
+{
+   struct headless_head *head;
+
+   /* name can't be NULL. */
+   assert(name);
+
+   head = zalloc(sizeof *head);
+   if (head == NULL)
+   return -1;
+
+   weston_head_init(&head->base, name);
+   weston_head_set_connection_status(&head->base, true);
+
+   /* Ideally all attributes of the head would be set here, so that the
+* user has all the information when deciding to create outputs.
+* We do not have those until set_size() time through.
+*/
+
+   weston_compositor_add_head(compositor, &head->base);
+
return 0;
 }
 
 static void
+headless_head_destroy(struct headless_head *head)
+{
+   weston_head_release(&head->base);
+   free(head);
+}
+
+static void
 headless_restore(struct weston_compositor *ec)
 {
 }
@@ -254,15 +300,19 @@ static void
 headless_destroy(struct weston_compositor *ec)
 {
struct headless_backend *b = to_headless_backend(ec);
+   struct weston_head *base, *next;
 
weston_compositor_shutdown(ec);
 
+   wl_list_for_each_safe(base, next, &ec->head_list, compositor_link)
+   headless_head_destroy(to_headless_head(base));
+
free(b);
 }
 
 static const struct weston_windowed_output_api api =

[PATCH weston v5 27/36] libweston: assert make/model in weston_output_enable()

[Pekka Paalanen]

From: Pekka Paalanen 

Output make and model are not allowed to be NULL in the protocol, so
ensure they are not forgotten when enabling an output.

Signed-off-by: Pekka Paalanen 
---
 libweston/compositor.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index 11b9bc4d..903e8809 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -5462,6 +5462,7 @@ weston_output_enable(struct weston_output *output)
 {
struct weston_compositor *c = output->compositor;
struct weston_output *iterator;
+   struct weston_head *head;
int x = 0, y = 0;
 
if (output->enabled) {
@@ -5476,6 +5477,11 @@ weston_output_enable(struct weston_output *output)
return -1;
}
 
+   wl_list_for_each(head, &output->head_list, output_link) {
+   assert(head->make);
+   assert(head->model);
+   }
+
iterator = container_of(c->output_list.prev,
struct weston_output, link);
 
-- 
2.13.6

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

[PATCH weston v5 28/36] libweston: assert current_mode in weston_output_enable()

[Pekka Paalanen]

From: Pekka Paalanen 

The functions called here, particularly
weston_output_transform_scale_init(), rely on current mode being set.
The current mode must also be found in the mode list, though we don't
explicitly check it here.

current_mode not being set is a programmer error. It could be a backend
bug, but it could also be a libweston user bug not calling a set size
function.

Signed-off-by: Pekka Paalanen 
---
 libweston/compositor.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index 903e8809..d9185b85 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -5477,6 +5477,12 @@ weston_output_enable(struct weston_output *output)
return -1;
}
 
+   if (wl_list_empty(&output->mode_list) || !output->current_mode) {
+   weston_log("Error: no video mode for output '%s'.\n",
+  output->name);
+   return -1;
+   }
+
wl_list_for_each(head, &output->head_list, output_link) {
assert(head->make);
assert(head->model);
-- 
2.13.6

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

[PATCH weston v5 29/36] libweston: cancel idle_repaint on output destroy

[Pekka Paalanen]

From: Pekka Paalanen 

If the idle_repaint() callback has been scheduled when a weston_output
gets destroyed, the callback will hit use-after-free. I have encountered
this when migrating the wayland backend to the head-based API, using
--sprawl, and closing/disconnecting one of the parent compositor
outputs.

Store the idle_repaint callback source, and destroy it in
weston_output_release(), ensuring we don't get a stale call to
start_repaint_loop later.

Signed-off-by: Pekka Paalanen 
---
 libweston/compositor.c | 8 +++-
 libweston/compositor.h | 3 +++
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index d9185b85..be02ad69 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -2582,6 +2582,7 @@ idle_repaint(void *data)
 
assert(output->repaint_status == REPAINT_BEGIN_FROM_IDLE);
output->repaint_status = REPAINT_AWAITING_COMPLETION;
+   output->idle_repaint_source = NULL;
output->start_repaint_loop(output);
 }
 
@@ -2706,7 +2707,9 @@ weston_output_schedule_repaint(struct weston_output 
*output)
return;
 
output->repaint_status = REPAINT_BEGIN_FROM_IDLE;
-   wl_event_loop_add_idle(loop, idle_repaint, output);
+   assert(!output->idle_repaint_source);
+   output->idle_repaint_source = wl_event_loop_add_idle(loop, idle_repaint,
+output);
TL_POINT("core_repaint_enter_loop", TLP_OUTPUT(output), TLP_END);
 }
 
@@ -5614,6 +5617,9 @@ weston_output_release(struct weston_output *output)
 
output->destroying = 1;
 
+   if (output->idle_repaint_source)
+   wl_event_source_remove(output->idle_repaint_source);
+
if (output->enabled)
weston_compositor_remove_output(output);
 
diff --git a/libweston/compositor.h b/libweston/compositor.h
index af681e51..a9617755 100644
--- a/libweston/compositor.h
+++ b/libweston/compositor.h
@@ -216,6 +216,9 @@ struct weston_output {
 *  next repaint should be run */
struct timespec next_repaint;
 
+   /** For cancelling the idle_repaint callback on output destruction. */
+   struct wl_event_source *idle_repaint_source;
+
struct weston_output_zoom zoom;
int dirty;
struct wl_signal frame_signal;
-- 
2.13.6

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

[PATCH weston v5 32/36] compositor-fbdev: make re-enable less drastic

[Pekka Paalanen]

From: Pekka Paalanen 

Destroying the whole output in reenable would cause list walk
corruption: the loop over output_list in session_notify() is not using
wl_list_for_each_safe so output removal would break it.

Creating a new output is also problematic as it needs the compositor to
configure it, but that probably saved us from another list walk failure:
adding the new output to be list while walking the list, possibly
causing it to be destroyed and re-created ad infinitum.

Instead of a complete destroy/create cycle, just do our internal
disable/enable cycle. That will re-open the fbdev, re-read the
parameters, re-create hw_surface, and reinitialize the renderer output.

A problem with this is if fbdev_set_screen_info() fails. We do read the
new parameters, but we don't communicate them to libweston core or old
clients.

However, it is hard to care: to trigger this path, one needs to
VT-switch to another fbdev app which changes the fbdev parameters. That
is quite difficult as VT-switching has been broken for a good while for
fbdev-backend, at least with logind. Also fbdev_set_screen_info() would
have to fail before one should be able to tell something is wrong.

The real reason behind this patch, though, is the migration to the
head-based output API. Destroying and re-creating an output really does
not fit that design. Destroying and re-creating a head would be better,
but again not testable in the current state.

Signed-off-by: Pekka Paalanen 
---
 libweston/compositor-fbdev.c | 19 ++-
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/libweston/compositor-fbdev.c b/libweston/compositor-fbdev.c
index c71d7eb5..fe79de44 100644
--- a/libweston/compositor-fbdev.c
+++ b/libweston/compositor-fbdev.c
@@ -594,15 +594,15 @@ fbdev_output_reenable(struct fbdev_backend *backend,
struct fbdev_output *output = to_fbdev_output(base);
struct fbdev_screeninfo new_screen_info;
int fb_fd;
-   char *device;
 
weston_log("Re-enabling fbdev output.\n");
+   assert(output->base.enabled);
 
/* Create the frame buffer. */
fb_fd = fbdev_frame_buffer_open(output->device, &new_screen_info);
if (fb_fd < 0) {
weston_log("Creating frame buffer failed.\n");
-   goto err;
+   return -1;
}
 
/* Check whether the frame buffer details have changed since we were
@@ -616,27 +616,20 @@ fbdev_output_reenable(struct fbdev_backend *backend,
 
close(fb_fd);
 
-   /* Remove and re-add the output so that resources depending on
+   /* Disable and enable the output so that resources depending on
 * the frame buffer X/Y resolution (such as the shadow buffer)
 * are re-initialised. */
-   device = strdup(output->device);
-   fbdev_output_destroy(&output->base);
-   fbdev_output_create(backend, device);
-   free(device);
-
-   return 0;
+   fbdev_output_disable(&output->base);
+   return fbdev_output_enable(&output->base);
}
 
/* Map the device if it has the same details as before. */
if (fbdev_frame_buffer_map(output, fb_fd) < 0) {
weston_log("Mapping frame buffer failed.\n");
-   goto err;
+   return -1;
}
 
return 0;
-
-err:
-   return -1;
 }
 
 static void
-- 
2.13.6

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

[PATCH weston v5 22/36] weston: migrate RDP to head-based output API

[Pekka Paalanen]

From: Pekka Paalanen 

Migrate the RDP frontend to use the new head-based output configuration
API: listen for heads_changed, and process all heads.

Signed-off-by: Pekka Paalanen 
---
 compositor/main.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/compositor/main.c b/compositor/main.c
index 939201b3..55947675 100644
--- a/compositor/main.c
+++ b/compositor/main.c
@@ -1502,10 +1502,9 @@ load_headless_backend(struct weston_compositor *c,
return 0;
 }
 
-static void
-rdp_backend_output_configure(struct wl_listener *listener, void *data)
+static int
+rdp_backend_output_configure(struct weston_output *output)
 {
-   struct weston_output *output = data;
struct wet_compositor *compositor = 
to_wet_compositor(output->compositor);
struct wet_output_config *parsed_options = compositor->parsed_options;
const struct weston_rdp_output_api *api = 
weston_rdp_output_get_api(output->compositor);
@@ -1516,7 +1515,7 @@ rdp_backend_output_configure(struct wl_listener 
*listener, void *data)
 
if (!api) {
weston_log("Cannot use weston_rdp_output_api.\n");
-   return;
+   return -1;
}
 
if (parsed_options->width)
@@ -1531,10 +1530,10 @@ rdp_backend_output_configure(struct wl_listener 
*listener, void *data)
if (api->output_set_size(output, width, height) < 0) {
weston_log("Cannot configure output \"%s\" using 
weston_rdp_output_api.\n",
   output->name);
-   return;
+   return -1;
}
 
-   weston_output_enable(output);
+   return 0;
 }
 
 static void
@@ -1579,14 +1578,14 @@ load_rdp_backend(struct weston_compositor *c,
 
parse_options(rdp_options, ARRAY_LENGTH(rdp_options), argc, argv);
 
+   wet_set_simple_head_configurator(c, rdp_backend_output_configure);
+
ret = weston_compositor_load_backend(c, WESTON_BACKEND_RDP,
 &config.base);
 
if (ret < 0)
goto out;
 
-   wet_set_pending_output_handler(c, rdp_backend_output_configure);
-
 out:
free(config.bind_address);
free(config.rdp_key);
-- 
2.13.6

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

[PATCH weston v5 21/36] weston: migrate fbdev to head-based output API

[Pekka Paalanen]

From: Pekka Paalanen 

Migrate the fbdev frontend to use the new head-based output
configuration API: listen for heads_changed, and process all heads.

Signed-off-by: Pekka Paalanen 
---
 compositor/main.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/compositor/main.c b/compositor/main.c
index 6eb755e5..939201b3 100644
--- a/compositor/main.c
+++ b/compositor/main.c
@@ -1596,10 +1596,9 @@ out:
return ret;
 }
 
-static void
-fbdev_backend_output_configure(struct wl_listener *listener, void *data)
+static int
+fbdev_backend_output_configure(struct weston_output *output)
 {
-   struct weston_output *output = data;
struct weston_config *wc = wet_get_config(output->compositor);
struct weston_config_section *section;
 
@@ -1608,7 +1607,7 @@ fbdev_backend_output_configure(struct wl_listener 
*listener, void *data)
wet_output_set_transform(output, section, WL_OUTPUT_TRANSFORM_NORMAL, 
UINT32_MAX);
weston_output_set_scale(output, 1);
 
-   weston_output_enable(output);
+   return 0;
 }
 
 static int
@@ -1632,6 +1631,8 @@ load_fbdev_backend(struct weston_compositor *c,
config.base.struct_size = sizeof(struct weston_fbdev_backend_config);
config.configure_device = configure_input_device;
 
+   wet_set_simple_head_configurator(c, fbdev_backend_output_configure);
+
/* load the actual wayland backend and configure it */
ret = weston_compositor_load_backend(c, WESTON_BACKEND_FBDEV,
 &config.base);
@@ -1639,8 +1640,6 @@ load_fbdev_backend(struct weston_compositor *c,
if (ret < 0)
goto out;
 
-   wet_set_pending_output_handler(c, fbdev_backend_output_configure);
-
 out:
free(config.device);
return ret;
-- 
2.13.6

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

[PATCH weston v5 31/36] compositor-rdp: migrate to head-based output API

[Pekka Paalanen]

From: Pekka Paalanen 

Follow the starndard patttern as the other backends, headless and x11 in
particular, to stop relying on the implicit weston_output::head.

Signed-off-by: Pekka Paalanen 
---
 libweston/compositor-rdp.c | 64 ++
 1 file changed, 53 insertions(+), 11 deletions(-)

diff --git a/libweston/compositor-rdp.c b/libweston/compositor-rdp.c
index ffad52a6..2f7f885e 100644
--- a/libweston/compositor-rdp.c
+++ b/libweston/compositor-rdp.c
@@ -130,6 +130,10 @@ struct rdp_peers_item {
struct wl_list link;
 };
 
+struct rdp_head {
+   struct weston_head base;
+};
+
 struct rdp_output {
struct weston_output base;
struct wl_event_source *finish_frame_timer;
@@ -152,6 +156,12 @@ struct rdp_peer_context {
 };
 typedef struct rdp_peer_context RdpPeerContext;
 
+static inline struct rdp_head *
+to_rdp_head(struct weston_head *base)
+{
+   return container_of(base, struct rdp_head, base);
+}
+
 static inline struct rdp_output *
 to_rdp_output(struct weston_output *base)
 {
@@ -482,13 +492,20 @@ rdp_output_set_size(struct weston_output *base,
int width, int height)
 {
struct rdp_output *output = to_rdp_output(base);
-   struct weston_head *head = &output->base.head;
+   struct weston_head *head;
struct weston_mode *currentMode;
struct weston_mode initMode;
 
/* We can only be called once. */
assert(!output->base.current_mode);
 
+   wl_list_for_each(head, &output->base.head_list, output_link) {
+   weston_head_set_monitor_strings(head, "weston", "rdp", NULL);
+
+   /* XXX: Calculate proper size. */
+   weston_head_set_physical_size(head, width, height);
+   }
+
wl_list_init(&output->peers);
 
initMode.flags = WL_OUTPUT_MODE_CURRENT | WL_OUTPUT_MODE_PREFERRED;
@@ -502,11 +519,6 @@ rdp_output_set_size(struct weston_output *base,
 
output->base.current_mode = output->base.native_mode = currentMode;
 
-   weston_head_set_monitor_strings(head, "weston", "rdp", NULL);
-
-   /* XXX: Calculate proper size. */
-   weston_head_set_physical_size(head, width, height);
-
output->base.start_repaint_loop = rdp_output_start_repaint_loop;
output->base.repaint = rdp_output_repaint;
output->base.assign_planes = NULL;
@@ -576,27 +588,51 @@ rdp_output_destroy(struct weston_output *base)
free(output);
 }
 
-static int
-rdp_backend_create_output(struct weston_compositor *compositor)
+static struct weston_output *
+rdp_output_create(struct weston_compositor *compositor, const char *name)
 {
struct rdp_output *output;
 
output = zalloc(sizeof *output);
if (output == NULL)
-   return -1;
+   return NULL;
 
-   weston_output_init(&output->base, compositor, "rdp");
+   weston_output_init(&output->base, compositor, name);
 
output->base.destroy = rdp_output_destroy;
output->base.disable = rdp_output_disable;
output->base.enable = rdp_output_enable;
+   output->base.attach_head = NULL;
 
weston_compositor_add_pending_output(&output->base, compositor);
 
+   return &output->base;
+}
+
+static int
+rdp_head_create(struct weston_compositor *compositor, const char *name)
+{
+   struct rdp_head *head;
+
+   head = zalloc(sizeof *head);
+   if (!head)
+   return -1;
+
+   weston_head_init(&head->base, name);
+   weston_head_set_connection_status(&head->base, true);
+   weston_compositor_add_head(compositor, &head->base);
+
return 0;
 }
 
 static void
+rdp_head_destroy(struct rdp_head *head)
+{
+   weston_head_release(&head->base);
+   free(head);
+}
+
+static void
 rdp_restore(struct weston_compositor *ec)
 {
 }
@@ -605,9 +641,14 @@ static void
 rdp_destroy(struct weston_compositor *ec)
 {
struct rdp_backend *b = to_rdp_backend(ec);
+   struct weston_head *base, *next;
int i;
 
weston_compositor_shutdown(ec);
+
+   wl_list_for_each_safe(base, next, &ec->head_list, compositor_link)
+   rdp_head_destroy(to_rdp_head(base));
+
for (i = 0; i < MAX_FREERDP_FDS; i++)
if (b->listener_events[i])
wl_event_source_remove(b->listener_events[i]);
@@ -1304,6 +1345,7 @@ rdp_backend_create(struct weston_compositor *compositor,
b->compositor = compositor;
b->base.destroy = rdp_destroy;
b->base.restore = rdp_restore;
+   b->base.create_output = rdp_output_create;
b->rdp_key = config->rdp_key ? strdup(config->rdp_key) : NULL;
b->no_clients_resize = config->no_clients_resize;
 
@@ -1325,7 +1367,7 @@ rdp_backend_create(struct we

[PATCH weston v5 23/36] weston: migrate DRM to head-based output API

[Pekka Paalanen]

From: Pekka Paalanen 

Migrate the DRM frontend to use the simple head-based output
configurator, maintaining the exact same features and semantics as
before.

This is an intermediate step. It is unoptimal to create a weston_output
just to turn it off, but the libweston implementation and the DRM
backend require it for now. In the future, the DRM frontend will get its
own configurator that does not create useless weston_outputs and
supports clone mode by attaching multiple heads to the same
weston_output. Clone mode is not yet supported by libweston/DRM.

This is the last frontend migrated, wet_set_pending_output_handler() is
deleted as dead code.

Signed-off-by: Pekka Paalanen 
---
 compositor/main.c | 32 
 1 file changed, 12 insertions(+), 20 deletions(-)

diff --git a/compositor/main.c b/compositor/main.c
index 55947675..e171e12d 100644
--- a/compositor/main.c
+++ b/compositor/main.c
@@ -83,7 +83,6 @@ struct wet_head_tracker {
 struct wet_compositor {
struct weston_config *config;
struct wet_output_config *parsed_options;
-   struct wl_listener pending_output_listener;
bool drm_use_current_mode;
int (*simple_output_configure)(struct weston_output *output);
bool init_failed;
@@ -444,16 +443,6 @@ to_wet_compositor(struct weston_compositor *compositor)
return weston_compositor_get_user_data(compositor);
 }
 
-static void
-wet_set_pending_output_handler(struct weston_compositor *ec,
-  wl_notify_func_t handler)
-{
-   struct wet_compositor *compositor = to_wet_compositor(ec);
-
-   compositor->pending_output_listener.notify = handler;
-   wl_signal_add(&ec->output_pending_signal, 
&compositor->pending_output_listener);
-}
-
 static struct wet_output_config *
 wet_init_parsed_options(struct weston_compositor *ec)
 {
@@ -1238,6 +1227,10 @@ simple_head_enable(struct weston_compositor *compositor, 
struct weston_head *hea
return;
}
 
+   /* Escape hatch for DRM backend "off" setting. */
+   if (ret > 0)
+   return;
+
if (weston_output_enable(output) < 0) {
weston_log("Enabling output \"%s\" failed.\n",
   weston_head_get_name(head));
@@ -1328,10 +1321,9 @@ configure_input_device(struct weston_compositor 
*compositor,
}
 }
 
-static void
-drm_backend_output_configure(struct wl_listener *listener, void *data)
+static int
+drm_backend_output_configure(struct weston_output *output)
 {
-   struct weston_output *output = data;
struct weston_config *wc = wet_get_config(output->compositor);
struct wet_compositor *wet = to_wet_compositor(output->compositor);
struct weston_config_section *section;
@@ -1346,7 +1338,7 @@ drm_backend_output_configure(struct wl_listener 
*listener, void *data)
 
if (!api) {
weston_log("Cannot use weston_drm_output_api.\n");
-   return;
+   return -1;
}
 
section = weston_config_get_section(wc, "output", "name", output->name);
@@ -1355,7 +1347,7 @@ drm_backend_output_configure(struct wl_listener 
*listener, void *data)
if (strcmp(s, "off") == 0) {
weston_output_disable(output);
free(s);
-   return;
+   return 1;
} else if (wet->drm_use_current_mode || strcmp(s, "current") == 0) {
mode = WESTON_DRM_BACKEND_OUTPUT_CURRENT;
} else if (strcmp(s, "preferred") != 0) {
@@ -1367,7 +1359,7 @@ drm_backend_output_configure(struct wl_listener 
*listener, void *data)
if (api->set_mode(output, mode, modeline) < 0) {
weston_log("Cannot configure an output using 
weston_drm_output_api.\n");
free(modeline);
-   return;
+   return -1;
}
free(modeline);
 
@@ -1385,7 +1377,7 @@ drm_backend_output_configure(struct wl_listener 
*listener, void *data)
api->set_seat(output, seat);
free(seat);
 
-   weston_output_enable(output);
+   return 0;
 }
 
 static int
@@ -1419,11 +1411,11 @@ load_drm_backend(struct weston_compositor *c,
config.base.struct_size = sizeof(struct weston_drm_backend_config);
config.configure_device = configure_input_device;
 
+   wet_set_simple_head_configurator(c, drm_backend_output_configure);
+
ret = weston_compositor_load_backend(c, WESTON_BACKEND_DRM,
 &config.base);
 
-   wet_set_pending_output_handler(c, drm_backend_output_configure);
-
free(config.gbm_format);
free(config.seat_id);
 
-- 
2.13.6

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