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 suppo
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 time.
--- 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
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, FillInV
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 us
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: signat
> 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 bi
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
in
--- 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
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?
I
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
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
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
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> 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
> >
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 ca
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
w
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
This patch plus the changes I just checked into Mesa make it build again.
The patch just copies the DRM changes into the DRI tree and then adjusts a bunch
of includes to make it build.
Let me know it if it is ok and I can check it into the DRI tree.
=
Jon Smirl
[EMAIL PROTECTED]
___
I have DRI building again locally. I need a little while longer to make a decent
patch. I copied my DRM changes into the DRI copy and then touched up the DRI
source. It's taking a while because a bunch of DRM defines are repeated inside
the 2D drivers.
Again, I am sorry for doing breaking DRI. I w
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
Jon Smirl wrote:
Sorry I broke the DRI build, now I see what the problem is. When the Mesa is
included in the DRI tree is it is using the DRM driver in the DRI tree. I didn't
know that the DRI build would alter the Mesa include paths.
Ugh. In the future, if people are going to do something that
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 Tut
--- 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 morp
Sorry I broke the DRI build, now I see what the problem is. When the Mesa is
included in the DRI tree is it is using the DRM driver in the DRI tree. I didn't
know that the DRI build would alter the Mesa include paths.
So there are two choices:
1) Copy my changes from Mesa back into the DRI tree.
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 pulls
--- 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 says"SiS 305 AGP 2X
It doesn't build Jon, because drm.h is being pulled from the shared
directory in the DRI tree first and not the Mesa tree.
Alan.
On Fri, Mar 12, 2004 at 09:01:25AM -0800, Jon Smirl wrote:
> I just pulled a clean tree and it built without problems.
>
> --- Dieter Nützel <[EMAIL PROTECTED]> wrote:
On Fri, 2004-03-12 at 12:57, Keith Whitwell wrote:
> Michel DÃnzer 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
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: n
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:
>
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
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) R
I don't know, if it loads or not, I stoped trying when I found ought that
only Rage pro was supported. However the 2d driver workes fine.
01:00.0 Class 0300: 1002:4c4d (rev 64)
01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M
AGP 2x (rev 64) (prog-if 00 [VGA])
Sub
I initially just proposed a copy in the Mesa tree. I didn't get any responses
for two days so I added it. That was just a first pass at removing redundant
defines, there are more I haven't got to yet.
I also have a lot more code that isn't checked in yet. It's all based on
parallel changes that I
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
--
--- 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
> >
>
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
Michel DÃnzer 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 do
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 part
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 use
> 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?
mac
41 matches
Mail list logo