Fonts carriage return

2003-12-16 Thread Frank Gießler
Hi,

Any ideas how to prevent CR from being rendered in bitmap and scalable fonts?

TIA,
Frank.
--
 Frank Giessler
 Klinikum der Universitaet Jena   Tel.: +49-3641-9 32 57 80
 Biomagnetisches Zentrum  Fax : +49-3641-9 32 57 72
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: Static GLX extension?

2003-11-20 Thread Frank Gießler
David Dawes wrote:

There are no standard build switches for selectively building in
extensions.  It would be easier to build a completely static server
I tried that. Unfortunately, my linker segfaults when linking the server. That's why I want 
only GLX to be static.

Thanks,
Frank.
--
 Frank Giessler
 Klinikum der Universitaet Jena   Tel.: +49-3641-9 32 57 80
 Biomagnetisches Zentrum  Fax : +49-3641-9 32 57 72
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Static GLX extension?

2003-11-19 Thread Frank Gießler
Hi all,

I need some help. For debugging purposes I want to build a server that is loadable, except 
for the glx module which should be statically linked in. How do I do this?

TIA,
Frank.
--
 Frank Giessler
 Klinikum der Universitaet Jena   Tel.: +49-3641-9 32 57 80
 Biomagnetisches Zentrum  Fax : +49-3641-9 32 57 72
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: glx failing

2003-11-14 Thread Frank Gießler
David Dawes wrote:
The patch below fixes the problem.  The command lengths for several
rendering requests were getting set incorrectly because of mis-ordered
variable initialisations.  I'm committing it now.
Index: g_render.c
===
RCS file: /home/x-cvs/xc/lib/GL/glx/g_render.c,v
retrieving revision 1.5
diff -u -r1.5 g_render.c
I'm still getting the same error with some Mesa demos (cubemap, drawpix, fire, gamma, gloss, 
and more). Others work (bounce, clearspd, gears, geartrain, and more).

The patch above only changes g_render.c, what about render2.c and renderpix.c? In them, there 
also some places that look very similar to the ones changed in g_render.c.

Just a thought...

Regards,
Frank.
--
 Frank Giessler
 Klinikum der Universitaet Jena   Tel.: +49-3641-9 32 57 80
 Biomagnetisches Zentrum  Fax : +49-3641-9 32 57 72
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


glx failing

2003-11-10 Thread Frank Gießler
Hi all,

with my current CVS snapshot (Changelog up to #530), glxgears gives me the following at startup:

X Error of failed request:  BadLength (poly request too large or internal Xlib length 
error)
  Major opcode of failed request:  144 (GLX)
  Minor opcode of failed request:  1 (X_GLXRender)
  Serial number of failed request:  22
  Current serial number in output stream:  23
This used to work before. I've seen this on both OS/2 and SuSE Linux 8.2 (XFree CVS built 
without DRI). Any idea what this means and/or where I should look?

Thanks,
Frank.
--
 Frank Giessler
 Klinikum der Universitaet Jena   Tel.: +49-3641-9 32 57 80
 Biomagnetisches Zentrum  Fax : +49-3641-9 32 57 72
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: Server regeneration no longer works

2003-10-28 Thread Frank Gießler
David Dawes wrote:
On Wed, Oct 15, 2003 at 04:17:35PM -0400, David Dawes wrote:

On Wed, Oct 15, 2003 at 12:53:32PM -0400, Mark Vojkovich wrote:

Start the server with no clients and access control disabled
XFree86 -ac.  Run a client and kill it, or run a client that
terminates itself (like xset) and the server segfaults on the
server regeneration.  I'm having a hard time getting a back trace.
It looks like the stack is trashed pretty badly.  This appears
to be a recent regression.
It looks like a malloc/free bug -- maybe a double free somewhere.  I
see it crashing in free(), called from CMapUnwrapScreen().  If I add
some debugging ErrorF's the caller of the crashing free() moves.  I'll
try a build on FreeBSD and enable some of its malloc debugging flags.


That located the problem nicely, aborting at the actual double-free.
The screen saver timers get freed in TimerInit() for each generation.
However, the timer pointers kept by the screen saver code weren't being
cleared for each generation, so the old values kept being used and added
back to the timers list.  Then they'd get freed again in TimerInit() at
the second regeneration.  Not to mention that freed memory was still
being used.  I'm going to commit a fix that clears the Screensaver and
DPMS timers at each regeneration.
David
Is this fix available as a single patch? I would like to check whether this also fixes 
Bugzilla's #776.

Thanks, Frank.

--
 Frank Giessler
 Klinikum der Universitaet Jena   Tel.: +49-3641-9 32 57 80
 Biomagnetisches Zentrum  Fax : +49-3641-9 32 57 72
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel