more MAXSCREENS patches
Tiago Vignatti
tiago.vignatti at nokia.com
Tue Jun 1 10:39:35 PDT 2010
Hey Jamey,
I took a look on this series. Comments are bellow.
On Mon, May 24, 2010 at 01:22:06AM +0200, ext Jamey Sharp wrote:
> After applying this series, there aren't many uses of MAXSCREENS left.
> Keith's fix-private-usage branch deals with one of the per-screen
> private key arrays, and probably illustrates how to handle the other.
> Most of the other cases are pretty easy to deal with. The obnoxious
> cases are PanoramiXRes.info and SpriteRec.windows, since they're
> MAXSCREENS-sized arrays embedded in a lot of objects throughout the
> server.
...
> 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 :)
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.
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.
Here it's:
Reviewed-by: Tiago Vignatti <tiago.vignatti at nokia.com>
Tested-by: Tiago Vignatti <tiago.vignatti at nokia.com> (i686 GNU/Linux)
Thanks,
Tiago
More information about the xorg-devel
mailing list