From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752432AbdLSQX5 (ORCPT ); Tue, 19 Dec 2017 11:23:57 -0500 Received: from mx2.suse.de ([195.135.220.15]:58798 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751032AbdLSQXz (ORCPT ); Tue, 19 Dec 2017 11:23:55 -0500 Subject: Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing To: Daniel Vetter Cc: Bartlomiej Zolnierkiewicz , Linux Fbdev development list , michal@markovi.net, sndirsch@suse.com, Oliver Neukum , Takashi Iwai , dri-devel , Linux Kernel Mailing List , =?UTF-8?Q?Bero_Rosenkr=c3=a4nzer?= , philm@manjaro.org References: <20171213194755.3409-1-mstaudt@suse.de> <20171213194755.3409-4-mstaudt@suse.de> <20171213213506.GD26573@phenom.ffwll.local> <20171219122313.GE26573@phenom.ffwll.local> <8bbb0497-4a10-2f81-0040-6e7cd4e7353c@suse.de> <20171219135715.GG26573@phenom.ffwll.local> <8036b6a6-6ed5-2f34-e854-1c397a9f34d4@suse.de> From: Max Staudt Message-ID: <24fd8767-bdf2-0073-2161-a0cf3b61780d@suse.de> Date: Tue, 19 Dec 2017 17:23:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/19/2017 05:02 PM, Daniel Vetter wrote: > On Tue, Dec 19, 2017 at 4:41 PM, Max Staudt wrote: >> On 12/19/2017 02:57 PM, Daniel Vetter wrote: >>> The problem is that defio is totally not how a real driver works. >> >> But they do exist and I can't ignore them. >> >> I'm afraid I don't understand - why are those, such as xenfb, not real drivers? > > I mean kms drivers. The problem is that the magic mapping that fbdev > expects is real pain. Everyone else, including kms, expects an > explicit flush operation. So instead of hacking around even more with > the defio corner cases that don't work, I'm suggesting we just add > that flush operation. At least internally. > > Fixing kms drivers to implement a better defio is probably not a > reasonable investement of time. Ah yes, I understand now, you mean that KMS drivers have explicit flush, and defio is a hack to retrofit such drivers to an API that never supported a flush operation (the fbdev API), but always used to expose the video memory directly. Right? If yes, then I agree. Fixing the defio in the KMS drivers wouldn't even solve my problem - I'd still need to implement flush. So might as well care about the flush straight away, yep! >>> So >>> preferrably bootsplash would use kms directly, and use the explict dirtyfb >>> callback. >> >> Sure, if I'd be hooking into drmcon, that would be great. >> >> But drmcon doesn't exist yet, so it doesn't get us further to talk about a bootsplash on KMS :( >> >> I'm hooking into the in-kernel terminal emulator, because the bootsplash is a functional extension of that. It just happens that fbcon sits on top of FB, so I work with what I get. > > Why do you need a console for a boot splash? You're not drawing > console output afaiui ... And even your current fbdev-based > implementation only interfaces with fbcon insofar as you're making > sure fbcon doesn't wreak your boot splash. Or I'm missing something > somewhere. Errr... true. I'll answer it below, where you ask again. >> In fact, if I define fbops->flush(), defio drivers can still add their own proper flushing function, so everybody wins. I like that, see below. > > tbh I'd forget about ever touching any of the existing fbdev drivers. > Imo just not worth the time investement. Fair point. It's optional anyway, and can still be done (quickly and painlessly) on demand. Since my goal here is making a nice bootsplash, I'll touch as few drivers as I can. >>>> So, what shall I do? As it is, the hack is already specific to devices that really, really need it. >>>> >>>> Would you like me to extend the FB API or not? >>> >>> Yes. Well for real I'd like you to do kms, so maybe you need to explain >>> why exactly you absolutely have to use fbdev (aka which driver isn't >>> supported by drm that you want to enable this on). >> >> See Oliver's reply - we have plenty of fb-only systems deployed in the real world. Think Xen. Think AArch64 with efifb. Think any system before the KMS driver is loaded (which is a case that the splash is supposed to handle). > > And you need a real pretty boot-splash on those? That sounds all like > servers, and I haven't yet seen a request for real pretty&fast boot > splash for servers. Yeah, every little helps. And the vesafb/efifb case is valid for all of the desktop/laptop machines as well. >> Also, where would I hook into KMS, were I to implement it on top of KMS right now? I'm not working on top of FB per se, but on top of fbcon. So in a KMS world I wouldn't work on KMS itself, but on top of... drmcon, which doesn't exist. > > Hm, I guess I need to double check again, but I don't get why you need > to sit on top of a console for the boot splash. I mean I understand > that you need to shut up the console when the boot splash is on, but > from a quick look you're not using fbcon to render anything or > otherwise tie into it. Where's the connection? Fair point. So the case you're looking at is someone who wants to have a bootsplash, yet doesn't want to have fbcon. Correct? I agree, this is a case that is not covered with the current code. However such a generic solution would require the definition of new semantics of both fbcon and the bootsplash fighting for the same FB device - well, as long as no graphical application uses it. Urgh... It is a lot simpler to just dual-purpose fbcon, since it knows when to shut up on its own. And I simply assume that those who load a bootsplash file into their initramfs won't be short a few bytes to compile in fbcon as well. So... I've hooked into fbcon for simplicity's sake, so I don't have up to three parties fighting for the same device, and so I don't have to define semantics and interfaces to solve that conflict. Max From mboxrd@z Thu Jan 1 00:00:00 1970 From: Max Staudt Date: Tue, 19 Dec 2017 16:23:52 +0000 Subject: Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing Message-Id: <24fd8767-bdf2-0073-2161-a0cf3b61780d@suse.de> List-Id: References: <20171213194755.3409-1-mstaudt@suse.de> <20171213194755.3409-4-mstaudt@suse.de> <20171213213506.GD26573@phenom.ffwll.local> <20171219122313.GE26573@phenom.ffwll.local> <8bbb0497-4a10-2f81-0040-6e7cd4e7353c@suse.de> <20171219135715.GG26573@phenom.ffwll.local> <8036b6a6-6ed5-2f34-e854-1c397a9f34d4@suse.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Daniel Vetter Cc: Linux Fbdev development list , michal@markovi.net, Bartlomiej Zolnierkiewicz , sndirsch@suse.com, Oliver Neukum , Takashi Iwai , dri-devel , Linux Kernel Mailing List , philm@manjaro.org, =?UTF-8?Q?Bero_Rosenkr=c3=a4nzer?= On 12/19/2017 05:02 PM, Daniel Vetter wrote: > On Tue, Dec 19, 2017 at 4:41 PM, Max Staudt wrote: >> On 12/19/2017 02:57 PM, Daniel Vetter wrote: >>> The problem is that defio is totally not how a real driver works. >> >> But they do exist and I can't ignore them. >> >> I'm afraid I don't understand - why are those, such as xenfb, not real drivers? > > I mean kms drivers. The problem is that the magic mapping that fbdev > expects is real pain. Everyone else, including kms, expects an > explicit flush operation. So instead of hacking around even more with > the defio corner cases that don't work, I'm suggesting we just add > that flush operation. At least internally. > > Fixing kms drivers to implement a better defio is probably not a > reasonable investement of time. Ah yes, I understand now, you mean that KMS drivers have explicit flush, and defio is a hack to retrofit such drivers to an API that never supported a flush operation (the fbdev API), but always used to expose the video memory directly. Right? If yes, then I agree. Fixing the defio in the KMS drivers wouldn't even solve my problem - I'd still need to implement flush. So might as well care about the flush straight away, yep! >>> So >>> preferrably bootsplash would use kms directly, and use the explict dirtyfb >>> callback. >> >> Sure, if I'd be hooking into drmcon, that would be great. >> >> But drmcon doesn't exist yet, so it doesn't get us further to talk about a bootsplash on KMS :( >> >> I'm hooking into the in-kernel terminal emulator, because the bootsplash is a functional extension of that. It just happens that fbcon sits on top of FB, so I work with what I get. > > Why do you need a console for a boot splash? You're not drawing > console output afaiui ... And even your current fbdev-based > implementation only interfaces with fbcon insofar as you're making > sure fbcon doesn't wreak your boot splash. Or I'm missing something > somewhere. Errr... true. I'll answer it below, where you ask again. >> In fact, if I define fbops->flush(), defio drivers can still add their own proper flushing function, so everybody wins. I like that, see below. > > tbh I'd forget about ever touching any of the existing fbdev drivers. > Imo just not worth the time investement. Fair point. It's optional anyway, and can still be done (quickly and painlessly) on demand. Since my goal here is making a nice bootsplash, I'll touch as few drivers as I can. >>>> So, what shall I do? As it is, the hack is already specific to devices that really, really need it. >>>> >>>> Would you like me to extend the FB API or not? >>> >>> Yes. Well for real I'd like you to do kms, so maybe you need to explain >>> why exactly you absolutely have to use fbdev (aka which driver isn't >>> supported by drm that you want to enable this on). >> >> See Oliver's reply - we have plenty of fb-only systems deployed in the real world. Think Xen. Think AArch64 with efifb. Think any system before the KMS driver is loaded (which is a case that the splash is supposed to handle). > > And you need a real pretty boot-splash on those? That sounds all like > servers, and I haven't yet seen a request for real pretty&fast boot > splash for servers. Yeah, every little helps. And the vesafb/efifb case is valid for all of the desktop/laptop machines as well. >> Also, where would I hook into KMS, were I to implement it on top of KMS right now? I'm not working on top of FB per se, but on top of fbcon. So in a KMS world I wouldn't work on KMS itself, but on top of... drmcon, which doesn't exist. > > Hm, I guess I need to double check again, but I don't get why you need > to sit on top of a console for the boot splash. I mean I understand > that you need to shut up the console when the boot splash is on, but > from a quick look you're not using fbcon to render anything or > otherwise tie into it. Where's the connection? Fair point. So the case you're looking at is someone who wants to have a bootsplash, yet doesn't want to have fbcon. Correct? I agree, this is a case that is not covered with the current code. However such a generic solution would require the definition of new semantics of both fbcon and the bootsplash fighting for the same FB device - well, as long as no graphical application uses it. Urgh... It is a lot simpler to just dual-purpose fbcon, since it knows when to shut up on its own. And I simply assume that those who load a bootsplash file into their initramfs won't be short a few bytes to compile in fbcon as well. So... I've hooked into fbcon for simplicity's sake, so I don't have up to three parties fighting for the same device, and so I don't have to define semantics and interfaces to solve that conflict. Max From mboxrd@z Thu Jan 1 00:00:00 1970 From: Max Staudt Subject: Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing Date: Tue, 19 Dec 2017 17:23:52 +0100 Message-ID: <24fd8767-bdf2-0073-2161-a0cf3b61780d@suse.de> References: <20171213194755.3409-1-mstaudt@suse.de> <20171213194755.3409-4-mstaudt@suse.de> <20171213213506.GD26573@phenom.ffwll.local> <20171219122313.GE26573@phenom.ffwll.local> <8bbb0497-4a10-2f81-0040-6e7cd4e7353c@suse.de> <20171219135715.GG26573@phenom.ffwll.local> <8036b6a6-6ed5-2f34-e854-1c397a9f34d4@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by gabe.freedesktop.org (Postfix) with ESMTPS id 53B3A6E14F for ; Tue, 19 Dec 2017 16:23:55 +0000 (UTC) In-Reply-To: Content-Language: en-US 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: Linux Fbdev development list , michal@markovi.net, Bartlomiej Zolnierkiewicz , sndirsch@suse.com, Oliver Neukum , Takashi Iwai , dri-devel , Linux Kernel Mailing List , philm@manjaro.org, =?UTF-8?Q?Bero_Rosenkr=c3=a4nzer?= List-Id: dri-devel@lists.freedesktop.org T24gMTIvMTkvMjAxNyAwNTowMiBQTSwgRGFuaWVsIFZldHRlciB3cm90ZToKPiBPbiBUdWUsIERl YyAxOSwgMjAxNyBhdCA0OjQxIFBNLCBNYXggU3RhdWR0IDxtc3RhdWR0QHN1c2UuZGU+IHdyb3Rl Ogo+PiBPbiAxMi8xOS8yMDE3IDAyOjU3IFBNLCBEYW5pZWwgVmV0dGVyIHdyb3RlOgo+Pj4gVGhl IHByb2JsZW0gaXMgdGhhdCBkZWZpbyBpcyB0b3RhbGx5IG5vdCBob3cgYSByZWFsIGRyaXZlciB3 b3Jrcy4KPj4KPj4gQnV0IHRoZXkgZG8gZXhpc3QgYW5kIEkgY2FuJ3QgaWdub3JlIHRoZW0uCj4+ Cj4+IEknbSBhZnJhaWQgSSBkb24ndCB1bmRlcnN0YW5kIC0gd2h5IGFyZSB0aG9zZSwgc3VjaCBh cyB4ZW5mYiwgbm90IHJlYWwgZHJpdmVycz8KPiAKPiBJIG1lYW4ga21zIGRyaXZlcnMuIFRoZSBw cm9ibGVtIGlzIHRoYXQgdGhlIG1hZ2ljIG1hcHBpbmcgdGhhdCBmYmRldgo+IGV4cGVjdHMgaXMg cmVhbCBwYWluLiBFdmVyeW9uZSBlbHNlLCBpbmNsdWRpbmcga21zLCBleHBlY3RzIGFuCj4gZXhw bGljaXQgZmx1c2ggb3BlcmF0aW9uLiBTbyBpbnN0ZWFkIG9mIGhhY2tpbmcgYXJvdW5kIGV2ZW4g bW9yZSB3aXRoCj4gdGhlIGRlZmlvIGNvcm5lciBjYXNlcyB0aGF0IGRvbid0IHdvcmssIEknbSBz dWdnZXN0aW5nIHdlIGp1c3QgYWRkCj4gdGhhdCBmbHVzaCBvcGVyYXRpb24uIEF0IGxlYXN0IGlu dGVybmFsbHkuCj4gCj4gRml4aW5nIGttcyBkcml2ZXJzIHRvIGltcGxlbWVudCBhIGJldHRlciBk ZWZpbyBpcyBwcm9iYWJseSBub3QgYQo+IHJlYXNvbmFibGUgaW52ZXN0ZW1lbnQgb2YgdGltZS4K CkFoIHllcywgSSB1bmRlcnN0YW5kIG5vdywgeW91IG1lYW4gdGhhdCBLTVMgZHJpdmVycyBoYXZl IGV4cGxpY2l0IGZsdXNoLCBhbmQgZGVmaW8gaXMgYSBoYWNrIHRvIHJldHJvZml0IHN1Y2ggZHJp dmVycyB0byBhbiBBUEkgdGhhdCBuZXZlciBzdXBwb3J0ZWQgYSBmbHVzaCBvcGVyYXRpb24gKHRo ZSBmYmRldiBBUEkpLCBidXQgYWx3YXlzIHVzZWQgdG8gZXhwb3NlIHRoZSB2aWRlbyBtZW1vcnkg ZGlyZWN0bHkuIFJpZ2h0PwoKSWYgeWVzLCB0aGVuIEkgYWdyZWUuIEZpeGluZyB0aGUgZGVmaW8g aW4gdGhlIEtNUyBkcml2ZXJzIHdvdWxkbid0IGV2ZW4gc29sdmUgbXkgcHJvYmxlbSAtIEknZCBz dGlsbCBuZWVkIHRvIGltcGxlbWVudCBmbHVzaC4gU28gbWlnaHQgYXMgd2VsbCBjYXJlIGFib3V0 IHRoZSBmbHVzaCBzdHJhaWdodCBhd2F5LCB5ZXAhCgoKPj4+IFNvCj4+PiBwcmVmZXJyYWJseSBi b290c3BsYXNoIHdvdWxkIHVzZSBrbXMgZGlyZWN0bHksIGFuZCB1c2UgdGhlIGV4cGxpY3QgZGly dHlmYgo+Pj4gY2FsbGJhY2suCj4+Cj4+IFN1cmUsIGlmIEknZCBiZSBob29raW5nIGludG8gZHJt Y29uLCB0aGF0IHdvdWxkIGJlIGdyZWF0Lgo+Pgo+PiBCdXQgZHJtY29uIGRvZXNuJ3QgZXhpc3Qg eWV0LCBzbyBpdCBkb2Vzbid0IGdldCB1cyBmdXJ0aGVyIHRvIHRhbGsgYWJvdXQgYSBib290c3Bs YXNoIG9uIEtNUyA6KAo+Pgo+PiBJJ20gaG9va2luZyBpbnRvIHRoZSBpbi1rZXJuZWwgdGVybWlu YWwgZW11bGF0b3IsIGJlY2F1c2UgdGhlIGJvb3RzcGxhc2ggaXMgYSBmdW5jdGlvbmFsIGV4dGVu c2lvbiBvZiB0aGF0LiBJdCBqdXN0IGhhcHBlbnMgdGhhdCBmYmNvbiBzaXRzIG9uIHRvcCBvZiBG Qiwgc28gSSB3b3JrIHdpdGggd2hhdCBJIGdldC4KPiAKPiBXaHkgZG8geW91IG5lZWQgYSBjb25z b2xlIGZvciBhIGJvb3Qgc3BsYXNoPyBZb3UncmUgbm90IGRyYXdpbmcKPiBjb25zb2xlIG91dHB1 dCBhZmFpdWkgLi4uIEFuZCBldmVuIHlvdXIgY3VycmVudCBmYmRldi1iYXNlZAo+IGltcGxlbWVu dGF0aW9uIG9ubHkgaW50ZXJmYWNlcyB3aXRoIGZiY29uIGluc29mYXIgYXMgeW91J3JlIG1ha2lu Zwo+IHN1cmUgZmJjb24gZG9lc24ndCB3cmVhayB5b3VyIGJvb3Qgc3BsYXNoLiBPciBJJ20gbWlz c2luZyBzb21ldGhpbmcKPiBzb21ld2hlcmUuCgpFcnJyLi4uIHRydWUuIEknbGwgYW5zd2VyIGl0 IGJlbG93LCB3aGVyZSB5b3UgYXNrIGFnYWluLgoKCj4+IEluIGZhY3QsIGlmIEkgZGVmaW5lIGZi b3BzLT5mbHVzaCgpLCBkZWZpbyBkcml2ZXJzIGNhbiBzdGlsbCBhZGQgdGhlaXIgb3duIHByb3Bl ciBmbHVzaGluZyBmdW5jdGlvbiwgc28gZXZlcnlib2R5IHdpbnMuIEkgbGlrZSB0aGF0LCBzZWUg YmVsb3cuCj4gCj4gdGJoIEknZCBmb3JnZXQgYWJvdXQgZXZlciB0b3VjaGluZyBhbnkgb2YgdGhl IGV4aXN0aW5nIGZiZGV2IGRyaXZlcnMuCj4gSW1vIGp1c3Qgbm90IHdvcnRoIHRoZSB0aW1lIGlu dmVzdGVtZW50LgoKRmFpciBwb2ludC4gSXQncyBvcHRpb25hbCBhbnl3YXksIGFuZCBjYW4gc3Rp bGwgYmUgZG9uZSAocXVpY2tseSBhbmQgcGFpbmxlc3NseSkgb24gZGVtYW5kLgoKU2luY2UgbXkg Z29hbCBoZXJlIGlzIG1ha2luZyBhIG5pY2UgYm9vdHNwbGFzaCwgSSdsbCB0b3VjaCBhcyBmZXcg ZHJpdmVycyBhcyBJIGNhbi4KCgo+Pj4+IFNvLCB3aGF0IHNoYWxsIEkgZG8/IEFzIGl0IGlzLCB0 aGUgaGFjayBpcyBhbHJlYWR5IHNwZWNpZmljIHRvIGRldmljZXMgdGhhdCByZWFsbHksIHJlYWxs eSBuZWVkIGl0Lgo+Pj4+Cj4+Pj4gV291bGQgeW91IGxpa2UgbWUgdG8gZXh0ZW5kIHRoZSBGQiBB UEkgb3Igbm90Pwo+Pj4KPj4+IFllcy4gV2VsbCBmb3IgcmVhbCBJJ2QgbGlrZSB5b3UgdG8gZG8g a21zLCBzbyBtYXliZSB5b3UgbmVlZCB0byBleHBsYWluCj4+PiB3aHkgZXhhY3RseSB5b3UgYWJz b2x1dGVseSBoYXZlIHRvIHVzZSBmYmRldiAoYWthIHdoaWNoIGRyaXZlciBpc24ndAo+Pj4gc3Vw cG9ydGVkIGJ5IGRybSB0aGF0IHlvdSB3YW50IHRvIGVuYWJsZSB0aGlzIG9uKS4KPj4KPj4gU2Vl IE9saXZlcidzIHJlcGx5IC0gd2UgaGF2ZSBwbGVudHkgb2YgZmItb25seSBzeXN0ZW1zIGRlcGxv eWVkIGluIHRoZSByZWFsIHdvcmxkLiBUaGluayBYZW4uIFRoaW5rIEFBcmNoNjQgd2l0aCBlZmlm Yi4gVGhpbmsgYW55IHN5c3RlbSBiZWZvcmUgdGhlIEtNUyBkcml2ZXIgaXMgbG9hZGVkICh3aGlj aCBpcyBhIGNhc2UgdGhhdCB0aGUgc3BsYXNoIGlzIHN1cHBvc2VkIHRvIGhhbmRsZSkuCj4gCj4g QW5kIHlvdSBuZWVkIGEgcmVhbCBwcmV0dHkgYm9vdC1zcGxhc2ggb24gdGhvc2U/IFRoYXQgc291 bmRzIGFsbCBsaWtlCj4gc2VydmVycywgYW5kIEkgaGF2ZW4ndCB5ZXQgc2VlbiBhIHJlcXVlc3Qg Zm9yIHJlYWwgcHJldHR5JmZhc3QgYm9vdAo+IHNwbGFzaCBmb3Igc2VydmVycy4KClllYWgsIGV2 ZXJ5IGxpdHRsZSBoZWxwcy4KCkFuZCB0aGUgdmVzYWZiL2VmaWZiIGNhc2UgaXMgdmFsaWQgZm9y IGFsbCBvZiB0aGUgZGVza3RvcC9sYXB0b3AgbWFjaGluZXMgYXMgd2VsbC4KCgo+PiBBbHNvLCB3 aGVyZSB3b3VsZCBJIGhvb2sgaW50byBLTVMsIHdlcmUgSSB0byBpbXBsZW1lbnQgaXQgb24gdG9w IG9mIEtNUyByaWdodCBub3c/IEknbSBub3Qgd29ya2luZyBvbiB0b3Agb2YgRkIgcGVyIHNlLCBi dXQgb24gdG9wIG9mIGZiY29uLiBTbyBpbiBhIEtNUyB3b3JsZCBJIHdvdWxkbid0IHdvcmsgb24g S01TIGl0c2VsZiwgYnV0IG9uIHRvcCBvZi4uLiBkcm1jb24sIHdoaWNoIGRvZXNuJ3QgZXhpc3Qu Cj4gCj4gSG0sIEkgZ3Vlc3MgSSBuZWVkIHRvIGRvdWJsZSBjaGVjayBhZ2FpbiwgYnV0IEkgZG9u J3QgZ2V0IHdoeSB5b3UgbmVlZAo+IHRvIHNpdCBvbiB0b3Agb2YgYSBjb25zb2xlIGZvciB0aGUg Ym9vdCBzcGxhc2guIEkgbWVhbiBJIHVuZGVyc3RhbmQKPiB0aGF0IHlvdSBuZWVkIHRvIHNodXQg dXAgdGhlIGNvbnNvbGUgd2hlbiB0aGUgYm9vdCBzcGxhc2ggaXMgb24sIGJ1dAo+IGZyb20gYSBx dWljayBsb29rIHlvdSdyZSBub3QgdXNpbmcgZmJjb24gdG8gcmVuZGVyIGFueXRoaW5nIG9yCj4g b3RoZXJ3aXNlIHRpZSBpbnRvIGl0LiBXaGVyZSdzIHRoZSBjb25uZWN0aW9uPwpGYWlyIHBvaW50 LgoKU28gdGhlIGNhc2UgeW91J3JlIGxvb2tpbmcgYXQgaXMgc29tZW9uZSB3aG8gd2FudHMgdG8g aGF2ZSBhIGJvb3RzcGxhc2gsIHlldCBkb2Vzbid0IHdhbnQgdG8gaGF2ZSBmYmNvbi4gQ29ycmVj dD8KCkkgYWdyZWUsIHRoaXMgaXMgYSBjYXNlIHRoYXQgaXMgbm90IGNvdmVyZWQgd2l0aCB0aGUg Y3VycmVudCBjb2RlLiBIb3dldmVyIHN1Y2ggYSBnZW5lcmljIHNvbHV0aW9uIHdvdWxkIHJlcXVp cmUgdGhlIGRlZmluaXRpb24gb2YgbmV3IHNlbWFudGljcyBvZiBib3RoIGZiY29uIGFuZCB0aGUg Ym9vdHNwbGFzaCBmaWdodGluZyBmb3IgdGhlIHNhbWUgRkIgZGV2aWNlIC0gd2VsbCwgYXMgbG9u ZyBhcyBubyBncmFwaGljYWwgYXBwbGljYXRpb24gdXNlcyBpdC4gVXJnaC4uLiBJdCBpcyBhIGxv dCBzaW1wbGVyIHRvIGp1c3QgZHVhbC1wdXJwb3NlIGZiY29uLCBzaW5jZSBpdCBrbm93cyB3aGVu IHRvIHNodXQgdXAgb24gaXRzIG93bi4KCkFuZCBJIHNpbXBseSBhc3N1bWUgdGhhdCB0aG9zZSB3 aG8gbG9hZCBhIGJvb3RzcGxhc2ggZmlsZSBpbnRvIHRoZWlyIGluaXRyYW1mcyB3b24ndCBiZSBz aG9ydCBhIGZldyBieXRlcyB0byBjb21waWxlIGluIGZiY29uIGFzIHdlbGwuCgpTby4uLiBJJ3Zl IGhvb2tlZCBpbnRvIGZiY29uIGZvciBzaW1wbGljaXR5J3Mgc2FrZSwgc28gSSBkb24ndCBoYXZl IHVwIHRvIHRocmVlIHBhcnRpZXMgZmlnaHRpbmcgZm9yIHRoZSBzYW1lIGRldmljZSwgYW5kIHNv IEkgZG9uJ3QgaGF2ZSB0byBkZWZpbmUgc2VtYW50aWNzIGFuZCBpbnRlcmZhY2VzIHRvIHNvbHZl IHRoYXQgY29uZmxpY3QuCgoKCk1heApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVl ZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5m by9kcmktZGV2ZWwK