Hi,
I've had some problems with certain DRI applications occasionally
corrupting fonts in programs that use Xft. The corruption was
noticeable after the DRI program exited. Strangely, it could be
mitigated by running another different DRI program afterwards; this
seems to be the only way to get
turn off HW render accel. both HW render and 3D use the 3D engine and
I don't know if they both keep state properly. that's probably were
your corruption comes from.
Alex
--- Ryan Underwood <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I've had some problems with certain DRI applications occasionall
By "turn off HW render", you mean RenderAccel "off", or NoAccel "on" ?
BTW, I should clarify my previous post by saying that the fonts across
_all_ Xft applications are corrupted when any of them is corrupted by
DRI usage; no other non-AA fonts or pixmap data are affected, however.
It is only AA
renderaccel. the reason for the curruption is that both the 2d driver
and the 3d driver are using the 3d engine. since they are not keeping
state (render accel my write on 3d textures and vice versa, etc.),
games will corrupt fonts and vice versa. Unfortunately it's a tough
problem to solve. I
Thanks for the insight. Is this already something that has been
extensively looked at without success, or would it be worth my time to
dig into the code and try to find the cause? I've thought about it, but
afraid that I will just hit a brick wall someone else already ran into
with it. ;)
Is th
You could dig into it if you wish. if this is indeed the problem, you
will have to figure out a way to maintain the state of the 3d enigne
between the render accel and the DRI. you might want to ask Ian about
it. you can also check the archives. there was some discussion about
this in regards t
On Tue, Dec 09, 2003 at 01:24:16PM -0600, Ryan Underwood wrote:
>
> Thanks for the insight. Is this already something that has been
> extensively looked at without success, or would it be worth my time to
> dig into the code and try to find the cause? I've thought about it, but
> afraid that I w
On Wed, Dec 10, 2003 at 09:03:34AM +0200, Ville Syrjälä wrote:
> On Tue, Dec 09, 2003 at 01:24:16PM -0600, Ryan Underwood wrote:
> >
> > Thanks for the insight. Is this already something that has been
> > extensively looked at without success, or would it be worth my time to
> > dig into the cod
On Wed, Dec 10, 2003 at 04:26:25AM -0600, Ryan Underwood wrote:
>
> On Wed, Dec 10, 2003 at 09:03:34AM +0200, Ville Syrjälä wrote:
> > On Tue, Dec 09, 2003 at 01:24:16PM -0600, Ryan Underwood wrote:
> > >
> > > Thanks for the insight. Is this already something that has been
> > > extensively loo
On Wed, 10 Dec 2003, Ryan Underwood wrote:
> >
> > They're not available anymore :( It's a real shame since they seemed to be
> > quite friendly towards open source developers at one point. I can almost
> > understand that they don't want to release any parhelia docs but I don't
> > understand wh
On Wed, Dec 10, 2003 at 08:52:03AM -0800, Linus Torvalds wrote:
>
> > Must be some new management over there... *sigh*
>
> Never attribute to malice what can be sufficiently explained by
> laziness or stupidity.
^
Why do you think I mentioned "management"? :)
> But when it
On Wed, Dec 10, 2003 at 12:25:36PM -0600, Ryan Underwood wrote:
>
> In an open software architecture like the DRI, we should do our best to
> support proprietary vendors when they give us the means to do so, but
> all the pissing and moaning about what they will and won't do should go
> either to /
On Wed, Dec 10, 2003 at 06:32:18AM -0600, Ryan Underwood wrote:
>
> On Wed, Dec 10, 2003 at 12:53:53PM +0200, Ville Syrjälä wrote:
> >
> > If you remove/comment out the following line
> > $(MAKE_CMD) $(MFLAGS) $(WORLDOPTS) World
> > in the top Makefile "make World" shouldn't actually buil
On Thu, Dec 11, 2003 at 02:02:36PM +0200, Ville Syrjälä wrote:
>
> I don't run XFree86 except when trying to hunt DRI related bugs. It's
> been well over a year since I really used XFree86 and I honestly don't
> remember if DPMS ever worked with the second head. I don't have a second
> monitor to
Ville,
On Thu, Dec 11, 2003 at 02:02:36PM +0200, Ville Syrjälä wrote:
>
> I can't reproduce any font corruption with crack-attack (or any other gl
> app) and quake2 just segfaults when I try to run it. Maybe it doesn't
> like to run with the demo pak file...
>
> But running quake3 and crack-att
On Tue, Jan 20, 2004 at 03:52:37AM -0600, Ryan Underwood wrote:
>
> Ville,
>
> On Thu, Dec 11, 2003 at 02:02:36PM +0200, Ville Syrjälä wrote:
> >
> > I can't reproduce any font corruption with crack-attack (or any other gl
> > app) and quake2 just segfaults when I try to run it. Maybe it doesn't
--- Ryan Underwood <[EMAIL PROTECTED]> wrote:
>
[snip]
>
> > > On another topic, do you use a dualhead G400? If so, are you
> able to
> > > properly use DPMS on the second head?
> >
> > I don't run XFree86 except when trying to hunt DRI related bugs.
> It's
> > been well over a year since I re
On Tue, Jan 20, 2004 at 12:57:11PM +0200, Ville Syrjälä wrote:
> > The only problem I have with the mga driver right now is lack of mouse
> > cursor in UT, though there is a claim in bugzilla that you fixed it. Do
> > you have any details on the fix?
>
> http://freedesktop.org/cgi-bin/viewcvs.cg
--- Ryan Underwood <[EMAIL PROTECTED]> wrote:
>
> On Tue, Jan 20, 2004 at 12:57:11PM +0200, Ville Syrjälä wrote:
> > > The only problem I have with the mga driver right now is lack of
> mouse
> > > cursor in UT, though there is a claim in bugzilla that you fixed
> it. Do
> > > you have any detai
On Wed, 2004-01-21 at 00:02, Ryan Underwood wrote:
>
> Are those fixes on a branch somewhere? It appears trunk's version is:
> /* $XFree86: xc/lib/GL/mesa/src/drv/mga/mga_xmesa.c,v 1.19 2003/03/26 20:43:49 tsi
> Exp $ */
>
> but that is from Michel's trunk packages, so I don't know if he is
> co
On Wed, Jan 21, 2004 at 01:30:15AM +0100, Michel Dänzer wrote:
> On Wed, 2004-01-21 at 00:02, Ryan Underwood wrote:
> >
> > Are those fixes on a branch somewhere? It appears trunk's version is:
> > /* $XFree86: xc/lib/GL/mesa/src/drv/mga/mga_xmesa.c,v 1.19 2003/03/26 20:43:49 tsi
> > Exp $ */
>
On Wed, Jan 21, 2004 at 01:30:15AM +0100, Michel Dänzer wrote:
> On Wed, 2004-01-21 at 00:02, Ryan Underwood wrote:
> >
> > Are those fixes on a branch somewhere? It appears trunk's version is:
> > /* $XFree86: xc/lib/GL/mesa/src/drv/mga/mga_xmesa.c,v 1.19 2003/03/26 20:43:49 tsi
> > Exp $ */
>
On Tue, Jan 20, 2004 at 08:23:55AM -0800, Alex Deucher wrote:
> > >
> > > I don't run XFree86 except when trying to hunt DRI related bugs.
> > It's
> > > been well over a year since I really used XFree86 and I honestly
> > don't
> > > remember if DPMS ever worked with the second head. I don't hav
--- Ryan Underwood <[EMAIL PROTECTED]> wrote:
[snip]
>
> No code was copied, only some defines. I need other people to check
> the
> code and tell me if it will break on other video cards. I only have
> a
> G400 DH, but there is G450, G550, G200 DH, G200 non-maven DH, etc
> which
> need to be t
On Tue, Jan 20, 2004 at 02:13:50PM -0800, Alex Deucher wrote:
>
> --- Ryan Underwood <[EMAIL PROTECTED]> wrote:
> [snip]
> >
> > No code was copied, only some defines. I need other people to check
> > the
> > code and tell me if it will break on other video cards. I only have
> > a
> > G400 DH
On Wed, 2004-01-21 at 04:52, Ryan Underwood wrote:
> On Wed, Jan 21, 2004 at 01:30:15AM +0100, Michel DÃnzer wrote:
> > On Wed, 2004-01-21 at 00:02, Ryan Underwood wrote:
> > >
> > > Are those fixes on a branch somewhere? It appears trunk's version is:
> > > /* $XFree86: xc/lib/GL/mesa/src/drv/mga
On Wed, Jan 21, 2004 at 03:24:23PM +0100, Michel Dänzer wrote:
>
> Well, yes, it's hard to package future changes. :)
>
> (BTW, the XFree86 tag is only relevant in XFree86 CVS, and Ville's fixes
> likely happened after 2003/10/05.)
Oops, you're right. They were from November.
> PS: You get th
Keep in mind that if you have previously checked out a branch, the
'no -r' option will keep you on that branch. If you have previously
checked out a branch into your working area, make sure you do a
update with '-A' which forgets the sticky tags (in this case a branch).
Regards,
Matthew
Ryan
[reposting... attachments caused message to be killed]
On Wed, Dec 10, 2003 at 12:53:53PM +0200, Ville Syrjälä wrote:
>
> If you remove/comment out the following line
> $(MAKE_CMD) $(MFLAGS) $(WORLDOPTS) World
> in the top Makefile "make World" shouldn't actually build anything.
> After
29 matches
Mail list logo
