On Thu, Nov 02, 2006 at 01:55:41PM +0100, Jan Gorski wrote:
> On Wed, 01 Nov 2006 at 19:51:20 -0500, Thomas Dickey wrote:
> > You could add a printf to get the number of screens in the display,
> > e.g., I did this (enabling trace), but a printf would also work:
> >
> > Trace("FIXME %d\n", dpy->default_screen);
> > Trace("FIXME %d\n", dpy->nscreens);
> > if (XParseColor(screen->display, cmap, spec, &def)
>
> Well, dpy is no defined in function AllocateAnsiColor(...), I used:
sorry - I should have pasted that - something like
Display *dpy = screen->display;
> printf("Before XParseColor\n def_screen = %d\n nscreens = %d\n",
> DefaultScreen(screen->display),
> ScreenCount(screen->display));
>
> But I did not any programming in plain X and am not sure if this is what you
> wanted to see.
that looks right (thanks)
> > For the normal single-screen, that's default_screen=0, nscreens=1.
>
> My code gives
>
> (gdb) run
> Starting program: /home/slimak/kodowanie/got/debian/xterm-210/xterm
> (start mc here)
> XXX Before XParseColor
> def_screen = 0
> nscreens = 1
> (those three lines repeated few times)
ok - then my guess was wrong. It seems that xinerama is presenting a single
screen to the application. That's good since I don't have to change xterm
to work with that, bad since it's pointing to the X libraries or server.
Oddhand, I _think_ the poll() call is from the X libraries talking to the
X server.
> both on single and multihead configurations.
>
> Xterm allocates few colours in first run and then freezes in poll(). On
> subsequent run it allocates more colours and freezes, on third run it works.
> But
> I remember, that it is a little bit random --- some times in the past it
> needed
> more mc runnings before stopping freezes.
>
> I have also created new user and tested xterm on it --- it worked. So I
> started
> looking for a reason, and found it. If on newly created user I add .Xresources
> with this line
>
> xterm*font: -xos4-terminus-bold-r-normal--24-*-*-*-*-*-iso10646-1
>
> the problem appears if xterm is run on multihead xinerama configuration.
One issue with the iso10646 fonts is that the X server (or associated server)
has to load the font. That makes uxterm setup perhaps ten times slower than
xterm. Apparently _each_ process that requires the fonts has to get that
information separately.
Perhaps the problem is related to time.
Or perhaps the xinerama configuration limits the amount of X resource data
that is stored, to allow for multiple screens.
> On single head it works fine.
>
> Another strange thing --- it somtimes happens, that after starting xterm (on
> multihead and with changed font) it is completly white --- the command promt
> is
> not visible. New characters are visible.
From xterm's viewpoint, that could be a missed exposure event, or it could
mean that some colors were not allocated. (Sometimes it is time-dependent,
so I cannot always see things like that in a trace).
> > Next - to see if xterm is seeing more than one screen, if being started
> > on the second screen is the cause of the problem (confusing X), and if so,
> > whether the display information passed to xterm can tell it to use a
> > different screen number. If that's the explanation, I can modify xterm
> > to take that into account. (If it's not, I'm still puzzled ;-)
>
> Thats part of my xorg.conf
>
> Section "ServerLayout"
> Identifier "ii19ii22"
> Screen 0 "II22 NV436" 1280 0
> Screen 1 "II19 NV432" 0 0
> Option "Xinerama"
> InputDevice "HHKB"
> InputDevice "Mysz A4Tech 0"
> Option "CustomKeycode" "on"
> EndSection
>
> xterm starts always on left screen, which is Screen 1
> but when using xinerama there is no screen :0.1 ---
>
> [EMAIL PROTECTED]:~$ set |grep DISP
> DISPLAY=:0.0
> [EMAIL PROTECTED]:~$ xterm -display :0.1
> xterm Xt error: Can't open display: :0.1
>
> As I recall xinerama merges all screens --- it even allows overlapping of
> them.
ok - I was unfamiliar with it on the initial report. But reading about it
since then, it does sound as if its operation is intended to be transparent.
If it is only the (size of the) font, you might be able to compare other
applications loading the font, to see if they are successful. xfd would give
some insight (though I expect it uses less resources than xterm). A web
browser would probably use more resources, though getting it to load a specific
font might be hard.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
pgpuPVAYGq5Pb.pgp
Description: PGP signature
