From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D727AC282DD for ; Sat, 20 Apr 2019 22:41:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 93E3D208C0 for ; Sat, 20 Apr 2019 22:41:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="nEW5kE/K" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727172AbfDTWk6 (ORCPT ); Sat, 20 Apr 2019 18:40:58 -0400 Received: from perceval.ideasonboard.com ([213.167.242.64]:57288 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725965AbfDTWk6 (ORCPT ); Sat, 20 Apr 2019 18:40:58 -0400 Received: from pendragon.ideasonboard.com (dfj612yhrgyx302h3jwwy-3.rev.dnainternet.fi [IPv6:2001:14ba:21f5:5b00:ce28:277f:58d7:3ca4]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 835F75F; Sun, 21 Apr 2019 00:40:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1555800054; bh=nMMfdyv+gYWL/rzGRQxoZDTpKhi9T+p/BKTgaM49D1E=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nEW5kE/KcCUCiBOZ5rauRPeNiMnSnZLAeeLtG4ELwverbQXX4z894rr87N3YRfTTs BdZJw5s8t7aAY/MthpOpP/+PEe6BFzikwVbuHKA60NrnlWyHtE+LzFVF64s2yZG66b 4omh1kcWJXVf3oedt3ehQnRQFOHqIszEFjIdVFDs= Date: Sun, 21 Apr 2019 01:40:45 +0300 From: Laurent Pinchart To: Paul Kocialkowski Cc: Maxime Ripard , Daniel Vetter , Daniel Vetter , David Airlie , Maarten Lankhorst , Sean Paul , Mauro Carvalho Chehab , Sakari Ailus , Linux Kernel Mailing List , dri-devel , Hans Verkuil , Thomas Petazzoni , "open list:DMA BUFFER SHARING FRAMEWORK" , Boris Brezillon Subject: Re: [PATCH 00/20] drm: Split out the formats API and move it to a common place Message-ID: <20190420224045.GY4964@pendragon.ideasonboard.com> References: <20190417154121.GJ13337@phenom.ffwll.local> <20190418062229.eyog4i62eg4pr6uf@flea> <20190418090221.e57dogn4yx5nwdni@flea> <6578c22ddf5420d4dead69d29f451bc6a91f6c4a.camel@bootlin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6578c22ddf5420d4dead69d29f451bc6a91f6c4a.camel@bootlin.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Paul, On Thu, Apr 18, 2019 at 01:49:54PM +0200, Paul Kocialkowski wrote: > On Thu, 2019-04-18 at 11:02 +0200, Maxime Ripard wrote: > > On Thu, Apr 18, 2019 at 09:52:10AM +0200, Daniel Vetter wrote: > >> And a lot of people pushed for the "fourcc is a standard", when > >> really it's totally not. > > > > Even if it's not a standard, having consistency would be a good thing. > > > > And you said yourself that DRM fourcc is now pretty much an authority > > for the fourcc, so it definitely looks like a standard to me. > > I think trying to make the V4L2 and DRM fourccs converge is a lost > cause, as it has already significantly diverged. Even if we coordinate > an effort to introduce new formats with the same fourcc on both sides, > I don't see what good that would be since the formats we have now are > still plagued by the inconsistency. > > I think we always need an explicit translation step from either v4l2 or > drm to the internal representation and back, without ever assuming that > formats might be compatible because they share the same fourcc. I don't agree. APIs evolve, and while we can't switch from one set of 4CCs to another in existing APIs, we could in new APIs. Boris is working on new ioctls to handle formats in V4L2, and while 4CC unification could be impopular from a userspace developers point of view there, I don't think we have ruled it out completely. The move to the request API is also an area where a common set of 4CCs could be used, as it will depart from the existing V4L2 ioctls. To summarize my opinion, we're not there yet, but I wouldn't rule it out completely for the future. > It looks like so far, V4L2 pixel formats describe a DRM pixel format + > modifier. DRM modifiers are mostly about tiling and compression, and we hardly support these in V4L2. What are the modifiers you think are hardcoded in 4CCs in V4L2 ? > I think Boris (CCed) is working to change that by allowing to > pass a DRM modifier through V4L2. With that, we'd be in a situation > where some formats are described by the v4l2 pixfmt alone and some > formats are also described a modifier (but I looked at it from a > distance so might have misunderstod). That feels better since it avoids > the combinatory explosion from describing each format + modifier > individually. > > What do you think? > > >> v4l tends to conflate pixel format with stuff that we tend to encode > >> in modifiers a lot more. > > > > Boris is working on adding the modifiers concept to v4l2, so we're > > converging here, and we can totally have a layer in v4l2 to convert > > between old v4l2 "format+modifiers" formats, and DRM style formats. > > > >> There's a bunch of reasons we can't just use v4l, and they're as > >> valid as ever: > >> > >> - We overlap badly in some areas, so even if fourcc codes match, we > >> can't use them and need a duplicated DRM_FOURCC code. > > > > Do yo have an example of one of those areas? > > > >> - v4l encodes some metadata into the fourcc that we encode elsewhere, > >> e.g. offset for planar yuv formats, or tiling mode > > > > As I was saying, this changes on the v4l2 side, and converging to > > what DRM is doing. > > > >> - drm fourcc code doesn't actually define the drm_format_info > >> uniquely, drivers can override that (that's an explicit design > >> intent of modifiers, to allow drivers to add another plane for > >> e.g. compression information). You'd need to pull that driver > >> knowledge into your format library. > > > > I'm not sure how my patches are changing anything here. This is > > litterally the same code, with the functions renamed. > > > > If drivers want to override that, then yeah, fine, we can let them do > > that. Just like any helper this just provides a default that covers > > most of the cases. > > > >> Iow there's no way we can easily adopt v4l fourcc, except if we do > >> something like a new addfb flag. > > > > For the formats that would be described as a modifier, sure. For all > > the others (that are not yet supported by DRM), then I don't really > > see why not. > > > >>> And given how the current state is a mess in this regard, I'm not too > >>> optimistic about keeping the formats in their relevant frameworks. > >>> > >>> Having a shared library, governed by both, will make this far easier, > >>> since it will be easy to discover the formats that are already > >>> supported by the other subsystem. > >> > >> I think a compat library that (tries to, best effort) convert between > >> v4l and drm fourcc would make sense. Somewhere in drivers/video, next > >> to the conversion functions for videomode <-> drm_display_mode > >> perhaps. That should be useful for drivers. > > > > That's not really what this series is about though. That series is > > about sharing the (image|pixels) formats database across everyone so > > that everyone can benefit from it. > > > >> Unifying the formats themselves, and all the associated metadata is > >> imo a no-go, and was a pretty conscious decision when we implemented > >> drm_fourcc a few years back. > >> > >>> If we want to keep the current library in DRM, we have two options > >>> then: > >>> > >>> - Support all the v4l2 formats in the DRM library, which is > >>> essentially what I'm doing in the last patches. However, that > >>> would require to have the v4l2 developpers also reviewing stuff > >>> there. And given how busy they are, I cannot really see how that > >>> would work. > >> > >> Well, if we end up with a common library then yes we need cross > >> review. There's no way around that. Doesn't matter where exactly that > >> library is in the filesystem tree, and adding a special MAINTAINERS > >> entry for anything related to fourcc (both drm and v4l) to make sure > >> they get cross-posted is easy. No file renaming needed. > > > > That would create some governing issues as well. For example, if you > > ever have a patch from one fourcc addition (that might or might not be > > covered by v4l2), will you wait for any v4l2 developper to review it? > > > > If it's shared code, then it should be shared, and every client > > framework put on an equal footing. > > > >>> - Develop the same library from within v4l2. That is really a poor > >>> solution, since the information would be greatly duplicated > >>> between the two, and in terms of maintainance, code, and binary > >>> size that would be duplicated too. > >> > >> It's essentially what we decided to do for drm years back. > > > > And it was probably the right solution back then, but I'm really not > > convinced it's still the right thing to do today. > > > >>> Having it shared allows to easily share, and discover formats from the > >>> other subsystem, and to have a single, unique place where this is > >>> centralized. > >> > >> What I think could work as middle ground: > >> - Put drm_format stuff into a separate .ko > >> - Add a MAINTAINERS entry to make sure all things fourcc are cross > >> posted to both drm and v4l lists. Easy on the drm side, since it's all > >> separate files. Not sure it's so convenient for v4l uapi. > >> - Add a conversion library that tries to best-effort map between drm > >> and v4l formats. On the drm side that most likely means you need > >> offsets for planes, and modifiers too (since those are implied in some > >> v4l fourcc). Emphasis on "best effort" i.e. only support as much as > >> the drivers that use this library need. > >> - Add drm_fourcc as-needed by these drivers that want to use a unified > >> format space. > >> > >> Forcing this unification on everyone otoh is imo way too much. > > > > v4l2 is starting to converge with DRM, and we're using the DRM API > > pretty much untouched for that library, so I'm not really sure how > > anyone is hurt by that unification. -- Regards, Laurent Pinchart From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Subject: Re: [PATCH 00/20] drm: Split out the formats API and move it to a common place Date: Sun, 21 Apr 2019 01:40:45 +0300 Message-ID: <20190420224045.GY4964@pendragon.ideasonboard.com> References: <20190417154121.GJ13337@phenom.ffwll.local> <20190418062229.eyog4i62eg4pr6uf@flea> <20190418090221.e57dogn4yx5nwdni@flea> <6578c22ddf5420d4dead69d29f451bc6a91f6c4a.camel@bootlin.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) by gabe.freedesktop.org (Postfix) with ESMTPS id 602ED892B2 for ; Sat, 20 Apr 2019 22:40:56 +0000 (UTC) Content-Disposition: inline In-Reply-To: <6578c22ddf5420d4dead69d29f451bc6a91f6c4a.camel@bootlin.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Paul Kocialkowski Cc: Thomas Petazzoni , Sakari Ailus , Maxime Ripard , Linux Kernel Mailing List , dri-devel , David Airlie , Hans Verkuil , Sean Paul , Boris Brezillon , Daniel Vetter , Mauro Carvalho Chehab , "open list:DMA BUFFER SHARING FRAMEWORK" List-Id: dri-devel@lists.freedesktop.org SGkgUGF1bCwKCk9uIFRodSwgQXByIDE4LCAyMDE5IGF0IDAxOjQ5OjU0UE0gKzAyMDAsIFBhdWwg S29jaWFsa293c2tpIHdyb3RlOgo+IE9uIFRodSwgMjAxOS0wNC0xOCBhdCAxMTowMiArMDIwMCwg TWF4aW1lIFJpcGFyZCB3cm90ZToKPiA+IE9uIFRodSwgQXByIDE4LCAyMDE5IGF0IDA5OjUyOjEw QU0gKzAyMDAsIERhbmllbCBWZXR0ZXIgd3JvdGU6Cj4gPj4gQW5kIGEgbG90IG9mIHBlb3BsZSBw dXNoZWQgZm9yIHRoZSAiZm91cmNjIGlzIGEgc3RhbmRhcmQiLCB3aGVuCj4gPj4gcmVhbGx5IGl0 J3MgdG90YWxseSBub3QuCj4gPiAKPiA+IEV2ZW4gaWYgaXQncyBub3QgYSBzdGFuZGFyZCwgaGF2 aW5nIGNvbnNpc3RlbmN5IHdvdWxkIGJlIGEgZ29vZCB0aGluZy4KPiA+IAo+ID4gQW5kIHlvdSBz YWlkIHlvdXJzZWxmIHRoYXQgRFJNIGZvdXJjYyBpcyBub3cgcHJldHR5IG11Y2ggYW4gYXV0aG9y aXR5Cj4gPiBmb3IgdGhlIGZvdXJjYywgc28gaXQgZGVmaW5pdGVseSBsb29rcyBsaWtlIGEgc3Rh bmRhcmQgdG8gbWUuCj4gCj4gSSB0aGluayB0cnlpbmcgdG8gbWFrZSB0aGUgVjRMMiBhbmQgRFJN IGZvdXJjY3MgY29udmVyZ2UgaXMgYSBsb3N0Cj4gY2F1c2UsIGFzIGl0IGhhcyBhbHJlYWR5IHNp Z25pZmljYW50bHkgZGl2ZXJnZWQuIEV2ZW4gaWYgd2UgY29vcmRpbmF0ZQo+IGFuIGVmZm9ydCB0 byBpbnRyb2R1Y2UgbmV3IGZvcm1hdHMgd2l0aCB0aGUgc2FtZSBmb3VyY2Mgb24gYm90aCBzaWRl cywKPiBJIGRvbid0IHNlZSB3aGF0IGdvb2QgdGhhdCB3b3VsZCBiZSBzaW5jZSB0aGUgZm9ybWF0 cyB3ZSBoYXZlIG5vdyBhcmUKPiBzdGlsbCBwbGFndWVkIGJ5IHRoZSBpbmNvbnNpc3RlbmN5Lgo+ IAo+IEkgdGhpbmsgd2UgYWx3YXlzIG5lZWQgYW4gZXhwbGljaXQgdHJhbnNsYXRpb24gc3RlcCBm cm9tIGVpdGhlciB2NGwyIG9yCj4gZHJtIHRvIHRoZSBpbnRlcm5hbCByZXByZXNlbnRhdGlvbiBh bmQgYmFjaywgd2l0aG91dCBldmVyIGFzc3VtaW5nIHRoYXQKPiBmb3JtYXRzIG1pZ2h0IGJlIGNv bXBhdGlibGUgYmVjYXVzZSB0aGV5IHNoYXJlIHRoZSBzYW1lIGZvdXJjYy4KCkkgZG9uJ3QgYWdy ZWUuIEFQSXMgZXZvbHZlLCBhbmQgd2hpbGUgd2UgY2FuJ3Qgc3dpdGNoIGZyb20gb25lIHNldCBv Zgo0Q0NzIHRvIGFub3RoZXIgaW4gZXhpc3RpbmcgQVBJcywgd2UgY291bGQgaW4gbmV3IEFQSXMu IEJvcmlzIGlzIHdvcmtpbmcKb24gbmV3IGlvY3RscyB0byBoYW5kbGUgZm9ybWF0cyBpbiBWNEwy LCBhbmQgd2hpbGUgNENDIHVuaWZpY2F0aW9uIGNvdWxkCmJlIGltcG9wdWxhciBmcm9tIGEgdXNl cnNwYWNlIGRldmVsb3BlcnMgcG9pbnQgb2YgdmlldyB0aGVyZSwgSSBkb24ndAp0aGluayB3ZSBo YXZlIHJ1bGVkIGl0IG91dCBjb21wbGV0ZWx5LiBUaGUgbW92ZSB0byB0aGUgcmVxdWVzdCBBUEkg aXMKYWxzbyBhbiBhcmVhIHdoZXJlIGEgY29tbW9uIHNldCBvZiA0Q0NzIGNvdWxkIGJlIHVzZWQs IGFzIGl0IHdpbGwgZGVwYXJ0CmZyb20gdGhlIGV4aXN0aW5nIFY0TDIgaW9jdGxzLiBUbyBzdW1t YXJpemUgbXkgb3Bpbmlvbiwgd2UncmUgbm90IHRoZXJlCnlldCwgYnV0IEkgd291bGRuJ3QgcnVs ZSBpdCBvdXQgY29tcGxldGVseSBmb3IgdGhlIGZ1dHVyZS4KCj4gSXQgbG9va3MgbGlrZSBzbyBm YXIsIFY0TDIgcGl4ZWwgZm9ybWF0cyBkZXNjcmliZSBhIERSTSBwaXhlbCBmb3JtYXQgKwo+IG1v ZGlmaWVyLgoKRFJNIG1vZGlmaWVycyBhcmUgbW9zdGx5IGFib3V0IHRpbGluZyBhbmQgY29tcHJl c3Npb24sIGFuZCB3ZSBoYXJkbHkKc3VwcG9ydCB0aGVzZSBpbiBWNEwyLiBXaGF0IGFyZSB0aGUg bW9kaWZpZXJzIHlvdSB0aGluayBhcmUgaGFyZGNvZGVkIGluCjRDQ3MgaW4gVjRMMiA/Cgo+IEkg dGhpbmsgQm9yaXMgKENDZWQpIGlzIHdvcmtpbmcgdG8gY2hhbmdlIHRoYXQgYnkgYWxsb3dpbmcg dG8KPiBwYXNzIGEgRFJNIG1vZGlmaWVyIHRocm91Z2ggVjRMMi4gV2l0aCB0aGF0LCB3ZSdkIGJl IGluIGEgc2l0dWF0aW9uCj4gd2hlcmUgc29tZSBmb3JtYXRzIGFyZSBkZXNjcmliZWQgYnkgdGhl IHY0bDIgcGl4Zm10IGFsb25lIGFuZCBzb21lCj4gZm9ybWF0cyBhcmUgYWxzbyBkZXNjcmliZWQg YSBtb2RpZmllciAoYnV0IEkgbG9va2VkIGF0IGl0IGZyb20gYQo+IGRpc3RhbmNlIHNvIG1pZ2h0 IGhhdmUgbWlzdW5kZXJzdG9kKS4gVGhhdCBmZWVscyBiZXR0ZXIgc2luY2UgaXQgYXZvaWRzCj4g dGhlIGNvbWJpbmF0b3J5IGV4cGxvc2lvbiBmcm9tIGRlc2NyaWJpbmcgZWFjaCBmb3JtYXQgKyBt b2RpZmllcgo+IGluZGl2aWR1YWxseS4KPiAKPiBXaGF0IGRvIHlvdSB0aGluaz8KPiAKPiA+PiB2 NGwgdGVuZHMgdG8gY29uZmxhdGUgcGl4ZWwgZm9ybWF0IHdpdGggc3R1ZmYgdGhhdCB3ZSB0ZW5k IHRvIGVuY29kZQo+ID4+IGluIG1vZGlmaWVycyBhIGxvdCBtb3JlLgo+ID4gCj4gPiBCb3JpcyBp cyB3b3JraW5nIG9uIGFkZGluZyB0aGUgbW9kaWZpZXJzIGNvbmNlcHQgdG8gdjRsMiwgc28gd2Un cmUKPiA+IGNvbnZlcmdpbmcgaGVyZSwgYW5kIHdlIGNhbiB0b3RhbGx5IGhhdmUgYSBsYXllciBp biB2NGwyIHRvIGNvbnZlcnQKPiA+IGJldHdlZW4gb2xkIHY0bDIgImZvcm1hdCttb2RpZmllcnMi IGZvcm1hdHMsIGFuZCBEUk0gc3R5bGUgZm9ybWF0cy4KPiA+IAo+ID4+IFRoZXJlJ3MgYSBidW5j aCBvZiByZWFzb25zIHdlIGNhbid0IGp1c3QgdXNlIHY0bCwgYW5kIHRoZXkncmUgYXMKPiA+PiB2 YWxpZCBhcyBldmVyOgo+ID4+IAo+ID4+IC0gV2Ugb3ZlcmxhcCBiYWRseSBpbiBzb21lIGFyZWFz LCBzbyBldmVuIGlmIGZvdXJjYyBjb2RlcyBtYXRjaCwgd2UKPiA+PiAgIGNhbid0IHVzZSB0aGVt IGFuZCBuZWVkIGEgZHVwbGljYXRlZCBEUk1fRk9VUkNDIGNvZGUuCj4gPiAKPiA+IERvIHlvIGhh dmUgYW4gZXhhbXBsZSBvZiBvbmUgb2YgdGhvc2UgYXJlYXM/Cj4gPiAKPiA+PiAtIHY0bCBlbmNv ZGVzIHNvbWUgbWV0YWRhdGEgaW50byB0aGUgZm91cmNjIHRoYXQgd2UgZW5jb2RlIGVsc2V3aGVy ZSwKPiA+PiAgIGUuZy4gb2Zmc2V0IGZvciBwbGFuYXIgeXV2IGZvcm1hdHMsIG9yIHRpbGluZyBt b2RlCj4gPiAKPiA+IEFzIEkgd2FzIHNheWluZywgdGhpcyBjaGFuZ2VzIG9uIHRoZSB2NGwyIHNp ZGUsIGFuZCBjb252ZXJnaW5nIHRvCj4gPiB3aGF0IERSTSBpcyBkb2luZy4KPiA+IAo+ID4+IC0g ZHJtIGZvdXJjYyBjb2RlIGRvZXNuJ3QgYWN0dWFsbHkgZGVmaW5lIHRoZSBkcm1fZm9ybWF0X2lu Zm8KPiA+PiAgIHVuaXF1ZWx5LCBkcml2ZXJzIGNhbiBvdmVycmlkZSB0aGF0ICh0aGF0J3MgYW4g ZXhwbGljaXQgZGVzaWduCj4gPj4gICBpbnRlbnQgb2YgbW9kaWZpZXJzLCB0byBhbGxvdyBkcml2 ZXJzIHRvIGFkZCBhbm90aGVyIHBsYW5lIGZvcgo+ID4+ICAgZS5nLiBjb21wcmVzc2lvbiBpbmZv cm1hdGlvbikuIFlvdSdkIG5lZWQgdG8gcHVsbCB0aGF0IGRyaXZlcgo+ID4+ICAga25vd2xlZGdl IGludG8geW91ciBmb3JtYXQgbGlicmFyeS4KPiA+IAo+ID4gSSdtIG5vdCBzdXJlIGhvdyBteSBw YXRjaGVzIGFyZSBjaGFuZ2luZyBhbnl0aGluZyBoZXJlLiBUaGlzIGlzCj4gPiBsaXR0ZXJhbGx5 IHRoZSBzYW1lIGNvZGUsIHdpdGggdGhlIGZ1bmN0aW9ucyByZW5hbWVkLgo+ID4gCj4gPiBJZiBk cml2ZXJzIHdhbnQgdG8gb3ZlcnJpZGUgdGhhdCwgdGhlbiB5ZWFoLCBmaW5lLCB3ZSBjYW4gbGV0 IHRoZW0gZG8KPiA+IHRoYXQuIEp1c3QgbGlrZSBhbnkgaGVscGVyIHRoaXMganVzdCBwcm92aWRl cyBhIGRlZmF1bHQgdGhhdCBjb3ZlcnMKPiA+IG1vc3Qgb2YgdGhlIGNhc2VzLgo+ID4gCj4gPj4g SW93IHRoZXJlJ3Mgbm8gd2F5IHdlIGNhbiBlYXNpbHkgYWRvcHQgdjRsIGZvdXJjYywgZXhjZXB0 IGlmIHdlIGRvCj4gPj4gc29tZXRoaW5nIGxpa2UgYSBuZXcgYWRkZmIgZmxhZy4KPiA+IAo+ID4g Rm9yIHRoZSBmb3JtYXRzIHRoYXQgd291bGQgYmUgZGVzY3JpYmVkIGFzIGEgbW9kaWZpZXIsIHN1 cmUuIEZvciBhbGwKPiA+IHRoZSBvdGhlcnMgKHRoYXQgYXJlIG5vdCB5ZXQgc3VwcG9ydGVkIGJ5 IERSTSksIHRoZW4gSSBkb24ndCByZWFsbHkKPiA+IHNlZSB3aHkgbm90Lgo+ID4gCj4gPj4+IEFu ZCBnaXZlbiBob3cgdGhlIGN1cnJlbnQgc3RhdGUgaXMgYSBtZXNzIGluIHRoaXMgcmVnYXJkLCBJ J20gbm90IHRvbwo+ID4+PiBvcHRpbWlzdGljIGFib3V0IGtlZXBpbmcgdGhlIGZvcm1hdHMgaW4g dGhlaXIgcmVsZXZhbnQgZnJhbWV3b3Jrcy4KPiA+Pj4gCj4gPj4+IEhhdmluZyBhIHNoYXJlZCBs aWJyYXJ5LCBnb3Zlcm5lZCBieSBib3RoLCB3aWxsIG1ha2UgdGhpcyBmYXIgZWFzaWVyLAo+ID4+ PiBzaW5jZSBpdCB3aWxsIGJlIGVhc3kgdG8gZGlzY292ZXIgdGhlIGZvcm1hdHMgdGhhdCBhcmUg YWxyZWFkeQo+ID4+PiBzdXBwb3J0ZWQgYnkgdGhlIG90aGVyIHN1YnN5c3RlbS4KPiA+PiAKPiA+ PiBJIHRoaW5rIGEgY29tcGF0IGxpYnJhcnkgdGhhdCAodHJpZXMgdG8sIGJlc3QgZWZmb3J0KSBj b252ZXJ0IGJldHdlZW4KPiA+PiB2NGwgYW5kIGRybSBmb3VyY2Mgd291bGQgbWFrZSBzZW5zZS4g U29tZXdoZXJlIGluIGRyaXZlcnMvdmlkZW8sIG5leHQKPiA+PiB0byB0aGUgY29udmVyc2lvbiBm dW5jdGlvbnMgZm9yIHZpZGVvbW9kZSA8LT4gZHJtX2Rpc3BsYXlfbW9kZQo+ID4+IHBlcmhhcHMu IFRoYXQgc2hvdWxkIGJlIHVzZWZ1bCBmb3IgZHJpdmVycy4KPiA+IAo+ID4gVGhhdCdzIG5vdCBy ZWFsbHkgd2hhdCB0aGlzIHNlcmllcyBpcyBhYm91dCB0aG91Z2guIFRoYXQgc2VyaWVzIGlzCj4g PiBhYm91dCBzaGFyaW5nIHRoZSAoaW1hZ2V8cGl4ZWxzKSBmb3JtYXRzIGRhdGFiYXNlIGFjcm9z cyBldmVyeW9uZSBzbwo+ID4gdGhhdCBldmVyeW9uZSBjYW4gYmVuZWZpdCBmcm9tIGl0Lgo+ID4g Cj4gPj4gVW5pZnlpbmcgdGhlIGZvcm1hdHMgdGhlbXNlbHZlcywgYW5kIGFsbCB0aGUgYXNzb2Np YXRlZCBtZXRhZGF0YSBpcwo+ID4+IGltbyBhIG5vLWdvLCBhbmQgd2FzIGEgcHJldHR5IGNvbnNj aW91cyBkZWNpc2lvbiB3aGVuIHdlIGltcGxlbWVudGVkCj4gPj4gZHJtX2ZvdXJjYyBhIGZldyB5 ZWFycyBiYWNrLgo+ID4+IAo+ID4+PiBJZiB3ZSB3YW50IHRvIGtlZXAgdGhlIGN1cnJlbnQgbGli cmFyeSBpbiBEUk0sIHdlIGhhdmUgdHdvIG9wdGlvbnMKPiA+Pj4gdGhlbjoKPiA+Pj4gCj4gPj4+ ICAgLSBTdXBwb3J0IGFsbCB0aGUgdjRsMiBmb3JtYXRzIGluIHRoZSBEUk0gbGlicmFyeSwgd2hp Y2ggaXMKPiA+Pj4gICAgIGVzc2VudGlhbGx5IHdoYXQgSSdtIGRvaW5nIGluIHRoZSBsYXN0IHBh dGNoZXMuIEhvd2V2ZXIsIHRoYXQKPiA+Pj4gICAgIHdvdWxkIHJlcXVpcmUgdG8gaGF2ZSB0aGUg djRsMiBkZXZlbG9wcGVycyBhbHNvIHJldmlld2luZyBzdHVmZgo+ID4+PiAgICAgdGhlcmUuIEFu ZCBnaXZlbiBob3cgYnVzeSB0aGV5IGFyZSwgSSBjYW5ub3QgcmVhbGx5IHNlZSBob3cgdGhhdAo+ ID4+PiAgICAgd291bGQgd29yay4KPiA+PiAKPiA+PiBXZWxsLCBpZiB3ZSBlbmQgdXAgd2l0aCBh IGNvbW1vbiBsaWJyYXJ5IHRoZW4geWVzIHdlIG5lZWQgY3Jvc3MKPiA+PiByZXZpZXcuIFRoZXJl J3Mgbm8gd2F5IGFyb3VuZCB0aGF0LiBEb2Vzbid0IG1hdHRlciB3aGVyZSBleGFjdGx5IHRoYXQK PiA+PiBsaWJyYXJ5IGlzIGluIHRoZSBmaWxlc3lzdGVtIHRyZWUsIGFuZCBhZGRpbmcgYSBzcGVj aWFsIE1BSU5UQUlORVJTCj4gPj4gZW50cnkgZm9yIGFueXRoaW5nIHJlbGF0ZWQgdG8gZm91cmNj IChib3RoIGRybSBhbmQgdjRsKSB0byBtYWtlIHN1cmUKPiA+PiB0aGV5IGdldCBjcm9zcy1wb3N0 ZWQgaXMgZWFzeS4gTm8gZmlsZSByZW5hbWluZyBuZWVkZWQuCj4gPiAKPiA+IFRoYXQgd291bGQg Y3JlYXRlIHNvbWUgZ292ZXJuaW5nIGlzc3VlcyBhcyB3ZWxsLiBGb3IgZXhhbXBsZSwgaWYgeW91 Cj4gPiBldmVyIGhhdmUgYSBwYXRjaCBmcm9tIG9uZSBmb3VyY2MgYWRkaXRpb24gKHRoYXQgbWln aHQgb3IgbWlnaHQgbm90IGJlCj4gPiBjb3ZlcmVkIGJ5IHY0bDIpLCB3aWxsIHlvdSB3YWl0IGZv ciBhbnkgdjRsMiBkZXZlbG9wcGVyIHRvIHJldmlldyBpdD8KPiA+IAo+ID4gSWYgaXQncyBzaGFy ZWQgY29kZSwgdGhlbiBpdCBzaG91bGQgYmUgc2hhcmVkLCBhbmQgZXZlcnkgY2xpZW50Cj4gPiBm cmFtZXdvcmsgcHV0IG9uIGFuIGVxdWFsIGZvb3RpbmcuCj4gPiAKPiA+Pj4gICAtIERldmVsb3Ag dGhlIHNhbWUgbGlicmFyeSBmcm9tIHdpdGhpbiB2NGwyLiBUaGF0IGlzIHJlYWxseSBhIHBvb3IK PiA+Pj4gICAgIHNvbHV0aW9uLCBzaW5jZSB0aGUgaW5mb3JtYXRpb24gd291bGQgYmUgZ3JlYXRs eSBkdXBsaWNhdGVkCj4gPj4+ICAgICBiZXR3ZWVuIHRoZSB0d28sIGFuZCBpbiB0ZXJtcyBvZiBt YWludGFpbmFuY2UsIGNvZGUsIGFuZCBiaW5hcnkKPiA+Pj4gICAgIHNpemUgdGhhdCB3b3VsZCBi ZSBkdXBsaWNhdGVkIHRvby4KPiA+PiAKPiA+PiBJdCdzIGVzc2VudGlhbGx5IHdoYXQgd2UgZGVj aWRlZCB0byBkbyBmb3IgZHJtIHllYXJzIGJhY2suCj4gPiAKPiA+IEFuZCBpdCB3YXMgcHJvYmFi bHkgdGhlIHJpZ2h0IHNvbHV0aW9uIGJhY2sgdGhlbiwgYnV0IEknbSByZWFsbHkgbm90Cj4gPiBj b252aW5jZWQgaXQncyBzdGlsbCB0aGUgcmlnaHQgdGhpbmcgdG8gZG8gdG9kYXkuCj4gPiAKPiA+ Pj4gSGF2aW5nIGl0IHNoYXJlZCBhbGxvd3MgdG8gZWFzaWx5IHNoYXJlLCBhbmQgZGlzY292ZXIg Zm9ybWF0cyBmcm9tIHRoZQo+ID4+PiBvdGhlciBzdWJzeXN0ZW0sIGFuZCB0byBoYXZlIGEgc2lu Z2xlLCB1bmlxdWUgcGxhY2Ugd2hlcmUgdGhpcyBpcwo+ID4+PiBjZW50cmFsaXplZC4KPiA+PiAK PiA+PiBXaGF0IEkgdGhpbmsgY291bGQgd29yayBhcyBtaWRkbGUgZ3JvdW5kOgo+ID4+IC0gUHV0 IGRybV9mb3JtYXQgc3R1ZmYgaW50byBhIHNlcGFyYXRlIC5rbwo+ID4+IC0gQWRkIGEgTUFJTlRB SU5FUlMgZW50cnkgdG8gbWFrZSBzdXJlIGFsbCB0aGluZ3MgZm91cmNjIGFyZSBjcm9zcwo+ID4+ IHBvc3RlZCB0byBib3RoIGRybSBhbmQgdjRsIGxpc3RzLiBFYXN5IG9uIHRoZSBkcm0gc2lkZSwg c2luY2UgaXQncyBhbGwKPiA+PiBzZXBhcmF0ZSBmaWxlcy4gTm90IHN1cmUgaXQncyBzbyBjb252 ZW5pZW50IGZvciB2NGwgdWFwaS4KPiA+PiAtIEFkZCBhIGNvbnZlcnNpb24gbGlicmFyeSB0aGF0 IHRyaWVzIHRvIGJlc3QtZWZmb3J0IG1hcCBiZXR3ZWVuIGRybQo+ID4+IGFuZCB2NGwgZm9ybWF0 cy4gT24gdGhlIGRybSBzaWRlIHRoYXQgbW9zdCBsaWtlbHkgbWVhbnMgeW91IG5lZWQKPiA+PiBv ZmZzZXRzIGZvciBwbGFuZXMsIGFuZCBtb2RpZmllcnMgdG9vIChzaW5jZSB0aG9zZSBhcmUgaW1w bGllZCBpbiBzb21lCj4gPj4gdjRsIGZvdXJjYykuIEVtcGhhc2lzIG9uICJiZXN0IGVmZm9ydCIg aS5lLiBvbmx5IHN1cHBvcnQgYXMgbXVjaCBhcwo+ID4+IHRoZSBkcml2ZXJzIHRoYXQgdXNlIHRo aXMgbGlicmFyeSBuZWVkLgo+ID4+IC0gQWRkIGRybV9mb3VyY2MgYXMtbmVlZGVkIGJ5IHRoZXNl IGRyaXZlcnMgdGhhdCB3YW50IHRvIHVzZSBhIHVuaWZpZWQKPiA+PiBmb3JtYXQgc3BhY2UuCj4g Pj4gCj4gPj4gRm9yY2luZyB0aGlzIHVuaWZpY2F0aW9uIG9uIGV2ZXJ5b25lIG90b2ggaXMgaW1v IHdheSB0b28gbXVjaC4KPiA+IAo+ID4gdjRsMiBpcyBzdGFydGluZyB0byBjb252ZXJnZSB3aXRo IERSTSwgYW5kIHdlJ3JlIHVzaW5nIHRoZSBEUk0gQVBJCj4gPiBwcmV0dHkgbXVjaCB1bnRvdWNo ZWQgZm9yIHRoYXQgbGlicmFyeSwgc28gSSdtIG5vdCByZWFsbHkgc3VyZSBob3cKPiA+IGFueW9u ZSBpcyBodXJ0IGJ5IHRoYXQgdW5pZmljYXRpb24uCgotLSAKUmVnYXJkcywKCkxhdXJlbnQgUGlu Y2hhcnQKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJp LWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBz Oi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs