Messages in this thread | | | Date | Tue, 30 May 2006 16:15:50 -0500 | From | "Ian Kester-Haney" <> | Subject | Re: OpenGL-based framebuffer concepts |
| |
Good Day,
I think this debate boils down ti a few issues that could be easily resolved. As far as I can tell, the OpenGL Framebuffer is for an accelerated console in 2D While expecting Intel, ATI and Nvidia to cough up specs for their cards, a simpler implementation of OpenGL for the console could be offered up. The existing system works well for most people and a newer system could either tranisition from the base or take over if the installer or distro supports it. I don't see the hardware folks releasing all the details, but I can see them releasing a mini-GL driver ala the quake era in LGPL or other comparable liscense. It just seems that those of us with Expensive GPUs should be able to get a better console experience. I think a main goal would be to allow the existing code to gracefully release the hardware for a different driver to take over, be it a Xorg driver, a GLX driver, an Open Source driver or a binary driver that 'taints' the kernel. I want X to release to the console in some cases and I want the consoles basic driver to release to the Xorg driver. Most 'power users' run the binary drivers just fine.
I hope it makes sense to you guys. I love Linux and want it to get better. Just as the static /dev gave way to udev, the basic console should make/prepare the way for an accelerated console that uses newer and more powerful grapics cards to better use.
Thank You for reading. Regards, Ian
On 5/30/06, Jon Smirl <jonsmirl@gmail.com> wrote: > On 5/30/06, Pavel Machek <pavel@ucw.cz> wrote: > > Hi! > > > > > >No, to the contrary. suspend/resume can't ever work properly with > > > >vgacon and vesafb. It works okay with radeonfb tooday, and in fact > > > >radeonfb is neccessary today for saving power over S3. > > > > > > But the things is today for many users suspend/resume to RAM works for > > > people running X drivers, I know on my laptop that my radeon > > > suspends/resumes fine when running vgacon/DRM/accelerated X, it > > > doesn't suspend/resume at all well when running vgacon on its own of > > > course. or with radeonfb for that matter. so I still believe the > > > suspend/resume code for a card can live in userspace if necessary but > > > it just shouldn't be part of X... it needs to be part of another > > > graphics controller process. > > > > So we are mostly in agreement. I'd prefer to have suspend/resume code > > in kernel in cases it is simple... but separate userspace process is > > better than having it in X. > > Don't draw any conclusions from saying that suspend/resume works in X > and doesn't work on xx_fb. What matters is that a set of code that can > perform suspend/resumes exists at all. Once a coherent driver model is > designed the relevant code can be moved to the correct place. > > Another reason for moving things like this out of X is to allow the > implementation of alternative graphics systems. It makes no sense that > every new graphics system has to develop their own video and keyboard > drivers. ALSA is a good model for this, it is shared by everyone. > Imagine what things would be like if X built in drivers for every > sound card,. > > -- > Jon Smirl > jonsmirl@gmail.com > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |