From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Subject: Re: DRM Format Modifiers in v4l2 Date: Thu, 31 Aug 2017 17:36:43 +0300 Message-ID: <7090676.9SSa8TzciT@avalon> References: <20170821155203.GB38943@e107564-lin.cambridge.arm.com> <20170829091943.GA26907@e107564-lin.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from galahad.ideasonboard.com (galahad.ideasonboard.com [185.26.127.97]) by gabe.freedesktop.org (Postfix) with ESMTPS id D65CF89CF7 for ; Thu, 31 Aug 2017 14:36:11 +0000 (UTC) In-Reply-To: <20170829091943.GA26907@e107564-lin.cambridge.arm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Brian Starkey Cc: Hans Verkuil , jonathan.chai@arm.com, dri-devel , "linux-media@vger.kernel.org" List-Id: dri-devel@lists.freedesktop.org SGkgQnJpYW4sCgpPbiBUdWVzZGF5LCAyOSBBdWd1c3QgMjAxNyAxMjoxOTo0MyBFRVNUIEJyaWFu IFN0YXJrZXkgd3JvdGU6Cj4gT24gRnJpLCBBdWcgMjUsIDIwMTcgYXQgMTA6MTQ6MDNBTSArMDIw MCwgSGFucyBWZXJrdWlsIHdyb3RlOgo+ID5PbiAyNC8wOC8xNyAxNDoyNiwgQnJpYW4gU3Rhcmtl eSB3cm90ZToKPiA+PiBPbiBUaHUsIEF1ZyAyNCwgMjAxNyBhdCAwMTozNzozNVBNICswMjAwLCBI YW5zIFZlcmt1aWwgd3JvdGU6Cj4gPj4+IE9uIDA4LzI0LzE3IDEzOjE0LCBCcmlhbiBTdGFya2V5 IHdyb3RlOgo+ID4+Pj4gT24gTW9uLCBBdWcgMjEsIDIwMTcgYXQgMDY6MzY6MjlQTSArMDIwMCwg SGFucyBWZXJrdWlsIHdyb3RlOgo+ID4+Pj4+IE9uIDA4LzIxLzIwMTcgMDY6MDEgUE0sIERhbmll bCBWZXR0ZXIgd3JvdGU6Cj4gPj4+Pj4+IE9uIE1vbiwgQXVnIDIxLCAyMDE3IGF0IDU6NTIgUE0s IEJyaWFuIFN0YXJrZXkgd3JvdGU6Cj4gPj4+Pj4+PiBIaSBhbGwsCj4gPj4+Pj4+PiAKPiA+Pj4+ Pj4+IEkgY291bGRuJ3QgZmluZCB0aGlzIHRvcGljIHRhbGtlZCBhYm91dCBlbHNld2hlcmUsIGJ1 dCBhcG9sb2dpZXMgaWYKPiA+Pj4+Pj4+IGl0J3MgYSBkdXBsaWNhdGUgLSBJJ2xsIGJlIGdsYWQg dG8gYmUgc3RlZXJlZCBpbiB0aGUgZGlyZWN0aW9uIG9mIGEKPiA+Pj4+Pj4+IHRocmVhZC4KPiA+ Pj4+Pj4+IAo+ID4+Pj4+Pj4gV2UnZCBsaWtlIHRvIHN1cHBvcnQgRFJNIGZvcm1hdCBtb2RpZmll cnMgaW4gdjRsMiBpbiBvcmRlciB0byBzaGFyZQo+ID4+Pj4+Pj4gdGhlIGRlc2NyaXB0aW9uIG9m IGRpZmZlcmVudCAobW9zdGx5IHByb3ByaWV0YXJ5KSBidWZmZXIgZm9ybWF0cwo+ID4+Pj4+Pj4g YmV0d2VlbiBlLmcuIGEgdjRsMiBkZXZpY2UgYW5kIGEgRFJNIGRldmljZS4KPiA+Pj4+Pj4+IAo+ ID4+Pj4+Pj4gRFJNIGZvcm1hdCBtb2RpZmllcnMgYXJlIGRlZmluZWQgaW4gaW5jbHVkZS91YXBp L2RybS9kcm1fZm91cmNjLmgKPiA+Pj4+Pj4+IGFuZCBhcmUgYSB2ZW5kb3ItbmFtZXNwYWNlZCA2 NC1iaXQgdmFsdWUgdXNlZCB0byBkZXNjcmliZSB2YXJpb3VzCj4gPj4+Pj4+PiB2ZW5kb3Itc3Bl Y2lmaWMgYnVmZmVyIGxheW91dHMuIFRoZXkgYXJlIGNvbWJpbmVkIHdpdGggYSAoRFJNKQo+ID4+ Pj4+Pj4gRm91ckNDIGNvZGUgdG8gZ2l2ZSBhIGNvbXBsZXRlIGRlc2NyaXB0aW9uIG9mIHRoZSBk YXRhIGNvbnRhaW5lZCBpbgo+ID4+Pj4+Pj4gYSBidWZmZXIuCj4gPj4+Pj4+PiAKPiA+Pj4+Pj4+ IFRoZSBzYW1lIG1vZGlmaWVyIGRlZmluaXRpb24gaXMgdXNlZCBpbiB0aGUgS2hyb25vcyBFR0wg ZXh0ZW5zaW9uCj4gPj4+Pj4+PiBFR0xfRVhUX2ltYWdlX2RtYV9idWZfaW1wb3J0X21vZGlmaWVy cywgYW5kIGlzIHN1cHBvcnRlZCBpbiB0aGUKPiA+Pj4+Pj4+IFdheWxhbmQgbGludXgtZG1hYnVm IHByb3RvY29sLgo+ID4+Pj4+Pj4gCj4gPj4+Pj4+PiAKPiA+Pj4+Pj4+IFRoaXMgYnVmZmVyIGlu Zm9ybWF0aW9uIGNvdWxkIG9mIGNvdXJzZSBiZSBkZXNjcmliZWQgaW4gdGhlCj4gPj4+Pj4+PiB2 ZW5kb3Itc3BlY2lmaWMgcGFydCBvZiBWNEwyX1BJWF9GTVRfKiwgYnV0IHRoaXMgd291bGQgZHVw bGljYXRlIHRoZQo+ID4+Pj4+Pj4gaW5mb3JtYXRpb24gYWxyZWFkeSBkZWZpbmVkIGluIGRybV9m b3VyY2MuaC4gQWRkaXRpb25hbGx5LCB0aGVyZQo+ID4+Pj4+Pj4gd291bGQgYmUgcXVpdGUgYSBm b3JtYXQgZXhwbG9zaW9uIHdoZXJlIGEgZGV2aWNlIHN1cHBvcnRzIGEgZG96ZW4gb3IKPiA+Pj4+ Pj4+IG1vcmUgZm9ybWF0cywgYWxsIG9mIHdoaWNoIGNhbiB1c2Ugb25lIG9yIG1vcmUgZGlmZmVy ZW50Cj4gPj4+Pj4+PiBsYXlvdXRzL2NvbXByZXNzaW9uIHNjaGVtZXMuCj4gPj4+Pj4+PiAKPiA+ Pj4+Pj4+IFNvLCBJJ20gd29uZGVyaW5nIGlmIGFueW9uZSBoYXMgdmlld3Mgb24gaG93L3doZXRo ZXIgdGhpcyBjb3VsZCBiZQo+ID4+Pj4+Pj4gaW5jb3Jwb3JhdGVkPwo+ID4+Pj4+Pj4gCj4gPj4+ Pj4+PiBJIHNwb2tlIGJyaWVmbHkgYWJvdXQgdGhpcyB0byBMYXVyZW50IGF0IExQQyBsYXN0IHll YXIsIGFuZCBoZQo+ID4+Pj4+Pj4gc3VnZ2VzdGVkIHY0bDJfY29udHJvbCBhcyBvbmUgYXBwcm9h Y2guCj4gPj4+Pj4+PiAKPiA+Pj4+Pj4+IEkgYWxzbyB3b25kZXJlZCBpZiBjb3VsZCBiZSBhZGRl ZCBpbiB2NGwyX3BpeF9mb3JtYXRfbXBsYW5lIC0gbG9va3MKPiA+Pj4+Pj4+IGxpa2UgdGhlcmUn cyA4IGJ5dGVzIGxlZnQgYmVmb3JlIGl0IGV4Y2VlZHMgdGhlIDIwMCBieXRlcywgb3IgY291bGQK PiA+Pj4+Pj4+IGdvIGluIHRoZSByZXNlcnZlZCBwb3J0aW9uIG9mIHY0bDJfcGxhbmVfcGl4X2Zv cm1hdC4KPiA+Pj4+Pj4+IAo+ID4+Pj4+Pj4gVGhhbmtzIGZvciBhbnkgdGhvdWdodHMsCj4gPj4+ Pj4+IAo+ID4+Pj4+PiBPbmUgcHJvYmxlbSBpcyB0aGF0IHRoZSBtb2RpZmVycyBzb21ldGltZXMg cmVmZXJlbmNlIHRoZSBEUk0gZm91cmNjCj4gPj4+Pj4+IGNvZGVzLiB2NGwgaGFzIGEgZGlmZmVy ZW50IChhbmQgaW5jb21wYXRpYmxlIHNldCkgb2YgZm91cmNjIGNvZGVzLAo+ID4+Pj4+PiB3aGVy ZWFzIGFsbCB0aGUgcHJvdG9jb2xzIGFuZCBzcGVjcyAoeW91IGNhbiBhZGQgRFJJMy4xIGZvciBY b3JnIHRvCj4gPj4+Pj4+IHRoYXQgbGlzdCBidHcpIHVzZSBib3RoIGRybSBmb3VyY2MgYW5kIGRy bSBtb2RpZmllcnMuCj4gPj4+Pj4+IAo+ID4+Pj4+PiBUaGlzIG1pZ2h0IG9yIG1pZ2h0IG5vdCBt YWtlIHRoaXMgcHJvcG9zYWwgdW53b3JrYWJsZSwgYnV0IGl0J3MKPiA+Pj4+Pj4gc29tZXRoaW5n IEknZCBhdCBsZWFzdCByZXZpZXcgY2FyZWZ1bGx5Lgo+ID4+Pj4+PiAKPiA+Pj4+Pj4gT3RoZXJ3 aXNlIEkgdGhpbmsgaXQnZCBiZSBncmVhdCBpZiB3ZSBjb3VsZCBoYXZlIG9uZSBuYW1lc3BhY2Ug Zm9yCj4gPj4+Pj4+IGFsbCBtb2RpZmllcnMsIHRoYXQncyBwcmV0dHkgbXVjaCB3aHkgd2UgaGF2 ZSB0aGVtLiBQbGVhc2UgYWxzbyBub3RlCj4gPj4+Pj4+IHRoYXQgZm9yIGRybV9mb3VyY2MuaCB3 ZSBkb24ndCByZXF1aXJlIGFuIGluLWtlcm5lbCB1c2VyIGZvciBhIG5ldwo+ID4+Pj4+PiBtb2Rp ZmllciBzaW5jZSBhIGJ1bmNoIG9mIHRoZW0gbWlnaHQgbmVlZCB0byBiZSBhbGxvY2F0ZWQganVz dCBmb3IKPiA+Pj4+Pj4gdXNlcnNwYWNlLXRvLXVzZXJzcGFjZSBidWZmZXIgc2hhcmluZyAoZS5n LiBpbiBFR0wvdmspLiBPbmUgZXhhbXBsZQo+ID4+Pj4+PiBmb3IgdGhpcyB3b3VsZCBiZSBjb21w cmVzc2VkIHN1cmZhY2VzIHdpdGggZmFzdC1jbGVhcmluZywgd2hpY2ggaXMKPiA+Pj4+Pj4gcGxh bm5lZCBmb3IgaTkxNSAoYnV0IGN1cnJlbnQgaHcgY2FuJ3Qgc2NhbiBpdCBvdXQpLiBBbmQgd2Ug cmVhbGx5Cj4gPj4+Pj4+IHdhbnQgdG8gaGF2ZSBvbmUgbmFtZXNwYWNlIGZvciBldmVyeXRoaW5n Lgo+ID4+Pj4+IAo+ID4+Pj4+IFdobyBzZXRzIHRoZXNlIG1vZGlmaWVycz8gS2VybmVsIG9yIHVz ZXJzcGFjZT8gT3IgY2FuIGl0IGJlIHNldCBieQo+ID4+Pj4+IGJvdGg/IEkgYXNzdW1lIGFueSB1 c2Vyc3BhY2UgY29kZSB0aGF0IHNldHMvcmVhZHMgdGhpcyBpcyBjb2RlCj4gPj4+Pj4gc3BlY2lm aWMgZm9yIHRoYXQgaGFyZHdhcmU/Cj4gPj4+PiAKPiA+Pj4+IEkgdGhpbmsgbm9ybWFsbHkgdGhl IG1vZGlmaWVyIHdvdWxkIGJlIHNldCBieSB1c2Vyc3BhY2UuIEhvd2V2ZXIgaXQKPiA+Pj4+IG1p Z2h0IG5vdCBuZWNlc3NhcmlseSBiZSBkZXZpY2Utc3BlY2lmaWMgY29kZS4gSW4gRFJNIHRoZSBp bnRlbnRpb24gaXMKPiA+Pj4+IGZvciB1c2Vyc3BhY2UgdG8gcXVlcnkgdGhlIHNldCBvZiBtb2Rp ZmllcnMgd2hpY2ggYXJlIHN1cHBvcnRlZCwgYW5kCj4gPj4+PiB0aGVuIHVzZSB0aGVtIHdpdGhv dXQgbmVjZXNzYXJpbHkga25vd2luZyBleGFjdGx5IHdoYXQgdGhleSBtZWFuCj4gPj4+PiAoaW5z b2ZhciBhcyB0aGF0IGlzIHBvc3NpYmxlKS4KPiA+Pj4+IAo+ID4+Pj4gZS5nLiBpZiBJIGhhdmUg dHdvIGRldmljZXMgd2hpY2ggc3VwcG9ydCBNT0RJRklFUl9GT08sIEkgY291bGQgYXR0ZW1wdAo+ ID4+Pj4gdG8gc2hhcmUgYSBidWZmZXIgYmV0d2VlbiB0aGVtIHdoaWNoIHVzZXMgTU9ESUZJRVJf Rk9PIHdpdGhvdXQKPiA+Pj4+IG5lY2Vzc2FyaWx5IGtub3dpbmcgZXhhY3RseSB3aGF0IGl0IGlz L2RvZXMuCj4gPj4+PiAKPiA+Pj4+PiBJIHRoaW5rIExhdXJlbnQncyBzdWdnZXN0aW9uIG9mIHVz aW5nIGEgNjQgYml0IFY0TDIgY29udHJvbCBmb3IgdGhpcwo+ID4+Pj4+IG1ha2VzIHRoZSBtb3N0 IHNlbnNlLgo+ID4+Pj4+IAo+ID4+Pj4+IEVzcGVjaWFsbHkgaWYgeW91IGNhbiBhc3N1bWUgdGhh dCB3aG9ldmVyIHNldHMgdGhpcyBrbm93cyB0aGUKPiA+Pj4+PiBoYXJkd2FyZS4KPiA+Pj4+PiAK PiA+Pj4+PiBJIHRoaW5rIHRoaXMgb25seSBtYWtlcyBzZW5zZSBpZiB5b3UgcGFzcyBidWZmZXJz IGZyb20gb25lIEhXIGRldmljZQo+ID4+Pj4+IHRvIGFub3RoZXIuCj4gPj4+Pj4gCj4gPj4+Pj4g QmVjYXVzZSB5b3UgY2Fubm90IGV4cGVjdCBnZW5lcmljIHZpZGVvIGNhcHR1cmUgY29kZSB0byBi ZSBhYmxlIHRvCj4gPj4+Pj4gaW50ZXJwcmV0IGFsbCB0aGUgemlsbGlvbiBkaWZmZXJlbnQgY29t YmluYXRpb25zIG9mIG1vZGlmaWVycy4KPiA+Pj4+IAo+ID4+Pj4gSSBkb24ndCBxdWl0ZSBmb2xs b3cgdGhpcyBsYXN0IGJpdC4gVGhlIGNvbnRyb2wgY291bGQgcmVwb3J0IHRoZSBzZXQKPiA+Pj4+ IG9mIHN1cHBvcnRlZCBtb2RpZmllcnMuCj4gPj4+IAo+ID4+PiBXaGF0IEkgbWVhbiB3YXM6IGFu IGFwcGxpY2F0aW9uIGNhbiB1c2UgdGhlIG1vZGlmaWVyIHRvIGdpdmUgYnVmZmVycwo+ID4+PiBm cm9tIG9uZSBkZXZpY2UgdG8gYW5vdGhlciB3aXRob3V0IG5lZWRpbmcgdG8gdW5kZXJzdGFuZCBp dC4KPiA+Pj4gCj4gPj4+IEJ1dCBhIGdlbmVyaWMgdmlkZW8gY2FwdHVyZSBhcHBsaWNhdGlvbiB0 aGF0IHByb2Nlc3NlcyB0aGUgdmlkZW8gaXRzZWxmCj4gPj4+IGNhbm5vdCBiZSBleHBlY3RlZCB0 byBrbm93IGFib3V0IHRoZSBtb2RpZmllcnMuIEl0J3MgYSBjdXN0b20gSFcKPiA+Pj4gc3BlY2lm aWMgZm9ybWF0IHRoYXQgeW91IG9ubHkgdXNlIGJldHdlZW4gdHdvIEhXIGRldmljZXMgb3Igd2l0 aAo+ID4+PiBzb2Z0d2FyZSB3cml0dGVuIGZvciB0aGF0IGhhcmR3YXJlLgo+ID4+IAo+ID4+IFll cywgbWFrZXMgc2Vuc2UuCj4gPj4gCj4gPj4+PiBIb3dldmVyLCBpbiBEUk0gdGhlIEFQSSBsZXRz IHlvdSBnZXQgdGhlIHN1cHBvcnRlZCBmb3JtYXRzIGZvciBlYWNoCj4gPj4+PiBtb2RpZmllciBh cy13ZWxsLWFzIHRoZSBtb2RpZmllciBsaXN0IGl0c2VsZi4gSSdtIG5vdCBzdXJlIGhvdyBleGFj dGx5Cj4gPj4+PiB0byBwcm92aWRlIHRoYXQgaW4gYSBjb250cm9sLgo+ID4+PiAKPiA+Pj4gV2Ug aGF2ZSBzdXBwb3J0IGZvciBhICdtZW51JyBvZiA2NCBiaXQgaW50ZWdlcnM6Cj4gPj4+IFY0TDJf Q1RSTF9UWVBFX0lOVEVHRVJfTUVOVS4gWW91IHVzZSBWSURJT0NfUVVFUllNRU5VIHRvIGVudW1l cmF0ZSB0aGUKPiA+Pj4gYXZhaWxhYmxlIG1vZGlmaWVycy4KPiA+Pj4gCj4gPj4+IFNvIGVudW1l cmF0aW5nIHRoZXNlIG1vZGlmaWVycyB3b3VsZCB3b3JrIG91dC1vZi10aGUtYm94Lgo+ID4+IAo+ ID4+IFJpZ2h0LiBTbyBJIGd1ZXNzIHRoZSBzdXBwb3J0ZWQgc2V0IG9mIGZvcm1hdHMgY291bGQg YmUgc29tZWhvdwo+ID4+IGVudW1lcmF0ZWQgaW4gdGhlIG1lbnUgaXRlbSBzdHJpbmcuIEluIERS TSB0aGUgcGFpcnMgYXJlIChtb2RpZmllciArCj4gPj4gYml0bWFzaykgd2hlcmUgYml0cyByZXBy ZXNlbnQgZm9ybWF0cyBpbiB0aGUgc3VwcG9ydGVkIGZvcm1hdHMgbGlzdAo+ID4+IChjb21taXQg ZGIxNjg5YWE2MWJkIGluIGRybS1uZXh0KS4gUHJpbnRpbmcgYSBoZXggcmVwcmVzZW50YXRpb24g b2YKPiA+PiB0aGUgYml0bWFzayB3b3VsZCBiZSBmdW5jdGlvbmFsIGJ1dCBJIGNvbmNlZGUgbm90 IHZlcnkgcHJldHR5Lgo+ID4KPiA+IFNvIHRoaXMgcGF0Y2ggbGltaXRzIHRoZSBudW1iZXIgb2Yg Zm9ybWF0cyB0byA2NCAoYmVpbmcgdGhlIHNpemUgb2YKPiA+IHRoZSBiaXQgbWFzaykuCj4gCj4g SXQncyBub3QgbGltaXRlZCB0byA2NCBmb3JtYXRzLiBSaWdodCBub3cgbm8gRFJNIGRyaXZlcnMg c3VwcG9ydCBtb3JlCj4gdGhhbiA2NCBmb3JtYXRzLCBidXQgd2hlbiB0aGV5IGRvLCB0aGUgIm9m ZnNldCIgZmllbGQgaW4gc3RydWN0Cj4gZHJtX2Zvcm1hdF9tb2RpZmllciBjYW4gYmUgc2V0IHRv IDY0IGFuZCB0aGVuIHRoZSBiaXQgbWFzayByZXByZXNlbnRzCj4gZm9ybWF0cyA2NSB0aHJvdWdo IDEyOCAoc2VlIHRoZSBjb21tZW50IG9uIHRoYXQgc3RydWN0KToKPiAKPiAgICogSWYgdGhlIG51 bWJlciBmb3JtYXRzIGdyZXcgdG8gMTI4LCBhbmQgZm9ybWF0cyA5OC0xMDIgYXJlCj4gICAqIHN1 cHBvcnRlZCB3aXRoIHRoZSBtb2RpZmllcjoKPiAgICoKPiAgICogMHgwMDAwMDAzYzAwMDAwMDAw IDAwMDAwMDAwMDAwMDAwMDAKPiAgICogICAgICAgICAgICAgICAgICBeCj4gICAqICAgICAgICAg ICAgICAgICAgfF9fb2Zmc2V0ID0gNjQsIGZvcm1hdHMgPSAweDNjMDAwMDAwMDAKPiAKPiA+IEkg d2FzIGhvcGluZyB0aGVzZSBtb2RpZmllcnMgYXBwbGllZCB0byBhbGwgZm9ybWF0cywKPiA+IGJ1 dCB1bmZvcnR1bmF0ZWx5IHRoYXQgaXNuJ3QgdGhlIGNhc2UgYXBwYXJlbnRseS4KPiAKPiBZZWFo LCBpZiBvbmx5IGl0IHdlcmUgc28gc2ltcGxlIDotKQo+IAo+ID4gSG93IGl0IHdvdWxkIHdvcmsg d2l0aCBteSBwcm9wb3NhbCBpcyB0aGF0IHRoZSBpbnRlZ2VyIG1lbnUgY29udHJvbAo+ID4gd291 bGQgcmVmbGVjdCB0aGUgbGlzdCBvZiBzdXBwb3J0ZWQgbW9kaWZpZXJzIGZvciB0aGUgY3VycmVu dGx5IHNlbGVjdGVkCj4gPiBmb3JtYXQuIElmIHlvdSBjaGFuZ2UgZm9ybWF0LCB0aGVuIHRoZSBh dmFpbGFibGUgbW9kaWZpZXIgbGlzdCBjaGFuZ2VzCj4gPiBhcyB3ZWxsLgo+IAo+IEFoIHllcywg SSBuZWVkIHRvIGdldCB1c2VkIHRvIHRoaW5raW5nIGFib3V0IHN0YXRlZnVsIEFQSXMgLSB0aGF0 Cj4gd29ya3MuCgpObywgeW91IGRvbid0LCB3ZSBuZWVkIHRvIG1ha2UgZW51bWVyYXRpb24gc3Rh dGVsZXNzIDotKQoKPiA+IFRoZSBhZHZhbnRhZ2UgaXMgdGhhdCB0aGVyZSBpcyBubyAnNjQgZm9y bWF0cycgbGltaXRhdGlvbiwKPiA+IHNvbWV0aGluZyB0aGF0IEkgZmVlbCB2ZXJ5IHVuY29tZm9y dGFibGUgYWJvdXQgc2luY2Ugc29tZSBkZXZpY2VzIHN1cHBvcnQKPiA+IGEgKmxvdCogb2YgZm9y bWF0cy4gVGhlIGRpc2FkdmFudGFnZSBpcyB0aGF0IGl0IGlzIGhhcmRlciB0byBnZXQgYSBxdWlj awo+ID4gb3ZlcnZpZXcgb2YgYWxsIGNvbWJpbmF0aW9ucyBmb3IgZm9ybWF0cyBhbmQgbW9kaWZp ZXJzLgo+ID4KPiA+IFRoaXMgaGFzIG1vcmUgdG8gZG8gd2l0aCBsaW1pdGF0aW9ucyBpbiB0aGUg VjRMMiBBUEkgdGhhbiB3aXRoIHN1cHBvcnRpbmcKPiA+IG1vZGlmaWVycyBpbiBnZW5lcmFsLiBX ZSBuZWVkIHNvbWV0aGluZyBiZXR0ZXIgdG8gZ2l2ZSB1c2Vyc3BhY2UgYSBxdWljawo+ID4gb3Zl cnZpZXcgb2YgYWxsIGNvbWJpbmF0aW9ucyBvZiBwaXhlbGZvcm1hdHMsIGZyYW1lc2l6ZXMsIGZy YW1laW50ZXJ2YWxzCj4gPiBhbmQgbm93IG1vZGlmaWVycy4gSG93ZXZlciwgdGhhdCdzIG91ciBw cm9ibGVtIDotKQoKLS0gClJlZ2FyZHMsCgpMYXVyZW50IFBpbmNoYXJ0CgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0 CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3Rv cC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from galahad.ideasonboard.com ([185.26.127.97]:38519 "EHLO galahad.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751011AbdHaOgL (ORCPT ); Thu, 31 Aug 2017 10:36:11 -0400 From: Laurent Pinchart To: Brian Starkey Cc: Hans Verkuil , dri-devel , jonathan.chai@arm.com, "linux-media@vger.kernel.org" Subject: Re: DRM Format Modifiers in v4l2 Date: Thu, 31 Aug 2017 17:36:43 +0300 Message-ID: <7090676.9SSa8TzciT@avalon> In-Reply-To: <20170829091943.GA26907@e107564-lin.cambridge.arm.com> References: <20170821155203.GB38943@e107564-lin.cambridge.arm.com> <20170829091943.GA26907@e107564-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-media-owner@vger.kernel.org List-ID: Hi Brian, On Tuesday, 29 August 2017 12:19:43 EEST Brian Starkey wrote: > On Fri, Aug 25, 2017 at 10:14:03AM +0200, Hans Verkuil wrote: > >On 24/08/17 14:26, Brian Starkey wrote: > >> On Thu, Aug 24, 2017 at 01:37:35PM +0200, Hans Verkuil wrote: > >>> On 08/24/17 13:14, Brian Starkey wrote: > >>>> On Mon, Aug 21, 2017 at 06:36:29PM +0200, Hans Verkuil wrote: > >>>>> On 08/21/2017 06:01 PM, Daniel Vetter wrote: > >>>>>> On Mon, Aug 21, 2017 at 5:52 PM, Brian Starkey wrote: > >>>>>>> Hi all, > >>>>>>> > >>>>>>> I couldn't find this topic talked about elsewhere, but apologies if > >>>>>>> it's a duplicate - I'll be glad to be steered in the direction of a > >>>>>>> thread. > >>>>>>> > >>>>>>> We'd like to support DRM format modifiers in v4l2 in order to share > >>>>>>> the description of different (mostly proprietary) buffer formats > >>>>>>> between e.g. a v4l2 device and a DRM device. > >>>>>>> > >>>>>>> DRM format modifiers are defined in include/uapi/drm/drm_fourcc.h > >>>>>>> and are a vendor-namespaced 64-bit value used to describe various > >>>>>>> vendor-specific buffer layouts. They are combined with a (DRM) > >>>>>>> FourCC code to give a complete description of the data contained in > >>>>>>> a buffer. > >>>>>>> > >>>>>>> The same modifier definition is used in the Khronos EGL extension > >>>>>>> EGL_EXT_image_dma_buf_import_modifiers, and is supported in the > >>>>>>> Wayland linux-dmabuf protocol. > >>>>>>> > >>>>>>> > >>>>>>> This buffer information could of course be described in the > >>>>>>> vendor-specific part of V4L2_PIX_FMT_*, but this would duplicate the > >>>>>>> information already defined in drm_fourcc.h. Additionally, there > >>>>>>> would be quite a format explosion where a device supports a dozen or > >>>>>>> more formats, all of which can use one or more different > >>>>>>> layouts/compression schemes. > >>>>>>> > >>>>>>> So, I'm wondering if anyone has views on how/whether this could be > >>>>>>> incorporated? > >>>>>>> > >>>>>>> I spoke briefly about this to Laurent at LPC last year, and he > >>>>>>> suggested v4l2_control as one approach. > >>>>>>> > >>>>>>> I also wondered if could be added in v4l2_pix_format_mplane - looks > >>>>>>> like there's 8 bytes left before it exceeds the 200 bytes, or could > >>>>>>> go in the reserved portion of v4l2_plane_pix_format. > >>>>>>> > >>>>>>> Thanks for any thoughts, > >>>>>> > >>>>>> One problem is that the modifers sometimes reference the DRM fourcc > >>>>>> codes. v4l has a different (and incompatible set) of fourcc codes, > >>>>>> whereas all the protocols and specs (you can add DRI3.1 for Xorg to > >>>>>> that list btw) use both drm fourcc and drm modifiers. > >>>>>> > >>>>>> This might or might not make this proposal unworkable, but it's > >>>>>> something I'd at least review carefully. > >>>>>> > >>>>>> Otherwise I think it'd be great if we could have one namespace for > >>>>>> all modifiers, that's pretty much why we have them. Please also note > >>>>>> that for drm_fourcc.h we don't require an in-kernel user for a new > >>>>>> modifier since a bunch of them might need to be allocated just for > >>>>>> userspace-to-userspace buffer sharing (e.g. in EGL/vk). One example > >>>>>> for this would be compressed surfaces with fast-clearing, which is > >>>>>> planned for i915 (but current hw can't scan it out). And we really > >>>>>> want to have one namespace for everything. > >>>>> > >>>>> Who sets these modifiers? Kernel or userspace? Or can it be set by > >>>>> both? I assume any userspace code that sets/reads this is code > >>>>> specific for that hardware? > >>>> > >>>> I think normally the modifier would be set by userspace. However it > >>>> might not necessarily be device-specific code. In DRM the intention is > >>>> for userspace to query the set of modifiers which are supported, and > >>>> then use them without necessarily knowing exactly what they mean > >>>> (insofar as that is possible). > >>>> > >>>> e.g. if I have two devices which support MODIFIER_FOO, I could attempt > >>>> to share a buffer between them which uses MODIFIER_FOO without > >>>> necessarily knowing exactly what it is/does. > >>>> > >>>>> I think Laurent's suggestion of using a 64 bit V4L2 control for this > >>>>> makes the most sense. > >>>>> > >>>>> Especially if you can assume that whoever sets this knows the > >>>>> hardware. > >>>>> > >>>>> I think this only makes sense if you pass buffers from one HW device > >>>>> to another. > >>>>> > >>>>> Because you cannot expect generic video capture code to be able to > >>>>> interpret all the zillion different combinations of modifiers. > >>>> > >>>> I don't quite follow this last bit. The control could report the set > >>>> of supported modifiers. > >>> > >>> What I mean was: an application can use the modifier to give buffers > >>> from one device to another without needing to understand it. > >>> > >>> But a generic video capture application that processes the video itself > >>> cannot be expected to know about the modifiers. It's a custom HW > >>> specific format that you only use between two HW devices or with > >>> software written for that hardware. > >> > >> Yes, makes sense. > >> > >>>> However, in DRM the API lets you get the supported formats for each > >>>> modifier as-well-as the modifier list itself. I'm not sure how exactly > >>>> to provide that in a control. > >>> > >>> We have support for a 'menu' of 64 bit integers: > >>> V4L2_CTRL_TYPE_INTEGER_MENU. You use VIDIOC_QUERYMENU to enumerate the > >>> available modifiers. > >>> > >>> So enumerating these modifiers would work out-of-the-box. > >> > >> Right. So I guess the supported set of formats could be somehow > >> enumerated in the menu item string. In DRM the pairs are (modifier + > >> bitmask) where bits represent formats in the supported formats list > >> (commit db1689aa61bd in drm-next). Printing a hex representation of > >> the bitmask would be functional but I concede not very pretty. > > > > So this patch limits the number of formats to 64 (being the size of > > the bit mask). > > It's not limited to 64 formats. Right now no DRM drivers support more > than 64 formats, but when they do, the "offset" field in struct > drm_format_modifier can be set to 64 and then the bit mask represents > formats 65 through 128 (see the comment on that struct): > > * If the number formats grew to 128, and formats 98-102 are > * supported with the modifier: > * > * 0x0000003c00000000 0000000000000000 > * ^ > * |__offset = 64, formats = 0x3c00000000 > > > I was hoping these modifiers applied to all formats, > > but unfortunately that isn't the case apparently. > > Yeah, if only it were so simple :-) > > > How it would work with my proposal is that the integer menu control > > would reflect the list of supported modifiers for the currently selected > > format. If you change format, then the available modifier list changes > > as well. > > Ah yes, I need to get used to thinking about stateful APIs - that > works. No, you don't, we need to make enumeration stateless :-) > > The advantage is that there is no '64 formats' limitation, > > something that I feel very uncomfortable about since some devices support > > a *lot* of formats. The disadvantage is that it is harder to get a quick > > overview of all combinations for formats and modifiers. > > > > This has more to do with limitations in the V4L2 API than with supporting > > modifiers in general. We need something better to give userspace a quick > > overview of all combinations of pixelformats, framesizes, frameintervals > > and now modifiers. However, that's our problem :-) -- Regards, Laurent Pinchart