Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1722235imm; Mon, 3 Sep 2018 07:49:22 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYmmIZbJ7+kDSPP0p78E9DuSBPGptStbFt7wwvbwLH2uAUSLQDJveuW7TXyqhVQC9Ec5Y/B X-Received: by 2002:a62:868b:: with SMTP id x133-v6mr26976138pfd.252.1535986162279; Mon, 03 Sep 2018 07:49:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535986162; cv=none; d=google.com; s=arc-20160816; b=vDMBfoQUGi9UtE0BvxayWiIWi2ljZXA/d3yPV9V4V+5z0ZO1yNP+P4GaqJALz+K7Pp tMiDpfrQkcnZ66z3iZ1LsCvhNiBniO0eyUT1xwwCVqRt8kQFyu4zSBlqk0TNel+5wLrU cooenuFu7RsTPmZ7jm7hy27SGZs7vESTGV/l8I9p9iXNWMQ8/le56STUg/xhaML0M9SY QBNQJF+bSDh09n7qbkR5Lr7baaHPhzivxGhELum+XmBDG/iHp4fpOlc5z3nFYjVdnJxO OcbA+Z6b8RFkTfb66ZynkyLKYre9tMGUxAFqphMOEdta383CMQ5O8qXGFOePww3XAUPD MxSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=vI+efUYFl0M3X0GnW2E9xtkZwKm5/VQNepy1Z3Ki1o0=; b=O3Ki+g8E8vPpUpc+RwqvDR4BnucGGoSc8acmo1KvtOUcsUPI9zEadYJa9f3iF8iooT Fx+hZ7SYn3pMTV6RJHu9YMd5SyzUtLARknEtH2TceyujdqBxqAXkYzeWJT8Pnh8+ksCW R0ufE3aoaLxbBlKSP+LiQi/ZVPLKg0BdzpuC4Shy3/BQyOvkm89garoPlakRh7TiktOY a+0lEVNtMxkGPCnozdSIn4BKiSBVcVkoiCuIcoMERwNOgQgheT1IQYgDC/1Jhv/wkdxE yLXVEfZRdPfTRVrGGTBseEMtv/OpjNwrXFJxkJXSPw6o1ZDeUOS32lZudoYYFbrmZy8R HMvw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n19-v6si15772557pgb.3.2018.09.03.07.49.06; Mon, 03 Sep 2018 07:49:22 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726172AbeICTIa (ORCPT + 99 others); Mon, 3 Sep 2018 15:08:30 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:36211 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725969AbeICTIa (ORCPT ); Mon, 3 Sep 2018 15:08:30 -0400 Received: by mail-ed1-f67.google.com with SMTP id f4-v6so988643edq.3 for ; Mon, 03 Sep 2018 07:48:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vI+efUYFl0M3X0GnW2E9xtkZwKm5/VQNepy1Z3Ki1o0=; b=B8uCJaXjzUGEZtflZNPc+FD/n8az+S/h4ops1EX656PthwAkHO4Ri+aFdLZRpS0icY sn2MZMzeN0i8R2pm48bHprxFuhJeOERdAYIDw6CzeRX3sEf3JlnPnNh9zstBsCsm9B9N Q3XnQH+/dboEt+QrkLtY3fmlMCsjV+fo16zeUSqMZ850siilS+vXtqUxV5YKE/EGnrth SI8kX1TMhIDAv+Gn52olecZLIbX0ybRKmKAerMbfL9mlQyjTiy05zrH4SqEIFJPh7VQ7 LTDZzzSkTEvBeosP/28d7LJp6EQD/Nxpe/nYE363eIc7jiOs3qFkAJ+osl94UDnHDsan aEgA== X-Gm-Message-State: APzg51A8TzbRCf7AgNEpZJUHVoT1KBj4L0Jqdw/y1lchER5ktQkwnRAu qpIA+a3ZOMFTcOu7Hdv1vrp3GA== X-Received: by 2002:a50:908d:: with SMTP id c13-v6mr33242787eda.179.1535986079712; Mon, 03 Sep 2018 07:47:59 -0700 (PDT) Received: from shalem.localdomain (546A5441.cm-12-3b.dynamic.ziggo.nl. [84.106.84.65]) by smtp.gmail.com with ESMTPSA id x32-v6sm10810855eda.81.2018.09.03.07.47.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Sep 2018 07:47:58 -0700 (PDT) Subject: Re: [REGRESSION] boot-screen override by "34db50e55656 efifb: Copy the ACPI BGRT" To: Bartlomiej Zolnierkiewicz , David Herrmann Cc: linux-kernel , linux-fbdev@vger.kernel.org, linux-efi@vger.kernel.org, dri-devel@lists.freedesktop.org References: <1982440.Fn0LzJ7a3l@amdc3058> From: Hans de Goede Message-ID: Date: Mon, 3 Sep 2018 16:47:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1982440.Fn0LzJ7a3l@amdc3058> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 03-09-18 16:16, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Monday, September 03, 2018 03:23:38 PM David Herrmann wrote: >> Hey >> >> Since this commit: >> >> 34db50e55656 efifb: Copy the ACPI BGRT >> >> the kernel will override boot-splashs unasked. This breaks the >> graphical boot-process on our setups. In particular, we have a setup >> where an efi-boot-entry draws the early boot-splash on-screen, then >> hands-over to the linux-kernel + initrd. The boot-splash daemon in the >> initrd then takes over control of possible animations. >> >> With the mentioned commit compiled in, the kernel will redraw the >> firmware logo on screen at a random time without any way to intervene. > > You have CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER=y (the deferred > console takeover support introduced in v4,19-rc1). I assume that this > is intended? > >> What is the intention of this commit? Why is the kernel re-drawing the >> firmware logo unasked? If someone during the boot-process draws >> content on the screen, I would prefer if the kernel does not clear >> that on driver load. > > +/* > + * If fbcon deffered console takeover is configured, the intent is for the > + * framebuffer to show the boot graphics (e.g. vendor logo) until there is some > + * (error) message to display. But the boot graphics may have been destroyed by > + * e.g. option ROM output, detect this and restore the boot graphics. > + */ > +#if defined CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER && \ > + defined CONFIG_ACPI_BGRT > ... > +static void efifb_show_boot_graphics(struct fb_info *info) > ... > +#else > +static inline void efifb_show_boot_graphics(struct fb_info *info) {} > +#endif > >> Can we either provide an option to disable this feature, or revert the commit? > > Hans? We use the ACPI bgrt extension to get the logo to draw and then draw it since some devices rely on the OS to draw it and otherwise we just end up with a blackscreen when doing silent / flickerfree boot. Ideally you would be able to get your vendor to put the logo in firmware in the ACPI bgrt extension, then you also do not need to play any tricks with an EFI binary drawing your own logo. But I can understand if you don't have control over this, so you need to do this with the EFI binary trick. I can also understand that you want to use deferred console takeover in a setup like yours to avoid fbcon messing up what is on the display during boot, that is exactly what it is for. So I think a reasonable approach here is to add a kernel commandline option, say: video=efifb:nobgrt David, would that work for you? Regards, Hans