From mboxrd@z Thu Jan 1 00:00:00 1970 From: laurent.pinchart@ideasonboard.com (Laurent Pinchart) Date: Thu, 11 Jan 2018 20:34:58 +0200 Subject: [PATCH 06/19] drm/blend: Add a generic alpha property In-Reply-To: References: <20180111155857.bbfp4772fx56s5k3@flea.lan> Message-ID: <7937877.87F3UCTWB7@avalon> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Daniel, On Thursday, 11 January 2018 18:36:10 EET Daniel Vetter wrote: > On Thu, Jan 11, 2018 at 4:58 PM, Maxime Ripard wrote: > > On Tue, Jan 09, 2018 at 03:28:34PM +0100, Daniel Vetter wrote: > >> On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote: > >>> On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote: > >>>> On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote: > >>>>> Some drivers duplicate the logic to create a property to store a > >>>>> per-plane alpha. > >>>>> > >>>>> Let's create a helper in order to move that to the core. > >>>>> > >>>>> Cc: Boris Brezillon > >>>>> Cc: Laurent Pinchart > >>>>> Signed-off-by: Maxime Ripard > >>>> > >>>> Do we have userspace for this? > >>> > >>> Wayland seems to be on its way to implement this, with ChromeOS using > >>> it: > >>> https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741 > >>> .html > >>> > >>> and more specifically: > >>> https://chromium.googlesource.com/chromium/src/+/master/third_party/way > >>> land-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1 > >>> .xml#118 > >> > >> Yay, would be good to include these links in the patch description. > >> Really happy we're having a real standard now used by multiple people. > > > > I will. > > > >> > > Is encoding a fixed 0-255 range really the best idea? > >> > > >> > I don't really know, is there hardware or formats where there is more > >> > than 255? Or did you mean less than that? > >> > >> 30bit I'd assume wants more alpha. In the past we've done some > >> fixed-point stuff (e.g. for LUT), using the 0.0-1.0 float range. Using > >> that for the blend equation docs is also what I recommend (and that we > >> map from 0-255 to 0.0-1.0 logically). Ofc the hw might not do any of that > >> ... I think 0.16 fixed point, stored in a u16 is probably best. That's > >> what we're doing for gamma tables already, and that way drivers can > >> simply throw away the lower bits. > > > > But that would also break the two users of that property that won't be > > able to move to the generic property (with the same name) without > > breaking userspace. The point of that patch was to allow some code > > consolidation, and that would mean failing to do so here :/ > > Let me try to clarify: > - We'll keep the exact existing property semantics with the 0-255 > range for the userspace visible property. > > - But internally, in the decode value that we store into > drm_plane_state, we'll do the slightly more future proof thing with a > few more bits. > > That gives us the option of exposing those bits in the future without > having to change all the drivers again (which we have to do for this > series here already anyway, since the decoded value moves into > drm_plane_state from driver subclasses). > > Definitely not asking to break userspace here :-) As the property range is available to userspace, we could allow drivers to expose a driver-dependent number of bits for the alpha value without breaking anything. We can even require new drivers to expose 16 bits regardless of the number of bits that the hardware can handle, or we could keep that driver- specific. Please note, however, that U0.16 can only represent [0.0, 0.999984741...] while we need [0.0, 1.0]. As all the hardware I know map the full range of values ([0, 255] for 8-bit for instance) to [0.0, 1.0] I wouldn't pretend that the 16-bit value exposed to userspace is U0.16. > >>>> I know other drivers have skimped on the rules here a bit ... But at > >>>> least internally (i.e. within the drm_plane_state) we probably should > >>>> restrict ourselves to u8. And this needs real docs (i.e. the full blend > >>>> equation drivers are supposed to implement). > >>> > >>> You mean straight vs premultiplied? Maybe we should implement this as > >>> an additional property in read only depending on how the hardware > >>> behaves? > >> > >> No need for an additional property right now, but definitely document > >> whether you mean straight or pre-multiplied. Just writing down the blend > >> equation is probably best. -- Regards, Laurent Pinchart From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Subject: Re: [PATCH 06/19] drm/blend: Add a generic alpha property Date: Thu, 11 Jan 2018 20:34:58 +0200 Message-ID: <7937877.87F3UCTWB7@avalon> References: <20180111155857.bbfp4772fx56s5k3@flea.lan> 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 CBA016E671 for ; Thu, 11 Jan 2018 18:34:27 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Vetter Cc: Thomas Petazzoni , Boris Brezillon , Linux Kernel Mailing List , Chen-Yu Tsai , dri-devel , Daniel Vetter , Maxime Ripard , Linux ARM , thomas@vitsch.nl List-Id: dri-devel@lists.freedesktop.org SGkgRGFuaWVsLAoKT24gVGh1cnNkYXksIDExIEphbnVhcnkgMjAxOCAxODozNjoxMCBFRVQgRGFu aWVsIFZldHRlciB3cm90ZToKPiBPbiBUaHUsIEphbiAxMSwgMjAxOCBhdCA0OjU4IFBNLCBNYXhp bWUgUmlwYXJkIHdyb3RlOgo+ID4gT24gVHVlLCBKYW4gMDksIDIwMTggYXQgMDM6Mjg6MzRQTSAr MDEwMCwgRGFuaWVsIFZldHRlciB3cm90ZToKPiA+PiBPbiBUdWUsIEphbiAwOSwgMjAxOCBhdCAw Mjo1MzoyMlBNICswMTAwLCBNYXhpbWUgUmlwYXJkIHdyb3RlOgo+ID4+PiBPbiBUdWUsIEphbiAw OSwgMjAxOCBhdCAwMTozMjo0MVBNICswMTAwLCBEYW5pZWwgVmV0dGVyIHdyb3RlOgo+ID4+Pj4g T24gVHVlLCBKYW4gMDksIDIwMTggYXQgMTE6NTY6MjVBTSArMDEwMCwgTWF4aW1lIFJpcGFyZCB3 cm90ZToKPiA+Pj4+PiBTb21lIGRyaXZlcnMgZHVwbGljYXRlIHRoZSBsb2dpYyB0byBjcmVhdGUg YSBwcm9wZXJ0eSB0byBzdG9yZSBhCj4gPj4+Pj4gcGVyLXBsYW5lIGFscGhhLgo+ID4+Pj4+IAo+ ID4+Pj4+IExldCdzIGNyZWF0ZSBhIGhlbHBlciBpbiBvcmRlciB0byBtb3ZlIHRoYXQgdG8gdGhl IGNvcmUuCj4gPj4+Pj4gCj4gPj4+Pj4gQ2M6IEJvcmlzIEJyZXppbGxvbiA8Ym9yaXMuYnJlemls bG9uQGZyZWUtZWxlY3Ryb25zLmNvbT4KPiA+Pj4+PiBDYzogTGF1cmVudCBQaW5jaGFydCA8bGF1 cmVudC5waW5jaGFydEBpZGVhc29uYm9hcmQuY29tPgo+ID4+Pj4+IFNpZ25lZC1vZmYtYnk6IE1h eGltZSBSaXBhcmQgPG1heGltZS5yaXBhcmRAZnJlZS1lbGVjdHJvbnMuY29tPgo+ID4+Pj4gCj4g Pj4+PiBEbyB3ZSBoYXZlIHVzZXJzcGFjZSBmb3IgdGhpcz8KPiA+Pj4gCj4gPj4+IFdheWxhbmQg c2VlbXMgdG8gYmUgb24gaXRzIHdheSB0byBpbXBsZW1lbnQgdGhpcywgd2l0aCBDaHJvbWVPUyB1 c2luZwo+ID4+PiBpdDoKPiA+Pj4gaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvYXJjaGl2 ZXMvd2F5bGFuZC1kZXZlbC8yMDE3LUF1Z3VzdC8wMzQ3NDEKPiA+Pj4gLmh0bWwKPiA+Pj4gCj4g Pj4+IGFuZCBtb3JlIHNwZWNpZmljYWxseToKPiA+Pj4gaHR0cHM6Ly9jaHJvbWl1bS5nb29nbGVz b3VyY2UuY29tL2Nocm9taXVtL3NyYy8rL21hc3Rlci90aGlyZF9wYXJ0eS93YXkKPiA+Pj4gbGFu ZC1wcm90b2NvbHMvdW5zdGFibGUvYWxwaGEtY29tcG9zaXRpbmcvYWxwaGEtY29tcG9zaXRpbmct dW5zdGFibGUtdjEKPiA+Pj4gLnhtbCMxMTgKPiA+PiAKPiA+PiBZYXksIHdvdWxkIGJlIGdvb2Qg dG8gaW5jbHVkZSB0aGVzZSBsaW5rcyBpbiB0aGUgcGF0Y2ggZGVzY3JpcHRpb24uCj4gPj4gUmVh bGx5IGhhcHB5IHdlJ3JlIGhhdmluZyBhIHJlYWwgc3RhbmRhcmQgbm93IHVzZWQgYnkgbXVsdGlw bGUgcGVvcGxlLgo+ID4gCj4gPiBJIHdpbGwuCj4gPiAKPiA+PiA+ID4gSXMgZW5jb2RpbmcgYSBm aXhlZCAwLTI1NSByYW5nZSByZWFsbHkgdGhlIGJlc3QgaWRlYT8KPiA+PiA+IAo+ID4+ID4gSSBk b24ndCByZWFsbHkga25vdywgaXMgdGhlcmUgaGFyZHdhcmUgb3IgZm9ybWF0cyB3aGVyZSB0aGVy ZSBpcyBtb3JlCj4gPj4gPiB0aGFuIDI1NT8gT3IgZGlkIHlvdSBtZWFuIGxlc3MgdGhhbiB0aGF0 Pwo+ID4+IAo+ID4+IDMwYml0IEknZCBhc3N1bWUgd2FudHMgbW9yZSBhbHBoYS4gSW4gdGhlIHBh c3Qgd2UndmUgZG9uZSBzb21lCj4gPj4gZml4ZWQtcG9pbnQgc3R1ZmYgKGUuZy4gZm9yIExVVCks IHVzaW5nIHRoZSAwLjAtMS4wIGZsb2F0IHJhbmdlLiBVc2luZwo+ID4+IHRoYXQgZm9yIHRoZSBi bGVuZCBlcXVhdGlvbiBkb2NzIGlzIGFsc28gd2hhdCBJIHJlY29tbWVuZCAoYW5kIHRoYXQgd2UK PiA+PiBtYXAgZnJvbSAwLTI1NSB0byAwLjAtMS4wIGxvZ2ljYWxseSkuIE9mYyB0aGUgaHcgbWln aHQgbm90IGRvIGFueSBvZiB0aGF0Cj4gPj4gLi4uIEkgdGhpbmsgMC4xNiBmaXhlZCBwb2ludCwg c3RvcmVkIGluIGEgdTE2IGlzIHByb2JhYmx5IGJlc3QuIFRoYXQncwo+ID4+IHdoYXQgd2UncmUg ZG9pbmcgZm9yIGdhbW1hIHRhYmxlcyBhbHJlYWR5LCBhbmQgdGhhdCB3YXkgZHJpdmVycyBjYW4K PiA+PiBzaW1wbHkgdGhyb3cgYXdheSB0aGUgbG93ZXIgYml0cy4KPiA+IAo+ID4gQnV0IHRoYXQg d291bGQgYWxzbyBicmVhayB0aGUgdHdvIHVzZXJzIG9mIHRoYXQgcHJvcGVydHkgdGhhdCB3b24n dCBiZQo+ID4gYWJsZSB0byBtb3ZlIHRvIHRoZSBnZW5lcmljIHByb3BlcnR5ICh3aXRoIHRoZSBz YW1lIG5hbWUpIHdpdGhvdXQKPiA+IGJyZWFraW5nIHVzZXJzcGFjZS4gVGhlIHBvaW50IG9mIHRo YXQgcGF0Y2ggd2FzIHRvIGFsbG93IHNvbWUgY29kZQo+ID4gY29uc29saWRhdGlvbiwgYW5kIHRo YXQgd291bGQgbWVhbiBmYWlsaW5nIHRvIGRvIHNvIGhlcmUgOi8KPiAKPiBMZXQgbWUgdHJ5IHRv IGNsYXJpZnk6Cj4gLSBXZSdsbCBrZWVwIHRoZSBleGFjdCBleGlzdGluZyBwcm9wZXJ0eSBzZW1h bnRpY3Mgd2l0aCB0aGUgMC0yNTUKPiByYW5nZSBmb3IgdGhlIHVzZXJzcGFjZSB2aXNpYmxlIHBy b3BlcnR5Lgo+IAo+IC0gQnV0IGludGVybmFsbHksIGluIHRoZSBkZWNvZGUgdmFsdWUgdGhhdCB3 ZSBzdG9yZSBpbnRvCj4gZHJtX3BsYW5lX3N0YXRlLCB3ZSdsbCBkbyB0aGUgc2xpZ2h0bHkgbW9y ZSBmdXR1cmUgcHJvb2YgdGhpbmcgd2l0aCBhCj4gZmV3IG1vcmUgYml0cy4KPiAKPiBUaGF0IGdp dmVzIHVzIHRoZSBvcHRpb24gb2YgZXhwb3NpbmcgdGhvc2UgYml0cyBpbiB0aGUgZnV0dXJlIHdp dGhvdXQKPiBoYXZpbmcgdG8gY2hhbmdlIGFsbCB0aGUgZHJpdmVycyBhZ2FpbiAod2hpY2ggd2Ug aGF2ZSB0byBkbyBmb3IgdGhpcwo+IHNlcmllcyBoZXJlIGFscmVhZHkgYW55d2F5LCBzaW5jZSB0 aGUgZGVjb2RlZCB2YWx1ZSBtb3ZlcyBpbnRvCj4gZHJtX3BsYW5lX3N0YXRlIGZyb20gZHJpdmVy IHN1YmNsYXNzZXMpLgo+IAo+IERlZmluaXRlbHkgbm90IGFza2luZyB0byBicmVhayB1c2Vyc3Bh Y2UgaGVyZSA6LSkKCkFzIHRoZSBwcm9wZXJ0eSByYW5nZSBpcyBhdmFpbGFibGUgdG8gdXNlcnNw YWNlLCB3ZSBjb3VsZCBhbGxvdyBkcml2ZXJzIHRvIApleHBvc2UgYSBkcml2ZXItZGVwZW5kZW50 IG51bWJlciBvZiBiaXRzIGZvciB0aGUgYWxwaGEgdmFsdWUgd2l0aG91dCBicmVha2luZyAKYW55 dGhpbmcuIFdlIGNhbiBldmVuIHJlcXVpcmUgbmV3IGRyaXZlcnMgdG8gZXhwb3NlIDE2IGJpdHMg cmVnYXJkbGVzcyBvZiB0aGUgCm51bWJlciBvZiBiaXRzIHRoYXQgdGhlIGhhcmR3YXJlIGNhbiBo YW5kbGUsIG9yIHdlIGNvdWxkIGtlZXAgdGhhdCBkcml2ZXItCnNwZWNpZmljLgoKUGxlYXNlIG5v dGUsIGhvd2V2ZXIsIHRoYXQgVTAuMTYgY2FuIG9ubHkgcmVwcmVzZW50IFswLjAsIDAuOTk5OTg0 NzQxLi4uXSAKd2hpbGUgd2UgbmVlZCBbMC4wLCAxLjBdLiBBcyBhbGwgdGhlIGhhcmR3YXJlIEkg a25vdyBtYXAgdGhlIGZ1bGwgcmFuZ2Ugb2YgCnZhbHVlcyAoWzAsIDI1NV0gZm9yIDgtYml0IGZv ciBpbnN0YW5jZSkgdG8gWzAuMCwgMS4wXSBJIHdvdWxkbid0IHByZXRlbmQgdGhhdCAKdGhlIDE2 LWJpdCB2YWx1ZSBleHBvc2VkIHRvIHVzZXJzcGFjZSBpcyBVMC4xNi4KCj4gPj4+PiBJIGtub3cg b3RoZXIgZHJpdmVycyBoYXZlIHNraW1wZWQgb24gdGhlIHJ1bGVzIGhlcmUgYSBiaXQgLi4uIEJ1 dCBhdAo+ID4+Pj4gbGVhc3QgaW50ZXJuYWxseSAoaS5lLiB3aXRoaW4gdGhlIGRybV9wbGFuZV9z dGF0ZSkgd2UgcHJvYmFibHkgc2hvdWxkCj4gPj4+PiByZXN0cmljdCBvdXJzZWx2ZXMgdG8gdTgu IEFuZCB0aGlzIG5lZWRzIHJlYWwgZG9jcyAoaS5lLiB0aGUgZnVsbCBibGVuZAo+ID4+Pj4gZXF1 YXRpb24gZHJpdmVycyBhcmUgc3VwcG9zZWQgdG8gaW1wbGVtZW50KS4KPiA+Pj4gCj4gPj4+IFlv dSBtZWFuIHN0cmFpZ2h0IHZzIHByZW11bHRpcGxpZWQ/IE1heWJlIHdlIHNob3VsZCBpbXBsZW1l bnQgdGhpcyBhcwo+ID4+PiBhbiBhZGRpdGlvbmFsIHByb3BlcnR5IGluIHJlYWQgb25seSBkZXBl bmRpbmcgb24gaG93IHRoZSBoYXJkd2FyZQo+ID4+PiBiZWhhdmVzPwo+ID4+IAo+ID4+IE5vIG5l ZWQgZm9yIGFuIGFkZGl0aW9uYWwgcHJvcGVydHkgcmlnaHQgbm93LCBidXQgZGVmaW5pdGVseSBk b2N1bWVudAo+ID4+IHdoZXRoZXIgeW91IG1lYW4gc3RyYWlnaHQgb3IgcHJlLW11bHRpcGxpZWQu IEp1c3Qgd3JpdGluZyBkb3duIHRoZSBibGVuZAo+ID4+IGVxdWF0aW9uIGlzIHByb2JhYmx5IGJl c3QuCgotLSAKUmVnYXJkcywKCkxhdXJlbnQgUGluY2hhcnQKCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRl dmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935607AbeAKSea (ORCPT + 1 other); Thu, 11 Jan 2018 13:34:30 -0500 Received: from galahad.ideasonboard.com ([185.26.127.97]:47378 "EHLO galahad.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965478AbeAKSeZ (ORCPT ); Thu, 11 Jan 2018 13:34:25 -0500 From: Laurent Pinchart To: Daniel Vetter Cc: Maxime Ripard , Chen-Yu Tsai , Daniel Vetter , Jani Nikula , Sean Paul , Thomas Petazzoni , Boris Brezillon , Linux Kernel Mailing List , dri-devel , Linux ARM , thomas@vitsch.nl Subject: Re: [PATCH 06/19] drm/blend: Add a generic alpha property Date: Thu, 11 Jan 2018 20:34:58 +0200 Message-ID: <7937877.87F3UCTWB7@avalon> Organization: Ideas on Board Oy In-Reply-To: References: <20180111155857.bbfp4772fx56s5k3@flea.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: Hi Daniel, On Thursday, 11 January 2018 18:36:10 EET Daniel Vetter wrote: > On Thu, Jan 11, 2018 at 4:58 PM, Maxime Ripard wrote: > > On Tue, Jan 09, 2018 at 03:28:34PM +0100, Daniel Vetter wrote: > >> On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote: > >>> On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote: > >>>> On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote: > >>>>> Some drivers duplicate the logic to create a property to store a > >>>>> per-plane alpha. > >>>>> > >>>>> Let's create a helper in order to move that to the core. > >>>>> > >>>>> Cc: Boris Brezillon > >>>>> Cc: Laurent Pinchart > >>>>> Signed-off-by: Maxime Ripard > >>>> > >>>> Do we have userspace for this? > >>> > >>> Wayland seems to be on its way to implement this, with ChromeOS using > >>> it: > >>> https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741 > >>> .html > >>> > >>> and more specifically: > >>> https://chromium.googlesource.com/chromium/src/+/master/third_party/way > >>> land-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1 > >>> .xml#118 > >> > >> Yay, would be good to include these links in the patch description. > >> Really happy we're having a real standard now used by multiple people. > > > > I will. > > > >> > > Is encoding a fixed 0-255 range really the best idea? > >> > > >> > I don't really know, is there hardware or formats where there is more > >> > than 255? Or did you mean less than that? > >> > >> 30bit I'd assume wants more alpha. In the past we've done some > >> fixed-point stuff (e.g. for LUT), using the 0.0-1.0 float range. Using > >> that for the blend equation docs is also what I recommend (and that we > >> map from 0-255 to 0.0-1.0 logically). Ofc the hw might not do any of that > >> ... I think 0.16 fixed point, stored in a u16 is probably best. That's > >> what we're doing for gamma tables already, and that way drivers can > >> simply throw away the lower bits. > > > > But that would also break the two users of that property that won't be > > able to move to the generic property (with the same name) without > > breaking userspace. The point of that patch was to allow some code > > consolidation, and that would mean failing to do so here :/ > > Let me try to clarify: > - We'll keep the exact existing property semantics with the 0-255 > range for the userspace visible property. > > - But internally, in the decode value that we store into > drm_plane_state, we'll do the slightly more future proof thing with a > few more bits. > > That gives us the option of exposing those bits in the future without > having to change all the drivers again (which we have to do for this > series here already anyway, since the decoded value moves into > drm_plane_state from driver subclasses). > > Definitely not asking to break userspace here :-) As the property range is available to userspace, we could allow drivers to expose a driver-dependent number of bits for the alpha value without breaking anything. We can even require new drivers to expose 16 bits regardless of the number of bits that the hardware can handle, or we could keep that driver- specific. Please note, however, that U0.16 can only represent [0.0, 0.999984741...] while we need [0.0, 1.0]. As all the hardware I know map the full range of values ([0, 255] for 8-bit for instance) to [0.0, 1.0] I wouldn't pretend that the 16-bit value exposed to userspace is U0.16. > >>>> I know other drivers have skimped on the rules here a bit ... But at > >>>> least internally (i.e. within the drm_plane_state) we probably should > >>>> restrict ourselves to u8. And this needs real docs (i.e. the full blend > >>>> equation drivers are supposed to implement). > >>> > >>> You mean straight vs premultiplied? Maybe we should implement this as > >>> an additional property in read only depending on how the hardware > >>> behaves? > >> > >> No need for an additional property right now, but definitely document > >> whether you mean straight or pre-multiplied. Just writing down the blend > >> equation is probably best. -- Regards, Laurent Pinchart