From nobody Fri Feb 25 14:23:21 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DF94D19E8777 for ; Fri, 25 Feb 2022 14:23:41 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K4sT86PX0z3tKF for ; Fri, 25 Feb 2022 14:23:40 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mailhost.netlabit.sk with ESMTPSA; Fri, 25 Feb 2022 15:23:32 +0100 id 00DD6040.6218E664.00006578 Date: Fri, 25 Feb 2022 15:23:21 +0100 From: Milan Obuch To: freebsd-hackers@freebsd.org Subject: Re: Rotating (efi) framebuffer console Message-ID: <20220225152321.4b339ec3@zeta.dino.sk> In-Reply-To: References: X-Mailer: Claws Mail 3.18.0git333 (GTK+ 2.24.33; i386-portbld-freebsd11.4) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4K4sT86PX0z3tKF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-hackers@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-hackers@dino.sk X-Spamd-Result: default: False [-3.27 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.975]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, 5 Feb 2022 20:50:41 +0000 Stefan Grundmann wrote: > Hi, > > the screen of my brand new GPD Pocket 3 (tiger lake) laptop is in > portrait mode and reports a resolution of 1200x1920. I have another > older device with the same issue (a GPD Pocket 1). > In 2019 johalun@FreeBSD.org wrote on the freebsd-current about an > Lenovo Ideapad with a portrait mode screen and raised the question if > it would be good to support rotation of the vt_fb console. > Hi, I just acquired a GPD Micro PC, which shows exactly the same issue, albeit with different resolution. Your patch comes just in time for me... > Since the new GPD Pocket 3 is a nice device and rather well supported > in FreeBSD, i thought "how hard can it be" (OpenBSD has fb console > rotation and Linux has fbcon=rotate..) > > The patch (against stable/13, at the end of this mail) works for > me(tm): Whenever the width of a frambuffer device is smaller than > it's height; a portrait mode screen is assumed and the screen is > rotated by 90 degrees clockwise. > After patching fresh stable/13 sources, doing full rebuild and reinstall, this works for me nicely. Thanks for the patch. > I write this here for two reasons: > > 1. give others with similar hardware a chance to avoid the > neck-craning issue > Thanks, this helps. I could use this device now in console mode with no issue. Just one small thing remains - loader output is still rotated. I have no idea how could this issue be solved properly, possibly similar patch for screen driver in loader (I did not look in the sources in stand directory). > 2. offer to work on something that can be reviewed and merged e. g. > - implement the rest of the transformations (180 degrees, 270 > degrees) > - boot-time variable to select behavior > - vt(4) man page update > > For 2. i would like to know if vt_fb.c is even the right place to do > this. The framebuffer code in the loader could also get this feature. > [ snip ] I'd like to ask whether you have some more hacks - for now, pressing power button while running FreeBSD does nothing, some driver/handler is missing, possibly for other parts of hardware as well, but overall, device runs nicely under FreeBSD. I am going to try X here, but this requires some work to build :) Once again, thanks for the patch. Regards, Milan