more MAXSCREENS patches

[Vignatti Tiago (Nokia-D/Helsinki)]

Hi,

On Wed, Jun 02, 2010 at 08:15:30PM +0200, ext Jamey Sharp wrote:
> 
> So, yes. I think I'd like to see the xfree86 DDX made usable on all
> platforms that have active maintainers; in parallel, factor out common
> code between Xvfb/Xfake/dummy and between Xnest/Xephyr/Xdmx; and
> finally, unify those servers as drivers for the xfree86 DDX. That's not
> going to happen this week though. ;-)

exactly!

I've been thinking about this for months already. All DDX unified would be
very beneficial in terms of development. Think for instance about devPrivates
rework / MAXSCREENS removal. It would be much more easier and less painful if
we had less lines of code. 

Another example is what Alan mentioned, where Sun simply decided to fork the
server to contour the problem of Xorg being glued with buses hardware
routines. Right now it is (well, was) so hard to separate all this hw
infrastructure from the server that they preferred to go for another
implementation.

Same happened some months ago when I started to investigate the memory usage
of Xorg. I decided to stop to work on the middle of the way because the server
code stills huge and difficult to add any new idea.

My main effort lately is only related with the organization of the code.
I'm not caring about memory usage or other features in which the device I'm
working would benefit immediately - it will eventually come after; and for
free if the code is clear, small and easy to understand. So I really
appreciate any move like you said above.


> Merging the video-dummy and input-void drivers into the xserver tree is
> an independent question, and I'd still like to see that happen in 1.9. I
> don't think any of the arguments for keeping drivers out-of-tree apply
> to these two.

as Peter and Alan pointed out, the implementation is pretty much done already
if we want to start the server without input drivers. Still missing the video
side though.

Before start to work on that I still would like to clean up a bit more bus
code. My last patches to "optionalize" PCI code stills not enough. Better than
that, we would want an xorg module called libbuses.so to dynamically load it
when needed. It would be loaded if any access for buses would be needed and
instead to hardcode the type of bus as we have now, it would have a callback
choosing it.

There's a quite big amount of implementation to make this possible. On the top
of my head I can think in the bus entity code, to be removed (which is very
tough cause all the drivers use some piece of it) and instead export xf86Pci.h
for drivers, the API would be xf86Bus.h to have the proper callbacks, as I
said. This would be _much_ more easier if the drivers would be together glued
with the server (!!!). Bus related stuff inside ScrnInfoRec could be moved
also to a new structure inside this new libbus.so.


Cheers,
             Tiago