Re: Native mode handling
Keith Whitwell <keith-CdwZJljFklH+2FeEXyspIVaTQe2KTcn/@public.gmane.org>
| Newsgroups | gmane.comp.freedesktop.xserver |
|---|---|
| Message-ID | <[email protected]> |
Alex Deucher wrote: > --- Keith Whitwell <keith-CdwZJljFklH+2FeEXyspIVaTQe2KTcn/@public.gmane.org> wrote: > >>Jon Smirl wrote: >> >>>--- Benjamin Herrenschmidt <[email protected]> wrote: >>> >>> >>>>I think we should start thinking about moving away from fbdev in >>>>the long run. Either that, or do some significant fixup of the >>>>fbdev, which is, imho, looking more and more like a lost cause. >>>> >>> >>> >>>I am with Ben on this one. fbdev will probably continue to exisit >> >>but future >> >>>X/DRM implementations may not coexist with it. I am strongly in >> >>favor of a model >> >>>with a single device driver per graphics card and no driver driver >> >>timesharing >> >>>between fbdev and DRM. There is no reason a new console system >> >>can't be built >> >>>around DRM to replace the features of the fbdev one. >>> >>>Ben also went down the path of trying to add full mode support to >> >>the radeon >> >>>fbdev driver. He may want to comment on that. I'm doing the mode >> >>code in user >> >>>space and the shared object for it is going to be at least a 100K >> >>in size. In >> >>>Linux 2.7 user space is going to be enabled very early in the boot >> >>process, at >> >>>that point you could switch from the BIOS console to a DRM based >> >>one with mode >> >>>support. >>> >>>Don't think of DRM as being 3D only. I would like to see DRM >> >>compatible drivers >> >>>built for 2D cards too, they'll just return not-implemented for 3D >> >>features. >> >>As I've said elsewhere, with MS Longhorn being the target for future >>card >>devlopment, do you really believe that cards are going to continue >>carting >>around blit engines? >> >>In this scheme, the voodoo & voodoo-2 cards were more prophetic than >>they are >>given credit for... >> >>Keith >> > > > Plus couldn't a simple openGL driver be build on the 2D engine of cards > lacking 3D specs or only supporting 2D? rather than layering sw mesa > over XAA/Xlib, just have the GL use the 2D engine directly. Maybe, but it's starting to get a little complex. If anyone really cares about full support for broken/obsolete hardware, they can put some effort into such a design at a later date. But understand you are talking about a vanishing class of hardware. I'd expect the non-open vendors to provide drivers for this infrastructure, assuming it takes off. Keith