From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 6F17E15800D for ; Sat, 31 Dec 2022 16:13:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 780A4E08EB; Sat, 31 Dec 2022 16:13:27 +0000 (UTC) Received: from mx3.muc.de (mx3.muc.de [193.149.48.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D2CFDE08C4 for ; Sat, 31 Dec 2022 16:13:26 +0000 (UTC) Received: (qmail 77125 invoked by uid 3782); 31 Dec 2022 17:13:25 +0100 Received: from acm.muc.de (p2e5d5394.dip0.t-ipconnect.de [46.93.83.148]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 31 Dec 2022 17:13:24 +0100 Received: (qmail 7055 invoked by uid 1000); 31 Dec 2022 16:13:23 -0000 Date: Sat, 31 Dec 2022 16:13:23 +0000 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Soft scrolling on framebuffer consoles - New version of the patch - with GPM handling. Message-ID: References: <5647862.DvuYhMxLoT@wstn> <5662152.DvuYhMxLoT@wstn> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5662152.DvuYhMxLoT@wstn> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Archives-Salt: 6bd39afd-79f8-4be9-a7a6-c269828ae27e X-Archives-Hash: a1448b2b54535cb132626236108fb509 Hello again, Peter. On Sat, Dec 31, 2022 at 15:47:01 +0000, Peter Humphrey wrote: > Hello Alan, > On Saturday, 31 December 2022 14:08:43 GMT you wrote: > > What I'm thinking here is that you might be installing a font which is > > bigger than the 8x16 standard that you appear to be booting with. To > > check this, would you please do: > > # file /lib/rc/console/font > > , which should return a message like: > > /lib/rc/console/font: Linux/i386 PC Screen Font v1 data, 256 characters, > > Unicode directory, 8x16 > > What is the size of this font, here (where it says 8x16 for my font)? > > The reason I ask is, I've got a horrible suspicion that one of the C > > functions which copies screen data when the screen size is changed can > > only copy to a same sized or (possibly) _bigger_ screen (i.e. with a > > smaller font). If this is indeed the case, it might explain why you're > > seeing a hang, here. > I think you've put your finger on it: > $ file /lib/rc/console/font > /lib/rc/console/font: Linux/i386 PC Screen Font v2 data, 256 characters, > Unicode directory, 22x11 > I use consolefont="ter-122n" from the terminus-font package. It's a long time > since I was able to read a high-resolution screen in its native resolution. > Is there some way I can get the UEFI BIOS to boot with that font, or a larger > one? Or perhaps let the system boot without setting a font and then changing > it later? Probably, but it would be better if I just fixed the bug(s) in my changes to the kernel. Changing font size is something one should be able to do. > Neither of those looks easy to do. I'd better have a good root through the > BIOS options to start with. A happy new year to you (and everybody else here), and give me somewhere between a few hours and a few days, and this bug should get fixed. Again, thanks for such effective testing! > -- > Regards, > Peter. -- Alan Mackenzie (Nuremberg, Germany).