> I haven't reached that stage yet so I'm open to any ideas that will work. Fell > free to download the code and work on whatever interests you. > > My immediate goal is to get a login console up on a single screen. That means I > need to get the mode set, make fonts work and write a mini-terminal emulator to > the DRM API. > > A plus to this design is that the entire kernel TTY, VT, FB layers are > by-passed. Some of that code is very ancient and it probably has SMP issues. > Under the new model everything that doesn't actually play with the hardware is > moved to user space. Also the old model only supported one card and the new one > supports many. > > There was a long discussion on the xserver list about making OpenGL the only API > for accessing the hardware. This is part of the path to getting there.
Note that I've spent time discussing these issues with Linus as well, and there are things to keep in mind: - GL cannot be the _only_ API, simply because we don't (and may not have for some time) GL support on all cards, while still wanting this new console stuff so we don't have to keep the old cruft around - No HW access from userland. It is not trusted. Whatever userland does has to be piped through the kernel driver. That means that mode setting has to be a kernel module. I'm working with Keith on the API mode setting should provide (this isn't trivial when you start dealign with all heads and outputs, relative geometry, mode validation, etc...). Part of it can be in userland, like the actual decision on which mode to use based on the probing information, but the act of actually configuring the card has to be in the kernel. Only exception here: we may admit that old crappy cards that have no DMA command pipe get registers mapped to userland and be done with it... - I'm personally against limiting us to the GL & 3D command pipe. - Arbitration, especially regarding mode setting. We probably need at least a futex, maybe a bit more, since the 3D side may actually want to re-initialize some state after a mode switch which usually involves an engine reset - As I told you separately, I see no reason to not keep the compatibility with fbcon, it's completely orthogonal as long as we have a good locking primitive in place. Compatibility with existing stuff to slowly phase it out is the way to go to get broad adoption & testing imho. Ben. ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
