On Tue, 2005-03-15 at 00:30 -0500, Jon Smirl wrote: > I agree that X has to be fixed to work cooperatively in this environment. > The alternative is to just leave X alone and make all of this work for XGL. > The user would then choose which environment they want to run. > > I'm leaning toward just leaving X alone and spending the resources on > making XGL work. After all XGL is a complete X replacement. > > If you want to run existing X load an old fbdev driver. We can keep both > fbdev drivers in the kernel until it is clear if XGL is going mainstream. > > One thing that does need to get fixed is mesa support for non-accelerated > fbdev drivers but mesa can add all of the appropriate locking.
No, that isn't realistic. I want a smooth transition, and XGL won't be the only player in the field anyway. > > I think that Jon's dream of having totally independant heads that can > > run 2 separate applications is a long way away and we have sort-of to > > tie /dev/fb's together, though I don't know how to acheive that in > > practice, unless we switch to a new API that can enforce it. The current > > fbdev API cannot. > > This is definitely something to works towards. There is a lot of > application for this in schools, libraries, internet cafe, etc. There > are several companies selling variations on this. > > I don't expect an immediate solution but I want to make sure the > redesign allows it to be built. Yes. But I think that we should basically consider that anybody openng /dev/fb also "locks out" write access to the other heads. That is, the other head can be opened, but nothing done (mmap etc... on it) unless both opener's have done the right ioctl telling us they know how to do arbitration or that kind of thing. No ? The fbdev API needs a mirror of the vga arbitration API. The later is for use only by applications directly tapping vga legacy stuff. But something using fbdev also need a lock/unlock API to enclose any hardware access, at the very least. And when you think about it, what you end up needing is ... the DRM lock. So there might be some need to have fbdev be capable of taking the DRM lock now. Unless that's done, I'll have to impose severe restrictions on accesses to radeonfb's second head. > Can we put in our own fault handler for the mmap, trap the directfb > accesses and do the proper locking? Gack. First that's "lazy locking" and something I'd like to avoid, but if directfb API doesn't provide any other option ... then, it also requires regulary un-mapping them back from the process using directfb or the stuff will remain locked forever, and unmapping things behind a process back isn't cool (some interesting locking issues). Overall rather complicated and inefficient performance wise. And part of that infrastructure already exist, somewhat, in the DRM ... If a directFB client uses a /dev/fb, I think it should own both heads. We simply can't do anything else. And we might even still need arbitration because of the VGA stuff in case the card we are using has legacy decoding enabled _anyway_. So .... Ben. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
