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=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 2D16FC433DB for ; Tue, 16 Mar 2021 20:29:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F39E864F75 for ; Tue, 16 Mar 2021 20:29:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229660AbhCPU3Q (ORCPT ); Tue, 16 Mar 2021 16:29:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45254 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229994AbhCPU2s (ORCPT ); Tue, 16 Mar 2021 16:28:48 -0400 Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:3005::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 14814C06174A for ; Tue, 16 Mar 2021 13:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tronnes.org ; s=ds202012; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ewtQ6oEgdnQBPOpUDyoc21YP+uvolAB570CcsVJHI1Y=; b=AcldiIjK918qSLqKGa6Gx1PtJg fg/9YrtfwthK5aPcSu65xh+DD4ySjElIHVSJfJK2rMQWbP9rk1yv2LA8ltPzmfX5tSuHB6wY6MIfw /y9tqdtEIa4gpF6qYMNHxO4R1AFrp+MeSe0v1yT97b5MAKTBFzkis02UWr7+MmhQgmeLLdSjz2TEC TdH2AYeu42lVgfGmAlWtKN/WCSng8otb0j26geyvxYLMJOYH8MvjQSFgALf/lkCjPB5JxzMbgr2Rb xqJpE8ZjO2FNM1BBZqv29BXFz/qeVw0uTYBLMev0dFeGh/cQBQ0nnjoWMuLYjzdqpTexbcY8EULdb EL+DH3DQ==; Received: from [2a01:799:95f:4600:cca0:57ac:c55d:a485] (port=62895) by smtp.domeneshop.no with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lMGJ0-0006nk-05; Tue, 16 Mar 2021 21:28:42 +0100 Subject: Re: [PATCH v8 3/3] drm: Add GUD USB Display driver To: Peter Stuge Cc: dri-devel@lists.freedesktop.org, hudson@trmm.net, markus@raatikainen.cc, sam@ravnborg.org, linux-usb@vger.kernel.org, th020394@gmail.com, lkundrak@v3.sk, pontus.fuchs@gmail.com, Daniel Vetter References: <20210313112545.37527-1-noralf@tronnes.org> <20210313112545.37527-4-noralf@tronnes.org> <20210315193729.10166.qmail@stuge.se> From: =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= Message-ID: Date: Tue, 16 Mar 2021 21:28:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210315193729.10166.qmail@stuge.se> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org Den 15.03.2021 20.37, skrev Peter Stuge: > Hi Noralf, > > super fair call with the BE testing, let's hope for some testing soonish. > > > I was thinking about my device doing protocol STALL when I try to > return 0 bytes, and while it *is* a bug in my device, from a standards > point of view it's actually completely valid, if not expected: > > --8<-- usb_20.pdf 8.5.3.4 STALL Handshakes Returned by Control Pipes > If the device is unable to complete a command, it returns a STALL in the > Data and/or Status stages of the control transfer. Unlike the case of a > functional stall, protocol stall does not indicate an error with the device. > -->8-- > > I think it's fair to say that a device can't complete the command > when it has no data to return. > > So how about allowing STALL for optional GUD_REQ_GET_:s to mean the same > as a 0 byte response? Should I propose a separate patch for it later? > Yeah, that would be nice. We can't look for -EPIPE though, since GUD_REQ_GET_STATUS will ask for the actual error. We have these to choose from currently: #define GUD_STATUS_OK 0x00 #define GUD_STATUS_BUSY 0x01 #define GUD_STATUS_REQUEST_NOT_SUPPORTED 0x02 #define GUD_STATUS_PROTOCOL_ERROR 0x03 #define GUD_STATUS_INVALID_PARAMETER 0x04 #define GUD_STATUS_ERROR 0x05 Maybe REQUEST_NOT_SUPPORTED (-EOPNOTSUPP) or add a more fitting status value. If the driver sees -EPIPE this means that the device has failed to respond properly. See gud_usb_transfer(). > > Noralf Trønnes wrote: >> +++ b/drivers/gpu/drm/gud/gud_connector.c > .. >> +static int gud_connector_get_modes(struct drm_connector *connector) > .. >> + ret = gud_usb_get(gdrm, GUD_REQ_GET_CONNECTOR_EDID, connector->index, >> + edid_ctx.buf, GUD_CONNECTOR_MAX_EDID_LEN); > > if (ret == -EPIPE) > ret = 0; > >> + if (ret > 0 && ret % EDID_LENGTH) { >> + gud_conn_err(connector, "Invalid EDID size", ret); >> + } else if (ret > 0) { >> + edid_ctx.len = ret; >> + edid = drm_do_get_edid(connector, gud_connector_get_edid_block, &edid_ctx); >> + } > > >> +static int gud_connector_add_properties(struct gud_device *gdrm, struct gud_connector *gconn) > .. >> + ret = gud_usb_get(gdrm, GUD_REQ_GET_CONNECTOR_PROPERTIES, connector->index, >> + properties, GUD_CONNECTOR_PROPERTIES_MAX_NUM * sizeof(*properties)); > > if (ret == -EPIPE) > ret = 0; > >> + if (ret <= 0) >> + goto out; >> + if (ret % sizeof(*properties)) { >> + ret = -EIO; >> + goto out; >> + } > > >> +++ b/drivers/gpu/drm/gud/gud_drv.c > .. > .. >> +static int gud_get_properties(struct gud_device *gdrm) > .. >> + ret = gud_usb_get(gdrm, GUD_REQ_GET_PROPERTIES, 0, >> + properties, GUD_PROPERTIES_MAX_NUM * sizeof(*properties)); > > if (ret == -EPIPE) > ret = 0; > >> + if (ret <= 0) >> + goto out; >> + if (ret % sizeof(*properties)) { >> + ret = -EIO; >> + goto out; >> + } > > > Then I looked whether a device could cause trouble in the driver by > returning complex/unexpected data, and found this: > >> +static int gud_probe(struct usb_interface *intf, const struct usb_device_id *id) > .. >> + /* Add room for emulated XRGB8888 */ >> + formats = devm_kmalloc_array(dev, GUD_FORMATS_MAX_NUM + 1, sizeof(*formats), GFP_KERNEL); > > It looks like this +1 and the way xrgb8888_emulation_format works means > that an interface will not always work correctly if multiple emulated > formats (R1, XRGB1111, RGB565) are returned, because only one emulated > mode is added after the loop, with struct drm_format_info for the last > emulated format returned by the device. So userspace would only see the > last emulated mode and the bulk output would only ever use that > particular pixel format, any earlier ones would be unavailable? > > If this is EWONTFIX then how about adding an error message if multiple > emulated modes are returned and ignore all but the first, rather than > all but the last? > It does ignore all but the first... doesn't it? You could make a patch if you care about this: case GUD_DRM_FORMAT_R1: fallthrough; case GUD_DRM_FORMAT_XRGB1111: if (!xrgb8888_emulation_format) xrgb8888_emulation_format = info; + else + dev_err(dev, "..."); break; It's only needed for the formats that are not exported to userspace. > > Related: Can userspace find out which GUD_PIXEL_FORMAT_* is behind an > emulated format? It's needed to decide how the emulated framebuffer > should be used, in particular to not use G or B if GUD_PIXEL_FORMAT_R1. > There's no way for userspace to know that. drm_fb_xrgb8888_to_gray8() uses ITU BT.601 rgb conversion so userspace doesn't have to know which colors to use, but ofc it will need to know there's a monochrome display for it to look good. XRGB8888 is the only format that is allowed to be emulated since some userspace only supports that one format. So we can't have a device that supports both R1 and XRGB1111. > >> + switch (format) { >> + case GUD_DRM_FORMAT_R1: >> + fallthrough; >> + case GUD_DRM_FORMAT_XRGB1111: >> + if (!xrgb8888_emulation_format) >> + xrgb8888_emulation_format = info; >> + break; >> + case DRM_FORMAT_RGB565: >> + rgb565_supported = true; >> + if (!xrgb8888_emulation_format) >> + xrgb8888_emulation_format = info; >> + break; > > Could RGB565 go before XRGB111 (or R1) and also fallthrough; in this > construct? Not terribly important, but the repetition caught my eye. > It could but I'd like to keep the increasing bits-per-pixel order. > > Then, in gud_connector.c I saw this, which surprised me: > > +int gud_connector_fill_properties(struct drm_connector_state *connector_state, > .. > + if (prop == GUD_PROPERTY_BACKLIGHT_BRIGHTNESS) { > + val = connector_state->tv.brightness; > + } else { > > Why is this using tv.brightness rather than say gconn->initial_brightness? > > It looks like the end result might be the same because tv.brightness is > set to gconn->initial_brightness in gud_connector_reset() but it's a > little confusing to me, since a GUD backlight isn't a drm/TV thing? > I'm reusing the tv state property since that saves me from subclassing the connector state. I want to have the value in the state because that makes it less of a special case. Some time in the future DRM will have proper backlight support as a DRM property, but so far no one has been willing to invest the necessary time and effort to make it happen. Noralf. 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=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 7A950C433E0 for ; Tue, 16 Mar 2021 20:28:47 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AE22064F4F for ; Tue, 16 Mar 2021 20:28:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AE22064F4F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=tronnes.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0E6078993B; Tue, 16 Mar 2021 20:28:46 +0000 (UTC) Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:3005::1]) by gabe.freedesktop.org (Postfix) with ESMTPS id F3B988993B for ; Tue, 16 Mar 2021 20:28:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tronnes.org ; s=ds202012; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ewtQ6oEgdnQBPOpUDyoc21YP+uvolAB570CcsVJHI1Y=; b=AcldiIjK918qSLqKGa6Gx1PtJg fg/9YrtfwthK5aPcSu65xh+DD4ySjElIHVSJfJK2rMQWbP9rk1yv2LA8ltPzmfX5tSuHB6wY6MIfw /y9tqdtEIa4gpF6qYMNHxO4R1AFrp+MeSe0v1yT97b5MAKTBFzkis02UWr7+MmhQgmeLLdSjz2TEC TdH2AYeu42lVgfGmAlWtKN/WCSng8otb0j26geyvxYLMJOYH8MvjQSFgALf/lkCjPB5JxzMbgr2Rb xqJpE8ZjO2FNM1BBZqv29BXFz/qeVw0uTYBLMev0dFeGh/cQBQ0nnjoWMuLYjzdqpTexbcY8EULdb EL+DH3DQ==; Received: from [2a01:799:95f:4600:cca0:57ac:c55d:a485] (port=62895) by smtp.domeneshop.no with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lMGJ0-0006nk-05; Tue, 16 Mar 2021 21:28:42 +0100 Subject: Re: [PATCH v8 3/3] drm: Add GUD USB Display driver To: Peter Stuge References: <20210313112545.37527-1-noralf@tronnes.org> <20210313112545.37527-4-noralf@tronnes.org> <20210315193729.10166.qmail@stuge.se> From: =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= Message-ID: Date: Tue, 16 Mar 2021 21:28:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210315193729.10166.qmail@stuge.se> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: hudson@trmm.net, markus@raatikainen.cc, Daniel Vetter , linux-usb@vger.kernel.org, dri-devel@lists.freedesktop.org, th020394@gmail.com, lkundrak@v3.sk, pontus.fuchs@gmail.com, sam@ravnborg.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" CgpEZW4gMTUuMDMuMjAyMSAyMC4zNywgc2tyZXYgUGV0ZXIgU3R1Z2U6Cj4gSGkgTm9yYWxmLAo+ IAo+IHN1cGVyIGZhaXIgY2FsbCB3aXRoIHRoZSBCRSB0ZXN0aW5nLCBsZXQncyBob3BlIGZvciBz b21lIHRlc3Rpbmcgc29vbmlzaC4KPiAKPiAKPiBJIHdhcyB0aGlua2luZyBhYm91dCBteSBkZXZp Y2UgZG9pbmcgcHJvdG9jb2wgU1RBTEwgd2hlbiBJIHRyeSB0bwo+IHJldHVybiAwIGJ5dGVzLCBh bmQgd2hpbGUgaXQgKmlzKiBhIGJ1ZyBpbiBteSBkZXZpY2UsIGZyb20gYSBzdGFuZGFyZHMKPiBw b2ludCBvZiB2aWV3IGl0J3MgYWN0dWFsbHkgY29tcGxldGVseSB2YWxpZCwgaWYgbm90IGV4cGVj dGVkOgo+IAo+IC0tODwtLSB1c2JfMjAucGRmIDguNS4zLjQgU1RBTEwgSGFuZHNoYWtlcyBSZXR1 cm5lZCBieSBDb250cm9sIFBpcGVzCj4gSWYgdGhlIGRldmljZSBpcyB1bmFibGUgdG8gY29tcGxl dGUgYSBjb21tYW5kLCBpdCByZXR1cm5zIGEgU1RBTEwgaW4gdGhlCj4gRGF0YSBhbmQvb3IgU3Rh dHVzIHN0YWdlcyBvZiB0aGUgY29udHJvbCB0cmFuc2Zlci4gVW5saWtlIHRoZSBjYXNlIG9mIGEK PiBmdW5jdGlvbmFsIHN0YWxsLCBwcm90b2NvbCBzdGFsbCBkb2VzIG5vdCBpbmRpY2F0ZSBhbiBl cnJvciB3aXRoIHRoZSBkZXZpY2UuCj4gLS0+OC0tCj4gCj4gSSB0aGluayBpdCdzIGZhaXIgdG8g c2F5IHRoYXQgYSBkZXZpY2UgY2FuJ3QgY29tcGxldGUgdGhlIGNvbW1hbmQKPiB3aGVuIGl0IGhh cyBubyBkYXRhIHRvIHJldHVybi4KPiAKPiBTbyBob3cgYWJvdXQgYWxsb3dpbmcgU1RBTEwgZm9y IG9wdGlvbmFsIEdVRF9SRVFfR0VUXzpzIHRvIG1lYW4gdGhlIHNhbWUKPiBhcyBhIDAgYnl0ZSBy ZXNwb25zZT8gU2hvdWxkIEkgcHJvcG9zZSBhIHNlcGFyYXRlIHBhdGNoIGZvciBpdCBsYXRlcj8K PiAKClllYWgsIHRoYXQgd291bGQgYmUgbmljZS4KCldlIGNhbid0IGxvb2sgZm9yIC1FUElQRSB0 aG91Z2gsIHNpbmNlIEdVRF9SRVFfR0VUX1NUQVRVUyB3aWxsIGFzayBmb3IKdGhlIGFjdHVhbCBl cnJvci4gV2UgaGF2ZSB0aGVzZSB0byBjaG9vc2UgZnJvbSBjdXJyZW50bHk6CgogICNkZWZpbmUg R1VEX1NUQVRVU19PSwkJCQkweDAwCiAgI2RlZmluZSBHVURfU1RBVFVTX0JVU1kJCQkweDAxCiAg I2RlZmluZSBHVURfU1RBVFVTX1JFUVVFU1RfTk9UX1NVUFBPUlRFRAkweDAyCiAgI2RlZmluZSBH VURfU1RBVFVTX1BST1RPQ09MX0VSUk9SCQkweDAzCiAgI2RlZmluZSBHVURfU1RBVFVTX0lOVkFM SURfUEFSQU1FVEVSCQkweDA0CiAgI2RlZmluZSBHVURfU1RBVFVTX0VSUk9SCQkJMHgwNQoKTWF5 YmUgUkVRVUVTVF9OT1RfU1VQUE9SVEVEICgtRU9QTk9UU1VQUCkgb3IgYWRkIGEgbW9yZSBmaXR0 aW5nIHN0YXR1cwp2YWx1ZS4KCklmIHRoZSBkcml2ZXIgc2VlcyAtRVBJUEUgdGhpcyBtZWFucyB0 aGF0IHRoZSBkZXZpY2UgaGFzIGZhaWxlZCB0bwpyZXNwb25kIHByb3Blcmx5LiBTZWUgZ3VkX3Vz Yl90cmFuc2ZlcigpLgoKPiAKPiBOb3JhbGYgVHLDuG5uZXMgd3JvdGU6Cj4+ICsrKyBiL2RyaXZl cnMvZ3B1L2RybS9ndWQvZ3VkX2Nvbm5lY3Rvci5jCj4gLi4KPj4gK3N0YXRpYyBpbnQgZ3VkX2Nv bm5lY3Rvcl9nZXRfbW9kZXMoc3RydWN0IGRybV9jb25uZWN0b3IgKmNvbm5lY3RvcikKPiAuLgo+ PiArCXJldCA9IGd1ZF91c2JfZ2V0KGdkcm0sIEdVRF9SRVFfR0VUX0NPTk5FQ1RPUl9FRElELCBj b25uZWN0b3ItPmluZGV4LAo+PiArCQkJICBlZGlkX2N0eC5idWYsIEdVRF9DT05ORUNUT1JfTUFY X0VESURfTEVOKTsKPiAKPiBpZiAocmV0ID09IC1FUElQRSkKPiAJcmV0ID0gMDsKPiAKPj4gKwlp ZiAocmV0ID4gMCAmJiByZXQgJSBFRElEX0xFTkdUSCkgewo+PiArCQlndWRfY29ubl9lcnIoY29u bmVjdG9yLCAiSW52YWxpZCBFRElEIHNpemUiLCByZXQpOwo+PiArCX0gZWxzZSBpZiAocmV0ID4g MCkgewo+PiArCQllZGlkX2N0eC5sZW4gPSByZXQ7Cj4+ICsJCWVkaWQgPSBkcm1fZG9fZ2V0X2Vk aWQoY29ubmVjdG9yLCBndWRfY29ubmVjdG9yX2dldF9lZGlkX2Jsb2NrLCAmZWRpZF9jdHgpOwo+ PiArCX0KPiAKPiAKPj4gK3N0YXRpYyBpbnQgZ3VkX2Nvbm5lY3Rvcl9hZGRfcHJvcGVydGllcyhz dHJ1Y3QgZ3VkX2RldmljZSAqZ2RybSwgc3RydWN0IGd1ZF9jb25uZWN0b3IgKmdjb25uKQo+IC4u Cj4+ICsJcmV0ID0gZ3VkX3VzYl9nZXQoZ2RybSwgR1VEX1JFUV9HRVRfQ09OTkVDVE9SX1BST1BF UlRJRVMsIGNvbm5lY3Rvci0+aW5kZXgsCj4+ICsJCQkgIHByb3BlcnRpZXMsIEdVRF9DT05ORUNU T1JfUFJPUEVSVElFU19NQVhfTlVNICogc2l6ZW9mKCpwcm9wZXJ0aWVzKSk7Cj4gCj4gaWYgKHJl dCA9PSAtRVBJUEUpCj4gCXJldCA9IDA7Cj4gCj4+ICsJaWYgKHJldCA8PSAwKQo+PiArCQlnb3Rv IG91dDsKPj4gKwlpZiAocmV0ICUgc2l6ZW9mKCpwcm9wZXJ0aWVzKSkgewo+PiArCQlyZXQgPSAt RUlPOwo+PiArCQlnb3RvIG91dDsKPj4gKwl9Cj4gCj4gCj4+ICsrKyBiL2RyaXZlcnMvZ3B1L2Ry bS9ndWQvZ3VkX2Rydi5jCj4gLi4KPiAuLgo+PiArc3RhdGljIGludCBndWRfZ2V0X3Byb3BlcnRp ZXMoc3RydWN0IGd1ZF9kZXZpY2UgKmdkcm0pCj4gLi4KPj4gKwlyZXQgPSBndWRfdXNiX2dldChn ZHJtLCBHVURfUkVRX0dFVF9QUk9QRVJUSUVTLCAwLAo+PiArCQkJICBwcm9wZXJ0aWVzLCBHVURf UFJPUEVSVElFU19NQVhfTlVNICogc2l6ZW9mKCpwcm9wZXJ0aWVzKSk7Cj4gCj4gaWYgKHJldCA9 PSAtRVBJUEUpCj4gCXJldCA9IDA7Cj4gCj4+ICsJaWYgKHJldCA8PSAwKQo+PiArCQlnb3RvIG91 dDsKPj4gKwlpZiAocmV0ICUgc2l6ZW9mKCpwcm9wZXJ0aWVzKSkgewo+PiArCQlyZXQgPSAtRUlP Owo+PiArCQlnb3RvIG91dDsKPj4gKwl9Cj4gCj4gCj4gVGhlbiBJIGxvb2tlZCB3aGV0aGVyIGEg ZGV2aWNlIGNvdWxkIGNhdXNlIHRyb3VibGUgaW4gdGhlIGRyaXZlciBieQo+IHJldHVybmluZyBj b21wbGV4L3VuZXhwZWN0ZWQgZGF0YSwgYW5kIGZvdW5kIHRoaXM6Cj4gCj4+ICtzdGF0aWMgaW50 IGd1ZF9wcm9iZShzdHJ1Y3QgdXNiX2ludGVyZmFjZSAqaW50ZiwgY29uc3Qgc3RydWN0IHVzYl9k ZXZpY2VfaWQgKmlkKQo+IC4uCj4+ICsJLyogQWRkIHJvb20gZm9yIGVtdWxhdGVkIFhSR0I4ODg4 ICovCj4+ICsJZm9ybWF0cyA9IGRldm1fa21hbGxvY19hcnJheShkZXYsIEdVRF9GT1JNQVRTX01B WF9OVU0gKyAxLCBzaXplb2YoKmZvcm1hdHMpLCBHRlBfS0VSTkVMKTsKPiAKPiBJdCBsb29rcyBs aWtlIHRoaXMgKzEgYW5kIHRoZSB3YXkgeHJnYjg4ODhfZW11bGF0aW9uX2Zvcm1hdCB3b3JrcyBt ZWFucwo+IHRoYXQgYW4gaW50ZXJmYWNlIHdpbGwgbm90IGFsd2F5cyB3b3JrIGNvcnJlY3RseSBp ZiBtdWx0aXBsZSBlbXVsYXRlZAo+IGZvcm1hdHMgKFIxLCBYUkdCMTExMSwgUkdCNTY1KSBhcmUg cmV0dXJuZWQsIGJlY2F1c2Ugb25seSBvbmUgZW11bGF0ZWQKPiBtb2RlIGlzIGFkZGVkIGFmdGVy IHRoZSBsb29wLCB3aXRoIHN0cnVjdCBkcm1fZm9ybWF0X2luZm8gZm9yIHRoZSBsYXN0Cj4gZW11 bGF0ZWQgZm9ybWF0IHJldHVybmVkIGJ5IHRoZSBkZXZpY2UuIFNvIHVzZXJzcGFjZSB3b3VsZCBv bmx5IHNlZSB0aGUKPiBsYXN0IGVtdWxhdGVkIG1vZGUgYW5kIHRoZSBidWxrIG91dHB1dCB3b3Vs ZCBvbmx5IGV2ZXIgdXNlIHRoYXQKPiBwYXJ0aWN1bGFyIHBpeGVsIGZvcm1hdCwgYW55IGVhcmxp ZXIgb25lcyB3b3VsZCBiZSB1bmF2YWlsYWJsZT8KPiAKPiBJZiB0aGlzIGlzIEVXT05URklYIHRo ZW4gaG93IGFib3V0IGFkZGluZyBhbiBlcnJvciBtZXNzYWdlIGlmIG11bHRpcGxlCj4gZW11bGF0 ZWQgbW9kZXMgYXJlIHJldHVybmVkIGFuZCBpZ25vcmUgYWxsIGJ1dCB0aGUgZmlyc3QsIHJhdGhl ciB0aGFuCj4gYWxsIGJ1dCB0aGUgbGFzdD8KPiAKCkl0IGRvZXMgaWdub3JlIGFsbCBidXQgdGhl IGZpcnN0Li4uIGRvZXNuJ3QgaXQ/CgpZb3UgY291bGQgbWFrZSBhIHBhdGNoIGlmIHlvdSBjYXJl IGFib3V0IHRoaXM6CgoJCWNhc2UgR1VEX0RSTV9GT1JNQVRfUjE6CgkJCWZhbGx0aHJvdWdoOwoJ CWNhc2UgR1VEX0RSTV9GT1JNQVRfWFJHQjExMTE6CgkJCWlmICgheHJnYjg4ODhfZW11bGF0aW9u X2Zvcm1hdCkKCQkJCXhyZ2I4ODg4X2VtdWxhdGlvbl9mb3JtYXQgPSBpbmZvOworCQkJZWxzZQor CQkJCWRldl9lcnIoZGV2LCAiLi4uIik7CgkJCWJyZWFrOwoKSXQncyBvbmx5IG5lZWRlZCBmb3Ig dGhlIGZvcm1hdHMgdGhhdCBhcmUgbm90IGV4cG9ydGVkIHRvIHVzZXJzcGFjZS4KCj4gCj4gUmVs YXRlZDogQ2FuIHVzZXJzcGFjZSBmaW5kIG91dCB3aGljaCBHVURfUElYRUxfRk9STUFUXyogaXMg YmVoaW5kIGFuCj4gZW11bGF0ZWQgZm9ybWF0PyBJdCdzIG5lZWRlZCB0byBkZWNpZGUgaG93IHRo ZSBlbXVsYXRlZCBmcmFtZWJ1ZmZlcgo+IHNob3VsZCBiZSB1c2VkLCBpbiBwYXJ0aWN1bGFyIHRv IG5vdCB1c2UgRyBvciBCIGlmIEdVRF9QSVhFTF9GT1JNQVRfUjEuCj4gCgpUaGVyZSdzIG5vIHdh eSBmb3IgdXNlcnNwYWNlIHRvIGtub3cgdGhhdC4gZHJtX2ZiX3hyZ2I4ODg4X3RvX2dyYXk4KCkK dXNlcyBJVFUgQlQuNjAxIHJnYiBjb252ZXJzaW9uIHNvIHVzZXJzcGFjZSBkb2Vzbid0IGhhdmUg dG8ga25vdyB3aGljaApjb2xvcnMgdG8gdXNlLCBidXQgb2ZjIGl0IHdpbGwgbmVlZCB0byBrbm93 IHRoZXJlJ3MgYSBtb25vY2hyb21lIGRpc3BsYXkKZm9yIGl0IHRvIGxvb2sgZ29vZC4KClhSR0I4 ODg4IGlzIHRoZSBvbmx5IGZvcm1hdCB0aGF0IGlzIGFsbG93ZWQgdG8gYmUgZW11bGF0ZWQgc2lu Y2Ugc29tZQp1c2Vyc3BhY2Ugb25seSBzdXBwb3J0cyB0aGF0IG9uZSBmb3JtYXQuIFNvIHdlIGNh bid0IGhhdmUgYSBkZXZpY2UgdGhhdApzdXBwb3J0cyBib3RoIFIxIGFuZCBYUkdCMTExMS4KCj4g Cj4+ICsJCXN3aXRjaCAoZm9ybWF0KSB7Cj4+ICsJCWNhc2UgR1VEX0RSTV9GT1JNQVRfUjE6Cj4+ ICsJCQlmYWxsdGhyb3VnaDsKPj4gKwkJY2FzZSBHVURfRFJNX0ZPUk1BVF9YUkdCMTExMToKPj4g KwkJCWlmICgheHJnYjg4ODhfZW11bGF0aW9uX2Zvcm1hdCkKPj4gKwkJCQl4cmdiODg4OF9lbXVs YXRpb25fZm9ybWF0ID0gaW5mbzsKPj4gKwkJCWJyZWFrOwo+PiArCQljYXNlIERSTV9GT1JNQVRf UkdCNTY1Ogo+PiArCQkJcmdiNTY1X3N1cHBvcnRlZCA9IHRydWU7Cj4+ICsJCQlpZiAoIXhyZ2I4 ODg4X2VtdWxhdGlvbl9mb3JtYXQpCj4+ICsJCQkJeHJnYjg4ODhfZW11bGF0aW9uX2Zvcm1hdCA9 IGluZm87Cj4+ICsJCQlicmVhazsKPiAKPiBDb3VsZCBSR0I1NjUgZ28gYmVmb3JlIFhSR0IxMTEg KG9yIFIxKSBhbmQgYWxzbyBmYWxsdGhyb3VnaDsgaW4gdGhpcwo+IGNvbnN0cnVjdD8gTm90IHRl cnJpYmx5IGltcG9ydGFudCwgYnV0IHRoZSByZXBldGl0aW9uIGNhdWdodCBteSBleWUuCj4gCgpJ dCBjb3VsZCBidXQgSSdkIGxpa2UgdG8ga2VlcCB0aGUgaW5jcmVhc2luZyBiaXRzLXBlci1waXhl bCBvcmRlci4KCj4gCj4gVGhlbiwgaW4gZ3VkX2Nvbm5lY3Rvci5jIEkgc2F3IHRoaXMsIHdoaWNo IHN1cnByaXNlZCBtZToKPiAKPiAraW50IGd1ZF9jb25uZWN0b3JfZmlsbF9wcm9wZXJ0aWVzKHN0 cnVjdCBkcm1fY29ubmVjdG9yX3N0YXRlICpjb25uZWN0b3Jfc3RhdGUsCj4gLi4KPiArCQlpZiAo cHJvcCA9PSBHVURfUFJPUEVSVFlfQkFDS0xJR0hUX0JSSUdIVE5FU1MpIHsKPiArCQkJdmFsID0g Y29ubmVjdG9yX3N0YXRlLT50di5icmlnaHRuZXNzOwo+ICsJCX0gZWxzZSB7Cj4gCj4gV2h5IGlz IHRoaXMgdXNpbmcgdHYuYnJpZ2h0bmVzcyByYXRoZXIgdGhhbiBzYXkgZ2Nvbm4tPmluaXRpYWxf YnJpZ2h0bmVzcz8KPiAKPiBJdCBsb29rcyBsaWtlIHRoZSBlbmQgcmVzdWx0IG1pZ2h0IGJlIHRo ZSBzYW1lIGJlY2F1c2UgdHYuYnJpZ2h0bmVzcyBpcwo+IHNldCB0byBnY29ubi0+aW5pdGlhbF9i cmlnaHRuZXNzIGluIGd1ZF9jb25uZWN0b3JfcmVzZXQoKSBidXQgaXQncyBhCj4gbGl0dGxlIGNv bmZ1c2luZyB0byBtZSwgc2luY2UgYSBHVUQgYmFja2xpZ2h0IGlzbid0IGEgZHJtL1RWIHRoaW5n Pwo+IAoKSSdtIHJldXNpbmcgdGhlIHR2IHN0YXRlIHByb3BlcnR5IHNpbmNlIHRoYXQgc2F2ZXMg bWUgZnJvbSBzdWJjbGFzc2luZwp0aGUgY29ubmVjdG9yIHN0YXRlLiBJIHdhbnQgdG8gaGF2ZSB0 aGUgdmFsdWUgaW4gdGhlIHN0YXRlIGJlY2F1c2UgdGhhdAptYWtlcyBpdCBsZXNzIG9mIGEgc3Bl Y2lhbCBjYXNlLiBTb21lIHRpbWUgaW4gdGhlIGZ1dHVyZSBEUk0gd2lsbCBoYXZlCnByb3BlciBi YWNrbGlnaHQgc3VwcG9ydCBhcyBhIERSTSBwcm9wZXJ0eSwgYnV0IHNvIGZhciBubyBvbmUgaGFz IGJlZW4Kd2lsbGluZyB0byBpbnZlc3QgdGhlIG5lY2Vzc2FyeSB0aW1lIGFuZCBlZmZvcnQgdG8g bWFrZSBpdCBoYXBwZW4uCgpOb3JhbGYuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZy ZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RyaS1kZXZlbAo=