[ANNOUNCE] libinput 1.11.2
libinput 1.11.2 is now available. Looks like a large number of fixes but that's deceptive. A third of those are to hook up the GitLab CI infrastructure. Many thanks to Benjamin here for his efforts. Most of the rest are device-specific features: - a trackpoint range entry for the Lenovo X270 - better lid handling for the Lenovo Thinkpad Yoga models - fixed touchpad palm detection on the Lenovo X1 Carbon 6th - pressure rnages for the XPS13 9333 Thanks to Konstantin's patch we now ignore any motion on touch end which should reduce inadvertent pointer movement on touch up. The other fixes are mainly too boring to get into detail for. As usual, the git shortlog is below. Benjamin Tissoires (4): CI: Hook up GitLab CI CI: do not pull images when checking for the creation date CI: speed up the docker_check stage CI: WIP: attempt to clean up the registry before leaving Hans de Goede (1): system-quirks: Add AttrTrackpointRange for Lenovo X270 Konstantin Kharlamov (1): touchpad: ignore motion on finger-up Peter Hutterer (12): doc: point to the gitlab ci file for a list of required packages data: add pressure range/palm threshold for the Dell XPS13 9333 tools: measure touchpad-pressure: prevent division by zero data: don't disable the keyboard on any Thinkpad Yoga models tools: pass a valid grab parameter to list-devices data: lenovo: fix device name for the X1 Carbon 6th touchpad: don't disable tapping on MT_TOOL_PALM tools: add record/replay to --help output doc: fix typo in pointer acceleration docs fallback: cancel the debounce timers during device remove, not destroy GitLab CI: don't use spaces in artifact names libinput 1.11.2 git tag: 1.11.2 https://www.freedesktop.org/software/libinput/libinput-1.11.2.tar.xz MD5: d179b5afbf414b34ce36ffe6ea8a401d libinput-1.11.2.tar.xz SHA1: 79820c8d08ac19f60d336a74ac5afb1cc78f07d4 libinput-1.11.2.tar.xz SHA256: 6b36e1163d306c292ec8359b35aa65431cd29d0a5254923775e8019ff5018107 libinput-1.11.2.tar.xz SHA512: cb6ada877fc3c09f634f3db39d5507e66d4b86c3d632bb8f7498c7b01fdf8372b2053a79b641293900b7fcc0aa4e920f7c830d9c7b2d9ff3cd61c58eb7c20b65 libinput-1.11.2.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.11.2.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
[PATCH weston] simple-dmabuf-drm: fix build with --disable-egl
Signed-off-by: Emilio Pozuelo Monfort --- I tried a build with --disable-egl as I didn't have the headers installed, and it broke here. The EGL usage here seemed optional so I did that, but I didn't run-test the result. If it would make more sense to disable the client if EGL support is disabled I can do that. clients/simple-dmabuf-drm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/clients/simple-dmabuf-drm.c b/clients/simple-dmabuf-drm.c index fcab30e5..1ae3a2dd 100644 --- a/clients/simple-dmabuf-drm.c +++ b/clients/simple-dmabuf-drm.c @@ -863,6 +863,7 @@ create_display(int opts, int format) display->req_dmabuf_immediate = opts & OPT_IMMEDIATE; display->req_dmabuf_modifiers = (format == DRM_FORMAT_NV12); +#if ENABLE_EGL /* * hard code format if the platform egl doesn't support format * querying / advertising. @@ -871,6 +872,7 @@ create_display(int opts, int format) if (extensions && !weston_check_egl_extension(extensions, "EGL_EXT_image_dma_buf_import_modifiers")) display->xrgb_format_found = 1; +#endif display->registry = wl_display_get_registry(display->display); wl_registry_add_listener(display->registry, -- 2.18.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland content-protection extension
On Monday 02 July 2018 07:26 PM, Pekka Paalanen wrote: On Fri, 29 Jun 2018 22:49:56 +0530 Ramalingam C wrote: Hi Pekka, Thanks a lot for making time for reviewing this proposal. On Friday 29 June 2018 06:08 PM, Pekka Paalanen wrote: On Sat, 16 Jun 2018 16:03:20 +0530 Ramalingam C wrote: Hello all, I am trying to call out the complete sequence that we are aiming to achieve. Please correct me if something is missed out. I am hoping that with this sequence and interface we could get the functionalities of HDCP what Arnaud and pekka also wants. Hi Ram, thanks for writing this up. As we discussed Each protected content providers have the same content in different quality. And they want to play each quality in a particular environment only. I am just leaving all other requirement except the HDCP protection for facilitating the discussion on HDCP support for weston. Before going further I would like to clarify that any content those needs to be protected against the copy over wire, can utilize the HDCP encryption. This could be a list of passwords as pekka mentioend or valuable high quality movie. The owner of those content can classify the content Type as 0/1 based on the HDCP version they want to use. As of now HDCP version 1.4 and 2.2 supports are getting added to Linux kernel. By the way, will you be using a future Weston implementation as the prooving vehicle for the kernel UABI? Yes. If so, we need to make sure the Weston implementation is not only a toy example. Absolutely no. We have few designs in infotainment domain using the weston compositor where we need HDCP support. Excellent, that is very useful to know. Also, I suppose the display is not showing content while the HDCP negotiation is on-going, so how will a Wayland compositor now when the picture becomes visible again? Will the KMS pageflip event be not delivered until negotiation ends in success or failure? nope. HDCP authentication doesn't stop the rendering. Unprotected content(Low value) like a frame mentioning that HDCP negotiation is in progress or similar stuff should be rendered by Application until it's HDCP requirements are met. Oh, that's nice. I thought it was something like link training, which I presume would not allow a video signal to be transmitted until it is finished. In fact that will provide the reason for delay(time required for negotiation) in playing the protected content. And the kernel will be keep checking the link protection status, incase of the runtime HDCP failure, "content protection" will be set to "DESIRED" Hence after the success of HDCP authentication, userspace has to continuously poll the "content protection" state in a required frequency for detecting the runtime failures. Ugh, polling. I'm really baffled why sending a kernel event for "content protection" changes was denied. Was it the very idea, or just implementation details? Lack of infrastructure for events other than pageflip and hotplug? That time existing HDCP consumer(chrome) was happy without the events. Now since we feel the need of it as a new consumer we could propose once again. Ok, that would be very nice. It should also reduce the latency to respond to losing protection as that would otherwise depend on the polling rate. Setting "content protection" to UNDESIRED will stop the HDCP protection on a connector. Now we know, HDCP services from kernel. So lets discuss how content provider's hdcp protection requirement could be met in a system with weston compositor. 1. Lets assume APP is a protected movie player. 2. Lets APP has different level of content quality 4k, FullHD, HD. And APP is willing to render 4k content only on HDCP2.2 protected external displays, FullHD content only on HDCP(1.4/2.2) protected external displays and HD content on any display. 3. So APP will classify the content as below: 4K - Type 1 protected content Full HD - Type 0 protected content HD - Unprotected content. Disclaimer: Content owner can classify any content as type 0/1 based on its sensitive nature. 4. When the APP starts it will render the preview of the movies or some other unprotected content to the compositor to display it on connectors 5. At this stage, based on the system mode (Extended/Mirror) connectors for that surface will be decided I guess. Not only at this stage, but continuously on every frame the compositor outputs. 6. Now when a user selects the Type 1 protected content for playing, APP1 will request the weston to create the protected wl_surface with Type 1 requirement mentioned. And also provides the latest SRM to compositor. Let's discuss the SRM separately, I wrote quite lengthily about in the other email just before this one. I understand it needs to be set before any protection is attempted, which makes it suitable to do during app start as early as possible. 7. Now compositor will check whether all intended HDMI and DP
Re: Wayland content-protection extension
On Monday 02 July 2018 07:30 PM, Pekka Paalanen wrote: On Mon, 2 Jul 2018 16:25:28 +0300 Pekka Paalanen wrote: On Fri, 29 Jun 2018 21:41:33 +0530 Ramalingam C wrote: The idea here was that set_srm_table() is a simple API we can easily maintain upstream. The external plugin would check the SRM table dates and signatures and if they pass, call set_srm_table(). The external plugin would also offer the client interface, whether it is Wayland, DBus, or something else, to the video players. I believe this is a design we could the very least agree to in upstream Weston, provided there is a way to test set_srm_table() by feeding a sample SRM table e.g. through a small test plugin in upstream. Oh, and if saving the latest SRM table to persistent memory is needed, the external plugin could do that as well. I forgot to note, the Wayland protocol implementation would be in Weston upstream. There should be no reason to push that out to an external plugin. So Weston upstream would not only offer set_srm_table() but also take care of tracking the protection status, enabling HDCP on Wayland client request and reporting the status to the client. That sounds good! It is only the SRM table management that I am concerned about. And the topology thing, but I know nothing about that yet. At least for SRM handling we have some clarity now. Topology info will be a structure as a blob from kernel. Compositor is expected to pass that to client. We need an API lets say get_hdcp_topology() similar to set_srm_table for passing the downstream topology. Plugin will read it and pass it to clients for their consumption. Thanks, Ram. 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 Monday 02 July 2018 06:55 PM, Pekka Paalanen wrote: On Fri, 29 Jun 2018 21:41:33 +0530 Ramalingam C wrote: Pekka, Thanks a lot for the responses. On Friday 29 June 2018 04:28 PM, Pekka Paalanen wrote: On Mon, 18 Jun 2018 15:56:40 +0530 Ramalingam C wrote: 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. But nothing there requires the use of Wayland for it. Sure, the compositor will have to program the SRM table via KMS, but it doesn't mean the compositor needs to get it by Wayland. True. thats what I meant. I used the word "wayland" loosely. :( The compositor does not care which process provides a SRM table, because: - the SRM table is global and cross-vendor - the SRM table is signed, so no fakes can be provided - the SRM table is versioned/dated, so always the most recent will be in use, regardless of which version a client might propose - clients are happy to use a SRM table that is more recent than what they have themselves Did I misunderstand something? You got it completely. Let me put it in another way: we don't need to standardise a Wayland interface, it could be DBus or something else since there is no connection to window management. I'm also concerned about the maintenance of an authenticated SRM table. Would we have Weston link to a new library to validate signatures? How does Weston load a guaranteed good DCP public key? Where will Weston store and load the SRM tables? DCP public key is static value. Available in the HDCP specs. Storing place for the SRM from weston is not thought about. Hi! Ok. Maybe it's fine that the compositor only keeps the SRM table at runtime and never saves it into persistent memory. I would assume the SRM table support to be both uninteresting to upstream in general, and possibly quite specific to the system where weston is running. Therefore, I would propose the following: Have the SRM table verification, maintenance, and IPC in an external Weston plugin. Actually I am afraid that I am not understanding this part. By this are you referring a library which provides the function pointers for weston compositor for verify the signature, update the latest SRM in Non volatile memory and to get the latest SRM etc? If not please elaborate on this. Weston can load arbitrary plugins as long as the plugin provides a single specific entry point to initialize it. The plugin will have access to all exported API of Weston, both for directly exported functions and via the so-called plugin registry where you can look up a function pointer table for a specific table name. It is possible to write a plugin that lives in a separate repository, so it does not need to be upstreamed. The downside is that the ABI for plugins is not stable, you will likely have to update the plugin for each Weston release. OTOH, this shouldn't be a problem for vendors who would take a specific release of weston and build a product with it. An external plugin will allow vendors to proceed without forking Weston. If the plugin seems upstreamable, that can be handled in due time. The alternative is to modify Weston itself and propose patches upstream. If the patches get accepted, nice. If
Re: Users of libweston?
On Mon, Jul 2, 2018 at 4:10 AM Pekka Paalanen wrote: > On Fri, 29 Jun 2018 10:05:58 -0500 > Matt Hoosier wrote: > > > Hi all, > > > > Pekka's recent comments about wanting to enable set-top boxes built with > > libweston to do DRM content got me to wondering: > > > > Who all is using libweston directly (as opposed to running > /usr/bin/weston > > possibly with custom shells plugins or similar)? For my own purposes, I > > just use the full compositor because it's pretty lean and mean anyway, > and > > I can do what I need by loading plugins. > > Hi Matt, > > I wouldn't be surprised if there weren't many users yet. There is a > huge amount of things I'd like to do before I could comfortably propose > using libweston. I still think it needs to be a goal in mind all the > time though, otherwise we'll never get there. :-) > > IMO the major point of using libweston instead of weston is to be able > to customize the UX any way you want - all the stuff and policy that is > currecntly hardcoded in main.c and the desktop-shell plugin. Making all > configurable is probably not feasible. > > My hope with gaining set-top box etc. use cases is to gather more people > developing for Weston, people who could be dedicated in the long run. > Maybe that could gain us more upstream maintainers. > > > Thanks, > pq > Hi -- Yeah, that all makes sense. I certainly didn't mean to imply any criticism with the question. I wasn't yet following the conversations on wayland-devel when Weston got overhauled to split out its core compositor features as libweston, so I wasn't positive exactly who the intended users are. I suppose that maybe there's little chance that Mutter or Kwin would ever adopt this (although that would be an amazing proof of generality). The question mainly came from my observation that the modularity of the plugin system in Weston seems _so effective_ that it almost completely subsumes the need for using libweston. I run several out-of-tree plugins (one of them providing an alternative to desktop-shell, and a few others doing random runtime things such as integrating with systemd -- yes, I know there's an official Weston plugin for that ;) ), and the /usr/bin/weston entrypoint still seems to hold up very well for all this. The bit about being able to work around policy choices made in main.c does make sense. On the topic of modularity: what was the reason why the libweston overhaul nixed the ability for out-of-tree plugins to contribute new backends? (This is just a curiosity question -- I'm don't have any particular opposition.) Thanks! Matt ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] compositor-headless: Report a more realistic physical size
> On Thu, 12 Apr 2018 09:31:48 +0200
> Johan Klokkhammer Helsing wrote:
>
> > Some clients rely on the physical size to determine the physical DPI. With
> > the
> > previous implementation, we would report 1px==1mm, which is a DPI of 25.4,
> > which is incredibly low.
> >
> > The problem is solved by setting a physical size so the DPI is close to 72
> > instead. If the output is scaled, the DPI is set to the corresponding
> > multiple
> > of 72.
> >
> > This makes the headless backend more usable for automated testing of DPI
> > sensitive functionality such as point sized fonts.
> >
> > Signed-off-by: Johan Klokkhammer Helsing
> > ---
> > libweston/compositor-headless.c | 16
> > 1 file changed, 12 insertions(+), 4 deletions(-)
>
> Hi,
>
> this is a good idea, but could you rebase this patch to master?
>
>
> Thanks,
> pq
Hi,
Would it make sense to change the protocol to allow compositors to send a zero
physical size in case it isn't relevant?
> >
> > diff --git a/libweston/compositor-headless.c
> > b/libweston/compositor-headless.c
> > index 9307a36a..9f1a1a72 100644
> > --- a/libweston/compositor-headless.c
> > +++ b/libweston/compositor-headless.c
> > @@ -180,12 +180,19 @@ err_malloc:
> > return -1;
> > }
> >
> > +static int
> > +physical_size_for_dpi(int pixels, int dpi)
> > +{
> > + static const float mm_per_inch = 25.4;
> > + return pixels * mm_per_inch / dpi;
> > +}
> > +
> > static int
> > headless_output_set_size(struct weston_output *base,
> > int width, int height)
> > {
> > struct headless_output *output = to_headless_output(base);
> > - int output_width, output_height;
> > + int output_width, output_height, output_dpi;
> >
> > /* We can only be called once. */
> > assert(!output->base.current_mode);
> > @@ -207,9 +214,10 @@ headless_output_set_size(struct weston_output *base,
> > output->base.make = "weston";
> > output->base.model = "headless";
> >
> > - /* XXX: Calculate proper size. */
> > - output->base.mm_width = width;
> > - output->base.mm_height = height;
> > + /* XXX: Make this configurable */
> > + output_dpi = 72 * output->base.scale;
> > + output->base.mm_width = physical_size_for_dpi(output_width, output_dpi);
> > + output->base.mm_height = physical_size_for_dpi(output_height,
> > output_dpi);
> >
> > output->base.start_repaint_loop = headless_output_start_repaint_loop;
> > output->base.repaint = headless_output_repaint;
>
> ___
> 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] compositor-headless: Report a more realistic physical size
On Thu, 12 Apr 2018 09:31:48 +0200
Johan Klokkhammer Helsing wrote:
> Some clients rely on the physical size to determine the physical DPI. With the
> previous implementation, we would report 1px==1mm, which is a DPI of 25.4,
> which is incredibly low.
>
> The problem is solved by setting a physical size so the DPI is close to 72
> instead. If the output is scaled, the DPI is set to the corresponding multiple
> of 72.
>
> This makes the headless backend more usable for automated testing of DPI
> sensitive functionality such as point sized fonts.
>
> Signed-off-by: Johan Klokkhammer Helsing
> ---
> libweston/compositor-headless.c | 16
> 1 file changed, 12 insertions(+), 4 deletions(-)
Hi,
this is a good idea, but could you rebase this patch to master?
Thanks,
pq
>
> diff --git a/libweston/compositor-headless.c b/libweston/compositor-headless.c
> index 9307a36a..9f1a1a72 100644
> --- a/libweston/compositor-headless.c
> +++ b/libweston/compositor-headless.c
> @@ -180,12 +180,19 @@ err_malloc:
> return -1;
> }
>
> +static int
> +physical_size_for_dpi(int pixels, int dpi)
> +{
> + static const float mm_per_inch = 25.4;
> + return pixels * mm_per_inch / dpi;
> +}
> +
> static int
> headless_output_set_size(struct weston_output *base,
>int width, int height)
> {
> struct headless_output *output = to_headless_output(base);
> - int output_width, output_height;
> + int output_width, output_height, output_dpi;
>
> /* We can only be called once. */
> assert(!output->base.current_mode);
> @@ -207,9 +214,10 @@ headless_output_set_size(struct weston_output *base,
> output->base.make = "weston";
> output->base.model = "headless";
>
> - /* XXX: Calculate proper size. */
> - output->base.mm_width = width;
> - output->base.mm_height = height;
> + /* XXX: Make this configurable */
> + output_dpi = 72 * output->base.scale;
> + output->base.mm_width = physical_size_for_dpi(output_width, output_dpi);
> + output->base.mm_height = physical_size_for_dpi(output_height,
> output_dpi);
>
> output->base.start_repaint_loop = headless_output_start_repaint_loop;
> output->base.repaint = headless_output_repaint;
pgpqclHCu7dK2.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, 2 Jul 2018 16:25:28 +0300 Pekka Paalanen wrote: > On Fri, 29 Jun 2018 21:41:33 +0530 > Ramalingam C wrote: > > The idea here was that set_srm_table() is a simple API we can easily > maintain upstream. The external plugin would check the SRM table dates > and signatures and if they pass, call set_srm_table(). The external > plugin would also offer the client interface, whether it is Wayland, > DBus, or something else, to the video players. I believe this is a > design we could the very least agree to in upstream Weston, provided > there is a way to test set_srm_table() by feeding a sample SRM table > e.g. through a small test plugin in upstream. > > Oh, and if saving the latest SRM table to persistent memory is needed, > the external plugin could do that as well. I forgot to note, the Wayland protocol implementation would be in Weston upstream. There should be no reason to push that out to an external plugin. So Weston upstream would not only offer set_srm_table() but also take care of tracking the protection status, enabling HDCP on Wayland client request and reporting the status to the client. It is only the SRM table management that I am concerned about. And the topology thing, but I know nothing about that yet. Thanks, pq pgpCQnpvXziI_.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, 29 Jun 2018 22:49:56 +0530 Ramalingam C wrote: > Hi Pekka, > > Thanks a lot for making time for reviewing this proposal. > > On Friday 29 June 2018 06:08 PM, Pekka Paalanen wrote: > > On Sat, 16 Jun 2018 16:03:20 +0530 > > Ramalingam C wrote: > > > >> Hello all, > >> > >> I am trying to call out the complete sequence that we are aiming to > >> achieve. Please correct me if something is missed out. I am hoping > >> that with this sequence and interface we could get the > >> functionalities of HDCP what Arnaud and pekka also wants. > > Hi Ram, > > > > thanks for writing this up. > > > >> As we discussed Each protected content providers have the same > >> content in different quality. And they want to play each quality in a > >> particular environment only. I am just leaving all other requirement > >> except the HDCP protection for facilitating the discussion on HDCP > >> support for weston. > >> > >> Before going further I would like to clarify that any content those > >> needs to be protected against the copy over wire, can utilize the > >> HDCP encryption. This could be a list of passwords as pekka mentioend > >> or valuable high quality movie. The owner of those content can > >> classify the content Type as 0/1 based on the HDCP version they want > >> to use. As of now HDCP version 1.4 and 2.2 supports are getting added > >> to Linux kernel. > > By the way, will you be using a future Weston implementation as the > > prooving vehicle for the kernel UABI? > Yes. > > > > If so, we need to make sure the Weston implementation is not only a toy > > example. > Absolutely no. We have few designs in infotainment domain using the weston > compositor where we need HDCP support. Excellent, that is very useful to know. > > Also, I suppose the display is not showing content while the HDCP > > negotiation is on-going, so how will a Wayland compositor now when the > > picture becomes visible again? Will the KMS pageflip event be not > > delivered until negotiation ends in success or failure? > nope. HDCP authentication doesn't stop the rendering. Unprotected > content(Low value) > like a frame mentioning that HDCP negotiation is in progress or similar > stuff > should be rendered by Application until it's HDCP requirements are met. Oh, that's nice. I thought it was something like link training, which I presume would not allow a video signal to be transmitted until it is finished. > In fact that will provide the reason for delay(time required for > negotiation) in playing the > protected content. > > > >> And the kernel will be keep checking the link protection status, > >> incase of the runtime HDCP failure, "content protection" will be set > >> to "DESIRED" Hence after the success of HDCP authentication, > >> userspace has to continuously poll the "content protection" state in > >> a required frequency for detecting the runtime failures. > > Ugh, polling. > > > > I'm really baffled why sending a kernel event for "content protection" > > changes was denied. Was it the very idea, or just implementation > > details? Lack of infrastructure for events other than pageflip and > > hotplug? > That time existing HDCP consumer(chrome) was happy without the events. > Now since we feel the need of it as a new consumer we could propose once > again. Ok, that would be very nice. It should also reduce the latency to respond to losing protection as that would otherwise depend on the polling rate. > > > >> Setting "content protection" to UNDESIRED will stop the HDCP > >> protection on a connector. > >> > >> Now we know, HDCP services from kernel. So lets discuss how content > >> provider's hdcp protection requirement could be met in a system with > >> weston compositor. > > > >> 1. Lets assume APP is a protected movie player. > >> 2. Lets APP has different level of content quality 4k, FullHD, HD. > >> And APP is willing to render 4k content only on HDCP2.2 protected > >> external displays, > >>FullHD content only on HDCP(1.4/2.2) protected external > >> displays and HD content on any display. > >> 3. So APP will classify the content as below: > >>4K - Type 1 protected content > >>Full HD - Type 0 protected content > >>HD - Unprotected content. > >>Disclaimer: Content owner can classify any content as type > >> 0/1 based on its sensitive nature. > >> 4. When the APP starts it will render the preview of the movies or > >> some other unprotected content to the compositor to display it on > >> connectors > >> 5. At this stage, based on the system mode (Extended/Mirror) > >> connectors for that surface will be decided I guess. > > Not only at this stage, but continuously on every frame the compositor > > outputs. > > > >> 6. Now when a user selects the Type 1 protected content for playing, > >> APP1 will request the weston to create the protected > >>wl_surface with Type 1 requirement mentioned. And also > >> provides the latest SRM to
Re: Wayland content-protection extension
On Fri, 29 Jun 2018 21:41:33 +0530 Ramalingam C wrote: > Pekka, > > Thanks a lot for the responses. > > On Friday 29 June 2018 04:28 PM, Pekka Paalanen wrote: > > On Mon, 18 Jun 2018 15:56:40 +0530 > > Ramalingam C wrote: > > > >> 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. > > But nothing there requires the use of Wayland for it. Sure, the > > compositor will have to program the SRM table via KMS, but it doesn't > > mean the compositor needs to get it by Wayland. > True. thats what I meant. I used the word "wayland" loosely. :( > > > > The compositor does not care which process provides a SRM table, > > because: > > - the SRM table is global and cross-vendor > > - the SRM table is signed, so no fakes can be provided > > - the SRM table is versioned/dated, so always the most recent will be > >in use, regardless of which version a client might propose > > - clients are happy to use a SRM table that is more recent than what > >they have themselves > > > > Did I misunderstand something? > You got it completely. > > > > Let me put it in another way: we don't need to standardise a Wayland > > interface, it could be DBus or something else since there is no > > connection to window management. > > > > I'm also concerned about the maintenance of an authenticated SRM table. > > Would we have Weston link to a new library to validate signatures? How > > does Weston load a guaranteed good DCP public key? Where will Weston > > store and load the SRM tables? > DCP public key is static value. Available in the HDCP specs. > Storing place for the SRM from weston is not thought about. Hi! Ok. Maybe it's fine that the compositor only keeps the SRM table at runtime and never saves it into persistent memory. > > > > I would assume the SRM table support to be both uninteresting to > > upstream in general, and possibly quite specific to the system where > > weston is running. Therefore, I would propose the following: > > > > Have the SRM table verification, maintenance, and IPC in an external > > Weston plugin. > Actually I am afraid that I am not understanding this part. > By this are you referring a library which provides the function pointers > for weston compositor for verify the signature, update the latest SRM > in Non volatile memory and to get the latest SRM etc? > > If not please elaborate on this. Weston can load arbitrary plugins as long as the plugin provides a single specific entry point to initialize it. The plugin will have access to all exported API of Weston, both for directly exported functions and via the so-called plugin registry where you can look up a function pointer table for a specific table name. It is possible to write a plugin that lives in a separate repository, so it does not need to be upstreamed. The downside is that the ABI for plugins is not stable, you will likely have to update the plugin for
Re: [PATCH v9 0/6] Make Weston multiseat aware
On Fri, 29 Jun 2018 08:17:45 -0400 nerdopolis wrote: > These patches make Weston handle multiple seats. Fixes from the last > attempt include updating fbdev_set_screen_info , updating some fuzz, > and making the selection of the framebuffer device similar to > compositor-drm.c by favoring the boot_vga device, and making > requested changes. These now address some memory leaks, and other > changes requested. Hi, thank you a lot for the revisions, it's all fine now. Pushed: efdebbc4..35280448 master -> master Thanks, pq pgpuGNYbjqCKO.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 6/5] tools: add a test to verify the builddir lookup works correctly
On Fri, 29 Jun 2018 11:08:31 +1000
Peter Hutterer wrote:
> The binary takes an argument to check whether we expect the builddir to be
> detected or not. Then it's executed once as normal test and once after being
> copied to /tmp.
>
> Signed-off-by: Peter Hutterer
> ---
>
> that was easier than expected... :)
>
> meson.build| 16 +
> tools/helper-copy-and-exec-from-tmp.sh | 18 ++
> tools/test-builddir-lookup.c | 47 ++
> 3 files changed, 81 insertions(+)
> create mode 100755 tools/helper-copy-and-exec-from-tmp.sh
> create mode 100644 tools/test-builddir-lookup.c
>
> diff --git a/meson.build b/meson.build
> index 826b4fd0..45786d9f 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -679,6 +679,22 @@ executable('ptraccel-debug',
> install : false
> )
>
> +# the libinput tools check whether we execute from the builddir, this is
> +# the test to verify that lookup. We test twice, once as normal test
> +# run from the builddir, once after copying to /tmp
> +test_builddir_lookup = executable('test-builddir-lookup',
> + 'tools/test-builddir-lookup.c',
> + dependencies : [ dep_tools_shared],
> + include_directories : [includes_src,
> includes_include],
> + install : false)
> +test('tools-builddir-lookup',
> + test_builddir_lookup,
> + args : ['--builddir-is-set'])
> +test('tools-builddir-lookup-installed',
> + find_program('tools/helper-copy-and-exec-from-tmp.sh'),
> + args : [test_builddir_lookup.full_path(), '--builddir-is-null'],
> + workdir : '/tmp')
> +
> tests
>
> test_symbols_leak = find_program('test/symbols-leak-test.in')
> diff --git a/tools/helper-copy-and-exec-from-tmp.sh
> b/tools/helper-copy-and-exec-from-tmp.sh
> new file mode 100755
> index ..46182c42
> --- /dev/null
> +++ b/tools/helper-copy-and-exec-from-tmp.sh
> @@ -0,0 +1,18 @@
> +#!/bin/bash -x
> +#
> +# Usage: helper-copy-and-exec-from-tmp.sh /path/to/binary [args]
> +#
> +# Copies the given binary into a unique file in /tmp and executes it with
> +# [args]. Exits with the same return code as the binary did.
> +
> +executable="$1"
> +shift
> +
> +target_name=$(mktemp)
> +cp "$executable" "$target_name"
> +chmod +x "$target_name"
> +
> +$target_name "$@"
> +rc=$?
> +rm $target_name
> +exit $rc
I'd apply more paranoia in bash scripts and but $target_name in quotes.
> diff --git a/tools/test-builddir-lookup.c b/tools/test-builddir-lookup.c
> new file mode 100644
> index ..457ed8cb
> --- /dev/null
> +++ b/tools/test-builddir-lookup.c
> @@ -0,0 +1,47 @@
> +/*
> + * Copyright © 2018 Red Hat, Inc.
> + *
> + * 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.
> + */
> +
> +#include "config.h"
> +#include "libinput-util.h"
> +#include "shared.h"
> +
> +
> +int main(int argc, char **argv) {
> + char *builddir;
> + char *mode;
> +
> + assert(argc == 2);
Is libinput test suite buildable with NDEBUG? I suppose not.
> + mode = argv[1];
> +
> + builddir = tools_execdir_is_builddir();
> + if (streq(mode, "--builddir-is-null")) {
> + assert(builddir == NULL);
> + } else if (streq(mode, "--builddir-is-set")) {
> + assert(builddir != NULL);
> + assert(streq(MESON_BUILD_ROOT, builddir));
> + } else {
> + abort();
> + }
> +
> + return 0;
> +}
Looks good to me. This patch:
Reviewed-by: Pekka Paalanen
with a pinch of salt.
Thanks,
pq
pgpxroUdrDbcI.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] configure.ac: bump libdrm requirement to 2.4.68
On Mon, 2 Jul 2018 10:43:12 +0100 Emil Velikov wrote: > On 2 July 2018 at 10:41, Emil Velikov wrote: > > On 2 July 2018 at 03:07, Peter Hutterer wrote: > >> On Mon, Jun 11, 2018 at 11:02:19AM +0100, Daniel Stone wrote: > >>> Hi, > >>> > >>> On 11 June 2018 at 10:25, Pekka Paalanen wrote: > >>> > On Mon, 11 Jun 2018 09:29:49 +1000 > >>> > Peter Hutterer wrote: > >>> >> +PKG_CHECK_MODULES(LIBDRM, [libdrm >= 2.4.68], [], [AC_MSG_ERROR([ > >>> >> libdrm is a hard build-time dependency for libweston core, > >>> >> but a sufficient version was not found. However, libdrm > >>> >> is not a runtime dependency unless you have features > >>> > > >>> > this patch is correct, but I would like to hear more opinions if we > >>> > want to bump the hard build-time dependency from release of Jan 2012 to > >>> > Apr 2016. > >>> > > >>> > If we do this bump, we could remove the fallback definitions for > >>> > DRM_FORMAT_R8 and DRM_FORMAT_GR88. > >>> > > >>> > In case we want to consider bumping even further, DRM_FORMAT_MOD_* were > >>> > introduced in 2.4.83 (Aug 2017), and atomic in 2.4.78 (Apr 2017). > >>> > >>> I'd be in favour of bumping all the way to .83. It's available in > >>> Debian testing and unstable, as well as for stable (stretch) via the > >>> backports.debian.org repository. It's available for Ubuntu 16.04 LTS > >>> via the xenial-updates repository, and releases since. It's available > >>> in Yocto Rocko (Oct 2017), but unsurprisingly not in Pyro (May 2017); > >>> I believe there are a few BSPs based on Pyro and earlier still, but > >>> they would be pretty trivial bumps to include if vendors want to > >>> upgrade Weston. > >>> > >>> Either patch is: > >>> Acked-by: Daniel Stone > >> > >> pekka: gentle ping, if you're happy with this one > >> > > On Debian front: > > - oldstable: 2.4.74 in backports > > - stable: 2.4.74 in main, 2.4.91 in backports > > > > Ubuntu: > > - 16.04: 2.4.83 in xenial-updates > > - 14.04: 2.4.67 in trusty-updates > > > > In other words, Trusty is def. out of the question: I'd go with this > > patch for now to unblock. > > Might want to bump to .83 closer to the release/branch point. > > > Should have added: As-is patch is > Reviewed-by: Emil Velikov Thank you all, pushed: 90718170..efdebbc4 master -> master Btw. we should be getting alpha release on the 10th, so that's pretty close now. Do we want a bump to .83 and clean-up before or after 5.0.0 release? Looking at Emil's list of distributions, I would go for .83 already right now. Thanks, pq pgpnpR4uIMakX.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: I want to participate in EVoC with Wayland and Linux, how to start?
On Sun, 1 Jul 2018 20:03:36 +0300 Denis Obrezkov wrote: > Hello, > > I am a phd student and I would like to participate in Endless Vacation > of Code: > > https://www.x.org/wiki/SummerOfCodeIdeas/ Hello, welcome! > I have read wayland documentation and started to read the Linux GPU > Driver Developers' guide. I also found some interesting project: > > https://gitlab.freedesktop.org/wayland/weston/issues/17 That's the atomic modesetting feature. The basics have landed, Daniel has a remaining series brewing for restoring the composite bypass path and using hardware planes. What hasn't been worked on yet AFAIK is the TEST_ONLY feature of atomic modesetting. Essentially, before we take an output configuration into use, we should do a TEST_ONLY commit to see if it possible before-hand, rather than failing after the configuration is used. TEST_ONLY would allow iterating through different configurations to see which ones should work. > and I found a label called "Good for new contributors". But right now I > don't understand where and how to start. For example, how a typical > working environment looks like? Should I use wayland in some distro or > should I build on top of a bare kernel with glibc? You run a distribution you like and are familiar with. You can use distribution packages for all components you don't need to modify and are new enough. Set up a prefix under your home directory where you install all the software you need to build manually. Getting Weston built manually and running from a prefix directory would be the first step. Atomic modesetting is exclusive to the DRM-backend, so you should be prepared to run Weston from the virtual terminal on "bare" hardware. If something goes wrong, it is very handy to have another computer to log in remotely to diagnose and recover. Virtual machines like qemu are not always suitable for testing the DRM-backend. Also note that NVIDIA proprietary drivers are not suitable for working on Weston. > Also, I have some organizational questions about evoc, e.g. about its > duration, about possible mentor, etc. These I cannot personally help with, sorry. Thanks, pq pgpRDhIT7G60T.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] configure.ac: bump libdrm requirement to 2.4.68
On 2 July 2018 at 10:41, Emil Velikov wrote: > On 2 July 2018 at 03:07, Peter Hutterer wrote: >> On Mon, Jun 11, 2018 at 11:02:19AM +0100, Daniel Stone wrote: >>> Hi, >>> >>> On 11 June 2018 at 10:25, Pekka Paalanen wrote: >>> > On Mon, 11 Jun 2018 09:29:49 +1000 >>> > Peter Hutterer wrote: >>> >> +PKG_CHECK_MODULES(LIBDRM, [libdrm >= 2.4.68], [], [AC_MSG_ERROR([ >>> >> libdrm is a hard build-time dependency for libweston core, >>> >> but a sufficient version was not found. However, libdrm >>> >> is not a runtime dependency unless you have features >>> > >>> > this patch is correct, but I would like to hear more opinions if we >>> > want to bump the hard build-time dependency from release of Jan 2012 to >>> > Apr 2016. >>> > >>> > If we do this bump, we could remove the fallback definitions for >>> > DRM_FORMAT_R8 and DRM_FORMAT_GR88. >>> > >>> > In case we want to consider bumping even further, DRM_FORMAT_MOD_* were >>> > introduced in 2.4.83 (Aug 2017), and atomic in 2.4.78 (Apr 2017). >>> >>> I'd be in favour of bumping all the way to .83. It's available in >>> Debian testing and unstable, as well as for stable (stretch) via the >>> backports.debian.org repository. It's available for Ubuntu 16.04 LTS >>> via the xenial-updates repository, and releases since. It's available >>> in Yocto Rocko (Oct 2017), but unsurprisingly not in Pyro (May 2017); >>> I believe there are a few BSPs based on Pyro and earlier still, but >>> they would be pretty trivial bumps to include if vendors want to >>> upgrade Weston. >>> >>> Either patch is: >>> Acked-by: Daniel Stone >> >> pekka: gentle ping, if you're happy with this one >> > On Debian front: > - oldstable: 2.4.74 in backports > - stable: 2.4.74 in main, 2.4.91 in backports > > Ubuntu: > - 16.04: 2.4.83 in xenial-updates > - 14.04: 2.4.67 in trusty-updates > > In other words, Trusty is def. out of the question: I'd go with this > patch for now to unblock. > Might want to bump to .83 closer to the release/branch point. > Should have added: As-is patch is Reviewed-by: Emil Velikov -Emil ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] configure.ac: bump libdrm requirement to 2.4.68
On 2 July 2018 at 03:07, Peter Hutterer wrote: > On Mon, Jun 11, 2018 at 11:02:19AM +0100, Daniel Stone wrote: >> Hi, >> >> On 11 June 2018 at 10:25, Pekka Paalanen wrote: >> > On Mon, 11 Jun 2018 09:29:49 +1000 >> > Peter Hutterer wrote: >> >> +PKG_CHECK_MODULES(LIBDRM, [libdrm >= 2.4.68], [], [AC_MSG_ERROR([ >> >> libdrm is a hard build-time dependency for libweston core, >> >> but a sufficient version was not found. However, libdrm >> >> is not a runtime dependency unless you have features >> > >> > this patch is correct, but I would like to hear more opinions if we >> > want to bump the hard build-time dependency from release of Jan 2012 to >> > Apr 2016. >> > >> > If we do this bump, we could remove the fallback definitions for >> > DRM_FORMAT_R8 and DRM_FORMAT_GR88. >> > >> > In case we want to consider bumping even further, DRM_FORMAT_MOD_* were >> > introduced in 2.4.83 (Aug 2017), and atomic in 2.4.78 (Apr 2017). >> >> I'd be in favour of bumping all the way to .83. It's available in >> Debian testing and unstable, as well as for stable (stretch) via the >> backports.debian.org repository. It's available for Ubuntu 16.04 LTS >> via the xenial-updates repository, and releases since. It's available >> in Yocto Rocko (Oct 2017), but unsurprisingly not in Pyro (May 2017); >> I believe there are a few BSPs based on Pyro and earlier still, but >> they would be pretty trivial bumps to include if vendors want to >> upgrade Weston. >> >> Either patch is: >> Acked-by: Daniel Stone > > pekka: gentle ping, if you're happy with this one > On Debian front: - oldstable: 2.4.74 in backports - stable: 2.4.74 in main, 2.4.91 in backports Ubuntu: - 16.04: 2.4.83 in xenial-updates - 14.04: 2.4.67 in trusty-updates In other words, Trusty is def. out of the question: I'd go with this patch for now to unblock. Might want to bump to .83 closer to the release/branch point. -Emil ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] build: don't manually parse the weston.ini.in templates
On Mon, 2 Jul 2018 08:37:52 +0100 Emil Velikov wrote: > Agreed, DESTDIR in itself should be (and is) fine. > Some illustrations on the "disaster" mentioned earlier. > > git clean > ./configure > make // implicit all - weston.ini is generated > make bindir=foo install // weston.ini is not regenerated, bindir is ignored > > git clean > ./configure > make bindir=foo > make install // the previous bindir is used, even when you did not ask for it > > git clean > ./configure > make bindir=foo install // implicit all, bindir is used I never knew that was even a thing. Is that actually supposed to work? Wouldn't the first case be broken on all software that builds in any such paths? Thanks, pq pgpjcP1gwXhdW.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Users of libweston?
On Fri, 29 Jun 2018 10:05:58 -0500 Matt Hoosier wrote: > Hi all, > > Pekka's recent comments about wanting to enable set-top boxes built with > libweston to do DRM content got me to wondering: > > Who all is using libweston directly (as opposed to running /usr/bin/weston > possibly with custom shells plugins or similar)? For my own purposes, I > just use the full compositor because it's pretty lean and mean anyway, and > I can do what I need by loading plugins. Hi Matt, I wouldn't be surprised if there weren't many users yet. There is a huge amount of things I'd like to do before I could comfortably propose using libweston. I still think it needs to be a goal in mind all the time though, otherwise we'll never get there. :-) IMO the major point of using libweston instead of weston is to be able to customize the UX any way you want - all the stuff and policy that is currecntly hardcoded in main.c and the desktop-shell plugin. Making all configurable is probably not feasible. My hope with gaining set-top box etc. use cases is to gather more people developing for Weston, people who could be dedicated in the long run. Maybe that could gain us more upstream maintainers. Thanks, pq pgpEUhVf0ec2d.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] build: don't manually parse the weston.ini.in templates
Hi All,
Tl;Dr: Silly brain of mine auto-expanded $(foo). Patch might work, but
as Quentin mentioned it won't majority of the time.
Please consider this binned.
On 29 June 2018 at 08:37, Pekka Paalanen wrote:
> On Thu, 28 Jun 2018 18:59:01 +0100
> Emil Velikov wrote:
>
>> On 28 June 2018 at 10:58, Quentin Glidic
>> wrote:
>> > On 6/27/18 3:04 PM, Emil Velikov wrote:
>> >>
>> >> From: Emil Velikov
>> >>
>> >> Adding those to configure.ac ensures that:
>> >> - the weston.ini files are {re,}generated only when needed
>> >> - the .in files are shipped in the tarball
>> >> - all the manual handling of the above can be removed ;-)
>> >
>> >
>> > Did you actually test that?
>> > In configure.ac, "bindir" is "${prefix}/bin" (default value), so you’d end
>> > up with "path=${prefix}/bin/weston-flower", and obviously, it won’t launch.
Weirdly enough, I do actually set the folders passed to configure when
building a local distro package.
Turns out that brain of mine auto-expanded $[prefix}, going foobar
with your comment.
The variable is stored literally, thus patch will work only in corner cases.
Thank you for this.
>> > Also, though it’s not that used, you can override directories at "make"
>> > time.
>> > In the end, Makefile is the only place we know the full usable value for
>> > directories. (Otherwise, the only case it’ll work is when you pass all the
>> > directories as full paths to "./configure".)
>> >
>> Hmm I think a good point is to step back a bit and say how the
>> weston.ini files should be used.
>> Are they meant for builddir only usage (a), are they sort of a
>> template that one should copy (b) or other (c).
>
> I believe the weston.ini files in root and ivi-shell/ directories are
> examples, which could be used as templates for a custom config
> primarily. It would be good if they are correct and usable as is, that
> is, they use the directories used by 'make install' when DESTDIR is
> *not* given. That way a user can copy the file, have a test run that
> works, and then tweak further.
>
> Weston will pick weston.ini from CWD only if it finds it nowhere else,
> see weston.ini.man.
>
Right, I will send a patch later adding a small comment at the top of the files.
"This file is a drop-in template. See `man weston.ini' for more"
> If weston cannot find any weston.ini, it will still run with built-in
> defaults, which include one launcher icon that should start
> weston-terminal. So there is a precedent of a built-in path already
> that cannot change at install time. (Whether that should rely on PATH
> instead is another question - maybe it should?)
>
Relying on PATH seems reasonable. But it's not my call at the end of the day.
> IMO it would be fine to just remove weston-flower and any client that
> is normally not installed from the example ini files. weston-terminal
> is the most important launcher.
>
AFAICT weston-flower is the only instance that needs a
builddir->install dir fix.
It's one of the base demos.
>> The patch from Emre suggest (b). My current assumption is on the same
>> page, based on the bindir/weston-foo (and friends) instances in
>> weston.ini.in.
>>
>> I wonder if "make allows you to override everything" is not it's bane.
>> Just because you can, don't mean one should.
>> All in all people who thinker with that should really know what they're
>> doing.
>
> If Quentin was referring to DESTDIR only, then there should be no
> problem. DESTDIR is used for installing into a staging tree which
> cannot be executed from. One is expected to copy that into the proper
> $prefix before running is possible.
>
Agreed, DESTDIR in itself should be (and is) fine.
Some illustrations on the "disaster" mentioned earlier.
git clean
./configure
make // implicit all - weston.ini is generated
make bindir=foo install // weston.ini is not regenerated, bindir is ignored
git clean
./configure
make bindir=foo
make install // the previous bindir is used, even when you did not ask for it
git clean
./configure
make bindir=foo install // implicit all, bindir is used
Thanks
Emil
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
