From owner-freebsd-hackers@freebsd.org Tue Sep 11 10:27:35 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B067B108C353 for ; Tue, 11 Sep 2018 10:27:35 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: from mail-qt0-f169.google.com (mail-qt0-f169.google.com [209.85.216.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5127D710C5; Tue, 11 Sep 2018 10:27:35 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: by mail-qt0-f169.google.com with SMTP id r37-v6so27616236qtc.0; Tue, 11 Sep 2018 03:27:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=QSRO40+M3M/xdJzlxY92Bv9p1vQCncouNEGRb7V6rtI=; b=WE1T/9Pi/SphayssLpOg3RXs5f775WeRq5jhnY1ZuIy+KswxYnf+JTLqv3zc4YkKvr vp3PM3lqrXIKXjylJDSuE791R870CpMGyRnVcs0mWWlPiLm3wJkrs6vSRiOhxTUGplq4 9jUeEy4oSGOg0L988JtEFGYVHt5t0SGIgGcbHhKVu+rVjHhK3IlsgU0yv03/OuPAU8lT je+vkFpYcSdJ8S/rIZmFli7M+v/jcnQ1lu1hzhAAFDa7fIGJpjJm6mzAIsLoQbIg07QN cdSivJJ8TJu+p3jKcwO0w7uZY6TFbGWibM+ntvCbPdtkyZ7YI85GoSxL88+cAmCUeSl2 BqTw== X-Gm-Message-State: APzg51BSt3xz/ztV192LvjyKJXeH9WUOb+a3P538mplfnF+rP9COu+rp ajqdNXU4JlHI9edRuVnpWNdILnghzwBAyQ== X-Google-Smtp-Source: ANB0VdYRVaE5ba5Ely90vS/0FMoAqWq1W8jezvjUzo8nXk4muKk/vtc7AwlahZQB7WdjE4dc5y84cg== X-Received: by 2002:a0c:88ad:: with SMTP id 42-v6mr17989729qvn.79.1536660156266; Tue, 11 Sep 2018 03:02:36 -0700 (PDT) Received: from mail-qt0-f180.google.com (mail-qt0-f180.google.com. [209.85.216.180]) by smtp.gmail.com with ESMTPSA id x76-v6sm11475118qkx.25.2018.09.11.03.02.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 03:02:36 -0700 (PDT) Received: by mail-qt0-f180.google.com with SMTP id g53-v6so27491150qtg.10; Tue, 11 Sep 2018 03:02:35 -0700 (PDT) X-Received: by 2002:ac8:1978:: with SMTP id g53-v6mr19605329qtk.193.1536660155671; Tue, 11 Sep 2018 03:02:35 -0700 (PDT) MIME-Version: 1.0 From: Mateusz Piotrowski <0mp@freebsd.org> Date: Tue, 11 Sep 2018 12:02:29 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Let's improve splash screen support in vt(4) To: FreeBSD Hackers Cc: emaste@freebsd.org, dumbbell@freebsd.org, cperciva@freebsd.org, royger@freebsd.org, nwhitehorn@freebsd.org, ed@freebsd.org, ray@dlink.ua, wblock@freebsd.org, r.fernandez-cueto@bally-wulff.de X-Mailman-Approved-At: Tue, 11 Sep 2018 10:37:51 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 10:27:36 -0000 Hello, I'd like to improve splash screen support in vt(4) and I'm looking for your guidance and suggestions. Background ---------- As you may know, vt(4) does not support custom splash screens at the moment.[1][2][3] As splash screen could be turned on by specifying the -m flag to boot(8). It cannot be customized, however: the displayed image, its colors and size are set at compile time. Goals ----- - Support for BMP files so that they could be specified in loader.conf(5) (similarly to how it is done when using sc(4) and splash(4)). - Kernel tunables to control colors of the displayed image. Basically, I'd like to "unhardcode" colors used for vt(4) splash screens. Proposed implementation ----------------------- Unhardcoding colors seems to be an easy task: from what I understand it all boils down to adding a couple of sysctls. This way a user might choose which colors of the vt(4) color pallet should be used for the splash image. The more challenging part is getting raw data from a bitmap file in the vt(4) driver. I've done some research and I think that the easiest solution would be to use the existing splash(4) driver to extract data from a BMP file as drawing functions in vt(4) expect raw data. We could use splash(4) to load the file and put it into a C structure, which would then be accessible in vt(4) via a to-be-written interface. This approach does not feel super clean so this I decided to ask you if you've got any suggestions on how to improve this solution. Stretched goals -------------- At first I thought that adding support for 8-bit colors is not going to be a big problem. Then I found out that the vd_bitblt_bmp function expect exactly two colors (1 for foreground and 1 for background). I'll have to do more research if I want to support bitmaps with an 8-bit color depth. I'll be grateful for al suggestions, hints and pieces of advice. ---- The wiki page of this project is here: https://wiki.freebsd.org/MateuszPiotrowski/ImproveVtSplashScreenSupport Thanks & happy hacking, Mateusz [1]: https://wiki.freebsd.org/Newcons [2]: https://svnweb.freebsd.org/base/head/sys/dev/vt/vt_core.c?revision=338324&view=markup#l142 [3]: https://svnweb.freebsd.org/base/head/sys/dev/vt/vt_core.c?revision=338324&view=markup#l1373