It shouldn't be very hard to do this for:
sis, tdfx, i810, i830, savage, gamma
so are we making the Mesa tree the DRM master repo as opposed to the DRI
tree? I don't remember much discussion on this either way,
What about?
mach64, unichrome
Where are the DRM drivers for these two?
mach64
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
--- Additional Comments From [EMAIL PROTECTED] 2004-03-12 06:36 ---
hi people,
i
On Fri, 2004-03-12 at 11:25, Dave Airlie wrote:
It shouldn't be very hard to do this for:
sis, tdfx, i810, i830, savage, gamma
so are we making the Mesa tree the DRM master repo as opposed to the DRI
tree? I don't remember much discussion on this either way,
Indeed, and I don't
Michel Dnzer wrote:
On Fri, 2004-03-12 at 11:25, Dave Airlie wrote:
It shouldn't be very hard to do this for:
sis, tdfx, i810, i830, savage, gamma
so are we making the Mesa tree the DRM master repo as opposed to the DRI
tree? I don't remember much discussion on this either way,
Indeed, and I
On Fri, 12 Mar 2004 14:48:45 +
avilella [EMAIL PROTECTED] wrote:
The DRI seems to be enabled:
-
[snip]
yes, looks good.
-
and here is the log of:
[avb]$ LIBGL_DEBUG=verbose glxinfo
-
name of display: :0.0
libGL: XF86DRIGetClientDriverName: 1.1.16 savage (screen
--- Felix Kühling [EMAIL PROTECTED] wrote:
On Fri, 12 Mar 2004 14:48:45 +
avilella [EMAIL PROTECTED] wrote:
The DRI seems to be enabled:
-
[snip]
yes, looks good.
-
and here is the log of:
[avb]$ LIBGL_DEBUG=verbose glxinfo
-
name of display:
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
Could folks that are seeing these issues, on any card, look in
/var/log/XFree86.0.log? Are there are any messages like the following?
My mission today is to track this down, and it looks like something is
subtly broken in the DRI context creation protocol between libGL and the
server.
(II)
MX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM r200_context.c
In file included from r200_context.c:54:
r200_context.h:572: error: parse error before drm_hw_lock_t
r200_context.h:572: Warnung: no semicolon at end of struct or union
r200_context.h:575: error: parse error before '}' token
r200_context.h:575:
I removed src/glx/mini/drm.h from CVS. Is it still in your local copy? If so it
will mask the version that is in src/mesa/drivers/dri/drm/shared/drm.h
--- Dieter Nützel [EMAIL PROTECTED] wrote:
MX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM r200_context.c
In file included from r200_context.c:54:
I just pulled a clean tree and it built without problems.
--- Dieter Nützel [EMAIL PROTECTED] wrote:
MX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM r200_context.c
In file included from r200_context.c:54:
r200_context.h:572: error: parse error before drm_hw_lock_t
r200_context.h:572: Warnung: no
--- Felix Kühling [EMAIL PROTECTED] wrote: On Thu,
11 Mar 2004 18:01:11 + (GMT)
deb pal [EMAIL PROTECTED] wrote:
Hi
I am using sis305 AGP card. I read all the
documents.
Including Thomas winiscoffer's sis page.To be
specific
the bios saysSiS 305 AGP 2X/4X True Color
I was checking all of the Mesa builds. I don't normally build in the dri tree, I
thought people were building in the Mesa tree.
It will take me a while to get a DRI build tree in place. Is there a simple fix
for this while I get the build environment in place? Where is the include path
that
--- deb pal [EMAIL PROTECTED] wrote: ---
Felix Kühling [EMAIL PROTECTED] wrote: On Thu,
11 Mar 2004 18:01:11 + (GMT)
deb pal [EMAIL PROTECTED] wrote:
Hies I loaded sis-agp and agpgart. IIRC they are
enough.
Interestingly the live CDs like knoppix and morphix
failed to load
deb pal wrote:
Mother board is Intel845 and agp card is sis305.
Do I need to insert agpart and intel-agp.ko ?
Or sis-agp ?
Since the AGP controller is by Intel, you need the Intel driver. :)
---
This SF.Net email is sponsored by: IBM Linux
Am Freitag, 12. März 2004 17:52 schrieb Jon Smirl:
I removed src/glx/mini/drm.h from CVS. Is it still in your local copy? If
so it will mask the version that is in
src/mesa/drivers/dri/drm/shared/drm.h
Mesa CVS:
/opt/Mesa find -name drm.h | xargs ls -la
-rw-r--r--1 nuetzel users
Let's try again with the right file. That's what I get for trying to hurry.
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Search - Find what youre looking for faster
http://search.yahoo.com
patch
Description: patch
I checked in the needed fixes to make DRI build again.
1) I copied the changes to the mesa DRM driver into the copy in the DRI tree
2) I adjusted some h files in the 2D drivers so as not to include the DRM
changes.
Sorry about the mess that I made. I hadn't been following the changes in how DRI
Ville Syrjälä wrote:
On Tue, Nov 11, 2003 at 10:50:01AM -0800, Ian Romanick wrote:
I must say that I am very impressed with how far the MGA driver has come
since you started working on it. Now the only thing that's missing is
support for PCI cards. ;)
A quick fix would be simply enabling PCI
from my laptop
01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M
AGP 2x (rev 64) (prog-if 00 [VGA])
looks the same to me and mine works :-) so yours should ...
On Fri, 12 Mar 2004, Mike Mestnik wrote:
I don't know, if it loads or not, I stoped trying when I found ought
On Gwe, 2004-03-12 at 21:40, Ian Romanick wrote:
MGADRIPciInit wouldn't be a complete duplication of MGADRIAgpInit
because I don't intend to (initially) support PCIGART. Even when
PCIGART is supported, not all chips in the MGA family support it. Is
the PCI G450 the only one?
Is there any
Alex Deucher wrote:
There was a website with support for the PCI G450 (for alpha I think):
http://www.instmath.rwth-aachen.de:8000/linux/G450-PCI/
However it seems to be down at the moment. Someone on the ML knew the
guy who was doing the work. perhaps they an find out the state of it.
It's been
Alan Cox wrote:
On Gwe, 2004-03-12 at 21:40, Ian Romanick wrote:
MGADRIPciInit wouldn't be a complete duplication of MGADRIAgpInit
because I don't intend to (initially) support PCIGART. Even when
PCIGART is supported, not all chips in the MGA family support it. Is
the PCI G450 the only one?
--- Ian Romanick [EMAIL PROTECTED] wrote:
Alex Deucher wrote:
There was a website with support for the PCI G450 (for alpha I
think):
http://www.instmath.rwth-aachen.de:8000/linux/G450-PCI/
However it seems to be down at the moment. Someone on the ML knew
the
guy who was doing the
Alex Deucher wrote:
--- Ian Romanick [EMAIL PROTECTED] wrote:
Alex Deucher wrote:
As I recall the G450-PCI cards were just AGP chips with an agp to pci
bridge. Perhaps you need to hack up an agpgart driver for the bridge?
Also, for the pci g450, matrox only supported 3D on motherboards with
Then comes the kernel. :( I started looking that the ILOAD code in
mga_state.c. Basically, it looks like everything assume the source
buffers are in AGP space. I'm guessing that I could just look at the
flags field in the drm_device_dma structure and only set the
MGA_SRCACC_AGP bit if
The recent enforcement of the d_version for kernel modules in FreeBSD on
-CURRENT breaks the drm kernel modules. I've only checked out
mach64-0-0-7-branch so it might be fixed in the other branches.
New to the list, sorry if I missed something.
--
Anish Mistry
pgp0.pgp
Description:
Andreas Stenglein wrote:
here is patch against Mesa CVS HEAD to refactor i830 texcombine
as its done in radeon/r200 driver.
it compiles, but its untested if it works.
feel free to test, modify, commit, drop
progs/demos/texenv produces the same results on my i845GE with this
patch installed or
Ian Romanick wrote:
Log message:
Fixes a bad interaction between the new libGL and drivers built in the
trunk that haven't been converted to the new interface or drivers
built before the driinterface merge (i.e., the ones that ship with
every XFree86 4.x.x release).
Basically,
--- Ian Romanick [EMAIL PROTECTED] wrote:
A 3rd option would be to forge ahead and get DRI drivers building
directly in the Mesa tree. We've been talking about doing this ever
since CVS moved to fd.o. No time like the present, I guess. What we'll
want to do is move some of the files from
The final goal of this code is DRI drivers that can control the hardware without
needing to map either the registers or framebuffer. All direct hardware
interaction will be handled via the DRM device driver.
The code for the proposed IOCTLs is written and tested. They would be added one
at a
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
--- Additional Comments From [EMAIL PROTECTED] 2004-03-13 02:22 ---
Is there 3D
32 matches
Mail list logo
