[PATCH] architecture: Fix EGL URLs
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 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 https://cgit.freedesktop.org/mesa/mesa/tree/src/egl/wayland/wayland-egl/wayland-egl.c;>wayland-egl.c - and https://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/platform_wayland.c;>platform_wayland.c. + the 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 + https://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/platform_wayland.c;>platform_wayland.c. -- 2.1.4 ___ 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
Hi, 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. 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. Jonas On Mon, Jun 11, 2018 at 05:03:36AM -0400, Simon Ser wrote: > Hi Jonas, > > Any news about this? > > Thanks, > > --- > Simon Ser > https://emersion.fr > > On June 4, 2018 9:11 AM, Simon Ser wrote: > > Hi Jonas, > > > > Did you have the chance to have a look at this version? > > > > Thanks, > > --- > > Simon Ser > > https://emersion.fr > > > > On May 28, 2018 8:04 AM, Simon Ser wrote: > > > Hi Jonas, > > > > > > What do you think of this new proposal? > > > > > > Thanks, > > > --- > > > Simon Ser > > > https://emersion.fr > > > > > > On May 20, 2018 11:39 AM, Simon Ser wrote: > > > > 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 v5 to v6: > > > > - Add back the set_mode request, add a new unset_mode request > > > > > > > > This version fixes the race condition Jonas pointed out in his v4 > > > > review. > > > > > > > > I believe there were two client use-cases for the set_mode request in > > > > v4: > > > > - Request a specific preferred mode, and ignore the compositor > > > > preference. This > > > > is still possible since the set_mode request is back. > > > > - Use the compositor's preference, as the client doesn't have one. In > > > > v4 this > > > > was achieved by sending a set_mode request with the mode received in > > > > the > > > > preferred_mode event. In this version this is achieved by not > > > > unsetting the > > > > mode (either by not sending any set_mode request, or by sending an > > > > unset_mode > > > > request). > > > > > > > > The race condition could happen in v4 if the compositor sent a > > > > preferred_mode > > > > event and couldn't decide if the client would want to keep its current > > > > mode or > > > > change it (ie. should the compositor wait for a set_mode request or > > > > not?). This > > > > new design doesn't let the client know the compositor's preferred mode. > > > > When the > > > > compositor changes its preferred mode, it already knows if the client > > > > prefers to > > > > use it or to use its own - and thus can directly send a configure event > > > > if > > > > necessary. > > > > > > > > I believe this lso simplifies the protocol and makes it easier to > > > > understand. I > > > > don't think there are any regressions due to the fact that the client > > > > doesn't > > > > know anymore the compositor's preferred mode. > > > > > > > > [1] https://github.com/swaywm/wlroots/pull/638 > > > > > > > > Makefile.am | 1 + > > > > unstable/xdg-decoration/README| 4 + > > > > .../xdg-decoration-unstable-v1.xml| 145
Re: [PATCH] Makefile.am: add include dir for AC_CONFIG_MACRO_DIR to work
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. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland content-protection extension
On Fri, 15 Jun 2018 15:06:05 +0200 Arnaud Vrac wrote: > On Fri, Jun 15, 2018 at 10:08 AM Pekka Paalanen wrote: > > > > On Thu, 14 Jun 2018 13:09:24 +0200 > > Arnaud Vrac wrote: > > > > > On Wed, Jun 13, 2018 at 12:34 PM, 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/ > > > > > > > > As per the IRC discussion on #wayland about content protection > > > > extension for > > > > Wayland (yesterday, 12th June 2018) , please find below the agreed > > > > points: > > > > > > > > > > Hi Ankit, > > > > > > Thanks for working on this, overall I agree with your design, which > > > provides a first level of security when more advanced output > > > protection enforcement is not available. I missed the discussion on > > > IRC so I'm sorry if my comments are reduntant. > > > > > > I see one problem with this approach of hiding the output state to the > > > client: there is no way to choose the content in advance based on the > > > output protection capabilities. > > > > Hi, > > > > generally there cannot be in-advance information. Until a window is > > actually mapped, the compositor will not know where it will show up as > > the scenegraph may change due to the client, other clients, or hotplug, > > etc. > > > > It would be a narrow special case compositor that would know > > before-hand what the protection for a surface would be. > > > > I have assumed that applications are able to switch the content quality > > at runtime to match changes in the protection status. If this is not > > the case, the issue needs to be brought up now. > > > > OTOH, an application can always map the window with non-sensitive > > content to see what it will get. I don't think that would be a problem > > if the system design otherwise guarantees that the protection status > > does not change while the window is mapped. However, I don't think we > > should make the demand of status not changing in the protocol extension. > > Hi Pekka, > > A content provider can provide many stream versions for the same > content, based on the codec, profile, level supported by the video > decoders of the platform, the capabilities of the display hardware > (max resolution, hdcp level support, hdr modes), and the capabilities > of the connected outputs. There's no point in serving 4k content if > the display or decoders do not support it, or if the display block or > connected sink does not support the required protection level. > > So I believe wl_output (or an extension of it via a separate protocol) > should expose its supported protection levels (which would be the > intersection of the display block and the connected sink > capabilities). This does require negotiating with the connected output > for its protection capabilities beforehand. Does it have to be per wl_output, why not just a single global maximum level? After all, clients generally do not get to pick where they show, so knowing per wl_output does not seem useful. (Btw. anything you want per-connector is per-wl_output, so that is right, even for clone mode IMO.) I'm still not quite sure what the benefit is. You can hotplug a display with higher capabilities at any time. Or is that out of scope? Btw. is the content itself can carry something (SRM table?) that affects the possible protection level, would you need to report maximum possible protection level per surface? > > > Most content providers have the same > > > content available in multiple qualities, and the better qualities will > > > be available based on the device and output capabilities. > > > > > > Since the client has no way of knowing on which output the video > > > surface will be shown, the maximum protection level supported by all > > > outputs should be exposed to the client, and the client can then > > > determine if it's worth switching to a higher quality, and if there's > > > a chance it will be displayed on at least one output. > > > > I'm not sure knowing the chance is possible given how the DRM UAPI for > > it has been designed: you will know only after attempting to enable a > > specific content type whether you got what you asked for. If you ask > > for Type 1 and receive "no", that won't tell you anything about whether > > Type 0 would succeed, so the compositor has to try again. I'm told that > > HDCP negotiation can take a noticeable amount of time, so I assume > > compositors would not want to attempt it speculatively. > > > > At least I am assuming that a compositor would not want to enable HDCP > > unless it is actually wanted. If a compositor is enabling maximum > > protection at all times, then it would know the chances. > > You're right, enabling HDCP can take time and even cause screen >
Re: Wayland content-protection extension
On Fri, Jun 15, 2018 at 10:08 AM Pekka Paalanen wrote: > > On Thu, 14 Jun 2018 13:09:24 +0200 > Arnaud Vrac wrote: > > > On Wed, Jun 13, 2018 at 12:34 PM, 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/ > > > > > > As per the IRC discussion on #wayland about content protection extension > > > for > > > Wayland (yesterday, 12th June 2018) , please find below the agreed points: > > > > > > > Hi Ankit, > > > > Thanks for working on this, overall I agree with your design, which > > provides a first level of security when more advanced output > > protection enforcement is not available. I missed the discussion on > > IRC so I'm sorry if my comments are reduntant. > > > > I see one problem with this approach of hiding the output state to the > > client: there is no way to choose the content in advance based on the > > output protection capabilities. > > Hi, > > generally there cannot be in-advance information. Until a window is > actually mapped, the compositor will not know where it will show up as > the scenegraph may change due to the client, other clients, or hotplug, > etc. > > It would be a narrow special case compositor that would know > before-hand what the protection for a surface would be. > > I have assumed that applications are able to switch the content quality > at runtime to match changes in the protection status. If this is not > the case, the issue needs to be brought up now. > > OTOH, an application can always map the window with non-sensitive > content to see what it will get. I don't think that would be a problem > if the system design otherwise guarantees that the protection status > does not change while the window is mapped. However, I don't think we > should make the demand of status not changing in the protocol extension. Hi Pekka, A content provider can provide many stream versions for the same content, based on the codec, profile, level supported by the video decoders of the platform, the capabilities of the display hardware (max resolution, hdcp level support, hdr modes), and the capabilities of the connected outputs. There's no point in serving 4k content if the display or decoders do not support it, or if the display block or connected sink does not support the required protection level. So I believe wl_output (or an extension of it via a separate protocol) should expose its supported protection levels (which would be the intersection of the display block and the connected sink capabilities). This does require negotiating with the connected output for its protection capabilities beforehand. > > Most content providers have the same > > content available in multiple qualities, and the better qualities will > > be available based on the device and output capabilities. > > > > Since the client has no way of knowing on which output the video > > surface will be shown, the maximum protection level supported by all > > outputs should be exposed to the client, and the client can then > > determine if it's worth switching to a higher quality, and if there's > > a chance it will be displayed on at least one output. > > I'm not sure knowing the chance is possible given how the DRM UAPI for > it has been designed: you will know only after attempting to enable a > specific content type whether you got what you asked for. If you ask > for Type 1 and receive "no", that won't tell you anything about whether > Type 0 would succeed, so the compositor has to try again. I'm told that > HDCP negotiation can take a noticeable amount of time, so I assume > compositors would not want to attempt it speculatively. > > At least I am assuming that a compositor would not want to enable HDCP > unless it is actually wanted. If a compositor is enabling maximum > protection at all times, then it would know the chances. You're right, enabling HDCP can take time and even cause screen flickering. To avoid this it is preferable to negotiate the highest level supported to avoid switching at runtime. This is not required though to query the sink HDCP capabilities, so exposing the wl_output HDCP capabilities is still possible without enabling encryption. > > Then again, I suppose if a compositor knows what the protection status > will be, it can send events for it even before mapping the window. I > just don't want to require it, and I would not want to imply that apps > can rely on it. Unfortunately all the major content providers already require this for their "official" app to work correctly and expose the proper video streams (and their PlayReady/Widevine/foo DRM license, which contains the stream output protection level requirement). I don't see how they could handle this use-case efficiently without this information. > > All this
Re: [PATCH weston v10 0/1] Head-based output configuration API a.k.a clone mode infrastructure
On Wed, 6 Jun 2018 14:30:04 +0300 Pekka Paalanen wrote: > From: Pekka Paalanen > > Hi all, > > all of the clone mode infrastructure has landed. There is just this one > patch remaining that actually allows one to use it through weston.ini. > > Mind, this may be hard to test, because most contemporary PC graphics > devices might not support shared-CRTC clone mode at all. So if you try > this and face a frozen or black screen, it's likely that your hardware > just doesn't support this. An indication of no support is an error in > Weston log saying "atomic: couldn't commit new state" or "set mode > failed". Unfortunately, Weston does not recover from modeset failures > yet, but you should be able to quit gracefully with the usual > Ctrl+Alt+Backspace. You can still see in the Weston log how Weston tried > to configure clone mode. > > I have used an i.MX6 based system to test. Hi, Ville Syrjälä was kind enough to give a list of Intel support: i915 cloning support: gen2: DVO(non-LVDS encoders)+VGA gen3/4: nope g4x: VGA+HDMI HDMI+HDMI ilk-ivb,vlv: VGA+HDMI hsw+: nope Thanks, pq > This is also available in a GitLab(!) branch here along with the other > patch (force-on output) depending on this one: > https://gitlab.freedesktop.org/pq/weston/commits/clonemode-v10 > > > The old Phabricator task (obsolete): > https://phabricator.freedesktop.org/T7727 > The GitLab issue: > https://gitlab.freedesktop.org/wayland/weston/issues/22 > > > Thanks, > pq > > Pekka Paalanen (1): > weston: support clone mode on DRM-frontend > > compositor/main.c | 492 > ++--- > man/weston-drm.man | 12 ++ > 2 files changed, 484 insertions(+), 20 deletions(-) > pgpE4QqwaNgiA.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 Fri, 15 Jun 2018 16:16:26 +0530 "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/ > >> Note: Some things that are still open, but will be discussed later: > >> * SRM table (list of backlisted Monitors/Sinks) which need to > >> be sent from the client side. > > That list could be big, right? I mean more than, say, 1 kB. If yes, you > > would want to use a shared memory buffer. > > > > Why does the client have to send it? Can it not be just compositor > > configuration? > The revocation list will be big can be maximum of 5K. > > 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. Is that only because of the possibility of repeaters? I.e. you give a repeater the blacklist and then that will check if it forwards the content to its downstream devices or not? Not for a display to refuse itself if it finds itself on the list? > >> * 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. But why? What if the compositor uses non-HDCP ways that still comply with the content type requirements to show the content? How do you describe that the compositor is showing the content one protected output and another unprotected output but blurred? Suddenly this got much much more complicated, I doubt I'll have time for that. Thanks, pq pgpII8ASUyQJZ.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 Thu, 14 Jun 2018 13:09:24 +0200 Arnaud Vrac wrote: > On Wed, Jun 13, 2018 at 12:34 PM, 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/ > > > > As per the IRC discussion on #wayland about content protection extension for > > Wayland (yesterday, 12th June 2018) , please find below the agreed points: > > > > Hi Ankit, > > Thanks for working on this, overall I agree with your design, which > provides a first level of security when more advanced output > protection enforcement is not available. I missed the discussion on > IRC so I'm sorry if my comments are reduntant. > > I see one problem with this approach of hiding the output state to the > client: there is no way to choose the content in advance based on the > output protection capabilities. Hi, generally there cannot be in-advance information. Until a window is actually mapped, the compositor will not know where it will show up as the scenegraph may change due to the client, other clients, or hotplug, etc. It would be a narrow special case compositor that would know before-hand what the protection for a surface would be. I have assumed that applications are able to switch the content quality at runtime to match changes in the protection status. If this is not the case, the issue needs to be brought up now. OTOH, an application can always map the window with non-sensitive content to see what it will get. I don't think that would be a problem if the system design otherwise guarantees that the protection status does not change while the window is mapped. However, I don't think we should make the demand of status not changing in the protocol extension. > Most content providers have the same > content available in multiple qualities, and the better qualities will > be available based on the device and output capabilities. > > Since the client has no way of knowing on which output the video > surface will be shown, the maximum protection level supported by all > outputs should be exposed to the client, and the client can then > determine if it's worth switching to a higher quality, and if there's > a chance it will be displayed on at least one output. I'm not sure knowing the chance is possible given how the DRM UAPI for it has been designed: you will know only after attempting to enable a specific content type whether you got what you asked for. If you ask for Type 1 and receive "no", that won't tell you anything about whether Type 0 would succeed, so the compositor has to try again. I'm told that HDCP negotiation can take a noticeable amount of time, so I assume compositors would not want to attempt it speculatively. At least I am assuming that a compositor would not want to enable HDCP unless it is actually wanted. If a compositor is enabling maximum protection at all times, then it would know the chances. Then again, I suppose if a compositor knows what the protection status will be, it can send events for it even before mapping the window. I just don't want to require it, and I would not want to imply that apps can rely on it. All this really becomes a question of scope for the protocol extension, how narrow or wide the use cases will be. If we narrow down the intended use cases, we could have more restrictions written down in the specification. I have a funny thought that normal desktop applications that show sensitive information like password lists might be able to use this extension to protect the window content from being leaked to screenshots or such. Of course, such use cases would need consideration right now to set the expectations in the protocol introduction correctly. That use case might well be better served by an extension explicitly designed for it. Thanks, pq pgphlmcyMXvpG.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 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/ > > As per the IRC discussion on #wayland about content protection > extension for Wayland (yesterday, 12th June 2018) , please find below > the agreed points: Hi Ankit, very good to summarize the discussion. > > On exposing connector info to the clients: > * The Client cannot request for content protection on a > specific connector. > * Wayland does not expose connector information to the clients. > Client cannot put a window on a specific connector. > * Compositor always decides where the surfaces are to be shown. > There is no way for a client to audit that the compositor is doing > the right thing, compositor is trusted to begin with and there's no > reason to inspect it. Yes. > On encryption of the content: > * The client will provide unencrypted data to the compositor. > The Kernel encrypts the content just before transmitting through the > wire. > * Once the Sink (the monitor), is authenticated to be HDCP > compliant, the display engine will encrypt the data and send to the > sink, where it will be decrypted. Right. This was a fundamental point to know in designing the extension. This would be good to explain in the introduction of the actual protocol extension XML to set up expectations. Because the compositor will always receive unencrypted content, the compositor must always be a trusted component, including all the libraries it uses and the hardware drivers. > Level of protection required by a client, depends on the type of > content sent by the client to the compositor: > * The Content sent by a client app can be : >Type 0 : Supported by HDCP1.4, and HDCP2.2 >Type 1: Supported by only HDCP2.2 > * Clients just request for content protection and provide the > content type ie Type-0 or Type-1 to the compositor. > * The compositor will check through all connectors of the > intended surface receivers and make sure all connectors support the > given content type. In case if some connector/s do not support a > given content type, there are multiple strategy the compositor can > follow: o do not show the protected content on any of the > connector, return "content_protection failure" to the client. o > show protected content on the supporting connectors, reduce image > quality on unprotected connectors, and return > "content_protection_success" to the client. Rather than protection failed/success, I would word the events more like protection on/off, because I envision that a surface can change the status at runtime. It would be weird to first fail, then succeed, then fail again. The state would change according to where and how the surface is shown at times. The compositor will have a great freedom in deciding on the policy on how to handle protected content. If someone is developing a closed system, they can very well build in assumptions like "the state does not change after mapping" into their compositor and apps. But, I would prefer to leave such requirements out of the protocol specification. 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. > * The display driver will take the call for providing best > possible protection for a given content type. It will never provide > information to the compositor, about which content protection > protocol is used, i.e. compositor will only know if the connector > supports a particular content-type, it would never know if HDCP1.4 or > 2.2 is employed. Right, this confused me at first, but this is your DRM UAPI design. > Scope of the protocol extension: > * The protocol helps client to request for content protection. > The client needs to provide the content type. > * It provides the client with events for > successful/unsuccessful content protection enablement. > * Helps client to disable the content protection, and provide > with success/ fail events. > * The policy for showing the protected content with low > quality, or stop showing the content on unprotected connectors is out > of scope for the protocol. At best it can provide some guidelines/ > specifications, but there's no way to ensure that. > Sounds good. I would formulate the protocol like this: - a global interface with a request to create a protection object; has arguments wl_surface and content type - the protection object interface has events for protection on/off, initially protection being off; it has a destructor, which will remove the requirement for
Re: [PATCH libinput] CI: Hook up GitLab CI
Hi Peter, On Fri, Jun 15, 2018 at 8:59 AM Peter Hutterer wrote: > > From: Benjamin Tissoires > > The main tasks it does is build on a few different distros as well as build > with the various build options to make sure they work.It doesn't (yet) run the > test suite runner because that one mostly requires device nodes to operate on. > > Most of the fancy is to get the docker images ready. A dnf update takes > forever, so we don't want to do that on 10 different machines. So instead we > build docker images with all the bits pre-installed, push that to the registry > and use those images for testing. > > To speed things up, we only do that when the current image is older than a > week. And we only do that when we push to libinput proper, so a merge request > or pushing to your private gitlab repo will never trigger a docker image > update - it will trigger the tests and use the docker images tough. > > Co-authored-by: Peter Hutterer > Signed-off-by: Benjamin Tissoires I have one tiny issue, I already mentioned it over IRC but posting here for posterity. > --- > .gitlab-ci.yml | 411 > + > 1 file changed, 411 insertions(+) > create mode 100644 .gitlab-ci.yml > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml > new file mode 100644 > index ..15fe0594 > --- /dev/null > +++ b/.gitlab-ci.yml > @@ -0,0 +1,411 @@ > +# vim: set expandtab shiftwidth=2 tabstop=8 textwidth=0: > +# > +# This is a bit complicated for two reasons: > +# - we really want to run dnf/apt/... only once, updating on the test runner > for > +# each job takes forever. So we create a docker image for each distribution > +# tested, then run the tests on this docker image. > +# > +# Creating a docker image is time-consuming, so we only do so for pushes to > +# libinput directly (not merge requests) and if the current image is 'old'. > +# > +# - GitLab only allows one script: set per job but we have a bunch of > commands > +# we need to re-run for each build (meson && ninja && etc). YAML cannot > merge > +# arrays templates so we're screwed. > +# > +# So instead we use a default_build template and override everything with > +# variables. The only two variables that matter: > +# MESON_PARAMS=-Denable-something=true > +# NINJA_ARGS=dist ... to run 'ninja -C builddir dist' > +# Note that you cannot use scripts: in any target if you expect > default_build > +# to work. > +# > +# > +# All jobs must follow the naming scheme of > +# :@activity: > +# e.g. fedora:28@build-default > + > +stages: > + - docker_check # check if the current docker images are up to date > + - docker_prep # rebuild the docker images if previous step failed > + - build # for actually building things > + > +variables: > + MESON_BUILDDIR: builddir > + NINJA_ARGS: '' > + MESON_PARAMS: '' > + FEDORA_RPMS: 'git gcc gcc-c++ meson check-devel libudev-devel > libevdev-devel doxygen graphviz valgrind binutils libwacom-devel cairo-devel > gtk3-devel glib2-develmtdev-devel' > + UBUNTU_DEBS: 'git gcc g++ meson check libudev-dev libevdev-dev > doxygen graphviz valgrind binutils libwacom-dev libcairo2-dev > libgtk-3-dev libglib2.0-dev libmtdev-dev' > + FEDORA_DOCKER_IMAGE: > $CI_REGISTRY/libinput/$CI_PROJECT_NAME/fedora/$FEDORA_VERSION:latest > + UBUNTU_DOCKER_IMAGE: > $CI_REGISTRY/libinput/$CI_PROJECT_NAME/ubuntu/$UBUNTU_VERSION:latest > + # When using docker-in-docker (dind), it's wise to use the overlayfs driver > + # for improved performance. > + DOCKER_DRIVER: overlay2 > + > +.default_artifacts: _artifacts > + artifacts: > +name: "meson-logs-$CI_JOB_NAME" > +when: always > +expire_in: 1 week > +paths: > + - $MESON_BUILDDIR/meson-logs > + > +# The default build instructions > +.default_build: _build > + script: > + - rm -rf $MESON_BUILDDIR > + - meson $MESON_BUILDDIR $MESON_PARAMS > + - meson configure $MESON_BUILDDIR > + - ninja -C $MESON_BUILDDIR $NINJA_ARGS > + > +# special rule to not expose the docker creation runners to other users > +# than those who have set up the CI to push on the registry. > +# Users who have write access to libinput/libinput will have write > +# access to the registry, so the libinput/libinput is a catch-all for > +# our core developers. > +# > +# we can add as many users as we want by adding a new line like: > +# - $GITLAB_USER_LOGIN == "someone" > +.restrict_docker_creation: _docker_creation > + only: > +variables: > + # Note: this is a set of logical OR, not AND > + - $CI_PROJECT_PATH == "libinput/libinput" > + > +# > +# # > +# docker check stage# > +# # > +# > + >
[PATCH libinput] CI: Hook up GitLab CI
From: Benjamin Tissoires
The main tasks it does is build on a few different distros as well as build
with the various build options to make sure they work.It doesn't (yet) run the
test suite runner because that one mostly requires device nodes to operate on.
Most of the fancy is to get the docker images ready. A dnf update takes
forever, so we don't want to do that on 10 different machines. So instead we
build docker images with all the bits pre-installed, push that to the registry
and use those images for testing.
To speed things up, we only do that when the current image is older than a
week. And we only do that when we push to libinput proper, so a merge request
or pushing to your private gitlab repo will never trigger a docker image
update - it will trigger the tests and use the docker images tough.
Co-authored-by: Peter Hutterer
Signed-off-by: Benjamin Tissoires
---
.gitlab-ci.yml | 411 +
1 file changed, 411 insertions(+)
create mode 100644 .gitlab-ci.yml
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
new file mode 100644
index ..15fe0594
--- /dev/null
+++ b/.gitlab-ci.yml
@@ -0,0 +1,411 @@
+# vim: set expandtab shiftwidth=2 tabstop=8 textwidth=0:
+#
+# This is a bit complicated for two reasons:
+# - we really want to run dnf/apt/... only once, updating on the test runner
for
+# each job takes forever. So we create a docker image for each distribution
+# tested, then run the tests on this docker image.
+#
+# Creating a docker image is time-consuming, so we only do so for pushes to
+# libinput directly (not merge requests) and if the current image is 'old'.
+#
+# - GitLab only allows one script: set per job but we have a bunch of commands
+# we need to re-run for each build (meson && ninja && etc). YAML cannot merge
+# arrays templates so we're screwed.
+#
+# So instead we use a default_build template and override everything with
+# variables. The only two variables that matter:
+# MESON_PARAMS=-Denable-something=true
+# NINJA_ARGS=dist ... to run 'ninja -C builddir dist'
+# Note that you cannot use scripts: in any target if you expect default_build
+# to work.
+#
+#
+# All jobs must follow the naming scheme of
+# :@activity:
+# e.g. fedora:28@build-default
+
+stages:
+ - docker_check # check if the current docker images are up to date
+ - docker_prep # rebuild the docker images if previous step failed
+ - build # for actually building things
+
+variables:
+ MESON_BUILDDIR: builddir
+ NINJA_ARGS: ''
+ MESON_PARAMS: ''
+ FEDORA_RPMS: 'git gcc gcc-c++ meson check-devel libudev-devel libevdev-devel
doxygen graphviz valgrind binutils libwacom-devel cairo-devel gtk3-devel
glib2-develmtdev-devel'
+ UBUNTU_DEBS: 'git gcc g++ meson check libudev-dev libevdev-dev
doxygen graphviz valgrind binutils libwacom-dev libcairo2-dev libgtk-3-dev
libglib2.0-dev libmtdev-dev'
+ FEDORA_DOCKER_IMAGE:
$CI_REGISTRY/libinput/$CI_PROJECT_NAME/fedora/$FEDORA_VERSION:latest
+ UBUNTU_DOCKER_IMAGE:
$CI_REGISTRY/libinput/$CI_PROJECT_NAME/ubuntu/$UBUNTU_VERSION:latest
+ # When using docker-in-docker (dind), it's wise to use the overlayfs driver
+ # for improved performance.
+ DOCKER_DRIVER: overlay2
+
+.default_artifacts: _artifacts
+ artifacts:
+name: "meson-logs-$CI_JOB_NAME"
+when: always
+expire_in: 1 week
+paths:
+ - $MESON_BUILDDIR/meson-logs
+
+# The default build instructions
+.default_build: _build
+ script:
+ - rm -rf $MESON_BUILDDIR
+ - meson $MESON_BUILDDIR $MESON_PARAMS
+ - meson configure $MESON_BUILDDIR
+ - ninja -C $MESON_BUILDDIR $NINJA_ARGS
+
+# special rule to not expose the docker creation runners to other users
+# than those who have set up the CI to push on the registry.
+# Users who have write access to libinput/libinput will have write
+# access to the registry, so the libinput/libinput is a catch-all for
+# our core developers.
+#
+# we can add as many users as we want by adding a new line like:
+# - $GITLAB_USER_LOGIN == "someone"
+.restrict_docker_creation: _docker_creation
+ only:
+variables:
+ # Note: this is a set of logical OR, not AND
+ - $CI_PROJECT_PATH == "libinput/libinput"
+
+#
+# #
+# docker check stage#
+# #
+#
+
+.docker-check: _check
+ stage: docker_check
+ services:
+- docker:dind
+ script:
+# get the full docker image name (CURRENT_DOCKER_IMAGE still has
indirections)
+- DOCKER_IMAGE=$(eval echo "$CURRENT_DOCKER_IMAGE")
+
+# get the date of the current image
+- docker pull $DOCKER_IMAGE
+- IMG_DATE="$(docker inspect -f '{{ .Created }}' $DOCKER_IMAGE | cut -dT
-f1)"
+
+
