more MAXSCREENS patches

[Jamey Sharp]

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.

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.

On Wed, Jun 02, 2010 at 12:08:23AM +0200, Rémi Cardona wrote:
> Please don't take out Xvfb, it's a good intro to DDX writing

That's an interesting point. I'm not sure the DIX/DDX split is relevant
today though. As far as I can tell, it's an arbitrary API boundary
within a single git repo that just makes maintenance harder. The xfree86
driver API seems marginally more useful, and that has the video-dummy
and input-void drivers as examples.

> and a valuable tool for testing. (and building/running application
> test suites on tinderboxes)

I would never kill the ability to have some kind of X server with a fake
framebuffer, on any supported platform. That's obviously useful for so
many reasons.

On Tue, Jun 01, 2010 at 08:39:35PM +0300, Tiago Vignatti wrote:
> On Mon, May 24, 2010 at 01:22:06AM +0200, ext Jamey Sharp wrote:
> >   git://people.freedesktop.org/~jamey/xserver maxscreenless
> > 
> > Jamey Sharp (7):
> >       Move each screen's screensaver data into ScreenRec.
> >       Move each screen's root-window pointer into ScreenRec.
> >       Delete panoramiXdataPtr: it's redundant.
> >       Move each screen's x/y origin into ScreenRec.
> >       XineramaSetCursorPosition: use screen bounds directly, not POINT_IN_REGION.
> >       Delete XineramaScreenRegions cache.
> >       Accumulate graphics exposures incrementally in PanoramiXCopyArea/Plane.
> 
> In the first patch, given it involves screen saver extension I'd say maybe we
> could hide inside devPrivates instead create a mandatory ScreenRec field.
> However we're not loading scree saver as a separate module or component from
> the rest of the server code. So seems okay. Also, you could change the name of
> its structure for another than ScreenSaverStuff :)

Heh, yeah, ScreenSaverStuff is not the best name I've ever seen.
Although it's kind of funny, so I don't mind leaving it alone. :-)

As I noted in the commit message, dix uses values from these structs, so
I think it's appropriate as-is.

> As you mentioned above we might want to work on the remaining MAXSCREENS, for
> instance applying my ReallocGlobals patch to realloc screenInfo.screens. But
> I'd say to think about that after keithp's fix-private-usage get merged.

The ReallocGlobals patch is independent of fix-private-usage, so I think
it's worth getting that ready for merge now.

In fact, as long as you don't actually delete the definition of
MAXSCREENS when introducing the SCREENSALLOC macros, patches that use
those macros should be safe to merge at any time as well.

I'd only leave alone MAXSCREENS-sized arrays that hold private-index
ints, because Keith's work should be able to take care of those.

Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100602/85706426/attachment.pgp>