Bug 90126 - XFree86 mishandles very large numbers of screens
XFree86 mishandles very large numbers of screens
Status: CLOSED UPSTREAM
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
http://bugs.xfree86.org/cgi-bin/bugzi...
: MoveUpstream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-02 17:41 EDT by Alan Cox
Modified: 2007-04-18 12:53 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-24 09:52:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alan Cox 2003-05-02 17:41:24 EDT
Description of problem:
Configure a video wall. Try and run X11 on it and it aborts with

Fatal server error:
AddScreen/ScreenInit failed for driver 16

If it just skipped extra displays it couldnt cope with that wouldn't be too bad
but it aborts the server instead which sucks 8)

(Of course bumping X to 32 heads would be nice 8))
Comment 1 Mike A. Harris 2003-05-13 07:29:19 EDT
After discussing with XFree86 developers, increasing MAXSCREENS would break
binary compatibility of the server<->module interface, and so can not be
done until a major server version bump (ie: 5.0).  Additionally, doing it
as a customized build where bin compat doesn't matter will result in some
amount of wasted resources do to fixed sized arrays that get allocated the
size of MAXSCREENS, or some other similarly poorly implemented code.

So for a short term hack, you can try increasing MAXSCREENS to 32 or whatever
in xc/programs/Xserver/include/misc.h

The protocol maximum is 256 screens, which is probably what the hard coded
limit should be when the code is refactored to be dynamic for 5.0.

Note also however, that someone mentioned that there might be somewhere in
the server in which screens are manipulated via a 32bit integer bitmask or
somesuch.  If so, this would imply that going beyond 32 screens (possibly 31
if sign issues are present) would also break things.  I haven't attempted
to substantiate this last claim though.

Closing as UPSTREAM, and linking to upstream bug report to track this for
XFree86 5.0 et al.

http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=235
Comment 2 Mike A. Harris 2003-07-17 06:41:09 EDT
Cleaning up UPSTREAM flagged bugs, moving this one to DEFERRED for long term
tracking instead.
Comment 3 Mike A. Harris 2005-05-24 09:52:41 EDT
The MAXSCREENS problem has patches floating around which bypass this
problem but change ABI incompatibly, so are unsuitable for any existing
OS release.  It's not possible to solve this issue without breaking ABI,
so this will become an upstream change in a future X.Org major release.
It might be in X11R7 later this year, but it hasn't been decided yet I
don't think.  A quick search of X.org bugzilla didn't yield a bug that
is tracking this, but I know several developers have thought about it
at least and discussed different solutions.

The best place to track this is on xorg@freedesktop.org or to file an
Xorg report to track it.

Setting status to UPSTREAM.

Note You need to log in before you can comment on or make changes to this bug.