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.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 2B765C76188 for ; Fri, 19 Jul 2019 14:15:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0055821849 for ; Fri, 19 Jul 2019 14:15:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729415AbfGSOPd (ORCPT ); Fri, 19 Jul 2019 10:15:33 -0400 Received: from mga17.intel.com ([192.55.52.151]:59297 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727717AbfGSOPd (ORCPT ); Fri, 19 Jul 2019 10:15:33 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2019 07:15:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,282,1559545200"; d="scan'208";a="176303842" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by FMSMGA003.fm.intel.com with SMTP; 19 Jul 2019 07:15:29 -0700 Received: by stinkbox (sSMTP sendmail emulation); Fri, 19 Jul 2019 17:15:28 +0300 Date: Fri, 19 Jul 2019 17:15:28 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Sean Paul Cc: Daniel Vetter , linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, pdhaval@codeaurora.org, seanpaul@chromium.org, Daniel Vetter , freedreno@lists.freedesktop.org Subject: Re: [RFC] Expanding drm_mode_modeinfo flags Message-ID: <20190719141528.GN5942@intel.com> References: <1562870805-32314-1-git-send-email-jsanka@codeaurora.org> <20190716090712.GY15868@phenom.ffwll.local> <16fee2b42fa03d2cf104452223dcf5af@codeaurora.org> <20190719090553.GF15868@phenom.ffwll.local> <20190719135558.GC104440@art_vandelay> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190719135558.GC104440@art_vandelay> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Fri, Jul 19, 2019 at 09:55:58AM -0400, Sean Paul wrote: > On Fri, Jul 19, 2019 at 11:05:53AM +0200, Daniel Vetter wrote: > > On Thu, Jul 18, 2019 at 11:18:42AM -0700, Jeykumar Sankaran wrote: > > > On 2019-07-16 02:07, Daniel Vetter wrote: > > > > On Thu, Jul 11, 2019 at 11:46:44AM -0700, Jeykumar Sankaran wrote: > > > > > Hello All, > > > > > drm_mode_modeinfo::flags is a 32 bit field currently used to > > > > > describe the properties of a connector mode. I see the least order > > > > 22 bits > > > > > are already in use. Posting this RFC to discuss on any potential > > > > plans to > > > > > expand the bit range support of this field for growing mode > > > > properties and > > > > > ways to handle one such property needed by the msm dpu driver. > > > > > > > > > > msm drivers support panels which can dynamically switch between > > > > > video(active) and command(smart) modes. Within video mode, they > > > > > also > > > > support > > > > > switching between resolutions seamlessly i.e. glitch free > > > > > resolution > > > > switch. > > > > > But they cannot do a seamless switch from a resolutions from video > > > > to > > > > > command or vice versa. Clients need to be aware for these > > > > capablities before > > > > > they switch between the resolutions. Since these capabilities are > > > > identified > > > > > per drm_mode, we are considering the below two approaches to > > > > > handle > > > > this > > > > > use case. > > > > > > > > > > Option 1: > > > > > Attached patch adds flag values to associate a drm_mode to > > > > video/command > > > > > mode and to indicate its capability to do a seamless switch. > > > > > > > > > > Option 2: > > > > > drm_mode_modeinfo can expose a new "private_flags" field to handle > > > > vendor > > > > > specific mode flags. Besides the above mentioned use case, we are > > > > also > > > > > expoloring methods to handle some of our display port resolution > > > > switch use > > > > > cases where the DP ports can be operated in a tiled/detiled modes. > > > > This > > > > > approach will provide a standard channel for drm driver vendors > > > > > for > > > > their > > > > > growing need for drm_mode specific capabilities. > > > > > > > > > > Please provide your inputs on the options or any upstream friendly > > > > > recommendation to handle such custom use cases. > > > > > > > > > > Thanks and Regards, > > > > > Jeykumar S. > > > > > > > > > > Jeykumar Sankaran (1): > > > > > drm: add mode flags in uapi for seamless mode switch > > > > > > > > I think the uapi is the trivial part here, the real deal is how > > > > userspace > > > > uses this. Can you pls post the patches for your compositor? > > > > > > > > Also note that we already allow userspace to tell the kernel whether > > > > flickering is ok or not for a modeset. msm driver could use that to at > > > > least tell userspace whether a modeset change is possible. So you can > > > > already implement glitch-free modeset changes for at least video mode. > > > > -Daniel > > > > > > I believe you are referring to the below tv property of the connector. > > > > > > /** > > > * @tv_flicker_reduction_property: Optional TV property to control the > > > * flicker reduction mode. > > > */ > > > struct drm_property *tv_flicker_reduction_property; > > > > Not even close :-) > > > > I mean the DRM_MODE_ATOMIC_ALLOW_MODESET flag for the atomic ioctl. This > > is not a property of a mode, this is a property of a _transition_ between > > configurations. Some transitions can be done flicker free, others can't. > > Agree that an atomic flag on a commit is the way to accomplish this. It's pretty > similar to the psr transitions, where we want to reuse most of the atomic > circuitry, but in a specialized way. We'd also have to be careful to only > involve the drm objects which are seamless modeset aware (you could imagine > a bridge chain where the bridges downstream of the first bridge don't care). > > > > > There's then still the question of how to pick video vs command mode, but > > imo better to start with implementing the transition behaviour correctly > > first. > > Connector property? Possibly a terrible idea, but I wonder if we could [re]use > the vrr properties for command mode. The docs state that the driver has the > option of putting upper and lower bounds on the refresh rate. Not really sure why this needs new props and whatnot. This is kinda what the i915 "fastset" stuff already does: 1. userspace asks for something to be changed via atomic 2. driver calculates whether a modeset is actually required 3. atomic validates need_modeset() vs. DRM_MODE_ATOMIC_ALLOW_MODESET 4. if (need_modeset) heavyweight_commit() else lightweight_commit() Ie. why should userspace really care about anything except the "flickers are OK" vs. "flickers not wanted" thing? Also what's the benefit of using video mode if your panel supportes command mode? Can you turn off the memory in the panel and actually save power that way? And if there is a benefit can't the driver just automagically switch between the two based on how often things are getting updated? That would match how eDP PSR already works. -- Ville Syrjälä Intel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [RFC] Expanding drm_mode_modeinfo flags Date: Fri, 19 Jul 2019 17:15:28 +0300 Message-ID: <20190719141528.GN5942@intel.com> References: <1562870805-32314-1-git-send-email-jsanka@codeaurora.org> <20190716090712.GY15868@phenom.ffwll.local> <16fee2b42fa03d2cf104452223dcf5af@codeaurora.org> <20190719090553.GF15868@phenom.ffwll.local> <20190719135558.GC104440@art_vandelay> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <20190719135558.GC104440@art_vandelay> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Sean Paul Cc: linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, pdhaval@codeaurora.org, seanpaul@chromium.org, Daniel Vetter , freedreno@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org T24gRnJpLCBKdWwgMTksIDIwMTkgYXQgMDk6NTU6NThBTSAtMDQwMCwgU2VhbiBQYXVsIHdyb3Rl Ogo+IE9uIEZyaSwgSnVsIDE5LCAyMDE5IGF0IDExOjA1OjUzQU0gKzAyMDAsIERhbmllbCBWZXR0 ZXIgd3JvdGU6Cj4gPiBPbiBUaHUsIEp1bCAxOCwgMjAxOSBhdCAxMToxODo0MkFNIC0wNzAwLCBK ZXlrdW1hciBTYW5rYXJhbiB3cm90ZToKPiA+ID4gT24gMjAxOS0wNy0xNiAwMjowNywgRGFuaWVs IFZldHRlciB3cm90ZToKPiA+ID4gPiBPbiBUaHUsIEp1bCAxMSwgMjAxOSBhdCAxMTo0Njo0NEFN IC0wNzAwLCBKZXlrdW1hciBTYW5rYXJhbiB3cm90ZToKPiA+ID4gPiA+ICAgICBIZWxsbyBBbGws Cj4gPiA+ID4gPiAgICAgCWRybV9tb2RlX21vZGVpbmZvOjpmbGFncyBpcyBhIDMyIGJpdCBmaWVs ZCBjdXJyZW50bHkgdXNlZCB0bwo+ID4gPiA+ID4gICAgIGRlc2NyaWJlIHRoZSBwcm9wZXJ0aWVz IG9mIGEgY29ubmVjdG9yIG1vZGUuIEkgc2VlIHRoZSBsZWFzdCBvcmRlcgo+ID4gPiA+IDIyIGJp dHMKPiA+ID4gPiA+ICAgICBhcmUgYWxyZWFkeSBpbiB1c2UuIFBvc3RpbmcgdGhpcyBSRkMgdG8g ZGlzY3VzcyBvbiBhbnkgcG90ZW50aWFsCj4gPiA+ID4gcGxhbnMgdG8KPiA+ID4gPiA+ICAgICBl eHBhbmQgdGhlIGJpdCByYW5nZSBzdXBwb3J0IG9mIHRoaXMgZmllbGQgZm9yIGdyb3dpbmcgbW9k ZQo+ID4gPiA+IHByb3BlcnRpZXMgYW5kCj4gPiA+ID4gPiAgICAgd2F5cyB0byBoYW5kbGUgb25l IHN1Y2ggcHJvcGVydHkgbmVlZGVkIGJ5IHRoZSBtc20gZHB1IGRyaXZlci4KPiA+ID4gPiA+IAo+ ID4gPiA+ID4gICAgIG1zbSBkcml2ZXJzIHN1cHBvcnQgcGFuZWxzIHdoaWNoIGNhbiBkeW5hbWlj YWxseSBzd2l0Y2ggYmV0d2Vlbgo+ID4gPiA+ID4gICAgIHZpZGVvKGFjdGl2ZSkgYW5kIGNvbW1h bmQoc21hcnQpIG1vZGVzLiBXaXRoaW4gdmlkZW8gbW9kZSwgdGhleQo+ID4gPiA+ID4gYWxzbwo+ ID4gPiA+IHN1cHBvcnQKPiA+ID4gPiA+ICAgICBzd2l0Y2hpbmcgYmV0d2VlbiByZXNvbHV0aW9u cyBzZWFtbGVzc2x5IGkuZS4gZ2xpdGNoIGZyZWUKPiA+ID4gPiA+IHJlc29sdXRpb24KPiA+ID4g PiBzd2l0Y2guCj4gPiA+ID4gPiAgICAgQnV0IHRoZXkgY2Fubm90IGRvIGEgc2VhbWxlc3Mgc3dp dGNoIGZyb20gYSByZXNvbHV0aW9ucyBmcm9tIHZpZGVvCj4gPiA+ID4gdG8KPiA+ID4gPiA+ICAg ICBjb21tYW5kIG9yIHZpY2UgdmVyc2EuIENsaWVudHMgbmVlZCB0byBiZSBhd2FyZSBmb3IgdGhl c2UKPiA+ID4gPiBjYXBhYmxpdGllcyBiZWZvcmUKPiA+ID4gPiA+ICAgICB0aGV5IHN3aXRjaCBi ZXR3ZWVuIHRoZSByZXNvbHV0aW9ucy4gU2luY2UgdGhlc2UgY2FwYWJpbGl0aWVzIGFyZQo+ID4g PiA+IGlkZW50aWZpZWQKPiA+ID4gPiA+ICAgICBwZXIgZHJtX21vZGUsIHdlIGFyZSBjb25zaWRl cmluZyB0aGUgYmVsb3cgdHdvIGFwcHJvYWNoZXMgdG8KPiA+ID4gPiA+IGhhbmRsZQo+ID4gPiA+ IHRoaXMKPiA+ID4gPiA+ICAgICB1c2UgY2FzZS4KPiA+ID4gPiA+IAo+ID4gPiA+ID4gICAgIE9w dGlvbiAxOgo+ID4gPiA+ID4gICAgIEF0dGFjaGVkIHBhdGNoIGFkZHMgZmxhZyB2YWx1ZXMgdG8g YXNzb2NpYXRlIGEgZHJtX21vZGUgdG8KPiA+ID4gPiB2aWRlby9jb21tYW5kCj4gPiA+ID4gPiAg ICAgbW9kZSBhbmQgdG8gaW5kaWNhdGUgaXRzIGNhcGFiaWxpdHkgdG8gZG8gYSBzZWFtbGVzcyBz d2l0Y2guCj4gPiA+ID4gPiAKPiA+ID4gPiA+ICAgICBPcHRpb24gMjoKPiA+ID4gPiA+ICAgICBk cm1fbW9kZV9tb2RlaW5mbyBjYW4gZXhwb3NlIGEgbmV3ICJwcml2YXRlX2ZsYWdzIiBmaWVsZCB0 byBoYW5kbGUKPiA+ID4gPiB2ZW5kb3IKPiA+ID4gPiA+ICAgICBzcGVjaWZpYyBtb2RlIGZsYWdz LiBCZXNpZGVzIHRoZSBhYm92ZSBtZW50aW9uZWQgdXNlIGNhc2UsIHdlIGFyZQo+ID4gPiA+IGFs c28KPiA+ID4gPiA+ICAgICBleHBvbG9yaW5nIG1ldGhvZHMgdG8gaGFuZGxlIHNvbWUgb2Ygb3Vy IGRpc3BsYXkgcG9ydCByZXNvbHV0aW9uCj4gPiA+ID4gc3dpdGNoIHVzZQo+ID4gPiA+ID4gICAg IGNhc2VzIHdoZXJlIHRoZSBEUCBwb3J0cyBjYW4gYmUgb3BlcmF0ZWQgaW4gYSB0aWxlZC9kZXRp bGVkIG1vZGVzLgo+ID4gPiA+IFRoaXMKPiA+ID4gPiA+ICAgICBhcHByb2FjaCB3aWxsIHByb3Zp ZGUgYSBzdGFuZGFyZCBjaGFubmVsIGZvciBkcm0gZHJpdmVyIHZlbmRvcnMKPiA+ID4gPiA+IGZv cgo+ID4gPiA+IHRoZWlyCj4gPiA+ID4gPiAgICAgZ3Jvd2luZyBuZWVkIGZvciBkcm1fbW9kZSBz cGVjaWZpYyBjYXBhYmlsaXRpZXMuCj4gPiA+ID4gPiAKPiA+ID4gPiA+ICAgICBQbGVhc2UgcHJv dmlkZSB5b3VyIGlucHV0cyBvbiB0aGUgb3B0aW9ucyBvciBhbnkgdXBzdHJlYW0gZnJpZW5kbHkK PiA+ID4gPiA+ICAgICByZWNvbW1lbmRhdGlvbiB0byBoYW5kbGUgc3VjaCBjdXN0b20gdXNlIGNh c2VzLgo+ID4gPiA+ID4gCj4gPiA+ID4gPiAgICAgVGhhbmtzIGFuZCBSZWdhcmRzLAo+ID4gPiA+ ID4gICAgIEpleWt1bWFyIFMuCj4gPiA+ID4gPiAKPiA+ID4gPiA+IEpleWt1bWFyIFNhbmthcmFu ICgxKToKPiA+ID4gPiA+ICAgZHJtOiBhZGQgbW9kZSBmbGFncyBpbiB1YXBpIGZvciBzZWFtbGVz cyBtb2RlIHN3aXRjaAo+ID4gPiA+IAo+ID4gPiA+IEkgdGhpbmsgdGhlIHVhcGkgaXMgdGhlIHRy aXZpYWwgcGFydCBoZXJlLCB0aGUgcmVhbCBkZWFsIGlzIGhvdwo+ID4gPiA+IHVzZXJzcGFjZQo+ ID4gPiA+IHVzZXMgdGhpcy4gQ2FuIHlvdSBwbHMgcG9zdCB0aGUgcGF0Y2hlcyBmb3IgeW91ciBj b21wb3NpdG9yPwo+ID4gPiA+IAo+ID4gPiA+IEFsc28gbm90ZSB0aGF0IHdlIGFscmVhZHkgYWxs b3cgdXNlcnNwYWNlIHRvIHRlbGwgdGhlIGtlcm5lbCB3aGV0aGVyCj4gPiA+ID4gZmxpY2tlcmlu ZyBpcyBvayBvciBub3QgZm9yIGEgbW9kZXNldC4gbXNtIGRyaXZlciBjb3VsZCB1c2UgdGhhdCB0 byBhdAo+ID4gPiA+IGxlYXN0IHRlbGwgdXNlcnNwYWNlIHdoZXRoZXIgYSBtb2Rlc2V0IGNoYW5n ZSBpcyBwb3NzaWJsZS4gU28geW91IGNhbgo+ID4gPiA+IGFscmVhZHkgaW1wbGVtZW50IGdsaXRj aC1mcmVlIG1vZGVzZXQgY2hhbmdlcyBmb3IgYXQgbGVhc3QgdmlkZW8gbW9kZS4KPiA+ID4gPiAt RGFuaWVsCj4gPiA+IAo+ID4gPiBJIGJlbGlldmUgeW91IGFyZSByZWZlcnJpbmcgdG8gdGhlIGJl bG93IHR2IHByb3BlcnR5IG9mIHRoZSBjb25uZWN0b3IuCj4gPiA+IAo+ID4gPiAvKioKPiA+ID4g ICogQHR2X2ZsaWNrZXJfcmVkdWN0aW9uX3Byb3BlcnR5OiBPcHRpb25hbCBUViBwcm9wZXJ0eSB0 byBjb250cm9sIHRoZQo+ID4gPiAgKiBmbGlja2VyIHJlZHVjdGlvbiBtb2RlLgo+ID4gPiAgKi8K PiA+ID4gc3RydWN0IGRybV9wcm9wZXJ0eSAqdHZfZmxpY2tlcl9yZWR1Y3Rpb25fcHJvcGVydHk7 Cj4gPiAKPiA+IE5vdCBldmVuIGNsb3NlIDotKQo+ID4gCj4gPiBJIG1lYW4gdGhlIERSTV9NT0RF X0FUT01JQ19BTExPV19NT0RFU0VUIGZsYWcgZm9yIHRoZSBhdG9taWMgaW9jdGwuIFRoaXMKPiA+ IGlzIG5vdCBhIHByb3BlcnR5IG9mIGEgbW9kZSwgdGhpcyBpcyBhIHByb3BlcnR5IG9mIGEgX3Ry YW5zaXRpb25fIGJldHdlZW4KPiA+IGNvbmZpZ3VyYXRpb25zLiBTb21lIHRyYW5zaXRpb25zIGNh biBiZSBkb25lIGZsaWNrZXIgZnJlZSwgb3RoZXJzIGNhbid0Lgo+IAo+IEFncmVlIHRoYXQgYW4g YXRvbWljIGZsYWcgb24gYSBjb21taXQgaXMgdGhlIHdheSB0byBhY2NvbXBsaXNoIHRoaXMuIEl0 J3MgcHJldHR5Cj4gc2ltaWxhciB0byB0aGUgcHNyIHRyYW5zaXRpb25zLCB3aGVyZSB3ZSB3YW50 IHRvIHJldXNlIG1vc3Qgb2YgdGhlIGF0b21pYwo+IGNpcmN1aXRyeSwgYnV0IGluIGEgc3BlY2lh bGl6ZWQgd2F5LiBXZSdkIGFsc28gaGF2ZSB0byBiZSBjYXJlZnVsIHRvIG9ubHkKPiBpbnZvbHZl IHRoZSBkcm0gb2JqZWN0cyB3aGljaCBhcmUgc2VhbWxlc3MgbW9kZXNldCBhd2FyZSAoeW91IGNv dWxkIGltYWdpbmUKPiBhIGJyaWRnZSBjaGFpbiB3aGVyZSB0aGUgYnJpZGdlcyBkb3duc3RyZWFt IG9mIHRoZSBmaXJzdCBicmlkZ2UgZG9uJ3QgY2FyZSkuCj4gCj4gPiAKPiA+IFRoZXJlJ3MgdGhl biBzdGlsbCB0aGUgcXVlc3Rpb24gb2YgaG93IHRvIHBpY2sgdmlkZW8gdnMgY29tbWFuZCBtb2Rl LCBidXQKPiA+IGltbyBiZXR0ZXIgdG8gc3RhcnQgd2l0aCBpbXBsZW1lbnRpbmcgdGhlIHRyYW5z aXRpb24gYmVoYXZpb3VyIGNvcnJlY3RseQo+ID4gZmlyc3QuCj4gCj4gQ29ubmVjdG9yIHByb3Bl cnR5PyBQb3NzaWJseSBhIHRlcnJpYmxlIGlkZWEsIGJ1dCBJIHdvbmRlciBpZiB3ZSBjb3VsZCBb cmVddXNlCj4gdGhlIHZyciBwcm9wZXJ0aWVzIGZvciBjb21tYW5kIG1vZGUuIFRoZSBkb2NzIHN0 YXRlIHRoYXQgdGhlIGRyaXZlciBoYXMgdGhlCj4gb3B0aW9uIG9mIHB1dHRpbmcgdXBwZXIgYW5k IGxvd2VyIGJvdW5kcyBvbiB0aGUgcmVmcmVzaCByYXRlLgoKTm90IHJlYWxseSBzdXJlIHdoeSB0 aGlzIG5lZWRzIG5ldyBwcm9wcyBhbmQgd2hhdG5vdC4gVGhpcyBpcyBraW5kYSB3aGF0CnRoZSBp OTE1ICJmYXN0c2V0IiBzdHVmZiBhbHJlYWR5IGRvZXM6CjEuIHVzZXJzcGFjZSBhc2tzIGZvciBz b21ldGhpbmcgdG8gYmUgY2hhbmdlZCB2aWEgYXRvbWljCjIuIGRyaXZlciBjYWxjdWxhdGVzIHdo ZXRoZXIgYSBtb2Rlc2V0IGlzIGFjdHVhbGx5IHJlcXVpcmVkCjMuIGF0b21pYyB2YWxpZGF0ZXMg bmVlZF9tb2Rlc2V0KCkgdnMuIERSTV9NT0RFX0FUT01JQ19BTExPV19NT0RFU0VUCjQuIGlmIChu ZWVkX21vZGVzZXQpIGhlYXZ5d2VpZ2h0X2NvbW1pdCgpIGVsc2UgbGlnaHR3ZWlnaHRfY29tbWl0 KCkKCkllLiB3aHkgc2hvdWxkIHVzZXJzcGFjZSByZWFsbHkgY2FyZSBhYm91dCBhbnl0aGluZyBl eGNlcHQgdGhlCiJmbGlja2VycyBhcmUgT0siIHZzLiAiZmxpY2tlcnMgbm90IHdhbnRlZCIgdGhp bmc/CgpBbHNvIHdoYXQncyB0aGUgYmVuZWZpdCBvZiB1c2luZyB2aWRlbyBtb2RlIGlmIHlvdXIg cGFuZWwgc3VwcG9ydGVzCmNvbW1hbmQgbW9kZT8gQ2FuIHlvdSB0dXJuIG9mZiB0aGUgbWVtb3J5 IGluIHRoZSBwYW5lbCBhbmQgYWN0dWFsbHkKc2F2ZSBwb3dlciB0aGF0IHdheT8gQW5kIGlmIHRo ZXJlIGlzIGEgYmVuZWZpdCBjYW4ndCB0aGUgZHJpdmVyIGp1c3QKYXV0b21hZ2ljYWxseSBzd2l0 Y2ggYmV0d2VlbiB0aGUgdHdvIGJhc2VkIG9uIGhvdyBvZnRlbiB0aGluZ3MgYXJlCmdldHRpbmcg dXBkYXRlZD8gVGhhdCB3b3VsZCBtYXRjaCBob3cgZURQIFBTUiBhbHJlYWR5IHdvcmtzLgoKLS0g ClZpbGxlIFN5cmrDpGzDpApJbnRlbApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVl ZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5m by9kcmktZGV2ZWw=