vt(4) using efifb is unable to fully utilise the dimensions of any screen over 2048x1600, including Retina displays in many Apple computers. This is due to it taking the minimum of the reported (correct) resolution, and a hardcoded VT_FB_DEFAULT_WIDTH and VT_FB_DEFAULT_HEIGHT. From the source: vt.h: #ifndef VT_FB_DEFAULT_WIDTH #define VT_FB_DEFAULT_WIDTH 2048 #endif #ifndef VT_FB_DEFAULT_HEIGHT #define VT_FB_DEFAULT_HEIGHT 1200 #endif vt_fb.c: vd->vd_height = MIN(VT_FB_DEFAULT_HEIGHT, info->fb_height); vd->vd_width = MIN(VT_FB_DEFAULT_WIDTH, info->fb_width); This results in a noticeable black border around the console, which can also lead to further issues with the screen not completely clearing. Solution: either remove the maximum (but I don't know if there would be any implications from this), or set it to a significantly higher value - 4096 by 2400 should last for a little while.
Also, this should be a pretty straightforward fix, and would result in a significant usability improvement, and so it would be nice to get this ready for 11.0 if that's still possible.
Created attachment 171584 [details] A simple solution - increase limit and clarify This is probably the simplest way to fix the issue - double the limit, and rename VT_FB_DEFAULT_* to VT_FB_MAX_* to clarify this behaviour. It probably wouldn't be a bad idea to document this either.
+1 SHIP IT I confirm this fixes the issue for me. The resulting console is slow, but the size works fine again. It should also allow closing #203376 (which I linked) and #202288 (which I can't link but I mentioned this ticket in that one). The clearing of the virtual consoles also works (at least for me on Apple / Intel Iris Pro graphics) when using the new drm-next-4.6 branch. Thanks Felix!
@Dave to clarify, is the console slower as a result of applying attachment 171584 [details] or does it perform the same as prior?
Created attachment 171602 [details] Increase limit, rename DEFAULT to MAX (includes man page change) Just realised the man page also needs to be updated. Otherwise the same as the previous patch.
The .Dd date in the man page also needs to be updated.
Created attachment 171626 [details] Increase limit, rename DEFAULT to MAX (includes man page change) @Warren done.
@koobs after a bit of testing using the max screen resolution 2800x1800 I found it's equally slow in OSX as FreeBSD at this resolution. Later in the boot sequence, once you can log in at console, is nice and fast again. If I force a lower resolution the speed is faster, but I don't think this is due to FreeBSD directly. It would be great to see this in 10-STABLE as well if that's a possibility.
Is this likely to be implemented soon, or is it waiting on something else?? (I've never done this before, so someone can tell me what's normal if you like.)
I'm happy to just go ahead and commit it if there are no objections in the next day or so.
A commit references this bug: Author: cem Date: Tue Jul 19 19:20:48 UTC 2016 New revision: 303043 URL: https://svnweb.freebsd.org/changeset/base/303043 Log: Increase vt(4) framebuffer maximum size And rename "DEFAULT" constants to the more accurate "MAX." PR: 210382 Submitted by: Felix <felixphew0 at gmail.com> Reviewed by: wblock, cem Tested by: Dave Cottlehuber <dch at skunkwerks.at> Changes: head/share/man/man4/vt.4 head/sys/dev/vt/hw/fb/vt_fb.c head/sys/dev/vt/vt.h head/sys/dev/vt/vt_core.c
Re-open for MFC request
A commit references this bug: Author: bdrewery Date: Mon Jul 25 17:37:03 UTC 2016 New revision: 303312 URL: https://svnweb.freebsd.org/changeset/base/303312 Log: MFC r303043: Increase vt(4) framebuffer maximum size PR: 210382 Approved by: re (gjb) Changes: _U stable/11/ stable/11/share/man/man4/vt.4 stable/11/sys/dev/vt/hw/fb/vt_fb.c stable/11/sys/dev/vt/vt.h stable/11/sys/dev/vt/vt_core.c
Should this go to stable/10?
(In reply to Bryan Drewery from comment #14) If possible (user perspective), unless other code missing precludes it. CC'ing 'significant contributors to vt' [1] [1] https://wiki.freebsd.org/Newcons
(In reply to Bryan Drewery from comment #14) > Should this go to stable/10? I think the rest of the changes for high resolution displays have been merged to stable/10, so if this works I have no objection.
A commit references this bug: Author: emaste Date: Wed Jul 19 13:11:36 UTC 2017 New revision: 321198 URL: https://svnweb.freebsd.org/changeset/base/321198 Log: MFC r303043: Increase vt(4) framebuffer maximum size PR: 210382 Relnotes: Yes Changes: _U stable/10/ stable/10/share/man/man4/vt.4 stable/10/sys/dev/vt/hw/fb/vt_fb.c stable/10/sys/dev/vt/vt.h stable/10/sys/dev/vt/vt_core.c
Created attachment 213861 [details] Adjust conf/NOTES, conf/options and man4/vt.4 after renaming VT_FB_DEFAULT_* Hello, following NOTES, I missed the rename. Don't know if there's a automatic options generation, but in case it's to be done manually the attached diff should cover the vestiges. Thanks, -harry