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=3D210382 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 o= ver 2048x1600, including Retina displays in many Apple computers. This is due t= o 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 =3D MIN(VT_FB_DEFAULT_HEIGHT, info->fb_height); vd->vd_width =3D 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. --=20 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>