Re: How to support wl_touch input? (when developing clients)

[Philipp Kerling]

2024-05-09 (木) の 08:57 +1000 に Peter Hutterer さんは書きました:
> Another one I wrote (apparently):
> https://gitlab.freedesktop.org/whot/touchmouse
> I don't remember much about this (last commit 3 years ago) but it
> still
> works. This may be the easiest one for quick testing if no specific
> event sequences are required.
If you need multi-touch, you can try https://gitlab.com/shul/mtemu (it
uses/requires multiple mice). It's 6 years old though so no idea if it
still works OK.

Re: [PATCH wayland] protocol: Bump seat to version 7 and require keymaps be private

[Philipp Kerling]

Actually...  (below)

2018-11-01 (木) の 11:15 -0500 に Derek Foreman さんは書きました:
> Weston commit 76829fc4eaea329d2a525c3978271e13bd76c078 (and similar
> commits for other compositors) protects the compositor's keyboard
> mapping from client damage by duplicating the keymap for every
> client.
> 
> On some systems there are other potential fixes for this - such as
> using sealed memfds on linux - but we can't use them since
> essentially all client code anywhere has mapped the keyboard map
> with a MAP_SHARED mmap() call.
> 
> While we can't break years worth of code, we can require any future
> clients to use MAP_PRIVATE if they use a seat version above 6.
> 
> If a compositor can't use sealing or a similar facility, it should
> still protect itself with copied keymaps, but clients must always
> assume shared mapping of a keymap will fail.
> 
> Signed-off-by: Derek Foreman 
> ---
>  protocol/wayland.xml | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 141038b..802d433 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -1660,7 +1660,7 @@
>  
> 
>  
> -  
> +  
>  
>A seat is a group of keyboards, pointer and touch devices.
> This
>object is published as a global during start up, or when such
> a
> @@ -1769,7 +1769,7 @@
>  
>
>  
> -  
> +  
What is the reason for this version bump? The wl_pointer behavior is
unaffected by the wl_keyboard change, right? As far as I understood the
protocol versioning rules, bumping all child interfaces when updating
one child interface is not required. In fact that would make their
version counters quite superfluous.

(Same for wl_touch)

>  
>The wl_pointer interface represents one or more input devices,
>such as mice, which control the pointer location and
> pointer_focus
> @@ -2092,7 +2092,7 @@
>  
>
>  
> -  
> +  
>  
>The wl_keyboard interface represents one or more keyboards
>associated with a seat.
> @@ -2113,6 +2113,9 @@
>
>   This event provides a file descriptor to the client which can
> be
>   memory-mapped to provide a keyboard mapping description.
> +
> + From version 7 onwards, the fd must be mapped with MAP_PRIVATE
> by
> + the recipient, as MAP_SHARED may fail.
>
> summary="keymap format"/>
>
> @@ -2203,7 +2206,7 @@
>  
>
>  
> -  
> +  
>  
>The wl_touch interface represents a touchscreen
>associated with a seat.

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

Re: [PATCH wayland] protocol: Bump seat to version 7 and require keymaps be private

[Philipp Kerling]

I second: \o/

Don't know if it means much at this point, but as original reporter of
the issue I claim this is

Reviewed-by: Philipp Kerling 

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

Re: [PATCH] protocol: warn clients about some wl_output properties

[Philipp Kerling]

Hi,

one small comment below.

2018-07-03 (火) の 09:01 -0400 に Simon Ser さんは書きました:
> All wl_output properties don't always make sense for all
> compositors.
> 
> Some compositors might not implement a "global compositor space",
> (e.g. 3D compositors) in which case properties like x and y don't
> make sense.
> 
> Some compositors might expose virtual outputs, in which case modes,
> make and model are not relevant.
> 
> In a lot of these situations, information from xdg_output is better
> suited.
> ---
> Regular clients shouldn't use most of these properties anyway.
> wl_output is not meant to be an output management protocol. wl_output
> should only expose enough information to allow clients to display
> themselves properly. I don't think there's any legitimate use-case
> to read geometry.{x,y,make,model} and modes for regular clients. Some
> clients (e.g. xwayland) need more information and support an
> additional
> protocol (xdg-output) that's better suited.
> 
> Because of this, compositors should be allowed to fake these
> properties,
> and clients should be prepared to receive fake data.
> 
> I'm not completely happy with this patch. IMHO we should completely
> deprecate modes because I really fail to see how clients will use
> this
> information properly.
I'm not sure if that was the original intention, but having the modes
IMO is required to you use the (still unstable) fullscreen-shell
protocol. There you really need this kind of information to make
sensible choices about your window size. Of course, this does not mean
that the mode information must or should be conveyed over wl_output in
general, it could as well be a protocol specific to fullscreen-shell.

> To do so we can probably just bump the protocol
> version and make this event optional?
> 
>  protocol/wayland.xml | 15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index b5662e0..b4ffcd5 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -2399,6 +2399,13 @@
>   The geometry event describes geometric properties of the
> output.
>   The event is sent when binding to the output object and
> whenever
>   any of the properties change.
> +
> + Note: wl_output only advertises partial information about
> the output
> + position and identification. Some compositors, for instance
> those not
> + implementing a desktop-style output layout or those exposing
> virtual
> + outputs, might fake this information. Instead of using x and
> y, clients
> + should use xdg_output.logical_position. Instead of using
> make and model,
> + clients should use xdg_output.name and
> xdg_output.description.
>
>  summary="x position within the global compositor space"/>
> @@ -2443,7 +2450,13 @@
>   the output device. This is not necessarily the same as
>   the output size in the global compositor space. For
> instance,
>   the output may be scaled, as described in wl_output.scale,
> - or transformed, as described in wl_output.transform.
> + or transformed, as described in wl_output.transform. Clients
> + willing to retrieve the output size in the global compositor
> + space should use xdg_output.logical_size instead.
> +
> + Note: this information is not always meaningful for all
> outputs. Some
> + compositors, such as those exposing virtual outputs, might
> fake the
> + refresh rate or the size.
>
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCHv3] Add name event to xdg-output

[Philipp Kerling]

Hi,

maybe I missed it at some point in the discussion (sorry if that is the
case), but what is your use case for the "name?" What are clients
expected to use it for?
The description mentions "similar behaviors", but it is unclear to me
what you are referring to.

Regards,
Philipp

2018-04-10 (火) の 20:27 -0400 に Drew DeVault さんは書きました:
> Signed-off-by: Drew DeVault 
> Reviewed-by: Simon Ser 
> ---
> This version clarifies the uniqueness constraint, mapping of names to
> wl_outputs, and persistence between sessions.
> 
>  .../xdg-output/xdg-output-unstable-v1.xml | 19
> ++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml
> b/unstable/xdg-output/xdg-output-unstable-v1.xml
> index 0c0c481..b46c9df 100644
> --- a/unstable/xdg-output/xdg-output-unstable-v1.xml
> +++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
> @@ -77,7 +77,7 @@
>  
>
>  
> -  
> +  
>  
>An xdg_output describes part of the compositor geometry.
>  
> @@ -157,5 +157,22 @@
>
>  
>  
> +
> +  
> +Many compositors will assign names to their outputs, show them
> to the user,
> +allow them to be configured by name, etc. The client may wish to
> know this
> +name as well to offer the user similar behaviors.
> +
> +The naming convention is compositor defined. Each name is unique
> among all
> +wl_output globals, but if a wl_output global is destroyed the
> same name may
> +be reused later. The names will also remain consistent across
> sessions with
> +the same hardware and software configuration.
> +
> +The name event is sent after creating an xdg_output (see
> +xdg_output_manager.get_xdg_output).
> +  
> +  
> +
> +
>
>  
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCHv2] Add name event to xdg-output

[Philipp Kerling]

Hey,

I'll just reiterate one point from the prior discussion.

> On Mon, 9 Apr 2018 08:13:15 -0400
> Drew DeVault  wrote:
> 
> > Good feedback.
> > 
> > On 2018-04-09 11:09 AM, Pekka Paalanen wrote:
> > > Does this name correspond to the physical connector or to the
> > > specific
> > > monitor connected? Or some abstract "output" concept, see the
> > > next
> > > paragraph about clone mode.  
> > 
> > Doesn't matter, whatever the compositor wants. Should be unique to
> > each
> > wl_output.
> 
> If it is unique to each wl_output, then it is referring to either a
> connector or a monitor, ok.
> 
> > > [...] Would xdg_outputs for the cloned wl_outputs report
> > > identical
> > > names to signify they in fact always show the exact same image?  
> > 
> > No.
> 
> This is consistent with the above, good.
> 
> > > Is this name intended to be stable and persistent, so that
> > > applications
> > > can expect to save it in a config and find the same one later,
> > > after a
> > > machine reboot, at least if the configuration of that output has
> > > not
> > > changed and the compositor is still the same version?  
> > 
> > Yes.
> 
> But if it is undefined whether the name refers to a connector or a
> monitor, would that not cause problems for apps to decide how to use
> it?
> 
> If a user unplugs one monitor and then plugs in a different monitor
> to
> the same connector, should the name change or stay the same?
> 
> If the name is defined to stay the same, the app can look at
> wl_output
> make/model to see if the monitor is different.
No, this does not work. Having multiple instances of the same make and
model is common in desktop multi-monitor setups. The app has no option
to recognize specific ones as long as there is no serial number or
other additional identifier involved that is not currently part of the
wl_output and xdg_output info.

> If the name is defined
> to change, then apps cannot target a specific connector. It obviously
> depends on apps or even users what they actually want.
> 
> If it is undefined, or if the name is defined to change in that case,
> then there is no way to reliably target a connector. Is this
> acceptable?
> 
> I would be interested too hear if you can think of why it should not
> be
> specified to refer to a connector specifically, because off-hand I
> can't imagine any reason.
> 
> Even if the name refers to a connector, a compositor could name it as
> it wishes.
> 
> > > The name is arbitrary, right? No standardization is inteneded?
> > > I.e.
> > > switching compositors will likely result in different names.  
> > 
> > Aye. Some compositors might find it useful to follow an informal
> > standard, though, like all wlroots-based compositors use consistent
> > names (e.g. DP-1).
> 
> Yeah, standardising on names would be difficult to write down right
> now.
> 
> > > Is the name enough, would you perhaps want to have a human-
> > > readable
> > > description string as well? Perhaps something for a user to
> > > totally
> > > customize and more verbose than just a name?  
> > 
> > Eh, I'm not a fan of this idea.
> 
> Very good.
> 
> > 
> > > I think it would be good to explicitly answer most of these
> > > questions
> > > in the spec, even if "configured by name" does imply some
> > > answers.  
> > 
> > Yep, will send a v3 answering some of these.
> 
> Cool.
> 
> 
> 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 00/25] A new touchscreen calibrator

[Philipp Kerling]

> Do you happen to know of a good readymade program that fakes the
> presence of a touch input device with uinput? I'd love to test this
> series, but current Weston is far ahead of what my embedded devices
> will do; so I'm in the position of mostly relying on the desktop for
> testing. 
I'm not sure whether it fits your use case, but you can give mtemu a
spin.

https://gitlab.com/shul/mtemu


> On Fri, Mar 23, 2018, 09:38 Matt Hoosier 
> wrote:
> > On Fri, Mar 23, 2018 at 9:30 AM, Pekka Paalanen  > m> wrote:
> > > On Fri, 23 Mar 2018 08:46:46 -0500
> > > Matt Hoosier  wrote:
> > >
> > >> I am very much in favor of the overall approach on this patch
> > series.
> > >> I've experienced every single one of the problems described in
> > this
> > >> summary, and my company currently resorts to maintaining a hacky
> > >> out-of-tree calibration tool to paper over these problems.
> > >
> > > Hi Matt,
> > >
> > > that is very heartwarming to hear. Is your tool specifically for
> > Weston
> > > too?
> > 
> > Yes and no. It's not phrased as a patch against the Weston source
> > code, but it uses heuristics for determining which output the raw
> > /dev/input/* events should be correlated against, and those
> > heuristics
> > probably would fail if some different compositor happened to be
> > running.
> > 
> > >
> > > I would be very happy if this proposal fits your needs, and
> > certainly
> > > interested in hearing where it falls short.
> > >
> > >
> > > Thanks,
> > > pq
> > >
> > >> On Fri, Mar 23, 2018 at 7:00 AM, Pekka Paalanen  > .com> wrote:
> > >> > From: Pekka Paalanen 
> > >> >
> > >> > Hi all,
> > >> >
> > >> > the existing touchscreen calibrator in Weston has several
> > problems. This
> > >> > proposal intends to solve them all by introducing a new
> > protocol
> > >> > extension for touchscreen calibration and a new calibrator
> > tool.
> > >> >
> > >> > The benefits of the new tool, which the old tool lacks, are:
> > >> >
> > >> > - You can unambiguously pick a physical touch device to
> > calibrate.
> > >> >
> > >> > - You can be sure your touch events come only from that
> > particular
> > >> >   device, and that you cannot miss touch events even if the
> > current
> > >> >   calibration is horribly wrong.
> > >> >
> > >> > - You can be sure the calibration window (pattern) is shown on
> > the right
> > >> >   output with the right coordinates.
> > >> >
> > >> > - You can unambiguously calibrate even multiple touchscreens
> > that are
> > >> >   all cloned (showing the same image).
> > >> >
> > >> > - You get a libinput style calibation matrix instead of the
> > >> >   WL_CALIBRATION format which depends on output resolution.
> > >> >
> > >> > - You can load a new calibration into the compositor without
> > playing
> > >> >   tricks with udev or restarting the compositor.
> > >> >
> > >> > There is more discussion about the topic at:
> > >> > https://phabricator.freedesktop.org/T7868
> > >> >
> > >> > This patch series depends on the clone mode series:
> > >> > https://patchwork.freedesktop.org/series/32898/
> > >> >
> > >> > There is a full branch available at:
> > >> > https://gitlab.collabora.com/pq/weston/commits/touchcalib-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

[RFC weston v2] libweston: Commit subsurfaces before committing root surface

[Philipp Kerling]

Committing the root surface triggers a commit of the xdg_surface state,
which might require the subsurface state already being applied (e.g.
when an xdg_toplevel needs to follow size constraints, the subsurfaces
must be in the right position and size at the time this is verified).
---
 libweston/compositor.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index aec937bb..8589e390 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -3191,12 +3191,12 @@ surface_commit(struct wl_client *client, struct 
wl_resource *resource)
return;
}
 
-   weston_surface_commit(surface);
-
wl_list_for_each(sub, >subsurface_list, parent_link) {
if (sub->surface != surface)
weston_subsurface_parent_commit(sub, 0);
}
+
+   weston_surface_commit(surface);
 }
 
 static void
-- 
2.16.2

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

Re: [RFC weston] libweston: Do not include subsurfaces with NULL buffer in bounding box

[Philipp Kerling]

Hi,

thanks for resurrecting this :-) reply below

2017-12-04 (月) の 21:37 + に Daniel Stone さんは書きました:
> Hi Philipp,
> 
> On 28 July 2017 at 15:41, Philipp Kerling <pkerl...@casix.org> wrote:
> > I was pondering how to remove the window decorations of my
> > application
> > (which live in subsurfaces) when going full screen without
> > flickering.
> > 
> > At first I just destroyed the surfaces, but that lead to flicker
> > (window without decoration will appear for one frame before the
> > full
> > screen application is displayed) since subsurface destruction is
> > not
> > specified to be synchronized to the commit of the main surface.
> > 
> > Then I tried attaching a NULL wl_buffer to the surfaces. This works
> > and
> > does not flicker, but it has the problem that weston will
> > disconnect my
> > application when going to full screen for violating the configured
> > xdg_shell buffer size. The reason seems to be that attaching a NULL
> > wl_buffer does not reset the surface size and
> > weston_surface_get_bounding_box still thinks that the surface has
> > the
> > prior size.
> > 
> > The patch fixes this by checking explicitly for the buffer and is
> > confirmed to fix the issue, but I am not sure whether this is the
> > right
> > solution. Maybe surface->width and surface->height should be set to
> > 0
> > anyway?
> 
> Hm. Yes, it does seem like the width/height should be 0, which is
> undefined but not disallowed by the subsurface spec. I have no idea
> if
> this would work with Mutter in particular, which had problems
> implementing that for top-levels.
> 
> In any case, perhaps one way you could do it would be to stack the
> decoration subsurfaces below your primary surface before committing
> your fullscreen buffer. It's ugly, but does seem like it should work
> ...
I already did solve the problem for my application by attaching a NULL
buffer and explicitly setting the window geometry on my xdg toplevel -
then the bounding box calculation code in weston is not executed (think
that was discussed in IRC).
Still, it would be nice to get this right in weston, which is what the
patch was about.

With "setting width/height to 0" I was referring to the variables in
the weston code (subsurface->surface->width and ...->height), which I
think may be better set to 0 if no buffer is attached to the
subsurface. Currently, they seem to retain the size of the last
attached buffer if you attach a NULL buffer.

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

[PATCH weston] gl-renderer: Fix crash in dmabuf format query for fallback formats

[Philipp Kerling]

Since formats is an out parameter, we need to copy to the alloc'ed
memory and not over the pointer address.

Signed-off-by: Philipp Kerling <pkerl...@casix.org>
---
 libweston/gl-renderer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index 371e06b3..d091d165 100644
--- a/libweston/gl-renderer.c
+++ b/libweston/gl-renderer.c
@@ -2122,7 +2122,7 @@ gl_renderer_query_dmabuf_formats(struct weston_compositor 
*wc,
}
 
if (fallback) {
-   memcpy(formats, fallback_formats, num * sizeof(int));
+   memcpy(*formats, fallback_formats, num * sizeof(int));
*num_formats = num;
return;
}
-- 
2.16.1

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

[PATCH wayland] doc: Document behavior of non-nullable object arguments in clients

[Philipp Kerling]

---
 src/wayland-util.h | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/src/wayland-util.h b/src/wayland-util.h
index caeac82..b6cbe0e 100644
--- a/src/wayland-util.h
+++ b/src/wayland-util.h
@@ -78,12 +78,23 @@ extern "C" {
  * wl_message is to a protocol message like a class is to an object.
  *
  * The `name` of a wl_message is the name of the corresponding protocol 
message.
+ *
  * The `signature` is an ordered list of symbols representing the data types
  * of message arguments and, optionally, a protocol version and indicators for
  * nullability. A leading integer in the `signature` indicates the _since_
  * version of the protocol message. A `?` preceding a data type symbol 
indicates
- * that the following argument type is nullable. When no arguments accompany a
- * message, `signature` is an empty string.
+ * that the following argument type is nullable. While it is a protocol 
violation
+ * to send messages with non-nullable arguments set to `NULL`, event handlers 
in
+ * clients might still get called with non-nullable object arguments set to
+ * `NULL`. This can happen when the client destroyed the object being used as
+ * argument on its side and an event referencing that object was sent before 
the
+ * server knew about its destruction. As this race cannot be prevented, clients
+ * should - as a general rule - program their event handlers such that they can
+ * handle object arguments declared non-nullable being `NULL` gracefully.
+ *
+ * When no arguments accompany a message, `signature` is an empty string.
+ *
+ * Symbols:
  *
  * * `i`: int
  * * `u`: uint
-- 
2.15.1

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

[PATCH wayland 2/2] server: Send differentiated errors on wl_registry.bind

[Philipp Kerling]

This now uses the new error codes introduced to wl_registry instead
of abusing WL_DISPLAY_ERROR_INVALID_OBJECT.
---
 src/wayland-server.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/wayland-server.c b/src/wayland-server.c
index 7225b4e..e33af62 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -882,21 +882,21 @@ registry_bind(struct wl_client *client,
 
if (>link == >global_list)
wl_resource_post_error(resource,
-  WL_DISPLAY_ERROR_INVALID_OBJECT,
+  WL_REGISTRY_ERROR_INVALID_GLOBAL,
   "invalid global %s (%d)", interface, 
name);
else if (version == 0)
wl_resource_post_error(resource,
-  WL_DISPLAY_ERROR_INVALID_OBJECT,
+  WL_REGISTRY_ERROR_INVALID_VERSION,
   "invalid version for global %s (%d): 0 
is not a valid version",
   interface, name);
else if (global->version < version)
wl_resource_post_error(resource,
-  WL_DISPLAY_ERROR_INVALID_OBJECT,
+  WL_REGISTRY_ERROR_INCOMPATIBLE_VERSION,
   "invalid version for global %s (%d): 
have %d, wanted %d",
   interface, name, global->version, 
version);
else if (!wl_global_is_visible(client, global))
wl_resource_post_error(resource,
-  WL_DISPLAY_ERROR_INVALID_OBJECT,
+  WL_REGISTRY_ERROR_INVALID_GLOBAL,
   "invalid global %s (%d)", interface, 
name);
else
global->bind(client, global->data, version, id);
-- 
2.15.1

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

[PATCH wayland 1/2] protocol: Add error enum to wl_registry

[Philipp Kerling]

As an oversight, wl_registry did not define any errors. At least error 0
is already being sent by libwayland-server although it is - strictly
speaking - undefined.

Define error 0 to be an invalid global which is also a sort of catch-all
error code. Errors 1 (invalid version) and 2 (incompatible version) can
provide further insight into the reason the bind failed and might be
useful for test-suites.
---
 protocol/wayland.xml | 9 +
 1 file changed, 9 insertions(+)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index b5662e0..55a8c6f 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -132,6 +132,15 @@
   the object.
 
 
+
+  
+   These errors can be emitted in response to wl_registry requests.
+  
+  
+  
+  
+
+
 
   
Binds a new, client-created object to the server using the
-- 
2.15.1

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

Re: Wayland talk at FOSDEM

[Philipp Kerling]

Hi Pekka,

2017-12-07 (木) の 09:56 +0200 に Pekka Paalanen さんは書きました:
> On Tue, 05 Dec 2017 16:46:41 +0200
> Philipp Kerling <pkerl...@casix.org> wrote:
> 
> > Hey everyone,
> > 
> > I've been thinking about submitting a Wayland-themed talk to the
> > FOSDEM
> > graphics devroom [1] and wanted to check with the community if
> > anyone
> > else has considered this or another Wayland topic and whether you
> > think
> > it would be a good idea™.
> > 
> > What I would want to talk about is a beginner's introduction to
> > Wayland
> > from the client perspective. I think that resources on this (and on
> > Wayland in general to be honest) are quite scarce and that I could
> > pass
> > on some of the knowledge I have gained by implementing native
> > Wayland
> > support in Kodi this way.
> 
> Hi,
> 
> that sounds like a good idea.
Thanks!

> 
> > This would include stuff such as:
> >  * Wayland architecture
> > * Comparison with X
> > * Security architecture
> > * Limitations: What is not possible with Wayland (currently)
> 
> Please underline that many things are wanted and the only reason they
> are not there yet is because they have not been worked on enough to
> produce a Waylandish solution and reach a concensus, not because they
> are somehow "banned". :-)
Good point since you hear from time to time that Wayland "forbids"
this-and-that and therefore is evil ... I'll definitely keep it in
mind. Even so, I guess it is a quite safe bet to e.g. say that
accessing the buffer contents of all other applications without any
user authentication will not be a feature of mainstream Wayland
compositors anytime soon.

> In some cases, the Waylandish solution to produce an end-user feature
> may be very different from what has traditionally been done. In some
> other cases, a solution might be better or already exist outside of
> Wayland.
Yes, the problem lies mostly in the expectation that things will work
just like they did with X.

> 
> > * Difference between core and extension protocols
> 
> This is a bit hazy to me as well, depending on at what level you are
> looking to use Wayland. Only wl_display, wl_registry and wl_callback
> interfaces are not extensions, strictly speaking. What extensions are
> mandatory depends on the target environment. Technically, e.g.
> wl_compositor is an extension and not mandatory, but it's hard to
> find
> a use case without it.
I'd have argued that the wayland.xml shipped with wayland is the "core"
protocol and wayland-protocols + all other stuff are "extensions." Is
that a reasonable assumption or should I be more careful about the
wording here? In any case, I guess it makes sense to mention that
Wayland is not only built for traditional desktop environments, even if
that is what I'll be focusing on in the talk.

> So it kind of depends on your definition of "Wayland". Purely IPC? A
> graphical output protocol? A windowing protocol with input? A desktop
> window system protocol?
> 
> Maybe giving a definition for "Wayland" would be a good way to start?
Is there an officially accepted one? :-)
My personal stance would be: Windowing protocol definition + ecosystem
(C libraries, scanner, extension protocols that among other things
cover the traditional desktop use case)

> > * Global registry
> > * Relevant documentation and resources
> >  * Why you should not be writing a Wayland client yourself (aka use
> >toolkits if possible)
> 
> +1
> 
> >  * Relevant compositors to test on and how to use nested mode
> >  * Basic client programming
> > * Protocols needed to get a surface on screen (wl_compositor,
> >   wl_surface, wl_shm, wl_shm_pool, wl_shell, wl_shell_surface)
> 
> Mind that wl_shell is finally officially deprecated with the
> stabilization of xdg-shell.
I'm not sure how to handle that yet. Technically, it would make sense
to directly introduce xdg-shell and skip the wl_shell details. But
realistically speaking it will still take some time until there is
sufficient compositor support and you can get by with an application
that does not support anything but the xdg_wm_base global.
One alternative could be to introduce xdg-shell unstable v6 instead of
wl_shell and tell people to switch to xdg-shell stable at some point?
I'm not sure the latest KDE stable release supports xdg-shell unstable
v6 though. Last time I checked KDE only had v5 in stable.

> > * Seats and input
> >* Keyboard: wl_keyboard and libxkbcommon
> >* Mouse: wl_pointer and libwayland-cursor for cursor
> > handling
> > * xdg_wm_base
> > * Window decora

Re: Wayland talk at FOSDEM

[Philipp Kerling]

Hi,

2017-12-06 (水) の 08:56 +0100 に Silvan Jegen さんは書きました:
> Hi
> 
> On Tue, Dec 5, 2017 at 3:46 PM, Philipp Kerling <pkerl...@casix.org>
> wrote:
> > I've been thinking about submitting a Wayland-themed talk to the
> > FOSDEM
> > graphics devroom [1] and wanted to check with the community if
> > anyone
> > else has considered this or another Wayland topic and whether you
> > think
> > it would be a good idea™.
> > 
> > What I would want to talk about is a beginner's introduction to
> > Wayland
> > from the client perspective. I think that resources on this (and on
> > Wayland in general to be honest) are quite scarce and that I could
> > pass
> > on some of the knowledge I have gained by implementing native
> > Wayland
> > support in Kodi this way.
> > 
> > This would include stuff such as:
> >  * Wayland architecture
> > * Comparison with X
> > * Security architecture
> > * Limitations: What is not possible with Wayland (currently)
> > * Difference between core and extension protocols
> > * Global registry
> > * Relevant documentation and resources
> >  * Why you should not be writing a Wayland client yourself (aka use
> >toolkits if possible)
> >  * Relevant compositors to test on and how to use nested mode
> >  * Basic client programming
> > * Protocols needed to get a surface on screen (wl_compositor,
> >   wl_surface, wl_shm, wl_shm_pool, wl_shell, wl_shell_surface)
> > * Seats and input
> >* Keyboard: wl_keyboard and libxkbcommon
> >* Mouse: wl_pointer and libwayland-cursor for cursor
> > handling
> > * xdg_wm_base
> > * Window decorations
> > * EGL
> 
> I would be very interested in an overview like that and think it's a
> very good idea™ indeed!
Thanks! I've submitted the abstract, let's see if I get a slot.

> I see that you left out the text-input/input-method protocols in your
> topics. Is it because those are unstable or because you don't
> consider
> them to be important enough?
I just hadn't seen them in practice yet personally, to be honest.
Having taken a closer look, I think it would be best to focus on
protocols that have or are expected to have good cross-compositor
support and are useful for general-purpose desktop applications. Is
text-input implemented in a mainstream compositor besides weston?

Regards,
Philipp

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

Re: Wayland talk at FOSDEM

[Philipp Kerling]

Hello Eugen,

2017-12-05 (火) の 22:08 +0100 に Eugen Friedrich さんは書きました:
> Hello Philipp,
> 
> I also thinking give a talk about the usage of weston in ivi systems,
> this should give an overview what is the main difference to the
> desktop environment and why the ivi-shell is used. Also I would like
> to give short overview about the recent activities in ivi-shell and
> usage of waltham.
Nice, I'll be looking forward to that. I always wanted to know more
about how Wayland is actually being used for IVI.

> 2017-12-05 15:46 GMT+01:00 Philipp Kerling <pkerl...@casix.org>:
> > 
> > Hey everyone,
> > 
> > I've been thinking about submitting a Wayland-themed talk to the
> > FOSDEM
> > graphics devroom [1] and wanted to check with the community if
> > anyone
> > else has considered this or another Wayland topic and whether you
> > think
> > it would be a good idea™.
> > 
> > What I would want to talk about is a beginner's introduction to
> > Wayland
> > from the client perspective. I think that resources on this (and on
> > Wayland in general to be honest) are quite scarce and that I could
> > pass
> > on some of the knowledge I have gained by implementing native
> > Wayland
> > support in Kodi this way.
> > 
> > This would include stuff such as:
> >  * Wayland architecture
> > * Comparison with X
> > * Security architecture
> > * Limitations: What is not possible with Wayland (currently)
> > * Difference between core and extension protocols
> > * Global registry
> > * Relevant documentation and resources
> >  * Why you should not be writing a Wayland client yourself (aka use
> >toolkits if possible)
> >  * Relevant compositors to test on and how to use nested mode
> >  * Basic client programming
> > * Protocols needed to get a surface on screen (wl_compositor,
> >   wl_surface, wl_shm, wl_shm_pool, wl_shell, wl_shell_surface)
> > * Seats and input
> >* Keyboard: wl_keyboard and libxkbcommon
> >* Mouse: wl_pointer and libwayland-cursor for cursor
> > handling
> > * xdg_wm_base
> > * Window decorations
> > * EGL
> > 
> > Possible extensions/replacement topics:
> >  * Bindings (just mention: C++, D, Java, Rust)
> >  * Vulkan (I think EGL is more relevant at the moment)
> >  * Some more extension protocols such as pointer-constraints and
> >relative-pointer (relevant e.g. for games)
> >  * Subcompositing
> >  * ...
> 
> just as idea: there are a few patch series which are pending for a
> very long time,
> one of the famous one is the atomic mode setting patch series from
> Daniel :-)
> maybe it would be interesting to give a short overview of the "cool"
> pending feature
> on the list which people can expect in next or over next release.
I thought that I'd just introduce the common/important compositors
(weston, mutter, KWin, sway maybe?) briefly. But I'll have to say a few
words about weston in particular anyway since it is the reference
compositor, so it could very well fit there.

Regards,
Philipp

> > 
> > I would not include:
> >  * Details of libwayland API (e.g. proxy wrappers)
> >  * Every extension protocol or even core protocol object just for
> >completeness
> >  * Historical baggage such as xdg_shell v5
> >  * EGL/Mesa internals
> > 
> > I'd love to hear any comments/suggestions you might have and
> > generally
> > what kind of topics people would be interested in.
> > 
> > [1] https://lists.freedesktop.org/archives/wayland-devel/2017-Novem
> > ber/035880.html
> > 
> > Regards,
> > Philipp
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Wayland talk at FOSDEM

[Philipp Kerling]

Hey everyone,

I've been thinking about submitting a Wayland-themed talk to the FOSDEM
graphics devroom [1] and wanted to check with the community if anyone
else has considered this or another Wayland topic and whether you think
it would be a good idea™.

What I would want to talk about is a beginner's introduction to Wayland
from the client perspective. I think that resources on this (and on
Wayland in general to be honest) are quite scarce and that I could pass
on some of the knowledge I have gained by implementing native Wayland
support in Kodi this way.

This would include stuff such as:
 * Wayland architecture
* Comparison with X
* Security architecture
* Limitations: What is not possible with Wayland (currently)
* Difference between core and extension protocols
* Global registry
* Relevant documentation and resources
 * Why you should not be writing a Wayland client yourself (aka use
   toolkits if possible)
 * Relevant compositors to test on and how to use nested mode
 * Basic client programming
* Protocols needed to get a surface on screen (wl_compositor,
  wl_surface, wl_shm, wl_shm_pool, wl_shell, wl_shell_surface)
* Seats and input
   * Keyboard: wl_keyboard and libxkbcommon
   * Mouse: wl_pointer and libwayland-cursor for cursor handling
* xdg_wm_base
* Window decorations
* EGL

Possible extensions/replacement topics:
 * Bindings (just mention: C++, D, Java, Rust)
 * Vulkan (I think EGL is more relevant at the moment)
 * Some more extension protocols such as pointer-constraints and
   relative-pointer (relevant e.g. for games)
 * Subcompositing
 * ...

I would not include:
 * Details of libwayland API (e.g. proxy wrappers)
 * Every extension protocol or even core protocol object just for
   completeness
 * Historical baggage such as xdg_shell v5
 * EGL/Mesa internals

I'd love to hear any comments/suggestions you might have and generally
what kind of topics people would be interested in.

[1] 
https://lists.freedesktop.org/archives/wayland-devel/2017-November/035880.html

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

Re: Who generate the headers?

[Philipp Kerling]

Hi,

2017-12-02 (土) の 06:05 -0500 に ferreiradaselva さんは書きました:
> Hello, everyone
> 
> I'm still learning how the distribution to the access of the API
> works. I'm making a library like GLFW/SDL2 with Wayland as one of the
> backends.
> 
> I have in my system `/usr/include` the headers of my interest
> `wayland-client-protocol.h` and `wayland-client.h`. However, the
> protocols header doesn't have the XDG Shell API, since it's just
> recently declared stable.
I think there is a fundamental misunderstanding here: wayland-client-
protocol.h only includes the Wayland core protocol, which XDG Shell is
not part of. All other more-or-less-standardized stuff is in wayland-
protocols, which is separate. XDG Shell will (presumably) never be
available in wayland-client-protocol.h, also in future versions.

Only the protocol XML files are installed as part of wayland-protocols
(to /usr/share/wayland-protocols or similar). If you want to use them
in your application, you will have to call wayland-scanner and generate
the header and code files yourself (see below).

> The questions:
> 
> 1. If I wanted to have access to the unstable features (could be any,
> like XDG output, tablet, text input), could I generate the headers
> myself and I would have access to them by just linking my sources
> with `-lwayland-client`?
You have to generate the headers yourself if what you want to use is
not part of the core protocol, no matter whether the extension protocol
is stable or unstable. You also have to generate the code. Linking with
wayland-client is not enough as it also only contains the core protocol
symbols.

> 2. Is there some header generator available, anywhere, that is
> recommended?
wayland-scanner is part of core wayland. You hvae to generate the
"client-header" (.h) and "code" (.c) parts out of the XML(s) you want
to use.

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

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

[Philipp Kerling]

Hi,

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

Best regards,
Philipp


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

Re: [wayland + ILM] proxy wrappers usage of wayland 1.11.0 to 1.9.0

[Philipp Kerling]

Hi,

2017-08-21 (月) の 11:05 +0530 に Vikas Patil さんは書きました:
> Thanks a lot Philipp for your comments, it really helped. Now I get
> the display correctly. However now I get the segmentation at
> different
> location with my uses case [1] after back porting patches from
> wayland
> 1.11.0 to 1.9.0 and and also utilizing proxy wrappers in ILM control
> library.
> 
> (gdb) bt
> #0  0x68d11554 in wl_array_copy (array=0x67d2eb98, source=0x1) at
> /usr/src/debug/wayland/1.9.0-r0/wayland-1.9.0/src/wayland-util.c:145
> #1  0x in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt
> stack?)
I don't think anyone will be able to help you with this backtrace as
you can't see what's happening at all. You will first have to try to
determine where exactly and for what reason the erroneous call to
wl_array_copy (second parameter is clearly invalid) happens.

- Philipp

> 
> [1] https://lists.freedesktop.org/archives/wayland-devel/2017-August/
> 
> Thanks & Regards,
> Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [wayland + ILM] proxy wrappers usage of wayland 1.11.0 to 1.9.0

[Philipp Kerling]

Hi,

Am Freitag, den 18.08.2017, 18:35 +0530 schrieb Vikas Patil:
> Dear All,
> 
> 
> I have backported following patches from wayland 1.11.0 to 1.9.0 to
> test one crash issue [1] . I am able to backport and start Weston
> with
> it. Is this valid thing to do?
> 
> 
> https://cgit.freedesktop.org/wayland/wayland/commit/?id=6d29c0da3cd16
> 8e08187cd204d2314188479c0f1
> [client: Introduce proxy wrappers]
> 
> https://cgit.freedesktop.org/wayland/wayland/commit/?id=6fe12f02e3b48
> 79cd3d5faa08f023cc761d13be9
> [client: Fix wl_display_roundtrip_queue() race condition]
> 
> https://cgit.freedesktop.org/wayland/wayland/commit/?id=69ec70fb0d3f7
> 5f4bcce449238d6297f6a986b5f
> [tests/queue-test: Add tests for proxy wrappers] -- not required.
> 
> 
> 
> Now If I understand it correctly I need to use/modify code where the
> wayland client creates the proxy and sets the queue. One such
> components is [2] ILM control library. I tried to do as per the
> patches but with it nothing is coming on display even though weston
> starts successfully with ivi-shell and ivi-controller.so.
> 
> 
> Attached here the modified file. I would like to understand if the
> way I used is correct or not? Could someone explain this fix and How
> to use it properly for ILM control library? Do I need to add similar
> fix in qtwayland  5.5.1 and other such components (e.g. wayland sink
> from gstreamer) ?
I think there are some problems judging by a quick look at your file:
 * You create a wrapper for the wl_display, but then call
   wl_display_get_registry on your original display. You need to use
   the wrapped display here.
 * Consequently, you must set the queue on the wl_display wrapper
   before that so it correctly gets inherited to the wl_registry.
 * I don't understand what you use wl_display_sync for. You do know
   that wl_display_roundtrip_queue uses that implicitly?
 * You must add the registry listener immediately after creating it and
   not dispatch any events (on the queue the registry uses) in between.
   Otherwise they will get lost.

You might want to take a look at how other libraries use the API, e.g.
https://github.com/01org/libva/blob/master/va/wayland/va_wayland_drm.c#L251

If other libraries you use also operate on global objects in a thread-
unsafe way (i.e. they are not using proxy wrappers *and* you cannot
guarantee that the main queue will not be dispatched in parallel) then
you will have to patch them.

Regards
Philipp


> 
> [1] https://lists.freedesktop.org/archives/wayland-devel/2017-August/
> 034784.html
> 
> [2] https://github.com/GENIVI/wayland-ivi-extension/blob/1.9.1/ivi-la
> yermanagement-api/ilmControl/src/ilm_control_wayland_platform.c
> (function: init_control(),  line: 1260 )
> 
> 
> Thanking you in advance for your time and comments.
> 
> 
> 
> Thanks & Regards,
> 
> Vikash
> ___
> 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: Add serial to wl_output::geometry?

[Philipp Kerling]

Hi,

Am Freitag, den 18.08.2017, 10:47 +0300 schrieb Pekka Paalanen:
> On Thu, 03 Aug 2017 08:27:06 -0400
> Simon Ser  wrote:
> 
> > Hello,
> > I'm writing a Wayland client that needs to keep track of screens
> > across reboots. I registered a wl_output::geometry event handler.
> > This event already has the fields "make" and "model", but is
> > missing
> > "serial". Is there a way to get an output serial (something like
> > "HS3P505873")? Would it be possible to add it to the protocol or is
> > it too late? Is there another way to identify screens?
> 
> Hi Simon,
> 
> these are very good questions. I have a vague recollection this has
> been discussed before on wayland-devel@, but personally I may have
> been
> skeptical about the use cases at the time.
For reference: 
https://lists.freedesktop.org/archives/wayland-devel/2017-May/034083.html 
A lot of points were discussed back then already.

> Anyway, nowadays I think adding the physical monitor serial to
> wl_output as a new event should be fine. There are some details to
> discuss like if the monitor hardware does not provide a reliable
> serial, should the compositor maybe manufacture some GUID or just
> leave
> the serial unset. What about "monitors" that are not physical
> devices,
> like a window in another window system - should one relay the serial
> from the other window system's monitor, manufacture an artificial
> GUID
> based on e.g. window system connection, or just not send a serial at
> all.
You could argue that similar concerns apply to "make" and "model", but
they only have a very vague description in the protocol.

> Maybe it would be best to just say the serial is from a locally
> connected monitor hardware (or equivalent), and leave the cases where
> the hardware serial is not available or the output is not a local
> physical monitor to not send a serial.
Also needs to be discussed whether the values should be compatible
accross compositors (e.g. make and model are not currently because of
their vague definition).

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

[RFC weston] libweston: Do not include subsurfaces with NULL buffer in bounding box

[Philipp Kerling]

I was pondering how to remove the window decorations of my application
(which live in subsurfaces) when going full screen without flickering.

At first I just destroyed the surfaces, but that lead to flicker
(window without decoration will appear for one frame before the full
screen application is displayed) since subsurface destruction is not
specified to be synchronized to the commit of the main surface.

Then I tried attaching a NULL wl_buffer to the surfaces. This works and
does not flicker, but it has the problem that weston will disconnect my
application when going to full screen for violating the configured
xdg_shell buffer size. The reason seems to be that attaching a NULL
wl_buffer does not reset the surface size and
weston_surface_get_bounding_box still thinks that the surface has the
prior size.

The patch fixes this by checking explicitly for the buffer and is
confirmed to fix the issue, but I am not sure whether this is the right
solution. Maybe surface->width and surface->height should be set to 0
anyway?

---
 libweston/compositor.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index 813b6634..747c5ebc 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -3621,11 +3621,16 @@ weston_surface_get_bounding_box(struct weston_surface 
*surface)
  surface->width, surface->height);
 
wl_list_for_each(subsurface, >subsurface_list, parent_link)
-   pixman_region32_union_rect(, ,
-  subsurface->position.x,
-  subsurface->position.y,
-  subsurface->surface->width,
-  subsurface->surface->height);
+   {
+   if (subsurface->surface->buffer_ref.buffer)
+   {
+   pixman_region32_union_rect(, ,
+  subsurface->position.x,
+  subsurface->position.y,
+  subsurface->surface->width,
+  subsurface->surface->height);
+   }
+   }
 
box = pixman_region32_extents();
struct weston_geometry geometry = {
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] desktop-shell: Set surface resizing state during interactive resize

[Philipp Kerling]

xdg_shell requires this information to be shared with the client in
order to conform with the specification.

The code to forward this to the client by way of a configure() event
is already in place and works fine, it was just never being used until
now.

Signed-off-by: Philipp Kerling <pkerl...@casix.org>
---
 desktop-shell/shell.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 4608cf2f..f0b76352 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -1638,6 +1638,8 @@ resize_grab_button(struct weston_pointer_grab *grab,
 
if (pointer->button_count == 0 &&
state == WL_POINTER_BUTTON_STATE_RELEASED) {
+   weston_desktop_surface_set_resizing(
+   resize->base.shsurf->desktop_surface, false);
shell_grab_end(>base);
free(grab);
}
@@ -1648,6 +1650,8 @@ resize_grab_cancel(struct weston_pointer_grab *grab)
 {
struct weston_resize_grab *resize = (struct weston_resize_grab *) grab;
 
+   
weston_desktop_surface_set_resizing(resize->base.shsurf->desktop_surface,
+   false);
shell_grab_end(>base);
free(grab);
 }
@@ -1731,6 +1735,7 @@ surface_resize(struct shell_surface *shsurf,
resize->height = geometry.height;
 
shsurf->resize_edges = edges;
+   weston_desktop_surface_set_resizing(shsurf->desktop_surface, true);
shell_grab_start(>base, _grab_interface, shsurf,
 pointer, edges);
 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] libweston-desktop/xdg-shell: Check window geometry instead of surface size against configured size

[Philipp Kerling]

Shell surfaces may have a geometry that is different to the size of
their main surface, e.g. due to subcompositing.

In states where size is strictly enforced (fullscreen and maximized),
the size that the compositor wants must be checked against the window
geometry and not just the main surface size.

Fix by calling weston_desktop_surface_get_geometry and using that size
instead of main surface size.

Signed-off-by: Philipp Kerling <pkerl...@casix.org>
---
 libweston-desktop/xdg-shell-v5.c | 7 +--
 libweston-desktop/xdg-shell-v6.c | 7 +--
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/libweston-desktop/xdg-shell-v5.c b/libweston-desktop/xdg-shell-v5.c
index d7c49b15..3f97cd23 100644
--- a/libweston-desktop/xdg-shell-v5.c
+++ b/libweston-desktop/xdg-shell-v5.c
@@ -264,9 +264,12 @@ weston_desktop_xdg_surface_committed(struct 
weston_desktop_surface *dsurface,
weston_desktop_surface_get_surface(surface->surface);
bool reconfigure = false;
 
+   struct weston_geometry geometry =
+   weston_desktop_surface_get_geometry(surface->surface);
+
if (surface->next.state.maximized || surface->next.state.fullscreen)
-   reconfigure = surface->next.size.width != wsurface->width ||
- surface->next.size.height != wsurface->height;
+   reconfigure = surface->next.size.width != geometry.width ||
+ surface->next.size.height != geometry.height;
 
if (reconfigure) {
weston_desktop_xdg_surface_schedule_configure(surface, true);
diff --git a/libweston-desktop/xdg-shell-v6.c b/libweston-desktop/xdg-shell-v6.c
index dda0bf92..1344dda0 100644
--- a/libweston-desktop/xdg-shell-v6.c
+++ b/libweston-desktop/xdg-shell-v6.c
@@ -644,9 +644,12 @@ weston_desktop_xdg_toplevel_committed(struct 
weston_desktop_xdg_toplevel *toplev
if (!wsurface->buffer_ref.buffer)
return;
 
+   struct weston_geometry geometry =
+   
weston_desktop_surface_get_geometry(toplevel->base.desktop_surface);
+
if ((toplevel->next.state.maximized || toplevel->next.state.fullscreen) 
&&
-   (toplevel->next.size.width != wsurface->width ||
-toplevel->next.size.height != wsurface->height)) {
+   (toplevel->next.size.width != geometry.width ||
+toplevel->next.size.height != geometry.height)) {
struct weston_desktop_client *client =

weston_desktop_surface_get_client(toplevel->base.desktop_surface);
struct wl_resource *client_resource =
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] desktop-shell: Track focused shell surface by main surface

[Philipp Kerling]

The focused surface is used for determining whether shell surfaces
are activated. They should also be considered activated when a
subsurface has focus. Inserting a call to
weston_surface_get_main_surface fixes this.

seat->focused_surface is only used for shell_surface keyboard focus
tracking.
---
 desktop-shell/shell.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 832a7b74..4608cf2f 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -1852,7 +1852,7 @@ handle_keyboard_focus(struct wl_listener *listener, void 
*data)
shell_surface_lose_keyboard_focus(shsurf);
}
 
-   seat->focused_surface = keyboard->focus;
+   seat->focused_surface = 
weston_surface_get_main_surface(keyboard->focus);
 
if (seat->focused_surface) {
struct shell_surface *shsurf = 
get_shell_surface(seat->focused_surface);
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v2 02/13] xdg-shell: Rename interfaces

[Philipp Kerling]

Am Freitag, den 30.06.2017, 15:42 +0800 schrieb Jonas Ådahl:
> On Fri, Jun 30, 2017 at 08:48:58AM +0200, Philipp Kerling wrote:
> > Hi,
> > 
> > Am Freitag, den 30.06.2017, 13:50 +0800 schrieb Jonas Ådahl:
> > > Rename the interfaces according to the wayland-protocols policy.
> > > Since
> > > the name 'xdg_shell' as an interface was already taken (by
> > > xdg-shell-unstable-v5) zxdg_shell_v6 was renamed xdg_wm_base. The
> > > surface role related interfaces were not renamed, as naming
> > > collision
> > > is only unmanagable when exposed as globals via the registry.
> > 
> > What about clients that want to support both xdg_shell (unstable
> > v5)
> > and xdg_wm_base? Won't they have a problem with
> >A. clashing type/function/macro names in the header files
> > generated by
> >   wayland-scanner, at least when they are including both
> > headers in
> >   one file?
> >B. clashing interface global names (e.g.
> > "xdg_toplevel_interface") at
> >   link time even when they do not include both headers at the
> > same
> >   time?
> 
> Right. This means you can't have xdg_shell_unstable_v5 at the same
> time
> as xdg_wm_base, without messing around avoiding compiling and linking
> issues.
> 
> Personally I'd rather not support v5 instead of coming up with new
> names
> for everything; it *is* (was) an unstable protocol version and it has
> always been expected that support for it will be removed.
Yes I know, but the situation is that this particular unstable protocol
practically had to be implemented to have a somewhat usable desktop
experience due to the shortcomings of wl_shell.

> Do you know of
> any client out in the wild that still only supports xdg_shell
> unstable
> v5?
I was thinking more of e.g. Qt (or any other toolkit) that supports
wl_shell, xdg_shell unstable v5 and v6 (albeit to a wildly differing
extent sadly) and would now have to drop unstable v5 in order to
support xdg_wm_base. Also, I think both KWin and Qt did only support
unstable v5 until very recently. wl_shell is always available as
fallback though.
Do note that I am not personally opposed to saying that that's the way
it is going to be, I just wanted to point this out since the commit
message was a bit brief on the implications of keeping the interface
names. If you have considered this and decided that people will have to
drop v5 support (compositors as well as clients I presume) if they had
it before, everything is fine by me.

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

Re: [PATCH wayland-protocols v2 02/13] xdg-shell: Rename interfaces

[Philipp Kerling]

Hi,

Am Freitag, den 30.06.2017, 13:50 +0800 schrieb Jonas Ådahl:
> Rename the interfaces according to the wayland-protocols policy.
> Since
> the name 'xdg_shell' as an interface was already taken (by
> xdg-shell-unstable-v5) zxdg_shell_v6 was renamed xdg_wm_base. The
> surface role related interfaces were not renamed, as naming collision
> is only unmanagable when exposed as globals via the registry.
What about clients that want to support both xdg_shell (unstable v5)
and xdg_wm_base? Won't they have a problem with
   A. clashing type/function/macro names in the header files generated by
  wayland-scanner, at least when they are including both headers in
  one file?
   B. clashing interface global names (e.g. "xdg_toplevel_interface") at
  link time even when they do not include both headers at the same
  time?

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

[PATCH] extras: Update status for Kodi

[Philipp Kerling]

Wayland integration in Kodi was accepted as Google Summer of Code
Project. It is already on-par with the prior implementation
feature-wise.

Sorting is in reverse chronological order because usually people are
most interested in the current state of affairs.

Also fixes broken link that ended with >a>.
---
 extras.html | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/extras.html b/extras.html
index b590899..fe7f555 100644
--- a/extras.html
+++ b/extras.html
@@ -34,14 +34,20 @@ Java bindings by Jason Ekstrand's
 
 
 
-XBMC Media Center
+Kodi (formerly XBMC)
 
 
 
-http://smspillaz.wordpress.com/2013/02/27/hello-from-xbmc-on-wayland/;>Initial
 announcement (2013)
+https://github.com/pkerling/xbmc/;>Wayland integration as Google 
Summer of Code project (2017)
+
+
+Previously:
 
 
-https://www.phoronix.com/scan.php?page=news_item=Kodi-Drops-Wayland-For-Now;>Temporarily
 dropped as 'unmaintained' (2016)>a>
+https://www.phoronix.com/scan.php?page=news_item=Kodi-Drops-Wayland-For-Now;>Temporarily
 dropped as 'unmaintained' (2016)
+
+
+http://smspillaz.wordpress.com/2013/02/27/hello-from-xbmc-on-wayland/;>Initial
 announcement (2013)
 
 
 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: wl_output ambiguity, xdg_shell fullscreen refresh rate

[Philipp Kerling]

Am Dienstag, den 16.05.2017, 12:28 +0300 schrieb Pekka Paalanen:
> On Mon, 15 May 2017 17:31:57 +0200
> Philipp Kerling <pkerl...@casix.org> wrote:
> 2017-05-15 (月) の 11:18 +0300 に Pekka Paalanen さんは書きました:
> > > On Sun, 14 May 2017 14:43:44 +0200
> > > Philipp Kerling <pkerl...@casix.org> wrote:  
> > > > To start off:
> > > >  * Kodi should offer the user the opportunity to select inside
> > > > the
> > > >application on which monitor he/she wants to have Kodi
> > > > displayed
> > > > on
> > > >when in full-screen mode. Now I see that I can do this with
> > > > either
> > > >wl_shell_surface::set_fullscreen and
> > > > zxdg_toplevel::set_fullscreen,
> > > >which expect a wl_output to display the window on. But I am
> > > > not
> > > > sure
> > > >how I should match the wl_output instance I get from Wayland
> > > > with
> > > >the monitor that the user selected. As far as I can see, I
> > > > can
> > > > only
> > > >identify the monitor by way of "make" and "model". This
> > > > seems
> > > >reasonable enough at first glance, but I think that in
> > > > multi-
> > > > monitor 
> > > >configurations it is not so uncommon to buy the same monitor
> > > > model
> > > >multiple times - I personally have done this. Naturally, the
> > > > "make"
> > > >and "model" of both monitors are identical, so I cannot
> > > > discern
> > > >which is which by looking at the wl_output metadata. Am I
> > > > missing
> > > >something here?  
> > > 
> > > That is all true, you are not missing anything.
> > > 
> > > It is a missing piece of protocol - I believe no-one has had both
> > > the
> > > need and the time to work on getting anything better yet.
> > >   
> > > > Why isn't e.g. the connector the output is connected
> > > >to exported?  
> > > 
> > > Because connector names are specific to DRM while Wayland (core
> > > protocol at least) is not.  
> > 
> > I'm not sure I agree. See further below.
> > 
> > > Also, would you not want to identify the
> > > monitor rather than which connector it happens to be plugged
> > > in?   
> > 
> > I think that it's not quite decided yet what we want the user
> > experience to be on the Kodi side, i.e. do we want to bind output
> > to
> > the physical monitor (however it is identified) or the GPU
> > connector?
> > You can probably find use cases for both, so it's not an easy
> > decision
> > to make. With X11 it was limited to the latter, so my first
> > approach
> > was to mimic that. Ideally, both would be possible with Wayland and
> > the
> > application can decide what is best for its specific use case. I
> > realize that this might be too much to ask for all at once, so I'll
> > talk to my mentor to decide which case we want to focus on for
> > Kodi.
> > There are also two different points involved in this discussion:
> >I. How the *user* identifies which output/monitor the fullscreen
> >   display should be on (e.g. with make+model+connector name, or
> > by
> >   compositor-specific numbering).
> >   II. How *Kodi* or any other application then stores this, re-
> > identifies
> >   this output/monitor and maps it to a wl_output on application
> > start
> >   and hotplug. Possiblities include saving information
> > pertaining to
> >   the output, the connector, the physical device, or any
> > combination.
> 
> Hi,
> 
> very much agreed.
> 
> > > Would
> > > a user even know which connector name matches to which monitor?  
> > 
> > Yes, I also thought about this. Tech-savvy users might actually be
> > able
> > to identify the connector name, but you are absolutely right that
> > usually users should not be expected to. In fact, having make and
> > model
> > available actually is an improvement in that regard (on X11, Kodi
> > *only* displays connector since that is what's available via
> > RANDR).
> > So: How do you suggest to identify a particular monitor then? As I
> > said, make and model are not sufficient - but serial number will
> > not
> > help the user in identification. If there are multiple monito

Re: wl_output ambiguity, xdg_shell fullscreen refresh rate

[Philipp Kerling]

Hi,

Am Dienstag, den 16.05.2017, 11:30 +0300 schrieb Pekka Paalanen:
> On Mon, 15 May 2017 17:51:16 +0200
> Philipp Kerling <pkerl...@casix.org> wrote:
> 
> > 2017-05-15 (月) の 12:19 +0200 に Philipp Zabel さんは書きました:
> > > On Mon, 2017-05-15 at 11:18 +0300, Pekka Paalanen wrote:  
> > > > On Sun, 14 May 2017 14:43:44 +0200
> > > > Philipp Kerling <pkerl...@casix.org> wrote:  
> > > > >  * Am I correct in that if I use zxdg_toplevel (i.e. give
> > > > > this
> > > > > role to
> > > > >a surface), I cannot also use wl_shell_surface? If so,
> > > > > this
> > > > > would be  
> > > > 
> > > > Yes. wl_shell and xdg_shell suites of protocol extensions are
> > > > mutually
> > > > exclusive, you cannot use both for the same wl_surface.
> > > > wl_shell is
> > > > the
> > > > deprecated one, and xdg_shell suite is the replacement waiting
> > > > to
> > > > be
> > > > decleared stable.
> > > >   
> > > > >quite a problem. I can see that zxdg_toplevel
> > > > > functionality is
> > > > >mostly superior to that of wl_shell_surface, but it has
> > > > > one
> > > > > omission
> > > > >that is crucial for Kodi: the ability to request a
> > > > > specific
> > > > > refresh
> > > > >rate for fullscreen display. This is needed for closely
> > > > > matching the
> > > > >display and video FPS so duplicated and skipped frames are
> > > > > kept to a
> > > > >minimum. Is this an intentional omission and/or is there
> > > > > anything
> > > > >that provides this functionality?  
> > > > 
> > > > Hopefully the xdg_shell designers would answer that, but I
> > > > believe
> > > > it
> > > > has been omitted for now to make it easier to declare the first
> > > > fundamental parts of xdg_shell stable. It is missing a lot, but
> > > > the
> > > > foundation must agreed upon first before building more on
> > > > top.  
> > > 
> > > Rather than combining the FPS request with fullscreening,
> > > wouldn't it
> > > be
> > > better to let applications set FPS as a property of the surface?
> > > 
> > > That way the client would make a promise that is is going to
> > > update
> > > surface contents with periodic commits of the specified rate,
> > > completely
> > > independent of the actual output hardware or fullscreen state.
> > > 
> > > The server could use that information to choose the best display
> > > refresh
> > > rate even if not in fullscreen mode.  
> > 
> > I would not want my compositor to do that, since changing the
> > refresh
> > rate means that the monitor will go blank for a while while
> > resyncing
> > on most hardware.
> 
> Hi,
> 
> I get the feeling that you are assuming the server would always obey
> the
> client refresh rate. The protocol should not be designed like that.
I actually don't and I think I explicitly stated that in an earlier
email. I know that Wayland has nothing like RANDR (i.e. where every
application can mess around with the output modes as it pleases) on
purpose. Sorry if I gave the impression that this or something similar
is what I'd want.

> Wayland protocol design principle for the desktops is that clients
> describe what they would want to do (and why), and the server
> implements the policy on when and how that actually happens - if at
> all. This is very much the opposite from X11. A typical example is
> input grabs: a client has to provide both the reason (the input event
> they are acting on) and the context (the surface a grab will be tied
> to). The server decides if it grants a grab or not, and if yes, it
> can
> also revoke the grab at any time.
> 
> The reason the framerate was in the fullscreen request in wl_shell is
> that fullscreen offers fairly clear conditions on when the server
> should or could switch the video mode:
> - when the fullscreen window becomes top-most and active, switch
> video
>   mode to the client requested one
> - when the fullscreen window becomes inactive, is hidden, or some
> other
>   top-level window comes on top of it; a condition that is not just
>   transient; switch video mode back to the default one
> - do not switch back to default one for insignificant actions, e.

Re: wl_output ambiguity, xdg_shell fullscreen refresh rate

[Philipp Kerling]

2017-05-15 (月) の 12:19 +0200 に Philipp Zabel さんは書きました:
> On Mon, 2017-05-15 at 11:18 +0300, Pekka Paalanen wrote:
> > On Sun, 14 May 2017 14:43:44 +0200
> > Philipp Kerling <pkerl...@casix.org> wrote:
> > >  * Am I correct in that if I use zxdg_toplevel (i.e. give this
> > > role to
> > >    a surface), I cannot also use wl_shell_surface? If so, this
> > > would be
> > 
> > Yes. wl_shell and xdg_shell suites of protocol extensions are
> > mutually
> > exclusive, you cannot use both for the same wl_surface. wl_shell is
> > the
> > deprecated one, and xdg_shell suite is the replacement waiting to
> > be
> > decleared stable.
> > 
> > >    quite a problem. I can see that zxdg_toplevel functionality is
> > >    mostly superior to that of wl_shell_surface, but it has one
> > > omission
> > >    that is crucial for Kodi: the ability to request a specific
> > > refresh
> > >    rate for fullscreen display. This is needed for closely
> > > matching the
> > >    display and video FPS so duplicated and skipped frames are
> > > kept to a
> > >    minimum. Is this an intentional omission and/or is there
> > > anything
> > >    that provides this functionality?
> > 
> > Hopefully the xdg_shell designers would answer that, but I believe
> > it
> > has been omitted for now to make it easier to declare the first
> > fundamental parts of xdg_shell stable. It is missing a lot, but the
> > foundation must agreed upon first before building more on top.
> 
> Rather than combining the FPS request with fullscreening, wouldn't it
> be
> better to let applications set FPS as a property of the surface?
> 
> That way the client would make a promise that is is going to update
> surface contents with periodic commits of the specified rate,
> completely
> independent of the actual output hardware or fullscreen state.
> 
> The server could use that information to choose the best display
> refresh
> rate even if not in fullscreen mode.
I would not want my compositor to do that, since changing the refresh
rate means that the monitor will go blank for a while while resyncing
on most hardware. Doing this on a regular basis would be very
disturbing. Kodi can get away with it since
 * it only does it when starting to play a video,
 * it only does it in full-screen mode when nothing else is on the
   screen anyway, and
 * it has the option to wait a configurable amount of time before
   starting playback to ensure that the mode switch is complete.
But I can see how this is the more general solution and also supports
the video playback use case. If this operation would include a
recommendation that the compositor should try to closely match the
requested framerate of currently displayed full-screen surfaces to the
vertical refresh rate of the corresponding output, I guess it would be
fine.

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

Re: wl_output ambiguity, xdg_shell fullscreen refresh rate

[Philipp Kerling]

Thanks for your answers! See reply below.

2017-05-15 (月) の 11:18 +0300 に Pekka Paalanen さんは書きました:
> On Sun, 14 May 2017 14:43:44 +0200
> Philipp Kerling <pkerl...@casix.org> wrote:
> > To start off:
> >  * Kodi should offer the user the opportunity to select inside the
> >    application on which monitor he/she wants to have Kodi displayed
> > on
> >    when in full-screen mode. Now I see that I can do this with
> > either
> >    wl_shell_surface::set_fullscreen and
> > zxdg_toplevel::set_fullscreen,
> >    which expect a wl_output to display the window on. But I am not
> > sure
> >    how I should match the wl_output instance I get from Wayland
> > with
> >    the monitor that the user selected. As far as I can see, I can
> > only
> >    identify the monitor by way of "make" and "model". This seems
> >    reasonable enough at first glance, but I think that in multi-
> > monitor 
> >    configurations it is not so uncommon to buy the same monitor
> > model
> >    multiple times - I personally have done this. Naturally, the
> > "make"
> >    and "model" of both monitors are identical, so I cannot discern
> >    which is which by looking at the wl_output metadata. Am I
> > missing
> >    something here?
> 
> That is all true, you are not missing anything.
> 
> It is a missing piece of protocol - I believe no-one has had both the
> need and the time to work on getting anything better yet.
> 
> > Why isn't e.g. the connector the output is connected
> >    to exported?
> 
> Because connector names are specific to DRM while Wayland (core
> protocol at least) is not.
I'm not sure I agree. See further below.

> Also, would you not want to identify the
> monitor rather than which connector it happens to be plugged in? 
I think that it's not quite decided yet what we want the user
experience to be on the Kodi side, i.e. do we want to bind output to
the physical monitor (however it is identified) or the GPU connector?
You can probably find use cases for both, so it's not an easy decision
to make. With X11 it was limited to the latter, so my first approach
was to mimic that. Ideally, both would be possible with Wayland and the
application can decide what is best for its specific use case. I
realize that this might be too much to ask for all at once, so I'll
talk to my mentor to decide which case we want to focus on for Kodi.
There are also two different points involved in this discussion:
   I. How the *user* identifies which output/monitor the fullscreen
  display should be on (e.g. with make+model+connector name, or by
  compositor-specific numbering).
  II. How *Kodi* or any other application then stores this, re-identifies
  this output/monitor and maps it to a wl_output on application start
  and hotplug. Possiblities include saving information pertaining to
  the output, the connector, the physical device, or any combination.

> Would
> a user even know which connector name matches to which monitor?
Yes, I also thought about this. Tech-savvy users might actually be able
to identify the connector name, but you are absolutely right that
usually users should not be expected to. In fact, having make and model
available actually is an improvement in that regard (on X11, Kodi
*only* displays connector since that is what's available via RANDR).
So: How do you suggest to identify a particular monitor then? As I
said, make and model are not sufficient - but serial number will not
help the user in identification. If there are multiple monitors of the
same model, I do not think that they (i.e. the physical devices) can be
reasonably discerned in a way that is transparent to the user. That's
why I suggested the connector name.

> To expose such a name in the protocol, we should define the space or
> meaning of the names. Human-readable? That's not the connector name,
> IMHO. Machine-parseable? Needs a very strict definition to work.
> Both?
RANDR output names (which are somewhat close to what I refer to as
connector names - it's a matter of debate whether output or connector
name would be more fitting for the Kodi use case) are specifically
meant to be "presented to the user", but I can see your point. I think
that machine-parseable is doable, also considering that RANDR did have
a "ConnectorType" property which is probably part of what we'd want
here. 

> A simple numbering with a way in the compositor to identify the
> monitors? Maybe.
What exactly do you mean by "a way in the compositor to identify the
monitors"? Like you can tell the compositor to display the output names
(briefly) on the outputs so the user knows which is which?
If so, couldn't this also be done by the application at least with more