On Fri, 2011-11-25 at 11:03 +0000, Phil Blundell wrote: > On Fri, 2011-11-25 at 00:00 +0000, Richard Purdie wrote: > > Looking at vesa.c, there is quite a chunk of code in there depending on > > DGA. > > I guess the question is, is this chunk of code actually doing anything > useful/important, or is it just there to support DGA on VESA? If the > latter then people who don't need/want DGA (which is probably everybody, > nowadays) can just take it out. > > All that said, I would have thought that the VESA driver itself was > pretty much a fringe interest in this day and age. Is anybody really > using that on a shipping system? If it's just for qemux86 test harness > purposes then maybe we could turn on the vesafb driver in the kernel and > use the straight framebuffer driver in Xorg rather than the VESA one. > > > Is there any harm to building DGA apart from an extra package? Its a > > self contained module isn't it? > > I don't think it's that self-contained. Admittedly it isn't all that > big either, but still. > > > If so, we should just be able to turn it on, package it separately and > > forget about it? > > > > Of course the ideal solution would be for someone to convert the vesa > > driver to use the xrandr API... > > I don't quite understand what xrandr has to do with that. How does this > relate to DGA?
The vesa driver looks like its using DGA APIs to expose mode setting. A comment to that end is also in a TODO list at the top of the file. Cheers, Richard _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
