From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-189.mta1.migadu.com (out-189.mta1.migadu.com [95.215.58.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B7B0419DF6A for ; Sun, 19 Jan 2025 11:29:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.189 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737286178; cv=none; b=HG09ORUctxAyruYa3qLeBfkaSgd7nnAigyE20jpzFUccZ0HL+e318Azo8pweHTXqwjjEF85KA3L90NQwVSMRSM7OBpUAQZejuIWjjgam6Nq51D0jKB6oFgZY7PcLq8VzEpJ1j4euCLCS+P3w+CsvXsWQrwhlh8KbxAXPT1SRHTI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737286178; c=relaxed/simple; bh=7RerRqZdue3bMzgOBsuTBAAh+prW4dbvWF7BYRiX6tQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=fdExz+dbF6MVVB5WsLjWtsNVvBOZzsb9lpeKfc3jQdI0pu2fA1sPDw1vwd7BNcZGnFs1jH6V8i2WUaJ+T5wIkM+EA6K2qs3Vf2YQVBiVlP9Qa1Pv1skE4/Lhy/dXrsogTHC3RH7169+Lk2xWN867MypVxN/fFcMU+7WaSkLSrO0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=xMqoqpXw; arc=none smtp.client-ip=95.215.58.189 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="xMqoqpXw" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1737286164; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uuK0LkbEgQqPgK0yPnR5LzoggyynezSlKlKR/CKdeTY=; b=xMqoqpXwM+10B3buteMukau9UQmlGuAXyj0ur9aXSA7WbWzwRnMniPiQaxTWp6qqTY2fRw kdeVaGsloeyKfqel8VbZAIHcFFD77zLC4uiMyod2/pw8443jMEAy0AngMSBb8Lp3KLn9lX baphMPg1zk5Qs828ODB8iVWTCpuol5w= Date: Sun, 19 Jan 2025 19:29:14 +0800 Precedence: bulk X-Mailing-List: imx@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with drm_mode_size_dumb() To: Dmitry Baryshkov , Geert Uytterhoeven Cc: Tomi Valkeinen , Thomas Zimmermann , maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com, simona@ffwll.ch, dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org, virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org, intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org, Laurent Pinchart , Andy Yan , Daniel Stone References: <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de> <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Sui Jingfeng In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT Hi, On 2025/1/16 18:35, Dmitry Baryshkov wrote: > On Thu, Jan 16, 2025 at 11:17:50AM +0100, Geert Uytterhoeven wrote: >> On Thu, Jan 16, 2025 at 11:03 AM Tomi Valkeinen >> wrote: >>> On 16/01/2025 10:09, Thomas Zimmermann wrote: >>>> Am 15.01.25 um 15:20 schrieb Tomi Valkeinen: >>>> [...] >>>>> My point is that we have the current UAPI, and we have userspace using >>>>> it, but we don't have clear rules what the ioctl does with specific >>>>> parameters, and we don't document how it has to be used. >>>>> >>>>> Perhaps the situation is bad, and all we can really say is that >>>>> CREATE_DUMB only works for use with simple RGB formats, and the >>>>> behavior for all other formats is platform specific. But I think even >>>>> that would be valuable in the UAPI docs. >>>> To be honest, I would not want to specify behavior for anything but the >>>> linear RGB formats. If anything, I'd take Daniel's reply mail for >>>> documentation as-is. Anyone stretching the UAPI beyond RGB is on their own. >>>> >>>>> Thinking about this, I wonder if this change is good for omapdrm or >>>>> xilinx (probably other platforms too that support non-simple non-RGB >>>>> formats via dumb buffers): without this patch, in both drivers, the >>>>> pitch calculations just take the bpp as bit-per-pixels, align it up, >>>>> and that's it. >>>>> >>>>> With this patch we end up using drm_driver_color_mode_format(), and >>>>> aligning buffers according to RGB formats figured out via heuristics. >>>>> It does happen to work, for the formats I tested, but it sounds like >>>>> something that might easily not work, as it's doing adjustments based >>>>> on wrong format. >>>>> >>>>> Should we have another version of drm_mode_size_dumb() which just >>>>> calculates using the bpp, without the drm_driver_color_mode_format() >>>>> path? Or does the drm_driver_color_mode_format() path provide some >>>>> value for the drivers that do not currently do anything similar? >>>> With the RGB-only rule, using drm_driver_color_mode_format() makes >>>> sense. It aligns dumb buffers and video=, provides error checking, and >>>> overall harmonizes code. The fallback is only required because of the >>>> existing odd cases that already bend the UAPI's rules. >>> I have to disagree here. >>> >>> On the platforms I have been using (omap, tidss, xilinx, rcar) the dumb >>> buffers are the only buffers you can get from the DRM driver. The dumb >>> buffers have been used to allocate linear and multiplanar YUV buffers >>> for a very long time on those platforms. >>> >>> I tried to look around, but I did not find any mentions that CREATE_DUMB >>> should only be used for RGB buffers. Is anyone outside the core >>> developers even aware of it? >>> >>> If we don't use dumb buffers there, where do we get the buffers? Maybe >>> from a v4l2 device or from a gpu device, but often you don't have those. >>> DMA_HEAP is there, of course. >> Why can't there be a variant that takes a proper fourcc format instead of >> an imprecise bpp value? > Backwards compatibility. We can add an IOCTL for YUV / etc. [...] > But userspace must be able to continue allocating YUV buffers through > CREATE_DUMB. I think, allocating YUV buffers through CREATE_DUMB interface is just an *abuse* and *misuse* of this API for now. Take the NV12 format as an example, NV12 is YUV420 planar format, have two planar: the Y-planar and the UV-planar. The Y-planar appear first in memory as an array of unsigned char values. The Y-planar is followed immediately by the UV-planar, which is also an array of unsigned char values that contains packed U (Cb) and V (Cr) samples. But the 'drm_mode_create_dumb' structure is only intend to provide descriptions for *one* planar. struct drm_mode_create_dumb { __u32 height; __u32 width; __u32 bpp; __u32 flags; __u32 handle; __u32 pitch; __u64 size; }; An width x height NV12 image takes up width*height*(1 + 1/4 + 1/4) bytes. So we can allocate an *equivalent* sized buffer to store the NV12 raw data. Either 'width * (height * 3/2)' where each pixel take up 8 bits, or just 'with * height' where each pixels take up 12 bits. However, all those math are just equivalents description to the original NV12 format, neither are concrete correct physical description. Therefore, allocating YUV buffers through the dumb interface is just an abuse for that API. We certainly can abuse more by allocating two dumb buffers, one for Y-planer, another one for the UV-planer. But again,dumb buffers can be (and must be) used for *scanout* directly. What will yield if I commit the YUV buffers you allocated to the CRTC directly? In other words, You can allocated buffers via the dumb APIs to store anything, but the key point is that how can we interpret it. As Daniel puts it, the semantics of that API is well defined for simple RGB formats. Usages on non linear RGB dumb buffers are considered as undefined behavior. Peoples can still abusing it at the user-space though, but the kernel don't have to guarantee that the user-space *must* to be able to continue doing balabala..., That's it. Best regards, Sui >> Gr{oetje,eeting}s, >> >> Geert >> >> -- >> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org >> >> In personal conversations with technical people, I call myself a hacker. But >> when I'm talking to journalists I just say "programmer" or something like that. >> -- Linus Torvalds -- Best regards, Sui 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 37532C02183 for ; Sun, 19 Jan 2025 11:29:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=9u4t4cuNGDstuZNV0FEXsPPxIZZMu5JKA+Yt1ZYgW4M=; b=Hjcr5IzV2222kL Nw3+BX0S0tKi3o0moeK4b5S/Rl/SflhMxsi4p2erG+pXeturEDEv+sC30ri2YnWynOkwFljFyl2Zx kLL1256SwBT1+IA7x1ndmHDjxMmfYfy+L6pDO3UCqLIow4+XzI05rOupezL+JEvQnL8OzbnCsJiAH qeWZ3ScHJf3UHfXxBibo0YrPRiWeOh8K+KxFrnpahGbxhuRtR9IA7HTZRPcmiulvp7zSMjnJkBeek 2gwPuuOdBBo5i18EtBfWcA4/Q9pp/sEKNntGVTzwOHrWL8JGbEfnsXfXjq1/xUUn9PikTRnnquTSa M90fZuvgMV8guA+4ndkQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tZTUp-00000003nb5-1uFi; Sun, 19 Jan 2025 11:29:39 +0000 Received: from out-175.mta1.migadu.com ([95.215.58.175]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tZTUn-00000003nYp-0hYV for linux-rockchip@lists.infradead.org; Sun, 19 Jan 2025 11:29:38 +0000 Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1737286164; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uuK0LkbEgQqPgK0yPnR5LzoggyynezSlKlKR/CKdeTY=; b=xMqoqpXwM+10B3buteMukau9UQmlGuAXyj0ur9aXSA7WbWzwRnMniPiQaxTWp6qqTY2fRw kdeVaGsloeyKfqel8VbZAIHcFFD77zLC4uiMyod2/pw8443jMEAy0AngMSBb8Lp3KLn9lX baphMPg1zk5Qs828ODB8iVWTCpuol5w= Date: Sun, 19 Jan 2025 19:29:14 +0800 MIME-Version: 1.0 Subject: Re: [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with drm_mode_size_dumb() To: Dmitry Baryshkov , Geert Uytterhoeven Cc: Tomi Valkeinen , Thomas Zimmermann , maarten.lankhorst@linux.intel.com, mripard@kernel.org, airlied@gmail.com, simona@ffwll.ch, dri-devel@lists.freedesktop.org, linux-mediatek@lists.infradead.org, freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, imx@lists.linux.dev, linux-samsung-soc@vger.kernel.org, nouveau@lists.freedesktop.org, virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-tegra@vger.kernel.org, intel-xe@lists.freedesktop.org, xen-devel@lists.xenproject.org, Laurent Pinchart , Andy Yan , Daniel Stone References: <0ea6be58-0e04-4172-87cd-064a3e4a43bc@suse.de> <4af0b6a7-c16a-4187-bbf5-365a9c86de21@suse.de> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Sui Jingfeng In-Reply-To: X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250119_032937_353049_88C3E10F X-CRM114-Status: GOOD ( 30.20 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org SGksCgpPbiAyMDI1LzEvMTYgMTg6MzUsIERtaXRyeSBCYXJ5c2hrb3Ygd3JvdGU6Cj4gT24gVGh1 LCBKYW4gMTYsIDIwMjUgYXQgMTE6MTc6NTBBTSArMDEwMCwgR2VlcnQgVXl0dGVyaG9ldmVuIHdy b3RlOgo+PiBPbiBUaHUsIEphbiAxNiwgMjAyNSBhdCAxMTowM+KAr0FNIFRvbWkgVmFsa2VpbmVu Cj4+IDx0b21pLnZhbGtlaW5lbkBpZGVhc29uYm9hcmQuY29tPiB3cm90ZToKPj4+IE9uIDE2LzAx LzIwMjUgMTA6MDksIFRob21hcyBaaW1tZXJtYW5uIHdyb3RlOgo+Pj4+IEFtIDE1LjAxLjI1IHVt IDE1OjIwIHNjaHJpZWIgVG9taSBWYWxrZWluZW46Cj4+Pj4gWy4uLl0KPj4+Pj4gTXkgcG9pbnQg aXMgdGhhdCB3ZSBoYXZlIHRoZSBjdXJyZW50IFVBUEksIGFuZCB3ZSBoYXZlIHVzZXJzcGFjZSB1 c2luZwo+Pj4+PiBpdCwgYnV0IHdlIGRvbid0IGhhdmUgY2xlYXIgcnVsZXMgd2hhdCB0aGUgaW9j dGwgZG9lcyB3aXRoIHNwZWNpZmljCj4+Pj4+IHBhcmFtZXRlcnMsIGFuZCB3ZSBkb24ndCBkb2N1 bWVudCBob3cgaXQgaGFzIHRvIGJlIHVzZWQuCj4+Pj4+Cj4+Pj4+IFBlcmhhcHMgdGhlIHNpdHVh dGlvbiBpcyBiYWQsIGFuZCBhbGwgd2UgY2FuIHJlYWxseSBzYXkgaXMgdGhhdAo+Pj4+PiBDUkVB VEVfRFVNQiBvbmx5IHdvcmtzIGZvciB1c2Ugd2l0aCBzaW1wbGUgUkdCIGZvcm1hdHMsIGFuZCB0 aGUKPj4+Pj4gYmVoYXZpb3IgZm9yIGFsbCBvdGhlciBmb3JtYXRzIGlzIHBsYXRmb3JtIHNwZWNp ZmljLiBCdXQgSSB0aGluayBldmVuCj4+Pj4+IHRoYXQgd291bGQgYmUgdmFsdWFibGUgaW4gdGhl IFVBUEkgZG9jcy4KPj4+PiBUbyBiZSBob25lc3QsIEkgd291bGQgbm90IHdhbnQgdG8gc3BlY2lm eSBiZWhhdmlvciBmb3IgYW55dGhpbmcgYnV0IHRoZQo+Pj4+IGxpbmVhciBSR0IgZm9ybWF0cy4g SWYgYW55dGhpbmcsIEknZCB0YWtlIERhbmllbCdzIHJlcGx5IG1haWwgZm9yCj4+Pj4gZG9jdW1l bnRhdGlvbiBhcy1pcy4gQW55b25lIHN0cmV0Y2hpbmcgdGhlIFVBUEkgYmV5b25kIFJHQiBpcyBv biB0aGVpciBvd24uCj4+Pj4KPj4+Pj4gVGhpbmtpbmcgYWJvdXQgdGhpcywgSSB3b25kZXIgaWYg dGhpcyBjaGFuZ2UgaXMgZ29vZCBmb3Igb21hcGRybSBvcgo+Pj4+PiB4aWxpbnggKHByb2JhYmx5 IG90aGVyIHBsYXRmb3JtcyB0b28gdGhhdCBzdXBwb3J0IG5vbi1zaW1wbGUgbm9uLVJHQgo+Pj4+ PiBmb3JtYXRzIHZpYSBkdW1iIGJ1ZmZlcnMpOiB3aXRob3V0IHRoaXMgcGF0Y2gsIGluIGJvdGgg ZHJpdmVycywgdGhlCj4+Pj4+IHBpdGNoIGNhbGN1bGF0aW9ucyBqdXN0IHRha2UgdGhlIGJwcCBh cyBiaXQtcGVyLXBpeGVscywgYWxpZ24gaXQgdXAsCj4+Pj4+IGFuZCB0aGF0J3MgaXQuCj4+Pj4+ Cj4+Pj4+IFdpdGggdGhpcyBwYXRjaCB3ZSBlbmQgdXAgdXNpbmcgZHJtX2RyaXZlcl9jb2xvcl9t b2RlX2Zvcm1hdCgpLCBhbmQKPj4+Pj4gYWxpZ25pbmcgYnVmZmVycyBhY2NvcmRpbmcgdG8gUkdC IGZvcm1hdHMgZmlndXJlZCBvdXQgdmlhIGhldXJpc3RpY3MuCj4+Pj4+IEl0IGRvZXMgaGFwcGVu IHRvIHdvcmssIGZvciB0aGUgZm9ybWF0cyBJIHRlc3RlZCwgYnV0IGl0IHNvdW5kcyBsaWtlCj4+ Pj4+IHNvbWV0aGluZyB0aGF0IG1pZ2h0IGVhc2lseSBub3Qgd29yaywgYXMgaXQncyBkb2luZyBh ZGp1c3RtZW50cyBiYXNlZAo+Pj4+PiBvbiB3cm9uZyBmb3JtYXQuCj4+Pj4+Cj4+Pj4+IFNob3Vs ZCB3ZSBoYXZlIGFub3RoZXIgdmVyc2lvbiBvZiBkcm1fbW9kZV9zaXplX2R1bWIoKSB3aGljaCBq dXN0Cj4+Pj4+IGNhbGN1bGF0ZXMgdXNpbmcgdGhlIGJwcCwgd2l0aG91dCB0aGUgZHJtX2RyaXZl cl9jb2xvcl9tb2RlX2Zvcm1hdCgpCj4+Pj4+IHBhdGg/IE9yIGRvZXMgdGhlIGRybV9kcml2ZXJf Y29sb3JfbW9kZV9mb3JtYXQoKSBwYXRoIHByb3ZpZGUgc29tZQo+Pj4+PiB2YWx1ZSBmb3IgdGhl IGRyaXZlcnMgdGhhdCBkbyBub3QgY3VycmVudGx5IGRvIGFueXRoaW5nIHNpbWlsYXI/Cj4+Pj4g V2l0aCB0aGUgUkdCLW9ubHkgcnVsZSwgdXNpbmcgZHJtX2RyaXZlcl9jb2xvcl9tb2RlX2Zvcm1h dCgpIG1ha2VzCj4+Pj4gc2Vuc2UuIEl0IGFsaWducyBkdW1iIGJ1ZmZlcnMgYW5kIHZpZGVvPSwg cHJvdmlkZXMgZXJyb3IgY2hlY2tpbmcsIGFuZAo+Pj4+IG92ZXJhbGwgaGFybW9uaXplcyBjb2Rl LiBUaGUgZmFsbGJhY2sgaXMgb25seSByZXF1aXJlZCBiZWNhdXNlIG9mIHRoZQo+Pj4+IGV4aXN0 aW5nIG9kZCBjYXNlcyB0aGF0IGFscmVhZHkgYmVuZCB0aGUgVUFQSSdzIHJ1bGVzLgo+Pj4gSSBo YXZlIHRvIGRpc2FncmVlIGhlcmUuCj4+Pgo+Pj4gT24gdGhlIHBsYXRmb3JtcyBJIGhhdmUgYmVl biB1c2luZyAob21hcCwgdGlkc3MsIHhpbGlueCwgcmNhcikgdGhlIGR1bWIKPj4+IGJ1ZmZlcnMg YXJlIHRoZSBvbmx5IGJ1ZmZlcnMgeW91IGNhbiBnZXQgZnJvbSB0aGUgRFJNIGRyaXZlci4gVGhl IGR1bWIKPj4+IGJ1ZmZlcnMgaGF2ZSBiZWVuIHVzZWQgdG8gYWxsb2NhdGUgbGluZWFyIGFuZCBt dWx0aXBsYW5hciBZVVYgYnVmZmVycwo+Pj4gZm9yIGEgdmVyeSBsb25nIHRpbWUgb24gdGhvc2Ug cGxhdGZvcm1zLgo+Pj4KPj4+IEkgdHJpZWQgdG8gbG9vayBhcm91bmQsIGJ1dCBJIGRpZCBub3Qg ZmluZCBhbnkgbWVudGlvbnMgdGhhdCBDUkVBVEVfRFVNQgo+Pj4gc2hvdWxkIG9ubHkgYmUgdXNl ZCBmb3IgUkdCIGJ1ZmZlcnMuIElzIGFueW9uZSBvdXRzaWRlIHRoZSBjb3JlCj4+PiBkZXZlbG9w ZXJzIGV2ZW4gYXdhcmUgb2YgaXQ/Cj4+Pgo+Pj4gSWYgd2UgZG9uJ3QgdXNlIGR1bWIgYnVmZmVy cyB0aGVyZSwgd2hlcmUgZG8gd2UgZ2V0IHRoZSBidWZmZXJzPyBNYXliZQo+Pj4gZnJvbSBhIHY0 bDIgZGV2aWNlIG9yIGZyb20gYSBncHUgZGV2aWNlLCBidXQgb2Z0ZW4geW91IGRvbid0IGhhdmUg dGhvc2UuCj4+PiBETUFfSEVBUCBpcyB0aGVyZSwgb2YgY291cnNlLgo+PiBXaHkgY2FuJ3QgdGhl cmUgYmUgYSB2YXJpYW50IHRoYXQgdGFrZXMgYSBwcm9wZXIgZm91cmNjIGZvcm1hdCBpbnN0ZWFk IG9mCj4+IGFuIGltcHJlY2lzZSBicHAgdmFsdWU/Cj4gQmFja3dhcmRzIGNvbXBhdGliaWxpdHku IFdlIGNhbiBhZGQgYW4gSU9DVEwgZm9yIFlVViAvIGV0Yy4KClsuLi5dCgo+IEJ1dCB1c2Vyc3Bh Y2UgbXVzdCBiZSBhYmxlIHRvIGNvbnRpbnVlIGFsbG9jYXRpbmcgWVVWIGJ1ZmZlcnMgdGhyb3Vn aAo+IENSRUFURV9EVU1CLgoKSSB0aGluaywgYWxsb2NhdGluZyBZVVYgYnVmZmVycyB0aHJvdWdo IENSRUFURV9EVU1CIGludGVyZmFjZSBpcyBqdXN0CmFuICphYnVzZSogYW5kICptaXN1c2UqIG9m IHRoaXMgQVBJIGZvciBub3cuCgpUYWtlIHRoZSBOVjEyIGZvcm1hdCBhcyBhbiBleGFtcGxlLCBO VjEyIGlzIFlVVjQyMCBwbGFuYXIgZm9ybWF0LCBoYXZlCnR3byBwbGFuYXI6IHRoZSBZLXBsYW5h ciBhbmQgdGhlIFVWLXBsYW5hci4gVGhlIFktcGxhbmFyIGFwcGVhciBmaXJzdAppbiBtZW1vcnkg YXMgYW4gYXJyYXkgb2YgdW5zaWduZWQgY2hhciB2YWx1ZXMuIFRoZSBZLXBsYW5hciBpcyBmb2xs b3dlZAppbW1lZGlhdGVseSBieSB0aGUgVVYtcGxhbmFyLCB3aGljaCBpcyBhbHNvIGFuIGFycmF5 IG9mIHVuc2lnbmVkIGNoYXIKdmFsdWVzIHRoYXQgY29udGFpbnMgcGFja2VkIFUgKENiKSBhbmQg ViAoQ3IpIHNhbXBsZXMuCgpCdXQgdGhlICdkcm1fbW9kZV9jcmVhdGVfZHVtYicgc3RydWN0dXJl IGlzIG9ubHkgaW50ZW5kIHRvIHByb3ZpZGUKZGVzY3JpcHRpb25zIGZvciAqb25lKiBwbGFuYXIu CgpzdHJ1Y3QgZHJtX21vZGVfY3JlYXRlX2R1bWIgewogICAgIF9fdTMyIGhlaWdodDsKICAgICBf X3UzMiB3aWR0aDsKICAgICBfX3UzMiBicHA7CiAgICAgX191MzIgZmxhZ3M7CiAgICAgX191MzIg aGFuZGxlOwogICAgIF9fdTMyIHBpdGNoOwogICAgIF9fdTY0IHNpemU7Cn07CgpBbiB3aWR0aCB4 IGhlaWdodCBOVjEyIGltYWdlIHRha2VzIHVwIHdpZHRoKmhlaWdodCooMSArIDEvNCArIDEvNCkg Ynl0ZXMuCgpTbyB3ZSBjYW4gYWxsb2NhdGUgYW4gKmVxdWl2YWxlbnQqIHNpemVkIGJ1ZmZlciB0 byBzdG9yZSB0aGUgTlYxMiByYXcgZGF0YS4KCkVpdGhlciAnd2lkdGggKiAoaGVpZ2h0ICogMy8y KScgd2hlcmUgZWFjaCBwaXhlbCB0YWtlIHVwIDggYml0cywKb3IganVzdCAnd2l0aCAqIGhlaWdo dCcgd2hlcmUgZWFjaCBwaXhlbHMgdGFrZSB1cCAxMiBiaXRzLgoKSG93ZXZlciwgYWxsIHRob3Nl IG1hdGggYXJlIGp1c3QgZXF1aXZhbGVudHMgZGVzY3JpcHRpb24gdG8gdGhlIG9yaWdpbmFsCk5W MTIgZm9ybWF0LCBuZWl0aGVyIGFyZSBjb25jcmV0ZSBjb3JyZWN0IHBoeXNpY2FsIGRlc2NyaXB0 aW9uLgoKVGhlcmVmb3JlLCBhbGxvY2F0aW5nIFlVViBidWZmZXJzIHRocm91Z2ggdGhlIGR1bWIg aW50ZXJmYWNlIGlzIGp1c3QgYW4KYWJ1c2UgZm9yIHRoYXQgQVBJLiBXZSBjZXJ0YWlubHkgY2Fu IGFidXNlIG1vcmUgYnkgYWxsb2NhdGluZyB0d28gZHVtYgpidWZmZXJzLCBvbmUgZm9yIFktcGxh bmVyLCBhbm90aGVyIG9uZSBmb3IgdGhlIFVWLXBsYW5lci4gQnV0IGFnYWluLGR1bWIgYnVmZmVy cyBjYW4gYmUgKGFuZCBtdXN0IGJlKSB1c2VkIGZvciAqc2Nhbm91dCogZGlyZWN0bHkuIFdoYXQg d2lsbCB5aWVsZCBpZiBJIGNvbW1pdCB0aGUgWVVWIGJ1ZmZlcnMgeW91IGFsbG9jYXRlZCB0byB0 aGUgQ1JUQyBkaXJlY3RseT8KCkluIG90aGVyIHdvcmRzLCBZb3UgY2FuIGFsbG9jYXRlZCBidWZm ZXJzIHZpYSB0aGUgZHVtYiBBUElzIHRvIHN0b3JlIGFueXRoaW5nLApidXQgdGhlIGtleSBwb2lu dCBpcyB0aGF0IGhvdyBjYW4gd2UgaW50ZXJwcmV0IGl0LgoKQXMgRGFuaWVsIHB1dHMgaXQsIHRo ZSBzZW1hbnRpY3Mgb2YgdGhhdCBBUEkgaXMgd2VsbCBkZWZpbmVkIGZvciBzaW1wbGUgUkdCCmZv cm1hdHMuIFVzYWdlcyBvbiBub24gbGluZWFyIFJHQiBkdW1iIGJ1ZmZlcnMgYXJlIGNvbnNpZGVy ZWQgYXMgdW5kZWZpbmVkCmJlaGF2aW9yLgoKUGVvcGxlcyBjYW4gc3RpbGwgYWJ1c2luZyBpdCBh dCB0aGUgdXNlci1zcGFjZSB0aG91Z2gsIGJ1dCB0aGUga2VybmVsIGRvbid0CmhhdmUgdG8gZ3Vh cmFudGVlIHRoYXQgdGhlIHVzZXItc3BhY2UgKm11c3QqIHRvIGJlIGFibGUgdG8gY29udGludWUg ZG9pbmcKYmFsYWJhbGEuLi4sIFRoYXQncyBpdC4KCgpCZXN0IHJlZ2FyZHMsClN1aQoKPj4gR3J7 b2V0amUsZWV0aW5nfXMsCj4+Cj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBHZWVydAo+Pgo+ PiAtLSAKPj4gR2VlcnQgVXl0dGVyaG9ldmVuIC0tIFRoZXJlJ3MgbG90cyBvZiBMaW51eCBiZXlv bmQgaWEzMiAtLSBnZWVydEBsaW51eC1tNjhrLm9yZwo+Pgo+PiBJbiBwZXJzb25hbCBjb252ZXJz YXRpb25zIHdpdGggdGVjaG5pY2FsIHBlb3BsZSwgSSBjYWxsIG15c2VsZiBhIGhhY2tlci4gQnV0 Cj4+IHdoZW4gSSdtIHRhbGtpbmcgdG8gam91cm5hbGlzdHMgSSBqdXN0IHNheSAicHJvZ3JhbW1l ciIgb3Igc29tZXRoaW5nIGxpa2UgdGhhdC4KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgLS0gTGludXMgVG9ydmFsZHMKCi0tIApCZXN0IHJlZ2FyZHMsClN1aQoKCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkxpbnV4LXJvY2tjaGlwIG1h aWxpbmcgbGlzdApMaW51eC1yb2NrY2hpcEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0 cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtcm9ja2NoaXAK