Bug 210382 - Remove hardcoded maximum size (2048x1600) from vt(4) framebuffer
Summary: Remove hardcoded maximum size (2048x1600) from vt(4) framebuffer
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: Bryan Drewery
URL:
Keywords: easy, feature, patch, vt
Depends on:
Blocks: 203376
  Show dependency treegraph
 
Reported: 2016-06-19 07:17 UTC by Felix
Modified: 2017-07-19 13:12 UTC (History)
11 users (show)

See Also:
koobs: mfc-stable11+
emaste: mfc-stable10+


Attachments
A simple solution - increase limit and clarify (1.88 KB, patch)
2016-06-19 22:51 UTC, Felix
no flags Details | Diff
Increase limit, rename DEFAULT to MAX (includes man page change) (2.26 KB, patch)
2016-06-20 09:01 UTC, Felix
no flags Details | Diff
Increase limit, rename DEFAULT to MAX (includes man page change) (2.38 KB, patch)
2016-06-20 22:32 UTC, Felix
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Felix 2016-06-19 07:17:30 UTC
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.
Comment 1 Felix 2016-06-19 07:22:55 UTC
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.
Comment 2 Felix 2016-06-19 22:51:12 UTC
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.
Comment 3 Dave Cottlehuber freebsd_committer 2016-06-20 08:37:48 UTC
+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!
Comment 4 Kubilay Kocak freebsd_committer freebsd_triage 2016-06-20 08:53:53 UTC
@Dave to clarify, is the console slower as a result of applying attachment 171584 [details] or does it perform the same as prior?
Comment 5 Felix 2016-06-20 09:01:27 UTC
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.
Comment 6 Warren Block freebsd_committer 2016-06-20 14:58:10 UTC
The .Dd date in the man page also needs to be updated.
Comment 7 Felix 2016-06-20 22:32:04 UTC
Created attachment 171626 [details]
Increase limit, rename DEFAULT to MAX (includes man page change)

@Warren done.
Comment 8 Dave Cottlehuber freebsd_committer 2016-06-24 17:30:05 UTC
@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.
Comment 9 Felix 2016-07-16 22:22:35 UTC
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.)
Comment 10 Conrad Meyer freebsd_committer 2016-07-18 16:44:18 UTC
I'm happy to just go ahead and commit it if there are no objections in the next day or so.
Comment 11 commit-hook freebsd_committer 2016-07-19 19:21:02 UTC
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
Comment 12 Kubilay Kocak freebsd_committer freebsd_triage 2016-07-20 07:44:11 UTC
Re-open for MFC request
Comment 13 commit-hook freebsd_committer 2016-07-25 17:37:18 UTC
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
Comment 14 Bryan Drewery freebsd_committer 2016-07-25 17:42:21 UTC
Should this go to stable/10?
Comment 15 Kubilay Kocak freebsd_committer freebsd_triage 2016-07-26 07:21:08 UTC
(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
Comment 16 Ed Maste freebsd_committer 2017-02-10 14:56:19 UTC
(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.
Comment 17 commit-hook freebsd_committer 2017-07-19 13:12:08 UTC
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