From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 00/20] drm: Split out the formats API and move it to a common place Date: Mon, 13 May 2019 16:57:19 +0200 Message-ID: <20190513145719.GS17751@phenom.ffwll.local> References: <20190417154121.GJ13337@phenom.ffwll.local> <20190418062229.eyog4i62eg4pr6uf@flea> <20190418090221.e57dogn4yx5nwdni@flea> <20190420225904.GZ4964@pendragon.ideasonboard.com> <20190423072554.GW13337@phenom.ffwll.local> <20190423154527.GH16111@pendragon.ideasonboard.com> <20190511192632.GN13043@pendragon.ideasonboard.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) by gabe.freedesktop.org (Postfix) with ESMTPS id 148D789F27 for ; Mon, 13 May 2019 14:57:26 +0000 (UTC) Received: by mail-ed1-x542.google.com with SMTP id g57so17986618edc.12 for ; Mon, 13 May 2019 07:57:26 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20190511192632.GN13043@pendragon.ideasonboard.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Laurent Pinchart Cc: Thomas Petazzoni , Sakari Ailus , Maxime Ripard , Linux Kernel Mailing List , dri-devel , Paul Kocialkowski , David Airlie , Hans Verkuil , Sean Paul , Daniel Vetter , Mauro Carvalho Chehab , "open list:DMA BUFFER SHARING FRAMEWORK" List-Id: dri-devel@lists.freedesktop.org T24gU2F0LCBNYXkgMTEsIDIwMTkgYXQgMTA6MjY6MzJQTSArMDMwMCwgTGF1cmVudCBQaW5jaGFy dCB3cm90ZToKPiBPbiBUdWUsIEFwciAyMywgMjAxOSBhdCAwOToxODo1MlBNICswMjAwLCBEYW5p ZWwgVmV0dGVyIHdyb3RlOgo+ID4gT24gVHVlLCBBcHIgMjMsIDIwMTkgYXQgNTo0NSBQTSBMYXVy ZW50IFBpbmNoYXJ0IHdyb3RlOgo+ID4gPiBPbiBUdWUsIEFwciAyMywgMjAxOSBhdCAwOToyNTo1 NEFNICswMjAwLCBEYW5pZWwgVmV0dGVyIHdyb3RlOgo+ID4gPj4gT24gU3VuLCBBcHIgMjEsIDIw MTkgYXQgMDE6NTk6MDRBTSArMDMwMCwgTGF1cmVudCBQaW5jaGFydCB3cm90ZToKPiA+ID4+PiBP biBUaHUsIEFwciAxOCwgMjAxOSBhdCAxMjowNzo0NFBNICswMjAwLCBEYW5pZWwgVmV0dGVyIHdy b3RlOgo+ID4gPj4+PiBPbiBUaHUsIEFwciAxOCwgMjAxOSBhdCAxMTowMiBBTSBNYXhpbWUgUmlw YXJkIHdyb3RlOgo+ID4gPj4+Pj4gT24gVGh1LCBBcHIgMTgsIDIwMTkgYXQgMDk6NTI6MTBBTSAr MDIwMCwgRGFuaWVsIFZldHRlciB3cm90ZToKPiA+ID4+Pj4+PiBPbiBUaHUsIEFwciAxOCwgMjAx OSBhdCA4OjIyIEFNIE1heGltZSBSaXBhcmQgd3JvdGU6Cj4gPiA+Pj4+Pj4+IE9uIFdlZCwgQXBy IDE3LCAyMDE5IGF0IDA1OjQxOjIxUE0gKzAyMDAsIERhbmllbCBWZXR0ZXIgd3JvdGU6Cj4gPiA+ Pj4+Pj4+PiBPbiBXZWQsIEFwciAxNywgMjAxOSBhdCAwOTo1NDoyNkFNICswMjAwLCBNYXhpbWUg UmlwYXJkIHdyb3RlOgo+ID4gPj4+Pj4+Pj4+IEhpLAo+ID4gPj4+Pj4+Pj4+Cj4gPiA+Pj4+Pj4+ Pj4gRFJNIGNvbWVzIHdpdGggYW4gZXh0ZW5zaXZlIGZvcm1hdCBzdXBwb3J0IHRvIHJldHJpZXZl IHRoZSB2YXJpb3VzCj4gPiA+Pj4+Pj4+Pj4gcGFyYW1ldGVycyBhc3NvY2lhdGVkIHdpdGggYSBn aXZlbiBmb3JtYXQgKHN1Y2ggYXMgdGhlIHN1YnNhbXBsaW5nLCBvciB0aGUKPiA+ID4+Pj4+Pj4+ PiBiaXRzIHBlciBwaXhlbCksIGFzIHdlbGwgYXMgc29tZSBoZWxwZXJzIGFuZCB1dGlsaXRpZXMg dG8gZWFzZSB0aGUgZHJpdmVyCj4gPiA+Pj4+Pj4+Pj4gZGV2ZWxvcG1lbnQuCj4gPiA+Pj4+Pj4+ Pj4KPiA+ID4+Pj4+Pj4+PiB2NGwyLCBvbiB0aGUgb3RoZXIgc2lkZSwgZG9lc24ndCBwcm92aWRl IHN1Y2ggZmFjaWxpdGllcywgbGVhdmluZyBlYWNoCj4gPiA+Pj4+Pj4+Pj4gZHJpdmVyIHJlaW1w bGVtZW50IGEgc3Vic2V0IG9mIHRoZSBmb3JtYXRzIHBhcmFtZXRlcnMgZm9yIHRoZSBvbmUgc3Vw cG9ydGVkCj4gPiA+Pj4+Pj4+Pj4gYnkgdGhhdCBwYXJ0aWN1bGFyIGRyaXZlci4gVGhpcyBsZWFk cyB0byBhIGxvdCBvZiBkdXBsaWNhdGlvbiBhbmQKPiA+ID4+Pj4+Pj4+PiBib2lsZXJwbGF0ZSBj b2RlIGluIHRoZSB2NGwyIGRyaXZlcnMuCj4gPiA+Pj4+Pj4+Pj4KPiA+ID4+Pj4+Pj4+PiBUaGlz IHNlcmllcyB0cmllcyB0byBhZGRyZXNzIHRoaXMgYnkgbW92aW5nIHRoZSBEUk0gZm9ybWF0IEFQ SSBpbnRvIGxpYiBhbmQKPiA+ID4+Pj4+Pj4+PiB0dXJuaW5nIGl0IGludG8gYSBtb3JlIGdlbmVy aWMgQVBJLiBJbiBvcmRlciB0byBkbyB0aGlzLCB3ZSd2ZSBuZWVkZWQgdG8gZG8KPiA+ID4+Pj4+ Pj4+PiBzb21lIHByZWxpbWluYXJ5IGNoYW5nZXMgb24gdGhlIERSTSBkcml2ZXJzLCB0aGVuIG1v dmVkIHRoZSBBUEkgYW5kIGZpbmFsbHkKPiA+ID4+Pj4+Pj4+PiBjb252ZXJ0ZWQgYSB2NGwyIGRy aXZlciB0byBnaXZlIGFuIGV4YW1wbGUgb2YgaG93IHN1Y2ggbGlicmFyeSBjb3VsZCBiZQo+ID4g Pj4+Pj4+Pj4+IHVzZWQuCj4gPiA+Pj4+Pj4+Pj4KPiA+ID4+Pj4+Pj4+PiBMZXQgbWUga25vdyB3 aGF0IHlvdSB0aGluaywKPiA+ID4+Pj4+Pj4+PiBNYXhpbWUKPiA+ID4+Pj4+Pj4+Pgo+ID4gPj4+ Pj4+Pj4+IENoYW5nZXMgZnJvbSBSRkM6Cj4gPiA+Pj4+Pj4+Pj4gICAtIFJlYmFzZWQgb24gbmV4 dAo+ID4gPj4+Pj4+Pj4+ICAgLSBGaXhlZCB0aGUgdmFyaW91cyBmb3JtYXRzIG1hcHBpbmcKPiA+ ID4+Pj4+Pj4+PiAgIC0gQWRkZWQgdGFncwo+ID4gPj4+Pj4+Pj4+ICAgLSBEaWQgbW9zdCBvZiB0 aGUgZm9ybWF0cyBmdW5jdGlvbnMgYXMgaW5saW5lIGZ1bmN0aW9ucwo+ID4gPj4+Pj4+Pj4+ICAg LSBVc2VkIGEgY29uc2lzdGVudCBwcmVmaXggZm9yIGFsbCB0aGUgdXRpbGl0aWVzIGZ1bmN0aW9u cwo+ID4gPj4+Pj4+Pj4+ICAgLSBGaXhlZCB0aGUgY29tcGlsYXRpb24gYnJlYWthZ2VzLCBhbmQg ZGlkIGEgcnVuIG9mIGFsbG1vZGNvbmZpZyBmb3IgYXJtLAo+ID4gPj4+Pj4+Pj4+ICAgICBhcm02 NCBhbmQgeDg2XzY0Cj4gPiA+Pj4+Pj4+Pj4gICAtIEZpeGVkIG91dCBvZiBhcnJheSBib3VuZHMg d2FybmluZ3MgaW4gdGhlIGltYWdlX2Zvcm1hdF9pbmZvX2Jsb2NrXyoKPiA+ID4+Pj4+Pj4+PiAg ICAgZnVuY3Rpb25zCj4gPiA+Pj4+Pj4+Pj4gICAtIEFkZGVkIExpY2Vuc2UgYW5kIGNvcHlyaWdo dCBoZWFkZXJzIG9uIG1pc3NpbmcgZmlsZXMKPiA+ID4+Pj4+Pj4+Pgo+ID4gPj4+Pj4+Pj4+IE1h eGltZSBSaXBhcmQgKDIwKToKPiA+ID4+Pj4+Pj4+PiAgIGRybTogUmVtb3ZlIHVzZXJzIG9mIGRy bV9mb3JtYXRfbnVtX3BsYW5lcwo+ID4gPj4+Pj4+Pj4+ICAgZHJtOiBSZW1vdmUgdXNlcnMgb2Yg ZHJtX2Zvcm1hdF8oaG9yenx2ZXJ0KV9jaHJvbWFfc3Vic2FtcGxpbmcKPiA+ID4+Pj4+Pj4+PiAg IGRybS9mb3VyY2M6IFBhc3MgdGhlIGZvcm1hdF9pbmZvIHBvaW50ZXIgdG8gZHJtX2Zvcm1hdF9w bGFuZV9jcHAKPiA+ID4+Pj4+Pj4+PiAgIGRybS9mb3VyY2M6IFBhc3MgdGhlIGZvcm1hdF9pbmZv IHBvaW50ZXIgdG8gZHJtX2Zvcm1hdF9wbGFuZV93aWR0aC9oZWlnaHQKPiA+ID4+Pj4+Pj4+PiAg IGRybTogUmVwbGFjZSBpbnN0YW5jZXMgb2YgZHJtX2Zvcm1hdF9pbmZvIGJ5IGRybV9nZXRfZm9y bWF0X2luZm8KPiA+ID4+Pj4+Pj4+PiAgIGxpYjogQWRkIHZpZGVvIGZvcm1hdCBpbmZvcm1hdGlv biBsaWJyYXJ5Cj4gPiA+Pj4+Pj4+Pj4gICBkcm0vZmI6IE1vdmUgZnJvbSBkcm1fZm9ybWF0X2lu Zm8gdG8gaW1hZ2VfZm9ybWF0X2luZm8KPiA+ID4+Pj4+Pj4+PiAgIGRybS9tYWxpZHA6IENvbnZl cnQgdG8gZ2VuZXJpYyBpbWFnZSBmb3JtYXQgbGlicmFyeQo+ID4gPj4+Pj4+Pj4+ICAgZHJtL2Ns aWVudDogQ29udmVydCB0byBnZW5lcmljIGltYWdlIGZvcm1hdCBsaWJyYXJ5Cj4gPiA+Pj4+Pj4+ Pj4gICBkcm0vZXh5bm9zOiBDb252ZXJ0IHRvIGdlbmVyaWMgaW1hZ2UgZm9ybWF0IGxpYnJhcnkK PiA+ID4+Pj4+Pj4+PiAgIGRybS9pOTE1OiBDb252ZXJ0IHRvIGdlbmVyaWMgaW1hZ2UgZm9ybWF0 IGxpYnJhcnkKPiA+ID4+Pj4+Pj4+PiAgIGRybS9pcHV2MzogQ29udmVydCB0byBnZW5lcmljIGlt YWdlIGZvcm1hdCBsaWJyYXJ5Cj4gPiA+Pj4+Pj4+Pj4gICBkcm0vbXNtOiBDb252ZXJ0IHRvIGdl bmVyaWMgaW1hZ2UgZm9ybWF0IGxpYnJhcnkKPiA+ID4+Pj4+Pj4+PiAgIGRybS9vbWFwOiBDb252 ZXJ0IHRvIGdlbmVyaWMgaW1hZ2UgZm9ybWF0IGxpYnJhcnkKPiA+ID4+Pj4+Pj4+PiAgIGRybS9y b2NrY2hpcDogQ29udmVydCB0byBnZW5lcmljIGltYWdlIGZvcm1hdCBsaWJyYXJ5Cj4gPiA+Pj4+ Pj4+Pj4gICBkcm0vdGVncmE6IENvbnZlcnQgdG8gZ2VuZXJpYyBpbWFnZSBmb3JtYXQgbGlicmFy eQo+ID4gPj4+Pj4+Pj4+ICAgZHJtL2ZvdXJjYzogUmVtb3ZlIG9sZCBEUk0gZm9ybWF0IEFQSQo+ ID4gPj4+Pj4+Pj4+ICAgbGliOiBpbWFnZS1mb3JtYXRzOiBBZGQgdjRsMiBmb3JtYXRzIHN1cHBv cnQKPiA+ID4+Pj4+Pj4+PiAgIGxpYjogaW1hZ2UtZm9ybWF0czogQWRkIG1vcmUgZnVuY3Rpb25z Cj4gPiA+Pj4+Pj4+Pj4gICBtZWRpYTogc3VuNmk6IENvbnZlcnQgdG8gdGhlIGltYWdlIGZvcm1h dCBBUEkKPiA+ID4+Pj4+Pj4+Cj4gPiA+Pj4+Pj4+PiBJbiB0aGUgaW50ZXJlc3Qgb2YgbWFraW5n IG15c2VsZiB1bnBvcHVsYXI6IFdoeSBtb3ZlIHRoaXMgb3V0IG9mIGRybT8KPiA+ID4+Pj4+Pj4+ Cj4gPiA+Pj4+Pj4+PiBXZSBkbyBoYXZlIGEgYnVuY2ggb2Ygb3RoZXIgc3VjaCBzaGFyZWQgaGVs cGVycyBhbHJlYWR5IChtb3N0bHkgaW4KPiA+ID4+Pj4+Pj4+IGRyaXZlcnMvdmlkZW8pIGZvciBk dCB2aWRlb21vZGUgYW5kIGhkbWkgaW5mb2ZyYW1lcywgYW5kIEknbSBub3Qgc3VwZXIKPiA+ID4+ Pj4+Pj4+IHN1cmUgdGhhdCdzIGdvaW5nIGJldHRlciB0aGFuIGtlZXBpbmcgaXQgbWFpbnRhaW5l ZCBpbiBkcm0uCj4gPiA+Pj4KPiA+ID4+PiBUaGF0J3MgYSBiaXQgb2YgYSBkaWZmZXJlbnQgc2l0 dWF0aW9uIGFzIGJvdGggRFJNIGFuZCBGQkRFViBhZGRyZXNzIHRoZQo+ID4gPj4+IHNhbWUgZmVh dHVyZXMgKGRpc3BsYXkgb3V0cHV0KSwgYW5kIEZCREVWIGlzIGRlcHJlY2FyZWQgYW5kIHJlcGxh Y2VkIGJ5Cj4gPiA+Pj4gRFJNLgo+ID4gPj4+Cj4gPiA+Pj4gSSdtIG5vdCBhZ2FpbnN0IG1haW50 YWluaW5nIGEgNENDIGxpYnJhcnkgaW4gRFJNIChhZGRpbmcgYSB0aGlyZC1wYXJ0eQo+ID4gPj4+ IG1haW50YWluZXIgd291bGQgbGlrZWx5IGNyZWF0ZSBtb3JlIHByb2JsZW1zIHRoYW4gaXQgd291 bGQgc29sdmUpLCBidXQKPiA+ID4+PiB0aGF0IGRvZXNuJ3QgbWVhbiB0aGUgbGlicmFyeSBoYXMg dG8gbGl2ZSBpbiBkcml2ZXJzL2dwdS8sIG5vciB0aGF0IGl0Cj4gPiA+Pj4gbmVlZHMgdG8gaGF2 ZSB0aGUgZHJtXyBwcmVmaXguIEkgd291bGQgYWN0dWFsbHkgYWR2b2NhdGUgdG8gbWFrZSBpdCBs aXZlCj4gPiA+Pj4gaW4gYSBuZXV0cmFsIGRpcmVjdG9yeSwgd2l0aCBhIG5ldXRyYWwgcHJlZml4 IChrdWRvcyB0byBhbnlvbmUgd2hvIGNhbgo+ID4gPj4+IHByb3Bvc2UgYSBuaWNlIG5hbWluZyBj b252ZW50aW9uIHRoYXQgd291bGQgZXN0YWJsaXNoIGEgbmV3IHNoYXJlZAo+ID4gPj4+IGdyb3Vu ZCBmb3IgaW1hZ2UvdmlkZW8tcmVsYXRlZCBMaW51eCBBUElzKSwgYW5kIG1haW50YWluZWQgdGhy b3VnaCB0aGUKPiA+ID4+PiBEUk0gdHJlZSAocG9zc2libHkgd2l0aCBleHRyYSBlbnRyaWVzIGlu IE1BSU5UQUlORVJTIHRvIGVuc3VyZSBpdAo+ID4gPj4+IHJlYWNoZXMgYWxsIHRoZSByZWxhdGVk IGZvbGtzKS4KPiA+ID4+Pgo+ID4gPj4+Pj4+Pj4gUGx1cyB0aGUgdWFwaSBpcyBhbHJlYWR5IHRo YXQgeW91IGluY2x1ZGUgZHJtX2ZvdXJjYy5oIHRvIGdldCBhdCB0aGVzZSwKPiA+ID4+Pj4+Pj4+ IGRyb3BwaW5nIHRoZSBkcm0gcHJlZml4IGlzbid0IGdvaW5nIHRvIGhlbHAgSSB0aGluay4KPiA+ ID4+Pj4+Pj4+Cj4gPiA+Pj4+Pj4+PiBPZiBjb3Vyc2Ugd2UnZCBuZWVkIHRvIG1ha2UgaXQgYSBz ZXBhcmF0ZSBkcm1fZm9ybWF0cy5rbyAoc28gdGhhdCB2NGwgY2FuCj4gPiA+Pj4+Pj4+PiB1c2Ug aXQgd2l0aG91dCBkcmFnZ2luZyBpbiBhbGwgb2YgZHJtKSwgYW5kIHdlIG5lZWQgdG8gYWRkIHNv bWUgZmllbGRzIGZvcgo+ID4gPj4+Pj4+Pj4gY29udmVydGluZyB0byB2NGwgZm91cmNjIGNvZGVz ICh3aGljaCBhcmUgZGlmZmVyZW50KS4gQnV0IHRoYXQgc2hvdWxkIGJlCj4gPiA+Pj4+Pj4+PiBh bGwgcG9zc2libGUuIEFuZCBJIGRvbid0IHRoaW5rIHRoZSBkcm1fIHByZWZpeCBpbiB2NGwgY29k ZSBpcyBhIHByb2JsZW0sCj4gPiA+Pj4+Pj4+PiBpdCdzIGFjdHVhbGx5IGEgZmVhdHVyZTogSXQg bWFrZXMgaXQgcmVhbGx5IGNsZWFyIHRoYXQgdGhlc2UgYXJlIHRoZSBkcm0KPiA+ID4+Pj4+Pj4+ IGZvdXJjYyBjb2RlcywgYXMgYWxsb2NhdGVkIGluIGRybV9mb3VyY2MuaCwgcGx1cyB0aGVpciBt b2RpZmllcnMsIGFuZCBhbGwKPiA+ID4+Pj4+Pj4+IHRoYXQuIFRoYXQgYWxsb2NhdGlvbiBhdXRo b3JpdHkgaXMgYWxzbyBhbHJlYWR5IGJha2VkIGludG8gdmFyaW91cyBraHIvZXh0Cj4gPiA+Pj4+ Pj4+PiBzdGFuZGFyZHMsIHRvby4KPiA+ID4+Pgo+ID4gPj4+IFRoZXJlJ3Mgb25lIHRoaW5nIHRo YXQgVjRMMiBoYXMgYW5kIERSTSBoYXNuJ3QgZm9yIDRDQ3M6IGdvb2QKPiA+ID4+PiBkb2N1bWVu dGF0aW9uLiBMb29rIGF0Cj4gPiA+Pj4gaHR0cHM6Ly9saW51eHR2Lm9yZy9kb3dubG9hZHMvdjRs LWR2Yi1hcGlzLW5ldy91YXBpL3Y0bC9waXhmbXQtcGFja2VkLXJnYi5odG1sCj4gPiA+Pj4gb3IK PiA+ID4+PiBodHRwczovL2xpbnV4dHYub3JnL2Rvd25sb2Fkcy92NGwtZHZiLWFwaXMtbmV3L3Vh cGkvdjRsL3l1di1mb3JtYXRzLmh0bWwKPiA+ID4+PiBmb3IgaW5zdGFuY2UuIEl0J3MgcGFpbmZ1 bCB0byB3cml0ZSwgcGFpbmZ1bCB0byByZWFkLCBidXQgZGVmaW5lcyB0aGUKPiA+ID4+PiA0Q0Nz IHZlcnkgY2xlYXJseSB3aXRob3V0IGFtYmlndWl0eS4gSSB3b3VsZG4ndCBiZSBzdXJwcmlzZWQg aWYKPiA+ID4+PiBkaWZmZXJlbnQgZHJpdmVycyB1c2VkIHRoZSBzYW1lIERSTSA0Q0MgZm9yIGRp ZmZlcmVudCBmb3JtYXRzIGR1ZSB0byB0aGUKPiA+ID4+PiBsYWNrIG9mIGRldGFpbGVkIGRvY3Vt ZW50YXRpb24uIE1vdmluZyB0byBhIHNoYXJlZCBsaWJyYXJ5IGZvciA0Q0NzCj4gPiA+Pj4gc2hv dWxkIGFsc28gYWRkcmVzcyB0aGUgZG9jdW1lbnRhdGlvbiBzaWRlLCBhbmQgYW55IG5ldyBmb3Jt YXQgYWRkZWQgdG8KPiA+ID4+PiB0aGUga2VybmVsLCB3aGV0aGVyIGZyb20gdGhlIFY0TDIgc2lk ZSBvciB0aGUgRFJNIHNpZGUsIHdvdWxkIGJlCj4gPiA+Pj4gcmVxdWlyZWQgdG8gcHJvdmlkZSBk ZXRhaWxlZCBkb2N1bWVudGF0aW9uLiBUaGF0IHdvdWxkIGJlIGEgZ3JlYXQKPiA+ID4+PiBpbXBy b3ZlbWVudCBmb3IgRFJNIDRDQyBoYW5kbGluZy4KPiA+ID4+Pgo+ID4gPj4+Pj4+PiBUaGUgd2F5 IEkgc2VlIGl0LCB0aGVyZSdzIGEgZnVuZGFtZW50YWwgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBV QVBJCj4gPiA+Pj4+Pj4+IGFuZCB0aGUga2VybmVsLiBJIGRvbid0IHN1Z2dlc3Qgd2UgY2hhbmdl IGFueXRoaW5nIGFib3V0IHRoZSBVQVBJOiB0aGUKPiA+ID4+Pj4+Pj4gZHJtIGZvcm1hdHMgc2hv dWxkIGtlZXAgdGhlaXIgcHJlZml4LCBkcm1fZm91cmNjLmggY2FuIHJlbWFpbiB0aGF0Cj4gPiA+ Pj4+Pj4+IGF1dGhvcml0eSwgaXQncyBhbGwgZmluZS4KPiA+ID4+Pj4+Pj4KPiA+ID4+Pj4+Pj4g SW50ZXJuYWxseSBob3dldmVyLCB0aGUgbG9uZyB0ZXJtIGdvYWwgaXMgdG8gc2hhcmUgdGhlIGZv dXJjYydzCj4gPiA+Pj4+Pj4+IGJldHdlZW4gRFJNIGFuZCBWNEwyIGZvciB0aGUgc2FtZSBmb3Jt YXRzLiBJdCBiYXNpY2FsbHkgbWVhbnMgdGhhdCBvZgo+ID4gPj4+Pj4+PiBjb3Vyc2UgdjRsMiBz aG91bGQgYmUgdXNpbmcgdGhlIERSTSBmb3VyY2Mgd2hlbiBhIGZvcm1hdCBleGlzdHMgaW4gRFJN Cj4gPiA+Pj4+Pj4+IGFuZCBub3QgdjRsMiwgYnV0IGFsc28gdGhhdCBEUk0gc2hvdWxkIHVzZSB2 NGwyIGZvdXJjYyB3aGVuIHRoZSBmb3JtYXQKPiA+ID4+Pj4+Pj4gZXhpc3RzIGluIHY0bDIgYnV0 IG5vdCBEUk0sIGFuZCB0aGF0IGlzIGZhciBtb3JlIGxpa2VseSwgZ2l2ZW4gdGhlCj4gPiA+Pj4+ Pj4+IGFscmVhZHkgZXh0ZW5zaXZlIHY0bDIgZm9ybWF0cyBzdXBwb3J0Lgo+ID4gPj4+Pj4+Cj4g PiA+Pj4+Pj4gVWggbm8uIFdlIGRpZCBsb29rIGF0IHY0bCBmb3VyY2MgZXh0ZW5zaXZlbHkgd2hl biBkZWNpZGluZyB1cG9uIGEgZHJtCj4gPiA+Pj4+Pj4gZm9ybWF0IGlkZW50aWZpZXIgc3BhY2Uu Cj4gPiA+Pj4+Pgo+ID4gPj4+Pj4gTm8gdG8gd2hhdCBleGFjdGx5Pwo+ID4gPj4+Pj4KPiA+ID4+ Pj4+PiBBbmQgYSBsb3Qgb2YgcGVvcGxlIHB1c2hlZCBmb3IgdGhlICJmb3VyY2MgaXMgYSBzdGFu ZGFyZCIsIHdoZW4KPiA+ID4+Pj4+PiByZWFsbHkgaXQncyB0b3RhbGx5IG5vdC4KPiA+ID4+Pj4+ Cj4gPiA+Pj4+PiBFdmVuIGlmIGl0J3Mgbm90IGEgc3RhbmRhcmQsIGhhdmluZyBjb25zaXN0ZW5j eSB3b3VsZCBiZSBhIGdvb2QgdGhpbmcuCj4gPiA+Pj4+Pgo+ID4gPj4+Pj4gQW5kIHlvdSBzYWlk IHlvdXJzZWxmIHRoYXQgRFJNIGZvdXJjYyBpcyBub3cgcHJldHR5IG11Y2ggYW4gYXV0aG9yaXR5 Cj4gPiA+Pj4+PiBmb3IgdGhlIGZvdXJjYywgc28gaXQgZGVmaW5pdGVseSBsb29rcyBsaWtlIGEg c3RhbmRhcmQgdG8gbWUuCj4gPiA+Pj4+Cj4gPiA+Pj4+IGRybSBmb3VyY2MgaXMgdGhlIGF1dGhv cml0eSBmb3IgZHJtIGZvdXJjYyBjb2Rlcy4gTm90IGZvciBhbnkgb2YgdGhlCj4gPiA+Pj4+IG90 aGVycyAoYW5kIHRoZXJlJ3MgbG90cyBvZiB0aGVtKS4gTm93IGl0J3MgdXNlZCBpbiBhIGJ1bmNo IG9mIG90aGVyCj4gPiA+Pj4+IHBsYWNlcyAoa2hyIHN0YW5kYXJkcywgZHJpIHByb3RvY29scyBp biB3YXlsYW5kL1gxMSksIGJ1dCB0aGV5J3JlCj4gPiA+Pj4+IHN0aWxsIG9ubHkgZHJtIGZvdXJj Yy4gVGhlcmUgaXMgbm8gb3ZlcmFsbCBmb3VyY2Mgc3RhbmRhcmQuCj4gPiA+Pj4+Cj4gPiA+Pj4+ Pj4gdjRsIHRlbmRzIHRvIGNvbmZsYXRlIHBpeGVsIGZvcm1hdCB3aXRoIHN0dWZmIHRoYXQgd2Ug dGVuZCB0byBlbmNvZGUKPiA+ID4+Pj4+PiBpbiBtb2RpZmllcnMgYSBsb3QgbW9yZS4KPiA+ID4+ Pj4+Cj4gPiA+Pj4+PiBCb3JpcyBpcyB3b3JraW5nIG9uIGFkZGluZyB0aGUgbW9kaWZpZXJzIGNv bmNlcHQgdG8gdjRsMiwgc28gd2UncmUKPiA+ID4+Pj4+IGNvbnZlcmdpbmcgaGVyZSwgYW5kIHdl IGNhbiB0b3RhbGx5IGhhdmUgYSBsYXllciBpbiB2NGwyIHRvIGNvbnZlcnQKPiA+ID4+Pj4+IGJl dHdlZW4gb2xkIHY0bDIgImZvcm1hdCttb2RpZmllcnMiIGZvcm1hdHMsIGFuZCBEUk0gc3R5bGUg Zm9ybWF0cy4KPiA+ID4+Pj4+Cj4gPiA+Pj4+Pj4gVGhlcmUncyBhIGJ1bmNoIG9mIHJlYXNvbnMg d2UgY2FuJ3QganVzdCB1c2UgdjRsLCBhbmQgdGhleSdyZSBhcwo+ID4gPj4+Pj4+IHZhbGlkIGFz IGV2ZXI6Cj4gPiA+Pj4+Pj4KPiA+ID4+Pj4+PiAtIFdlIG92ZXJsYXAgYmFkbHkgaW4gc29tZSBh cmVhcywgc28gZXZlbiBpZiBmb3VyY2MgY29kZXMgbWF0Y2gsIHdlCj4gPiA+Pj4+Pj4gICBjYW4n dCB1c2UgdGhlbSBhbmQgbmVlZCBhIGR1cGxpY2F0ZWQgRFJNX0ZPVVJDQyBjb2RlLgo+ID4gPj4+ Pj4KPiA+ID4+Pj4+IERvIHlvIGhhdmUgYW4gZXhhbXBsZSBvZiBvbmUgb2YgdGhvc2UgYXJlYXM/ Cj4gPiA+Pj4+Cj4gPiA+Pj4+IEkgdGhpbmsgdGhlIHJnYiBzdHVmZiB3YXMgb25lIG9mIHRoZSBi aWcgcmVhc29ucyB0byBub3QgcmV1c2UgYW55Cj4gPiA+Pj4+IGV4aXN0aW5nIGZvdXJjYyBzdGFu ZGFyZCAod2hldGhlciB2NGwsIG9yIGFub3RoZXIgb25lIGZyb20gZS5nLiB2aWRlbwo+ID4gPj4+ PiBjb250YWluZXIgZm9ybWF0cykuIFdlIGhhZCBpbml0aWFsIHBhdGNoZXMgdG8gcmV1c2UgdGhl IGZvdXJjYyB0aGF0Cj4gPiA+Pj4+IGV4aXN0ZWQsIGJ1dCB0aGUgZW5kIHJlc3VsdCB3YXMgcmVh bGx5IGluY29uc2lzdGVudCwgc28gd2UgZGl0Y2ggdGhhdAo+ID4gPj4+PiBhbmQgcm9sbGVkIG91 dCBhIG5ldyBzZXQgb2YgZW50aXJlbHkgZHJtIHNwZWNpZmljIGZvdXJjYyBjb2RlcyBmb3IKPiA+ ID4+Pj4gcmdiYS4KPiA+ID4+Pgo+ID4gPj4+IENvdWxkIHlvdSBnaXZlIG9uZSBvciBhIGNvdXBs ZSBvZiBleGFtcGxlcyBvZiBWNEwyIDRDQ3MgdGhhdCBhcmUgbm90Cj4gPiA+Pj4gT0NELWNvbXBh dGlibGUgPyA6LSkKPiA+ID4+Pgo+ID4gPj4+Pj4+IC0gdjRsIGVuY29kZXMgc29tZSBtZXRhZGF0 YSBpbnRvIHRoZSBmb3VyY2MgdGhhdCB3ZSBlbmNvZGUgZWxzZXdoZXJlLAo+ID4gPj4+Pj4+ICAg ZS5nLiBvZmZzZXQgZm9yIHBsYW5hciB5dXYgZm9ybWF0cywgb3IgdGlsaW5nIG1vZGUKPiA+ID4+ Pj4+Cj4gPiA+Pj4+PiBBcyBJIHdhcyBzYXlpbmcsIHRoaXMgY2hhbmdlcyBvbiB0aGUgdjRsMiBz aWRlLCBhbmQgY29udmVyZ2luZyB0bwo+ID4gPj4+Pj4gd2hhdCBEUk0gaXMgZG9pbmcuCj4gPiA+ Pj4+Pgo+ID4gPj4+Pj4+IC0gZHJtIGZvdXJjYyBjb2RlIGRvZXNuJ3QgYWN0dWFsbHkgZGVmaW5l IHRoZSBkcm1fZm9ybWF0X2luZm8KPiA+ID4+Pj4+PiAgIHVuaXF1ZWx5LCBkcml2ZXJzIGNhbiBv dmVycmlkZSB0aGF0ICh0aGF0J3MgYW4gZXhwbGljaXQgZGVzaWduCj4gPiA+Pj4+Pj4gICBpbnRl bnQgb2YgbW9kaWZpZXJzLCB0byBhbGxvdyBkcml2ZXJzIHRvIGFkZCBhbm90aGVyIHBsYW5lIGZv cgo+ID4gPj4+Pj4+ICAgZS5nLiBjb21wcmVzc2lvbiBpbmZvcm1hdGlvbikuIFlvdSdkIG5lZWQg dG8gcHVsbCB0aGF0IGRyaXZlcgo+ID4gPj4+Pj4+ICAga25vd2xlZGdlIGludG8geW91ciBmb3Jt YXQgbGlicmFyeS4KPiA+ID4+Pgo+ID4gPj4+IFRoYXQncyBhIG1pc3Rha2UgaW4gbXkgb3Bpbmlv bi4gV2UgdHJpZWQgdGhhdCBpbiBWNEwyIHRvIHN0b3JlIG1ldGFkYXRhCj4gPiA+Pj4gaW4gYSBz ZXBhcmF0ZSBwbGFuZSwgYW5kIGhhZCB0byBnbyBhbm90aGVyIHJvdXRlIGV2ZW50dWFsbHkgYXMg aXQKPiA+ID4+PiBjcmVhdGVkIGEgdmVyeSBiYWQgbWVzcy4KPiA+ID4+Cj4gPiA+PiBKdXN0IHF1 aWNrIGNsYXJpZmljYXRpb24gaW4gdGhlIG1pZGRsZSBoZXJlOiBUaGlzIGlzIGhvdyB0aGUgaHcg d29ya3MuCj4gPiA+Cj4gPiA+IFRoZSBoYXJkd2FyZSB0YWtlcyBwYXJhbWV0ZXJzIGZyb20gYSBi dWZmZXIsIGJ1dCBpdCBkb2Vzbid0IG1hbmRhdGUgaG93Cj4gPiA+IHRoYXQgYnVmZmVyIGlzIGV4 cG9zZWQgdG8gdXNlcnNwYWNlIDotKSBVc2luZyBhbiBleHRyYSBwbGFuZSBpcyBvbmUKPiA+ID4g b3B0aW9uLCBidXQgb3RoZXIgQVBJcyBhcmUgcG9zc2libGUuCj4gPiAKPiA+IEkgdGhpbmsgRGFu aWVsIFN0b25lIGV4cGxhaW5zIGZhaXJseSB3ZWxsIHdoeSBzb21lIG9mIG91ciBhZGRpdGlvbmFs Cj4gPiBtZXRhZGF0YSBpcyBpbmNsdWRlZCBhcyBhIHBsYW5lLCB3aGlsZSBhIGxvdCBvZiB0aGUg b3RoZXIgbWV0YWRhdGEKPiA+IGludm9sdmVkIGluIHJlbmRlcmluZy9jb21wdXRlIHRoZSBmcmFt ZWJ1ZmZlciBpc24ndC4gTm90IHJlYWxseQo+ID4gYW55dGhpbmcgdG8gYWRkIGhlcmUuCj4gPiAK PiA+ID4+IEl0J3Mgbm90IG1ldGFkYXRhIHRoYXQgc3cgZXZlciB0b3VjaGVzIChpbiBnZW5lcmFs LCB0ZXN0Y2FzZXMgdG8gbWFrZSBzdXJlCj4gPiA+PiB3ZSBkaXNwbGF5IHRoZXNlIGNvcnJlY3Rs eSBleGNlcHRlZCkuCj4gPiA+Pgo+ID4gPj4gVGhlcmUgaGFzIGJlZW4gc29tZSB0YWxraW5nIHRv IGFkZCBtYXliZSBhIGJpdCBtb3JlIG1peGVkIG1ldGFkYXRhLCBmb3IKPiA+ID4+IGZhc3QtY2xl YXIgY29sb3JzICh3aGljaCBpc24ndCB1c2VkIGJ5IGFueSBkaXNwbGF5IGVuZ2luZSBhZmFpayB5 ZXQpLiBUaGF0Cj4gPiA+Cj4gPiA+IFdoYXQgYXJlIGZhc3QtY2xlYXIgY29sb3JzID8KPiA+IAo+ ID4gaHcgb2ZmZXJzIGVub3Jtb3VzIGFtb3VudHMgb2YgdHJpY2tzIHRvIG1ha2UgZ2xDbGVhciBP KDEpLCBvciBhdCBsZWFzdAo+ID4gY2xvc2UgZW5vdWdoLiBnbENsZWFyIGlzIHVzdWFsbHkgd2hh dCdzIGRvbmUgYXQgdGhlIHN0YXJ0IG9mIGV2ZXJ5Cj4gPiBmcmFtZSwgYW5kIGNsZWFycyB0aGUg ZW50aXJlIGZyYW1lYnVmZmVyIHRvIGEgdW5pZm9ybSBjb2xvci4gVGhpcyBpcwo+ID4gYWNoaWV2 ZWQgdXN1YWxseSB0aHJvdWdoIDMgcGllY2VzOgo+ID4gLSBhY3R1YWwgZnJhbWVidWZmZXIgcGxh bmUgd2l0aCB0aGUgcGl4ZWwgZGF0YQo+ID4gLSBhIDJuZCBwbGFuZSB0aGF0ICh1c3VhbGx5LCBi dXQgdGhlcmUncyBsb3RzIG9mIHRyaWNrcyBoZXJlKSBjb250YWlucwo+ID4gYSBiaXQgb2YgbWV0 YWRhdGEgcGVyIGNhY2hlbGluZS9ibG9jay93aGF0ZXZlciBpbiB0aGUgZnJhbWVidWZmZXIgdG8K PiA+IGluZGljYXRlIGhvdy9pZiB0aG9zZSBwaXhlbHMgYXJlIGNvbXByZXNzZWQsIG9yIHdoZXRo ZXIgdGhleSBhcmUgc3RpbGwKPiA+IHRoZSB1bmlmb3JtIGNvbG9yIHN1cHBsaWVkIHRocm91Z2gg Z2xDbGVhci4gRm9yIGFjdHVhbCBPKDEpIHRoaXMKPiA+IG1ldGFkYXRhIGlzIGhpZXJhcmNoaWNh bCwgc28gdGhhdCBhIGdsQ2xlYXIgcmVhbGx5IG9ubHkgc2V0cyB0aGUKPiA+IHRvcC1sZXZlbCBt ZXRhZGF0YSB0byAiYWxsIHN1Ym9yZGluYXRlIGJsb2NrcyBzdGlsbCBoYXZlIGFyZSB0aGUgY2xl YXIKPiA+IGNvbG9yIi4gaHcgdGVuZHMgdG8gaGF2ZSBzb21lIHByZXR0eSBzdHJvbmcgb3Bpbmlv bnMgb24gd2hlcmUgaXQncwo+ID4gZ29pbmcgdG8gbG9vayBmb3IgdGhhdCAybmQgcGxhbmUuCj4g PiAtIGN1cmlvdXNseSBvbiBtb3N0IGh3IHRoZSBhY3R1YWwgY2xlYXIgY29sb3IgaXMgc3VwcGxp ZWQgc2VwYXJhdGVseQo+ID4gKGFuZCBvdXIgcGxhbiBpcyB0byBqdXN0IHN0dWZmIGl0IGludG8g YSAzcmQgcGxhbmUpCj4gCj4gSnVzdCB0byBjbGFyaWZ5LCBpcyB0aGlzIG5lZWRlZCBmb3IgZGlz cGxheSBlbmdpbmVzID8gRG9lcyB0aGUgR1BVCj4gcmVuZGVyIHRvIGEgMyBwbGFuZXMgYnVmZmVy IHdpdGggZ2xDbGVhcigpLXJlbGF0ZWQgZGF0YSBpbiBwbGFuZXMgMiBhbmQKPiAzLCB3aXRoIHRo ZSBidWZmZXIgdGhlbiBiZWluZyBwYXNzZWQgdG8gdGhlIGRpc3BsYXkgZW5naW5lIHRoYXQga25v d3MKPiBob3cgdG8gaW50ZXJwcmV0IHRoaXMsIG9yIGFyZSB0aG9zZSBleHRyYSBwbGFuZXMgb25s eSBuZWVkZWQgZm9yIEdQVQo+IHJlbmRlcmluZyA/CgpJIGhhdmVuJ3QgeWV0IHNlZW4gYSBkaXNw bGF5IGVuZ2luZSB0aGF0IGNhbiBzY2FuIG91dCBmYXN0LWNsZWFyZWQgYnVmZmVycwpsaWtlIHRo ZXNlLiBFdmVyeW9uZSBjYW4gc2NhbiBvdXQgY29tcHJlc3NlZCBidWZmZXJzLCBpLmUuIHJnYiAr IDJuZAphdXhpYWxsaWFyeSBidWZmZXIgd2l0aCBzb21lIGNvbXByZXNzaW9uIG1ldGFkYXRhLiBC dXQgbm90IHlldCB3aXRoIHRoZQozcmQgcGxhbmUuCgpTbyBub3QgcmVsZXZhbnQgZm9yIGRpc3Bs YXkuIEJ1dCBpdCBpcyB2ZXJ5IG11Y2ggcmVsZXZhbnQgZm9yCnVhcGkvZHJtX2ZvdXJjYy5oLCBi ZWNhdXNlIHdlJ2xsIG5lZWQgaXQgZm9yIHVzZXJzcGFjZSBpbnRlcm9wIGJldHdlZW4KZGlmZmVy ZW50IGFwaXMgKHZrLCBnbCwgLi4uKSBhbmQgZGlmZmVyZW50IHByb2Nlc3NlcyAoY2xpZW50LCBj b21wb3NpdG9yKS4KQW5kIGluIHRoZXNlIHN0YW5kYXJkIGV4dGVuc2lvbiB0ZXh0cyB3ZSd2ZSBv ZmZpY2lhbGx5IG1hZGUgdGhlIGtlcm5lbCdzCmNvcHkgb2YgdGhhdCBmaWxlIHRoZSBvZmZpY2lh bCByZWdpc3RyeS4gU28gdGhlc2UgZm91cmNjK21vZGlmaWVyIGNvZGVzCndpbGwgZW5kIHVwIGF0 IGxlYXN0IGluIHRoYXQgbmFtZXNwYWNlIChidXQgbWF5YmUgbm90IGluIHRoZSBzYW1lCmxpYnJh cnkgdGhlIGtlcm5lbCB1c2VzIGludGVybmFsbHkpLgoKPiA+ID4+IHdvdWxkIGdlbmVyYWxseSBi ZSB3cml0dGVuIGJ5IHRoZSBjcHUgKGluIHRoZSBnbCBzdGFjayksIGJ1dCBhZ2FpbiByZWFkIGJ5 Cj4gPiA+PiB0aGUgaHcgKGxvYWRlZCBhcyBpbmRpcmVjdCBzdGF0ZSBwYWNrZXQgbW9zdCBsaWtl bHksIG9yIHNvbWV0aGluZyBsaWtlCj4gPiA+PiB0aGF0KS4gU28gYWdhaW4gaHcgc3BlY2lmaWMg bGF5b3V0LCBiZWNhdXNlIHRoZSBodyBuZWVkcyB0byByZWFkIGl0Lgo+ID4gPj4KPiA+ID4+IFB1 cmUgbWV0YWRhdGEgb25seSBvZiBpbnRlcmVzdCBmb3IgdGhlIGNwdS9zdyBzdGFjayBoYXMgYmVl biBzaG90IGRvd24KPiA+ID4+IGNvbXBsZXRlbHkgb24gdGhlIGRybSBzaWRlIHRvby4KPiA+ID4+ Cj4gPiA+Pj4gVGhlcmUncyBhIHRlbmRlbmN5IGluIGJvdGggc3Vic3lzdGVtcyB0byBsb29rIGF0 IHRoZSBvdGhlciBhcyBhIGJpdCBvZiBhCj4gPiA+Pj4gcmV0YXJkZWQgcmVsYXRpdmUsIGFuZCB0 aGF0J3MgYSBzaGFtZSwgd2UgaGF2ZSBsb3RzIHRvIGxlYXJuIGZyb20gZWFjaAo+ID4gPj4+IG90 aGVyJ3MgbWlzdGFrZXMuIFRoYXQgd291bGRuJ3QgYmUgdG9vIGRpZmZpY3VsdCBpZiBwZW9wbGUg c3RhcnRlZAo+ID4gPj4+IHRhbGtpbmcgdG8gZWFjaCBvdGhlci4KPiA+ID4+Pgo+ID4gPj4+IEEg c2VtaS1yZWxhdGVkIGNvbW1lbnQ6IERSTSBhbHNvIGNhcnJpZXMgb3RoZXIgbWlzdGFrZXMgb2Yg aXRzIG93biwgSSdtCj4gPiA+Pj4gdGhpbmtpbmcgYWJvdXQgRFJNX0ZPUk1BVF9CSUdfRU5ESUFO IGluIHBhcnRpY3VsYXIKPiA+ID4+Cj4gPiA+PiBZZWFoIHRoYXQgb25lIGlzIGhpbGFyaW9zLCBi dXQgaW4gcHJhY3RpY2UgYmlnIGVuZGlhbiBpcyBkZWFkLCBleGNlcHQgZm9yCj4gPiA+PiBhIHZl cnkgZmV3IHNlcnZlciBjaGlwcywgYW5kIHRoZXJlIEkgdGhpbmsgR2VyZCdzIHdvcmsgbW9zdGx5 IGZpeGVkIHVwCj4gPiA+PiB0aGF0IG1lc3MuCj4gPiA+Pgo+ID4gPj4+Pj4gSSdtIG5vdCBzdXJl IGhvdyBteSBwYXRjaGVzIGFyZSBjaGFuZ2luZyBhbnl0aGluZyBoZXJlLiBUaGlzIGlzCj4gPiA+ Pj4+PiBsaXR0ZXJhbGx5IHRoZSBzYW1lIGNvZGUsIHdpdGggdGhlIGZ1bmN0aW9ucyByZW5hbWVk Lgo+ID4gPj4+Pj4KPiA+ID4+Pj4+IElmIGRyaXZlcnMgd2FudCB0byBvdmVycmlkZSB0aGF0LCB0 aGVuIHllYWgsIGZpbmUsIHdlIGNhbiBsZXQgdGhlbSBkbwo+ID4gPj4+Pj4gdGhhdC4gSnVzdCBs aWtlIGFueSBoZWxwZXIgdGhpcyBqdXN0IHByb3ZpZGVzIGEgZGVmYXVsdCB0aGF0IGNvdmVycwo+ ID4gPj4+Pj4gbW9zdCBvZiB0aGUgY2FzZXMuCj4gPiA+Pj4+Pgo+ID4gPj4+Pj4+IElvdyB0aGVy ZSdzIG5vIHdheSB3ZSBjYW4gZWFzaWx5IGFkb3B0IHY0bCBmb3VyY2MsIGV4Y2VwdCBpZiB3ZSBk bwo+ID4gPj4+Pj4+IHNvbWV0aGluZyBsaWtlIGEgbmV3IGFkZGZiIGZsYWcuCj4gPiA+Pj4+Pgo+ ID4gPj4+Pj4gRm9yIHRoZSBmb3JtYXRzIHRoYXQgd291bGQgYmUgZGVzY3JpYmVkIGFzIGEgbW9k aWZpZXIsIHN1cmUuIEZvciBhbGwKPiA+ID4+Pj4+IHRoZSBvdGhlcnMgKHRoYXQgYXJlIG5vdCB5 ZXQgc3VwcG9ydGVkIGJ5IERSTSksIHRoZW4gSSBkb24ndCByZWFsbHkKPiA+ID4+Pj4+IHNlZSB3 aHkgbm90Lgo+ID4gPj4+Pgo+ID4gPj4+PiBTZWUgYWJvdmUsIHdlIHRyaWVkIHRoYXQgaW5pdGlh bGx5LCBkaWRuJ3QgcGFzcyB0aGUgb2NkIHRlc3RzIHdoZW4KPiA+ID4+Pj4gcmV2aWV3aW5nLiBN YXliZSB0aGUgc2l0dWF0aW9uIGlzIGJldHRlciBvdXRzaWRlIG9mIHJiZ3gvYSBmb3JtYXRzLAo+ ID4gPj4+PiBhbmQgSSB0aGluayB3ZSBkbyBhdCBsZWFzdCB0cnkgdG8gdXNlIHRoZSBzYW1lIGZv dXJjYyBjb2RlcyB0aGVyZSB3aGVuCj4gPiA+Pj4+IHRoZXJlIGFscmVhZHkgaXMgb25lLiBCdXQg dGhlbiB0aGUgZGV0YWlscyBvY2Nhc2lvbmFsbHkgbG9vawo+ID4gPj4+PiBkaWZmZXJlbnQuCj4g PiA+Pj4+Cj4gPiA+Pj4+Pj4+IEFuZCBnaXZlbiBob3cgdGhlIGN1cnJlbnQgc3RhdGUgaXMgYSBt ZXNzIGluIHRoaXMgcmVnYXJkLCBJJ20gbm90IHRvbwo+ID4gPj4+Pj4+PiBvcHRpbWlzdGljIGFi b3V0IGtlZXBpbmcgdGhlIGZvcm1hdHMgaW4gdGhlaXIgcmVsZXZhbnQgZnJhbWV3b3Jrcy4KPiA+ ID4+Pj4+Pj4KPiA+ID4+Pj4+Pj4gSGF2aW5nIGEgc2hhcmVkIGxpYnJhcnksIGdvdmVybmVkIGJ5 IGJvdGgsIHdpbGwgbWFrZSB0aGlzIGZhciBlYXNpZXIsCj4gPiA+Pj4+Pj4+IHNpbmNlIGl0IHdp bGwgYmUgZWFzeSB0byBkaXNjb3ZlciB0aGUgZm9ybWF0cyB0aGF0IGFyZSBhbHJlYWR5Cj4gPiA+ Pj4+Pj4+IHN1cHBvcnRlZCBieSB0aGUgb3RoZXIgc3Vic3lzdGVtLgo+ID4gPj4+Pj4+Cj4gPiA+ Pj4+Pj4gSSB0aGluayBhIGNvbXBhdCBsaWJyYXJ5IHRoYXQgKHRyaWVzIHRvLCBiZXN0IGVmZm9y dCkgY29udmVydCBiZXR3ZWVuCj4gPiA+Pj4+Pj4gdjRsIGFuZCBkcm0gZm91cmNjIHdvdWxkIG1h a2Ugc2Vuc2UuIFNvbWV3aGVyZSBpbiBkcml2ZXJzL3ZpZGVvLCBuZXh0Cj4gPiA+Pj4+Pj4gdG8g dGhlIGNvbnZlcnNpb24gZnVuY3Rpb25zIGZvciB2aWRlb21vZGUgPC0+IGRybV9kaXNwbGF5X21v ZGUKPiA+ID4+Pj4+PiBwZXJoYXBzLiBUaGF0IHNob3VsZCBiZSB1c2VmdWwgZm9yIGRyaXZlcnMu Cj4gPiA+Pj4+Pgo+ID4gPj4+Pj4gVGhhdCdzIG5vdCByZWFsbHkgd2hhdCB0aGlzIHNlcmllcyBp cyBhYm91dCB0aG91Z2guIFRoYXQgc2VyaWVzIGlzCj4gPiA+Pj4+PiBhYm91dCBzaGFyaW5nIHRo ZSAoaW1hZ2V8cGl4ZWxzKSBmb3JtYXRzIGRhdGFiYXNlIGFjcm9zcyBldmVyeW9uZSBzbwo+ID4g Pj4+Pj4gdGhhdCBldmVyeW9uZSBjYW4gYmVuZWZpdCBmcm9tIGl0Lgo+ID4gPj4+Pgo+ID4gPj4+ PiBZZWFoIEkga25vdy4gSSBzdGlsbCB0aGluayBsZWF2aW5nIHRoZSBkcm0gZm91cmNjIHdpdGgg dGhlIGRybSBwcmVmaXgKPiA+ID4+Pj4gd291bGQgYmUgZ29vZCwgc2luY2UgdGhlcmUncyByZWFs bHkgbm8gc3RhbmRhcmQgaGVyZS4KPiA+ID4+Pj4KPiA+ID4+Pj4+PiBVbmlmeWluZyB0aGUgZm9y bWF0cyB0aGVtc2VsdmVzLCBhbmQgYWxsIHRoZSBhc3NvY2lhdGVkIG1ldGFkYXRhIGlzCj4gPiA+ Pj4+Pj4gaW1vIGEgbm8tZ28sIGFuZCB3YXMgYSBwcmV0dHkgY29uc2Npb3VzIGRlY2lzaW9uIHdo ZW4gd2UgaW1wbGVtZW50ZWQKPiA+ID4+Pj4+PiBkcm1fZm91cmNjIGEgZmV3IHllYXJzIGJhY2su Cj4gPiA+Pj4+Pj4KPiA+ID4+Pj4+Pj4gSWYgd2Ugd2FudCB0byBrZWVwIHRoZSBjdXJyZW50IGxp YnJhcnkgaW4gRFJNLCB3ZSBoYXZlIHR3byBvcHRpb25zCj4gPiA+Pj4+Pj4+IHRoZW46Cj4gPiA+ Pj4+Pj4+Cj4gPiA+Pj4+Pj4+ICAgLSBTdXBwb3J0IGFsbCB0aGUgdjRsMiBmb3JtYXRzIGluIHRo ZSBEUk0gbGlicmFyeSwgd2hpY2ggaXMKPiA+ID4+Pj4+Pj4gICAgIGVzc2VudGlhbGx5IHdoYXQg SSdtIGRvaW5nIGluIHRoZSBsYXN0IHBhdGNoZXMuIEhvd2V2ZXIsIHRoYXQKPiA+ID4+Pj4+Pj4g ICAgIHdvdWxkIHJlcXVpcmUgdG8gaGF2ZSB0aGUgdjRsMiBkZXZlbG9wcGVycyBhbHNvIHJldmll d2luZyBzdHVmZgo+ID4gPj4+Pj4+PiAgICAgdGhlcmUuIEFuZCBnaXZlbiBob3cgYnVzeSB0aGV5 IGFyZSwgSSBjYW5ub3QgcmVhbGx5IHNlZSBob3cgdGhhdAo+ID4gPj4+Pj4+PiAgICAgd291bGQg d29yay4KPiA+ID4+Pj4+Pgo+ID4gPj4+Pj4+IFdlbGwsIGlmIHdlIGVuZCB1cCB3aXRoIGEgY29t bW9uIGxpYnJhcnkgdGhlbiB5ZXMgd2UgbmVlZCBjcm9zcwo+ID4gPj4+Pj4+IHJldmlldy4gVGhl cmUncyBubyB3YXkgYXJvdW5kIHRoYXQuIERvZXNuJ3QgbWF0dGVyIHdoZXJlIGV4YWN0bHkgdGhh dAo+ID4gPj4+Pj4+IGxpYnJhcnkgaXMgaW4gdGhlIGZpbGVzeXN0ZW0gdHJlZSwgYW5kIGFkZGlu ZyBhIHNwZWNpYWwgTUFJTlRBSU5FUlMKPiA+ID4+Pj4+PiBlbnRyeSBmb3IgYW55dGhpbmcgcmVs YXRlZCB0byBmb3VyY2MgKGJvdGggZHJtIGFuZCB2NGwpIHRvIG1ha2Ugc3VyZQo+ID4gPj4+Pj4+ IHRoZXkgZ2V0IGNyb3NzLXBvc3RlZCBpcyBlYXN5LiBObyBmaWxlIHJlbmFtaW5nIG5lZWRlZC4K PiA+ID4+Pj4+Cj4gPiA+Pj4+PiBUaGF0IHdvdWxkIGNyZWF0ZSBzb21lIGdvdmVybmluZyBpc3N1 ZXMgYXMgd2VsbC4gRm9yIGV4YW1wbGUsIGlmIHlvdQo+ID4gPj4+Pj4gZXZlciBoYXZlIGEgcGF0 Y2ggZnJvbSBvbmUgZm91cmNjIGFkZGl0aW9uICh0aGF0IG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZQo+ ID4gPj4+Pj4gY292ZXJlZCBieSB2NGwyKSwgd2lsbCB5b3Ugd2FpdCBmb3IgYW55IHY0bDIgZGV2 ZWxvcHBlciB0byByZXZpZXcgaXQ/Cj4gPiA+Pj4+Cj4gPiA+Pj4+IE5vbmUgb2YgdGhpcyBpcyBm aXhlZCBieSBjb2RlIHJlbmFtaW5nIG9yIGxvY2F0aW9ucy4gRWl0aGVyIHdheSB3ZQo+ID4gPj4+ PiBuZWVkIHRvIGZpZ3VyZSB0aGF0IG91dC4KPiA+ID4+Pj4KPiA+ID4+Pj4gQW5kIHllcyBwYXJ0 IG9mIHRoZSByZWFzb25zIGZvciBub3QgbW92aW5nIHRoaXMgb3V0IG9mIGRybSBpcyB0aGF0IEkn bQo+ID4gPj4+PiBub3QgYSBmYW4gb2YgYm91dGlxdWUgdHJlZXMgZm9yIHNtYWxsIHN0dWZmLiBJ ZiBzaGFyaW5nIG1lYW5zIHdlIG5lZWQKPiA+ID4+Pj4gdG8gc3BsaXQgdGhlIGRybV9mb3VyY2Mg Y29kZSBhbmQgbGlicmFyeSBvdXQgb2YgZHJtIHRyZWVzLCBJJ20gbm90Cj4gPiA+Pj4+IHN1cmUg dGhhdCdzIGEgZ29vZCBpZGVhLiBXZSdyZSBhbHJlYWR5IHN1cGVyIGxpYmVyYWwgd2l0aCBtZXJn aW5nCj4gPiA+Pj4+IGFueXRoaW5nIHRocm91Z2ggZHJpdmVyIHRyZWVzIHdpdGggYWNrcywgYW5k IGludGVncmF0aW5nIHRoZW0gcXVpY2tseQo+ID4gPj4+PiBpbnRvIGRybS1uZXh0LiBUaGlzIHdv dWxkIHN0aWxsIGJlIHdvcmthYmxlIGlmIHY0bCBzZW5kcyByZWd1bGFyIHB1bGwKPiA+ID4+Pj4g cmVxdWVzdHMgdG8gZHJtLW5leHQgKGV2ZXJ5IDEtMiB3ZWVrcywgbGlrZSB0aGUgb3RoZXIgYmln IGdwdSB0cmVlcwo+ID4gPj4+PiBkbykuIElmIHdlIGNhbiBvbmx5IHN5bmMgdXAgb25jZSBwZXIg bWVyZ2Ugd2luZG93IHdpdGggYSBzaGFyZWQKPiA+ID4+Pj4gYm91dGlxdWUgdHJlZSBmb3IgZm9y bWF0cyBvbmx5LCBsaWZlIGlzIGdvaW5nIHRvIGJlIHBhaW5mdWwuCj4gPiA+Pj4KPiA+ID4+PiBU aGF0IHNob3VsZCBiZSBzb2x2ZWQgYnkgdGhlIHByb3Bvc2FsIGFib3ZlLCBtYWludGFpbmluZyB0 aGUgc2hhcmVkCj4gPiA+Pj4gbGlicmFyeSBpbiB0aGUgRFJNIHRyZWUuIFdlIHdvdWxkIG5lZWQg dG8gYmUgY2FyZWZ1bCB0aGVyZSwgYW5kIGlkZWFsbHkKPiA+ID4+PiBtYWludGFpbiB0aGF0IGlu IGEgc2VwYXJhdGUgYnJhbmNoIHRoYXQgY291bGQgYmUgbWVyZ2VkIGluIGJvdGggRFJNIGFuZAo+ ID4gPj4+IFY0TDIgd2l0aG91dCBoYXZpbmcgdG8gbWVyZ2UgbW9zdCBvZiB0aGUgb3RoZXIgc3Vi c3lzdGVtJ3MgcGVuZGluZwo+ID4gPj4+IGNoYW5nZXMgYXQgdGhlIHNhbWUgdGltZSwgYnV0IEkg dGhpbmsgaXQncyBkb2FibGUgd2l0aG91dCBhbnkgYmlnIGlzc3VlLgo+ID4gPj4+Cj4gPiA+Pj4+ PiBJZiBpdCdzIHNoYXJlZCBjb2RlLCB0aGVuIGl0IHNob3VsZCBiZSBzaGFyZWQsIGFuZCBldmVy eSBjbGllbnQKPiA+ID4+Pj4+IGZyYW1ld29yayBwdXQgb24gYW4gZXF1YWwgZm9vdGluZy4KPiA+ ID4+Pj4+Cj4gPiA+Pj4+Pj4+ICAgLSBEZXZlbG9wIHRoZSBzYW1lIGxpYnJhcnkgZnJvbSB3aXRo aW4gdjRsMi4gVGhhdCBpcyByZWFsbHkgYSBwb29yCj4gPiA+Pj4+Pj4+ICAgICBzb2x1dGlvbiwg c2luY2UgdGhlIGluZm9ybWF0aW9uIHdvdWxkIGJlIGdyZWF0bHkgZHVwbGljYXRlZAo+ID4gPj4+ Pj4+PiAgICAgYmV0d2VlbiB0aGUgdHdvLCBhbmQgaW4gdGVybXMgb2YgbWFpbnRhaW5hbmNlLCBj b2RlLCBhbmQgYmluYXJ5Cj4gPiA+Pj4+Pj4+ICAgICBzaXplIHRoYXQgd291bGQgYmUgZHVwbGlj YXRlZCB0b28uCj4gPiA+Pj4+Pj4KPiA+ID4+Pj4+PiBJdCdzIGVzc2VudGlhbGx5IHdoYXQgd2Ug ZGVjaWRlZCB0byBkbyBmb3IgZHJtIHllYXJzIGJhY2suCj4gPiA+Pj4+Pgo+ID4gPj4+Pj4gQW5k IGl0IHdhcyBwcm9iYWJseSB0aGUgcmlnaHQgc29sdXRpb24gYmFjayB0aGVuLCBidXQgSSdtIHJl YWxseSBub3QKPiA+ID4+Pj4+IGNvbnZpbmNlZCBpdCdzIHN0aWxsIHRoZSByaWdodCB0aGluZyB0 byBkbyB0b2RheS4KPiA+ID4+Pj4+Cj4gPiA+Pj4+Pj4+IEhhdmluZyBpdCBzaGFyZWQgYWxsb3dz IHRvIGVhc2lseSBzaGFyZSwgYW5kIGRpc2NvdmVyIGZvcm1hdHMgZnJvbSB0aGUKPiA+ID4+Pj4+ Pj4gb3RoZXIgc3Vic3lzdGVtLCBhbmQgdG8gaGF2ZSBhIHNpbmdsZSwgdW5pcXVlIHBsYWNlIHdo ZXJlIHRoaXMgaXMKPiA+ID4+Pj4+Pj4gY2VudHJhbGl6ZWQuCj4gPiA+Pj4+Pj4KPiA+ID4+Pj4+ PiBXaGF0IEkgdGhpbmsgY291bGQgd29yayBhcyBtaWRkbGUgZ3JvdW5kOgo+ID4gPj4+Pj4+IC0g UHV0IGRybV9mb3JtYXQgc3R1ZmYgaW50byBhIHNlcGFyYXRlIC5rbwo+ID4gPj4+Pj4+IC0gQWRk IGEgTUFJTlRBSU5FUlMgZW50cnkgdG8gbWFrZSBzdXJlIGFsbCB0aGluZ3MgZm91cmNjIGFyZSBj cm9zcwo+ID4gPj4+Pj4+IHBvc3RlZCB0byBib3RoIGRybSBhbmQgdjRsIGxpc3RzLiBFYXN5IG9u IHRoZSBkcm0gc2lkZSwgc2luY2UgaXQncyBhbGwKPiA+ID4+Pj4+PiBzZXBhcmF0ZSBmaWxlcy4g Tm90IHN1cmUgaXQncyBzbyBjb252ZW5pZW50IGZvciB2NGwgdWFwaS4KPiA+ID4+Pj4+PiAtIEFk ZCBhIGNvbnZlcnNpb24gbGlicmFyeSB0aGF0IHRyaWVzIHRvIGJlc3QtZWZmb3J0IG1hcCBiZXR3 ZWVuIGRybQo+ID4gPj4+Pj4+IGFuZCB2NGwgZm9ybWF0cy4gT24gdGhlIGRybSBzaWRlIHRoYXQg bW9zdCBsaWtlbHkgbWVhbnMgeW91IG5lZWQKPiA+ID4+Pj4+PiBvZmZzZXRzIGZvciBwbGFuZXMs IGFuZCBtb2RpZmllcnMgdG9vIChzaW5jZSB0aG9zZSBhcmUgaW1wbGllZCBpbiBzb21lCj4gPiA+ Pj4+Pj4gdjRsIGZvdXJjYykuIEVtcGhhc2lzIG9uICJiZXN0IGVmZm9ydCIgaS5lLiBvbmx5IHN1 cHBvcnQgYXMgbXVjaCBhcwo+ID4gPj4+Pj4+IHRoZSBkcml2ZXJzIHRoYXQgdXNlIHRoaXMgbGli cmFyeSBuZWVkLgo+ID4gPj4+Pj4+IC0gQWRkIGRybV9mb3VyY2MgYXMtbmVlZGVkIGJ5IHRoZXNl IGRyaXZlcnMgdGhhdCB3YW50IHRvIHVzZSBhIHVuaWZpZWQKPiA+ID4+Pj4+PiBmb3JtYXQgc3Bh Y2UuCj4gPiA+Pj4+Pj4KPiA+ID4+Pj4+PiBGb3JjaW5nIHRoaXMgdW5pZmljYXRpb24gb24gZXZl cnlvbmUgb3RvaCBpcyBpbW8gd2F5IHRvbyBtdWNoLgo+ID4gPj4+Pj4KPiA+ID4+Pj4+IHY0bDIg aXMgc3RhcnRpbmcgdG8gY29udmVyZ2Ugd2l0aCBEUk0sIGFuZCB3ZSdyZSB1c2luZyB0aGUgRFJN IEFQSQo+ID4gPj4+Pj4gcHJldHR5IG11Y2ggdW50b3VjaGVkIGZvciB0aGF0IGxpYnJhcnksIHNv IEknbSBub3QgcmVhbGx5IHN1cmUgaG93Cj4gPiA+Pj4+PiBhbnlvbmUgaXMgaHVydCBieSB0aGF0 IHVuaWZpY2F0aW9uLgo+ID4gPj4+Pgo+ID4gPj4+PiBJdCBtaWdodCBtYWtlIHNlbnNlIHRvIHJl Z3VsYXJseSBwdWxsIHY0bCB1cGRhdGVzIGludG8gZHJtLW5leHQgdGhlbgo+ID4gPj4+PiBhbnl3 YXkuIFRoYXQgd291bGQgYWxzbyByZW1vdmUgdGhlIG5lZWQgdG8gaGF2ZSB0aGUgZm9ybWF0IGxp YnJhcnkKPiA+ID4+Pj4gc29tZXdoZXJlIGVsc2UuCj4gPiA+Pj4KPiA+ID4+PiBBcmUgeW91IHNh eWluZyBpdCBzaG91bGQgdGhlIGxpdmUgaW4gVjRMMiA/IDstKQo+ID4gPj4KPiA+ID4+IE1heWJl IGEgZmV3IGNsYXJpZmljYXRpb25zIG9uIGhvdyB0aGUgZHJtIHNoYXJlZCBjb3JlIHRoaW5nIHVz dWFsbHkgd29ya3MsCj4gPiA+PiBhbmQgd2h5IEknbSBhIHN0aWNrZXIgaGVyZS4gQm90dG9tIHJl cGx5IHNpbmNlIEknbSBub3Qgc3VyZSB3aGVyZSB0byBwdXQKPiA+ID4+IGl0Ogo+ID4gPj4KPiA+ ID4+IC0gUmVmYWN0b3JpbmdzIHVzdWFsbHkgZ28gaW4gdGhyb3VnaCBkcm0tbWlzYyAoYXQgbGVh c3Qgc2luY2UgYSBmZXcKPiA+ID4+ICAgeWVhcnMpLgo+ID4gPj4KPiA+ID4+IC0gU21hbGwgcGF0 Y2hlcyBnbyBpbiB0aHJvdWdoIHRoZSByZWxldmFudCBkcml2ZXIgdHJlZSAod2hpY2ggaXMgb2Z0 ZW4KPiA+ID4+ICAgZHJtLW1pc2MsIGJ1dCBub3QgYWx3YXlzKSwgd2l0aCBhbiBBY2sgZnJvbSBk cm0gbWFpbnRhaW5lcnMuCj4gPiA+Pgo+ID4gPj4gLSBObyB0b3BpYyBicmFuY2hlcywgZXZlcnlv bmUganVzdCBwdXNoZXMgcGF0Y2hlcyB3aGVyZSBpdCdzIG1vc3QKPiA+ID4+ICAgY29udmVuaWVu dC4KPiA+ID4+Cj4gPiA+PiBXZSBnZXQgYXdheSB3aXRoIHRoaXMgbWVzcyBiZWNhdXNlIGV2ZXJ5 b25lIHNlbmRzIHJlZ3VsYXIgcHVsbCByZXF1ZXN0cyB0bwo+ID4gPj4gZHJtLCB3aGVyZSB0aGUg ZW50aXJlIGhpc3RvcnkgaXMgYmFrZWQgaW4gYW5kIG90aGVycyBjYW4gYmFja21lcmdlL2Zhc3QK PiA+ID4+IGZvcndhcmQvcmViYXNlLiBXb3JzdCBjYXNlIHlvdSB3YWl0IG9uZSBtb250aCAoYXJv dW5kIHRoZSBtZXJnZSB3aW5kb3csCj4gPiA+PiB3aGVuIGRybS1uZXh0IGlzIGNsb3NlZCBmb3Ig ZmVhdHVyZXMpLCBidXQgdXN1YWxseSBpdCdzIGp1c3QgMS0yIHdlZWtzLgo+ID4gPj4gUGx1cyB3 ZSB0ZW5kIHRvIGhhdmUgZmFpcmx5IGJpZyB0cmVlcywgd2l0aCBnb29kIGNoYW5jZXMgdGhhdCB0 aGUgbmV4dAo+ID4gPj4gcGF0Y2ggc2VyaWVzIGxhbmRzIGluIHRoZSBzYW1lIHRyZWUgYWdhaW4g YW5kIG5vIHdvcmsgYXQgYWxsIGlzIG5lZWRlZC4KPiA+ID4+Cj4gPiA+PiBJZiB3ZSBzdGFydCBy ZWd1bGFybHkgc2hhcmluZyBsb3RzIG9mIGNvZGUgd2l0aCB2NGwgKHdoaWNoIHNlZW1zIHRvIGJl IHRoZQo+ID4gPj4gbG9uZyB0ZXJtIGdvYWwgaGVyZSksIHRoZW4gSSB0aGluayB3ZSBuZWVkIHNv bWV0aGluZyBlcXVhbGx5IGNvbnZlbmllbnQKPiA+ID4+IGZvciBhbGwgdGhhdC4KPiA+ID4+Cj4g PiA+PiBXZSdyZSBub3QgZ29pbmcgdG8gYmUgYWJsZSB0byB0ZWFjaCBzb21lIGNvbXBsaWNhdGVk IHRvcGljIGJyYW5jaCBzY2hlbWUKPiA+ID4+IHRvIHRoZSA1MCsgc3VibWFpbnRhaW5lcnMvY29t bWl0dGVycyB3ZSBoYXZlIGluIGRybSAtIGEgbG90IG11Y2ggbW9yZQo+ID4gPj4gYmFzaWMgc3R1 ZmYgYWxyZWFkeSB0YWtlcyBsb3RzIG9mIHdvcmsgdG8gZ2V0IGl0IHRvIHN0aWNrLiBJZiB0aGUg cHJvcG9zYWwKPiA+ID4+IGlzICJ0byBiZSBjYXJlZnVsIiBhbmQgIm1haW50YWluIGl0IGluIGEg c2VwYXJhdGUgYnJhbmNoIiwgSSdtIG5vdCBpbgo+ID4gPj4gZmF2b3VyIGJlY2F1c2UgSSB0aGlu ayB0aGF0IGp1c3Qgd291bGRuJ3Qgd29yay4KPiA+ID4KPiA+ID4gV2h5IG5vdCA/IEl0IGNhbiBi ZSBhIGZhc3QtbW92aW5nIGJyYW5jaCB0aGF0IGdldHMgbWVyZ2VkIGluIGRybS1taXNjCj4gPiA+ IGFzIG9mdGVuIGFzIHlvdSB3YW50IChldmVuIGF0IGV2ZXJ5IGNvbW1pdCBpZiB0aGF0J3MgZGVz aXJlZCkuIFdlJ3JlCj4gPiA+IGRlYWxpbmcgd2l0aCBhIGxpbWl0ZWQgYW1vdW50IG9mIGNvZGUg aGVyZSwgYW5kIHRoZXJlJ3Mgbm8gbW9yZSByZWFzb24KPiA+ID4gdGhhdCBWNEwyIHNob3VsZCBw dWxsIGluIGRybS1taXNjIHRvIGdldCA0Q0MgdXBkYXRlcyB0aGFuIERSTSBzaG91bGQKPiA+ID4g cHVsbCBWNEwyIGZvciB0aGUgc2FtZS4gSSBoYXZlIG5vIG9iamVjdGlvbiBhZ2FpbnN0IGEgNEND IGJyYW5jaCBiZWluZwo+ID4gPiBvZmZpY2lhbGx5IG1haW50YWluZWQgdW5kZXIgdGhlIERSTSB1 bWJyZWxsYSwgYnV0IEkgdGhpbmsgdGhlIGNvZGUKPiA+ID4gc2hvdWxkIGxpdmUgZWxzZXdoZXJl IHRoYW4gZHJpdmVycy9ncHUvZHJtLywgaGF2ZSBhIG5ldXRyYWwgcHJlZml4LCBhbmQKPiA+ID4g bm90IHJlcXVpcmUgcHVsbGluZyBhbiBlbnRpcmUgc3Vic3lzdGVtIGluLgo+ID4gCj4gPiBJIHRo aW5rIHNtYWxsIGJvdXRpcXVlIHRyZWVzIGFyZSBhIHByb2JsZW0gdGhlbXNlbHZlcywgbm90IGEg c29sdXRpb24uCj4gPiBTbyBpZiB5b3UncmUgY3JlYXRpbmcgYSBuZXcgc21hbGwgYm91dGlxdWUg dHJlZSB0byBmaXggYSBwcm9ibGVtLCB5b3UKPiA+IHRoZW4gaGF2ZSAyLiBZZXMsIGFzc3VtaW5n IHN1ZmZpY2llbnQgZXhwZW5kaXR1cmUgb2YgZW5lcmd5IGl0IGNhbiBiZQo+ID4gbWFkZSB0byB3 b3JrLCBidXQgSSdkIHByZWZlciB0byBtYWtlIG15IG93biBsaWZlIGFzIGVhc3kgYW5kIGxhenkg YXMKPiA+IHBvc3NpYmxlIDotKSBBbmQgSSB0aGluayBJJ3ZlIGJlZW4gZmFpcmx5IHN1Y2Nlc3Nm dWwgYXQgdGhhdCB3aXRoaW4KPiA+IGRyaXZlcnMvZ3B1IGF0IGxlYXN0Lgo+ID4gCj4gPiBJbW8g dGhlIHByb3BlciBmaXggaXMgdG8gbWVyZ2UgdjRsIGFuZCBkcm0sIGF0IGEgcHJvY2Vzcy9tYWlu dGFpbmVyCj4gPiBsZXZlbC4gVGhhdCB3b3VsZCBzb2x2ZSBib3RoIHRoZSBvcmlnaW5hbCBpc3N1 ZSBhbmQgdGhlIDJuZGFyeSBvbmUgb2YKPiA+IHRoZSBwZXJtYW5lbnQgdG9waWMgYnJhbmNoLgo+ IAo+IFByb3Bvc2FscyBhcmUgd2VsY29tZSA7LSkKCkknbSBhbHJlYWR5IHNvbWV3aGF0IHVucG9w dWxhciBhdCBMUEMvbGttbC9rZXJuZWwtYXQtbGFyZ2UsIEkgZG9uJ3Qgd2FudAp0byBtYWtlIHRo aXMgd29yc2UuICBUaGF0J3Mgd2h5IEkgZG9uJ3Qgd2FudCB0byBvZmZpY2lhbGx5IHB1c2ggZm9y CmFueXRoaW5nIGhlcmUgbXlzZWxmLCBub3IgYmUgaW4gYW55IG90aGVyIHdheSBpbnZvbHZlZCBp biBhbiBlZmZvcnQgdG8KZmlndXJlIG91dCB2NGwgZ292ZXJuYW5jZSBhbmQgbWFpbnRhaW5lcnNo aXAgcnVsZXMuCgpXaGF0IEkgdGhpbmsgaXMgcmVxdWlyZWQgZm9yIGVmZmljaWVudCBjb2xsYWJv cmF0aW9uIHdpdGggZHJtIChubyBtYXR0ZXIKaG93IHdlIGltcGxlbWVudCB0aGF0IGluIHRoZSBk ZXRhaWxzIG9uY2Ugd2UncmUgcmVhZHkgZm9yIHRoYXQgc3RlcCkgaXMKc29tZSBraW5kIG9mIGdy b3VwIG1haW50YWluZXJzaGlwIG1vZGVsLiBEb2Vzbid0IG5lZWQgdG8gYmUgYXMgZXh0cmVtZSBh cwpkcm0tbWlzYywgYnV0IEkgdGhpbmsgYXQgbGVhc3Qgc29tZXRoaW5nIGxpa2UgdGhlIHNvYyB0 cmVlICh3aGlsZSBpdCB3YXMKc3RpbGwgYSBiaXQgbW9yZSBsaW1pdGVkIGFzIGFybS1zb2MpLiBP dGhlcndpc2UgdGhlIGltcGVuZGVuY2UgbWlzbWF0Y2gKYmV0d2VlbiBob3cgZHJtIHJvbGxzIGFu ZCBob3cgdjRsIHJvbGxzIGlzIHByb2JhYmx5IHdheSB0b28gbXVjaC4gRnJvbSBteQp1bmRlcnN0 YW5kaW5nIHY0bCBpcyB3b3JraW5nIGRpZmZlcmVudGx5LgoKQWxzbywgdGhyb3VnaCBzaGVlciBp bmVydGlhIG9mIHNpemUsIEkgZG9uJ3QgdGhpbmsgaXQnbGwgYmUgZWFzaWVyIHRvCmFsaWduIGRy bSB3aXRoIHRoZSB2NGwgbW9kZWwuIFNvIHRoYXQgb3B0aW9uIGlzIG5vdCByZWFsaXN0aWMuCi1E YW5pZWwKLS0gCkRhbmllbCBWZXR0ZXIKU29mdHdhcmUgRW5naW5lZXIsIEludGVsIENvcnBvcmF0 aW9uCmh0dHA6Ly9ibG9nLmZmd2xsLmNoCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZy ZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RyaS1kZXZlbA== 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.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 682CCC04AA7 for ; Mon, 13 May 2019 14:57:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 11B402133F for ; Mon, 13 May 2019 14:57:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="U2fuTfzG" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729954AbfEMO52 (ORCPT ); Mon, 13 May 2019 10:57:28 -0400 Received: from mail-ed1-f68.google.com ([209.85.208.68]:38697 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729949AbfEMO52 (ORCPT ); Mon, 13 May 2019 10:57:28 -0400 Received: by mail-ed1-f68.google.com with SMTP id w11so17984449edl.5 for ; Mon, 13 May 2019 07:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=MSvqTdxGXoyR9SQPB6RCcihc4VqmlnyyqmDs39GV/sQ=; b=U2fuTfzG1aK1gzJrGYTrgoJsQamoUrvL0nY4dS5jQZVEBcJU3Su3MvtxFqiUNN+wgh 0I6aMzJA0msS3KJ4fEb0cN7EzfhmhUEAbzxA/lhld0o28hkpeVURXNLMkAp1Ef34z6kg 04ZhD/PLDtM8E8ZSVrjQ6h6sbULn/if6xE7uU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=MSvqTdxGXoyR9SQPB6RCcihc4VqmlnyyqmDs39GV/sQ=; b=Hrl4aSL/jf1G/OCzn6zxE5DdZhSgrTRdjHCMijwPusY621wMIsk9eToKh+oPpTSQX0 pJqNz4TOpmKa9WCZZs/md/IUNJitaPLtACJkZ5lvRjtxoUqTAXDl1pHbNyPo9hgx10ww EqwfHlV0uyXHXqRsTlCyy3myoaWF8LDdh2bSzLNKf2o/ImvpmUWooSDjfGNvMwe/N8+o 2su93UYbAz6J5fMbsBHP8IEhVrBMYRjYUEyTdw9eYkx1w6GK6XZqN7oTDM5LnG+7oCZi uWKVNfEJsdxf1VvJSZvfBkTVcBHKYK8evTigsaJf3B5OmwpdkG1CBJtyuV5Y1TMLU8AQ rl8w== X-Gm-Message-State: APjAAAXxOQ0hQMLnY/a3qajW+iaJxvpxcIcPF4HxkOoTxmayylTDZAhb 7IxXIwepBOKT/tIa1HDDvzk3Cw== X-Google-Smtp-Source: APXvYqy3DGSIQg9VSwlkTahybIOfvXa9u/9dtv50I3+PIi8oBgOI5FhGCA/QrGCNHixS132laxvVtQ== X-Received: by 2002:aa7:db0c:: with SMTP id t12mr30494565eds.170.1557759444507; Mon, 13 May 2019 07:57:24 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:569e:0:3106:d637:d723:e855]) by smtp.gmail.com with ESMTPSA id i2sm917437edg.81.2019.05.13.07.57.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 13 May 2019 07:57:23 -0700 (PDT) Date: Mon, 13 May 2019 16:57:19 +0200 From: Daniel Vetter To: Laurent Pinchart Cc: Daniel Vetter , Maxime Ripard , Daniel Vetter , David Airlie , Maarten Lankhorst , Sean Paul , Mauro Carvalho Chehab , Sakari Ailus , Linux Kernel Mailing List , dri-devel , Paul Kocialkowski , Hans Verkuil , Thomas Petazzoni , "open list:DMA BUFFER SHARING FRAMEWORK" Subject: Re: [PATCH 00/20] drm: Split out the formats API and move it to a common place Message-ID: <20190513145719.GS17751@phenom.ffwll.local> Mail-Followup-To: Laurent Pinchart , Maxime Ripard , Daniel Vetter , David Airlie , Maarten Lankhorst , Sean Paul , Mauro Carvalho Chehab , Sakari Ailus , Linux Kernel Mailing List , dri-devel , Paul Kocialkowski , Hans Verkuil , Thomas Petazzoni , "open list:DMA BUFFER SHARING FRAMEWORK" References: <20190417154121.GJ13337@phenom.ffwll.local> <20190418062229.eyog4i62eg4pr6uf@flea> <20190418090221.e57dogn4yx5nwdni@flea> <20190420225904.GZ4964@pendragon.ideasonboard.com> <20190423072554.GW13337@phenom.ffwll.local> <20190423154527.GH16111@pendragon.ideasonboard.com> <20190511192632.GN13043@pendragon.ideasonboard.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190511192632.GN13043@pendragon.ideasonboard.com> X-Operating-System: Linux phenom 4.14.0-3-amd64 User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org On Sat, May 11, 2019 at 10:26:32PM +0300, Laurent Pinchart wrote: > On Tue, Apr 23, 2019 at 09:18:52PM +0200, Daniel Vetter wrote: > > On Tue, Apr 23, 2019 at 5:45 PM Laurent Pinchart wrote: > > > On Tue, Apr 23, 2019 at 09:25:54AM +0200, Daniel Vetter wrote: > > >> On Sun, Apr 21, 2019 at 01:59:04AM +0300, Laurent Pinchart wrote: > > >>> On Thu, Apr 18, 2019 at 12:07:44PM +0200, Daniel Vetter wrote: > > >>>> On Thu, Apr 18, 2019 at 11:02 AM Maxime Ripard wrote: > > >>>>> On Thu, Apr 18, 2019 at 09:52:10AM +0200, Daniel Vetter wrote: > > >>>>>> On Thu, Apr 18, 2019 at 8:22 AM Maxime Ripard wrote: > > >>>>>>> On Wed, Apr 17, 2019 at 05:41:21PM +0200, Daniel Vetter wrote: > > >>>>>>>> On Wed, Apr 17, 2019 at 09:54:26AM +0200, Maxime Ripard wrote: > > >>>>>>>>> Hi, > > >>>>>>>>> > > >>>>>>>>> DRM comes with an extensive format support to retrieve the various > > >>>>>>>>> parameters associated with a given format (such as the subsampling, or the > > >>>>>>>>> bits per pixel), as well as some helpers and utilities to ease the driver > > >>>>>>>>> development. > > >>>>>>>>> > > >>>>>>>>> v4l2, on the other side, doesn't provide such facilities, leaving each > > >>>>>>>>> driver reimplement a subset of the formats parameters for the one supported > > >>>>>>>>> by that particular driver. This leads to a lot of duplication and > > >>>>>>>>> boilerplate code in the v4l2 drivers. > > >>>>>>>>> > > >>>>>>>>> This series tries to address this by moving the DRM format API into lib and > > >>>>>>>>> turning it into a more generic API. In order to do this, we've needed to do > > >>>>>>>>> some preliminary changes on the DRM drivers, then moved the API and finally > > >>>>>>>>> converted a v4l2 driver to give an example of how such library could be > > >>>>>>>>> used. > > >>>>>>>>> > > >>>>>>>>> Let me know what you think, > > >>>>>>>>> Maxime > > >>>>>>>>> > > >>>>>>>>> Changes from RFC: > > >>>>>>>>> - Rebased on next > > >>>>>>>>> - Fixed the various formats mapping > > >>>>>>>>> - Added tags > > >>>>>>>>> - Did most of the formats functions as inline functions > > >>>>>>>>> - Used a consistent prefix for all the utilities functions > > >>>>>>>>> - Fixed the compilation breakages, and did a run of allmodconfig for arm, > > >>>>>>>>> arm64 and x86_64 > > >>>>>>>>> - Fixed out of array bounds warnings in the image_format_info_block_* > > >>>>>>>>> functions > > >>>>>>>>> - Added License and copyright headers on missing files > > >>>>>>>>> > > >>>>>>>>> Maxime Ripard (20): > > >>>>>>>>> drm: Remove users of drm_format_num_planes > > >>>>>>>>> drm: Remove users of drm_format_(horz|vert)_chroma_subsampling > > >>>>>>>>> drm/fourcc: Pass the format_info pointer to drm_format_plane_cpp > > >>>>>>>>> drm/fourcc: Pass the format_info pointer to drm_format_plane_width/height > > >>>>>>>>> drm: Replace instances of drm_format_info by drm_get_format_info > > >>>>>>>>> lib: Add video format information library > > >>>>>>>>> drm/fb: Move from drm_format_info to image_format_info > > >>>>>>>>> drm/malidp: Convert to generic image format library > > >>>>>>>>> drm/client: Convert to generic image format library > > >>>>>>>>> drm/exynos: Convert to generic image format library > > >>>>>>>>> drm/i915: Convert to generic image format library > > >>>>>>>>> drm/ipuv3: Convert to generic image format library > > >>>>>>>>> drm/msm: Convert to generic image format library > > >>>>>>>>> drm/omap: Convert to generic image format library > > >>>>>>>>> drm/rockchip: Convert to generic image format library > > >>>>>>>>> drm/tegra: Convert to generic image format library > > >>>>>>>>> drm/fourcc: Remove old DRM format API > > >>>>>>>>> lib: image-formats: Add v4l2 formats support > > >>>>>>>>> lib: image-formats: Add more functions > > >>>>>>>>> media: sun6i: Convert to the image format API > > >>>>>>>> > > >>>>>>>> In the interest of making myself unpopular: Why move this out of drm? > > >>>>>>>> > > >>>>>>>> We do have a bunch of other such shared helpers already (mostly in > > >>>>>>>> drivers/video) for dt videomode and hdmi infoframes, and I'm not super > > >>>>>>>> sure that's going better than keeping it maintained in drm. > > >>> > > >>> That's a bit of a different situation as both DRM and FBDEV address the > > >>> same features (display output), and FBDEV is deprecared and replaced by > > >>> DRM. > > >>> > > >>> I'm not against maintaining a 4CC library in DRM (adding a third-party > > >>> maintainer would likely create more problems than it would solve), but > > >>> that doesn't mean the library has to live in drivers/gpu/, nor that it > > >>> needs to have the drm_ prefix. I would actually advocate to make it live > > >>> in a neutral directory, with a neutral prefix (kudos to anyone who can > > >>> propose a nice naming convention that would establish a new shared > > >>> ground for image/video-related Linux APIs), and maintained through the > > >>> DRM tree (possibly with extra entries in MAINTAINERS to ensure it > > >>> reaches all the related folks). > > >>> > > >>>>>>>> Plus the uapi is already that you include drm_fourcc.h to get at these, > > >>>>>>>> dropping the drm prefix isn't going to help I think. > > >>>>>>>> > > >>>>>>>> Of course we'd need to make it a separate drm_formats.ko (so that v4l can > > >>>>>>>> use it without dragging in all of drm), and we need to add some fields for > > >>>>>>>> converting to v4l fourcc codes (which are different). But that should be > > >>>>>>>> all possible. And I don't think the drm_ prefix in v4l code is a problem, > > >>>>>>>> it's actually a feature: It makes it really clear that these are the drm > > >>>>>>>> fourcc codes, as allocated in drm_fourcc.h, plus their modifiers, and all > > >>>>>>>> that. That allocation authority is also already baked into various khr/ext > > >>>>>>>> standards, too. > > >>> > > >>> There's one thing that V4L2 has and DRM hasn't for 4CCs: good > > >>> documentation. Look at > > >>> https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/pixfmt-packed-rgb.html > > >>> or > > >>> https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/yuv-formats.html > > >>> for instance. It's painful to write, painful to read, but defines the > > >>> 4CCs very clearly without ambiguity. I wouldn't be surprised if > > >>> different drivers used the same DRM 4CC for different formats due to the > > >>> lack of detailed documentation. Moving to a shared library for 4CCs > > >>> should also address the documentation side, and any new format added to > > >>> the kernel, whether from the V4L2 side or the DRM side, would be > > >>> required to provide detailed documentation. That would be a great > > >>> improvement for DRM 4CC handling. > > >>> > > >>>>>>> The way I see it, there's a fundamental difference between the UAPI > > >>>>>>> and the kernel. I don't suggest we change anything about the UAPI: the > > >>>>>>> drm formats should keep their prefix, drm_fourcc.h can remain that > > >>>>>>> authority, it's all fine. > > >>>>>>> > > >>>>>>> Internally however, the long term goal is to share the fourcc's > > >>>>>>> between DRM and V4L2 for the same formats. It basically means that of > > >>>>>>> course v4l2 should be using the DRM fourcc when a format exists in DRM > > >>>>>>> and not v4l2, but also that DRM should use v4l2 fourcc when the format > > >>>>>>> exists in v4l2 but not DRM, and that is far more likely, given the > > >>>>>>> already extensive v4l2 formats support. > > >>>>>> > > >>>>>> Uh no. We did look at v4l fourcc extensively when deciding upon a drm > > >>>>>> format identifier space. > > >>>>> > > >>>>> No to what exactly? > > >>>>> > > >>>>>> 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. > > >>>> > > >>>> drm fourcc is the authority for drm fourcc codes. Not for any of the > > >>>> others (and there's lots of them). Now it's used in a bunch of other > > >>>> places (khr standards, dri protocols in wayland/X11), but they're > > >>>> still only drm fourcc. There is no overall fourcc standard. > > >>>> > > >>>>>> 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? > > >>>> > > >>>> I think the rgb stuff was one of the big reasons to not reuse any > > >>>> existing fourcc standard (whether v4l, or another one from e.g. video > > >>>> container formats). We had initial patches to reuse the fourcc that > > >>>> existed, but the end result was really inconsistent, so we ditch that > > >>>> and rolled out a new set of entirely drm specific fourcc codes for > > >>>> rgba. > > >>> > > >>> Could you give one or a couple of examples of V4L2 4CCs that are not > > >>> OCD-compatible ? :-) > > >>> > > >>>>>> - 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. > > >>> > > >>> That's a mistake in my opinion. We tried that in V4L2 to store metadata > > >>> in a separate plane, and had to go another route eventually as it > > >>> created a very bad mess. > > >> > > >> Just quick clarification in the middle here: This is how the hw works. > > > > > > The hardware takes parameters from a buffer, but it doesn't mandate how > > > that buffer is exposed to userspace :-) Using an extra plane is one > > > option, but other APIs are possible. > > > > I think Daniel Stone explains fairly well why some of our additional > > metadata is included as a plane, while a lot of the other metadata > > involved in rendering/compute the framebuffer isn't. Not really > > anything to add here. > > > > >> It's not metadata that sw ever touches (in general, testcases to make sure > > >> we display these correctly excepted). > > >> > > >> There has been some talking to add maybe a bit more mixed metadata, for > > >> fast-clear colors (which isn't used by any display engine afaik yet). That > > > > > > What are fast-clear colors ? > > > > hw offers enormous amounts of tricks to make glClear O(1), or at least > > close enough. glClear is usually what's done at the start of every > > frame, and clears the entire framebuffer to a uniform color. This is > > achieved usually through 3 pieces: > > - actual framebuffer plane with the pixel data > > - a 2nd plane that (usually, but there's lots of tricks here) contains > > a bit of metadata per cacheline/block/whatever in the framebuffer to > > indicate how/if those pixels are compressed, or whether they are still > > the uniform color supplied through glClear. For actual O(1) this > > metadata is hierarchical, so that a glClear really only sets the > > top-level metadata to "all subordinate blocks still have are the clear > > color". hw tends to have some pretty strong opinions on where it's > > going to look for that 2nd plane. > > - curiously on most hw the actual clear color is supplied separately > > (and our plan is to just stuff it into a 3rd plane) > > Just to clarify, is this needed for display engines ? Does the GPU > render to a 3 planes buffer with glClear()-related data in planes 2 and > 3, with the buffer then being passed to the display engine that knows > how to interpret this, or are those extra planes only needed for GPU > rendering ? I haven't yet seen a display engine that can scan out fast-cleared buffers like these. Everyone can scan out compressed buffers, i.e. rgb + 2nd auxialliary buffer with some compression metadata. But not yet with the 3rd plane. So not relevant for display. But it is very much relevant for uapi/drm_fourcc.h, because we'll need it for userspace interop between different apis (vk, gl, ...) and different processes (client, compositor). And in these standard extension texts we've officially made the kernel's copy of that file the official registry. So these fourcc+modifier codes will end up at least in that namespace (but maybe not in the same library the kernel uses internally). > > >> would generally be written by the cpu (in the gl stack), but again read by > > >> the hw (loaded as indirect state packet most likely, or something like > > >> that). So again hw specific layout, because the hw needs to read it. > > >> > > >> Pure metadata only of interest for the cpu/sw stack has been shot down > > >> completely on the drm side too. > > >> > > >>> There's a tendency in both subsystems to look at the other as a bit of a > > >>> retarded relative, and that's a shame, we have lots to learn from each > > >>> other's mistakes. That wouldn't be too difficult if people started > > >>> talking to each other. > > >>> > > >>> A semi-related comment: DRM also carries other mistakes of its own, I'm > > >>> thinking about DRM_FORMAT_BIG_ENDIAN in particular > > >> > > >> Yeah that one is hilarios, but in practice big endian is dead, except for > > >> a very few server chips, and there I think Gerd's work mostly fixed up > > >> that mess. > > >> > > >>>>> 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. > > >>>> > > >>>> See above, we tried that initially, didn't pass the ocd tests when > > >>>> reviewing. Maybe the situation is better outside of rbgx/a formats, > > >>>> and I think we do at least try to use the same fourcc codes there when > > >>>> there already is one. But then the details occasionally look > > >>>> different. > > >>>> > > >>>>>>> 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. > > >>>> > > >>>> Yeah I know. I still think leaving the drm fourcc with the drm prefix > > >>>> would be good, since there's really no standard here. > > >>>> > > >>>>>> 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? > > >>>> > > >>>> None of this is fixed by code renaming or locations. Either way we > > >>>> need to figure that out. > > >>>> > > >>>> And yes part of the reasons for not moving this out of drm is that I'm > > >>>> not a fan of boutique trees for small stuff. If sharing means we need > > >>>> to split the drm_fourcc code and library out of drm trees, I'm not > > >>>> sure that's a good idea. We're already super liberal with merging > > >>>> anything through driver trees with acks, and integrating them quickly > > >>>> into drm-next. This would still be workable if v4l sends regular pull > > >>>> requests to drm-next (every 1-2 weeks, like the other big gpu trees > > >>>> do). If we can only sync up once per merge window with a shared > > >>>> boutique tree for formats only, life is going to be painful. > > >>> > > >>> That should be solved by the proposal above, maintaining the shared > > >>> library in the DRM tree. We would need to be careful there, and ideally > > >>> maintain that in a separate branch that could be merged in both DRM and > > >>> V4L2 without having to merge most of the other subsystem's pending > > >>> changes at the same time, but I think it's doable without any big issue. > > >>> > > >>>>> 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. > > >>>> > > >>>> It might make sense to regularly pull v4l updates into drm-next then > > >>>> anyway. That would also remove the need to have the format library > > >>>> somewhere else. > > >>> > > >>> Are you saying it should the live in V4L2 ? ;-) > > >> > > >> Maybe a few clarifications on how the drm shared core thing usually works, > > >> and why I'm a sticker here. Bottom reply since I'm not sure where to put > > >> it: > > >> > > >> - Refactorings usually go in through drm-misc (at least since a few > > >> years). > > >> > > >> - Small patches go in through the relevant driver tree (which is often > > >> drm-misc, but not always), with an Ack from drm maintainers. > > >> > > >> - No topic branches, everyone just pushes patches where it's most > > >> convenient. > > >> > > >> We get away with this mess because everyone sends regular pull requests to > > >> drm, where the entire history is baked in and others can backmerge/fast > > >> forward/rebase. Worst case you wait one month (around the merge window, > > >> when drm-next is closed for features), but usually it's just 1-2 weeks. > > >> Plus we tend to have fairly big trees, with good chances that the next > > >> patch series lands in the same tree again and no work at all is needed. > > >> > > >> If we start regularly sharing lots of code with v4l (which seems to be the > > >> long term goal here), then I think we need something equally convenient > > >> for all that. > > >> > > >> We're not going to be able to teach some complicated topic branch scheme > > >> to the 50+ submaintainers/committers we have in drm - a lot much more > > >> basic stuff already takes lots of work to get it to stick. If the proposal > > >> is "to be careful" and "maintain it in a separate branch", I'm not in > > >> favour because I think that just wouldn't work. > > > > > > Why not ? It can be a fast-moving branch that gets merged in drm-misc > > > as often as you want (even at every commit if that's desired). We're > > > dealing with a limited amount of code here, and there's no more reason > > > that V4L2 should pull in drm-misc to get 4CC updates than DRM should > > > pull V4L2 for the same. I have no objection against a 4CC branch being > > > officially maintained under the DRM umbrella, but I think the code > > > should live elsewhere than drivers/gpu/drm/, have a neutral prefix, and > > > not require pulling an entire subsystem in. > > > > I think small boutique trees are a problem themselves, not a solution. > > So if you're creating a new small boutique tree to fix a problem, you > > then have 2. Yes, assuming sufficient expenditure of energy it can be > > made to work, but I'd prefer to make my own life as easy and lazy as > > possible :-) And I think I've been fairly successful at that within > > drivers/gpu at least. > > > > Imo the proper fix is to merge v4l and drm, at a process/maintainer > > level. That would solve both the original issue and the 2ndary one of > > the permanent topic branch. > > Proposals are welcome ;-) I'm already somewhat unpopular at LPC/lkml/kernel-at-large, I don't want to make this worse. That's why I don't want to officially push for anything here myself, nor be in any other way involved in an effort to figure out v4l governance and maintainership rules. What I think is required for efficient collaboration with drm (no matter how we implement that in the details once we're ready for that step) is some kind of group maintainership model. Doesn't need to be as extreme as drm-misc, but I think at least something like the soc tree (while it was still a bit more limited as arm-soc). Otherwise the impendence mismatch between how drm rolls and how v4l rolls is probably way too much. From my understanding v4l is working differently. Also, through sheer inertia of size, I don't think it'll be easier to align drm with the v4l model. So that option is not realistic. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch