[ANNOUNCE] libinput 1.11.1
libinput 1.11.1 is now available. A small release only with the required fixes to update the various URLs to gitlab. Yes, you read that right, libinput has moved from bugzilla to the freedesktop gitlab instance: http://gitlab.freedesktop.org/libinput/libinput/ In terms of real fixes we only have two: one for the IBM X41 tablet tablet mode (almost vintage computing!) and a fix to avoid external touchpads shutting down when the lid is closed or the tablet mode activates. Two more patches to fix minor bugs. One could have caused a NaN in the trackpoint acceleration code, the other one would somewhat randomly grab the device during libinput debug-events. Daniel Stone (1): doc: Fix URLs for GitLab, HTTPS Peter Hutterer (6): udev: the IBM X41 Tablet must not disable the keyboard in tablet mode filter: cap trackpoint scale factor at 1.0 COPYING: change a cgit to a gitlab URL touchpad: don't pair external touchpads with lid/tablet mode switches tools: fix grab argument passing for libinput debug-events libinput 1.11.1 git tag: 1.11.1 https://www.freedesktop.org/software/libinput/libinput-1.11.1.tar.xz MD5: 4ebf3ceb1d7de9b171050a4a254d85bb libinput-1.11.1.tar.xz SHA1: 22decba7e43b3fb0e76de579e50ef6a53157 libinput-1.11.1.tar.xz SHA256: 642e95aecc7a592c676cde5b4cfda6d2939d2e2f686a8edbbc369808e646f1fc libinput-1.11.1.tar.xz SHA512: 3dd1a318c89d66f5a66016c6dbfa5277b61a8cb5337d99f85b1eeef40ed894bdc04fd4588a97383988daea0f034df5a72bff318325320a01b857db9deb94a2b0 libinput-1.11.1.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.11.1.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] client: Allow send error recovery without an abort
Hi Pekka!
Thank you for the feedback. In the end, I think we have a good basic
agreement about the patch, and after reading your linked bug (
https://gitlab.freedesktop.org/wayland/wayland/issues/12), which I was
previously unaware of, it sounds like I will be just stripping out the
callback+retry case from my patch.
I will probably go ahead and add a function to check for the half-full
output buffer, and one you didn't think of to check whether MAX_FDS_OUT is
about to be exceeded by the next call (that count is small enough to
actually be a concern).
At this point I think the only real question I have is one of checking the
intent behind the bug you filed. Should the design be that ONLY behavior
is to set a fatal error on the display context, or should there be a public
API to select between the previous/default abort and the detal error?
I'll send out a revised patch after hearing back with that bit of guidance.
In case it matters, I did also include my responses to your points inline
below. I don't expect to convince that this patch should be used as is, but
perhaps it will give you or someone else some clarify and insight into why
I suggested the change I did.
Thanks!
- Lloyd
On Mon, Jun 18, 2018 at 4:58 AM Pekka Paalanen wrote:
> On Tue, 5 Jun 2018 18:14:54 -0700
> Lloyd Pique wrote:
>
> > Introduce a new call wl_display_set_error_handler_client(), which allows
> > a client to register a callback function which is invoked if there is an
> > error (possibly transient) while sending messages to the server.
> >
> > This allows a Wayland client that is actually a nested server to try and
> > recover more gracefully from send errors, allowing it one to disconnect
> > and reconnect to the server if necessary.
> >
> > The handler is called with the wl_display and the errno, and is expected
> > to return one of WL_SEND_ERROR_ABORT, WL_SEND_ERROR_FATAL, or
> > WL_SEND_ERROR_RETRY. The core-client code will then respectively abort()
> > the process (the default if no handler is set), set the display context
> > into an error state, or retry the send operation that failed.7
> >
> > The existing display test is extended to exercise the new function.
>
> Hi Lloyd,
>
> technically this looks like a quality submission, thank you for that. I
> am particularly happy to see all the new cases are added into the test
> suite. I agree that calling wl_abort() is nasty and it would be good to
> have something else.
>
> However, I'm not quite convinced of the introduced complexity here.
> More comments inline.
>
> > Signed-off-by: Lloyd Pique
> > ---
> > COPYING | 1 +
> > src/wayland-client-core.h | 75 +
> > src/wayland-client.c | 67 +++-
> > tests/display-test.c | 165 +-
> > 4 files changed, 306 insertions(+), 2 deletions(-)
> >
> > diff --git a/COPYING b/COPYING
> > index eb25a4e..bace5d7 100644
> > --- a/COPYING
> > +++ b/COPYING
> > @@ -2,6 +2,7 @@ Copyright © 2008-2012 Kristian Høgsberg
> > Copyright © 2010-2012 Intel Corporation
> > Copyright © 2011 Benjamin Franzke
> > Copyright © 2012 Collabora, Ltd.
> > +Copyright © 2018 Google LLC
> >
> > Permission is hereby granted, free of charge, to any person obtaining a
> > copy of this software and associated documentation files (the
> "Software"),
> > diff --git a/src/wayland-client-core.h b/src/wayland-client-core.h
> > index 03e781b..a3e4b8e 100644
> > --- a/src/wayland-client-core.h
> > +++ b/src/wayland-client-core.h
> > @@ -257,6 +257,81 @@ wl_display_cancel_read(struct wl_display *display);
> > int
> > wl_display_read_events(struct wl_display *display);
> >
> > +/** \enum wl_send_error_strategy
> > + *
> > + * This enum are the valid values that can be returned from a
> > + * wl_send_error_handler_func_t
> > + *
> > + * \sa wl_send_error_handler_func_t
> > + */
> > +enum wl_send_error_strategy {
> > + /** Abort the client */
> > + WL_SEND_ERROR_ABORT,
> > + /** Put the display into a fatal error state */
> > + WL_SEND_ERROR_FATAL,
> > + /** Retry the send operation */
> > + WL_SEND_ERROR_RETRY,
> > +};
> > +
> > +/**
> > + * \brief A function pointer type for customizing client send error
> handling
> > + *
> > + * A client send error strategy handler is a callback function which
> the client
> > + * can set to direct the core client library how to respond if an error
> is
> > + * encountered while sending a message.
> > + *
> > + * Normally messages are enqueued to an output buffer by the core client
> > + * library, and the user of the core client library is expected to call
> > + * wl_display_flush() occasionally, but as that is non-blocking,
> messages can
> > + * queue up in the output buffer. If later calls to send messages
> happen to
> > + * fill up the output buffer, the core client library will make an
> internal
> > + * call to flush the output buffer. But if the write call unexpectedly
> fails,
> > + * as
Re: [PATCH wayland] doc: update IANA MIME types registry URL
Reviewed-by: Matheus Santana Nice! FTP isn't even working for me (always get unauthorized). On Mon, Jun 18, 2018 at 7:58 AM, Simon Ser wrote: > Use a more official one, served over HTTP rather than FTP. > --- > doc/publican/sources/Protocol.xml | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/doc/publican/sources/Protocol.xml b/doc/publican/sources/ > Protocol.xml > index 9fdee9a..fedaaab 100644 > --- a/doc/publican/sources/Protocol.xml > +++ b/doc/publican/sources/Protocol.xml > @@ -479,7 +479,7 @@ > > >MIME is defined in RFC's 2045-2049. A > - ftp://ftp.isi.edu/in-notes/iana/assignments/media- > types/"> > + https://www.iana.org/assignments/media-types/media- > types.xhtml"> >registry of MIME types is maintained by the Internet > Assigned >Numbers Authority (IANA). > > -- > 2.17.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 2/2] contributing: commit rights
Reviewed-by: Matheus Santana Thanks for engaging on this. As a newcomer, it's great to have such information on my disposal. On Mon, Jun 18, 2018 at 10:42 AM, Pekka Paalanen wrote: > From: Pekka Paalanen > > This has been copied from > https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/ > CONTRIBUTING?id=eccae1360d6d01e73c6af2bd97122cef708207ef > and slightly edited to better with Wayland and Weston. > > The intention is to make it easier to give out commit access to new > people, let them know what is expected of them, and help the community > to grow. Hopefully this will in time improve the patch review throughput > and timeliness. > > The original text was introduced in > https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/ > commit/CONTRIBUTING?id=0350f0e7f6a0e07281445fc3082aa70419f4aac7 > > Signed-off-by: Pekka Paalanen > --- > CONTRIBUTING.md | 33 + > 1 file changed, 33 insertions(+) > > diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md > index 6e74b6d..70d0eca 100644 > --- a/CONTRIBUTING.md > +++ b/CONTRIBUTING.md > @@ -246,5 +246,38 @@ clarity suffers. > - The code adheres to the style guidelines. > > > +Commit rights > += > + > +Commit rights will be granted to anyone who requests them and fulfills the > +below criteria: > + > +- Submitted some (10 as a rule of thumb) non-trivial (not just simple > + spelling fixes and whitespace adjustment) patches that have been merged > + already. > + > +- Are actively participating in public discussions about their work (on > the > + mailing list or IRC). This should not be interpreted as a requirement to > + review other peoples patches but just make sure that patch submission > isn't > + one-way communication. Cross-review is still highly encouraged. > + > +- Will be regularly contributing further patches. This includes regular > + contributors to other parts of the open source graphics stack who only > + do the occasional development in this project. > + > +- Agrees to use their commit rights in accordance with the documented > merge > + criteria, tools, and processes. > + > +To apply for commit rights, create a new issue in gitlab for the > respective > +project and give it the "accounts" label. > + > +Committers are encouraged to request their commit rights get removed when > they > +no longer contribute to the project. Commit rights will be reinstated > when they > +come back to the project. > + > +Maintainers and committers should encourage contributors to request commit > +rights, especially junior contributors tend to underestimate their skills. > + > + > [git documentation]: http://git-scm.com/documentation > [notes on commit messages]: http://who-t.blogspot.de/2009/ > 12/on-commit-messages.html > -- > 2.16.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: [PATCH wayland 1/2] contributing: add review guidelines
Reviewed-by: Matheus Santana It seems a great starting point. On Mon, Jun 18, 2018 at 10:42 AM, Pekka Paalanen wrote: > From: Pekka Paalanen > > This sets up the standards for patch review, and defines when a patch > can be merged. I believe these are the practises we have been using > already for a long time, now they are just written down explicitly. > > It's not an exhaustive list of criteria and likely cannot ever be, but > it should give a good idea of what level of review we want to have. > > It has been written in general terms, so that we can easily apply the > same text not just to Wayland, but also Weston and other projects as > necessary. > > This addition is not redundant with > https://wayland.freedesktop.org/reviewing.html . > > The web page is a friendly introduction and encouragement for people to > get involved. The guidelines here are more specific and aimed for people > who seek commit rights or maintainership. > > Signed-off-by: Pekka Paalanen > --- > CONTRIBUTING.md | 49 + > 1 file changed, 49 insertions(+) > > diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md > index 7ad75b8..6e74b6d 100644 > --- a/CONTRIBUTING.md > +++ b/CONTRIBUTING.md > @@ -197,5 +197,54 @@ New source code files should specify the MIT Expat > license in their > boilerplate, as part of the copyright statement. > > > +Review > +== > + > +All patches, even trivial ones, require at least one positive review > +(Reviewed-by). Additionally, if no Reviewed-by's have been given by > +people with commit access, there needs to be at least one Acked-by from > +someone with commit access. A person with commit access is expected to be > +able to evaluate the patch with respect to the project scope and > architecture. > + > +During review, the following matters should be checked: > + > +- The commit message explains why the change is being made. > + > +- The code fits the project's scope. > + > +- The code license is the same MIT licence the project generally uses. > + > +- Stable ABI or API is not broken. > + > +- Stable ABI or API additions must be justified by actual use cases, not > only > +by speculation. They must also be documented, and it is strongly > recommended to > +include tests excercising the additions in the test suite. > + > +- The code fits the existing software architecture, e.g. no layering > +violations. > + > +- The code is correct and does not ignore corner-cases. > + > +- In a patch series, every intermediate step produces correct code as > well. > + > +- The code does what it says in the commit message and changes nothing > else. > + > +- The test suite passes. > + > +- The code does not depend on API or ABI which has no working free open > source > +implementation. > + > +- The code is not dead or untestable. E.g. if there are no free open > source > +software users for it then it is effectively dead code. > + > +- The code is written to be easy to understand, or if code cannot be clear > +enough on its own there are code comments to explain it. > + > +- The code is minimal, i.e. prefer refactor and re-use when possible > unless > +clarity suffers. > + > +- The code adheres to the style guidelines. > + > + > [git documentation]: http://git-scm.com/documentation > [notes on commit messages]: http://who-t.blogspot.de/2009/ > 12/on-commit-messages.html > -- > 2.16.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: Session suspension and restoration protocol
This document might be useful for the D-Bus side: https://dbus.freedesktop.org/doc/dbus-api-design.html On Mon, 18 Jun 2018 at 17:05:25 +0200, Roman Gilg wrote: > In certain high levels the compositor will ask the client through a > special D-Bus interface to restore its internal state. This interface > must be made available by the client on the address specified by the > desktop_id argument. A D-Bus "address" isn't what you think it is. I think you mean a *well-known bus name*, for example "org.gnome.Builder". Note that GNOME Builder's desktop ID is "org.gnome.Builder.desktop" but its D-Bus well-known name is "org.gnome.Builder", and any other DBusActivatable application will follow the same pattern (it's part of the Desktop Entry Specification). Be clear about which one you mean. Strictly speaking, you should also specify that this is a name on the *well-known session bus* (or "session bus" for short). I would recommend having a canonical XML description (somewhere) for the D-Bus side of this interface, similar to the one in the text of https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#dbus > The special interface name for the D-Bus call is > zxdg_session_suspension_v1 That isn't a valid D-Bus interface name. D-Bus interface names look something like "com.example.SessionSuspension1". The equivalent of Wayland's xdg_ is org.freedesktop. If you are proposing names in that namespace you should mention them on the x...@lists.freedesktop.org list, although I think it'd be OK to say "please send feedback to the Wayland list". To call a D-Bus method, you also need an object path. There are two reasonable object paths for a singleton object related to the Desktop Entry Specification's DBusActivatable protocol: either reuse the object path corresponding to the desktop ID (for example /org/gnome/Builder), or use an object path corresponding to your interface name (for example /org/freedesktop/SessionSuspension1). If you use the object path corresponding to the desktop ID, then it will be very awkward to implement this protocol without involving the implementation of DBusActivatable (for instance GApplication/GtkApplication in GNOME), but the GApplication/GtkApplication or equivalent is probably the right place to implement this protocol anyway, so either could work. (The reason why object paths and interfaces are separate is that in a more complex design, there might be many implementations of the same interface in a process, for instance media players that provide one object per file/track/stream at different object paths, each of them implementing org.gnome.UPnP.MediaItem2. If interfaces are like abstract base classes, then object paths are like pointers.) Do you intend the D-Bus side of the protocol to be equally useful to X11 apps, or is this a Wayland-only thing? > and the method being called by the > compositor on this interface is simply called 'restore' D-Bus method names are conventionally in camel-case, so 'Restore'. When we discussed this on #gnome-hackers we were talking about doing restoration by passing the restored session ID as platform_data to the Activate method defined by https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#dbus which would mean that for trivial/stateless apps, it would be enough to ignore it and just start up, which DBusActivatable implementations like GtkApplication will already do. Is there a reason why you've opted to define a new method instead? > compositor will issue on the next Wayland server launch the D-Bus > command: > > org.foo.bar /zxdg_session_suspension_v1 restore(1234) D-Bus has no concept of a "command". The jargon term you're looking for is a *method call*, which is one of several types of *message*. If you want a pseudocode notation, you might want something like this: a D-Bus method call to a destination given by the desktop_id, with object path /org/freedesktop/SessionSuspension1, interface org.freedesktop.SessionSuspension1, method name Restore, and the client_id as a uint32 parameter, similar to the result of this dbus-send(1) command line: dbus-send --type=method_call --destination=org.gnome.Builder \ /org/freedesktop/SessionSuspension1 \ org.freedesktop.SessionSuspension1.Restore \ uint32:1234 (Of course, compositors or session managers should normally implement this in-process instead of by running dbus-send(1).) > summary="desktop file id to restore the client via d-bus"/> Does this include .desktop or not? GNOME Builder's desktop ID is "org.gnome.Builder.desktop" but its D-Bus well-known name is "org.gnome.Builder", and any other DBusActivatable application will follow the same pattern (it's part of the Desktop Entry Specification). > The quit state ends when the compositor sends the D-Bus signal to >
Session suspension and restoration protocol
Hi all, I have worked the past few days on a protocol for client session suspension and restoration and I need to get some feedback if I'm running in the right direction. I did get some input from Sway and GNOME devs at the start on what they would want such a protocol to do in general, and I did try to respect that when working on the protocol. Main features of the protocol as pasted below are: * provides an extensible object creation mechanism to let the compositor announce support for a subset of three increasing levels of suspension and let the client opt-in to some or all of these supported suspension levels * these three levels are: 1. sleep: allows destroying surfaces and their later restoration 2. quit: allows connection closing and restart of the client by the compositor via an implementation-independent D-Bus interface 3. shutdown: client will get restored after a server shutdown in a new Wayland session via the same D-Bus interface. * using D-Bus interface only to secure against sandboxed clients * if the client opts-in to level 2, 3 or both, the compositor might try to also restore the client after a client or compositor crash * the program flow would be always: 1. compositor announces supported suspension levels 2. client opts-in to one or several of the supported suspension levels by creating protocol objects for the respective levels 3. when the compositor wants to suspend the client (for example on low memory or shutdown) it sends an event to the respective suspension object, which the client can acknowledge or it must destroy the object to cancel the suspension. So while client and server agree on a subset of usable suspension levels, in the end only the compositor activates a suspension. The protocol is written from scratch, but it shares some similarities with Mike's proposed xdg-session-management protocol (https://lists.freedesktop.org/archives/wayland-devel/2018-February/037236.html). In advance thank you for your feedback! Copyright © 2018 Roman Gilg 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. A protocol for suspending and restoring clients. Multiple modes allow clients and server to match their common support for different levels of suspension from suspending and restoring only the client's surfaces until full client restoration after a system reboot. Warning! The protocol described in this file is experimental and backward incompatible changes may be made. Backward compatible changes may be added together with the corresponding interface version bump. Backward incompatible changes are done by bumping the version number in the protocol and interface names and resetting the interface version. Once the protocol is to be declared stable, the 'z' prefix and the version number in the protocol and interface names are removed and the interface version number is reset. A compositor implementing this interface announces that it is capable of some form of session suspension. Clients can register themselves in order to get more information about the available suspension levels and decide which ones of these they want to support. Clients register themselves in two steps by first sending the register_session_suspension request and then creating other child interfaces relative to which levels of restoration they and the compositor agree on to support. In the current version the protocol supports suspension of surfaces and their subsequent restoration while keeping the Wayland connection between client and server alive, restoration after the client quits the connection voluntarily or by crashing and restoration at the beginning of a new compositor session after a compositor shutdown by regular means or because of a
Re: Wayland content-protection extension
On Monday 18 June 2018 07:48 PM, Pekka Paalanen wrote: On Mon, 18 Jun 2018 08:58:28 -0500 Matt Hoosier wrote: On Mon, Jun 18, 2018 at 8:54 AM Pekka Paalanen wrote: Hi Matt, did you intend to reply on list? Please CC if you did. On Mon, 18 Jun 2018 08:35:56 -0500 Matt Hoosier wrote: On Mon, Jun 18, 2018 at 3:59 AM Pekka Paalanen wrote: On Mon, 18 Jun 2018 13:38:09 +0530 Ramalingam C wrote: On Monday 18 June 2018 01:34 PM, Pekka Paalanen wrote: On Sat, 16 Jun 2018 12:50:52 +0530 Ramalingam C wrote: How does the kernel signal to userspace that the HDCP status has changed? Do you piggyback on the hotplug event? Anything that would require userspace to repeatedly re-read properties without any events triggering it is bad design. If nothing is happening, the compositor needs to be able to stay asleep. Pekka, We proposed a uevent from kernel for indicating the HDCP status change. But that didn't fly. Right now the merged interface expects compositor to poll the property state for the runtime failures. Ugh. :-( I get what you mean here, but maybe it's not actually that bad. The HDCP runtime failure polling would really only be needed during times when at least one video stream is actually using it, right? If that's true, then the compositor is regularly waking up as the clients submit successive buffers anyway. Can the HDCP connector status polling get folded into that wakeup cycle? Sure, but you are assuming the protected content is video. I'm thinking of still images. Yeah, that's a fair point. Still probably covers the dominant use-case though? Just curious, are you referring to the still images that result from pausing a video stream, or first-class static images (maybe photos or something) covered by content protection too? Anything that can actually sit still on the screen. Though current HDCP usecase is for video playback, I would prefer the HDCP design to consider any digital content(still fb or video protection) on wire. Thanks Ram Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 2/4] shared: remove weston_config_get_libexec_dir()
From: Pekka Paalanen
Now that WESTON_MODULE_MAP supersedes WESTON_BUILD_DIR for libexec
binaries, we don't need to check in WESTON_BUILD_DIR anymore.
There was only one user of weston_config_get_libexec_dir(), so remove
the whole function. There is no reason to export it.
Signed-off-by: Pekka Paalanen
---
compositor/main.c | 3 +--
shared/config-parser.c | 12
shared/config-parser.h | 2 --
3 files changed, 1 insertion(+), 16 deletions(-)
diff --git a/compositor/main.c b/compositor/main.c
index a801be87..2cb50c19 100644
--- a/compositor/main.c
+++ b/compositor/main.c
@@ -738,8 +738,7 @@ wet_get_binary_path(const char *name)
if (len > 0)
return strdup(path);
- len = snprintf(path, sizeof path, "%s/%s",
- weston_config_get_libexec_dir(), name);
+ len = snprintf(path, sizeof path, "%s/%s", LIBEXECDIR, name);
if (len >= sizeof path)
return NULL;
diff --git a/shared/config-parser.c b/shared/config-parser.c
index 2a595b1f..ae5f8035 100644
--- a/shared/config-parser.c
+++ b/shared/config-parser.c
@@ -330,18 +330,6 @@ weston_config_section_get_bool(struct
weston_config_section *section,
return 0;
}
-WL_EXPORT
-const char *
-weston_config_get_libexec_dir(void)
-{
- const char *path = getenv("WESTON_BUILD_DIR");
-
- if (path)
- return path;
-
- return LIBEXECDIR;
-}
-
const char *
weston_config_get_name_from_env(void)
{
diff --git a/shared/config-parser.h b/shared/config-parser.h
index af3f66a2..5cb0bca1 100644
--- a/shared/config-parser.h
+++ b/shared/config-parser.h
@@ -103,8 +103,6 @@ int
weston_config_section_get_bool(struct weston_config_section *section,
const char *key,
int *value, int default_value);
-const char *
-weston_config_get_libexec_dir(void);
const char *
weston_config_get_name_from_env(void);
--
2.16.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 3/4] tests: remove WESTON_BUILD_DIR from env
From: Pekka Paalanen
There are no users left.
Signed-off-by: Pekka Paalanen
---
tests/weston-tests-env | 4
1 file changed, 4 deletions(-)
diff --git a/tests/weston-tests-env b/tests/weston-tests-env
index 04648bf1..63aad4af 100755
--- a/tests/weston-tests-env
+++ b/tests/weston-tests-env
@@ -55,7 +55,6 @@ case $TEST_FILE in
set -x
WESTON_MODULE_MAP="${WESTON_MODULE_MAP}" \
WESTON_DATA_DIR=$abs_top_srcdir/data \
- WESTON_BUILD_DIR=$abs_builddir \
WESTON_TEST_REFERENCE_PATH=$abs_top_srcdir/tests/reference \
$WESTON --backend=$MODDIR/$BACKEND \
--no-config \
@@ -69,7 +68,6 @@ case $TEST_FILE in
set -x
WESTON_MODULE_MAP="${WESTON_MODULE_MAP}" \
WESTON_DATA_DIR=$abs_top_srcdir/data \
- WESTON_BUILD_DIR=$abs_builddir \
WESTON_TEST_REFERENCE_PATH=$abs_top_srcdir/tests/reference \
$WESTON --backend=$MODDIR/$BACKEND \
${CONFIG} \
@@ -86,7 +84,6 @@ case $TEST_FILE in
set -x
WESTON_MODULE_MAP="${WESTON_MODULE_MAP}" \
WESTON_DATA_DIR=$abs_top_srcdir/data \
- WESTON_BUILD_DIR=$abs_builddir \
WESTON_TEST_REFERENCE_PATH=$abs_top_srcdir/tests/reference \
WESTON_TEST_CLIENT_PATH=$abs_builddir/$TEST_FILE \
$WESTON --backend=$MODDIR/$BACKEND \
@@ -102,7 +99,6 @@ case $TEST_FILE in
set -x
WESTON_MODULE_MAP="${WESTON_MODULE_MAP}" \
WESTON_DATA_DIR=$abs_top_srcdir/data \
- WESTON_BUILD_DIR=$abs_builddir \
WESTON_TEST_REFERENCE_PATH=$abs_top_srcdir/tests/reference \
WESTON_TEST_CLIENT_PATH=$abs_builddir/$TEST_FILE \
$WESTON --backend=$MODDIR/$BACKEND \
--
2.16.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 4/4] tests: Reshuffle IVI layout tests
From: Daniel Stone
Rename the IVI tests to be more consistent with the others, and invert
the naming of plugin/client to make it slightly more clear what's going
to happen. Handle the renaming by using wet_get_binary_path to rewrite
the local binaries.
As a side-effect, weston.ini ivi-shell-user-interface no longer needs to
be given as an absolute path.
Signed-off-by: Daniel Stone
v2:
Call ivi-layout.ivi as ivi-layout-test-client.ivi to keep the same name
in both the file and the lookup, so that the module map does not need to
change the name.
Update code comments to reflect the new names.
Rename ivi_layout-test-plugin.c to ivi-layout-test-plugin.c.
Signed-off-by: Pekka Paalanen
---
Makefile.am | 16
ivi-shell/hmi-controller.c | 12 +++-
ivi-shell/weston.ini.in | 8
...layout-internal-test.c => ivi-layout-internal-test.c} | 0
tests/{ivi_layout-test.c => ivi-layout-test-client.c}| 8
...ivi_layout-test-plugin.c => ivi-layout-test-plugin.c} | 12 +++-
tests/weston-tests-env | 2 +-
7 files changed, 35 insertions(+), 23 deletions(-)
rename tests/{ivi_layout-internal-test.c => ivi-layout-internal-test.c} (100%)
rename tests/{ivi_layout-test.c => ivi-layout-test-client.c} (97%)
rename tests/{ivi_layout-test-plugin.c => ivi-layout-test-plugin.c} (98%)
diff --git a/Makefile.am b/Makefile.am
index d2025bc5..3bce47a1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1477,13 +1477,13 @@ ivi_layout_internal_test_la_LIBADD =
$(test_module_libadd)
ivi_layout_internal_test_la_LDFLAGS = $(test_module_ldflags)
ivi_layout_internal_test_la_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS)
ivi_layout_internal_test_la_SOURCES = \
- tests/ivi_layout-internal-test.c
+ tests/ivi-layout-internal-test.c
ivi_layout_test_la_LIBADD = $(test_module_libadd)
ivi_layout_test_la_LDFLAGS = $(test_module_ldflags)
ivi_layout_test_la_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS)
ivi_layout_test_la_SOURCES = \
- tests/ivi_layout-test-plugin.c \
+ tests/ivi-layout-test-plugin.c \
tests/ivi-test.h\
shared/helpers.h
nodist_ivi_layout_test_la_SOURCES =\
@@ -1500,17 +1500,17 @@ nodist_ivi_shell_app_weston_SOURCES = \
ivi_shell_app_weston_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS)
ivi_shell_app_weston_LDADD = libtest-client.la
-noinst_PROGRAMS += ivi-layout.ivi
+noinst_PROGRAMS += ivi-layout-test-client.ivi
-ivi_layout_ivi_SOURCES = \
- tests/ivi_layout-test.c \
+ivi_layout_test_client_ivi_SOURCES = \
+ tests/ivi-layout-test-client.c \
tests/ivi-test.h\
shared/helpers.h
-nodist_ivi_layout_ivi_SOURCES =\
+nodist_ivi_layout_test_client_ivi_SOURCES =\
protocol/ivi-application-protocol.c \
protocol/ivi-application-client-protocol.h
-ivi_layout_ivi_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS)
-ivi_layout_ivi_LDADD = libtest-client.la
+ivi_layout_test_client_ivi_CFLAGS = $(AM_CFLAGS) $(TEST_CLIENT_CFLAGS)
+ivi_layout_test_client_ivi_LDADD = libtest-client.la
endif
if BUILD_SETBACKLIGHT
diff --git a/ivi-shell/hmi-controller.c b/ivi-shell/hmi-controller.c
index 0e44df88..a0e49ba0 100644
--- a/ivi-shell/hmi-controller.c
+++ b/ivi-shell/hmi-controller.c
@@ -676,6 +676,7 @@ hmi_server_setting_create(struct weston_compositor *ec)
struct hmi_server_setting *setting = MEM_ALLOC(sizeof(*setting));
struct weston_config *config = wet_get_config(ec);
struct weston_config_section *shell_section = NULL;
+ char *ivi_ui_config;
shell_section = weston_config_get_section(config, "ivi-shell",
NULL, NULL);
@@ -704,7 +705,16 @@ hmi_server_setting_create(struct weston_compositor *ec)
weston_config_section_get_string(shell_section,
"ivi-shell-user-interface",
->ivi_homescreen, NULL);
+_ui_config, NULL);
+ if (ivi_ui_config && ivi_ui_config[0] != '/') {
+ setting->ivi_homescreen = wet_get_binary_path(ivi_ui_config);
+ if (setting->ivi_homescreen)
+ free(ivi_ui_config);
+ else
+ setting->ivi_homescreen = ivi_ui_config;
+ } else {
+ setting->ivi_homescreen = ivi_ui_config;
+ }
return setting;
}
diff --git a/ivi-shell/weston.ini.in b/ivi-shell/weston.ini.in
index 3f11e1c0..a06d76ef 100644
--- a/ivi-shell/weston.ini.in
+++ b/ivi-shell/weston.ini.in
@@ -1,9 +1,9 @@
[core]
-shell=@plugin_pre...@ivi-shell.so
[PATCH weston 1/4] tests: Don't rely on build directory layout
From: Daniel Stone
Rather than having a hardcoded dependency on the build-directory layout,
use an explicit module-map environment variable, which rewrites requests
for modules and helper/libexec binaries to specific paths.
This will help with migration to Meson where setting up the paths
according to autotools would be painful and unnecessary.
Signed-off-by: Daniel Stone
v2:
Fixed ivi_layout-test-plugin.c:wet_module_init().
Do not change the lookup name of ivi-layout.ivi.
Improved documentation of weston_module_path_from_env() and made it cope
with map strings that a) do not end with a semicolon, and b) have
multiple consecutive semicolons.
Let WESTON_MODULE_MAP be printed into the test log so that it is easier
to run tests manually.
Signed-off-by: Pekka Paalanen
---
compositor/main.c | 26 +-
compositor/text-backend.c | 6 +
compositor/weston-screenshooter.c | 8 +++---
compositor/weston.h | 3 +++
desktop-shell/shell.c | 9 ++-
libweston/compositor.c| 57 +++
libweston/compositor.h| 3 +++
tests/ivi_layout-test-plugin.c| 16 +--
tests/weston-tests-env| 17
9 files changed, 108 insertions(+), 37 deletions(-)
diff --git a/compositor/main.c b/compositor/main.c
index 86e3782f..a801be87 100644
--- a/compositor/main.c
+++ b/compositor/main.c
@@ -652,7 +652,6 @@ weston_create_listening_socket(struct wl_display *display,
const char *socket_na
WL_EXPORT void *
wet_load_module_entrypoint(const char *name, const char *entrypoint)
{
- const char *builddir = getenv("WESTON_BUILD_DIR");
char path[PATH_MAX];
void *module, *init;
size_t len;
@@ -661,10 +660,8 @@ wet_load_module_entrypoint(const char *name, const char
*entrypoint)
return NULL;
if (name[0] != '/') {
- if (builddir)
- len = snprintf(path, sizeof path, "%s/.libs/%s",
builddir,
- name);
- else
+ len = weston_module_path_from_env(name, path, sizeof path);
+ if (len == 0)
len = snprintf(path, sizeof path, "%s/%s", MODULEDIR,
name);
} else {
@@ -701,7 +698,6 @@ wet_load_module_entrypoint(const char *name, const char
*entrypoint)
return init;
}
-
WL_EXPORT int
wet_load_module(struct weston_compositor *compositor,
const char *name, int *argc, char *argv[])
@@ -732,6 +728,24 @@ wet_load_shell(struct weston_compositor *compositor,
return 0;
}
+WL_EXPORT char *
+wet_get_binary_path(const char *name)
+{
+ char path[PATH_MAX];
+ size_t len;
+
+ len = weston_module_path_from_env(name, path, sizeof path);
+ if (len > 0)
+ return strdup(path);
+
+ len = snprintf(path, sizeof path, "%s/%s",
+ weston_config_get_libexec_dir(), name);
+ if (len >= sizeof path)
+ return NULL;
+
+ return strdup(path);
+}
+
static int
load_modules(struct weston_compositor *ec, const char *modules,
int *argc, char *argv[], int32_t *xwayland)
diff --git a/compositor/text-backend.c b/compositor/text-backend.c
index 4d8c085b..54242427 100644
--- a/compositor/text-backend.c
+++ b/compositor/text-backend.c
@@ -1047,14 +1047,10 @@ text_backend_configuration(struct text_backend
*text_backend)
struct weston_config *config = wet_get_config(text_backend->compositor);
struct weston_config_section *section;
char *client;
- int ret;
section = weston_config_get_section(config,
"input-method", NULL, NULL);
- ret = asprintf(, "%s/weston-keyboard",
- weston_config_get_libexec_dir());
- if (ret < 0)
- client = NULL;
+ client = wet_get_binary_path("weston-keyboard");
weston_config_section_get_string(section, "path",
_backend->input_method.path,
client);
diff --git a/compositor/weston-screenshooter.c
b/compositor/weston-screenshooter.c
index 70afed4a..0994cb4f 100644
--- a/compositor/weston-screenshooter.c
+++ b/compositor/weston-screenshooter.c
@@ -117,12 +117,10 @@ screenshooter_binding(struct weston_keyboard *keyboard,
{
struct screenshooter *shooter = data;
char *screenshooter_exe;
- int ret;
- ret = asprintf(_exe, "%s/%s",
- weston_config_get_libexec_dir(),
- "/weston-screenshooter");
- if (ret < 0) {
+
+ screenshooter_exe = wet_get_binary_path("weston-screenshooter");
+ if (!screenshooter_exe) {
weston_log("Could not construct screenshooter path.\n");
return;
}
diff --git
[PATCH weston 0/4] Preparing for Meson
From: Pekka Paalanen
Hi,
these changes are intended to make using Meson easier. Daniel's patches
are v2, mine are v1.
Daniel Stone (2):
tests: Don't rely on build directory layout
tests: Reshuffle IVI layout tests
Pekka Paalanen (2):
shared: remove weston_config_get_libexec_dir()
tests: remove WESTON_BUILD_DIR from env
Makefile.am| 16 +++---
compositor/main.c | 25 +++---
compositor/text-backend.c | 6 +--
compositor/weston-screenshooter.c | 8 ++-
compositor/weston.h| 3 ++
desktop-shell/shell.c | 9 +---
ivi-shell/hmi-controller.c | 12 -
ivi-shell/weston.ini.in| 8 +--
libweston/compositor.c | 57 --
libweston/compositor.h | 3 ++
shared/config-parser.c | 12 -
shared/config-parser.h | 2 -
...-internal-test.c => ivi-layout-internal-test.c} | 0
...{ivi_layout-test.c => ivi-layout-test-client.c} | 8 +--
...yout-test-plugin.c => ivi-layout-test-plugin.c} | 26 +-
tests/weston-tests-env | 21 ++--
16 files changed, 140 insertions(+), 76 deletions(-)
rename tests/{ivi_layout-internal-test.c => ivi-layout-internal-test.c} (100%)
rename tests/{ivi_layout-test.c => ivi-layout-test-client.c} (97%)
rename tests/{ivi_layout-test-plugin.c => ivi-layout-test-plugin.c} (98%)
--
2.16.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland content-protection extension
On Mon, 18 Jun 2018 08:58:28 -0500 Matt Hoosier wrote: > On Mon, Jun 18, 2018 at 8:54 AM Pekka Paalanen wrote: > > > Hi Matt, > > > > did you intend to reply on list? Please CC if you did. > > > > On Mon, 18 Jun 2018 08:35:56 -0500 > > Matt Hoosier wrote: > > > > > On Mon, Jun 18, 2018 at 3:59 AM Pekka Paalanen > > wrote: > > > > > > > On Mon, 18 Jun 2018 13:38:09 +0530 > > > > Ramalingam C wrote: > > > > > > > > > On Monday 18 June 2018 01:34 PM, Pekka Paalanen wrote: > > > > > > On Sat, 16 Jun 2018 12:50:52 +0530 > > > > > > Ramalingam C wrote: > > > > > > > > > > > > > > > > How does the kernel signal to userspace that the HDCP status has > > > > > > changed? Do you piggyback on the hotplug event? > > > > > > > > > > > > Anything that would require userspace to repeatedly re-read > > properties > > > > > > without any events triggering it is bad design. If nothing is > > > > > > happening, the compositor needs to be able to stay asleep. > > > > > Pekka, > > > > > > > > > > We proposed a uevent from kernel for indicating the HDCP status > > change. > > > > > But that didn't fly. Right now the merged interface expects > > compositor > > > > > to poll > > > > > the property state for the runtime failures. > > > > > > > > Ugh. :-( > > > > > > > > > > I get what you mean here, but maybe it's not actually that bad. The HDCP > > > runtime failure polling would really only be needed during times when at > > > least one video stream is actually using it, right? If that's true, then > > > the compositor is regularly waking up as the clients submit successive > > > buffers anyway. Can the HDCP connector status polling get folded into > > that > > > wakeup cycle? > > > > Sure, but you are assuming the protected content is video. I'm thinking > > of still images. > > > > Yeah, that's a fair point. Still probably covers the dominant use-case > though? Just curious, are you referring to the still images that result > from pausing a video stream, or first-class static images (maybe photos or > something) covered by content protection too? Anything that can actually sit still on the screen. Thanks, pq pgpI921e_Wgee.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland content-protection extension
On Mon, Jun 18, 2018 at 8:54 AM Pekka Paalanen wrote: > Hi Matt, > > did you intend to reply on list? Please CC if you did. > > On Mon, 18 Jun 2018 08:35:56 -0500 > Matt Hoosier wrote: > > > On Mon, Jun 18, 2018 at 3:59 AM Pekka Paalanen > wrote: > > > > > On Mon, 18 Jun 2018 13:38:09 +0530 > > > Ramalingam C wrote: > > > > > > > On Monday 18 June 2018 01:34 PM, Pekka Paalanen wrote: > > > > > On Sat, 16 Jun 2018 12:50:52 +0530 > > > > > Ramalingam C wrote: > > > > > > > > > > > > > How does the kernel signal to userspace that the HDCP status has > > > > > changed? Do you piggyback on the hotplug event? > > > > > > > > > > Anything that would require userspace to repeatedly re-read > properties > > > > > without any events triggering it is bad design. If nothing is > > > > > happening, the compositor needs to be able to stay asleep. > > > > Pekka, > > > > > > > > We proposed a uevent from kernel for indicating the HDCP status > change. > > > > But that didn't fly. Right now the merged interface expects > compositor > > > > to poll > > > > the property state for the runtime failures. > > > > > > Ugh. :-( > > > > > > > I get what you mean here, but maybe it's not actually that bad. The HDCP > > runtime failure polling would really only be needed during times when at > > least one video stream is actually using it, right? If that's true, then > > the compositor is regularly waking up as the clients submit successive > > buffers anyway. Can the HDCP connector status polling get folded into > that > > wakeup cycle? > > Sure, but you are assuming the protected content is video. I'm thinking > of still images. > Yeah, that's a fair point. Still probably covers the dominant use-case though? Just curious, are you referring to the still images that result from pausing a video stream, or first-class static images (maybe photos or something) covered by content protection too? > > I'd ask for more details on why the kernel community thinks that there > must not be an event to signal HDCP state changes, I suspect it's a > problem with the implementation and not the idea, but I won't have time > to go there anyway. > > > Thanks, > pq > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland 2/2] contributing: commit rights
From: Pekka Paalanen This has been copied from https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/CONTRIBUTING?id=eccae1360d6d01e73c6af2bd97122cef708207ef and slightly edited to better with Wayland and Weston. The intention is to make it easier to give out commit access to new people, let them know what is expected of them, and help the community to grow. Hopefully this will in time improve the patch review throughput and timeliness. The original text was introduced in https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/commit/CONTRIBUTING?id=0350f0e7f6a0e07281445fc3082aa70419f4aac7 Signed-off-by: Pekka Paalanen --- CONTRIBUTING.md | 33 + 1 file changed, 33 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 6e74b6d..70d0eca 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -246,5 +246,38 @@ clarity suffers. - The code adheres to the style guidelines. +Commit rights += + +Commit rights will be granted to anyone who requests them and fulfills the +below criteria: + +- Submitted some (10 as a rule of thumb) non-trivial (not just simple + spelling fixes and whitespace adjustment) patches that have been merged + already. + +- Are actively participating in public discussions about their work (on the + mailing list or IRC). This should not be interpreted as a requirement to + review other peoples patches but just make sure that patch submission isn't + one-way communication. Cross-review is still highly encouraged. + +- Will be regularly contributing further patches. This includes regular + contributors to other parts of the open source graphics stack who only + do the occasional development in this project. + +- Agrees to use their commit rights in accordance with the documented merge + criteria, tools, and processes. + +To apply for commit rights, create a new issue in gitlab for the respective +project and give it the "accounts" label. + +Committers are encouraged to request their commit rights get removed when they +no longer contribute to the project. Commit rights will be reinstated when they +come back to the project. + +Maintainers and committers should encourage contributors to request commit +rights, especially junior contributors tend to underestimate their skills. + + [git documentation]: http://git-scm.com/documentation [notes on commit messages]: http://who-t.blogspot.de/2009/12/on-commit-messages.html -- 2.16.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland 0/2] Document review and commit access requirements
From: Pekka Paalanen Hi, for years we have relied on unwritten traditions on how to review patches. Gaining commit access has been a secret rite no-one really knew what was required for to ask or grant it. I would dare claim that this has been partially the reason for why there are so few people who routinely review and land patches. At least I hope so, because "unwritten" is something we can fix. Let's try to write down the existing conventions and criteria we use to review patches. These will not be rules to be followed to the letter but to the spirit. Once we have documented guidelines for quality assurance on patch review, we can set up rules for granting commit rights. The movement to document commit rights requirements started in the kernel DRM commmunity as a tool to give out commits rights to more people and get more people involved and reviewing patches. I believe we would certainly want more people involved with Wayland and Weston, but it won't work if we don't also get more reviewers and committers. So here goes. Documenting what is expected from reviewers and commmit rights holders should make everyone's lives easier. These patches are my first take on it, and build on others' as referenced. I want to ensure that I am replaceable. That everyone is. The guidelines will not be perfect from the start. They should we honed over time. Thanks, pq Pekka Paalanen (2): contributing: add review guidelines contributing: commit rights CONTRIBUTING.md | 82 + 1 file changed, 82 insertions(+) -- 2.16.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland 1/2] contributing: add review guidelines
From: Pekka Paalanen This sets up the standards for patch review, and defines when a patch can be merged. I believe these are the practises we have been using already for a long time, now they are just written down explicitly. It's not an exhaustive list of criteria and likely cannot ever be, but it should give a good idea of what level of review we want to have. It has been written in general terms, so that we can easily apply the same text not just to Wayland, but also Weston and other projects as necessary. This addition is not redundant with https://wayland.freedesktop.org/reviewing.html . The web page is a friendly introduction and encouragement for people to get involved. The guidelines here are more specific and aimed for people who seek commit rights or maintainership. Signed-off-by: Pekka Paalanen --- CONTRIBUTING.md | 49 + 1 file changed, 49 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 7ad75b8..6e74b6d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -197,5 +197,54 @@ New source code files should specify the MIT Expat license in their boilerplate, as part of the copyright statement. +Review +== + +All patches, even trivial ones, require at least one positive review +(Reviewed-by). Additionally, if no Reviewed-by's have been given by +people with commit access, there needs to be at least one Acked-by from +someone with commit access. A person with commit access is expected to be +able to evaluate the patch with respect to the project scope and architecture. + +During review, the following matters should be checked: + +- The commit message explains why the change is being made. + +- The code fits the project's scope. + +- The code license is the same MIT licence the project generally uses. + +- Stable ABI or API is not broken. + +- Stable ABI or API additions must be justified by actual use cases, not only +by speculation. They must also be documented, and it is strongly recommended to +include tests excercising the additions in the test suite. + +- The code fits the existing software architecture, e.g. no layering +violations. + +- The code is correct and does not ignore corner-cases. + +- In a patch series, every intermediate step produces correct code as well. + +- The code does what it says in the commit message and changes nothing else. + +- The test suite passes. + +- The code does not depend on API or ABI which has no working free open source +implementation. + +- The code is not dead or untestable. E.g. if there are no free open source +software users for it then it is effectively dead code. + +- The code is written to be easy to understand, or if code cannot be clear +enough on its own there are code comments to explain it. + +- The code is minimal, i.e. prefer refactor and re-use when possible unless +clarity suffers. + +- The code adheres to the style guidelines. + + [git documentation]: http://git-scm.com/documentation [notes on commit messages]: http://who-t.blogspot.de/2009/12/on-commit-messages.html -- 2.16.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] client: Allow send error recovery without an abort
On Tue, 5 Jun 2018 18:14:54 -0700
Lloyd Pique wrote:
> Introduce a new call wl_display_set_error_handler_client(), which allows
> a client to register a callback function which is invoked if there is an
> error (possibly transient) while sending messages to the server.
>
> This allows a Wayland client that is actually a nested server to try and
> recover more gracefully from send errors, allowing it one to disconnect
> and reconnect to the server if necessary.
>
> The handler is called with the wl_display and the errno, and is expected
> to return one of WL_SEND_ERROR_ABORT, WL_SEND_ERROR_FATAL, or
> WL_SEND_ERROR_RETRY. The core-client code will then respectively abort()
> the process (the default if no handler is set), set the display context
> into an error state, or retry the send operation that failed.
>
> The existing display test is extended to exercise the new function.
Hi Lloyd,
technically this looks like a quality submission, thank you for that. I
am particularly happy to see all the new cases are added into the test
suite. I agree that calling wl_abort() is nasty and it would be good to
have something else.
However, I'm not quite convinced of the introduced complexity here.
More comments inline.
> Signed-off-by: Lloyd Pique
> ---
> COPYING | 1 +
> src/wayland-client-core.h | 75 +
> src/wayland-client.c | 67 +++-
> tests/display-test.c | 165 +-
> 4 files changed, 306 insertions(+), 2 deletions(-)
>
> diff --git a/COPYING b/COPYING
> index eb25a4e..bace5d7 100644
> --- a/COPYING
> +++ b/COPYING
> @@ -2,6 +2,7 @@ Copyright © 2008-2012 Kristian Høgsberg
> Copyright © 2010-2012 Intel Corporation
> Copyright © 2011 Benjamin Franzke
> Copyright © 2012 Collabora, Ltd.
> +Copyright © 2018 Google LLC
>
> Permission is hereby granted, free of charge, to any person obtaining a
> copy of this software and associated documentation files (the "Software"),
> diff --git a/src/wayland-client-core.h b/src/wayland-client-core.h
> index 03e781b..a3e4b8e 100644
> --- a/src/wayland-client-core.h
> +++ b/src/wayland-client-core.h
> @@ -257,6 +257,81 @@ wl_display_cancel_read(struct wl_display *display);
> int
> wl_display_read_events(struct wl_display *display);
>
> +/** \enum wl_send_error_strategy
> + *
> + * This enum are the valid values that can be returned from a
> + * wl_send_error_handler_func_t
> + *
> + * \sa wl_send_error_handler_func_t
> + */
> +enum wl_send_error_strategy {
> + /** Abort the client */
> + WL_SEND_ERROR_ABORT,
> + /** Put the display into a fatal error state */
> + WL_SEND_ERROR_FATAL,
> + /** Retry the send operation */
> + WL_SEND_ERROR_RETRY,
> +};
> +
> +/**
> + * \brief A function pointer type for customizing client send error handling
> + *
> + * A client send error strategy handler is a callback function which the
> client
> + * can set to direct the core client library how to respond if an error is
> + * encountered while sending a message.
> + *
> + * Normally messages are enqueued to an output buffer by the core client
> + * library, and the user of the core client library is expected to call
> + * wl_display_flush() occasionally, but as that is non-blocking, messages can
> + * queue up in the output buffer. If later calls to send messages happen to
> + * fill up the output buffer, the core client library will make an internal
> + * call to flush the output buffer. But if the write call unexpectedly
> fails,
> + * as there is no good way to return an error to the caller, the core client
> + * library will log a message and call abort().
The analysis of the current situation is correct.
If you know you are sending lots of requests, you should be calling
wl_display_flush() occasionally. It will return -1 if flushing fails to
let you know you need to wait. The main problem I see with that is when
to attempt to flush.
I remember some discussion from the past, where we would make the
soft-buffer in libwayland-client larger and introduce a check API which
would return whether, say, more than half of the space is already
consumed. That would work as a trigger for an extra flush at a point
convenient to the client.
I remember discussing something like that with Daniel Stone, but I
can't find it. Might have been in IRC.
Or maybe it was more like, double the soft-buffer size, attempt an
automatic flush if it is more than half-full, and if that fails,
continue and raise a flag that the user can query at a convenient time
and do the dance for manual flush and poll for writable. The remaining
soft-buffer should hopefully allow the manual flush before the buffer
runs out.
> + *
> + * If instead a send error strategy function is set, the core client library
> + * will call it to allow the client to choose a different strategy.
> + *
> + * The function takes two arguments. The first is the display context for
> the
> + * error. The
[PATCH wayland] doc: update IANA MIME types registry URL
Use a more official one, served over HTTP rather than FTP. --- doc/publican/sources/Protocol.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/publican/sources/Protocol.xml b/doc/publican/sources/Protocol.xml index 9fdee9a..fedaaab 100644 --- a/doc/publican/sources/Protocol.xml +++ b/doc/publican/sources/Protocol.xml @@ -479,7 +479,7 @@ MIME is defined in RFC's 2045-2049. A - ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/;> + https://www.iana.org/assignments/media-types/media-types.xhtml;> registry of MIME types is maintained by the Internet Assigned Numbers Authority (IANA). -- 2.17.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCHv2 wayland 0/8] wayland-scanner: produce code with c99 initializers
On Thu, 14 Jun 2018 16:49:37 +0100 Emil Velikov wrote: > Hi all, > > Here's a take v2 of the series, with the following changes: > - don't trim trailing NULL entries from the wl_interfaces* array > - updated tests - separate patches to ease review, to be squashed > > On the question of why, despite the aesthetics these patches make the > generated files actually understandable by a human being... Hi Emil, on the previous round, this concern was raised: On Tue, 13 Feb 2018 13:36:06 + Daniel Stone wrote: > But that being said, my worry is that we don't actually control the > compilation environment for the scanner output. Scanner output > currently compiles with '-pedantic -ansi -Wall -Wextra' (at least, > when inline is defined). This patch changes that requirement, and I > worry that - like previous discussions on changing scanner output - > that upgrading Wayland would lead to people hitting compilation > failures. What is your rationale for that being a non-issue? Thanks, pq pgpoIY5a5Lf4G.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland content-protection extension
On Monday 18 June 2018 03:52 PM, Pekka Paalanen wrote: On Mon, 18 Jun 2018 14:32:32 +0530 Ramalingam C wrote: On Monday 18 June 2018 02:23 PM, Pekka Paalanen wrote: On Mon, 18 Jun 2018 13:38:09 +0530 Ramalingam C wrote: On Monday 18 June 2018 01:34 PM, Pekka Paalanen wrote: On Sat, 16 Jun 2018 12:50:52 +0530 Ramalingam C wrote: The SRM table smells very much like compositor configuration, especially because a) it is global state: you cannot program two different tables to the same connector, and b) the compositor is required to save it and use it later for all clients(?). One can also envision a security issue, if a system allows third party apps: an app could install a fake SRM table with a fake date. Compositor is expected to store the latest SRM in the non-volatile and update with only newest versions. And it will supply the latest version to kernel(irrespective of what version is provided by app). This caching is not per connector. SRM table itself provides the version of it. and The validity of an SRM is established by verifying the integrity of its signature with the Digital Content Protection LLC public key, which is specified by the Digital Content Protection LLC. So no fake SRM will be accepted. Right, so I would propose to make that completely separate. Ok. So how that should be implemented? As another protocol extension? I don't know. Is there a reason to do it by Wayland? Yes. As we need to supply the SRM table through drm connector properties to each ports HDCP authentication. At the least we need to receive the signature validated latest SRM from client and program into drm connector property. Means storing SRM could be kept within the wayland client but only drm_master can set the blob for the connectors. And AFAIK signature verification also a crypto calculation with DCP LLC public Key. Thanks Ram Requesting content protection is a good fit to do by Wayland, because it is per-window. Uploading a new SRB table is not tied to any window or even a Wayland client, so why should it be a Wayland extension? Is maintaining the SRB table the compositor's job, or is it a separate service in the system that the compositor contacts? I think this digs into the system design, and there is no obvious benefit from using Wayland for it, that I don't think I can make a recommendation. For instance, if installing a new SRB table optionally uses internet access to e.g. verify the signing key is still valid, then I don't think it should be the compositor in charge of maintaining the SRB table. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland content-protection extension
On Mon, 18 Jun 2018 14:32:32 +0530 Ramalingam C wrote: > On Monday 18 June 2018 02:23 PM, Pekka Paalanen wrote: > > On Mon, 18 Jun 2018 13:38:09 +0530 > > Ramalingam C wrote: > > > >> On Monday 18 June 2018 01:34 PM, Pekka Paalanen wrote: > >>> On Sat, 16 Jun 2018 12:50:52 +0530 > >>> Ramalingam C wrote: > >>> The SRM table smells very much like compositor configuration, > >>> especially because a) it is global state: you cannot program two > >>> different tables to the same connector, and b) the compositor is > >>> required to save it and use it later for all clients(?). One can also > >>> envision a security issue, if a system allows third party apps: an app > >>> could install a fake SRM table with a fake date. > >> Compositor is expected to store the latest SRM in the non-volatile and > >> update with only newest versions. > >> And it will supply the latest version to kernel(irrespective of what > >> version is provided by app). This caching is not per connector. > >> SRM table itself provides the version of it. and The validity of an SRM > >> is established by verifying the integrity of its > >> signature with the Digital Content Protection LLC public key, which is > >> specified by the Digital > >> Content Protection LLC. So no fake SRM will be accepted. > > Right, so I would propose to make that completely separate. > Ok. So how that should be implemented? As another protocol extension? I don't know. Is there a reason to do it by Wayland? Requesting content protection is a good fit to do by Wayland, because it is per-window. Uploading a new SRB table is not tied to any window or even a Wayland client, so why should it be a Wayland extension? Is maintaining the SRB table the compositor's job, or is it a separate service in the system that the compositor contacts? I think this digs into the system design, and there is no obvious benefit from using Wayland for it, that I don't think I can make a recommendation. For instance, if installing a new SRB table optionally uses internet access to e.g. verify the signing key is still valid, then I don't think it should be the compositor in charge of maintaining the SRB table. Thanks, pq pgpAfqXvbW_02.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland-protocols v7] unstable: add xdg-decoration protocol
This adds a new protocol to negotiate server-side rendering of window decorations for xdg-toplevels. This allows compositors that want to draw decorations themselves to send their preference to clients, and clients that prefer server-side decorations to request them. This is inspired by a protocol from KDE [1] which has been implemented in KDE and Sway and was submitted for consideration in 2017 [2]. This patch provides an updated protocol with those concerns taken into account. Signed-off-by: Simon Ser [1] https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml [2] https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html --- (Sorry, I somehow managed to send the old version and not the v7 one in my previous email) This was iterated on privately between representatives of Sway and wlroots (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), and Mir (Alan Griffiths). A proof-of-concept of a client and server implementation is available at [1]. Changes from v6 to v7: - Move errors in xdg_toplevel_decoration - Add errors descriptions - Add an error when toplevel is destroyed before decoration - State that objects created with the manager are still valid after destroying the manager - Compositors can no longer ignore set_mode requests, but they can disregard the client's preference - Describe how clients whose preference depend on the window state should behave to prevent frames with unwanted state [1] https://github.com/swaywm/wlroots/pull/1053 Makefile.am | 1 + unstable/xdg-decoration/README| 4 + .../xdg-decoration-unstable-v1.xml| 156 ++ 3 files changed, 161 insertions(+) create mode 100644 unstable/xdg-decoration/README create mode 100644 unstable/xdg-decoration/xdg-decoration-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 4b9a901..71909d8 100644 --- a/Makefile.am +++ b/Makefile.am @@ -17,6 +17,7 @@ unstable_protocols = \ unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \ unstable/xdg-output/xdg-output-unstable-v1.xml \ unstable/input-timestamps/input-timestamps-unstable-v1.xml \ + unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ $(NULL) stable_protocols = \ diff --git a/unstable/xdg-decoration/README b/unstable/xdg-decoration/README new file mode 100644 index 000..73f0c52 --- /dev/null +++ b/unstable/xdg-decoration/README @@ -0,0 +1,4 @@ +xdg_decoration protocol + +Maintainers: +Simon Ser diff --git a/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml new file mode 100644 index 000..378e8ff --- /dev/null +++ b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml @@ -0,0 +1,156 @@ + + + +Copyright © 2018 Simon Ser + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. + + + + + This interface allows a compositor to announce support for server-side + decorations. + + A window decoration is a set of window controls as deemed appropriate by + the party managing them, such as user interface components used to move, + resize and change a window's state. + + A client can use this protocol to request being decorated by a supporting + compositor. + + If compositor and client do not negotiate the use of a server-side + decoration using this protocol, clients continue to self-decorate as they + see fit. + + Warning! The protocol described in this file is experimental and + backward incompatible changes may be made. Backward compatible changes + may be added together with the
[PATCH wayland-protocols v7] unstable: add xdg-decoration protocol
This adds a new protocol to negotiate server-side rendering of window decorations for xdg-toplevels. This allows compositors that want to draw decorations themselves to send their preference to clients, and clients that prefer server-side decorations to request them. This is inspired by a protocol from KDE [1] which has been implemented in KDE and Sway and was submitted for consideration in 2017 [2]. This patch provides an updated protocol with those concerns taken into account. Signed-off-by: Simon Ser [1] https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml [2] https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html --- This was iterated on privately between representatives of Sway and wlroots (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), and Mir (Alan Griffiths). A proof-of-concept of a client and server implementation is available at [1]. Changes from v6 to v7: - Move errors in xdg_toplevel_decoration - Add errors descriptions - Add an error when toplevel is destroyed before decoration - State that objects created with the manager are still valid after destroying the manager - Compositors can no longer ignore set_mode requests, but they can disregard the client's preference - Describe how clients whose preference depend on the window state should behave to prevent frames with unwanted state [1] https://github.com/swaywm/wlroots/pull/1053 Makefile.am | 1 + unstable/xdg-decoration/README| 4 + .../xdg-decoration-unstable-v1.xml| 145 ++ 3 files changed, 150 insertions(+) create mode 100644 unstable/xdg-decoration/README create mode 100644 unstable/xdg-decoration/xdg-decoration-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 4b9a901..71909d8 100644 --- a/Makefile.am +++ b/Makefile.am @@ -17,6 +17,7 @@ unstable_protocols = \ unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \ unstable/xdg-output/xdg-output-unstable-v1.xml \ unstable/input-timestamps/input-timestamps-unstable-v1.xml \ + unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ $(NULL) stable_protocols = \ diff --git a/unstable/xdg-decoration/README b/unstable/xdg-decoration/README new file mode 100644 index 000..73f0c52 --- /dev/null +++ b/unstable/xdg-decoration/README @@ -0,0 +1,4 @@ +xdg_decoration protocol + +Maintainers: +Simon Ser diff --git a/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml new file mode 100644 index 000..cf8cbdb --- /dev/null +++ b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml @@ -0,0 +1,145 @@ + + + +Copyright © 2018 Simon Ser + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. + + + + + This interface allows a compositor to announce support for server-side + decorations. + + A window decoration is a set of window controls as deemed appropriate by + the party managing them, such as user interface components used to move, + resize and change a window's state. + + A client can use this protocol to request being decorated by a supporting + compositor. + + If compositor and client do not negotiate the use of a server-side + decoration using this protocol, clients continue to self-decorate as they + see fit. + + Warning! The protocol described in this file is experimental and + backward incompatible changes may be made. Backward compatible changes + may be added together with the corresponding interface version bump. + Backward incompatible changes are done by bumping the
Re: [PATCH] architecture: Fix EGL URLs
On Fri, 15 Jun 2018 16:58:38 -0300 Matheus Santana wrote: > Replace URL for file which has been moved and remove URL for remove > file. > > Signed-off-by: Matheus Santana > --- > architecture.html | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/architecture.html b/architecture.html > index 6cfa925..2ceed2a 100644 > --- a/architecture.html > +++ b/architecture.html > @@ -213,10 +213,9 @@ point where the change it affects appears on screen. >stack and its buffer sharing mechanism to the generic Wayland API. >The EGL stack is expected to provide an implementation of the >Wayland EGL platform. The full API is in > - the href="https://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-egl.h;>wayland-egl.h > - header. The open source implementation in the mesa EGL stack is > - in href="https://cgit.freedesktop.org/mesa/mesa/tree/src/egl/wayland/wayland-egl/wayland-egl.c;>wayland-egl.c > - and href="https://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/platform_wayland.c;>platform_wayland.c. > + the href="https://cgit.freedesktop.org/wayland/wayland/tree/egl/wayland-egl.h;>wayland-egl.h > + header. The open source implementation in the mesa EGL stack is in > + href="https://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/platform_wayland.c;>platform_wayland.c. > > > Hi, looks good otherwise, but wayland-egl.c wasn't really removed, it migrated to wayland repository. On the other hand, I'm not sure how much worth there is linking to wayland-egl.c since it's just a wrapper now. It might be useful to link to wayland-egl-backend.h and explain how that fits in instead. In any case this patch is nice, so pushed: f045c5c..399627a master -> master Thanks, pq pgpFW2U4hc7Y1.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] .gitlab-ci.yml: collect the distcheck error logs
On Thu, 14 Jun 2018 18:14:14 +0100 Emil Velikov wrote: > From: Emil Velikov > > Currently we issue both check and distcheck, as reportedly there has > been cases in the past one works, while the other doesn't. > > Yet we only collect the check artefacts (test logs). > > Correct that, by picking the distcheck ones as well. > Note: the build-*/wayland*/ directory is purged by distcheck if it runs > successfully. > > Signed-off-by: Emil Velikov > --- > .gitlab-ci.yml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml > index bc1a005..2489665 100644 > --- a/.gitlab-ci.yml > +++ b/.gitlab-ci.yml > @@ -31,5 +31,6 @@ build-native: > when: always > paths: > - build-*/wayland-*.tar.xz > +- build-*/wayland*/_build/sub/*.log > - build-*/*.log > - prefix-* Hi, seems to work ok, pushed: 630c25f..35d0425 master -> master Thanks, pq pgpaXqCD_YhPF.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland content-protection extension
On Monday 18 June 2018 02:23 PM, Pekka Paalanen wrote: On Mon, 18 Jun 2018 13:38:09 +0530 Ramalingam C wrote: On Monday 18 June 2018 01:34 PM, Pekka Paalanen wrote: On Sat, 16 Jun 2018 12:50:52 +0530 Ramalingam C wrote: How does the kernel signal to userspace that the HDCP status has changed? Do you piggyback on the hotplug event? Anything that would require userspace to repeatedly re-read properties without any events triggering it is bad design. If nothing is happening, the compositor needs to be able to stay asleep. Pekka, We proposed a uevent from kernel for indicating the HDCP status change. But that didn't fly. Right now the merged interface expects compositor to poll the property state for the runtime failures. Ugh. :-( The SRM table smells very much like compositor configuration, especially because a) it is global state: you cannot program two different tables to the same connector, and b) the compositor is required to save it and use it later for all clients(?). One can also envision a security issue, if a system allows third party apps: an app could install a fake SRM table with a fake date. Compositor is expected to store the latest SRM in the non-volatile and update with only newest versions. And it will supply the latest version to kernel(irrespective of what version is provided by app). This caching is not per connector. SRM table itself provides the version of it. and The validity of an SRM is established by verifying the integrity of its signature with the Digital Content Protection LLC public key, which is specified by the Digital Content Protection LLC. So no fake SRM will be accepted. Right, so I would propose to make that completely separate. Ok. So how that should be implemented? As another protocol extension? Thanks, Ram. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Makefile.am: add include dir for AC_CONFIG_MACRO_DIR to work
On Mon, 18 Jun 2018 08:23:42 +0100 Emil Velikov wrote: > On 15 June 2018 at 15:06, Maciej Wolny wrote: > > On 05/06/18 11:53, Maciej Wolny wrote: > >> da331647269ee9d73c4008ae901d107320bdc8d1 added a compatiblity macro for > >> old versions of pkg-config. However, the file in which that macro > >> resides was not included. From the autoconf docs: "Note that if you use > >> aclocal from Automake to generate aclocal.m4, you must also set > >> ACLOCAL_AMFLAGS = -I dir in your top-level Makefile.am.". > >> --- > >> Makefile.am | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/Makefile.am b/Makefile.am > >> index 4b9a901..1aa13cf 100644 > >> --- a/Makefile.am > >> +++ b/Makefile.am > >> @@ -1,3 +1,5 @@ > >> +ACLOCAL_AMFLAGS = -I m4 > >> + > >> unstable_protocols = > >>\ > >> unstable/pointer-gestures/pointer-gestures-unstable-v1.xml > >>\ > >> unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml > >>\ > >> > > > > I'm sorry, I didn't specify - this is a patch for wayland-protocols. > That helps clear some confusion. Thanks > > Reviewed-by: Emil Velikov Pushed: c5f0f1a..dae2a3d master -> master Thanks, pq pgpIqdOsCTfik.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland content-protection extension
On Mon, 18 Jun 2018 13:38:09 +0530 Ramalingam C wrote: > On Monday 18 June 2018 01:34 PM, Pekka Paalanen wrote: > > On Sat, 16 Jun 2018 12:50:52 +0530 > > Ramalingam C wrote: > > > > How does the kernel signal to userspace that the HDCP status has > > changed? Do you piggyback on the hotplug event? > > > > Anything that would require userspace to repeatedly re-read properties > > without any events triggering it is bad design. If nothing is > > happening, the compositor needs to be able to stay asleep. > Pekka, > > We proposed a uevent from kernel for indicating the HDCP status change. > But that didn't fly. Right now the merged interface expects compositor > to poll > the property state for the runtime failures. Ugh. :-( > > The SRM table smells very much like compositor configuration, > > especially because a) it is global state: you cannot program two > > different tables to the same connector, and b) the compositor is > > required to save it and use it later for all clients(?). One can also > > envision a security issue, if a system allows third party apps: an app > > could install a fake SRM table with a fake date. > Compositor is expected to store the latest SRM in the non-volatile and > update with only newest versions. > And it will supply the latest version to kernel(irrespective of what > version is provided by app). This caching is not per connector. > SRM table itself provides the version of it. and The validity of an SRM > is established by verifying the integrity of its > signature with the Digital Content Protection LLC public key, which is > specified by the Digital > Content Protection LLC. So no fake SRM will be accepted. Right, so I would propose to make that completely separate. Thanks, pq pgp41_ZLIdhDX.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v6] unstable: add xdg-decoration protocol
On Sun, Jun 17, 2018 at 06:22:11PM -0400, Simon Ser wrote: > On June 15, 2018 5:56 PM, Jonas Ådahl wrote: > > Hi, > > Hi Jonas, > > Thanks for you feedback. > > > What about when clients change their "preference" in combination with a > > window state change? > > > > Lets assume the compositor prefers server side, and the current state > > is that the client has set the preferred state to "server_side" as well. > > > > For client driven state change: > > > > client: unset_maximize > > server: configure(server_side, unmaximized) > > client: set_state(client_side) > > server: configure(client_side, unmaximized) > > > > And for the server driven state change: > > > > server: configure(server_side, unmaximized) > > client: set_state(client_side) > > server: configure(client_side, unmaximized) > > > > We'll temporarly have a unwanted configured state after the first > > configures. > > That's right. This always happens when the client decides to change its > preference on its own (e.g. when the window contents changes), not just when > it's because of a window state change. The "infinite loop" issue you describe > in case the server always sends configure events is specific to clients > change their preference because of a window state change, though. If it'd change its preference out of nowhere (e.g. configuration change), then I wouldn't count that as a glitch really, and the transition would be glitch free (the compositor and client always have the same idea of how each frame is drawn). The thing to avoid so is the glitch where one or two (or so) have the intermediate unwanted state. > > > I guess this is work-around:able by requiring the compositor to always > > reply with a configure() event for each (un)set_state() request no > > matter whether any state changed or not (except for the initial state!), > > and require the client to always ignore the configure() event when it > > knows it will change its state preference. > > > > Requiring that is a bit awkward, or what do you think? It'll make an > > extra back-and-forth between the compositor and client a necessity when > > a decoration state preference depends on some other window state. I > > don't have a better alternative in mind though. > > I'm okay with requiring the compositor to send configure events, but the > second > requirement seems a little weird phrased this way. I don't think we can avoid > the extra roundtrip anyway, because the compositor cannot guess the client's > preferred mode depending on its current state (and we really don't want to > make > the compositor able to do that). > > So, the client is aware that a set_mode or unset_mode request will always > trigger a configure event. The client is thus responsible for preventing > infinite loops to happen, and this might mean to prevent requests from being > sent if they don't change the client's current preferred mode (in case the > client changes its mode depending on the window state). > > In the protocol, we already have: > > > After requesting a decoration mode, the compositor will respond by > > emitting a xdg_surface.configure event. > > So I think the requirement is already covered by this sentence. We could add > "the compositor will always respond" if we want to play it safe. > > However, we also have: > > > The compositor can ignore this request. > > So we should probably change it to something like: > > > The compositor can decide not to use the client's mode and enforce a > > different > > mode instead. > > What do you think? The rewording sounds good to me. What about adding some paragraph about the "race condition" and how to work around it? Jonas > > Simon ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland content-protection extension
On Monday 18 June 2018 01:34 PM, Pekka Paalanen wrote: On Sat, 16 Jun 2018 12:50:52 +0530 Ramalingam C wrote: On Friday 15 June 2018 04:16 PM, Nautiyal, Ankit K wrote: Hi Pekka, Thanks for the suggestions. Please find my responses inline: On 6/15/2018 1:16 PM, Pekka Paalanen wrote: On Wed, 13 Jun 2018 10:34:45 + "Nautiyal, Ankit K" wrote: Hi All, I am working on wayland content-protection protocol extension, to enable content-protection (HDCP1.4, HDCP2.2) in wayland. DRM layer already has support for HDCP1.4 and patches for HDCP2.2 are in review :https://patchwork.freedesktop.org/series/39596/ From what I heard, the hardware will continuously or periodically confirm the protection status of the display data stream on the wire, and it is possible that the hardware status will change at runtime. The very least hotplug is a thing. Yes agreed. The app will have a listener to content protection status. It makes sense to have the even named as on/off. Yes. HDCP Link status can change in run time for any connector. So Compositor is expected to check the current HDCP status of all connectors on those protected surface is rendered. And inform the client with runtime cumulative HDCP protection for that protected surface. How does the kernel signal to userspace that the HDCP status has changed? Do you piggyback on the hotplug event? Anything that would require userspace to repeatedly re-read properties without any events triggering it is bad design. If nothing is happening, the compositor needs to be able to stay asleep. Pekka, We proposed a uevent from kernel for indicating the HDCP status change. But that didn't fly. Right now the merged interface expects compositor to poll the property state for the runtime failures. As I understand the SRM messages will be delivered with content, to the kernel. There is a separate Connector proprty of type blob for this. SRM can be transmitted with a cable TV signal. It might be keep on getting updated as more devices, keep on adding to the table. SRM table will be updated by DCP LLC as and when device is revocated. And updated SRM table will be shared to all protected content providers. So the protected content player needs to supply the SRM to the kernel for the revocation step in authentication, through compositor. Compositor has to store the latest version in non-volatile memory and expected to provide this information as a blob to all the connector for the authentication at the kernel. Storing in non-volatile is required to fulfill the HDCP spec. That sounds like the SRM table should not be part of a Wayland extension. Let's say you have two apps: A and B. Vendor of A is shipping an updated SRM table. Vendor of B is not shipping it yet, so it has an outdated SRM table. A user launches app A, then app B, to watch both. A trivial protocol implementation will have app B overwrite the SRM table with an outdated version. The SRM table smells very much like compositor configuration, especially because a) it is global state: you cannot program two different tables to the same connector, and b) the compositor is required to save it and use it later for all clients(?). One can also envision a security issue, if a system allows third party apps: an app could install a fake SRM table with a fake date. Compositor is expected to store the latest SRM in the non-volatile and update with only newest versions. And it will supply the latest version to kernel(irrespective of what version is provided by app). This caching is not per connector. SRM table itself provides the version of it. and The validity of an SRM is established by verifying the integrity of its signature with the Digital Content Protection LLC public key, which is specified by the Digital Content Protection LLC. So no fake SRM will be accepted. So I would recommend keeping the SRM table updates out of this protocol extension and work on that separately. Also, do you have a way or requirement to authenticate the SRM table? Is it signed? How do you install the verification key? * Downstream topology handling by the compositor, in case of, HDCP repeaters. Why would that be an issue affecting the protocol? The topology information needs to be sent to client, in case of repeater. I thin Ram can shed more light on it. This interface is required to implement the repeater using the intel platforms. In such scenario, each connectors will be considered as one HDCP downstream ports. Compositor and kernel will be used for the HDCP authentication of the downstream devices. And a userspace module can implement upstream port's HDCP authentication through wireless/wired channel. So this interface will be used for collecting the downstream devices in each ports and provide them to the upstream hdcp device for the repeater authentication step. I will try to compose complete flow in a mail. That will help us to be in sync about the design we need and feasible. Good,
Re: Wayland content-protection extension
On Sat, 16 Jun 2018 12:50:52 +0530 Ramalingam C wrote: > On Friday 15 June 2018 04:16 PM, Nautiyal, Ankit K wrote: > > > > Hi Pekka, > > > > Thanks for the suggestions. Please find my responses inline: > > > > On 6/15/2018 1:16 PM, Pekka Paalanen wrote: > >> On Wed, 13 Jun 2018 10:34:45 + > >> "Nautiyal, Ankit K" wrote: > >> > >>> Hi All, > >>> > >>> I am working on wayland content-protection protocol extension, to > >>> enable content-protection (HDCP1.4, HDCP2.2) in wayland. DRM layer > >>> already has support for HDCP1.4 and patches for HDCP2.2 are in > >>> review :https://patchwork.freedesktop.org/series/39596/ > >>> > >> From what I heard, the hardware will continuously or periodically > >> confirm the protection status of the display data stream on the wire, > >> and it is possible that the hardware status will change at runtime. The > >> very least hotplug is a thing. > > > > Yes agreed. The app will have a listener to content protection status. > > It makes sense to have the even named as on/off. > Yes. HDCP Link status can change in run time for any connector. > So Compositor is expected to check the current HDCP status of all > connectors on those protected surface is rendered. > And inform the client with runtime cumulative HDCP protection for that > protected surface. How does the kernel signal to userspace that the HDCP status has changed? Do you piggyback on the hotplug event? Anything that would require userspace to repeatedly re-read properties without any events triggering it is bad design. If nothing is happening, the compositor needs to be able to stay asleep. > > As I understand the SRM messages will be delivered with content, to > > the kernel. > > There is a separate Connector proprty of type blob for this. > > SRM can be transmitted with a cable TV signal. It might be keep on > > getting updated as more devices, keep on adding to the table. > > > > SRM table will be updated by DCP LLC as and when device is revocated. > And updated SRM table will be shared to all protected content providers. > So the protected content player needs to supply the SRM to the kernel > for the revocation step in authentication, through compositor. > > Compositor has to store the latest version in non-volatile memory and > expected to provide this information as a > blob to all the connector for the authentication at the kernel. Storing > in non-volatile is required to fulfill the HDCP spec. That sounds like the SRM table should not be part of a Wayland extension. Let's say you have two apps: A and B. Vendor of A is shipping an updated SRM table. Vendor of B is not shipping it yet, so it has an outdated SRM table. A user launches app A, then app B, to watch both. A trivial protocol implementation will have app B overwrite the SRM table with an outdated version. The SRM table smells very much like compositor configuration, especially because a) it is global state: you cannot program two different tables to the same connector, and b) the compositor is required to save it and use it later for all clients(?). One can also envision a security issue, if a system allows third party apps: an app could install a fake SRM table with a fake date. So I would recommend keeping the SRM table updates out of this protocol extension and work on that separately. Also, do you have a way or requirement to authenticate the SRM table? Is it signed? How do you install the verification key? > > > >>> * Downstream topology handling by the compositor, in case of, > >>> HDCP repeaters. > >> Why would that be an issue affecting the protocol? > > > > The topology information needs to be sent to client, in case of repeater. > > I thin Ram can shed more light on it. > This interface is required to implement the repeater using the intel > platforms. > In such scenario, each connectors will be considered as one HDCP > downstream ports. > Compositor and kernel will be used for the HDCP authentication of the > downstream devices. > And a userspace module can implement upstream port's HDCP authentication > through wireless/wired channel. > > So this interface will be used for collecting the downstream devices in > each ports and provide them > to the upstream hdcp device for the repeater authentication step. > > I will try to compose complete flow in a mail. That will help us to be > in sync about the design we need and feasible. Good, because I really didn't quite understand who does what now in there. Thanks, pq pgpCrlxO8_SjE.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Makefile.am: add include dir for AC_CONFIG_MACRO_DIR to work
On 15 June 2018 at 15:06, Maciej Wolny wrote: > On 05/06/18 11:53, Maciej Wolny wrote: >> da331647269ee9d73c4008ae901d107320bdc8d1 added a compatiblity macro for >> old versions of pkg-config. However, the file in which that macro >> resides was not included. From the autoconf docs: "Note that if you use >> aclocal from Automake to generate aclocal.m4, you must also set >> ACLOCAL_AMFLAGS = -I dir in your top-level Makefile.am.". >> --- >> Makefile.am | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/Makefile.am b/Makefile.am >> index 4b9a901..1aa13cf 100644 >> --- a/Makefile.am >> +++ b/Makefile.am >> @@ -1,3 +1,5 @@ >> +ACLOCAL_AMFLAGS = -I m4 >> + >> unstable_protocols = >> \ >> unstable/pointer-gestures/pointer-gestures-unstable-v1.xml >> \ >> unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml >> \ >> > > I'm sorry, I didn't specify - this is a patch for wayland-protocols. That helps clear some confusion. Thanks Reviewed-by: Emil Velikov -Emil ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
