On Wed, 2003-09-10 at 14:04, Michel Dänzer wrote: > On Tue, 2003-09-09 at 07:54, Soeren Sonnenburg wrote: > > On Tue, 2003-09-09 at 01:47, Michel Dänzer wrote: > > > On Mon, 2003-09-08 at 06:52, Soeren Sonnenburg wrote: > > > > > > > > I just realized that the daily updatedb run caused this 1G Ti 15" > > > > powerbook to swap (with just some apps open under X).
Ok, finally the problem reoccured and I found one client which seems to be responsible (taking 940MB as pixmaps) : Client 12 (base = 0x1a00000, mask = 0x1fffff): 7 resource types WINDOW: 4 PIXMAP: 44 (940768384 bytes) GC: 21 FONT: 7 CURSOR: 33 Unregistered resource 20: 2 Unregistered resource 34: 1 however the last action I did was popping up an xmms playlist window (which never appeared, but xmms quit instead)... then I found way to large window sizes in the .xmms/config file for that playlist window... so I don't know whether what I saw beforehand was a cause of this. So I better take back everything I said about memoryleaks until I see the problem reoccur without xmms. Sorry about that false report. However how can I find out who client 12 is ? > > > BTW, 2.6 kernels handle this much better than 2.4 kernels. :) > > > > But these don't happen to boot already on ppc machines right ? > > But sure they do. :) I'm using the linuxppc-2.5 tree via rsync, there's > also linuxppc-2.5-benh if you don't mind using bk. Beware that there are > still many minor problems, but the only major problem for me is that > sleep doesn't work with the linuxppc-2.5 tree yet. it looks like I will also jump on the 2.5/2.6-test track as soon as I find the time. > You should probably ask the following questions on an XFree86 mailing > list, but I'll do my best to answer some nonetheless. > > > BTW, is there a way to limit the movement of the mouse cursor, i.e. I > > want to limit it when I am disconnected from the second head to :0 and > > then when reconnected allow the full width of :0 and :1 ? > > There's no possibility to do this in the server yet, but it might be > possible to achieve this with a client to some extent. that client would need to hang in the message queue and discard movements over the border... hmmhh could work :-) [moving windows from :0 to :1 and vice versa] > Not transparently to clients, as non-Xinerama heads are basically > separate displays, but as I said earlier, GTK+ as of version 2.2 can do > this, though unfortunately there's no app-independent support for it > yet, see e.g. > http://mail.gnome.org/archives/wm-spec-list/2003-May/msg00029.html, > http://mail.gnome.org/archives/gtk-devel-list/2002-November/msg00103.html and > http://www.spinics.net/lists/xf-xpert/msg04877.html . nice links, I will investigate that. Soeren.
