Does the via driver support 3D with dualhead? It seems to. I noticed
the following code in via_context.c:
GLboolean saam;
int count = 0, fbSize;
saam = XineramaIsActive(vmesa->display);
if (saam && vmesa->viaScreen->drixinerama) {
vmesa->xsi = Xinerama
I managed to get the vtxfmt path enabled and fixed a small problem that
didn't show up when vtxfmt wasn't enabled. Flightgear performance
increased only marginally since it draws most of its geometry using
vertex arrays which is a vtxfmt fallback. I was able improve the
situation by not installing
- 3D now works with 2D acceleration enabled
- Chromium BSU runs entirely
- Window overlapping now works
- Tuxracer works except that the initial screen has a pale brown
not a pale blue background (any ideas anyone ?)
- Most screensavers run - morph3d and pipes crash
- Several screensavers (but n
On Fri, 2 Jan 2004, Nigel Cunningham wrote:
>
> Of course there are also advantages to _not_ using the file-per-kernel
> version scheme.
No there isn't.
The thing is, you should keep those "file-per-OS" files as small as
possible, and only contain the things that are literally different.
Bec
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=1038
--- Additional Comments From [EMAIL PROTECTED] 2004-01-01 17:46 ---
I think you need
On Fri, 2004-01-02 at 09:19, Linus Torvalds wrote:
> In contrast, full-file interfaces for different kernel versions are a
> _lot_ easier to merge and keep track of. They may look like "duplication",
> but the advantages are legion. You don't mix different OS's and different
> versions together,
On Thu, 1 Jan 2004, Michel Dänzer wrote:
>
> > well the advantage is that the ifdefs can just go away in kernel trees of
> > specific versions... (eg unifdef it)
>
> Does this look better? Maybe a macro (or a typedef?) for the type of the
> last argument would still be a good idea? Or is there y
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=1038
[EMAIL PROTECTED] changed:
What|Removed |Added
-
On Iau, 2004-01-01 at 13:50, Michel DÃnzer wrote:
> > Okay, you did something weird with nopage args, but I thought I did
> > the equivalent of this in the original patch?
>
> This is about the canonical DRM code in the DRI tree.
99.9% of people run the DRM code in the kernel tree, so definitions
On Thu, Jan 01, 2004 at 03:27:59PM +0100, Michel D?nzer wrote:
> Does this look better? Maybe a macro (or a typedef?) for the type of the
> last argument would still be a good idea? Or is there yet a better way?
I'm going to regret suggesting this, but how about:
(a) a typedef for the arg itself
(
On Thu, 01 Jan 2004 02:01:27 +
Alan Cox <[EMAIL PROTECTED]> wrote:
> I "played" tuxracer using XFree 4.3.0 and my test code last might. Depth
> buffering in some cases is shot, there is a lot of fallback stuff
> occuring for clipped polygons that isnt working and things are a
> peculiar brown
On Thu, 2004-01-01 at 13:28, Arjan van de Ven wrote:
> On Thu, Jan 01, 2004 at 01:23:40PM +0100, Michel DÃnzer wrote:
> > >
> > > I find using #defines for function arguments ugly beyond belief and
> > > makes it really hard to look through code. I 10x rather have an ifdef in
> > > the function pr
On Thu, 2004-01-01 at 14:33, William Lee Irwin III wrote:
>> Okay, you did something weird with nopage args, but I thought I did
>> the equivalent of this in the original patch?
On Thu, Jan 01, 2004 at 02:50:30PM +0100, Michel D?nzer wrote:
> This is about the canonical DRM code in the DRI tree.
On Thu, 2004-01-01 at 14:33, William Lee Irwin III wrote:
> On Thu, Jan 01, 2004 at 01:03:38PM +0100, Michel D?nzer wrote:
> > No, this is Linux specific.
> > How does this patch look?
>
> Okay, you did something weird with nopage args, but I thought I did
> the equivalent of this in the original
On Thu, Jan 01, 2004 at 01:03:38PM +0100, Michel D?nzer wrote:
> No, this is Linux specific.
> How does this patch look?
Okay, you did something weird with nopage args, but I thought I did
the equivalent of this in the original patch?
-- wli
On Thu, Jan 01, 2004 at 01:23:40PM +0100, Michel Dänzer wrote:
> > > How does this patch look?
> >
> > ugly.
> >
> > I find using #defines for function arguments ugly beyond belief and
> > makes it really hard to look through code. I 10x rather have an ifdef in
> > the function prototype (which t
Following up to the list as Michael's ISP doesn't seem to accept mail from
me, without giving a reason...
On Thu, 2004-01-01 at 22:49, MichaelM wrote:
> > Thanks. I don't see any obvious problems; does setting the R200_NO_IRQS
> > environment variable make a difference?
>
> Nup, that made no dif
On Thu, 2004-01-01 at 13:10, Arjan van de Ven wrote:
> On Thu, 2004-01-01 at 13:03, Michel DÃnzer wrote:
>
> > How does this patch look?
>
> ugly.
>
> I find using #defines for function arguments ugly beyond belief and
> makes it really hard to look through code. I 10x rather have an ifdef in
>
On Thu, 2004-01-01 at 13:03, Michel DÃnzer wrote:
> How does this patch look?
ugly.
I find using #defines for function arguments ugly beyond belief and
makes it really hard to look through code. I 10x rather have an ifdef in
the function prototype (which then for the mainstream kernel drm can be
On Wed, 2003-12-31 at 19:21, Jon Smirl wrote:
> The headers for nopageXX calls just changed.
>
> struct page * (*nopage)(struct vm_area_struct * area, unsigned long address, int
> unused);
> changed to:
> struct page * (*nopage)(struct vm_area_struct * area, unsigned long address, int
> *type);
>
On Thu, 2004-01-01 at 21:21, MichaelM wrote:
> On Thursday 01 January 2004 08:41, Michel DÃnzer wrote:
> > Nor is it a hard lock. :) Can you also log in remotely and kill the
> > game? What about glxgears, does it also lock up? Can you close the
> > window? ...
>
> I haven't tried to log in remote
On Thursday 01 January 2004 08:41, Michel DÃnzer wrote:
> Nor is it a hard lock. :) Can you also log in remotely and kill the
> game? What about glxgears, does it also lock up? Can you close the
> window? ...
I haven't tried to log in remotely, but I can alt-ctrl-f2 to a console and
kill the prog
On Thu, 2004-01-01 at 20:07, MichaelM wrote:
> I tried installing the new ati binary drivers, and every game, except Enemy
> Territory hard locks on start-up. I can, however, alt-ctrl-backspace back to
> the console, so it's not the end of the world.
Nor is it a hard lock. :) Can you also log in
I tried installing the new ati binary drivers, and every game, except Enemy
Territory hard locks on start-up. I can, however, alt-ctrl-backspace back to
the console, so it's not the end of the world.
I initially though it was an issue with the ati drivers, but when I reverted
to the DRI drivers,
24 matches
Mail list logo
