> On 10.12.2016, at 13:37, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > >> From: Reyk Floeter <r...@openbsd.org> >> Date: Sat, 10 Dec 2016 12:50:56 +0100 >> >>>> On Sat, Dec 10, 2016 at 08:17:10PM +0900, Ryan McBride wrote: >>>> So I've been eying this machine for a while: >>>> http://www.kingjim.co.jp/sp/portabook/xmc10/ >>> >>> Included below is the dmesg with the previous diff applied. >>> >>> Besides all the devices that show "not configured", there are a bunch of >>> other things that don't work. I guess there's more broken that I haven't >>> run into yet. >>> >>> - Built-in keyboard does not work in the bootloader (an external USB >>> keyboard is fine) >>> >>> - zzz fails with "acpi0: state S3 unavailable" >>> >>> - Console does not use the whole screen, there is an empty border around >>> the whole screen (~2 chars tall at top and bottom, ~3 wide on the >>> sides) >>> >> >> efifb(4) does not fill the screen, it uses hardcoded values; I only >> get a tiny console on my 2560x screen. > > There are hardcoded limits. On smaller screens it will use the entire > screen. >> >> I patched my kernel to fill the laptop screen but efifb should >> really just adjust to the actual resolution automatically. > > The problem with filling the entire screen is that the console becomes > quite slow. This makes doing things like running a full-screen editor > or scrolling through logs a bit of a pain. Maybe it is a bit better > now that we map the framebuffer in write-combining mode. Also > increasing the number of characters beyond what we have now is not > going to make it more usable. >
I know that it is a bit slow - I'm using it :) But the alternative is a tiny console that almost doesn't make sense - it is not much fun to stare at a tiny blue window in the middle of a black screen. > What we really need is a bigger font for those high-resolution screens. Agreed. Reyk
