On Sun, 2004-02-15 at 02:27, Dieter Nützel wrote:
>
> The xscreensaver flickering is a KDE (3.2) problem.
> KDE seems to be using xscreensaver without double buffering.
> Why this?
Hi had same problem with savage-2-0-0-0 branch.
FC1 have one update of X XFree86-4.3.0-55, and I had installed ov
On Tue, 17 Feb 2004 12:38:04 -0800
Alex Deucher <[EMAIL PROTECTED]> wrote:
> CVSROOT: /cvs/dri
> Module name: xc
> Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/savage/
> Changes by: [EMAIL PROTECTED] 04/02/17 12:38:04
>
> Log message:
> - fix console corruption. rather
On Tue, Feb 17, 2004 at 09:00:12PM +0100, Bernhard Wymann wrote:
> Hi All
>
> >>The microcode in the MGA driver can't handle multi texturing with
> >>projective textures. See Ville's comments in the thread "Slow Mtex in
> >> DRI".
> >
> >But in this case I think it should still work, just dead sl
I have lodged a bug report reguarding mutlitexture
being slower than multipass with radeons and DRI with mesaGL at http://sourceforge.net/tracker/index.php?func=detail&aid=899074&group_id=3&atid=13 as
I feel this may be a mesaGL bug that effects DRI. But please correct me if I'm
wrong.
Hi All
The microcode in the MGA driver can't handle multi texturing with
projective textures. See Ville's comments in the thread "Slow Mtex in
DRI".
But in this case I think it should still work, just dead slow (with a
software fallback). If I understand the torcs thread correctly, it just
cra
Roland Scheidegger wrote:
Bernhard Wymann wrote:
If you'd use glutInitDisplayString with depth>=16 you _should_ get a
24bit depth buffer if available though, at least in theory - if
not that would be a bug in glut or the glx visual matching code.
That might be true, but the code runs also on Wind
On Tue, Feb 17, 2004 at 07:24:07PM +0100, Roland Scheidegger wrote:
> >>Also, the OP is using the drivers from matrox, he should try the
> >>"normal" drivers. If this bug is only in the matrox version of the
> >> driver (I don't think it is, but it might be possible), then
> >>there's little the d
Bernhard Wymann wrote:
Hi, nice to hear from you,
If you'd use glutInitDisplayString with depth>=16 you _should_ get
a 24bit depth buffer if available though, at least in theory - if
not that would be a bug in glut or the glx visual matching code.
That might be true, but the code runs also on W
Felix Kühling wrote:
On Tue, 17 Feb 2004 17:46:48 +0100 Roland Scheidegger
<[EMAIL PROTECTED]> wrote:
[snip]
The GLX visual matching code is pretty much driver-independant, so
it's odd this would only be a problem with the mga driver. That
said, there were some changes in that area since XFree
Hi, nice to hear from you,
If you'd use glutInitDisplayString with depth>=16 you _should_ get
a 24bit depth buffer if available though, at least in theory - if not
that would be a bug in glut or the glx visual matching code.
That might be true, but the code runs also on Windows and proprietary
li
I chatted with a friend of mine who is an IP lawyer regarding s3tc.
Here was his response:
"I looked at the claims, and they all seem to be
related to processing, as opposed to data structures
or protocol, so it seems as long as the driver isn't
doing any processing you should be fine. Since you
On Tue, 17 Feb 2004 17:46:48 +0100
Roland Scheidegger <[EMAIL PROTECTED]> wrote:
[snip]
> The GLX visual matching code is pretty much driver-independant, so it's
> odd this would only be a problem with the mga driver. That said, there
> were some changes in that area since XFree86 4.3, but I don't
--- Felix Kühling <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I just took a brief look at the savage 2D driver. It looks like the
> COB
> is never enabled. On Savage4 and ProSavages it explicitly left
> disabled
> in SavageInitialize2DEngine. On the Savage3D/MX/IX that function is
> never even called. Ye
(also cc to dri-devel, not all developers might read dri-users)
Bernhard Wymann wrote:
Hi all
I'm a developer of the TORCS (The Open Racing Car Simulatior)
project, look at www.torcs.org. A user reported that the
initialization of TORCS 1.2.2 fails with his Matrox g550. I post here
because I w
Hi,
I just took a brief look at the savage 2D driver. It looks like the COB
is never enabled. On Savage4 and ProSavages it explicitly left disabled
in SavageInitialize2DEngine. On the Savage3D/MX/IX that function is
never even called. Yet I'm surprised that the 3D driver doesn't crash
and burn all
Ian Romanick wrote:
Brian Paul wrote:
Ian Romanick wrote:
2. Mesa's X11 driver, which is the basis of libGLcore, depends on
information from an X VisualInfo. Most of the uses can be eliminated
trivially, but the depth / nplanes and ColomapEntries / colormap_size
fields are another story. The
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=314
[EMAIL PROTECTED] changed:
What|Removed |Added
--
At 09:16 AM 17/2/2004, Felix Kühling wrote:
That's what I hoped. But unfortunately that's not the case. Now the
driver locks up in other situations that were fine before. Disabling DMA
apparently just masked the problem in some cases. I discussed this with
Alex on IRC yesterday. I'm going to try t
On Tue, 17 Feb 2004 08:59:20 -0300
Rafael Maximo <[EMAIL PROTECTED]> wrote:
> At 07:45 PM 14/2/2004, Felix Kühling wrote:
>
> >I'm downloading the game just now. :) I get another reproducable hard
> >lockup when the glblur xscreensaver hack exits. I havn't had time to
> >look into it yet. Can you
At 07:45 PM 14/2/2004, Felix Kühling wrote:
I'm downloading the game just now. :) I get another reproducable hard
lockup when the glblur xscreensaver hack exits. I havn't had time to
look into it yet. Can you try if setting SAVAGE_CMD_DMA to 0 in
savagedma.h helps. Just a guess.
Note that multiple
20 matches
Mail list logo
