more MAXSCREENS patches

[Alan Coopersmith]

Jamey Sharp wrote:
> Thanks for reviewing, Tiago! I'd like to address the Xvfb questions
> first before getting to your review comments...
> 
> On Tue, Jun 01, 2010 at 08:39:35PM +0300, Tiago Vignatti wrote:
>> And I wouldn't care about dummy video driver being broken, really - let's
>> squash it and void input driver within the server and delete xvfb. But other
>> conservative guys might have different opinions here. 
> 
> On Tue, Jun 01, 2010 at 10:53:30AM -0700, Alan Coopersmith wrote:
>> Certainly those who build on platforms that the XFree86 DDX isn't currently
>> built/supported on, such as MacOS X & Cygwin, should be consulted before you
>> take Xvfb away from them.   Or were you going to fix the Xorg server to build
>> on their platforms first?
> 
> When I first proposed this, I didn't realize that the xfree86 DDX wasn't
> usable on OS X and Windows. In fact I still don't understand why it
> isn't, but haven't had a chance to dig into that question.

Tiago's patches lead towards solving one of the issues - the PCI access
requirement that doesn't make sense there, since they don't access hardware
directly, but like Xnest/Xephyr layer on top of another graphics layers that
does all that.

I know our Sun Ray team created their Xnewt server instead of an Xorg loadable
module because of issues like that - there's no point crawling the PCI bus on
the server locked away in the machine room, when the devices are all found over
a TCP socket to your network-connected thin client device.   Unfortunately, I
don't have a list of all the things like that they found.

A bunch of stuff ended up down in hw/xfree86 in ancient times because XFree86
was trying to stay in sync with the X Consortium/TOG/old-X.Org Sample
Implementation and keeping changes to their ddx reduced the resync cost - many
things like the module loader, logging facility, etc. more logically belong up
at the DIX/OS level.

Working on that to hopefully get to the point where we could have Xvfb, Xephyr,
Xnewt, Xorg, etc. be loadable modules of a more generic server is something I've
long wished someone would have time to work on, but I have never had enough
unfortunately.

> 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. ;-)

> 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.

I don't think there's any point to input-void in a hotpluggable/AllowEmptyInput
server, except as a skeleton to start coding a new driver from.   (For now,
probably to avoid breaking old xorg.conf files, but it should be trivial to
add "void" to the list of input drivers we skip if AllowEmptyInput is true.)

-- 
	-Alan Coopersmith-        alan.coopersmith at oracle.com
	 Oracle Solaris Platform Engineering: X Window System