Re: [ANNOUNCE] wayland 1.10.91

[Jonas Ådahl]

On Wed, May 11, 2016 at 12:11:50PM -0700, Bryce Harrington wrote:
> On Fri, May 06, 2016 at 02:17:23PM +0300, Pekka Paalanen wrote:
> > On Wed, 4 May 2016 11:46:23 -0700
> > Bryce Harrington  wrote:
> > 
> > > On Wed, May 04, 2016 at 12:55:16AM -0700, Bryce Harrington wrote:
> > > > Here's the alpha for the upcoming 1.11 release.  I'll summarize the
> > > > major features for this release in the beta announcement, but see below
> > > > for the detailed listing.
> > > > 
> > > > The schedule going forward is:
> > > > 
> > > >   √ 1.11-alpha on May 3rd.  Major features done by this point.
> 
> It looks like someone (pq?) has marked some patches we decided to leave
> for post-1.11 as deferred in patchwork.  I've followed suit and moved
> other patchsets there which are new APIs or that sound like feature
> work.
> 
> Following are what remains.  Most of these I think should be deferred
> but am not 100% certain, so would appreciate hearing other people's
> thoughts:
> 
> 
> 1. Detect keyboard capabilities, refactor seat capability [Derek]
>- Awaiting review by jadahl
>- Over a year old now, probably needs rebased too...

I have completely forgotten about this one, sorry about that. I could
take it upon me to review this if its valuable for 1.11, but as far as I
remember I was not very happy about the internal API changes.

> 
> 2. xdg_popup behavior of input devices [Carlos]
>- Protocol additions for xdg-shell, needs review by xdg devels
>- Been in the queue a long time, but no reviews to date
>- No idea about disposition for this

Any changes to xdg_shell should target the v6, it needs to be rebased.
Might be something good to revisit before finalizing a v6.

> 
> 3. xwayland drag-and-drop window creation [Carlos]
>- Looks ok to be but xwayland isn't my area
>- Been in the queue a long time, but no reviews to date
>- From the commit description sounds WIP-ish and that there was
>  planned some followup work, but not sure if that happened?

This one can have my Acked-by for 1.11 since it avoids crashing weston.
As far as I can tell, wayland<->xwayland dnd is currently broken either
way, and hopefully Carlos can have a look for 1.12.

> 
> 4. Pointer locking (3 patches) [Jonas]
>- Was planned to land this feature for 1.11
>- Reviewers requested changes, but I'm not spotting a v2 for this
>- At a minimum needs updated for trunk, since the protocol files are
>  now in wayland-protocols
>- I'll mark it 'Changes Requested' and hope it will return for
>  consideration for 1.12.

I won't work on these for 1.11.

> 
> 5. V2 for text input protocol [Jan Arne]
>- This is intended for wayland-protocols so not really pertinent to
>  the release.  But is on v6 and hasn't received further reviews,
>  perhaps it's time to land it?

There has been some disagreements on various parts being out-of-scope
for said protocol. I think we need to discuss this one further before
landing.

> 
> 6. FreeRDP fixes (6 patches) [David]
>- Build fixes are suitable for landing now, so I consider at least
>  the first 3 patches here good candidates for including in 1.11
>- No R-b's other than my own; I'd be more comfortable landing if we
>  had another set of R-b's on this.
> 
> 7. compositor-drm clone mode + fixes (8 patches) [Emmanuel]
>- The fixes look straightforward and probably ok to land
>- I haven't reviewed the clone mode feature, but offhand judging by
>  the length of the patch it looks like post-1.11 stuff.
> 
> 8. get_subsurface double-buffered protocol [pq]
>- Is getting strong reviews, but also requests for tests 
>- There is debate on its thread as to whether to land vs. leave for
>  1.12

We are waiting with this one until 1.12.

> 
> 9. Don't set_fullscreen on already fullscreen surfaces [Emmanuel]
>- Short fix, might be worth including in 1.11
>- Needs another R-b or two, but may be an easy thing to land
> 
> 10. compositor fixes (2 patches) [pq]
> 11. eventdemo fixes (3 patches) [pq]
>- These sound landable for 1.11 offhand, but I haven't reviewed.
>- Needs R-b's
> 
> 12. ivi_layout_surface API
>- Straightforward patch, looks fine to me
>- Not sure about landing new API during feature freeze though
>- Needs R-b's
> 

For the ones I didn't comment on, I have no input right now.


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

Re: [PATCH v3 wayland-protocols 4/4] tablet: Add pad support to the tablet protocol

[Peter Hutterer]

On Wed, May 11, 2016 at 11:44:45AM -0700, Jason Gerecke wrote:
> On Tue, May 10, 2016 at 7:51 PM, Peter Hutterer
>  wrote:
> > From: Carlos Garnacho 
> >
> > The pad's interface is similar to the tool interface, a client is notified 
> > of
> > the pad after the tablet_added event.
> >
> > The pad has three functionalities: buttons, rings and strips.
> > Buttons are fairly straightforward, rings and strips are separate interfaces
> > with a pointer-axis-like source/value/frame events.
> > The two interfaces are effectively identical but for the actual value they
> > send (degrees vs normalized position).
> >
> > Buttons are sequentially indexed starting with zero, unlike other protocols
> > where a linux/input.h-style semantic event code is used. Since we expect all
> > buttons to have client-specific functionality, an additional event tells the
> > client when a given button index is not available, usually because the
> > compositor assignes some function to it (e.g. mode switching, see below).
> >
> > Specific to the pad device is the set_feedback request which enables a 
> > client
> > to set a user-defined string to display for an OSD on the current mappings.
> > This request is available for buttons, rings and strips.
> >
> > Finally, the pad supports "modes", effectively sets of button/ring/strip
> > configurations.
> >
> > Signed-off-by: Carlos Garnacho 
> > Signed-off-by: Peter Hutterer 
> > ---
> > Changes to v2:
> > - change to v2 of the protocol
> > - various comments and suggestions for improved wording incorporated
> > - ring is in wl_fixed degrees now (was int, in 0.01 of a degree)
> > - button events changed to sequential indices
> > - new buttons_reserved event
> >
> >  unstable/tablet/tablet-unstable-v2.xml | 436 
> > +
> >  1 file changed, 436 insertions(+)
> >
> > diff --git a/unstable/tablet/tablet-unstable-v2.xml 
> > b/unstable/tablet/tablet-unstable-v2.xml

[...]

> > +
> > +  
> > +   Requests the compositor to use the provided feedback string
> > +   associated with this button. This request should be issued
> > +   immediately after a wp_tablet_pad.enter event or whenever a button
> > +   is mapped to a different action.
> > +
> > +   Clients are encouraged to provide context-aware descriptions for
> > +   the actions associated with each button, and compositors may use
> > +   this information to offer visual feedback on the button layout
> > +   (e.g. on-screen displays).
> > +
> > +   The provided string 'description' is an UTF-8 encoded string to be
> > +   associated with this ring, and is considered user visible; general
> > +   internationalization rules apply.
> > +  
> > +  
> 
> The pad protocol doesn't use codes anymore. Perhaps change the summary
> of this argument to "button index" and mention that indices start at
> zero like in "buttons_reserved".

added the diff below:

diff --git a/unstable/tablet/tablet-unstable-v2.xml 
b/unstable/tablet/tablet-unstable-v2.xml
index 85a8f40..67c1134 100644
--- a/unstable/tablet/tablet-unstable-v2.xml
+++ b/unstable/tablet/tablet-unstable-v2.xml
@@ -897,11 +897,16 @@
this information to offer visual feedback on the button layout
(e.g. on-screen displays).
 
+   Button indices start at 0. Setting the feedback string on a button
+   that is reserved by the compositor (see
+   wp_tablet_pad.buttons_reserved) does not generate an error but the
+   compositor is free to ignore such a feedback string.
+
The provided string 'description' is an UTF-8 encoded string to be
associated with this ring, and is considered user visible; general
internationalization rules apply.
   
-  
+  
   
 
 

> > +
> > +
> > +  
> > +   Sent on wp_tablet_pad initialization and/or at a later time to 
> > notify the
> > +   client of reserved buttons.
> > +
> > +   Compositors may consume some buttons for global actions, those
> > +   global actions will not trigger wl_tablet_pad.button events (e.g.
> > +   the button to switch between modes, if any). This event notifies the
> > +   client that some button indices are reserved by the compositor and
> > +   will not generate events visible to the client. Button indices start
> > +   at 0.
> > +
> > +   This event may is sent in the initial burst of events before the
> > +   wp_tablet_pad.done event and/or at any later time when the
> > +   compositor changes the list of reserved buttons. This event is only
> > +   sent when the compositor reserves at least one button.
> 
> What happens when the number of buttons reserved by the compositor
> drops from nonzero to zero? Shouldn't this event be sent then as well
> (with a zero-length array)?

good point, added:

 + When the number of reserved 

Re: [PATCH v3 wayland-protocols 4/4] tablet: Add pad support to the tablet protocol

[Peter Hutterer]

On Wed, May 11, 2016 at 09:20:15AM -0500, Yong Bakos wrote:
> On May 10, 2016, at 9:51 PM, Peter Hutterer  wrote:
> > 
> > From: Carlos Garnacho 
> > 
> > The pad's interface is similar to the tool interface, a client is notified 
> > of
> > the pad after the tablet_added event.
> > 
> > The pad has three functionalities: buttons, rings and strips.
> > Buttons are fairly straightforward, rings and strips are separate interfaces
> > with a pointer-axis-like source/value/frame events.
> > The two interfaces are effectively identical but for the actual value they
> > send (degrees vs normalized position).
> > 
> > Buttons are sequentially indexed starting with zero, unlike other protocols
> > where a linux/input.h-style semantic event code is used. Since we expect all
> > buttons to have client-specific functionality, an additional event tells the
> > client when a given button index is not available, usually because the
> > compositor assignes some function to it (e.g. mode switching, see below).
> > 
> > Specific to the pad device is the set_feedback request which enables a 
> > client
> > to set a user-defined string to display for an OSD on the current mappings.
> > This request is available for buttons, rings and strips.
> > 
> > Finally, the pad supports "modes", effectively sets of button/ring/strip
> > configurations.
> > 
> > Signed-off-by: Carlos Garnacho 
> > Signed-off-by: Peter Hutterer 
> 
> Hi Carlos and Peter,
> I have some suggestions and corrections, noted inline below.

[...]

> > +   associated with this ring, and is considered user visible; general
> 
> user-visible or perhaps just "and is visible by the user;"
 
this is one I don't quite agree with, but this may be my interpretation:
"visible by the user" to me implies that the string is visible (i.e. shown)
but that may not be true at any given time.  user-visible does not have that
"shown" connotation, since it a technical term. I might be wrong on that
though.

I did change it locally to user-visible (i.e. with the dash)
 
> > +   internationalization rules apply.
> > +  
> > +  
> > +
> > +
> > +
> > +  
> > +   This destroys the client's resource for this ring object.
> > +  
> > +
> > +
> > +
> > +  
> > +   Describes the source types for ring events. This indicates to the
> > +   client how a ring event was physically generated; a client may
> > +   adjust the user interface accordingly. For example, events
> > +   from a "finger" source may trigger kinetic scrolling.
> > +  
> > +  
> > +
> > +
> > +
> > +  
> > +   Source information for ring events.
> > +
> > +   This event does not occur on its own. It is sent before a
> > +   wp_tablet_pad_ring.frame event and carries the source information
> > +   for all events within that frame.
> > +
> > +   The source specifies how this event was generated. If the source is
> > +   wp_tablet_pad_ring.source.finger, a wp_tablet_pad_ring.stop event
> > +   will be sent when the user lifts the finger off the device.
> > +
> > +   This event is optional. If the source is unknown for an interaction,
> > +   no event is sent.
> > +  
> > +  
> > +
> > +
> > +
> > +  
> > +   Sent whenever the angle on a ring changes.
> > +
> > +   The angle is provided in degrees clockwise from the logical
> > +   north of the ring in the pad's current rotation.
> > +  
> > +  
> 
> Perhaps the summary should mention units, eg "the current angle in degrees,"
> similar to the wheel event's degrees arg summary.

oh, actually, this is inconsistent with the rest where we use an arg name
"degrees". I've changed this locally.

all others amended as requested, thanks heaps!

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

Re: [PATCH weston] build: Define wayland prereq version

[Peter Hutterer]

On Wed, May 11, 2016 at 01:18:59PM -0700, Bryce Harrington wrote:
> Establishes a single variable for defining the libwayland version
> requirements.  Enforces the same version dependency between
> libwayland-client and libwayland-server, as recommended by pq in the
> 1.11 release discussions.
> 
> Signed-off-by: Bryce Harrington 
> ---
>  configure.ac | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 2ca1f4e..0b23fc4 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -4,6 +4,8 @@ m4_define([weston_micro_version], [91])
>  m4_define([weston_version],
>[weston_major_version.weston_minor_version.weston_micro_version])
>  
> +m4_define([WAYLAND_PREREQ_VERSION], "1.10.0")

