I have a use case where I need more than 400 connections to a single RedHat Linux Xorg server with multiple heads and I would like to see Xorg modified to support this configuration. The problem can be demonstrated by opening 400 xeyes on a computer with two heads (I think that a KDE limitation may prevent more than 256 on one head). Sun Microsystems engineers have produced private builds to support up to 1024 connections for Solaris. I have implemented the following changes to support 512 connections in a private build of 6.8.2: xc/include/XPoll.h -> #define XFD_SETSIZE 512 #define XFD_ANYSET(p) \ ((howmany(FD_SETSIZE, NFDBITS) > 0 && (p)->fds_bits[0]) || \ (howmany(FD_SETSIZE, NFDBITS) > 1 && (p)->fds_bits[1]) || \ (howmany(FD_SETSIZE, NFDBITS) > 2 && (p)->fds_bits[2]) || \ (howmany(FD_SETSIZE, NFDBITS) > 3 && (p)->fds_bits[3]) || \ (howmany(FD_SETSIZE, NFDBITS) > 4 && (p)->fds_bits[4]) || \ (howmany(FD_SETSIZE, NFDBITS) > 5 && (p)->fds_bits[5]) || \ (howmany(FD_SETSIZE, NFDBITS) > 6 && (p)->fds_bits[6]) || \ (howmany(FD_SETSIZE, NFDBITS) > 7 && (p)->fds_bits[7]) || \ (howmany(FD_SETSIZE, NFDBITS) > 8 && (p)->fds_bits[8]) || \ (howmany(FD_SETSIZE, NFDBITS) > 9 && (p)->fds_bits[9]) || \ (howmany(FD_SETSIZE, NFDBITS) > 10 && (p)->fds_bits[10]) || \ (howmany(FD_SETSIZE, NFDBITS) > 11 && (p)->fds_bits[11]) || \ (howmany(FD_SETSIZE, NFDBITS) > 12 && (p)->fds_bits[12]) || \ (howmany(FD_SETSIZE, NFDBITS) > 13 && (p)->fds_bits[13]) || \ (howmany(FD_SETSIZE, NFDBITS) > 14 && (p)->fds_bits[14]) || \ (howmany(FD_SETSIZE, NFDBITS) > 15 && (p)->fds_bits[15])) The above changes increase the number of file descriptors that are polled for input. xc/programs/Xserver/include/misc.h -> #define MAXCLIENTS 512 The above change increases the number of TCP connections allowed into the server. I realize that in 7.2 the XPoll.h is now dynamically constructed, and that the above changes would need to be folded into the new architecture. Thanks for looking into this.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
I believe the problem is still in 7.2 and 7.3. RedHat has provided me a patch for 6.8.2 as a part of RHEL 4 Update 6.
Note that raising MAXCLIENTS lowers the number of resources each client can have since the resource namespace is fixed across all clients in the X11 protocol, and evenly divided among them. Years ago we fixed this in Xsun in Solaris by offering an option to set maxclients at runtime to either 128 or 1024, allowing sites the option to set this themselves, but it did incur a small performance cost across the X server everytime that flag was checked. If someone wanted to investigate a similar option in Xorg, I could release that code.
(In reply to comment #3) > Note that raising MAXCLIENTS lowers the number of resources each client > can have since the resource namespace is fixed across all clients in the > X11 protocol, and evenly divided among them. > > Years ago we fixed this in Xsun in Solaris by offering an option to set > maxclients at runtime to either 128 or 1024, allowing sites the option > to set this themselves, but it did incur a small performance cost across > the X server everytime that flag was checked. If someone wanted to > investigate a similar option in Xorg, I could release that code. It is clear that the tradeoff that was made to only allow 256 connections is heavily lopsided towards allowing those clients to open far more resources than any actually use in practice. https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/260138 Large clients have been shown to use 3500 resources each, but we allow them to use 2^29/256, or 2 million. Can't we steal quite a few more bits for increasing the number of X clients? I don't just want a doubling - I never come close to the resources-per-client limit, but I am always running into the number-of-clients limit. If it's a bit too much work to add a configuration or cmdline option (your patch would definitely be worthwhile though), can't we change the default (such as in http://readlist.com/lists/lists.freedesktop.org/xorg/3/17055.html ) anyway, since it's currently so heavily lopsided?
(In reply to comment #4) > It is clear that the tradeoff that was made to only allow 256 connections is > heavily lopsided towards allowing those clients to open far more resources than > any actually use in practice. Than any your users use perhaps - we have had users with applications that ran out, especially CAD/CAM type applications. Remember that older toolkits did a lot more server side than GTK & Qt today, and some did things like creating a new Window id for every widget. > If it's a bit too much work to add a configuration or cmdline option (your > patch would definitely be worthwhile though), can't we change the default (such > as in http://readlist.com/lists/lists.freedesktop.org/xorg/3/17055.html ) > anyway, since it's currently so heavily lopsided? While I've not extracted the change into a patch that could be easily ported/applied to Xorg, the code to the Solaris Xsun fork of the X11R6.* server fork has since been published if someone else wants to try. The code to the entire server is published at: http://dlc.sun.com/osol/x/downloads/openXsun/ The command-line selectable 128/1024 clients code changes should be in these files (and possibly more, I've not searched, just referring to our original code changes - and obviously not all these apply to X11R7.x/Xorg 1.x): xc/programs/Xserver/Xext/mbuf.c xc/programs/Xserver/Xext/multibuf.c xc/programs/Xserver/Xext/security.c xc/programs/Xserver/Xi/closedev.c xc/programs/Xserver/dbe/dbe.c xc/programs/Xserver/dix/colormap.c xc/programs/Xserver/dix/dixutils.c xc/programs/Xserver/dix/grabs.c xc/programs/Xserver/include/misc.h xc/programs/Xserver/include/resource.h xc/programs/Xserver/include/windowstr.h xc/programs/Xserver/lbx/lbxcmap.c xc/programs/Xserver/lbx/lbxmain.c xc/programs/Xserver/lbx/lbxserve.h xc/programs/Xserver/os/WaitFor.c xc/programs/Xserver/os/connection.c xc/programs/Xserver/os/io.c xc/programs/Xserver/os/osdep.h xc/programs/Xserver/os/osinit.c xc/programs/Xserver/os/utils.c xc/programs/Xserver/os/xdmcp.c xc/programs/Xserver/pandix/dispatch.c xc/programs/Xserver/pandix/events.c xc/programs/Xserver/pandix/main.c xc/programs/Xserver/pandix/resource.c xc/programs/Xserver/pandix/window.c xc/programs/Xserver/record/record.c plus at least this patch to x11proto: http://src.opensolaris.org/source/xref/x-cons/XW_NV_tw-clone/open-src/proto/x11proto/Xpoll.h-patch
Any progress on that? I have similar problem in Ubuntu 10.04.
This is only going to get more embarassing, as machines get more ram and toolkits continue their trend to just send a pixmap to the server. I'm hitting the 256 limit everyday now, on a meduim-spec work laptop running kde.
Wondering what the current state for this bug is. Is someone working on this or is this stale? I don't mind helping out but my C knowledge is not as strong as my other languages and experiences. Is it just a matter of upping the include file's value? #define MAXCLIENTS 512 Or is it much more involved. I am looking for a fix for this issue. I use Xorg everyday and get max clients errors all the time and would like to leave applications running on all my virtual desktops. So just wondering whats going on and if I could help some how. I do know that Red Hat is patching to increase the MAXCLIENTS number but, as for Debian they would like this fixed upstream after looking into their bug tracking system. Best intentions, CS
Sorry, we forgot to update the bug. The fix was integrated to Xorg 1.18: https://cgit.freedesktop.org/xorg/xserver/commit/?id=d206c240c0b85c4da44f073d6e9a692afb6b96d2 and further changes have been integrated for 1.19: https://cgit.freedesktop.org/xorg/xserver/commit/?id=e0edb963fe09582f23a4b55da4f8840173e7a1ee
(In reply to Alan Coopersmith from comment #9) > Sorry, we forgot to update the bug. The fix was integrated to Xorg 1.18: > https://cgit.freedesktop.org/xorg/xserver/commit/ > ?id=d206c240c0b85c4da44f073d6e9a692afb6b96d2 > and further changes have been integrated for 1.19: > https://cgit.freedesktop.org/xorg/xserver/commit/ > ?id=e0edb963fe09582f23a4b55da4f8840173e7a1ee Thank you all for the fix. To show my appreciation I donated a small token at the donate page. Much is appreciated.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.