From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Date: Mon, 21 Mar 2011 19:25:18 +0000 Subject: Re: Future desktop on dumb frame buffers? Message-Id: <20110321122518.6b7ec7e4@jbarnes-desktop> List-Id: References: <20110321110040.6f1ea6d3@jbarnes-desktop> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: timofonic timofonic Cc: Linux Fbdev development list , Geert Uytterhoeven , dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, wayland-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org 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? All three major GPU device classes have KMS support (Intel, ATI, and nVidia). If you want it for a particular device, you can always port it over. As for fbdev emulation, what's still using it? There's nothing stopping projects from converting over; X and Wayland can already handle KMS APIs just fine. > I know the graphic driver situation is quite bad on Linux, especially > on the embedded world. Fbdev seems is still quite used there by binary > blob drivers. Probably for a couple of reasons: 1) inertia: fbdev has been around a lot longer, and provides most of what embedded devices need anyway 2) feature set: why bother doing a full KMS driver if you're not going to use any of the additional features it would provide (output management, memory management, execution management) Jesse