From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Date: Mon, 21 Mar 2011 19:56:05 +0000 Subject: Re: Future desktop on dumb frame buffers? Message-Id: <20110321125605.15aa6a04@jbarnes-desktop> List-Id: References: <20110321110040.6f1ea6d3@jbarnes-desktop> <20110321122518.6b7ec7e4@jbarnes-desktop> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Geert Uytterhoeven Cc: timofonic timofonic , Linux Fbdev development list , dri-devel@lists.freedesktop.org, wayland-devel@lists.freedesktop.org On Mon, 21 Mar 2011 20:50:20 +0100 Geert Uytterhoeven wrote: > On Mon, Mar 21, 2011 at 20:25, Jesse Barnes wr= ote: > > On Mon, 21 Mar 2011 19:19:43 +0000 > > timofonic timofonic wrote: > >> So if KMS is so cool and provides many advantages over fbdev and > >> such... Why isn't more widely used intead of still relying on fbdev? > >> Why still using fbdev emulation (that is partial and somewhat broken, > >> it seems) instead using KMS directly? > > > > Used by what? =A0All three major GPU device classes have KMS support > > (Intel, ATI, and nVidia). =A0If you want it for a particular device, you > > can always port it over. >=20 > The three major GPU device classes on PC... Yes, good point. :) > > As for fbdev emulation, what's still using it? =A0There's nothing > > stopping projects from converting over; X and Wayland can already > > handle KMS APIs just fine. >=20 > Can Wayland handle fbdev APIs ... Yes. Fundamentally, the Wayland protocol just assumes a way to share buffers between processes. For the software raster version of the Qt port, Kristian created a shmem interface for doing that to allow the results of CPU rendering to be passed around without copying. On an embedded device that would be one way to go. --=20 Jesse Barnes, Intel Open Source Technology Center