Date: Fri, 23 May 2008 09:20:54 -0700 From: Eric Anholt <eric@anholt.net> To: "Wilkinson, Alex" <alex.wilkinson@dsto.defence.gov.au> Cc: freebsd-current@freebsd.org Subject: Re: development of framebuffer driver hi res console Message-ID: <1211559654.10895.6.camel@localhost> In-Reply-To: <20080523045340.GD40788@stlux503.dsto.defence.gov.au> References: <CBB7AFEE-3E22-4059-8E5E-341BA0B40338@internode.on.net> <20080520074611.GH97796@carrot.home.paeps.cx> <1211300383.93737.6.camel@localhost> <20080523045340.GD40788@stlux503.dsto.defence.gov.au>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-f1vjGXUL3Qn1TwCKSQQC Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2008-05-23 at 12:53 +0800, Wilkinson, Alex wrote: > 0n Tue, May 20, 2008 at 09:19:43AM -0700, Eric Anholt wrote:=20 >=20 > >On Tue, 2008-05-20 at 09:46 +0200, Philip Paeps wrote: > >> On 2008-05-16 19:15:19 (+0800), ketracel <ketracel@internode.on.ne= t> wrote: > >> > Any FreeBSD developers out there working on a Framebuffer driver= which > >> > provides modern high resolution modes (including widescreen) for= the system > >> > console? > >>=20 > >> Not specifically working on a high-res framebuffer, but I'm workin= g on > >> divorcing the framebuffer from syscons. Once that work is done, i= t should be > >> possible to write more "advanced" framebuffer drivers. > > > >And the graphics developers are already porting their drivers to the > >kernel to provide the framebuffer part. What it would take to port = that > >to FreeBSD has been outlined elsewhere. >=20 > Can someone actually define what is meant as "framebuffer" as opposed to = VESA ? >=20 > I have physically seen OSs such as gentoo that have a framebuffer (pretty > consoles) but I have never ever known what a "framebuffer" is in the cont= ext of > VTYs. >=20 > Anyone care to post a nutshell summary ? A framebuffer's a collection of pixels. For consoles, that means not VGA where you store a collection of characters that are looked up through a font to produce pixels. For DRM modesetting, we don't use VESA at all, since it's a terrible interface and routinely under-tested for modern chips (since Windows doesn't use it, it doesn't really work). Instead, we write native device-specific modesetting, with all the featureset and power savings of the native X driver you've been running in the past. --=20 Eric Anholt anholt@FreeBSD.org eric@anholt.net eric.anholt@intel.com --=-f1vjGXUL3Qn1TwCKSQQC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEABECAAYFAkg27uMACgkQHUdvYGzw6vePwACfdXpFenY+okIsxEV157TFaH5Y mb4AoJetlheUXvU3/ujfnoCVimZt8NQn =O++S -----END PGP SIGNATURE----- --=-f1vjGXUL3Qn1TwCKSQQC--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1211559654.10895.6.camel>