Re: Wayland talk at FOSDEM

[Silvan Jegen]

Hi

On Tue, Dec 5, 2017 at 3:46 PM, Philipp Kerling  wrote:
> 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.
>
> This would include stuff such as:
>  * Wayland architecture
> * Comparison with X
> * Security architecture
> * Limitations: What is not possible with Wayland (currently)
> * Difference between core and extension protocols
> * Global registry
> * Relevant documentation and resources
>  * Why you should not be writing a Wayland client yourself (aka use
>toolkits if possible)
>  * 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)
> * Seats and input
>* Keyboard: wl_keyboard and libxkbcommon
>* Mouse: wl_pointer and libwayland-cursor for cursor handling
> * xdg_wm_base
> * Window decorations
> * EGL

I would be very interested in an overview like that and think it's a
very good idea™ indeed!

I see that you left out the text-input/input-method protocols in your
topics. Is it because those are unstable or because you don't consider
them to be important enough?


Cheers,

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

[Christian Stroetmann]

On 04 Dec 2017 09:45, Pekka Paalanen wrote:

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


Hello everybody

First of all, you raised one or more highly intersting questions, that 
could fill books and fuel scientific works.in the field of 
jurisprudence/law/legal studies for decades. :D



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.


The question, who owns a work that has been automatically generated from 
one or more other works, has not been answered, as far as I know, and 
cannot be answered in general. It depends on the act and the situation 
or context.


A comparable case is the field of generative music, where a user 
buys/gets a programm that includes for example building blocks of music 
(e.g. sounds, voices, instrumental tones, etc.) and an algorithm that 
puts these music blocks together at runtime resulting in audible music. 
Often this generation of music is virtually not repeatable in the same 
way, because of the many possible variants.


A musician, who creates and sells such generative music works, said he 
thinks the generated music is owned by the user.
My opinion is that merely pushing the play button of the generative 
music software is not sufficient to be acknowledged as an artistic act, 
which is required for copyright protection. Indeed, it is very difficult 
to see a personal expression in such an activity that is characteristic 
for a specific user of such a software.


The same holds in this case. It is very difficult to see an artistic act 
in writing a command line and pushing the enter button to start 
scanning, compiling, and generating a software out of another software 
or text.




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.


Indeed, safety first. Make clear where all the stuff comes from and how 
it is licensed, but do not impose your license or any other license on 
parts that you do not own.



---

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 

Re: Wayland talk at FOSDEM

[Eugen Friedrich]

Hello Philipp,

I also thinking give a talk about the usage of weston in ivi systems,
this should give an overview what is the main difference to the
desktop environment and why the ivi-shell is used. Also I would like
to give short overview about the recent activities in ivi-shell and
usage of waltham.

2017-12-05 15:46 GMT+01:00 Philipp Kerling :
>
> 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.
>
> This would include stuff such as:
>  * Wayland architecture
> * Comparison with X
> * Security architecture
> * Limitations: What is not possible with Wayland (currently)
> * Difference between core and extension protocols
> * Global registry
> * Relevant documentation and resources
>  * Why you should not be writing a Wayland client yourself (aka use
>toolkits if possible)
>  * 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)
> * 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
>  * ...
just as idea: there are a few patch series which are pending for a
very long time,
one of the famous one is the atomic mode setting patch series from Daniel :-)
maybe it would be interesting to give a short overview of the "cool"
pending feature
on the list which people can expect in next or over next release.

>
> I would not include:
>  * Details of libwayland API (e.g. proxy wrappers)
>  * 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
>
> Regards,
> Philipp
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Making weston (or maybe libinput) ignore an input device

[Matt Hoosier]

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.

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

[Alexandros Frantzis]

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.

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.

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.

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

https://gitlab.collabora.com/alf/weston/commits/zwp-input-timestamps

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

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

[Alexandros Frantzis]

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.

Signed-off-by: Alexandros Frantzis 
---
 Makefile.am|   1 +
 unstable/input-timestamps/README   |   4 +
 .../input-timestamps-unstable-v1.xml   | 138 +
 3 files changed, 143 insertions(+)
 create mode 100644 unstable/input-timestamps/README
 create mode 100644 unstable/input-timestamps/input-timestamps-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index cabc279..4b9a901 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -16,6 +16,7 @@ unstable_protocols =  
\
unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml  
\

unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \
unstable/xdg-output/xdg-output-unstable-v1.xml  
\
+   unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
$(NULL)
 
 stable_protocols = 
\
diff --git a/unstable/input-timestamps/README b/unstable/input-timestamps/README
new file mode 100644
index 000..3e82890
--- /dev/null
+++ b/unstable/input-timestamps/README
@@ -0,0 +1,4 @@
+High-resolution timestamps for input events.
+
+Maintainers:
+Alexandros Frantzis 
diff --git a/unstable/input-timestamps/input-timestamps-unstable-v1.xml 
b/unstable/input-timestamps/input-timestamps-unstable-v1.xml
new file mode 100644
index 000..5a9d120
--- /dev/null
+++ b/unstable/input-timestamps/input-timestamps-unstable-v1.xml
@@ -0,0 +1,138 @@
+
+
+
+  
+Copyright © 2017 Collabora, Ltd.
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+  
+
+  
+This protocol specifies a way for a client to request and receive
+high-resolution timestamps for input events.
+
+Warning! The protocol described in this file is experimental and
+backward incompatible changes may be made. Backward compatible changes
+may be added together with the corresponding interface version bump.
+Backward incompatible changes are done by bumping the version number in
+the protocol and interface names and resetting the interface version.
+Once the protocol is to be declared stable, the 'z' prefix and the
+version number in the protocol and interface names are removed and the
+interface version number is reset.
+  
+
+  
+
+  A global interface used for requesting high-resolution timestamps
+  for input events.
+
+
+
+  
+Informs the server 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 

Wayland talk at FOSDEM

[Philipp Kerling]

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.

This would include stuff such as:
 * Wayland architecture
* Comparison with X
* Security architecture
* Limitations: What is not possible with Wayland (currently)
* Difference between core and extension protocols
* Global registry
* Relevant documentation and resources
 * Why you should not be writing a Wayland client yourself (aka use
   toolkits if possible)
 * 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)
* 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)
 * 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

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

Re: [PATCH wayland-protocols 3/3] Remove autotools build system

[Emil Velikov]

On 11 October 2017 at 10:22, Jonas Ådahl  wrote:

>>
>> Besides, wayland-protocol doesn't compile/link anything at all, I'm not
>> sure what meson buys us here (other than being trendy).
>
> It does now, as part of the test suite. FWIW, I first opened Makefile.am
> and started typing when trying to add the various build testing I wanted
> to add, but quickly gave trying to fight with autotools yet another
> time.
>
Considering the tests are just introduced this reminds me the "Don't
throw the baby out with the bathwater" idiom ;-)
I'll take a look at wiring the tests with autotools.

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

Re: [PATCH 2/3] xwayland: Shape window region to clip shadow area from input

[Daniel Stone]

Hi Scott,

On 24 June 2017 at 08:18, Scott Moreau  wrote:
> Decorated windows were getting the size of the window including the
> shadow which is correct, but causing some confusion for motion input
> events. This was exhibited when one xwayland window overlaps another,
> hovering over the window beneath recieves no events if within the 32
> pixel shadow border area of the window above.

Seems correct, but can't this just use frame_input_rect() instead of
hard-coding the sizes?

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

Re: [PATCH 1/3] xwayland: Fix input coordinates of non-decorated windows

[Daniel Stone]

Hi Scott,

On 24 June 2017 at 08:18, Scott Moreau  wrote:
> Windows without decorations drawn by the xwayland window manager had
> wrong input coordinates because weston_wm_window_get_child_position was
> giving wrong x/y offsets. Set the offsets to 0 for windows without
> system decorations.

I tried to untangle what was going on through xwm here and just tied
myself in a knot. It looks like this case would also need a similar
change in weston_wm_window_get_frame_size, right? That should be
relatively harmless (resulting in us setting larger regions than the
actual window size), but still the same thing.

This is all a bit of a mess, but it seems correct enough that, with
the get_frame_size() change as well, this would be:
Acked-by: Daniel Stone 

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

[PATCH weston] libweston: drop return type from ::query_dmabuf_{formats, modifiers}

[Emil Velikov]

From: Emil Velikov 

Nobody checks for the bool returned by these functions. At the same
time: a) the functions set the respective num_foo to zero on error and
b) callers honour that variable.

Just drop the return type - it's useless.

Note: this is an ABI break.

Signed-off-by: Emil Velikov 
---
 libweston/compositor.h  |  6 --
 libweston/gl-renderer.c | 18 --
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/libweston/compositor.h b/libweston/compositor.h
index 769203a1..a4ac6355 100644
--- a/libweston/compositor.h
+++ b/libweston/compositor.h
@@ -748,10 +748,12 @@ struct weston_renderer {
bool (*import_dmabuf)(struct weston_compositor *ec,
  struct linux_dmabuf_buffer *buffer);
 
-   bool (*query_dmabuf_formats)(struct weston_compositor *ec,
+   /** On error sets num_formats to zero */
+   void (*query_dmabuf_formats)(struct weston_compositor *ec,
int **formats, int *num_formats);
 
-   bool (*query_dmabuf_modifiers)(struct weston_compositor *ec,
+   /** On error sets num_modifiers to zero */
+   void (*query_dmabuf_modifiers)(struct weston_compositor *ec,
int format, uint64_t **modifiers,
int *num_modifiers);
 };
diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index 7844f676..51e9d84a 100644
--- a/libweston/gl-renderer.c
+++ b/libweston/gl-renderer.c
@@ -1901,7 +1901,7 @@ import_dmabuf(struct gl_renderer *gr,
return image;
 }
 
-static bool
+static void
 gl_renderer_query_dmabuf_formats(struct weston_compositor *wc,
int **formats, int *num_formats)
 {
@@ -1913,25 +1913,24 @@ gl_renderer_query_dmabuf_formats(struct 
weston_compositor *wc,
if (!gr->has_dmabuf_import_modifiers ||
!gr->query_dmabuf_formats(gr->egl_display, 0, NULL, )) {
*num_formats = 0;
-   return false;
+   return;
}
 
*formats = calloc(num, sizeof(int));
if (*formats == NULL) {
*num_formats = 0;
-   return false;
+   return;
}
if (!gr->query_dmabuf_formats(gr->egl_display, num, *formats, )) {
*num_formats = 0;
free(*formats);
-   return false;
+   return;
}
 
*num_formats = num;
-   return true;
 }
 
-static bool
+static void
 gl_renderer_query_dmabuf_modifiers(struct weston_compositor *wc, int format,
uint64_t **modifiers,
int *num_modifiers)
@@ -1945,23 +1944,22 @@ gl_renderer_query_dmabuf_modifiers(struct 
weston_compositor *wc, int format,
!gr->query_dmabuf_modifiers(gr->egl_display, format, 0, NULL,
NULL, )) {
*num_modifiers = 0;
-   return false;
+   return;
}
 
*modifiers = calloc(num, sizeof(uint64_t));
if (*modifiers == NULL) {
*num_modifiers = 0;
-   return false;
+   return;
}
if (!gr->query_dmabuf_modifiers(gr->egl_display, format,
num, *modifiers, NULL, )) {
*num_modifiers = 0;
free(*modifiers);
-   return false;
+   return;
}
 
*num_modifiers = num;
-   return true;
 }
 
 static bool
-- 
2.15.0

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

Re: [PATCH wayland] scanner: Add autoconf macro to check for the proper scanner

[Daniel Stone]

Hi,

On 5 December 2017 at 14:08, Emil Velikov  wrote:
> On 4 December 2017 at 21:47, Daniel Stone  wrote:
>> Any comments on Quentin's suggestion here? Would they be enough for you?
>
> I fear that the ship has sailed long time ago and there will be
> practically zero users of this.
>
> AFAICT people have been stacking band-aid for years as opposed to
> addressing things properly.
> With key offender being Yocto and similar tools :-\

The Yocto people are in this thread; they've already dropped a bunch
of local hacks they had throughout the tree in favour of proper
solutions upstream. Hopefully this will get the last of it out.

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

Re: [weston v2 0/8] Implement NET_WM_SYNC_REQUEST basic support

[Daniel Stone]

Hi Louis-Francis,

On 13 November 2017 at 21:20, Louis-Francis Ratté-Boulianne
 wrote:
> This patchset implements NET_WM_SYNC_REQUEST protocol for throtting
> X11 window resizes in Weston's XWM. We wait for the window to be drawn
> (by setting an alarm on the sync counter) before configuring the window
> again.
>
> I also did some small fixes the Xwayland window manager as to better
> respect size hints from X11 applications and to display the title
> more elegantly when there isn't enough space available.

I've merged 2, 4, 7 and 8 now. I would certainly like to look at the
actual sync support when my brain doesn't feel like it's encased in
treacle. I held off on pushing the size-hints part of it after the
replies to both of those.

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

Re: [PATCH wayland] scanner: Add autoconf macro to check for the proper scanner

[Emil Velikov]

On 4 December 2017 at 21:47, Daniel Stone  wrote:
> Jussi, Tomek, Emil,
>
> On 18 August 2017 at 10:36, Quentin Glidic
>  wrote:
>> On 8/18/17 11:30 AM, Quentin Glidic wrote:
>>> Projects have been using various ways to check for the wayland-scanner,
>>> mostly based on their developper own use case, and often not allowing
>>> others use cases to work without a workaround.
>>>
>>> Hopefully this macro will support all use cases without needing user
>>> action.
>>>
>>> Signed-off-by: Quentin Glidic 
>>> ---
>>>
>>> Everyone should test this macro for their own project and use cases.
>>> Using the ${WAYLAND_SCANNER} variable should just work (assuming you have
>>> the proper
>>> wayland package built in the expected env). In very very rare cases,
>>> setting the
>>> WAYLAND_SCANNER variable as a ./configure argument may be needed, but
>>> nothing else.
>>>
>>> Please let me know with enough details if your use case is not working
>>> with it.
>
> Any comments on Quentin's suggestion here? Would they be enough for you?
>
I fear that the ship has sailed long time ago and there will be
practically zero users of this.

AFAICT people have been stacking band-aid for years as opposed to
addressing things properly.
With key offender being Yocto and similar tools :-\

I'll refrain from commenting further on the topic, I doubt it's be too
beneficial.
My earlier ramblings can be found in the ML archives [1].

That said, if people are happy with the patch do go ahead.

HTH
Emil

[1]
https://lists.freedesktop.org/archives/mesa-dev/2017-March/147163.html
https://lists.freedesktop.org/archives/mesa-dev/2017-May/157116.html
https://lists.freedesktop.org/archives/mesa-dev/2017-May/157203.html
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] protocol: make get_subsurface double-buffered

[Daniel Stone]

Hi Pekka,

On 9 May 2016 at 12:45, Pekka Paalanen  wrote:
> The existing specification was not explicitly clear on when
> wl_subcompositor.get_subsurface request actually adds the sub-surface to
> the parent in the compositor's scenegraph. The implicit assumption was
> that this happens immediately, but it was not written anywhere.

I think now is as good a time as any to actually land this, with the
million review/ack tags it's accumulated since. Which I've now done.

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

Re: [PATCH wayland] Do not create man page links with doxygen

[Daniel Stone]

Hi Armin,

On 27 July 2017 at 13:08, Armin K  wrote:
> There is a lot of files created with .so links to non-installed
> files, making most of installed pages useless. The files
> referenced in .so links are not suitable for installation nor
> do they contain any useful information for them to be worth
> fixing.

Thanks, reviewed and pushed.

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

Re: [PATCH] eventloop: clarify post_dispatch_check()

[Daniel Stone]

Hi Chris,

On 28 August 2017 at 09:03,   wrote:
> This *technically* changes the semantics of the return value of the source 
> callbacks.
> Previously you could return a negative number from a source callback and it 
> would prevent
> *other* source callbacks from triggering a subsequent recheck.
>
> Doing that seems like such a bad idea it's not worth supporting.
>
> v2: Log this case if it is hit, so we don't silently change behaviour.

Thanks for this! Reviewed and pushed now.

Cheers,
Daniel
___
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

[Daniel Stone]

Hi Jonas,

On 2 December 2017 at 02:57, 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.

[its-happening.gif]

Reviewed and pushed.

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

Re: [PATCH weston 2/2] desktop-shell: Handle the fullscreen to maximized case safely

[Daniel Stone]

Hi Derek,

On 6 October 2017 at 20:37, Derek Foreman  wrote:
> When a client transitions from maximized to fullscreen to maximized (run
> weston-terminal, maximize it, hit f11 twice) we're sending size 0,0 for
> the unfullscreen configure, which still has maximized set.
>
> This results in clients correctly picking any size they like, and weston
> disconnecting them for it.
>
> Instead, pass the correct maximized size.

Thanks, sounds plausible enough on the face of it. Reviewed and pushed.

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

Re: [PATCH weston 1/3] tests: add a create_test_surface function

[Daniel Stone]

Hi Emilio,

On 3 February 2017 at 15:10, Emilio Pozuelo Monfort  wrote:
> This doesn't attach a buffer to the surface. This is needed for the
> next commit, where we have a test case with a surface that doesn't
> have a buffer attached.

Thanks, this seems obviously fine so I've pushed this patch. Looks
like the other two need more work though.

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

Re: [PATCH weston v2] input: Do not override keyboard focus on restore

[Daniel Stone]

Hi Quentin,

On 21 July 2017 at 13:02, Quentin Glidic
 wrote:
> If we start a special (grabbing) client when Weston is unfocused, it
> would lose focus when coming back to Weston.

Thanks for this; reviewed and pushed.

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

Re: [PATCH weston 2/2] compositor-x11: Implement mode switching

[Daniel Stone]

Hi Armin,

On 28 October 2016 at 23:26, Armin Krezović  wrote:
> Signed-off-by: Armin Krezović 

I couldn't find anything wrong with this one, so have reviewed and
pushed it now. Was probably about time.

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

Re: [PATCH] clients: simple-egl: Restore window size when un-maximized

[Daniel Stone]

Hi,

On 26 June 2017 at 17:01, Tomohiro Komagata
 wrote:
> The window position was correct but the window size was wrong
> when simple-egl returns from maximized window to un-maximized.
> Its size should be restored to original size.

Thankyou very much for the patch. I have reviewed it and pushed it to git.

Cheers,
Daniel
___
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()

[Daniel Stone]

Hi Sergei,

On 31 May 2017 at 22:17, 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.

Thanks for this patch, it's now reviewed and pushed to mainline.

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

Re: [PATCH weston 1/2] config-parser: fix `short_name` type

[Daniel Stone]

Hi Eric,

On 8 June 2017 at 22:20, Eric Engestrom  wrote:
> On Wednesday, 2017-05-24 21:23:14 +0100, Eric Engestrom wrote:
>> This field is populated with chars, compared to chars and printed as
>> a char. It should probably be a char.
>>
>> Signed-off-by: Eric Engestrom 
>
> Humble ping?
>
> I don't have commit access either, so you'll have to push this for me :)

