Date: Sun, 19 Jun 2016 07:17:30 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 210382] vt(4) framebuffer (and efifb) has hardcoded maximum of 2048x1600 Message-ID: <bug-210382-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210382 Bug ID: 210382 Summary: vt(4) framebuffer (and efifb) has hardcoded maximum of 2048x1600 Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: felixphew0@gmail.com 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. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-210382-8>