From owner-freebsd-current@freebsd.org Mon Mar 2 08:47:50 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 02FAA25EF90 for ; Mon, 2 Mar 2020 08:47:50 +0000 (UTC) (envelope-from tsoome@me.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 48WDLF32hdz4L88 for ; Mon, 2 Mar 2020 08:47:49 +0000 (UTC) (envelope-from tsoome@me.com) Received: by mailman.nyi.freebsd.org (Postfix) id 5343C25EF8F; Mon, 2 Mar 2020 08:47:49 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 52FB625EF8E for ; Mon, 2 Mar 2020 08:47:49 +0000 (UTC) (envelope-from tsoome@me.com) Received: from pv50p00im-ztdg10021101.me.com (pv50p00im-ztdg10021101.me.com [17.58.6.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48WDLC6r72z4L5g for ; Mon, 2 Mar 2020 08:47:47 +0000 (UTC) (envelope-from tsoome@me.com) Received: from [192.168.150.41] (148-52-235-80.sta.estpak.ee [80.235.52.148]) by pv50p00im-ztdg10021101.me.com (Postfix) with ESMTPSA id 9BBEA180566 for ; Mon, 2 Mar 2020 08:47:44 +0000 (UTC) From: Toomas Soome Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: about loader & console Message-Id: Date: Mon, 2 Mar 2020 10:47:41 +0200 To: FreeBSD Current X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-03-02_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1031 mlxscore=0 mlxlogscore=965 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-2003020069 X-Rspamd-Queue-Id: 48WDLC6r72z4L5g X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16]; FREEMAIL_FROM(0.00)[me.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[me.com:+]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; RECEIVED_SPAMHAUS_PBL(0.00)[148.52.235.80.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; RCVD_IN_DNSWL_LOW(-0.10)[44.6.58.17.list.dnswl.org : 127.0.5.1]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:714, ipnet:17.58.0.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[me.com]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[me.com.dwl.dnswl.org : 127.0.5.1]; IP_SCORE(0.00)[ip: (-4.52), ipnet: 17.58.0.0/20(-1.99), asn: 714(-2.37), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 08:47:50 -0000 Hi! I have been busy with other bits for some time, but now back to poking = some bits. What we have now (on current): x86:=20 vidconsole on BIOS systems. Text mode, the screen is managed by teken = terminal emulator, we =E2=80=9Cdraw=E2=80=9D on vga text buffer.=20 comconsole: serial port driver shared by BIOS and UEFI mode. efi: Text mode, console =E2=80=9Cdevice=E2=80=9D which can have gfx = display, serial port or both connected as back end device, connection is = done by the firmware. We write by using UEFI Simple Text Output = Protocol. See also ConOut UEFI variable. To manage the screen, the efi console also defaults to use teken = terminal emulator, however, if the serial port is multiplexed to ConOut, = we can not have =E2=80=9Cour=E2=80=9D terminal emulator to draw the = screen, as that would distort the serial console. And worse, at least = some UEFI firmware implementations do not pass ESC code via simple text = output protocol, causing the console being filled by broken CSI = sequences. arm: efi console is the same state as in x86, no serial driver to = provide comconsole, the serial console is only available via redirection = from firmware. I actually do have basic comconsole implementation via UEFI Serial IO = protocol, but unfortunately, the UEFI API does not provide good way to = identify serial ports, we only do get array of handles of serial ports. = The SIO handle is opaque. What we want to get:=20 We would like to have framebuffer console (at least on efi), where we do = =E2=80=9Cdraw=E2=80=9D the glyphs and do not use simple text output = protocol for console output.=20 Why: this will allow us to provide more consistent screen output, draw = images and we would not depend on simple text output any more. UEFI gfx console is already built on framebuffer - on physical systems = we do get FB address, size and few other attributes, and after passing = this all to kernel, the kernel will draw the conole, as Simple Text = Output Protocol is not available once we start the kernel. To get this done, we need console font. To be able to output text, I do = plan to build into loader binary the limited set (ascii + box drawing) = 8x16 font, and once we have gained access to the disk, we will load best = matching font for the current resolution. This makes first problem - we = have font files in usr/share/vt/fonts, but there are too many options = where the /usr might be, so we would need to copy some of those fonts to = /boot tree. I=E2=80=99d use terminus fonts there for consistency (glyph = range) for various glyph sizes. And the kernel default built in font is = 8x16 terminus. With ability to draw our glyphs, we can build console device list in = console variable, just as it is currently done with x86 BIOS version. If = we should still use the console name =E2=80=9Cefi=E2=80=9D for FB = console or leave efi for pure Simple Text Output based console, is = something we would need to decide. Once we can draw the FB console on UEFI, it is not too hard to add the = implementation for BIOS VBE interface. To sum it all up: 0. my assumption is/was that we do not change the name of the console = driver, to keep the expected values people are used with. However, it is = quite easy to introduce new console types, if needed. 1. We need to provide serial driver on all platforms. 2. Provide option to switch between =E2=80=9Ctext=E2=80=9D and gfx mode. = In some systems (BIOS VGA) the gfx performance may be very low and text = mode might be preferred.=20 3. The screen updates are to be implemented via teken callback mechanism = (as it is also done in kernel for that matter). 4. The support to display images is using pnglite (and therefore png = format). Interpreters need updates to support the feature. I actually do have the core implementation for UEFI already, but = polishing it up will still get some time. Actually I am cheating there = quite a bit because I have done all this work already once and now I am = porting it to different terminal emulator. I hope this writeup does give some light about what is happening in this = area. thanks, toomas=