Sorry for the hideous delay. Reviewed and pushed both now.

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

Re: [PATCH] compositor-drm: fix z-order inversion in plane assignment

[Daniel Stone]

Hi Matt,

On 5 September 2017 at 15:13, Matt Hoosier  wrote:
> On Tue, Sep 5, 2017 at 9:00 AM, Daniel Stone  wrote:
>> It can't be correct to raise it to the cursor plane either, since both
>> cursor and overlay planes strictly stack above the scanout plane. I
>> guess this would read a lot easier with:
>> if (picked_scanout)
>> next_plane = primary;
>> at the top of the loop.
>
> Okay, sure. I think that in practice, no cursor surface would ever
> have the right dimensions to get picked by prepare_overlay_view() or
> prepare_scanout_view(), but I agree with you in principle.
>
> Thanks for the feedback. I see that you've resubmitted the atomic
> modesetting series again. Do you feel like it's near enough landing
> that there's no use in trying to commit a copy of this fix to master?

Might as well just push it by now, which I have in fact done last night. Thanks!

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

Re: [PATCH] weston: added missing header time.h

[Daniel Stone]

Hi Valery,

On 9 August 2017 at 12:27, Valery Kartel  wrote:
> without it I can't built weston on alpinelinux

Thanks for your patch; I've reviewed and pushed it.

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

Re: [PATCH weston] tests: Fix integer overflows on 32-bit systems

[Daniel Stone]

Hi Alexandros,

On 1 December 2017 at 17:28, Alexandros Frantzis
 wrote:
> Ensure that the integer type used in expressions involving
> multiplication with NSEC_PER_SEC is large enough to avoid overflows on
> 32-bit systems. In the expressions fixed by this patch a 64-bit type
> (long long) is required.

Thanks! Reviewed and pushed.

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

Re: [PATCH weston 1/2] clients: Don't crash when compositor doesn't support drag and drop

[Daniel Stone]

Hi Derek,

On 20 April 2017 at 20:31, Derek Foreman  wrote:
> display_create_data_source() can return NULL when there's no data device
> manager present.  Instead of carrying on blindly, test its return value.

Both seem trivially correct, reviewed and pushed.

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

Re: [PATCH weston v2] configure.ac: use PKG_CHECK_VAR for wayland-protocols

[Daniel Stone]

Hi,

On 18 July 2017 at 14:31, Pekka Paalanen  wrote:
> On Fri, 7 Jul 2017 10:51:16 +0200 Olivier Blin  
> wrote:
>> Also note that this requires a relatively new pkg-config for PKG_CHECK_VAR.
>> The macro appeared in pkg-config 0.28, from January 2013.
>>
>> It is for example not available in Ubuntu 14.04 LTS, which only provides
>> pkg-config 0.26.
>
> Hi,
>
> is anyone actually against requiring pkg-config 0.28? It sounds fine to
> me, so I'll give:
> Acked-by: Pekka Paalanen 

I think requiring it is fine.

> I think the pkg-config's own version check would need bumping, and I
> have a feeling the above M4 could use more quoting just in case.

Yes, the second and third arguments should be quoted.

> If the MODULE requirement for PKG_CHECK_VAR is not satisfied, does it
> fail the whole configure like we would want? The documentation does not
> say.

It doesn't, but takes action-if-found and action-if-not-found
arguments. Olivier, could you please respin to add an AC_MSG_ERROR
failure when it's not found?

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

[PATCH] scanner: add --no-documentation flag

[Felipe Ferreira da Silva]

The --no-documentation flag sets a static global variable print_doc to
`false`. When activated, the flag prevents wayland-scanner to print the
documentation comments. The copyright notice is not affected by this
flag.

Signed-off-by: Felipe Ferreira da Silva 
---
 src/scanner.c | 218 +-
 1 file changed, 123 insertions(+), 95 deletions(-)

diff --git a/src/scanner.c b/src/scanner.c
index c345ed6..a23e371 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -52,6 +52,8 @@ extern int DTD_DATA_len;
 
 #define PROGRAM_NAME "wayland-scanner"
 
+static bool print_doc = true;
+
 enum side {
CLIENT,
SERVER,
@@ -72,7 +74,8 @@ usage(int ret)
" the scanner was built 
against.\n"
"-c,  --include-core-only include the core 
version of the headers,\n"
" that is e.g. 
wayland-client-core.h instead\n"
-   " of 
wayland-client.h.\n");
+   " of 
wayland-client.h.\n"
+   "--no-documentation   don't include the 
documentation.\n");
exit(ret);
 }
 
@@ -1004,7 +1007,8 @@ emit_opcode_versions(struct wl_list *message_list, struct 
interface *interface)
struct message *m;
 
wl_list_for_each(m, message_list, link) {
-   printf("/**\n * @ingroup iface_%s\n */\n", interface->name);
+   if (print_doc)
+   printf("/**\n * @ingroup iface_%s\n */\n", 
interface->name);
printf("#define %s_%s_SINCE_VERSION %d\n",
   interface->uppercase_name, m->uppercase_name, m->since);
}
@@ -1047,7 +1051,8 @@ emit_stubs(struct wl_list *message_list, struct interface 
*interface)
struct arg *a, *ret;
int has_destructor, has_destroy;
 
-   printf("/** @ingroup iface_%s */\n", interface->name);
+   if (print_doc)
+   printf("/** @ingroup iface_%s */\n", interface->name);
printf("static inline void\n"
   "%s_set_user_data(struct %s *%s, void *user_data)\n"
   "{\n"
@@ -1056,7 +1061,8 @@ emit_stubs(struct wl_list *message_list, struct interface 
*interface)
   interface->name, interface->name, interface->name,
   interface->name);
 
-   printf("/** @ingroup iface_%s */\n", interface->name);
+   if (print_doc)
+   printf("/** @ingroup iface_%s */\n", interface->name);
printf("static inline void *\n"
   "%s_get_user_data(struct %s *%s)\n"
   "{\n"
@@ -1091,7 +1097,8 @@ emit_stubs(struct wl_list *message_list, struct interface 
*interface)
}
 
if (!has_destroy && strcmp(interface->name, "wl_display") != 0) {
-   printf("/** @ingroup iface_%s */\n", interface->name);
+   if (print_doc)
+   printf("/** @ingroup iface_%s */\n", interface->name);
printf("static inline void\n"
   "%s_destroy(struct %s *%s)\n"
   "{\n"
@@ -1120,11 +1127,13 @@ emit_stubs(struct wl_list *message_list, struct 
interface *interface)
ret = a;
}
 
-   printf("/**\n"
-  " * @ingroup iface_%s\n", interface->name);
-   if (m->description && m->description->text)
-   format_text_to_comment(m->description->text, false);
-   printf(" */\n");
+   if (print_doc) {
+   printf("/**\n"
+  " * @ingroup iface_%s\n", interface->name);
+   if (m->description && m->description->text)
+   format_text_to_comment(m->description->text, 
false);
+   printf(" */\n");
+   }
if (ret && ret->interface_name == NULL)
printf("static inline void *\n");
else if (ret)
@@ -1220,17 +1229,19 @@ emit_event_wrappers(struct wl_list *message_list, 
struct interface *interface)
return;
 
wl_list_for_each(m, message_list, link) {
-   printf("/**\n"
-  " * @ingroup iface_%s\n"
-  " * Sends an %s event to the client owning the 
resource.\n",
-  interface->name,
-  m->name);
-   printf(" * @param resource_ The client's resource\n");
-   wl_list_for_each(a, >arg_list, link) {
-   if (a->summary)
-   printf(" * @param %s %s\n", a->name, 
a->summary);
+   if (print_doc) {
+   printf("/**\n"
+  " * @ingroup iface_%s\n"
+ 

Re: [PATCH wayland] scanner: Add autoconf macro to check for the proper scanner

[Burton, Ross]

On 5 December 2017 at 13:15, Daniel Stone  wrote:

> Hi Quentin,
> I've added Ross and Fabien, who've been looking at this for Yocto.
>
> On 18 August 2017 at 10:30, Quentin Glidic
>  wrote:
> > --- a/wayland-scanner.m4
> > +++ b/wayland-scanner.m4
> > @@ -1,3 +1,5 @@
> > +#serial 2
>
> I don't quite understand the significance of this.
>

autoconf macros can be versioned and this is how that is done.  You don't
see it much in practise because the one piece of autoconf which should
respect the versions doesn't, but I approve of the intention!

Fixing aclocal is on my long list of Things To Do, but this involves 1)
autoconf 2) m4 so would mean more mental strength than I currently have.


> > +# WL_PROG_WAYLAND_SCANNER()
> > +AC_DEFUN([WL_PROG_WAYLAND_SCANNER], [
> > +AC_REQUIRE([AC_CANONICAL_BUILD])
> > +AC_REQUIRE([PKG_PROG_PKG_CONFIG])
> > +wl_cv_native_pkg_config=
> > +AS_IF([test x${cross_compiling} = xyes], [
> > +wl_cv_native_pkg_config=${build}-pkg-config
> > +AC_PATH_PROGS([wl_cv_native_pkg_config], [${build}-pkg-config])
>
> Ah, no thanks. I would prefer to have this passed in as
> $HOST_PKG_CONFIG (following the $HOST_CC precedent), falling back to
> just plain 'pkg-config'. Guessing triplets is a bit too much like
> magic, especially when you can be 'cross-compiling' to the same
> triplet.
>

I'm not aware of a precedent for "this is the host pkgconfig" but I endorse
HOST_PKG_CONFIG.  Clear semantics and we could export it globally.

It would be great if someone pushed that into pkg.m4...

The rest looks good to me, so assuming we can test it in Yocto and it
> works fine there, then it should be good to merge.
>

I'll definitely throw a v2 at our autobuilder cluster to see what happens.
This builds gtk+, xserver-xorg and gstreamer with wayland support, which
isn't everything but should be enough to find any gotchas.

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

Re: [PATCH wayland] scanner: Add autoconf macro to check for the proper scanner

[Daniel Stone]

Hi Quentin,
I've added Ross and Fabien, who've been looking at this for Yocto.

On 18 August 2017 at 10:30, Quentin Glidic
 wrote:
> --- a/wayland-scanner.m4
> +++ b/wayland-scanner.m4
> @@ -1,3 +1,5 @@
> +#serial 2

I don't quite understand the significance of this.

> +# WL_PROG_WAYLAND_SCANNER()
> +AC_DEFUN([WL_PROG_WAYLAND_SCANNER], [
> +AC_REQUIRE([AC_CANONICAL_BUILD])
> +AC_REQUIRE([PKG_PROG_PKG_CONFIG])
> +wl_cv_native_pkg_config=
> +AS_IF([test x${cross_compiling} = xyes], [
> +wl_cv_native_pkg_config=${build}-pkg-config
> +AC_PATH_PROGS([wl_cv_native_pkg_config], [${build}-pkg-config])

Ah, no thanks. I would prefer to have this passed in as
$HOST_PKG_CONFIG (following the $HOST_CC precedent), falling back to
just plain 'pkg-config'. Guessing triplets is a bit too much like
magic, especially when you can be 'cross-compiling' to the same
triplet.

> +wl_cv_scanner_found=no
> +wl_cv_scanner_wanted_version=`${PKG_CONFIG} --modversion wayland-server`
> +AC_MSG_CHECKING([that wayland-client and wayland-server versions are the 
> same])
> +AS_IF([test ${wl_cv_scanner_wanted_version} = `${PKG_CONFIG} 
> --modversion wayland-client`], [
> +AC_MSG_RESULT([ok])
> +], [
> +AC_MSG_ERROR([mismatch])
> +])
> +AC_MSG_CHECKING([for wayland-scanner ${wl_cv_scanner_wanted_version}])
> +AS_IF([test x${ac_cv_env_WAYLAND_SCANNER_set} = xset], [
> +_WL_PROG_WAYLAND_SCANNER_VERSION_CHECK()
> +])
> +AS_IF([test x${cross_compiling} = xyes -a x${wl_cv_native_pkg_config} != 
> xno], [
> +AS_IF([AC_RUN_LOG([${wl_cv_native_pkg_config} --exists 
> --print-errors wayland-scanner = ${wl_cv_scanner_wanted_version}])], [
> +WAYLAND_SCANNER=`${wl_cv_native_pkg_config} 
> --variable=wayland_scanner wayland-scanner = ${wl_cv_scanner_wanted_version}`
> +_WL_PROG_WAYLAND_SCANNER_VERSION_CHECK()
> +])
> +])
> +AS_IF([test x${wl_cv_scanner_found} = xno], [
> +AS_IF([AC_RUN_LOG([${PKG_CONFIG} --exists --print-errors 
> wayland-scanner = ${wl_cv_scanner_wanted_version}])], [
> +WAYLAND_SCANNER=`${PKG_CONFIG} --variable=wayland_scanner 
> wayland-scanner = ${wl_cv_scanner_wanted_version}`
> +_WL_PROG_WAYLAND_SCANNER_VERSION_CHECK()
> +])
> +])

I found this whole AS_IF forest pretty difficult to read. The last one
seems like we could also try to end up running a non-native version if
we fall through? It's also quite verbose on checking. Shrug.

The rest looks good to me, so assuming we can test it in Yocto and it
works fine there, then it should be good to merge.

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

Re: [RFC wayland-protocols] presentation-time: Add request to subscribe to wl_output presentation timings

[Daniel Stone]

Hi Alexandros,

On 31 August 2017 at 16:37, Alexandros Frantzis
 wrote:
> thank you for the additional feedback. I have attached an updated
> version which addresses your comments.
>
> I still haven't got any feedback from Chromium concerning the potential
> change from wl_output based timings to wl_surface based timings as
> discussed in previous emails, so, for the time being, I am keeping this
> proposal in RFC status.

I think this ended up being fine for Chromium/Exosphere, right?

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

Re: [RFC PATCH xserver] xwayland: Fix non-argb cursor conversion

[Daniel Stone]

On 27 September 2017 at 17:01, Olivier Fourdan  wrote:
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=103012
> Signed-off-by: Olivier Fourdan 

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

Re: [PATCH weston 5/5] gl-renderer: use correct pixel shader for NV12 format uploaded to RG texture

[Vincent ABRIOU]

Hi Arnaud,

On 12/04/2017 06:15 PM, Arnaud Vrac wrote:
> On Mon, Dec 4, 2017 at 6:08 PM, Emil Velikov  wrote:
>> On 29 November 2017 at 14:25, Arnaud Vrac  wrote:
>>> Signed-off-by: Arnaud Vrac 
>>
>> Please mention how you've spotted and/or verified this.
>>
>> I'm ~90% this is correct, although I would check with the author.
>> Vincent, can you double check the patch/series [1]?
> 
> I'm also not 100% sure about this one, I found all three drivers I
> mentionned on the cover letter displayed the wrong colors for NV12
> with R/G textures. This just seemed the logical fix after reading the
> pixel shaders code.
> 
> I'll mention this in the commit message.
> 

Your patch looks good.
I had no way to test has_gl_texture_rg when I submit 00a03d2f724 
("gl-renderer: add support of WL_SHM_FORMAT_NV12")

Thanks for testing it and correcting it.
Reviewed-by: Vincent Abriou 

BR
Vincent

> Thanks,
> -Arnaud
> 
>>
>> Fixes: 00a03d2f724 ("gl-renderer: add support of WL_SHM_FORMAT_NV12")
>> Cc: Vincent Abriou 
>>
>> -Emil
>>> ---
>>>   libweston/gl-renderer.c | 3 ++-
>>>   1 file cNphanged, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
>>> index 60a7bf06..4fffa78c 100644
>>> --- a/libweston/gl-renderer.c
>>> +++ b/libweston/gl-renderer.c
>>> @@ -1596,7 +1596,6 @@ gl_renderer_attach_shm(struct weston_surface *es, 
>>> struct weston_buffer *buffer,
>>>  }
>>>  break;
>>>  case WL_SHM_FORMAT_NV12:
>>> -   gs->shader = >texture_shader_y_xuxv;
>>>  pitch = wl_shm_buffer_get_stride(shm_buffer);
>>>  gl_pixel_type = GL_UNSIGNED_BYTE;
>>>  num_planes = 2;
>>> @@ -1605,9 +1604,11 @@ gl_renderer_attach_shm(struct weston_surface *es, 
>>> struct weston_buffer *buffer,
>>>  gs->hsub[1] = 2;
>>>  gs->vsub[1] = 2;
>>>  if (gr->has_gl_texture_rg) {
>>> +   gs->shader = >texture_shader_y_uv;
>>>  gl_format[0] = GL_R8_EXT;
>>>  gl_format[1] = GL_RG8_EXT;
>>>  } else {
>>> +   gs->shader = >texture_shader_y_xuxv;
>>>  gl_format[0] = GL_LUMINANCE;
>>>  gl_format[1] = GL_LUMINANCE_ALPHA;
>>>  }
>>> --
>>> 2.15.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 2/2] server: add log message when client connection is destroyed due to an error

[Fiedler, Mathias]

Hi Daniel,

thanks for your review. I will drop the storing and forwarding of the errno 
code.

Regards,
Mathias

From: Daniel Stone 
Sent: Monday, December 4, 2017 10:06 PM
To: Fiedler, Mathias
Cc: wayland-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/2] server: add log message when client connection is 
destroyed due to an error

Hi Mathias,
Thanks for your patch! The idea seems fine, but I have a few comments.

On 8 June 2017 at 08:39,   wrote:
> @@ -313,16 +326,30 @@ wl_client_connection_data(int fd, uint32_t mask, void 
> *data)
> uint32_t resource_flags;
> int opcode, size, since;
> int len;
> +   int err;
> +   socklen_t errlen;
>
> -   if (mask & (WL_EVENT_ERROR | WL_EVENT_HANGUP)) {
> +   if (mask & WL_EVENT_HANGUP) {
> wl_client_destroy(client);
> return 1;
> }
>
> +   if (mask & WL_EVENT_ERROR) {
> +   // query socket error
> +   errlen = sizeof(err);
> +   if (getsockopt(fd, SOL_SOCKET, SO_ERROR, , )) {
> +   // when getsockopt fails use its error instead
> +   err = errno;

I don't believe that errno is necessarily related in this case, so we
can't pass it to the client.

> @@ -334,7 +361,8 @@ wl_client_connection_data(int fd, uint32_t mask, void 
> *data)
> if (mask & WL_EVENT_READABLE) {
> len = wl_connection_read(connection);
> if (len == 0 || (len < 0 && errno != EAGAIN)) {
> -   wl_client_destroy(client);
> +   destroy_client_with_error(
> +   client, "failed to read client connection", 
> errno);

If (len == 0), errno may be irrelevant.

The same is true in your first patch: I believe there are a few places
where we might leak errno to the client when it is not actually
relevant. It would be nice to change the 'if (client->error)' checks
in that patch to (client->error != 0) as well, just to be more
explicit.

Also, your patch uses // C++ comments like this.

Please use /* Old-style C comments */ instead, but whilst you're at
it, comments like 'query socket error' are obvious enough from reading
the surrounding context that they are not really required.

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

Re: [PATCH wayland-protocols 1/3] Add meson build system support

[Philipp Zabel]

 Signed-off-by: Jonas Ådahl 
> ---
>  meson.build | 81 
> +
>  meson_options.txt   |  4 +++
>  tests/meson.build   | 13 
>  wayland-protocols.pc.in |  2 +-
>  4 files changed, 99 insertions(+), 1 deletion(-)
>  create mode 100644 meson.build
>  create mode 100644 meson_options.txt
>  create mode 100644 tests/meson.build
> 
> diff --git a/meson.build b/meson.build
> new file mode 100644
> index 000..b7f2a5b
> --- /dev/null
> +++ b/meson.build
> @@ -0,0 +1,81 @@
> +project('wayland-protocols',
> +version: '1.11',
> +meson_version: '>= 0.36.0')
> +wayland_protocols_version = meson.project_version()
> +
> +stable_protocols = [
> +  'stable/presentation-time/presentation-time.xml',
> +  'stable/viewporter/viewporter.xml',
> +]
> +
> +unstable_protocols = [
> +  'unstable/pointer-gestures/pointer-gestures-unstable-v1.xml',
> +  'unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml',
> +  'unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml',
> +  'unstable/text-input/text-input-unstable-v1.xml',
> +  'unstable/input-method/input-method-unstable-v1.xml',
> +  'unstable/xdg-shell/xdg-shell-unstable-v5.xml',
> +  'unstable/xdg-shell/xdg-shell-unstable-v6.xml',
> +  'unstable/relative-pointer/relative-pointer-unstable-v1.xml',
> +  'unstable/pointer-constraints/pointer-constraints-unstable-v1.xml',
> +  'unstable/tablet/tablet-unstable-v1.xml',
> +  'unstable/tablet/tablet-unstable-v2.xml',
> +  'unstable/xdg-foreign/xdg-foreign-unstable-v1.xml',
> +  'unstable/xdg-foreign/xdg-foreign-unstable-v2.xml',
> +  'unstable/idle-inhibit/idle-inhibit-unstable-v1.xml',
> +  'unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml',
> +  
> 'unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml',
> +  'unstable/xdg-output/xdg-output-unstable-v1.xml',
> +]
> +
> +protocols = stable_protocols + unstable_protocols
> +
> +# Check that each protocol has a README
> +foreach protocol : protocols
> +  protocol_components = protocol.split('/')
> +  stability = protocol_components[0]
> +  protocol_name = protocol_components[1]
> +  readme_path = join_paths(meson.source_root(),
> +   stability,
> +   protocol_name,
> +   'README')
> +  if run_command('[', '-f', readme_path, ']').returncode() != 0
> +error('Missing README in @0@'.format(protocol))
> +  endif
> +endforeach
> +
> +wayland_scanner = find_program('wayland-scanner')
> +
> +foreach protocol : stable_protocols + unstable_protocols

There is a "protocols" shorthand defined above, it could be reused here.

Not sure if it would be beneficial to merge this loop and the README
loop above to reduce the path splitting boilerplate?

> +  protocol_components = protocol.split('/')
> +  stability = protocol_components[0]
> +  protocol_name = protocol_components[1]
> +  xml_file = protocol_components[2]

xml_file is unused.

> +  protocol_install_dir = join_paths(get_option('datadir'),
> +'wayland-protocols',
> +stability,
> +protocol_name)
> +  install_data(protocol,
> +   install_dir: protocol_install_dir)
> +endforeach

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

Re: [PATCH weston 4/5] gl-renderer: fix pixel format used in texture uploads when using R/RG textures

[Vincent ABRIOU]

Hi Arnaud,

Reviewed-by: Vincent Abriou 

BR
Vincent

On 12/04/2017 05:56 PM, Emil Velikov wrote:
> On 29 November 2017 at 14:25, Arnaud Vrac  wrote:
>> From: Arnaud Vrac 
>>
>> In glTexImage2D / glTexSubImage2D calls, the only pixel formats allowed
>> for the GL_R8 and GL_RG internal formats are respectively GL_RED and
> s/GL_RG/GL_RG8/ ^^
> 
>> GL_RG [1].
>>
>> Make sure we match this requirement, as some drivers will fail with the
>> current code.
>>
> AFAICT the patch is spot on. Trivial suggestion below:
> Reviewed-by: Emil Velikov 
> 
> 
> I'd suggest using something like the following. A reference to the
> offending code is always nice, plus CC-ing the author gives you an
> extra reviewer ;-)
> 
> Fixes: 00a03d2f724 ("gl-renderer: add support of WL_SHM_FORMAT_NV12")
> Cc: Vincent Abriou 
> 
> HTH
> Emil
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH xserver] dix: avoid deferencing NULL PtrCtrl

[Olivier Fourdan]

PtrCtrl really makes sense for relative pointing device only, absolute
devices such as touch devices do not have any PtrCtrl set.

In some cases, if the client issues a XGetPointerControl() immediatlely
after a ChangeMasterDeviceClasses() copied the touch device to the VCP,
a NULL pointer dereference will occur leading to a crash of Xwayland.

Check whether the PtrCtrl is not NULL in ProcGetPointerControl() and
return the default control values oterhwise, to avoid the NULL pointer
dereference.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1519533
Signed-off-by: Olivier Fourdan 
---
 dix/devices.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/dix/devices.c b/dix/devices.c
index ea3c6c8a9..4a628afb0 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -2329,10 +2329,15 @@ int
 ProcGetPointerControl(ClientPtr client)
 {
 DeviceIntPtr ptr = PickPointer(client);
-PtrCtrl *ctrl = >ptrfeed->ctrl;
+PtrCtrl *ctrl;
 xGetPointerControlReply rep;
 int rc;
 
+if (ptr->ptrfeed)
+ctrl = >ptrfeed->ctrl;
+else
+ctrl = 
+
 REQUEST_SIZE_MATCH(xReq);
 
 rc = XaceHook(XACE_DEVICE_ACCESS, client, ptr, DixGetAttrAccess);
-- 
2.14.3

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

[PATCH v2] server: add log message when client connection is destroyed due to an error

[Mathias Fiedler]

The client connection is destroyed by the server in several
circumstances. This patch adds log messages in case the connection is
destroyed due to an error other than normal hangup.

Signed-off-by: Mathias Fiedler 
---
 src/wayland-server.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/src/wayland-server.c b/src/wayland-server.c
index 82a3b01..ebdd695 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -300,6 +300,13 @@ wl_resource_post_error(struct wl_resource *resource,
client->error = 1;
 }
 
+static void
+destroy_client_with_error(struct wl_client *client, const char *reason)
+{
+   wl_log("%s (pid %u)\n", reason, client->ucred.pid);
+   wl_client_destroy(client);
+}
+
 static int
 wl_client_connection_data(int fd, uint32_t mask, void *data)
 {
@@ -314,15 +321,21 @@ wl_client_connection_data(int fd, uint32_t mask, void 
*data)
int opcode, size, since;
int len;
 
-   if (mask & (WL_EVENT_ERROR | WL_EVENT_HANGUP)) {
+   if (mask & WL_EVENT_HANGUP) {
wl_client_destroy(client);
return 1;
}
 
+   if (mask & WL_EVENT_ERROR) {
+   destroy_client_with_error(client, "socket error");
+   return 1;
+   }
+
if (mask & WL_EVENT_WRITABLE) {
len = wl_connection_flush(connection);
if (len < 0 && errno != EAGAIN) {
-   wl_client_destroy(client);
+   destroy_client_with_error(
+   client, "failed to flush client connection");
return 1;
} else if (len >= 0) {
wl_event_source_fd_update(client->source,
@@ -334,7 +347,8 @@ wl_client_connection_data(int fd, uint32_t mask, void *data)
if (mask & WL_EVENT_READABLE) {
len = wl_connection_read(connection);
if (len == 0 || (len < 0 && errno != EAGAIN)) {
-   wl_client_destroy(client);
+   destroy_client_with_error(
+   client, "failed to read client connection");
return 1;
}
}
@@ -418,8 +432,10 @@ wl_client_connection_data(int fd, uint32_t mask, void 
*data)
len = wl_connection_pending_input(connection);
}
 
-   if (client->error)
-   wl_client_destroy(client);
+   if (client->error) {
+   destroy_client_with_error(client,
+ "error in client communication");
+   }
 
return 1;
 }
-- 
2.7.4

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