how comes the line above uses [] and here you use ""? is that intentional?
(I keep forgetting whether there's a difference between the two in m4)

Cheers,
   Peter

> +
>  AC_PREREQ([2.64])
>  AC_INIT([weston],
>  [weston_version],
> @@ -60,7 +62,7 @@ AC_CHECK_HEADERS([execinfo.h])
>  
>  AC_CHECK_FUNCS([mkostemp strchrnul initgroups posix_fallocate])
>  
> -COMPOSITOR_MODULES="wayland-server >= 1.10.0 pixman-1 >= 0.25.2"
> +COMPOSITOR_MODULES="wayland-server >= WAYLAND_PREREQ_VERSION pixman-1 >= 
> 0.25.2"
>  
>  AC_CONFIG_FILES([doc/doxygen/tools.doxygen doc/doxygen/tooldev.doxygen])
>  
> @@ -193,7 +195,7 @@ AM_CONDITIONAL(ENABLE_WAYLAND_COMPOSITOR,
>  if test x$enable_wayland_compositor = xyes -a x$enable_egl = xyes; then
>AC_DEFINE([BUILD_WAYLAND_COMPOSITOR], [1],
>   [Build the Wayland (nested) compositor])
> -  PKG_CHECK_MODULES(WAYLAND_COMPOSITOR, [wayland-client >= 1.5.91 
> wayland-egl wayland-cursor])
> +  PKG_CHECK_MODULES(WAYLAND_COMPOSITOR, [wayland-client >= 
> WAYLAND_PREREQ_VERSION wayland-egl wayland-cursor])
>  fi
>  
>  
> @@ -332,7 +334,7 @@ AM_CONDITIONAL(ENABLE_VAAPI_RECORDER, test "x$have_libva" 
> = xyes)
>  
>  PKG_CHECK_MODULES(CAIRO, [cairo])
>  
> -PKG_CHECK_MODULES(TEST_CLIENT, [wayland-client >= 1.10.0])
> +PKG_CHECK_MODULES(TEST_CLIENT, [wayland-client >= WAYLAND_PREREQ_VERSION])
>  
>  AC_ARG_ENABLE(simple-clients,
>AS_HELP_STRING([--disable-simple-clients],
> @@ -386,9 +388,9 @@ AM_CONDITIONAL(BUILD_CLIENTS, test x$enable_clients = 
> xyes)
>  if test x$enable_clients = xyes; then
>AC_DEFINE([BUILD_CLIENTS], [1], [Build the Wayland clients])
>  
> -  PKG_CHECK_MODULES(CLIENT, [wayland-client >= 1.5.91 cairo >= 1.10.0 
> xkbcommon wayland-cursor])
> +  PKG_CHECK_MODULES(CLIENT, [wayland-client >= WAYLAND_PREREQ_VERSION cairo 
> >= 1.10.0 xkbcommon wayland-cursor])
>PKG_CHECK_MODULES(SERVER, [wayland-server])
> -  PKG_CHECK_MODULES(WESTON_INFO, [wayland-client >= 1.5.91])
> +  PKG_CHECK_MODULES(WESTON_INFO, [wayland-client >= WAYLAND_PREREQ_VERSION])
>  
># Only check for cairo-egl if a GL or GLES renderer requested
>AS_IF([test "x$cairo_modules" = "xcairo-gl" -o "x$cairo_modules" = 
> "xcairo-glesv2"], [
> -- 
> 1.9.1
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols 3/4] tablet: restrict the cursor surface to one per tool

[Peter Hutterer]

On Wed, May 11, 2016 at 08:04:35AM -0500, Yong Bakos wrote:
> On May 10, 2016, at 9:51 PM, Peter Hutterer  wrote:
> > 
> > The initial approach was to allow one surface to be re-used between tools,
> > seats and even used together as wl_pointer cursor surface. This has a few
> > drawbacks, most of which are related to managing the surface correctly in 
> > the
> > compositor. For example, the same cursor surface could have two different
> > hotspots. Animated cursors should animate independently rather than update 
> > at
> > the same time.
> > 
> > Furthermore: a client cannot know when a surface will cease being used as a
> > cursor surface. The basic assumption of "after focus out" is an 
> > implementation
> > detail in the compositor and unless the client unsets the cursor it is not
> > guaranteed that the surface is released. This again makes sharing a surface
> > less obvious - you cannot know if the wl_pointer surface is still in use 
> > when
> > you set it for a new wp_tablet_tool.
> > 
> > Avoid these headaches (and push some of them to the clientl) by simply
> > restricting a wl_surface to be assigned to a single tool. For the 99% use 
> > case
> > where we have one tablet with two tools (pen + eraser) this means we merely
> > get two extra surfaces, and the two don't usually share the same cursor 
> > shape
> > anyway. If sharing is absolutely, a client may still opt to share the
> > underlying wl_buffer.
> > 
> > Signed-off-by: Peter Hutterer 
> 
> Do you think that last sentence should be mentioned in the description?
> Noted inline below...
> 
> 
> > ---
> > unstable/tablet/tablet-unstable-v2.xml | 12 +---
> > 1 file changed, 5 insertions(+), 7 deletions(-)
> > 
> > diff --git a/unstable/tablet/tablet-unstable-v2.xml 
> > b/unstable/tablet/tablet-unstable-v2.xml
> > index e7b8626..d3f57ff 100644
> > --- a/unstable/tablet/tablet-unstable-v2.xml
> > +++ b/unstable/tablet/tablet-unstable-v2.xml
> > @@ -225,13 +225,11 @@
> > and pending input regions become undefined, and the wl_surface is
> > unmapped.
> > 
> > -   This request gives the surface the role of a cursor. The role
> > -   assigned by this request is the same as assigned by
> > -   wl_pointer.set_cursor meaning the same surface can be
> > -   used both as a wl_pointer cursor and a wp_tablet cursor. If the
> > -   surface already has another role, it raises a protocol error.
> > -   The surface may be used on multiple tablets and across multiple
> > -   seats.
> > +   This request gives the surface the role of a wp_tablet_tool cursor. A
> > +   surface may only ever be used as cursor surface for one
> > +   wp_tablet_tool. If the surface already has another role or has
> > +   previously been used as cursor surface for a different tool, a
> > +   protocol error is raised.
> 
> Is it worth mentioning here that "Clients may still opt to share the 
> underlying
> wl_buffer, if sharing is absolutely necessary." Or perhaps its worth /not/
> mentioning, in order to not encourage the practice?

I don't think it should be documented here, because that's a matter of how a
wl_surface relates to the wl_buffer. Whether the surface is used as cursor
or not should not determine that interaction, otherwise we'd have to specify
that too and that's just opening a can of worms.

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

[PATCH weston v2] data: Some client icons

[Bryce Harrington]

This adds an alternate weston terminal icon and icons for the flower and
editor clients.  The original Inkscape SVG file is included.

Example screenshot:
  http://www.bryceharrington.org/Files/weston-icons.png

Signed-off-by: Bryce Harrington 

---
v2: License under both CC-SA and MIT, requested by daniels

 Makefile.am|3 +
 data/COPYING   |   18 +
 data/icon_editor.png   |  Bin 0 -> 915 bytes
 data/icon_flower.png   |  Bin 0 -> 1408 bytes
 data/icon_terminal.png |  Bin 0 -> 653 bytes
 data/icons.svg | 1012 
 6 files changed, 1033 insertions(+)
 create mode 100644 data/icon_editor.png
 create mode 100644 data/icon_flower.png
 create mode 100644 data/icon_terminal.png
 create mode 100644 data/icons.svg

diff --git a/Makefile.am b/Makefile.am
index 0b7aa35..00b74e5 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -808,6 +808,9 @@ dist_westondata_DATA =  \
data/pattern.png\
data/terminal.png   \
data/border.png \
+   data/icon_editor.png\
+   data/icon_flower.png\
+   data/icon_terminal.png  \
data/icon_window.png\
data/sign_close.png \
data/sign_maximize.png  \
diff --git a/data/COPYING b/data/COPYING
index 3c10126..0345023 100644
--- a/data/COPYING
+++ b/data/COPYING
@@ -35,3 +35,21 @@ icon_ivi_flower.png
 icon_ivi_simple-egl.png
 icon_ivi_simple-shm.png
 icon_ivi_smoke.png
+
+
+For the SVG icons:
+
+© 2016 Samsung Electronics Co., Ltd
+
+This work is dual-licenced under both the MIT "Expat" License and the
+Creative Commons Attribution-Share Alike 3.0 United States License, and
+may be redistributed under either (or both) licenses as desired.  See
+Weston's COPYING for details of the MIT license.  To view a copy of the
+CC-SA-3.0 licence, visit http://creativecommons.org/licenses/by-sa/3.0/
+or send a letter to Creative Commons, 171 Second Street, Suite 300, San
+Francisco, California 94105, USA.
+
+icons.svg
+icon_terminal.png
+icon_editor.png
+icon_flower.png
diff --git a/data/icon_editor.png b/data/icon_editor.png
new file mode 100644
index 
..19aa494c5f9bf0ff92b4ad9f3e19f30c41fd6379
GIT binary patch
literal 915
zcmV;E18n?>P)0n+ITDgXcg8FWQhbW?9;ba!ELWdL_~cP?peYja~^
zaAhuUa%Y?FJQ@H10}x3>K~zYIwUy6n6KNR7KQozWrb%jy(P^ncQM*6p^-bY2Ce)W|25QM!1TH1>%DXs^>ix;iSF1WikX<9KgowUYwl1!5M

Re: [PATCH weston] data: Some client icons

[Bryce Harrington]

On Wed, May 04, 2016 at 10:08:12AM +0100, Daniel Stone wrote:
> Hi Bryce,
> 
> On 25 March 2016 at 00:57, Bryce Harrington  wrote:
> > This adds an alternate weston terminal icon and icons for the flower and
> > editor clients.  The original Inkscape SVG file is included.
> >
> > Example screenshot:
> >   http://www.bryceharrington.org/Files/weston-icons.png
> 
> Thanks for these! My only concern is that they're licensed under
> CC-SA, which is a fine license, but does significantly complicate the
> redistribution status of our tarball, from 'just MIT, do whatever and
> no-one cares' to 'mostly that, but be careful with the icons'.
>
> Is there any chance of having the icons relicensed under the same
> license as the rest of our tree?

Note in data/COPYING that the terminal icon and the DMZ cursors
(whatever they are), are already being included as CC-SA.

Regarding mixing of different licenses for code vs. data, this is a
common practice elsewhere - you'll frequently see games with FOSS source
code and proprietary graphics (I seem to recall this is even spelled out
in a GNU or CC faq somewhere), and the code-as-GPL tradition
appears pretty widespread in GNOME at least.

Anyway, but with that said, I'll update the patch to dual-license the
icons, to remove any concern you have before providing your R-b.  I'm
fine with having them under different licenses, and was merely following
the gnome icon precidents.

Bryce


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

Re: Introduction and updates from NVIDIA

[James Jones]

On 05/11/2016 04:55 PM, Mike Blumenkrantz wrote:



On Wed, May 11, 2016 at 7:08 PM James Jones > wrote:

On 05/11/2016 02:31 PM, Daniel Stone wrote:
 > Hi James,
 >
 > On 11 May 2016 at 21:43, James Jones > wrote:
 >> On 05/04/2016 08:56 AM, Daniel Stone wrote:
 >>> Right - but as with the point I was making below, GBM _right
now_ is
 >>> more capable than Streams _right now_. GBM right now would
require API
 >>> additions to match EGLStreams + EGLSwitch +
Streams/KMS-interop, but
 >>> the last two aren't written either, so. (More below.)
 >>
 >> The current behavior that enables this, where basically all
Wayland buffers
 >> must be allocated as scanout-capable, isn't reasonable on NVIDIA
hardware.
 >> The requirements for scanout are too onerous.
 >
 > I think we're talking past each other, so I'd like to pare the
 > discussion down to these two sentences, and my two resultant points,
 > for now:
 >
 > I posit that the Streams proposal you (plural) have put forward
is, at
 > best, no better at meeting these criteria:
 >- there is currently no support for direct scanout from client
 > buffers in Streams, so it must always pessimise towards GPU
 > composition
 >- GBM stacks can obviously do the same: implement a no-op
 > gbm_bo_import, and have your client always allocate non-scanout
 > buffers - presto, you've matched Streams
 >
 > I posit that GBM _can_ match the capability of a hypothetical
 > EGLStreams/EGLSwitch implementation. Current _implementations_ of GBM
 > cannot, but I posit that it is not a limitation of the API it
exposes,
 > and unlike Streams, the capability can be plumbed in with no new
 > external API required.
 >
 > These seem pretty fundamental, so ... am I missing something? :\ If
 > so, can you please outline fairly specifically how you think
 > non-Streams implementations are not capable of meeting the
criteria in
 > your two sentences?

I respect the need to rein in the discussion, but I think several
substantive aspects have been lost here.  I typed up a much longer
response below, but I'll try to summarize in 4 sentences:

GBM could match the allocation aspects of streams used in Miguel's first
round of patches.  However, I disagree that its core API is sufficient
to match the allocation capabilities of EGLStream+EGLSwitch where all
producing and consuming devices+engines are known at allocation time.
Further, streams have additional equally valuable functionality beyond
allocation that GBM does not seem intended to address.  Absent
agreement, I believe co-existence of EGLStreams and GBM+wl_drm in
Wayland/Weston is a reasonable path forward in the short term.

The longer version:

GBM alone can not perform as well as EGLStreams unless it is extended
into something more or less the same as EGLStreams, where it knows
exactly what engines are being used to produce the buffer content (along
with their current configuration), and exactly what
engines/configuration are being used to consume it.  This implies
allocating against multiple specific objects, rather than a device and a
set of allocation modifier flags, and/or importing an external
allocation and hoping it meets the current requirements.  From what I
can see, GBM fundamentally understands at most the consumer side of the
equation.

Suppose however, GBM was taught everything streams know implicitly about
all users of the buffers at allocation time.  After allocation, GBM is
done with its job, but streams & drivers aren't.

The act of transitioning a buffer from optimal "producer mode" to
optimal "consumer mode" relies on all the device & config information as
well, meaning it would need to be fed into the graphics driver (EGL or
whatever window system binding is used) by each window system the
graphics driver was running on to achieve equivalent capabilities to
EGLStream.

Fundamentally, the API-level view of individual graphics buffers as raw
globally coherent & accessible stores of pixels with static layout is
flawed.  Images on a GPU are more of a mutating spill space for a
collection of state describing the side effects of various commands than
a 2D array of pixels.  Forcing GPUs to resolve an image to a 2D array of
pixels in any particular layout can be very inefficient.  The
GL+GLX/EGL/etc. driver model hides this well, but it breaks down in a
few cases like EGLImage and GLX_EXT_texture_from_pixmap, the former not
really living up to its implied potential because of this, and the
latter mostly working only because it has a very limited domain where
things can be shared, but 

Re: Introduction and updates from NVIDIA

[Mike Blumenkrantz]

On Wed, May 11, 2016 at 7:08 PM James Jones  wrote:

> On 05/11/2016 02:31 PM, Daniel Stone wrote:
> > Hi James,
> >
> > On 11 May 2016 at 21:43, James Jones  wrote:
> >> On 05/04/2016 08:56 AM, Daniel Stone wrote:
> >>> Right - but as with the point I was making below, GBM _right now_ is
> >>> more capable than Streams _right now_. GBM right now would require API
> >>> additions to match EGLStreams + EGLSwitch + Streams/KMS-interop, but
> >>> the last two aren't written either, so. (More below.)
> >>
> >> The current behavior that enables this, where basically all Wayland
> buffers
> >> must be allocated as scanout-capable, isn't reasonable on NVIDIA
> hardware.
> >> The requirements for scanout are too onerous.
> >
> > I think we're talking past each other, so I'd like to pare the
> > discussion down to these two sentences, and my two resultant points,
> > for now:
> >
> > I posit that the Streams proposal you (plural) have put forward is, at
> > best, no better at meeting these criteria:
> >- there is currently no support for direct scanout from client
> > buffers in Streams, so it must always pessimise towards GPU
> > composition
> >- GBM stacks can obviously do the same: implement a no-op
> > gbm_bo_import, and have your client always allocate non-scanout
> > buffers - presto, you've matched Streams
> >
> > I posit that GBM _can_ match the capability of a hypothetical
> > EGLStreams/EGLSwitch implementation. Current _implementations_ of GBM
> > cannot, but I posit that it is not a limitation of the API it exposes,
> > and unlike Streams, the capability can be plumbed in with no new
> > external API required.
> >
> > These seem pretty fundamental, so ... am I missing something? :\ If
> > so, can you please outline fairly specifically how you think
> > non-Streams implementations are not capable of meeting the criteria in
> > your two sentences?
>
> I respect the need to rein in the discussion, but I think several
> substantive aspects have been lost here.  I typed up a much longer
> response below, but I'll try to summarize in 4 sentences:
>
> GBM could match the allocation aspects of streams used in Miguel's first
> round of patches.  However, I disagree that its core API is sufficient
> to match the allocation capabilities of EGLStream+EGLSwitch where all
> producing and consuming devices+engines are known at allocation time.
> Further, streams have additional equally valuable functionality beyond
> allocation that GBM does not seem intended to address.  Absent
> agreement, I believe co-existence of EGLStreams and GBM+wl_drm in
> Wayland/Weston is a reasonable path forward in the short term.
>
> The longer version:
>
> GBM alone can not perform as well as EGLStreams unless it is extended
> into something more or less the same as EGLStreams, where it knows
> exactly what engines are being used to produce the buffer content (along
> with their current configuration), and exactly what
> engines/configuration are being used to consume it.  This implies
> allocating against multiple specific objects, rather than a device and a
> set of allocation modifier flags, and/or importing an external
> allocation and hoping it meets the current requirements.  From what I
> can see, GBM fundamentally understands at most the consumer side of the
> equation.
>
> Suppose however, GBM was taught everything streams know implicitly about
> all users of the buffers at allocation time.  After allocation, GBM is
> done with its job, but streams & drivers aren't.
>
> The act of transitioning a buffer from optimal "producer mode" to
> optimal "consumer mode" relies on all the device & config information as
> well, meaning it would need to be fed into the graphics driver (EGL or
> whatever window system binding is used) by each window system the
> graphics driver was running on to achieve equivalent capabilities to
> EGLStream.
>
> Fundamentally, the API-level view of individual graphics buffers as raw
> globally coherent & accessible stores of pixels with static layout is
> flawed.  Images on a GPU are more of a mutating spill space for a
> collection of state describing the side effects of various commands than
> a 2D array of pixels.  Forcing GPUs to resolve an image to a 2D array of
> pixels in any particular layout can be very inefficient.  The
> GL+GLX/EGL/etc. driver model hides this well, but it breaks down in a
> few cases like EGLImage and GLX_EXT_texture_from_pixmap, the former not
> really living up to its implied potential because of this, and the
> latter mostly working only because it has a very limited domain where
> things can be shared, but still requires a lot of platform-specific code
> to support properly.  Vulkan brings a lot more of this out into the open
> with its very explicit image state transitions and limitations on which
> engines can access an image in any given state, but that's just within
> the Vulkan API itself (I.e., strictly on a single GPU 

Re: Introduction and updates from NVIDIA

[James Jones]

On 05/11/2016 02:31 PM, Daniel Stone wrote:

Hi James,

On 11 May 2016 at 21:43, James Jones  wrote:

On 05/04/2016 08:56 AM, Daniel Stone wrote:

Right - but as with the point I was making below, GBM _right now_ is
more capable than Streams _right now_. GBM right now would require API
additions to match EGLStreams + EGLSwitch + Streams/KMS-interop, but
the last two aren't written either, so. (More below.)


The current behavior that enables this, where basically all Wayland buffers
must be allocated as scanout-capable, isn't reasonable on NVIDIA hardware.
The requirements for scanout are too onerous.


I think we're talking past each other, so I'd like to pare the
discussion down to these two sentences, and my two resultant points,
for now:

I posit that the Streams proposal you (plural) have put forward is, at
best, no better at meeting these criteria:
   - there is currently no support for direct scanout from client
buffers in Streams, so it must always pessimise towards GPU
composition
   - GBM stacks can obviously do the same: implement a no-op
gbm_bo_import, and have your client always allocate non-scanout
buffers - presto, you've matched Streams

I posit that GBM _can_ match the capability of a hypothetical
EGLStreams/EGLSwitch implementation. Current _implementations_ of GBM
cannot, but I posit that it is not a limitation of the API it exposes,
and unlike Streams, the capability can be plumbed in with no new
external API required.

These seem pretty fundamental, so ... am I missing something? :\ If
so, can you please outline fairly specifically how you think
non-Streams implementations are not capable of meeting the criteria in
your two sentences?


I respect the need to rein in the discussion, but I think several 
substantive aspects have been lost here.  I typed up a much longer 
response below, but I'll try to summarize in 4 sentences:


GBM could match the allocation aspects of streams used in Miguel's first 
round of patches.  However, I disagree that its core API is sufficient 
to match the allocation capabilities of EGLStream+EGLSwitch where all 
producing and consuming devices+engines are known at allocation time. 
Further, streams have additional equally valuable functionality beyond 
allocation that GBM does not seem intended to address.  Absent 
agreement, I believe co-existence of EGLStreams and GBM+wl_drm in 
Wayland/Weston is a reasonable path forward in the short term.


The longer version:

GBM alone can not perform as well as EGLStreams unless it is extended 
into something more or less the same as EGLStreams, where it knows 
exactly what engines are being used to produce the buffer content (along 
with their current configuration), and exactly what 
engines/configuration are being used to consume it.  This implies 
allocating against multiple specific objects, rather than a device and a 
set of allocation modifier flags, and/or importing an external 
allocation and hoping it meets the current requirements.  From what I 
can see, GBM fundamentally understands at most the consumer side of the 
equation.


Suppose however, GBM was taught everything streams know implicitly about 
all users of the buffers at allocation time.  After allocation, GBM is 
done with its job, but streams & drivers aren't.


The act of transitioning a buffer from optimal "producer mode" to 
optimal "consumer mode" relies on all the device & config information as 
well, meaning it would need to be fed into the graphics driver (EGL or 
whatever window system binding is used) by each window system the 
graphics driver was running on to achieve equivalent capabilities to 
EGLStream.


Fundamentally, the API-level view of individual graphics buffers as raw 
globally coherent & accessible stores of pixels with static layout is 
flawed.  Images on a GPU are more of a mutating spill space for a 
collection of state describing the side effects of various commands than 
a 2D array of pixels.  Forcing GPUs to resolve an image to a 2D array of 
pixels in any particular layout can be very inefficient.  The 
GL+GLX/EGL/etc. driver model hides this well, but it breaks down in a 
few cases like EGLImage and GLX_EXT_texture_from_pixmap, the former not 
really living up to its implied potential because of this, and the 
latter mostly working only because it has a very limited domain where 
things can be shared, but still requires a lot of platform-specific code 
to support properly.  Vulkan brings a lot more of this out into the open 
with its very explicit image state transitions and limitations on which 
engines can access an image in any given state, but that's just within 
the Vulkan API itself (I.e., strictly on a single GPU and optionally an 
associated display engine within the same driver & process) so far.


The EGLStream encapsulation takes into consideration the new use cases 
EGLImage, GBM, etc. were intended to address, and restores what I 
believe to be the minimal amount of the traditional 

Re: Protocol for window previews/thumbnails

[ade low]

Thanks for your feedback too.

On Wed, May 11, 2016 at 2:51 PM, Derek Foreman 
wrote:
>
>
> But I'm of the opinion that this doesn't need to be a "wayland" problem
> at all - but I'm not saying there can't be a standard way to do this.
>
> It just doesn't need to be solved by adding wayland protocol.  A common
> module framework for compositors that find this functionality useful
> would probably perform better and have less complexity.
>

Do you mean something like a shared library that compositors can link
against? Does this mean that compositors would not have to have their own
implementation of this functionality as it would be provided by this
library, or have I understood this incorrectly?

Regards

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

Re: Protocol for window previews/thumbnails

[ade low]

Thank you for the feedback, that was very helpful.

On Wed, May 11, 2016 at 9:07 AM, Pekka Paalanen  wrote:
>
>
> You should explain the use case behind the idea. Then it would be
> possible to assess whether such protocol would even be appropriate for
> it.
>

My use case is third-party window switcher applications, such as
xfdashboard or my program, xfce4-lightdash-plugin:
https://github.com/adlocode/xfce4-lightdash-plugin

If some sort of protocol would be needed, then you have to figure out
> how to not make it a gaping security breach
>

Perhaps the security could be improved by having a permissions system where
only authorised programs are allowed to use this protocol? Maybe the
compositor could expose a settings framework that allows the user to
control the permissions of applications.

A little more tractable plan would be to communicate only surface
> meta-data to the client, which could then ask the compositor to draw
> the thumbnails relative to one of the client's surfaces. The client
> would never have access to window content itself.


That's a good point; this could be a good solution, as long as it is
toolkit-independent and supports all rendering methods: OpenGL, pixman 2D
software rendering, etc.

 However, then there's

the question of whether it can be a standard protocol or not.


It is important that it is a standard, cross-compositor protocol. For
example, if I am using my app on "xfwm-wayland" and then I decide that I
want to switch to KWin, my app should continue to work.

Regards

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

Re: [ANNOUNCE] wayland 1.10.91

[Yong Bakos]

On May 11, 2016, at 2:32 PM, Yong Bakos  wrote:
> 
> On May 11, 2016, at 2:11 PM, Bryce Harrington  wrote:
>> 
>> On Fri, May 06, 2016 at 02:17:23PM +0300, Pekka Paalanen wrote:
>>> On Wed, 4 May 2016 11:46:23 -0700
>>> Bryce Harrington  wrote:
>>> 
 On Wed, May 04, 2016 at 12:55:16AM -0700, Bryce Harrington wrote:
> Here's the alpha for the upcoming 1.11 release.  I'll summarize the
> major features for this release in the beta announcement, but see below
> for the detailed listing.
> 
> The schedule going forward is:
> 
> √ 1.11-alpha on May 3rd.  Major features done by this point.
>> 
>> It looks like someone (pq?) has marked some patches we decided to leave
>> for post-1.11 as deferred in patchwork.  I've followed suit and moved
>> other patchsets there which are new APIs or that sound like feature
>> work.
>> 
>> Following are what remains.  Most of these I think should be deferred
>> but am not 100% certain, so would appreciate hearing other people's
>> thoughts:
> 
> Hi Bryce,
> I have on my list to review #5 below (text input protocol), and I should
> have that done today (May 11). Or I can submit patches after it's merged.
> 
> yong

Actually, I did review #5 (v2 for text input protocol), but at the time
I had to manually re-construct the reply as I was receiving mailing list
digests at the time... so Patchwork didn't associate my response.

https://lists.freedesktop.org/archives/wayland-devel/2016-April/027922.html

The things I pointed out weren't fixed, but they were all writing corrections,
which I can submit after a merge.

yong


> 
>> 
>> 1. Detect keyboard capabilities, refactor seat capability [Derek]
>>  - Awaiting review by jadahl
>>  - Over a year old now, probably needs rebased too...
>> 
>> 2. xdg_popup behavior of input devices [Carlos]
>>  - Protocol additions for xdg-shell, needs review by xdg devels
>>  - Been in the queue a long time, but no reviews to date
>>  - No idea about disposition for this
>> 
>> 3. xwayland drag-and-drop window creation [Carlos]
>>  - Looks ok to be but xwayland isn't my area
>>  - Been in the queue a long time, but no reviews to date
>>  - From the commit description sounds WIP-ish and that there was
>>planned some followup work, but not sure if that happened?
>> 
>> 4. Pointer locking (3 patches) [Jonas]
>>  - Was planned to land this feature for 1.11
>>  - Reviewers requested changes, but I'm not spotting a v2 for this
>>  - At a minimum needs updated for trunk, since the protocol files are
>>now in wayland-protocols
>>  - I'll mark it 'Changes Requested' and hope it will return for
>>consideration for 1.12.
>> 
>> 5. V2 for text input protocol [Jan Arne]
>>  - This is intended for wayland-protocols so not really pertinent to
>>the release.  But is on v6 and hasn't received further reviews,
>>perhaps it's time to land it?
>> 
>> 6. FreeRDP fixes (6 patches) [David]
>>  - Build fixes are suitable for landing now, so I consider at least
>>the first 3 patches here good candidates for including in 1.11
>>  - No R-b's other than my own; I'd be more comfortable landing if we
>>had another set of R-b's on this.
>> 
>> 7. compositor-drm clone mode + fixes (8 patches) [Emmanuel]
>>  - The fixes look straightforward and probably ok to land
>>  - I haven't reviewed the clone mode feature, but offhand judging by
>>the length of the patch it looks like post-1.11 stuff.
>> 
>> 8. get_subsurface double-buffered protocol [pq]
>>  - Is getting strong reviews, but also requests for tests 
>>  - There is debate on its thread as to whether to land vs. leave for
>>1.12
>> 
>> 9. Don't set_fullscreen on already fullscreen surfaces [Emmanuel]
>>  - Short fix, might be worth including in 1.11
>>  - Needs another R-b or two, but may be an easy thing to land
>> 
>> 10. compositor fixes (2 patches) [pq]
>> 11. eventdemo fixes (3 patches) [pq]
>>  - These sound landable for 1.11 offhand, but I haven't reviewed.
>>  - Needs R-b's
>> 
>> 12. ivi_layout_surface API
>>  - Straightforward patch, looks fine to me
>>  - Not sure about landing new API during feature freeze though
>>  - Needs R-b's
>> 
> - 1.11-beta around May 17th.
> 
> - 1.11-rc1 around May 24th.
> 
> - 1.11.0 release around May 31st.
> 
> At this time consider Wayland in feature freeze mode.  We'll continue to
> land minor enhancements through beta, and focus on bug fixes thereafter.  
 
 Do we need to up the version requirements for weston's libwayland client
 or server dependency, or the version of wayland-protocol?
>>> 
>>> Hi Bryce,
>>> 
>>> Wayland-protocol deps should all be dealt with as they happen. I
>>> believe we have the policy to land changes in wayland-protocols first
>>> and have a w-p release, and then land weston patches depending on them,
>>> bumping the dependency on configure.ac at the same time. That's what
>>> I've 

Re: Introduction and updates from NVIDIA

[Daniel Stone]

Hi James,

On 11 May 2016 at 21:43, James Jones  wrote:
> On 05/04/2016 08:56 AM, Daniel Stone wrote:
>> Right - but as with the point I was making below, GBM _right now_ is
>> more capable than Streams _right now_. GBM right now would require API
>> additions to match EGLStreams + EGLSwitch + Streams/KMS-interop, but
>> the last two aren't written either, so. (More below.)
>
> The current behavior that enables this, where basically all Wayland buffers
> must be allocated as scanout-capable, isn't reasonable on NVIDIA hardware.
> The requirements for scanout are too onerous.

I think we're talking past each other, so I'd like to pare the
discussion down to these two sentences, and my two resultant points,
for now:

I posit that the Streams proposal you (plural) have put forward is, at
best, no better at meeting these criteria:
  - there is currently no support for direct scanout from client
buffers in Streams, so it must always pessimise towards GPU
composition
  - GBM stacks can obviously do the same: implement a no-op
gbm_bo_import, and have your client always allocate non-scanout
buffers - presto, you've matched Streams

I posit that GBM _can_ match the capability of a hypothetical
EGLStreams/EGLSwitch implementation. Current _implementations_ of GBM
cannot, but I posit that it is not a limitation of the API it exposes,
and unlike Streams, the capability can be plumbed in with no new
external API required.

These seem pretty fundamental, so ... am I missing something? :\ If
so, can you please outline fairly specifically how you think
non-Streams implementations are not capable of meeting the criteria in
your two sentences?

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

Re: Introduction and updates from NVIDIA

[James Jones]

On 05/04/2016 08:56 AM, Daniel Stone wrote:

Hi,
Interleaving both replies ...

On 3 May 2016 at 19:44, James Jones  wrote:

On 05/03/2016 09:53 AM, Daniel Stone wrote:

On 3 May 2016 at 17:07, James Jones  wrote:

No, the necessary extensions can not be contained within the binding.
There
is not enough information within the driver layer alone. Something needs
to
tell the driver when the configuration changes (E.g., the consumer of a
wayland surface switches from a texture to a plane) and what the new
configuration is. This would trigger the protocol notifications &
subsequent optimization within the driver.  By the nature of their API,
streams would require the compositor to take action on such configuration
changes, and streams can discover the new configuration.  Something
equivalent would be required to make this work in the GBM+wl_drm/EGL
case.


I don't think this is the case. As I went through with Andy, we
_already_ have intent expressed in the GBM case, in the exact same way
that EGLStreams does: consider gbm_bo_import as equivalent for
attaching to an EGLOutput(Layer) consumer, and EGLImage import +
TargetTexture2D as equivalent for attaching a gltexture consumer.



"Will be used for display on device X" is not sufficient information, as
Daniel Vetter outlined.


Indeed, but nothing we have - including both the initial Streams
patchset, and the subsequent proposals for adding muxing as well as
KMS config passthrough - is sufficient for that.

The Streams Check/Commit proposal you outlined a couple of mails ago
isn't sufficient because you often need to know global configuration
to determine if a configuration is even usable, let alone optimal:
shared decompression/detiling units, global bandwidth/watermark
limits, etc. Having just one entrypoint to Streams where it gets very
limited information about each plane that Streams is using isn't
enough, because it needs to know the global configuration.

So to actually make this work on other hardware, you'd need to pass
the full request (including content which came via other sources, e.g.
dmabuf) through to Streams. And by the time you're handing your entire
scene graph off to an external component to determine the optimal
configuration ... well, that's basically HWC.


I'm sorry for mixing them up again by alluding to Daniel Vetter's 
statement, but there are two separate things being discussed here:


-A fully optimal scene-graph.  This is important, but not solved by 
streams alone.  Streams could work as one of several building blocks in 
a solution for this.


-Optimal presentation and allocation of buffers between two endpoints 
(I.e., optimizing frame allocation and delivery for what Weston can do 
right now).  My claim was that current streams solve this, while current 
GBM does not provide enough information for even this optimization.


Solving the global scene graph optimization problem is important, but 
will require additional work.  The incremental gains from using streams 
(worth around 10% raw throughput on Kepler-based NVIDIA GPUs for 
example, supposedly more on later hardware though I've not yet 
benchmarked directly there) should not be ignored just because they 
don't achieve perfection in a single step.  Incremental improvements are 
still valuable.



I'm also not sure what the plan is for integrating with Vulkan
compositors: does that end up as an interop extension? Does VK WSI
gain an equivalent which allows you to mux swapchain/device_swapchain?
(Similar questions for the Check/Commit API really.)


Yes, if an EGL-based client was presenting to a Vulkan-based compositor, 
interop would be happening somewhere.  Either yet-to-be-developed Vulkan 
primitives could be used to implement the wayland-egl library with 
interop on the client side, or EGLStreams could be used to implement the 
wayland-egl library with interop on the server side.  Or there could be 
EGL->(wl_drm)->Vulkan, which is essentially 2 interop steps, but that 
has the same shortcomings we've been discussing for the current 
EGL->(wl_drm)->EGL/GBM+DRM situation.



This
is the exact same proxy for intent to display, and in fact the GBM
approach is slightly more flexible, because it allows you to both do
direct scanout as well as GPU composition (e.g. if you're
capturing/streaming at the same time as display).

Again though, without stream-retargeting, this is not something which
exists in Streams today, and doing so is going to require more
extensions: more code in your driver, more code in every
implementation. GBM today, for all its faults, does not require
further API extension to make this work.


Agreed.  We're working on similar flexibility for streams via an EGLSwitch
muxing extension.  As mentioned above, GBM would require API extensions and
driver updates to reach the expressiveness of streams as well though.


Right - but as with the point I was making below, GBM _right now_ is
more capable than Streams 

[PATCH weston] build: Define wayland prereq version

[Bryce Harrington]

Establishes a single variable for defining the libwayland version
requirements.  Enforces the same version dependency between
libwayland-client and libwayland-server, as recommended by pq in the
1.11 release discussions.

Signed-off-by: Bryce Harrington 
---
 configure.ac | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index 2ca1f4e..0b23fc4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -4,6 +4,8 @@ m4_define([weston_micro_version], [91])
 m4_define([weston_version],
   [weston_major_version.weston_minor_version.weston_micro_version])
 
+m4_define([WAYLAND_PREREQ_VERSION], "1.10.0")
+
 AC_PREREQ([2.64])
 AC_INIT([weston],
 [weston_version],
@@ -60,7 +62,7 @@ AC_CHECK_HEADERS([execinfo.h])
 
 AC_CHECK_FUNCS([mkostemp strchrnul initgroups posix_fallocate])
 
-COMPOSITOR_MODULES="wayland-server >= 1.10.0 pixman-1 >= 0.25.2"
+COMPOSITOR_MODULES="wayland-server >= WAYLAND_PREREQ_VERSION pixman-1 >= 
0.25.2"
 
 AC_CONFIG_FILES([doc/doxygen/tools.doxygen doc/doxygen/tooldev.doxygen])
 
@@ -193,7 +195,7 @@ AM_CONDITIONAL(ENABLE_WAYLAND_COMPOSITOR,
 if test x$enable_wayland_compositor = xyes -a x$enable_egl = xyes; then
   AC_DEFINE([BUILD_WAYLAND_COMPOSITOR], [1],
[Build the Wayland (nested) compositor])
-  PKG_CHECK_MODULES(WAYLAND_COMPOSITOR, [wayland-client >= 1.5.91 wayland-egl 
wayland-cursor])
+  PKG_CHECK_MODULES(WAYLAND_COMPOSITOR, [wayland-client >= 
WAYLAND_PREREQ_VERSION wayland-egl wayland-cursor])
 fi
 
 
@@ -332,7 +334,7 @@ AM_CONDITIONAL(ENABLE_VAAPI_RECORDER, test "x$have_libva" = 
xyes)
 
 PKG_CHECK_MODULES(CAIRO, [cairo])
 
-PKG_CHECK_MODULES(TEST_CLIENT, [wayland-client >= 1.10.0])
+PKG_CHECK_MODULES(TEST_CLIENT, [wayland-client >= WAYLAND_PREREQ_VERSION])
 
 AC_ARG_ENABLE(simple-clients,
   AS_HELP_STRING([--disable-simple-clients],
@@ -386,9 +388,9 @@ AM_CONDITIONAL(BUILD_CLIENTS, test x$enable_clients = xyes)
 if test x$enable_clients = xyes; then
   AC_DEFINE([BUILD_CLIENTS], [1], [Build the Wayland clients])
 
-  PKG_CHECK_MODULES(CLIENT, [wayland-client >= 1.5.91 cairo >= 1.10.0 
xkbcommon wayland-cursor])
+  PKG_CHECK_MODULES(CLIENT, [wayland-client >= WAYLAND_PREREQ_VERSION cairo >= 
1.10.0 xkbcommon wayland-cursor])
   PKG_CHECK_MODULES(SERVER, [wayland-server])
-  PKG_CHECK_MODULES(WESTON_INFO, [wayland-client >= 1.5.91])
+  PKG_CHECK_MODULES(WESTON_INFO, [wayland-client >= WAYLAND_PREREQ_VERSION])
 
   # Only check for cairo-egl if a GL or GLES renderer requested
   AS_IF([test "x$cairo_modules" = "xcairo-gl" -o "x$cairo_modules" = 
"xcairo-glesv2"], [
-- 
1.9.1

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

[PATCH] Build a libweston library

[Giulio Camuffo]

This patch creates a libweston-N.so library, where N is the 
"libweston_abi_version"
defined in configure.ac. Almost all the code that was previously built in the
weston binary is now in libweston.sp, except main.c and log.c.
Possibly other files will need to be moved to weston but it can be done when we
identify which files are they.
When the API/ABI of libweston changes in an incompatible way, the abi version
will be bumped so that multiple versions can live together.
Also a libweston-N.pc file is created and installed together with weston.pc.

Signed-off-by: Giulio Camuffo 
---
 Makefile.am | 39 ---
 configure.ac|  3 +++
 src/input.c |  4 ++--
 src/libweston.pc.in | 11 +++
 4 files changed, 40 insertions(+), 17 deletions(-)
 create mode 100644 src/libweston.pc.in

diff --git a/Makefile.am b/Makefile.am
index 0b7aa35..fbc509d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3,7 +3,7 @@ ACLOCAL_AMFLAGS = -I m4
 bin_PROGRAMS =
 noinst_PROGRAMS =
 libexec_PROGRAMS =
-moduledir = $(libdir)/weston
+moduledir = $(libdir)/weston-${LIBWESTON_ABI_VERSION}
 module_LTLIBRARIES =
 noinst_LTLIBRARIES =
 BUILT_SOURCES =
@@ -59,17 +59,15 @@ CLEANFILES = weston.ini \
internal-screenshot-00.png  \
$(BUILT_SOURCES)
 
-bin_PROGRAMS += weston
+lib_LTLIBRARIES = libweston.la
+libweston_la_CPPFLAGS = $(AM_CPPFLAGS) -DIN_WESTON
+libweston_la_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS) $(LIBUNWIND_CFLAGS)
+libweston_la_LIBADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \
+$(DLOPEN_LIBS) -lm libshared.la
+libweston_la_LDFLAGS = -release ${LIBWESTON_ABI_VERSION}
 
-weston_LDFLAGS = -export-dynamic
-weston_CPPFLAGS = $(AM_CPPFLAGS) -DIN_WESTON
-weston_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS) $(LIBUNWIND_CFLAGS)
-weston_LDADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \
-   $(DLOPEN_LIBS) -lm $(CLOCK_GETTIME_LIBS) libshared.la
-
-weston_SOURCES =   \
+libweston_la_SOURCES = \
src/git-version.h   \
-   src/log.c   \
src/compositor.c\
src/compositor.h\
src/compositor-drm.h\
@@ -92,7 +90,6 @@ weston_SOURCES =  \
src/timeline.c  \
src/timeline.h  \
src/timeline-object.h   \
-   src/main.c  \
src/linux-dmabuf.c  \
src/linux-dmabuf.h  \
shared/helpers.h\
@@ -119,7 +116,7 @@ systemd_notify_la_SOURCES = \
src/compositor.h
 endif
 
-nodist_weston_SOURCES =\
+nodist_libweston_la_SOURCES =  \
protocol/weston-screenshooter-protocol.c\
protocol/weston-screenshooter-server-protocol.h \
protocol/text-cursor-position-protocol.c\
@@ -135,7 +132,19 @@ nodist_weston_SOURCES =
\
protocol/linux-dmabuf-unstable-v1-protocol.c\
protocol/linux-dmabuf-unstable-v1-server-protocol.h
 
-BUILT_SOURCES += $(nodist_weston_SOURCES)
+BUILT_SOURCES += $(nodist_libweston_la_SOURCES)
+
+bin_PROGRAMS += weston
+
+weston_LDFLAGS = -export-dynamic
+weston_CPPFLAGS = $(AM_CPPFLAGS) -DIN_WESTON
+weston_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS) $(LIBUNWIND_CFLAGS)
+weston_LDADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \
+   $(DLOPEN_LIBS) -lm libshared.la libweston.la
+
+weston_SOURCES =   \
+   src/main.c  \
+   src/log.c
 
 # Track this dependency explicitly instead of using BUILT_SOURCES.  We
 # add BUILT_SOURCES to CLEANFILES, but we want to keep git-version.h
@@ -205,12 +214,12 @@ endif
 endif # BUILD_WESTON_LAUNCH
 
 pkgconfigdir = $(libdir)/pkgconfig
-pkgconfig_DATA = src/weston.pc
+pkgconfig_DATA = src/weston.pc src/libweston-${LIBWESTON_ABI_VERSION}.pc
 
 wayland_sessiondir = $(datadir)/wayland-sessions
 dist_wayland_session_DATA = src/weston.desktop
 
-westonincludedir = $(includedir)/weston
+westonincludedir = $(includedir)/weston-${LIBWESTON_ABI_VERSION}
 westoninclude_HEADERS =\
src/version.h   \
src/compositor.h\
diff --git a/configure.ac b/configure.ac
index 2ca1f4e..94aad57 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3,6 +3,7 @@ m4_define([weston_minor_version], [10])
 m4_define([weston_micro_version], [91])
 m4_define([weston_version],
   

Re: [PATCH weston 0/5] gl-renderer: Renaming of things and minor improvements

[Bryce Harrington]

On Wed, May 11, 2016 at 02:48:13PM +0200, Miguel A. Vico wrote:
> Hi,
> 
> Feedback for the first revision has been addressed. Here is a new series that
> basically splits the orginal patch into several little pieces.
> 
> Additionally, gl_renderer_create() has been renamed to
> gl_renderer_display_create() as per Daniel Stone's request.
> 
> Thanks,
> Miguel.

Hi Miguel, thanks for the patches!  We've just entered feature freeze
for the 1.11 release, and are deferring most non-bugfix work to the next
cycle.  I haven't had a chance to review your patches in detail but as
they are sounding like refactoring and feature work I'm opting to defer
them to post-1.11.

If you feel any of these patches need to be included in 1.11, please let
me know (and why) and I'll take a closer look.

Bryce

> Summary:
>   gl-renderer: Accept non-NULL empty  arrays
>   gl-renderer: Add  param to gl_renderer_display_create
>   gl-renderer: Rename  param of gl_renderer to 
>   gl-renderer: Rename gl_renderer::output_create to output_window_create
>   gl-renderer: Rename gl_renderer_create to gl_renderer_display_create
> 
>   src/compositor-drm.c |  5 +++--
>   src/compositor-fbdev.c   |  5 +++--
>   src/compositor-wayland.c |  5 +++--
>   src/compositor-x11.c |  7 ---
>   src/gl-renderer.c| 22 +++---
>   src/gl-renderer.h|  9 +
>   6 files changed, 29 insertions(+), 24 deletions(-)
> 
> 
> NVIDIA GmbH, Wuerselen, Germany, Amtsgericht Aachen, HRB 8361
> Managing Director: Karen Theresa Burns
> 
> ---
> This email message is for the sole use of the intended recipient(s) and may 
> contain
> confidential information.  Any unauthorized review, use, disclosure or 
> distribution
> is prohibited.  If you are not the intended recipient, please contact the 
> sender by
> reply email and destroy all copies of the original message.
> ---
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 0/5] gl-renderer: Renaming of things and minor improvements

[Miguel Angel Vico]

Hi Bryce,

It's fine to defer these patches to next release.

Thanks for the heads-up.

Miguel.

On Wed, 11 May 2016 11:23:17 -0700
Bryce Harrington  wrote:

> On Wed, May 11, 2016 at 02:48:13PM +0200, Miguel A. Vico wrote:
> > Hi,
> > 
> > Feedback for the first revision has been addressed. Here is a new
> > series that basically splits the orginal patch into several little
> > pieces.
> > 
> > Additionally, gl_renderer_create() has been renamed to
> > gl_renderer_display_create() as per Daniel Stone's request.
> > 
> > Thanks,
> > Miguel.  
> 
> Hi Miguel, thanks for the patches!  We've just entered feature freeze
> for the 1.11 release, and are deferring most non-bugfix work to the
> next cycle.  I haven't had a chance to review your patches in detail
> but as they are sounding like refactoring and feature work I'm opting
> to defer them to post-1.11.
> 
> If you feel any of these patches need to be included in 1.11, please
> let me know (and why) and I'll take a closer look.
> 
> Bryce
> 
> > Summary:
> >   gl-renderer: Accept non-NULL empty  arrays
> >   gl-renderer: Add  param to
> > gl_renderer_display_create gl-renderer: Rename  param of
> > gl_renderer to  gl-renderer: Rename
> > gl_renderer::output_create to output_window_create gl-renderer:
> > Rename gl_renderer_create to gl_renderer_display_create
> > 
> >   src/compositor-drm.c |  5 +++--
> >   src/compositor-fbdev.c   |  5 +++--
> >   src/compositor-wayland.c |  5 +++--
> >   src/compositor-x11.c |  7 ---
> >   src/gl-renderer.c| 22 +++---
> >   src/gl-renderer.h|  9 +
> >   6 files changed, 29 insertions(+), 24 deletions(-)
> > 
> > 
> > NVIDIA GmbH, Wuerselen, Germany, Amtsgericht Aachen, HRB 8361
> > Managing Director: Karen Theresa Burns
> > 
> > ---
> > This email message is for the sole use of the intended recipient(s)
> > and may contain confidential information.  Any unauthorized review,
> > use, disclosure or distribution is prohibited.  If you are not the
> > intended recipient, please contact the sender by reply email and
> > destroy all copies of the original message.
> > ---
> > ___ wayland-devel
> > mailing list wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel  


-- 
Miguel


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

Re: [PATCH v3 wayland-protocols 4/4] tablet: Add pad support to the tablet protocol

[Jason Gerecke]

On Tue, May 10, 2016 at 7:51 PM, Peter Hutterer
 wrote:
> From: Carlos Garnacho 
>
> The pad's interface is similar to the tool interface, a client is notified of
> the pad after the tablet_added event.
>
> The pad has three functionalities: buttons, rings and strips.
> Buttons are fairly straightforward, rings and strips are separate interfaces
> with a pointer-axis-like source/value/frame events.
> The two interfaces are effectively identical but for the actual value they
> send (degrees vs normalized position).
>
> Buttons are sequentially indexed starting with zero, unlike other protocols
> where a linux/input.h-style semantic event code is used. Since we expect all
> buttons to have client-specific functionality, an additional event tells the
> client when a given button index is not available, usually because the
> compositor assignes some function to it (e.g. mode switching, see below).
>
> Specific to the pad device is the set_feedback request which enables a client
> to set a user-defined string to display for an OSD on the current mappings.
> This request is available for buttons, rings and strips.
>
> Finally, the pad supports "modes", effectively sets of button/ring/strip
> configurations.
>
> Signed-off-by: Carlos Garnacho 
> Signed-off-by: Peter Hutterer 
> ---
> Changes to v2:
> - change to v2 of the protocol
> - various comments and suggestions for improved wording incorporated
> - ring is in wl_fixed degrees now (was int, in 0.01 of a degree)
> - button events changed to sequential indices
> - new buttons_reserved event
>
>  unstable/tablet/tablet-unstable-v2.xml | 436 
> +
>  1 file changed, 436 insertions(+)
>
> diff --git a/unstable/tablet/tablet-unstable-v2.xml 
> b/unstable/tablet/tablet-unstable-v2.xml
> index d3f57ff..388b4d2 100644
> --- a/unstable/tablet/tablet-unstable-v2.xml
> +++ b/unstable/tablet/tablet-unstable-v2.xml
> @@ -172,6 +172,22 @@
>
> summary="the newly added tablet tool"/>
>  
> +
> +
> +  
> +   This event is sent whenever a new pad is known to the system. 
> Typically,
> +   pads are physically attached to tablets and a pad_added event is
> +   sent immediately after the wp_tablet_seat.tablet_added.
> +   However, some standalone pad devices logically attach to tablets at
> +   runtime, and the client must wait for wp_tablet_pad.enter to know
> +   the tablet a pad is attached to.
> +
> +   This event only provides the object id of the pad; and all further
> +   features (buttons, strips, rings) are sent through the wp_tablet_pad
> +   interface.
> +  
> +   summary="the newly added pad"/>
> +
>
>
>
> @@ -636,4 +652,424 @@
>  
>
>
> +  
> +
> +  A circular interaction area.
> +
> +  Events on a ring are logically grouped by the wl_tablet_pad_ring.frame
> +  event.
> +
> +
> +
> +  
> +   Request that the compositor use the provided feedback string
> +   associated with this ring. This request should be issued immediately
> +   after a wp_tablet_pad.enter, or whenever the ring is mapped to a
> +   different action.
> +
> +   Clients are encouraged to provide context-aware descriptions for
> +   the actions associated with the ring; compositors may use this
> +   information to offer visual feedback about the button layout
> +   (eg. on-screen displays).
> +
> +   The provided string 'description' is an UTF-8 encoded string to be
> +   associated with this ring, and is considered user visible; general
> +   internationalization rules apply.
> +  
> +  
> +
> +
> +
> +  
> +   This destroys the client's resource for this ring object.
> +  
> +
> +
> +
> +  
> +   Describes the source types for ring events. This indicates to the
> +   client how a ring event was physically generated; a client may
> +   adjust the user interface accordingly. For example, events
> +   from a "finger" source may trigger kinetic scrolling.
> +  
> +  
> +
> +
> +
> +  
> +   Source information for ring events.
> +
> +   This event does not occur on its own. It is sent before a
> +   wp_tablet_pad_ring.frame event and carries the source information
> +   for all events within that frame.
> +
> +   The source specifies how this event was generated. If the source is
> +   wp_tablet_pad_ring.source.finger, a wp_tablet_pad_ring.stop event
> +   will be sent when the user lifts the finger off the device.
> +
> +   This event is optional. If the source is unknown for an interaction,
> +   no event is sent.
> +  
> +  
> +
> +
> +
> +  
> +   Sent whenever the angle on a ring changes.
> +
> +   The angle is provided in degrees clockwise from the logical
> +   north of the 

Re: [PATCH wayland] private: Remove unnecessary forward declarations

[Bryce Harrington]

On Mon, May 09, 2016 at 01:24:29PM -0500, Derek Foreman wrote:
> On 07/05/16 09:11 AM, Yong Bakos wrote:
> > From: Yong Bakos 
> > 
> > Declarations for wl_connection and wl_closure are not needed here.
> > wl_closure already has a complete definition.
> > Removing these forward declarations results in a clean, warning-free 
> > compile.
> > 
> > Signed-off-by: Yong Bakos 
> > ---
> >  src/wayland-private.h | 4 
> >  1 file changed, 4 deletions(-)
> > 
> > diff --git a/src/wayland-private.h b/src/wayland-private.h
> > index 994bc45..0d8b630 100644
> > --- a/src/wayland-private.h
> > +++ b/src/wayland-private.h
> > @@ -99,10 +99,6 @@ wl_map_lookup_flags(struct wl_map *map, uint32_t i);
> >  void
> >  wl_map_for_each(struct wl_map *map, wl_iterator_func_t func, void *data);
> >  
> > -struct wl_connection;
> > -struct wl_closure;
> > -struct wl_proxy;
> 
> Trying to think of a place in C where a forward struct declaration is
> actually required.
> 
> This file isn't it. ;)
> 
> Reviewed-by: Derek Foreman 

Reviewed-by: Bryce Harrington 

I've rebased it to trunk and pushed:
   385906b..f86fbe1  master -> master


> > -
> >  int
> >  wl_interface_equal(const struct wl_interface *iface1,
> >const struct wl_interface *iface2);
> > 
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland 1/1] connection: Move wl_interface_equal to util

[Bryce Harrington]

On Tue, May 10, 2016 at 06:08:15PM -0700, Bryce Harrington wrote:
> On Mon, May 09, 2016 at 03:41:14PM +0300, Pekka Paalanen wrote:
> > On Sun,  8 May 2016 08:44:08 -0500
> > Yong Bakos  wrote:
> > 
> > > From: Yong Bakos 
> > > 
> > > Move the wl_interface_equal prototype to the top of wayland-private, where
> > > it is not buried in the middle of map, connection and closure functions.
> > > 
> > > Move the implementation out of connection and into util. This is a utility
> > > function, not specific to connections, and has call sites within 
> > > connection,
> > > wayland-client and wayland-server.
> > > 
> > > Signed-off-by: Yong Bakos 
> > > ---
> > >  src/connection.c  | 13 -
> > >  src/wayland-private.h |  8 
> > >  src/wayland-util.c| 13 +
> > >  3 files changed, 17 insertions(+), 17 deletions(-)
> > > 
> > > diff --git a/src/connection.c b/src/connection.c
> > > index 747229e..c3293a9 100644
> > > --- a/src/connection.c
> > > +++ b/src/connection.c
> > > @@ -798,19 +798,6 @@ wl_connection_demarshal(struct wl_connection 
> > > *connection,
> > >  }
> > >  
> > >  int
> > > -wl_interface_equal(const struct wl_interface *a, const struct 
> > > wl_interface *b)
> > > -{
> > > - /* In most cases the pointer equality test is sufficient.
> > > -  * However, in some cases, depending on how things are split
> > > -  * across shared objects, we can end up with multiple
> > > -  * instances of the interface metadata constants.  So if the
> > > -  * pointers match, the interfaces are equal, if they don't
> > > -  * match we have to compare the interface names. */
> > > -
> > > - return a == b || strcmp(a->name, b->name) == 0;
> > > -}
> > > -
> > > -int
> > >  wl_closure_lookup_objects(struct wl_closure *closure, struct wl_map 
> > > *objects)
> > >  {
> > >   struct wl_object *object;
> > > diff --git a/src/wayland-private.h b/src/wayland-private.h
> > > index 994bc45..a9a07a8 100644
> > > --- a/src/wayland-private.h
> > > +++ b/src/wayland-private.h
> > > @@ -55,6 +55,10 @@ struct wl_object {
> > >  extern struct wl_object global_zombie_object;
> > >  #define WL_ZOMBIE_OBJECT ((void*)_zombie_object)
> > >  
> > > +int
> > > +wl_interface_equal(const struct wl_interface *iface1,
> > > +const struct wl_interface *iface2);
> > > +
> > >  /* Flags for wl_map_insert_new and wl_map_insert_at.  Flags can be 
> > > queried with
> > >   * wl_map_lookup_flags.  The current implementation has room for 1 bit 
> > > worth of
> > >   * flags.  If more flags are ever added, the implementation of wl_map 
> > > will have
> > > @@ -103,10 +107,6 @@ struct wl_connection;
> > >  struct wl_closure;
> > >  struct wl_proxy;
> > >  
> > > -int
> > > -wl_interface_equal(const struct wl_interface *iface1,
> > > -const struct wl_interface *iface2);
> > > -
> > >  struct wl_connection *
> > >  wl_connection_create(int fd);
> > >  
> > > diff --git a/src/wayland-util.c b/src/wayland-util.c
> > > index 748476a..5bfb7e1 100644
> > > --- a/src/wayland-util.c
> > > +++ b/src/wayland-util.c
> > > @@ -35,6 +35,19 @@
> > >  
> > >  struct wl_object global_zombie_object;
> > >  
> > > +int
> > > +wl_interface_equal(const struct wl_interface *a, const struct 
> > > wl_interface *b)
> > > +{
> > > + /* In most cases the pointer equality test is sufficient.
> > > +  * However, in some cases, depending on how things are split
> > > +  * across shared objects, we can end up with multiple
> > > +  * instances of the interface metadata constants.  So if the
> > > +  * pointers match, the interfaces are equal, if they don't
> > > +  * match we have to compare the interface names.
> > > +  */
> > > + return a == b || strcmp(a->name, b->name) == 0;
> > > +}
> > > +
> > >  WL_EXPORT void
> > >  wl_list_init(struct wl_list *list)
> > >  {
> > 
> > Reviewed-by: Pekka Paalanen 
> 
> Reviewed-by: Bryce Harrington 

Pushed:
   e5b12aa..385906b  master -> master


> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2
> > 
> > iQIVAwUBVzCFcSNf5bQRqqqnAQjtfBAAmOgNH+tI3mDtBCTwTnPfslCyeDHlZmoa
> > JSvXlkyfxUx0C2TmC4pDUI89JB7pEHM1b2m3u8OotMDBgTf9Vawb9pQuCZB0W8MX
> > 406+41f/m4Lbfo6R66wMiec5swHDxIMA2iu2lR42NKoQEAMfHlkA6QPnZhhJhWNv
> > PT0lwIMG7S82x8j3iHOj/faXCG1WnK1zNL7ZAFCp7Ug1i4o2KeEZqpqS2MRDy/T0
> > O6U3tZHLi42vtxXqsWPY6X4/J2YIysbTM4K17IZlkgxiRUstBncoRdNf0Upo5rPc
> > ZaHBO0wmf55uzUNxgTC3Mh1XopgtNn6/jGV7UlW/U3avSv+cNx8x0k0Geq9K1cch
> > 8lX0RxyEyFlPn6pDk9S27wNdh0SLx7yhfpiCms6x+CHCF2mVjSbViM0d4g1VY5Uw
> > gT69+fhvnbdaJygh35oReoo86PZOpR61phWmeQkToXaj+FnEG8Pl5HSTpqG5tARH
> > G0OXoLdTIXC4yJZUVA15KiUB3QKJmYxiryX3LYrlqiCZI0UCPBY1pI59Nczmy7wo
> > IlQiL3PJIOMGNTqL+Fuzn42DPhfbxugxnTeFTlGyDrzPnUUjCpTqAUrc7r+25OCi
> > vb3wKtH6kgCoEJCY8gI9zKy0PpbMg40DIQDpTfC38ee4rDsvLwzfkYyqrOLK/sPO
> > HXM1WjdzO4Q=
> > =yi7J
> > -END PGP SIGNATURE-
> 
> 
> > 

Re: [PATCH wayland 1/1] doc: Formalize file comment in wayland-client.h, wayland-server.h

[Bryce Harrington]

On Tue, May 10, 2016 at 06:05:44PM -0700, Bryce Harrington wrote:
> On Sun, May 08, 2016 at 02:42:28PM -0500, Yong Bakos wrote:
> > From: Yong Bakos 
> > 
> > Publican was generating a subtle error during a build:
> > Error: no ID for constraint linkend: Server-wayland-server-core_8h.
> > 
> > This was caused by doxygen applying the doc comment at the top of
> > wayland-server.h as the documentation for struct wl_object. As such, the
> > generated documentation for wl_object was also very incorrect.
> > 
> > Make the file doc comments in wayland-client.h and wayland-server.h real
> > doxygen file doc comments with the \file command, add a \brief, make the
> > inclusion warning a \warning, correct the language of the comment in
> > wayland-server.h, and remove one unnecessary line break.
> > 
> > This squelches the publican error, removes the bad wl_object documentation,
> > and makes the comment appear in the generated html documentation.
> > 
> > References: d74a9c079b1aeb44f69b4132dc2c38362e21f281
> > 
> > Signed-off-by: Yong Bakos 
> 
> LGTM,
> 
> Reviewed-by: Bryce Harrington 

Thanks, pushed:
   c6d204f..e5b12aa  master -> master

 
> > ---
> >  src/wayland-client.h | 7 +--
> >  src/wayland-server.h | 9 ++---
> >  2 files changed, 11 insertions(+), 5 deletions(-)
> > 
> > diff --git a/src/wayland-client.h b/src/wayland-client.h
> > index 3856535..9f70fa3 100644
> > --- a/src/wayland-client.h
> > +++ b/src/wayland-client.h
> > @@ -23,8 +23,11 @@
> >   * SOFTWARE.
> >   */
> >  
> > -
> > -/** Use of this header file is discouraged. Prefer including
> > +/** \file
> > + *
> > + *  \brief Include the client API and protocol C API.
> > + *
> > + *  \warning Use of this header file is discouraged. Prefer including
> >   *  wayland-client-core.h instead, which does not include the
> >   *  client protocol header and as such only defines the library
> >   *  API.
> > diff --git a/src/wayland-server.h b/src/wayland-server.h
> > index b6d0e2b..3124703 100644
> > --- a/src/wayland-server.h
> > +++ b/src/wayland-server.h
> > @@ -23,10 +23,13 @@
> >   * SOFTWARE.
> >   */
> >  
> > -
> > -/** Use of this header file is discouraged. Prefer including
> > +/** \file
> > + *
> > + *  \brief Include the server API, deprecations and protocol C API.
> > + *
> > + *  \warning Use of this header file is discouraged. Prefer including
> >   *  wayland-server-core.h instead, which does not include the
> > - *  client protocol header and as such only defines the library
> > + *  server protocol header and as such only defines the library
> >   *  API, excluding the deprecated API below.
> >   */
> >  
> > -- 
> > 2.7.2
> > 
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols 3/4] tablet: restrict the cursor surface to one per tool

[Jason Gerecke]

On Tue, May 10, 2016 at 7:51 PM, Peter Hutterer
 wrote:
> The initial approach was to allow one surface to be re-used between tools,
> seats and even used together as wl_pointer cursor surface. This has a few
> drawbacks, most of which are related to managing the surface correctly in the
> compositor. For example, the same cursor surface could have two different
> hotspots. Animated cursors should animate independently rather than update at
> the same time.
>
> Furthermore: a client cannot know when a surface will cease being used as a
> cursor surface. The basic assumption of "after focus out" is an implementation
> detail in the compositor and unless the client unsets the cursor it is not
> guaranteed that the surface is released. This again makes sharing a surface
> less obvious - you cannot know if the wl_pointer surface is still in use when
> you set it for a new wp_tablet_tool.
>
> Avoid these headaches (and push some of them to the clientl) by simply
> restricting a wl_surface to be assigned to a single tool. For the 99% use case
> where we have one tablet with two tools (pen + eraser) this means we merely
> get two extra surfaces, and the two don't usually share the same cursor shape
> anyway. If sharing is absolutely, a client may still opt to share the
> underlying wl_buffer.
>
> Signed-off-by: Peter Hutterer 
> ---
>  unstable/tablet/tablet-unstable-v2.xml | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/unstable/tablet/tablet-unstable-v2.xml 
> b/unstable/tablet/tablet-unstable-v2.xml
> index e7b8626..d3f57ff 100644
> --- a/unstable/tablet/tablet-unstable-v2.xml
> +++ b/unstable/tablet/tablet-unstable-v2.xml
> @@ -225,13 +225,11 @@
> and pending input regions become undefined, and the wl_surface is
> unmapped.
>
> -   This request gives the surface the role of a cursor. The role
> -   assigned by this request is the same as assigned by
> -   wl_pointer.set_cursor meaning the same surface can be
> -   used both as a wl_pointer cursor and a wp_tablet cursor. If the
> -   surface already has another role, it raises a protocol error.
> -   The surface may be used on multiple tablets and across multiple
> -   seats.
> +   This request gives the surface the role of a wp_tablet_tool cursor. A
> +   surface may only ever be used as cursor surface for one

A surface may only ever be used as "the" cursor surface

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

> +   wp_tablet_tool. If the surface already has another role or has
> +   previously been used as cursor surface for a different tool, a
> +   protocol error is raised.
>
>
> allow-null="true"/>
> --
> 2.7.4
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Does anyone use Weston on the Raspberry Pi?

[Bryce Harrington]

On Wed, May 11, 2016 at 07:53:03AM -0500, Derek Foreman wrote:
> On 11/05/16 03:28 AM, Pekka Paalanen wrote:
> > Hi,
> > 
> > it has been a very long time since anything has happened with Weston's
> > rpi-backend. This is the (only) Weston backend using a proprietary API,
> > for Raspberry Pi it is the DispmanX API.
> > 
> > I have heard reports that the rpi-backend has been a lot more not
> > working than working, allegedly because of firmware issues.
> > 
> > I haven't tried it myself for a long time, but sounds like I wouldn't
> > have much luck in checking if the rpi-backend would still be ok. I
> > might be able to dig up an ancient sd-card image where I originally
> > developed the rpi-backend and test with that, but it seems useless if
> > no-one else doing the same, and if it won't work on recent images
> > anyway.
> > 
> > Is anyone using Weston with the rpi-backend on a Raspberry Pi?
> 
> Last time I tested it (on RPI2) it would run at 30fps when using
> offscreen compositing or hard lock at about 4 windows when using direct
> to screen compositing.  Really unacceptable either way. :/
> 
> I also recall once you crossed a certain number of windows, the
> offscreen compositing had visual anomalies.
> 
> > Would you be upset if I deleted the whole rpi-backend right now?
> > 
> > The rpi-backend is a dead end anyway, because the work in the kernel and
> > Mesa to support the Raspberry Pi is progressing, and eventually you
> > will be able to use the standard DRM-backend of Weston. But, I hear the
> > DRM support is not quite completely there yet, so deleting the
> > rpi-backend might cause a support gap in Weston releases.
> 
> I think there's also another issue at play, my recollection is that the
> video decoder blobs require the use of the openGL blob.
> 
> I think 3D accel works with Mesa now (not sure if that's upstream, but
> it's available), KMS works for setting modes, but if you want to use the
> video decoders with the open stuff you're in trouble. :(
> 
> > So, does anyone care about keeping up with Weston releases if you use
> > it on a Raspberry Pi?
> > 
> > If you do care, it does work for you, and you would like to keep on
> > updating Weston, would you be able to test Weston patches from the
> > mailing list?
> 
> It would be really nice if someone would pick up this torch.  Someone
> saying "Hey, I actually use this and it does work" would go a long way
> to keeping it in the repo.
> 
> If we don't pull the plug for this release, we should at least flag it
> deprecated in some way so people can't say they didn't see it coming?

I can make mention of it being on life support in the 1.11 notes.  Then
when 1.12 opens we could yank it, and have a full cycle to listen for
complaints.

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

Re: [PATCH v3 wayland-protocols 4/4] tablet: Add pad support to the tablet protocol

[Yong Bakos]

On May 10, 2016, at 9:51 PM, Peter Hutterer  wrote:
> 
> From: Carlos Garnacho 
> 
> The pad's interface is similar to the tool interface, a client is notified of
> the pad after the tablet_added event.
> 
> The pad has three functionalities: buttons, rings and strips.
> Buttons are fairly straightforward, rings and strips are separate interfaces
> with a pointer-axis-like source/value/frame events.
> The two interfaces are effectively identical but for the actual value they
> send (degrees vs normalized position).
> 
> Buttons are sequentially indexed starting with zero, unlike other protocols
> where a linux/input.h-style semantic event code is used. Since we expect all
> buttons to have client-specific functionality, an additional event tells the
> client when a given button index is not available, usually because the
> compositor assignes some function to it (e.g. mode switching, see below).
> 
> Specific to the pad device is the set_feedback request which enables a client
> to set a user-defined string to display for an OSD on the current mappings.
> This request is available for buttons, rings and strips.
> 
> Finally, the pad supports "modes", effectively sets of button/ring/strip
> configurations.
> 
> Signed-off-by: Carlos Garnacho 
> Signed-off-by: Peter Hutterer 

Hi Carlos and Peter,
I have some suggestions and corrections, noted inline below.

yong


> ---
> Changes to v2:
> - change to v2 of the protocol
> - various comments and suggestions for improved wording incorporated
> - ring is in wl_fixed degrees now (was int, in 0.01 of a degree)
> - button events changed to sequential indices
> - new buttons_reserved event
> 
> unstable/tablet/tablet-unstable-v2.xml | 436 +
> 1 file changed, 436 insertions(+)
> 
> diff --git a/unstable/tablet/tablet-unstable-v2.xml 
> b/unstable/tablet/tablet-unstable-v2.xml
> index d3f57ff..388b4d2 100644
> --- a/unstable/tablet/tablet-unstable-v2.xml
> +++ b/unstable/tablet/tablet-unstable-v2.xml
> @@ -172,6 +172,22 @@
>   
>summary="the newly added tablet tool"/>
> 
> +
> +
> +  
> + This event is sent whenever a new pad is known to the system. Typically,
> + pads are physically attached to tablets and a pad_added event is
> + sent immediately after the wp_tablet_seat.tablet_added.
> + However, some standalone pad devices logically attach to tablets at
> + runtime, and the client must wait for wp_tablet_pad.enter to know
> + the tablet a pad is attached to.
> +
> + This event only provides the object id of the pad; and all further
> + features (buttons, strips, rings) are sent through the wp_tablet_pad

This event only provides the object id of the pad. All further pad features


> + interface.
> +  
> +   summary="the newly added pad"/>
> +
>   
> 
>   
> @@ -636,4 +652,424 @@
> 
>   
> 
> +  
> +
> +  A circular interaction area.
> +
> +  Events on a ring are logically grouped by the wl_tablet_pad_ring.frame
> +  event.
> +
> +
> +
> +  
> + Request that the compositor use the provided feedback string
> + associated with this ring. This request should be issued immediately
> + after a wp_tablet_pad.enter, or whenever the ring is mapped to a
> + different action.
> +
> + Clients are encouraged to provide context-aware descriptions for
> + the actions associated with the ring; compositors may use this
> + information to offer visual feedback about the button layout
> + (eg. on-screen displays).
> +
> + The provided string 'description' is an UTF-8 encoded string to be

a UTF-8

> + associated with this ring, and is considered user visible; general

user-visible or perhaps just "and is visible by the user;"


> + internationalization rules apply.
> +  
> +  
> +
> +
> +
> +  
> + This destroys the client's resource for this ring object.
> +  
> +
> +
> +
> +  
> + Describes the source types for ring events. This indicates to the
> + client how a ring event was physically generated; a client may
> + adjust the user interface accordingly. For example, events
> + from a "finger" source may trigger kinetic scrolling.
> +  
> +  
> +
> +
> +
> +  
> + Source information for ring events.
> +
> + This event does not occur on its own. It is sent before a
> + wp_tablet_pad_ring.frame event and carries the source information
> + for all events within that frame.
> +
> + The source specifies how this event was generated. If the source is
> + wp_tablet_pad_ring.source.finger, a wp_tablet_pad_ring.stop event
> + will be sent when the user lifts the finger off the device.
> +
> + This event is optional. If the source is unknown for an interaction,
> + no event is sent.
> +  
> +  
> +
> +

Re: Protocol for window previews/thumbnails

[Derek Foreman]

On 11/05/16 03:07 AM, Pekka Paalanen wrote:
> On Tue, 10 May 2016 21:30:53 +0100
> ade low  wrote:
> 
>> I think that it would be a good idea to have a standard, cross-compositor
>> protocol for getting previews/thumbnails of windows, similar to XComposite.
> 
> Hi,
> 
> I strongly disagree. A huge part of Wayland's reason to exist is that
> things like XComposite protocol are not necessary.
> 
>> This protocol should be as fast as possible and use as little system
>> resources as possible. It should probably provide a handle to the native
>> window surface.
>>
>> It will also be necessary to receive damage events on these surfaces. I
>> don't know if this should be included in this protocol or if this should be
>> a separate protocol?
>>
>> Does anyone have any ideas on the best way to design such a protocol?
> 
> "Don't do it" is the only answer based on just this information you
> gave.

Right - and I'll be quick to stand behind Pekka on this one.

I think this is generally considered something that should be done
inside the compositor - but I also think the compositor itself could
expose some manner of API/modular interface/whatever to allow external
code to do this.

That is, wayland protocol is not required for a compositor to allow this
to happen.  And this is a key point people miss when "wayland refuses to
support external task switchers" or whatever shows up as a thread on
reddit. :)

Wayland is not preventing desktops from allowing third party application
switchers/pagers/previewers.

> You should explain the use case behind the idea. Then it would be
> possible to assess whether such protocol would even be appropriate for
> it.
> 
> If some sort of protocol would be needed, then you have to figure out
> how to not make it a gaping security breach, and how to not interfere
> with other clients too badly or cause too much work for the compositor.
> You would also have to figure out how and to what level to synchronize
> things between at least four different actors: your client, the
> compositor, a normal client, and the compositor again.
>
> A little more tractable plan would be to communicate only surface
> meta-data to the client, which could then ask the compositor to draw
> the thumbnails relative to one of the client's surfaces. The client
> would never have access to window content itself. However, then there's
> the question of whether it can be a standard protocol or not.

FWIW, if I had to address this problem, that is probably the route I'd take.

There are a lot of different buffer objects and formats to deal with,
and the compositor already knows how.  Also, keeping the actual contents
out of the hands of other applications (not just for security, but to
keep them from leaking giant chunks of shmem or screwing up timing)
seems like a win.

But I'm of the opinion that this doesn't need to be a "wayland" problem
at all - but I'm not saying there can't be a standard way to do this.

It just doesn't need to be solved by adding wayland protocol.  A common
module framework for compositors that find this functionality useful
would probably perform better and have less complexity.

Thanks,
Derek

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

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

Re: Introduction and updates from NVIDIA

[Miguel Angel Vico]

Hi all,

I just sent a second round of patches to add support for EGLStream &
friend in Weston.

Also, we've uploaded two weston branches that include all these patches
on top of weston master branch.

You can find them here:

  https://cgit.freedesktop.org/~jjones/weston/

'nvidia_head' contains the same set of patches I sent out for review.

'nvidia_r364' contains a slightly different set of patches to make
weston work with our r364 driver, which doesn't have an implementation
of EGL_WL_wayland_eglstream.


Don't hesitate to send me an email if you have doubts or suggestions
about the patches.

I'm also available on Freenode IRC as 'mvicomoya'.


Thanks,
Miguel.


On Mon, 21 Mar 2016 17:28:13 +0100
Miguel Angel Vico  wrote:

> Hi all,
> 
> First of all, I'd like to introduce myself to the Wayland community:
> My name is Miguel A. Vico, and I've been working as a Software
> Engineer for NVIDIA for some time now, more specifically, in the
> Linux drivers team. Although I've never spoken before, I've been
> lately following the amazing work that you all have been doing here.
> 
> We have been working on adding to our drivers all required features to
> be able to run Wayland and Weston on top of it. We have just released
> our NVIDIA's 364.12 GPU driver, which brings initial DRM KMS support
> (among other things). Please, check out our public announcement here:
> 
> 
> https://devtalk.nvidia.com/default/topic/925605/linux/nvidia-364-12-release-vulkan-glvnd-drm-kms-and-eglstreams/
> 
> 
> In order to make the Weston DRM compositor work with our drivers, we
> have used EGLDevice, EGLOutput, and EGLStream objects.
> 
> For those not familiar with this set of EGL structures, here I try to
> summarize the most important part of them, and how would they fit in
> the current Weston DRM compositor design:
> 
> EGLDevice provides means to enumerate native devices, and then
> create an EGL display connection from them.
> 
> Similarly, EGLOutput will provide means to access different
> portions of display control hardware associated with an EGLDevice.
> 
> For instance, EGLOutputLayer represents a portion of display
> control hardware that accepts an image as input and processes it
> for presentation on a display device.
> 
> EGLStream implements a mechanism to communicate frame producers
> and frame consumers. By attaching an EGLOutputLayer consumer to a
> stream, a producer will be able to present frames on a display
> device.
> 
> Thus, a compositor could produce frames and feed them to an
> EGLOutputLayer through an EGLStream for presentation on a display
> device.
> 
> In a similar way, by attaching a GLTexture consumer to a stream, a
> producer (wayland client) could feed frames to a texture, which in
> turn can be used by a compositor to prepare the final frame to be
> presented.
> 
> Whenever EGL_EXT_device_drm extension is present, EGLDevice can
> be used to enumerate and access DRM KMS devices, and
> EGLOutputLayer to enumerate and access DRM KMS crtcs and planes.
> 
> By using EGLStreams and attaching an EGLOutputLayer consumer
> (representing a DRM KMS crtc or plane) to it, compositor-drm can
> produce final composition frames and present them on a DRM device.
> 
> 
> Most of the EGL extensions required to implement this may be already
> found in the Khronos registry, but we also needed extended
> functionality for EGLStreams and EGLOutput consumers provided by
> following extensions:
> 
>  - EGL_NV_stream_attrib:
> 
>
> https://github.com/aritger/eglstreams-kms-example/blob/master/proposed-extensions/EGL_NV_stream_attrib.txt
> 
>Among other things, this extension defines a version of the stream
>acquire function that takes an EGLAttrib parameter, allowing to
>modify/extend acquire behavior in several cases.
> 
>  - EGL_EXT_stream_acquire_mode:
> 
>
> https://github.com/aritger/eglstreams-kms-example/blob/master/proposed-extensions/EGL_EXT_stream_acquire_mode.txt
> 
>By default, EGLOutputLayer consumer are set to automatically
> acquire frames, so eglSwapBuffers() call on the producer side will
> present to the display without any further action. This extension
> defines a new EGLStream attribute which allows to change this
> behavior so that acquire operations must be issued manually with
>eglStreamConsumerAcquireAttribNV().
> 
>  - EGL_NV_output_drm_flip_event:
> 
>
> https://github.com/aritger/eglstreams-kms-example/blob/master/proposed-extensions/EGL_NV_output_drm_flip_event.txt
> 
>This extension defines a new acquire attribute for EGLOutputLayer
>consumers tied to DRM KMS CRTCs. It allows clients to get notified
>whenever an acquire operation issued with
>eglStreamConsumerAcquireAttribNV() is done.
> 
> 
> Additionally, in order to allow wl_buffers to be bound to EGLStreams,
> we kludged eglQueryWaylandBufferWL(EGL_WAYLAND_BUFFER_WL) to 

[PATCH weston 0/1] compositor-drm: Add support for EGLDevice+EGLOutput

[Miguel A. Vico]

Hi,

Here is revised patch. It didn't actually changed very much compared to the
original one.

Thanks,
Miguel.


Summary:
  compositor-drm: Add support for EGLDevice+EGLOutput

  src/compositor-drm.c | 336 
+
  src/main.c   |   1 +
  2 files changed, 234 insertions(+), 103 deletions(-)


NVIDIA GmbH, Wuerselen, Germany, Amtsgericht Aachen, HRB 8361
Managing Director: Karen Theresa Burns

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 0/1] compositor-drm: Add support for EGLDevice+EGLOutput

[Miguel A. Vico]

Hi,

Here is revised patch. It didn't actually changed very much compared to the
original one.

Thanks,
Miguel.


Summary:
  compositor-drm: Add support for EGLDevice+EGLOutput

  src/compositor-drm.c | 336 
+
  src/main.c   |   1 +
  2 files changed, 234 insertions(+), 103 deletions(-)

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

[PATCH weston 1/1] compositor-drm: Add support for EGLDevice+EGLOutput

[Miguel A. Vico]

As previously stated, EGLDevice and EGLOutput will provide means
to access native device objects and different portions of display
control hardware respectively.

Whenever EGL_EXT_device_drm extension is present, EGLDevice can
be used to enumerate and access DRM KMS devices, and EGLOutputLayer
to enumerate and access DRM KMS crtcs and planes.

By using EGLStreams and attaching an EGLOutputLayer consumer
(representing a DRM KMS crtc or plane) to it, compositor-drm can
produce final composition frames and present them on a DRM device.

This change adds required logic to support presentation through
EGLDevice+EGLOutput+EGLStream. Whether GBM or EGLDevice should be
used can be controlled by --use-egldevice backend argument.

Signed-off-by: Miguel A Vico Moya 
Reviewed-by: Andy Ritger 
Reviewed-by: Adam Cheney 
Reviewed-by: James Jones 
---
 src/compositor-drm.c | 336 +++
 src/main.c   |   1 +
 2 files changed, 234 insertions(+), 103 deletions(-)

diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index eb1a2df..befe34c 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -75,6 +75,10 @@
 #define GBM_BO_USE_CURSOR GBM_BO_USE_CURSOR_64X64
 #endif
 
+#ifndef EGL_DRM_MASTER_FD_EXT
+#define EGL_DRM_MASTER_FD_EXT 0x333C
+#endif
+
 static int option_current_mode = 0;
 
 enum output_config {
@@ -101,7 +105,10 @@ struct drm_backend {
int fd;
char *filename;
} drm;
+
+   EGLDeviceEXT egldevice;
struct gbm_device *gbm;
+
uint32_t *crtcs;
int num_crtcs;
uint32_t crtc_allocator;
@@ -124,6 +131,7 @@ struct drm_backend {
int cursors_are_broken;
 
int use_pixman;
+   int use_egldevice;
 
uint32_t prev_state;
 
@@ -225,6 +233,7 @@ struct drm_parameters {
int connector;
int tty;
int use_pixman;
+   int use_egldevice;
const char *seat_id;
 };
 
@@ -531,17 +540,21 @@ drm_output_render_gl(struct drm_output *output, 
pixman_region32_t *damage)
output->base.compositor->renderer->repaint_output(>base,
  damage);
 
-   bo = gbm_surface_lock_front_buffer(output->gbm_surface);
-   if (!bo) {
-   weston_log("failed to lock front buffer: %m\n");
-   return;
-   }
+   if (b->use_egldevice)
+   output->next = output->dumb[0];
+   else {
+   bo = gbm_surface_lock_front_buffer(output->gbm_surface);
+   if (!bo) {
+   weston_log("failed to lock front buffer: %m\n");
+   return;
+   }
 
-   output->next = drm_fb_get_from_bo(bo, b, output->gbm_format);
-   if (!output->next) {
-   weston_log("failed to get drm_fb for bo\n");
-   gbm_surface_release_buffer(output->gbm_surface, bo);
-   return;
+   output->next = drm_fb_get_from_bo(bo, b, output->gbm_format);
+   if (!output->next) {
+   weston_log("failed to get drm_fb for bo\n");
+   gbm_surface_release_buffer(output->gbm_surface, bo);
+   return;
+   }
}
 }
 
@@ -666,9 +679,14 @@ drm_output_repaint(struct weston_output *output_base,
output_base->set_dpms(output_base, WESTON_DPMS_ON);
}
 
-   if (drmModePageFlip(backend->drm.fd, output->crtc_id,
-   output->next->fb_id,
-   DRM_MODE_PAGE_FLIP_EVENT, output) < 0) {
+   if (backend->use_egldevice)
+   ret = gl_renderer->output_stream_flip(>base, output);
+   else
+   ret = drmModePageFlip(backend->drm.fd, output->crtc_id,
+ output->next->fb_id,
+ DRM_MODE_PAGE_FLIP_EVENT, output);
+
+   if (ret < 0) {
weston_log("queueing pageflip failed: %m\n");
goto err_pageflip;
}
@@ -739,7 +757,6 @@ drm_output_start_repaint_loop(struct weston_output 
*output_base)
struct drm_output *output = (struct drm_output *) output_base;
struct drm_backend *backend = (struct drm_backend *)
output_base->compositor->backend;
-   uint32_t fb_id;
struct timespec ts, tnow;
struct timespec vbl2now;
int64_t refresh_nsec;
@@ -795,10 +812,14 @@ drm_output_start_repaint_loop(struct weston_output 
*output_base)
/* Immediate query succeeded, but didn't provide valid timestamp.
 * Use pageflip fallback.
 */
-   fb_id = output->current->fb_id;
+   if (backend->use_egldevice)
+   ret = gl_renderer->output_stream_flip(>base, output);
+   else
+   ret = drmModePageFlip(backend->drm.fd, output->crtc_id,
+ 

Re: [PATCH wayland-protocols 3/4] tablet: restrict the cursor surface to one per tool

[Yong Bakos]

On May 10, 2016, at 9:51 PM, Peter Hutterer  wrote:
> 
> The initial approach was to allow one surface to be re-used between tools,
> seats and even used together as wl_pointer cursor surface. This has a few
> drawbacks, most of which are related to managing the surface correctly in the
> compositor. For example, the same cursor surface could have two different
> hotspots. Animated cursors should animate independently rather than update at
> the same time.
> 
> Furthermore: a client cannot know when a surface will cease being used as a
> cursor surface. The basic assumption of "after focus out" is an implementation
> detail in the compositor and unless the client unsets the cursor it is not
> guaranteed that the surface is released. This again makes sharing a surface
> less obvious - you cannot know if the wl_pointer surface is still in use when
> you set it for a new wp_tablet_tool.
> 
> Avoid these headaches (and push some of them to the clientl) by simply
> restricting a wl_surface to be assigned to a single tool. For the 99% use case
> where we have one tablet with two tools (pen + eraser) this means we merely
> get two extra surfaces, and the two don't usually share the same cursor shape
> anyway. If sharing is absolutely, a client may still opt to share the
> underlying wl_buffer.
> 
> Signed-off-by: Peter Hutterer 

Do you think that last sentence should be mentioned in the description?
Noted inline below...


> ---
> unstable/tablet/tablet-unstable-v2.xml | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/unstable/tablet/tablet-unstable-v2.xml 
> b/unstable/tablet/tablet-unstable-v2.xml
> index e7b8626..d3f57ff 100644
> --- a/unstable/tablet/tablet-unstable-v2.xml
> +++ b/unstable/tablet/tablet-unstable-v2.xml
> @@ -225,13 +225,11 @@
>   and pending input regions become undefined, and the wl_surface is
>   unmapped.
> 
> - This request gives the surface the role of a cursor. The role
> - assigned by this request is the same as assigned by
> - wl_pointer.set_cursor meaning the same surface can be
> - used both as a wl_pointer cursor and a wp_tablet cursor. If the
> - surface already has another role, it raises a protocol error.
> - The surface may be used on multiple tablets and across multiple
> - seats.
> + This request gives the surface the role of a wp_tablet_tool cursor. A
> + surface may only ever be used as cursor surface for one
> + wp_tablet_tool. If the surface already has another role or has
> + previously been used as cursor surface for a different tool, a
> + protocol error is raised.

Is it worth mentioning here that "Clients may still opt to share the underlying
wl_buffer, if sharing is absolutely necessary." Or perhaps its worth /not/
mentioning, in order to not encourage the practice?

yong


>   
>   
>allow-null="true"/>
> -- 
> 2.7.4
> 
> ___
> 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 weston 2/3] gl-renderer: Add support for EGLDevice composited frame presentation

[Miguel A. Vico]

EGLDevice provides means to enumerate native devices, and then create
an EGL display connection from them.

Similarly, EGLOutput will provide means to access different
portions of display control hardware associated with an EGLDevice.

For instance, EGLOutputLayer represents a portion of display
control hardware that accepts an image as input and processes it
for presentation on a display device.

EGLStream implements a mechanism to communicate frame producers and
frame consumers. By attaching an EGLOutputLayer consumer to a stream,
a producer will be able to present frames on a display device.

Thus, a compositor could produce frames and feed them to an
EGLOutputLayer through an EGLStream for presentation on a display
device.

This change adds required logic to support presentation approach
described above.

Note that some unpublished EGL extensions were needed:

 - EGL_NV_stream_attrib:
   
https://github.com/aritger/eglstreams-kms-example/blob/master/proposed-extensions/EGL_NV_stream_attrib.txt

 - EGL_EXT_stream_acquire_mode:
   
https://github.com/aritger/eglstreams-kms-example/blob/master/proposed-extensions/EGL_EXT_stream_acquire_mode.txt

 - EGL_NV_output_drm_flip_event:
   
https://github.com/aritger/eglstreams-kms-example/blob/master/proposed-extensions/EGL_NV_output_drm_flip_event.txt

Signed-off-by: Miguel A Vico Moya 
Reviewed-by: Andy Ritger 
Reviewed-by: Adam Cheney 
Reviewed-by: James Jones 
---
 src/gl-renderer.c| 257 ++-
 src/gl-renderer.h|  19 
 src/weston-egl-ext.h |  34 +++
 3 files changed, 307 insertions(+), 3 deletions(-)

diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index 098440c..9380371 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -84,6 +84,8 @@ struct gl_output_state {
struct gl_border_image borders[4];
enum gl_border_status border_status;
 
+   EGLStreamKHR egl_stream;
+
struct weston_matrix output_matrix;
 };
 
@@ -202,6 +204,28 @@ struct gl_renderer {
 
int has_configless_context;
 
+   PFNEGLGETOUTPUTLAYERSEXTPROC get_output_layers;
+   PFNEGLQUERYOUTPUTLAYERATTRIBEXTPROC query_output_layer_attrib;
+   int has_egl_output_base;
+   int has_egl_output_drm;
+   int has_egl_output_drm_flip_event;
+
+   PFNEGLCREATESTREAMKHRPROC create_stream;
+   PFNEGLDESTROYSTREAMKHRPROC destroy_stream;
+   int has_egl_stream;
+
+   PFNEGLCREATESTREAMPRODUCERSURFACEKHRPROC create_stream_producer_surface;
+   int has_egl_stream_producer_eglsurface;
+
+   PFNEGLSTREAMCONSUMEROUTPUTEXTPROC stream_consumer_output;
+   int has_egl_stream_consumer_egloutput;
+
+#ifdef EGL_NV_stream_attrib
+   PFNEGLSTREAMCONSUMERACQUIREATTRIBNVPROC stream_consumer_acquire_attrib;
+#endif
+   int has_egl_stream_attrib;
+   int has_egl_stream_acquire_mode;
+
int has_dmabuf_import;
struct wl_list dmabuf_images;
 
@@ -1193,6 +1217,37 @@ gl_renderer_repaint_output(struct weston_output *output,
 }
 
 static int
+gl_renderer_output_stream_flip(struct weston_output *output,
+   void *flip_data)
+{
+#if defined(EGL_NV_stream_attrib) && defined(EGL_EXT_stream_acquire_mode)
+   struct gl_output_state *go = get_output_state(output);
+   struct weston_compositor *compositor = output->compositor;
+   struct gl_renderer *gr = get_renderer(compositor);
+
+   EGLAttrib acquire_attribs[3] = { EGL_NONE };
+
+#ifdef EGL_NV_output_drm_flip_event
+   if (gr->has_egl_output_drm_flip_event) {
+   acquire_attribs[0] = EGL_DRM_FLIP_EVENT_DATA_NV;
+   acquire_attribs[1] = (EGLAttrib)flip_data;
+   acquire_attribs[2] = EGL_NONE;
+   }
+#endif
+
+   if (go->egl_stream != EGL_NO_STREAM_KHR)
+   if (EGL_TRUE != 
gr->stream_consumer_acquire_attrib(gr->egl_display,
+  
go->egl_stream,
+  
acquire_attribs))
+   return -1;
+
+   return 0;
+#else
+   return -1;
+#endif
+}
+
+static int
 gl_renderer_read_pixels(struct weston_output *output,
   pixman_format_code_t format, void *pixels,
   uint32_t x, uint32_t y,
@@ -2587,9 +2642,92 @@ gl_renderer_create_window_surface(struct gl_renderer *gr,
return egl_surface;
 }
 
+static EGLSurface
+gl_renderer_create_stream_surface(struct gl_renderer *gr,
+  uint32_t plane_id,
+  uint32_t crtc_id,
+  EGLint width, EGLint height,
+  EGLStreamKHR *egl_stream)
+{
+   EGLint stream_attribs[] = {
+   EGL_STREAM_FIFO_LENGTH_KHR, 1,
+#ifdef EGL_EXT_stream_acquire_mode
+   

[PATCH weston 0/3] gl-renderer: Add support for EGLDevice+EGLOutput

[Miguel A. Vico]

Hi,

Feedback for the first revision has been addressed. Here is a new series that
splits the original patch into several pieces as per Daniel Stone's request.

Patch 1/3 and 2/3 were kept mainly the same as in the original patch. However,
3/3 is a significant refactor and improvement over the original implementation.

Note the usage of the new extension EGL_WL_wayland_eglstream (sent out for
review a week ago) to avoid incorrect utilization of
eglQueryWaylandBufferWL(EGL_WAYLAND_BUFFER_WL) to fetch the stream file
descriptor.

Also, I didn't wrap all newly added EGL function pointers with corresponding
#ifdef, since many of them are already shipped with the official headers. Let
me know if you still want me to wrap them all though.

Thanks,
Miguel.


Summary:
  gl-renderer: Add EGL client support for EGLStream frame presentation
  gl-renderer: Add support for EGLDevice composited frame presentation
  gl-renderer: Add EGLDevice enumeration support

  src/gl-renderer.c| 524 
+++--
  src/gl-renderer.h|  26 +++
  src/weston-egl-ext.h |  39 
  3 files changed, 585 insertions(+), 4 deletions(-)


NVIDIA GmbH, Wuerselen, Germany, Amtsgericht Aachen, HRB 8361
Managing Director: Karen Theresa Burns

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 1/3] gl-renderer: Add EGLDevice enumeration support

[Miguel A. Vico]

EGLDevice provides means to enumerate native devices.

In preparation for follow-on changes to support frame presentation
through EGLDevice+EGLOutput, this change adds both
gl_renderer_get_devices() and gl_renderer_get_drm_device_file()
functions which will help to enumerate EGLDevices and match them to DRM
devices.

Signed-off-by: Miguel A Vico Moya 
Reviewed-by: Andy Ritger 
Reviewed-by: Adam Cheney 
Reviewed-by: James Jones 
---
 src/gl-renderer.c | 87 ++-
 src/gl-renderer.h |  7 +
 2 files changed, 93 insertions(+), 1 deletion(-)

diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index c208f36..098440c 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -3175,6 +3175,88 @@ gl_renderer_setup(struct weston_compositor *ec, 
EGLSurface egl_surface)
return 0;
 }
 
+static int
+gl_renderer_get_devices(EGLint max_devices, EGLDeviceEXT *devices,
+EGLint *num_devices)
+{
+   const char *extensions;
+   PFNEGLQUERYDEVICESEXTPROC query_devices;
+
+   extensions = (const char *)eglQueryString(EGL_NO_DISPLAY, 
EGL_EXTENSIONS);
+   if (!extensions) {
+   weston_log("Retrieving EGL extension string failed.\n");
+   return -1;
+   }
+
+   if (!check_extension(extensions, "EGL_EXT_device_base") &&
+   (!check_extension(extensions, "EGL_EXT_device_query") ||
+!check_extension(extensions, "EGL_EXT_device_enumeration"))) {
+   weston_log("EGL_EXT_device_base not supported\n");
+   return -1;
+   }
+
+   query_devices = (void *) eglGetProcAddress("eglQueryDevicesEXT");
+   if (!query_devices) {
+   weston_log("Failed to get eglQueryDevicesEXT function\n");
+   return -1;
+   }
+
+   if (query_devices(max_devices, devices, num_devices) != EGL_TRUE) {
+   weston_log("Failed to query EGL Devices\n");
+   gl_renderer_print_egl_error_state();
+   return -1;
+   }
+
+   return 0;
+}
+
+static int
+gl_renderer_get_drm_device_file(EGLDeviceEXT device,
+const char **drm_device_file)
+{
+   const char *extensions;
+   PFNEGLQUERYDEVICESTRINGEXTPROC query_device_string;
+
+   extensions = (const char *)eglQueryString(EGL_NO_DISPLAY, 
EGL_EXTENSIONS);
+   if (!extensions) {
+   weston_log("Retrieving EGL extension string failed.\n");
+   return -1;
+   }
+
+   if (!check_extension(extensions, "EGL_EXT_device_base") &&
+   (!check_extension(extensions, "EGL_EXT_device_query") ||
+!check_extension(extensions, "EGL_EXT_device_enumeration"))) {
+   weston_log("EGL_EXT_device_base not supported.\n");
+   return -1;
+   }
+
+   query_device_string = (void *) 
eglGetProcAddress("eglQueryDeviceStringEXT");
+   if (!query_device_string) {
+   weston_log("Failed to get eglQueryDeviceStringEXT function\n");
+   return -1;
+   }
+
+   extensions = query_device_string(device, EGL_EXTENSIONS);
+   if (!extensions) {
+   weston_log("Retrieving EGL extension string failed.\n");
+   return -1;
+   }
+
+   if (!check_extension(extensions, "EGL_EXT_device_drm")) {
+   weston_log("EGL_EXT_device_drm not supported.\n");
+   return -1;
+   }
+
+   (*drm_device_file) = query_device_string(device, 
EGL_DRM_DEVICE_FILE_EXT);
+   if (*drm_device_file == NULL) {
+   weston_log("Failed to query DRM device name.\n");
+   gl_renderer_print_egl_error_state();
+   return -1;
+   }
+
+   return 0;
+}
+
 WL_EXPORT struct gl_renderer_interface gl_renderer_interface = {
.opaque_attribs = gl_renderer_opaque_attribs,
.alpha_attribs = gl_renderer_alpha_attribs,
@@ -3185,5 +3267,8 @@ WL_EXPORT struct gl_renderer_interface 
gl_renderer_interface = {
.output_destroy = gl_renderer_output_destroy,
.output_surface = gl_renderer_output_surface,
.output_set_border = gl_renderer_output_set_border,
-   .print_egl_error_state = gl_renderer_print_egl_error_state
+   .print_egl_error_state = gl_renderer_print_egl_error_state,
+
+   .get_devices = gl_renderer_get_devices,
+   .get_drm_device_file = gl_renderer_get_drm_device_file
 };
diff --git a/src/gl-renderer.h b/src/gl-renderer.h
index f778cd9..f376edd 100644
--- a/src/gl-renderer.h
+++ b/src/gl-renderer.h
@@ -129,5 +129,12 @@ struct gl_renderer_interface {
  int32_t tex_width, unsigned char *data);
 
void (*print_egl_error_state)(void);
+
+   int (*get_devices)(EGLint max_devices,
+  EGLDeviceEXT *devices,
+  EGLint *num_devices);
+
+   int 

[PATCH weston 1/1] gl-renderer: Refactor gl_renderer_output_window_create()

[Miguel A. Vico]

In preparation for follow-on changes to support frame presentation
through EGLDevice+EGLOutput, this change refactors
gl_renderer_output_window_create() to separate out window surface
creation code from output common creation code.

Bonus: Fix EGLSurface leakage upon gl_renderer_setup() failure.

Signed-off-by: Miguel A Vico Moya 
Reviewed-by: Andy Ritger 
Reviewed-by: James Jones 
---
 src/gl-renderer.c | 96 ---
 1 file changed, 64 insertions(+), 32 deletions(-)

diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index 1d76488..c208f36 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -1,6 +1,7 @@
 /*
  * Copyright © 2012 Intel Corporation
  * Copyright © 2015 Collabora, Ltd.
+ * Copyright © 2016 NVIDIA Corporation
  *
  * Permission is hereby granted, free of charge, to any person obtaining
  * a copy of this software and associated documentation files (the
@@ -2546,24 +2547,21 @@ gl_renderer_output_set_border(struct weston_output 
*output,
 static int
 gl_renderer_setup(struct weston_compositor *ec, EGLSurface egl_surface);
 
-static int
-gl_renderer_output_window_create(struct weston_output *output,
+static EGLSurface
+gl_renderer_create_window_surface(struct gl_renderer *gr,
  EGLNativeWindowType window_for_legacy,
  void *window_for_platform,
  const EGLint *config_attribs,
  const EGLint *visual_id,
  int n_ids)
 {
-   struct weston_compositor *ec = output->compositor;
-   struct gl_renderer *gr = get_renderer(ec);
-   struct gl_output_state *go;
+   EGLSurface egl_surface = EGL_NO_SURFACE;
EGLConfig egl_config;
-   int i;
 
if (egl_choose_config(gr, config_attribs, visual_id,
  n_ids, _config) == -1) {
weston_log("failed to choose EGL config for output\n");
-   return -1;
+   return EGL_NO_SURFACE;
}
 
if (egl_config != gr->egl_config &&
@@ -2571,48 +2569,82 @@ gl_renderer_output_window_create(struct weston_output 
*output,
weston_log("attempted to use a different EGL config for an "
   "output but EGL_MESA_configless_context is not "
   "supported\n");
-   return -1;
+   return EGL_NO_SURFACE;
}
 
-   go = zalloc(sizeof *go);
-   if (go == NULL)
-   return -1;
+   log_egl_config_info(gr->egl_display, egl_config);
 
-   if (gr->create_platform_window) {
-   go->egl_surface =
-   gr->create_platform_window(gr->egl_display,
-  egl_config,
-  window_for_platform,
-  NULL);
-   } else {
-   go->egl_surface =
-   eglCreateWindowSurface(gr->egl_display,
-  egl_config,
-  window_for_legacy, NULL);
-   }
+   if (gr->create_platform_window)
+   egl_surface = gr->create_platform_window(gr->egl_display,
+egl_config,
+window_for_platform,
+NULL);
+   else
+   egl_surface = eglCreateWindowSurface(gr->egl_display,
+egl_config,
+window_for_legacy, NULL);
 
-   if (go->egl_surface == EGL_NO_SURFACE) {
-   weston_log("failed to create egl surface\n");
-   free(go);
-   return -1;
-   }
+   return egl_surface;
+}
+
+static int
+gl_renderer_output_create(struct weston_output *output,
+  EGLSurface surface)
+{
+   struct weston_compositor *ec = output->compositor;
+   struct gl_renderer *gr = get_renderer(ec);
+   struct gl_output_state *go;
+   int i;
 
if (gr->egl_context == NULL)
-   if (gl_renderer_setup(ec, go->egl_surface) < 0) {
-   free(go);
+   if (gl_renderer_setup(ec, surface) < 0) {
return -1;
}
 
+   go = zalloc(sizeof *go);
+   if (go == NULL)
+   return -1;
+
+   go->egl_surface = surface;
+
for (i = 0; i < BUFFER_DAMAGE_COUNT; i++)
pixman_region32_init(>buffer_damage[i]);
 
output->renderer_state = go;
 
-   log_egl_config_info(gr->egl_display, egl_config);
-
return 0;
 }
 
+static int
+gl_renderer_output_window_create(struct weston_output *output,
+ 

[PATCH weston 0/1] gl-renderer: Refactor gl_renderer_output_window_create()

[Miguel A. Vico]

Hi,

Here is revised patch addressing Daniel Stone's concerns about the error
handling in gl_renderer_output_window_create().

Thanks,
Miguel.


Summary:
  gl-renderer: Refactor gl_renderer_output_window_create()

  src/gl-renderer.c | 96 
++---
  1 file changed, 64 insertions(+), 32 deletions(-)


NVIDIA GmbH, Wuerselen, Germany, Amtsgericht Aachen, HRB 8361
Managing Director: Karen Theresa Burns

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 0/5] gl-renderer: Renaming of things and minor improvements

[Miguel A. Vico]

Hi,

Feedback for the first revision has been addressed. Here is a new series that
basically splits the orginal patch into several little pieces.

Additionally, gl_renderer_create() has been renamed to
gl_renderer_display_create() as per Daniel Stone's request.

Thanks,
Miguel.


Summary:
  gl-renderer: Accept non-NULL empty  arrays
  gl-renderer: Add  param to gl_renderer_display_create
  gl-renderer: Rename  param of gl_renderer to 
  gl-renderer: Rename gl_renderer::output_create to output_window_create
  gl-renderer: Rename gl_renderer_create to gl_renderer_display_create

  src/compositor-drm.c |  5 +++--
  src/compositor-fbdev.c   |  5 +++--
  src/compositor-wayland.c |  5 +++--
  src/compositor-x11.c |  7 ---
  src/gl-renderer.c| 22 +++---
  src/gl-renderer.h|  9 +
  6 files changed, 29 insertions(+), 24 deletions(-)


NVIDIA GmbH, Wuerselen, Germany, Amtsgericht Aachen, HRB 8361
Managing Director: Karen Theresa Burns

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 1/5] gl-renderer: Rename gl_renderer_create to gl_renderer_display_create

[Miguel A. Vico]

No functional change. This patch only renames gl_renderer_create() to
gl_renderer_display_create(), which is something more descriptive of
what the function does.

Signed-off-by: Miguel A Vico Moya 
Reviewed-by: James Jones 
---
 src/compositor-drm.c | 2 +-
 src/compositor-fbdev.c   | 2 +-
 src/compositor-wayland.c | 2 +-
 src/compositor-x11.c | 5 +++--
 src/gl-renderer.c| 4 ++--
 src/gl-renderer.h| 2 +-
 6 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index a47b453..9c58710 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -1585,7 +1585,7 @@ drm_backend_create_gl_renderer(struct drm_backend *b)
 
if (format[1])
n_formats = 3;
-   if (gl_renderer->create(b->compositor,
+   if (gl_renderer->display_create(b->compositor,
EGL_PLATFORM_GBM_KHR,
(void *)b->gbm,
gl_renderer->opaque_attribs,
diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
index ee762e3..c6ffcd7 100644
--- a/src/compositor-fbdev.c
+++ b/src/compositor-fbdev.c
@@ -785,7 +785,7 @@ fbdev_backend_create(struct weston_compositor *compositor, 
int *argc, char *argv
goto out_launcher;
}
 
-   if (gl_renderer->create(compositor, NO_EGL_PLATFORM,
+   if (gl_renderer->display_create(compositor, NO_EGL_PLATFORM,
EGL_DEFAULT_DISPLAY,
gl_renderer->opaque_attribs,
NULL, 0) < 0) {
diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index d0d1082..e4595c7 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -2261,7 +2261,7 @@ wayland_backend_create(struct weston_compositor 
*compositor,
}
 
if (!b->use_pixman) {
-   if (gl_renderer->create(compositor,
+   if (gl_renderer->display_create(compositor,
EGL_PLATFORM_WAYLAND_KHR,
b->parent.wl_display,
gl_renderer->alpha_attribs,
diff --git a/src/compositor-x11.c b/src/compositor-x11.c
index 629b5f3..78b9c62 100644
--- a/src/compositor-x11.c
+++ b/src/compositor-x11.c
@@ -1557,8 +1557,9 @@ init_gl_renderer(struct x11_backend *b)
if (!gl_renderer)
return -1;
 
-   ret = gl_renderer->create(b->compositor, EGL_PLATFORM_X11_KHR, (void *) 
b->dpy,
- gl_renderer->opaque_attribs, NULL, 0);
+   ret = gl_renderer->display_create(b->compositor, EGL_PLATFORM_X11_KHR,
+ (void *) b->dpy,
+ gl_renderer->opaque_attribs, NULL, 0);
 
return ret;
 }
diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index 23c0cd7..197e5c2 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -2873,7 +2873,7 @@ platform_to_extension(EGLenum platform)
 }
 
 static int
-gl_renderer_create(struct weston_compositor *ec, EGLenum platform,
+gl_renderer_display_create(struct weston_compositor *ec, EGLenum platform,
void *native_window, const EGLint *attribs,
const EGLint *visual_id, int n_ids)
 {
@@ -3147,7 +3147,7 @@ WL_EXPORT struct gl_renderer_interface 
gl_renderer_interface = {
.opaque_attribs = gl_renderer_opaque_attribs,
.alpha_attribs = gl_renderer_alpha_attribs,
 
-   .create = gl_renderer_create,
+   .display_create = gl_renderer_display_create,
.display = gl_renderer_display,
.output_create = gl_renderer_output_create,
.output_destroy = gl_renderer_output_destroy,
diff --git a/src/gl-renderer.h b/src/gl-renderer.h
index 71f6b46..cd67a89 100644
--- a/src/gl-renderer.h
+++ b/src/gl-renderer.h
@@ -75,7 +75,7 @@ struct gl_renderer_interface {
const EGLint *opaque_attribs;
const EGLint *alpha_attribs;
 
-   int (*create)(struct weston_compositor *ec,
+   int (*display_create)(struct weston_compositor *ec,
  EGLenum platform,
  void *native_window,
  const EGLint *attribs,
-- 
2.8.0

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

[PATCH weston 4/5] gl-renderer: Add param to gl_renderer_display_create

[Miguel A. Vico]

In preparation for follow-on changes to support frame presentation
through EGLDevice+EGLOutput, this change adds 
parameter to gl_renderer_display_create().

Signed-off-by: Miguel A Vico Moya 
Reviewed-by: Andy Ritger 
Reviewed-by: James Jones 
---
 src/compositor-drm.c | 1 +
 src/compositor-fbdev.c   | 1 +
 src/compositor-wayland.c | 1 +
 src/compositor-x11.c | 2 +-
 src/gl-renderer.c| 6 +++---
 src/gl-renderer.h| 1 +
 6 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 4b4a3e7..a81d29f 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -1588,6 +1588,7 @@ drm_backend_create_gl_renderer(struct drm_backend *b)
if (gl_renderer->display_create(b->compositor,
EGL_PLATFORM_GBM_KHR,
(void *)b->gbm,
+   NULL,
gl_renderer->opaque_attribs,
format,
n_formats) < 0) {
diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
index 21a24fd..7a7c329 100644
--- a/src/compositor-fbdev.c
+++ b/src/compositor-fbdev.c
@@ -787,6 +787,7 @@ fbdev_backend_create(struct weston_compositor *compositor, 
int *argc, char *argv
 
if (gl_renderer->display_create(compositor, NO_EGL_PLATFORM,
EGL_DEFAULT_DISPLAY,
+   NULL,
gl_renderer->opaque_attribs,
NULL, 0) < 0) {
weston_log("gl_renderer_create failed.\n");
diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index 58d9ae7..1317aa5 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -2264,6 +2264,7 @@ wayland_backend_create(struct weston_compositor 
*compositor,
if (gl_renderer->display_create(compositor,
EGL_PLATFORM_WAYLAND_KHR,
b->parent.wl_display,
+   NULL,
gl_renderer->alpha_attribs,
NULL,
0) < 0) {
diff --git a/src/compositor-x11.c b/src/compositor-x11.c
index 6b61cee..52b7a7e 100644
--- a/src/compositor-x11.c
+++ b/src/compositor-x11.c
@@ -1558,7 +1558,7 @@ init_gl_renderer(struct x11_backend *b)
return -1;
 
ret = gl_renderer->display_create(b->compositor, EGL_PLATFORM_X11_KHR,
- (void *) b->dpy,
+ (void *) b->dpy, NULL,
  gl_renderer->opaque_attribs, NULL, 0);
 
return ret;
diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index b0bee7f..7f52205 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -2874,8 +2874,8 @@ platform_to_extension(EGLenum platform)
 
 static int
 gl_renderer_display_create(struct weston_compositor *ec, EGLenum platform,
-   void *native_window, const EGLint *config_attribs,
-   const EGLint *visual_id, int n_ids)
+   void *native_window, const EGLint *platform_attribs,
+   const EGLint *config_attribs, const EGLint *visual_id, int n_ids)
 {
struct gl_renderer *gr;
EGLint major, minor;
@@ -2917,7 +2917,7 @@ gl_renderer_display_create(struct weston_compositor *ec, 
EGLenum platform,
if (get_platform_display && platform) {
gr->egl_display = get_platform_display(platform,
   native_window,
-  NULL);
+  
platform_attribs);
}
}
 
diff --git a/src/gl-renderer.h b/src/gl-renderer.h
index d431319..f778cd9 100644
--- a/src/gl-renderer.h
+++ b/src/gl-renderer.h
@@ -78,6 +78,7 @@ struct gl_renderer_interface {
int (*display_create)(struct weston_compositor *ec,
  EGLenum platform,
  void *native_window,
+ const EGLint *platform_attribs,
  const EGLint *config_attribs,
  const EGLint *visual_id,
  const int n_ids);
-- 
2.8.0

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

[PATCH weston 3/5] gl-renderer: Rename param of gl_renderer to

[Miguel A. Vico]

In preparation for follow-on changes to support frame presentation
through EGLDevice+EGLOutput, this change renames  parameter
of gl_renderer_display_create() and gl_renderer_output_window_create()
to 

Signed-off-by: Miguel A Vico Moya 
Reviewed-by: Andy Ritger 
Reviewed-by: James Jones 
---
 src/gl-renderer.c | 8 
 src/gl-renderer.h | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index 784cacb..b0bee7f 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -2550,7 +2550,7 @@ static int
 gl_renderer_output_window_create(struct weston_output *output,
  EGLNativeWindowType window_for_legacy,
  void *window_for_platform,
- const EGLint *attribs,
+ const EGLint *config_attribs,
  const EGLint *visual_id,
  int n_ids)
 {
@@ -2560,7 +2560,7 @@ gl_renderer_output_window_create(struct weston_output 
*output,
EGLConfig egl_config;
int i;
 
-   if (egl_choose_config(gr, attribs, visual_id,
+   if (egl_choose_config(gr, config_attribs, visual_id,
  n_ids, _config) == -1) {
weston_log("failed to choose EGL config for output\n");
return -1;
@@ -2874,7 +2874,7 @@ platform_to_extension(EGLenum platform)
 
 static int
 gl_renderer_display_create(struct weston_compositor *ec, EGLenum platform,
-   void *native_window, const EGLint *attribs,
+   void *native_window, const EGLint *config_attribs,
const EGLint *visual_id, int n_ids)
 {
struct gl_renderer *gr;
@@ -2938,7 +2938,7 @@ gl_renderer_display_create(struct weston_compositor *ec, 
EGLenum platform,
goto fail_with_error;
}
 
-   if (egl_choose_config(gr, attribs, visual_id,
+   if (egl_choose_config(gr, config_attribs, visual_id,
  n_ids, >egl_config) < 0) {
weston_log("failed to choose EGL config\n");
goto fail_terminate;
diff --git a/src/gl-renderer.h b/src/gl-renderer.h
index ae9bf0f..d431319 100644
--- a/src/gl-renderer.h
+++ b/src/gl-renderer.h
@@ -78,7 +78,7 @@ struct gl_renderer_interface {
int (*display_create)(struct weston_compositor *ec,
  EGLenum platform,
  void *native_window,
- const EGLint *attribs,
+ const EGLint *config_attribs,
  const EGLint *visual_id,
  const int n_ids);
 
@@ -87,7 +87,7 @@ struct gl_renderer_interface {
int (*output_window_create)(struct weston_output *output,
 EGLNativeWindowType window_for_legacy,
 void *window_for_platform,
-const EGLint *attribs,
+const EGLint *config_attribs,
 const EGLint *visual_id,
 const int n_ids);
 
-- 
2.8.0

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

Re: [PATCH wayland-protocols 2/4] tablet: change all degree values from int to wl_fixed

[Yong Bakos]

Hi Peter,

On May 10, 2016, at 9:51 PM, Peter Hutterer  wrote:
> 
> Signed-off-by: Peter Hutterer 
> ---
> unstable/tablet/tablet-unstable-v2.xml | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/unstable/tablet/tablet-unstable-v2.xml 
> b/unstable/tablet/tablet-unstable-v2.xml
> index 81e9835..e7b8626 100644
> --- a/unstable/tablet/tablet-unstable-v2.xml
> +++ b/unstable/tablet/tablet-unstable-v2.xml
> @@ -478,21 +478,21 @@
> 
>   
>   Sent whenever one or both of the tilt axes on a tool change. Each tilt
> - value is in 0.01 of a degree, relative to the z-axis of the tablet.
> + value is in degrees, relative to the z-axis of the tablet.
>   The angle is positive when the top of a tool tilts along the
>   positive x or y axis.
>   
> -  
> -  
> +  
> +  
> 
> 
> 
>   
>   Sent whenever the z-rotation axis on the tool changes. The
> - rotation value is in 0.01 of a degree clockwise from the tool's
> + rotation value is in degrees clockwise from the tool's
>   logical neutral position.
>   
> -  
> +  
> 
> 
> 
> @@ -510,10 +510,10 @@
>   
>   Sent whenever the wheel on the tool emits an event. This event
>   contains two values for the same axis change. The degrees value is
> - in 0.01 of a degree in the same orientation as the
> - wl_pointer.vertical_scroll axis. The clicks value is in discrete
> - logical clicks of the mouse wheel. This value may be zero if the
> - movement of the wheel was less than one logical click.
> + in degrees in the same orientation as the wl_pointer.vertical_scroll

Perhaps just "The degrees value is in the same orientation as," because, here,
"The degrees value is in degrees," is cumbersome.

(Side note: maybe all 'degrees' arg names should actually be 'angle' ?)

Regards,
yong



> + axis. The clicks value is in discrete logical clicks of the mouse
> + wheel. This value may be zero if the movement of the wheel was less
> + than one logical click.
> 
>   Clients should choose either value and avoid mixing degrees and
>   clicks. The compositor may accumulate values smaller than a logical
> @@ -521,7 +521,7 @@
>   Thus, wl_tablet_tool.wheel events with non-zero clicks values may
>   have different degrees values.
>   
> -  
> +  
>   
> 
> 
> -- 
> 2.7.4
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

Re: Does anyone use Weston on the Raspberry Pi?

[Derek Foreman]

On 11/05/16 03:28 AM, Pekka Paalanen wrote:
> Hi,
> 
> it has been a very long time since anything has happened with Weston's
> rpi-backend. This is the (only) Weston backend using a proprietary API,
> for Raspberry Pi it is the DispmanX API.
> 
> I have heard reports that the rpi-backend has been a lot more not
> working than working, allegedly because of firmware issues.
> 
> I haven't tried it myself for a long time, but sounds like I wouldn't
> have much luck in checking if the rpi-backend would still be ok. I
> might be able to dig up an ancient sd-card image where I originally
> developed the rpi-backend and test with that, but it seems useless if
> no-one else doing the same, and if it won't work on recent images
> anyway.
> 
> Is anyone using Weston with the rpi-backend on a Raspberry Pi?

Last time I tested it (on RPI2) it would run at 30fps when using
offscreen compositing or hard lock at about 4 windows when using direct
to screen compositing.  Really unacceptable either way. :/

I also recall once you crossed a certain number of windows, the
offscreen compositing had visual anomalies.

> Would you be upset if I deleted the whole rpi-backend right now?
> 
> The rpi-backend is a dead end anyway, because the work in the kernel and
> Mesa to support the Raspberry Pi is progressing, and eventually you
> will be able to use the standard DRM-backend of Weston. But, I hear the
> DRM support is not quite completely there yet, so deleting the
> rpi-backend might cause a support gap in Weston releases.

I think there's also another issue at play, my recollection is that the
video decoder blobs require the use of the openGL blob.

I think 3D accel works with Mesa now (not sure if that's upstream, but
it's available), KMS works for setting modes, but if you want to use the
video decoders with the open stuff you're in trouble. :(

> So, does anyone care about keeping up with Weston releases if you use
> it on a Raspberry Pi?
> 
> If you do care, it does work for you, and you would like to keep on
> updating Weston, would you be able to test Weston patches from the
> mailing list?

It would be really nice if someone would pick up this torch.  Someone
saying "Hey, I actually use this and it does work" would go a long way
to keeping it in the repo.

If we don't pull the plug for this release, we should at least flag it
deprecated in some way so people can't say they didn't see it coming?

> I have a lot to do, and I would prefer to not invest effort in code
> no-one is using, that is tagged for removal in the future anyway.
> 
> 
> Thanks,
> pq
> 
> 
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 

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

Re: [PATCH weston v4 14/14] compositor-wayland: move weston_wayland_backend_config_release call from load_wayland_backend_config to caller

[Pekka Paalanen]

On Tue, 10 May 2016 22:47:57 +0200
Benoit Gschwind  wrote:

> Signed-off-by: Benoit Gschwind 
> ---
>  src/main.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)

And all the rest pushed too, with minor changes and Quentin's R-b:
   3ff10da..5375384  master -> master


Thanks,
pq


pgp0_xEJgxT4G.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 v4 06/14] compositor-wayland: move configuration parsing to weston main.c

[Pekka Paalanen]

On Tue, 10 May 2016 22:47:49 +0200
Benoit Gschwind  wrote:

> Move function load_wayland_backend_config,
> wayland_backend_config_add_new_output, wayland_backend_config_release,
> wayland_output_config_init from compositor-wayland.c to main.c.
> 
> Create a glue function load_wayland_backend to use moved functions and
> following the new load_*_backend style.
> 
> Signed-off-by: Benoit Gschwind 

Hi Benoit,

patches 1-6 with minor changes and Quentin's R-b from irc, pushed:
   1c0e40d..3ff10da  master -> master

I'll check the rest later.


Thanks,
pq


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

Does anyone use Weston on the Raspberry Pi?

[Pekka Paalanen]

Hi,

it has been a very long time since anything has happened with Weston's
rpi-backend. This is the (only) Weston backend using a proprietary API,
for Raspberry Pi it is the DispmanX API.

I have heard reports that the rpi-backend has been a lot more not
working than working, allegedly because of firmware issues.

I haven't tried it myself for a long time, but sounds like I wouldn't
have much luck in checking if the rpi-backend would still be ok. I
might be able to dig up an ancient sd-card image where I originally
developed the rpi-backend and test with that, but it seems useless if
no-one else doing the same, and if it won't work on recent images
anyway.

Is anyone using Weston with the rpi-backend on a Raspberry Pi?

Would you be upset if I deleted the whole rpi-backend right now?

The rpi-backend is a dead end anyway, because the work in the kernel and
Mesa to support the Raspberry Pi is progressing, and eventually you
will be able to use the standard DRM-backend of Weston. But, I hear the
DRM support is not quite completely there yet, so deleting the
rpi-backend might cause a support gap in Weston releases.

So, does anyone care about keeping up with Weston releases if you use
it on a Raspberry Pi?

If you do care, it does work for you, and you would like to keep on
updating Weston, would you be able to test Weston patches from the
mailing list?

I have a lot to do, and I would prefer to not invest effort in code
no-one is using, that is tagged for removal in the future anyway.


Thanks,
pq


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

Re: Protocol for window previews/thumbnails

[Pekka Paalanen]

On Tue, 10 May 2016 21:30:53 +0100
ade low  wrote:

> I think that it would be a good idea to have a standard, cross-compositor
> protocol for getting previews/thumbnails of windows, similar to XComposite.

Hi,

I strongly disagree. A huge part of Wayland's reason to exist is that
things like XComposite protocol are not necessary.

> This protocol should be as fast as possible and use as little system
> resources as possible. It should probably provide a handle to the native
> window surface.
> 
> It will also be necessary to receive damage events on these surfaces. I
> don't know if this should be included in this protocol or if this should be
> a separate protocol?
> 
> Does anyone have any ideas on the best way to design such a protocol?

"Don't do it" is the only answer based on just this information you
gave.

You should explain the use case behind the idea. Then it would be
possible to assess whether such protocol would even be appropriate for
it.

If some sort of protocol would be needed, then you have to figure out
how to not make it a gaping security breach, and how to not interfere
with other clients too badly or cause too much work for the compositor.
You would also have to figure out how and to what level to synchronize
things between at least four different actors: your client, the
compositor, a normal client, and the compositor again.

A little more tractable plan would be to communicate only surface
meta-data to the client, which could then ask the compositor to draw
the thumbnails relative to one of the client's surfaces. The client
would never have access to window content itself. However, then there's
the question of whether it can be a standard protocol or not.


Thanks,
pq


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