Date: Mon, 27 Sep 2004 20:54:36 -0700 From: Eric Anholt <eta@lclark.edu> To: Lauri J =?ISO-8859-1?Q?J=E4rvenp=E4=E4?= <Lauri.Jarvenpaa@students.turkuamk.fi> Cc: ports@freebsd.org Subject: Re: dri/drm/blender problem: no redraw? Message-ID: <1096343675.1024.1496.camel@leguin> In-Reply-To: <OFD9FF1C00.E06F8069-ONC2256F1C.0065E47B-C2256F1C.0065E48F@turkuamk.fi> References: <OFD9FF1C00.E06F8069-ONC2256F1C.0065E47B-C2256F1C.0065E48F@turkuamk.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2004-09-27 at 11:32, Lauri J Järvenpää wrote: > Hi. > > When using ports/graphics/blender on FreeBSD 4.10 with drm-kmod-0.9.6 and > dri-5.0.2,2 with Matrox G400 DualHead, scene is not redrawn after mouse > click. Instead screen just goes grey. Same happens when editing mesh. > Similar problems exist with menus: their backdrop is not drawn. Instead > text is drawn on scene, making it impossible to read. > > This problem appeared (I think, didn't write it down back then) in dri > version 5.x. Because once I had a working OpenGL setup. Problem exists in > every tested Blender version (2.28, 2.3x), so it must be in the drivers. > > And as I've heard of no-one who has experienced this with other cards, I > would say it is a MGA DRI/DRM problem. It is. > I have sent several mails and filed a bug report about it at dri bugzilla, > but nobody seems to be interested. If Matrox G400 is unsupported by dri > project (and therefore by FreeBSD ports), shouldn't it be dropped from the > package? The G400 works for many people. Blender is one of the few apps that it doesn't work on, and it also happens to be a large app and non-obvious to us developers to use as far as testing. Somebody affected by the bug would need to go and debug the issue. The DRI project is very short of hands, for the amount of work there is to be done (take a look at the number of unfinished drivers we have. for even more fun run glean on the drivers we do have.) There are a few things to do to help get the problem solved: 1) Binary search and find when the issue first appeared. 2) Debug the driver yourself and propose a fix. 3) Read the blender code and construct a small testcase that demonstrates an issue. Use the environment variable LIBGL_ALWAYS_INDIRECT=1 to force an app to software rendering, to compare to what's done with hardware rendering. -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1096343675.1024.1496.camel>