From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f65.google.com ([74.125.82.65]:54121 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754337AbeFTJRy (ORCPT ); Wed, 20 Jun 2018 05:17:54 -0400 Received: by mail-wm0-f65.google.com with SMTP id x6-v6so4770658wmc.3 for ; Wed, 20 Jun 2018 02:17:53 -0700 (PDT) Date: Wed, 20 Jun 2018 11:17:50 +0200 From: Daniel Vetter To: Russell King - ARM Linux Cc: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , Thomas Hellstrom , Laurent Pinchart , Neil Armstrong , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Alexandru Gheorghe , linux-renesas-soc@vger.kernel.org, linux-tegra@vger.kernel.org, Thierry Reding , Ben Skeggs , Rodrigo Vivi , Dmitry Osipenko , Maxime Ripard , linux-media@vger.kernel.org Subject: Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties Message-ID: <20180620091750.GD7186@phenom.ffwll.local> References: <20180526155623.12610-1-digetx@gmail.com> <20180526155623.12610-2-digetx@gmail.com> <20180528131501.GK23723@intel.com> <20180529071103.GL23723@intel.com> <20180619174011.GJ17671@n2100.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180619174011.GJ17671@n2100.armlinux.org.uk> Sender: linux-renesas-soc-owner@vger.kernel.org List-ID: On Tue, Jun 19, 2018 at 06:40:12PM +0100, Russell King - ARM Linux wrote: > On Tue, May 29, 2018 at 10:11:03AM +0300, Ville Syrj�l� wrote: > > On Tue, May 29, 2018 at 02:48:22AM +0300, Dmitry Osipenko wrote: > > > Though maybe "color components replacement" and "replacement with a complete > > > transparency" could be factored out into a specific color keying modes. > > > > Yes. I've never seen those in any hardware. In fact I'm wondering where > > is the userspace for all these complex modes? Ie. should we even bother > > with them at this time? > > Such hardware does exist - here's what Armada 510 supports (and is > supported via armada-drm): > > Color Key Mode > 0 = Disable: Disable color key function. > 1 = EnableY: Video Y color key is enabled. > 2 = EnableU: Video U color key is enabled. > 3 = EnableRGB: Graphic RGB color key is enabled. > 4 = EnableV: Video V color key is enabled. > 5 = EnableR: Graphic R color key is enabled. > 6 = EnableG: Graphic G color key is enabled. > 7 = EnableB: Graphic B color key is enabled. > > The description of how the colour keying works isn't particularly good, > which is rather unfortunate, but basically, there's three 32-bit > registers named LCD_SPU_COLORKEY_Y, LCD_SPU_COLORKEY_U and > LCD_SPU_COLORKEY_V. > > When a graphic mode is selected, then: > LCD_SPU_COLORKEY_Y is the R or B component depending on the red/blue swap > LCD_SPU_COLORKEY_U is the G component > LCD_SPU_COLORKEY_V is the B or R component according to the swap > > 31:24 is the high bound for the component (inclusive) > 23:16 is the low bound for the component (inclusive) > 15:8 is the replacement value for the component > 7:0 is the alpha value - seems to only be for LCD_SPU_COLORKEY_Y and > ignored in the other registers when in RGB mode, but I've not > fully tested this. I suspect it's used with the single-channel > colour keying modes. > > The colour key stage provides an alpha value to the next stage - which > is alpha blending between the graphic (primary) plane and video > (overlay) plane. Zero gives overlay only, 255 gives graphic only. > > So, it's possible to use an 0x0101fe (RGB) colour key, and have it > appear as "black" on the screen if you disable the overlay plane, > rather than the unsightly bright blue. > > One point to make though is about what userspace expects _today_ from > overlay. VLC, for example, expects overlay to be colour keyed, so it > can display its full-screen controller when the user moves the mouse. > I don't believe it explicitly sets up colour keying, but just expects > it to be there and functional. It _is_ rather necessary when you > consider that overlay via the Xvideo extension is supposed to be > "drawn" into the specified drawable, which may be a mapped window > partially obscured by other mapped windows. > > Maybe if the kernel DRM components doesn't want to do that, it'd be > something that an Xorg DDX would have to default-enable to ensure > that existing applications and expected Xorg behaviour doesn't break. Yes -modesetting (or whichever other driver) would need to set up the properties correctly for Xvideo color keying. Since default assumption for all other (generic) compositors is that planes won't do any color keying in the boot-up state. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties Date: Wed, 20 Jun 2018 11:17:50 +0200 Message-ID: <20180620091750.GD7186@phenom.ffwll.local> References: <20180526155623.12610-1-digetx@gmail.com> <20180526155623.12610-2-digetx@gmail.com> <20180528131501.GK23723@intel.com> <20180529071103.GL23723@intel.com> <20180619174011.GJ17671@n2100.armlinux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <20180619174011.GJ17671@n2100.armlinux.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Russell King - ARM Linux Cc: Thomas Hellstrom , Laurent Pinchart , Neil Armstrong , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org, Maxime Ripard , Thierry Reding , Ben Skeggs , Rodrigo Vivi , linux-tegra@vger.kernel.org, Dmitry Osipenko , Alexandru Gheorghe , linux-media@vger.kernel.org List-Id: linux-tegra@vger.kernel.org T24gVHVlLCBKdW4gMTksIDIwMTggYXQgMDY6NDA6MTJQTSArMDEwMCwgUnVzc2VsbCBLaW5nIC0g QVJNIExpbnV4IHdyb3RlOgo+IE9uIFR1ZSwgTWF5IDI5LCAyMDE4IGF0IDEwOjExOjAzQU0gKzAz MDAsIFZpbGxlIFN5cmrDpGzDpCB3cm90ZToKPiA+IE9uIFR1ZSwgTWF5IDI5LCAyMDE4IGF0IDAy OjQ4OjIyQU0gKzAzMDAsIERtaXRyeSBPc2lwZW5rbyB3cm90ZToKPiA+ID4gVGhvdWdoIG1heWJl ICJjb2xvciBjb21wb25lbnRzIHJlcGxhY2VtZW50IiBhbmQgInJlcGxhY2VtZW50IHdpdGggYSBj b21wbGV0ZQo+ID4gPiB0cmFuc3BhcmVuY3kiIGNvdWxkIGJlIGZhY3RvcmVkIG91dCBpbnRvIGEg c3BlY2lmaWMgY29sb3Iga2V5aW5nIG1vZGVzLgo+ID4gCj4gPiBZZXMuIEkndmUgbmV2ZXIgc2Vl biB0aG9zZSBpbiBhbnkgaGFyZHdhcmUuIEluIGZhY3QgSSdtIHdvbmRlcmluZyB3aGVyZQo+ID4g aXMgdGhlIHVzZXJzcGFjZSBmb3IgYWxsIHRoZXNlIGNvbXBsZXggbW9kZXM/IEllLiBzaG91bGQg d2UgZXZlbiBib3RoZXIKPiA+IHdpdGggdGhlbSBhdCB0aGlzIHRpbWU/Cj4gCj4gU3VjaCBoYXJk d2FyZSBkb2VzIGV4aXN0IC0gaGVyZSdzIHdoYXQgQXJtYWRhIDUxMCBzdXBwb3J0cyAoYW5kIGlz Cj4gc3VwcG9ydGVkIHZpYSBhcm1hZGEtZHJtKToKPiAKPiBDb2xvciBLZXkgTW9kZQo+IDAgPSBE aXNhYmxlOiBEaXNhYmxlIGNvbG9yIGtleSBmdW5jdGlvbi4KPiAxID0gRW5hYmxlWTogVmlkZW8g WSBjb2xvciBrZXkgaXMgZW5hYmxlZC4KPiAyID0gRW5hYmxlVTogVmlkZW8gVSBjb2xvciBrZXkg aXMgZW5hYmxlZC4KPiAzID0gRW5hYmxlUkdCOiBHcmFwaGljIFJHQiBjb2xvciBrZXkgaXMgZW5h YmxlZC4KPiA0ID0gRW5hYmxlVjogVmlkZW8gViBjb2xvciBrZXkgaXMgZW5hYmxlZC4KPiA1ID0g RW5hYmxlUjogR3JhcGhpYyBSIGNvbG9yIGtleSBpcyBlbmFibGVkLgo+IDYgPSBFbmFibGVHOiBH cmFwaGljIEcgY29sb3Iga2V5IGlzIGVuYWJsZWQuCj4gNyA9IEVuYWJsZUI6IEdyYXBoaWMgQiBj b2xvciBrZXkgaXMgZW5hYmxlZC4KPiAKPiBUaGUgZGVzY3JpcHRpb24gb2YgaG93IHRoZSBjb2xv dXIga2V5aW5nIHdvcmtzIGlzbid0IHBhcnRpY3VsYXJseSBnb29kLAo+IHdoaWNoIGlzIHJhdGhl ciB1bmZvcnR1bmF0ZSwgYnV0IGJhc2ljYWxseSwgdGhlcmUncyB0aHJlZSAzMi1iaXQKPiByZWdp c3RlcnMgbmFtZWQgTENEX1NQVV9DT0xPUktFWV9ZLCBMQ0RfU1BVX0NPTE9SS0VZX1UgYW5kCj4g TENEX1NQVV9DT0xPUktFWV9WLgo+IAo+IFdoZW4gYSBncmFwaGljIG1vZGUgaXMgc2VsZWN0ZWQs IHRoZW46Cj4gIExDRF9TUFVfQ09MT1JLRVlfWSBpcyB0aGUgUiBvciBCIGNvbXBvbmVudCBkZXBl bmRpbmcgb24gdGhlIHJlZC9ibHVlIHN3YXAKPiAgTENEX1NQVV9DT0xPUktFWV9VIGlzIHRoZSBH IGNvbXBvbmVudAo+ICBMQ0RfU1BVX0NPTE9SS0VZX1YgaXMgdGhlIEIgb3IgUiBjb21wb25lbnQg YWNjb3JkaW5nIHRvIHRoZSBzd2FwCj4gCj4gMzE6MjQgaXMgdGhlIGhpZ2ggYm91bmQgZm9yIHRo ZSBjb21wb25lbnQgKGluY2x1c2l2ZSkKPiAyMzoxNiBpcyB0aGUgbG93IGJvdW5kIGZvciB0aGUg Y29tcG9uZW50IChpbmNsdXNpdmUpCj4gMTU6OCAgaXMgdGhlIHJlcGxhY2VtZW50IHZhbHVlIGZv ciB0aGUgY29tcG9uZW50Cj4gIDc6MCAgaXMgdGhlIGFscGhhIHZhbHVlIC0gc2VlbXMgdG8gb25s eSBiZSBmb3IgTENEX1NQVV9DT0xPUktFWV9ZIGFuZAo+IAlpZ25vcmVkIGluIHRoZSBvdGhlciBy ZWdpc3RlcnMgd2hlbiBpbiBSR0IgbW9kZSwgYnV0IEkndmUgbm90Cj4gCWZ1bGx5IHRlc3RlZCB0 aGlzLiAgSSBzdXNwZWN0IGl0J3MgdXNlZCB3aXRoIHRoZSBzaW5nbGUtY2hhbm5lbAo+IAljb2xv dXIga2V5aW5nIG1vZGVzLgo+IAo+IFRoZSBjb2xvdXIga2V5IHN0YWdlIHByb3ZpZGVzIGFuIGFs cGhhIHZhbHVlIHRvIHRoZSBuZXh0IHN0YWdlIC0gd2hpY2gKPiBpcyBhbHBoYSBibGVuZGluZyBi ZXR3ZWVuIHRoZSBncmFwaGljIChwcmltYXJ5KSBwbGFuZSBhbmQgdmlkZW8KPiAob3ZlcmxheSkg cGxhbmUuICBaZXJvIGdpdmVzIG92ZXJsYXkgb25seSwgMjU1IGdpdmVzIGdyYXBoaWMgb25seS4K PiAKPiBTbywgaXQncyBwb3NzaWJsZSB0byB1c2UgYW4gMHgwMTAxZmUgKFJHQikgY29sb3VyIGtl eSwgYW5kIGhhdmUgaXQKPiBhcHBlYXIgYXMgImJsYWNrIiBvbiB0aGUgc2NyZWVuIGlmIHlvdSBk aXNhYmxlIHRoZSBvdmVybGF5IHBsYW5lLAo+IHJhdGhlciB0aGFuIHRoZSB1bnNpZ2h0bHkgYnJp Z2h0IGJsdWUuCj4gCj4gT25lIHBvaW50IHRvIG1ha2UgdGhvdWdoIGlzIGFib3V0IHdoYXQgdXNl cnNwYWNlIGV4cGVjdHMgX3RvZGF5XyBmcm9tCj4gb3ZlcmxheS4gIFZMQywgZm9yIGV4YW1wbGUs IGV4cGVjdHMgb3ZlcmxheSB0byBiZSBjb2xvdXIga2V5ZWQsIHNvIGl0Cj4gY2FuIGRpc3BsYXkg aXRzIGZ1bGwtc2NyZWVuIGNvbnRyb2xsZXIgd2hlbiB0aGUgdXNlciBtb3ZlcyB0aGUgbW91c2Uu Cj4gSSBkb24ndCBiZWxpZXZlIGl0IGV4cGxpY2l0bHkgc2V0cyB1cCBjb2xvdXIga2V5aW5nLCBi dXQganVzdCBleHBlY3RzCj4gaXQgdG8gYmUgdGhlcmUgYW5kIGZ1bmN0aW9uYWwuICBJdCBfaXNf IHJhdGhlciBuZWNlc3Nhcnkgd2hlbiB5b3UKPiBjb25zaWRlciB0aGF0IG92ZXJsYXkgdmlhIHRo ZSBYdmlkZW8gZXh0ZW5zaW9uIGlzIHN1cHBvc2VkIHRvIGJlCj4gImRyYXduIiBpbnRvIHRoZSBz cGVjaWZpZWQgZHJhd2FibGUsIHdoaWNoIG1heSBiZSBhIG1hcHBlZCB3aW5kb3cKPiBwYXJ0aWFs bHkgb2JzY3VyZWQgYnkgb3RoZXIgbWFwcGVkIHdpbmRvd3MuCj4gCj4gTWF5YmUgaWYgdGhlIGtl cm5lbCBEUk0gY29tcG9uZW50cyBkb2Vzbid0IHdhbnQgdG8gZG8gdGhhdCwgaXQnZCBiZQo+IHNv bWV0aGluZyB0aGF0IGFuIFhvcmcgRERYIHdvdWxkIGhhdmUgdG8gZGVmYXVsdC1lbmFibGUgdG8g ZW5zdXJlCj4gdGhhdCBleGlzdGluZyBhcHBsaWNhdGlvbnMgYW5kIGV4cGVjdGVkIFhvcmcgYmVo YXZpb3VyIGRvZXNuJ3QgYnJlYWsuCgpZZXMgLW1vZGVzZXR0aW5nIChvciB3aGljaGV2ZXIgb3Ro ZXIgZHJpdmVyKSB3b3VsZCBuZWVkIHRvIHNldCB1cCB0aGUKcHJvcGVydGllcyBjb3JyZWN0bHkg Zm9yIFh2aWRlbyBjb2xvciBrZXlpbmcuIFNpbmNlIGRlZmF1bHQgYXNzdW1wdGlvbiBmb3IKYWxs IG90aGVyIChnZW5lcmljKSBjb21wb3NpdG9ycyBpcyB0aGF0IHBsYW5lcyB3b24ndCBkbyBhbnkg Y29sb3Iga2V5aW5nCmluIHRoZSBib290LXVwIHN0YXRlLgotRGFuaWVsCi0tIApEYW5pZWwgVmV0 dGVyClNvZnR3YXJlIEVuZ2luZWVyLCBJbnRlbCBDb3Jwb3JhdGlvbgpodHRwOi8vYmxvZy5mZnds bC5jaApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmkt ZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6 Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-wm0-f66.google.com ([74.125.82.66]:55488 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754345AbeFTJRy (ORCPT ); Wed, 20 Jun 2018 05:17:54 -0400 Received: by mail-wm0-f66.google.com with SMTP id v16-v6so4772174wmh.5 for ; Wed, 20 Jun 2018 02:17:53 -0700 (PDT) Date: Wed, 20 Jun 2018 11:17:50 +0200 From: Daniel Vetter To: Russell King - ARM Linux Cc: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , Thomas Hellstrom , Laurent Pinchart , Neil Armstrong , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Alexandru Gheorghe , linux-renesas-soc@vger.kernel.org, linux-tegra@vger.kernel.org, Thierry Reding , Ben Skeggs , Rodrigo Vivi , Dmitry Osipenko , Maxime Ripard , linux-media@vger.kernel.org Subject: Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties Message-ID: <20180620091750.GD7186@phenom.ffwll.local> References: <20180526155623.12610-1-digetx@gmail.com> <20180526155623.12610-2-digetx@gmail.com> <20180528131501.GK23723@intel.com> <20180529071103.GL23723@intel.com> <20180619174011.GJ17671@n2100.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180619174011.GJ17671@n2100.armlinux.org.uk> Sender: linux-media-owner@vger.kernel.org List-ID: On Tue, Jun 19, 2018 at 06:40:12PM +0100, Russell King - ARM Linux wrote: > On Tue, May 29, 2018 at 10:11:03AM +0300, Ville Syrjälä wrote: > > On Tue, May 29, 2018 at 02:48:22AM +0300, Dmitry Osipenko wrote: > > > Though maybe "color components replacement" and "replacement with a complete > > > transparency" could be factored out into a specific color keying modes. > > > > Yes. I've never seen those in any hardware. In fact I'm wondering where > > is the userspace for all these complex modes? Ie. should we even bother > > with them at this time? > > Such hardware does exist - here's what Armada 510 supports (and is > supported via armada-drm): > > Color Key Mode > 0 = Disable: Disable color key function. > 1 = EnableY: Video Y color key is enabled. > 2 = EnableU: Video U color key is enabled. > 3 = EnableRGB: Graphic RGB color key is enabled. > 4 = EnableV: Video V color key is enabled. > 5 = EnableR: Graphic R color key is enabled. > 6 = EnableG: Graphic G color key is enabled. > 7 = EnableB: Graphic B color key is enabled. > > The description of how the colour keying works isn't particularly good, > which is rather unfortunate, but basically, there's three 32-bit > registers named LCD_SPU_COLORKEY_Y, LCD_SPU_COLORKEY_U and > LCD_SPU_COLORKEY_V. > > When a graphic mode is selected, then: > LCD_SPU_COLORKEY_Y is the R or B component depending on the red/blue swap > LCD_SPU_COLORKEY_U is the G component > LCD_SPU_COLORKEY_V is the B or R component according to the swap > > 31:24 is the high bound for the component (inclusive) > 23:16 is the low bound for the component (inclusive) > 15:8 is the replacement value for the component > 7:0 is the alpha value - seems to only be for LCD_SPU_COLORKEY_Y and > ignored in the other registers when in RGB mode, but I've not > fully tested this. I suspect it's used with the single-channel > colour keying modes. > > The colour key stage provides an alpha value to the next stage - which > is alpha blending between the graphic (primary) plane and video > (overlay) plane. Zero gives overlay only, 255 gives graphic only. > > So, it's possible to use an 0x0101fe (RGB) colour key, and have it > appear as "black" on the screen if you disable the overlay plane, > rather than the unsightly bright blue. > > One point to make though is about what userspace expects _today_ from > overlay. VLC, for example, expects overlay to be colour keyed, so it > can display its full-screen controller when the user moves the mouse. > I don't believe it explicitly sets up colour keying, but just expects > it to be there and functional. It _is_ rather necessary when you > consider that overlay via the Xvideo extension is supposed to be > "drawn" into the specified drawable, which may be a mapped window > partially obscured by other mapped windows. > > Maybe if the kernel DRM components doesn't want to do that, it'd be > something that an Xorg DDX would have to default-enable to ensure > that existing applications and expected Xorg behaviour doesn't break. Yes -modesetting (or whichever other driver) would need to set up the properties correctly for Xvideo color keying. Since default assumption for all other (generic) compositors is that planes won't do any color keying in the boot-up state. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch