Well I asked a question on dri-users and Keith said I'd be better asking
here ..
I want to get my OpenGL application to stop flickering on my i815 using a
sync to the vertical refresh, work has apparently started on this for the
radeon and g400, so,
a) does someone intend working on the i810
Well I built the CVS tree head and made the i810 modules and ran my test
opengl program on it and it worked the first time then started spewing
errors ala
(II) I810(0): vgaHWGetIOBase: hwp-IOBase is 0x03d0, hwp-PIOOffset is 0x
pgetbl_ctl: 0x7e40001 pgetbl_err: 0x0
ipeir: 0 iphdr: c2fb
LP
This takes some of the stuff that was recently submitted to the
xfree86.org for the i830 and tries to move the i810 along similiar
lines...
is all cosmetic apart from a new define for the FRONTBUFFER command this
is what they call it in the i815 spec anyways.
I'm submitting the equivalent patch
doh doh!!
wasn't sync'ed properly with the tree (damn firewall!!)...
this diff is a bit better and doesn't remove functionality...
Dave.
Dave Airlie said:
This takes some of the stuff that was recently submitted to the
xfree86.org for the i830 and tries to move the i810 along similiar
Dave Airlie said:
Which application is this?
glxgears from RH4.2 blows it away also!! I might try constucting a brand
new root file system for my development system using the DRI tree, I'm
currently running X etc from the DRI tree in my home directory
(un-installed).
Dave.
--
David Airlie
Well the i830 page flip code is using async flips, the main thing I want
to use page flipping for on my i815 is sync'ed flips so I don't see the
tearing that is so really obvious and gives people headaches.. (don't need
to be getting sued here!!).
It's not the timing I'm worried about it's the
before.
This will make the rendering at least correct, you can then work on the
page flipping as an optimization for full screen.
-Matt
-Original Message-
From: Dave Airlie [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 16, 2002 6:57 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED
Well that's a dodgy application on my part.. it now works sync'd with it ..
How should I do this without changing the kernel i810 module? is there an
way from the OpenGL level to do this that I could propogate down?
Dave.
Dave Airlie said:
Nice one, that gets rid of my tearing - thanks
purposes...) as I'm only doing a single 3d application full screen...
and I'll probably just use that for our purposes here, as I need to keep a
stable tree with minor patches - regulated industry isn't always the best
:-)
Dave.
-Matt
-Original Message-
From: Dave Airlie [mailto:[EMAIL
patches. I guess this 'prolonged' period, is the stickling point for most.
Why not simply have a second CVS repository, where most development
would take place under, while the current repository would be the one
used for (pre-/post-) releases with coarse-grain commits. Like stable
I've just had the misfortune of having my NFSROOT system (lots of network
interrupts), have its card sharing interrupts with the i810 graphics..
once I run anything 3d the kernel oops..
The attached patch contains the quick fix which is to check in thr irq
handler if dev-dev_private is NULL or
I've attached a second patch to
xc/xc/programs/Xserver/hw/xfree86/drivers/i810/i810_dri.c that may also
fix the problem but which I haven't tested,
yeah you can ignore the patch, but the idea is correct I think, the patch
is bogus using variables from places that dont exist :-)...
of course
I've noticed the i830 drivers have a unified memory allocation scheme for
2d and 3d, is there any reason this couldnt be used on the i810?
Is there any major reasons the i830 driver couldn't be usd on the i810
with the functionality it doesn't need turned off?
I'm just wondering the i810/i830
Correct.
The patch looks good.
Do you actually get a speedup from page flipping on the i810? Are there ever
any visual corruptions that you would attribute to the hardware?
I havent got the numbers on my home machine, but I got a definite speedup
on an 800x600 glxgears, and an internal
Do you actually get a speedup from page flipping on the i810? Are there ever
any visual corruptions that you would attribute to the hardware?
I havent got the numbers on my home machine, but I got a definite speedup
on an 800x600 glxgears, and an internal application, I'm going to get
wierd.. I've fixed this, but it built for me fine something wierd with
RING_LOCALS?
Dave.
On Fri, 6 Jun 2003, Dieter [iso-8859-15] Nützel wrote:
i810_dma.c: In function `i810_dma_dispatch_flip':
i810_dma.c:834: parse error before `int'
i810_dma.c:853: `pitch' undeclared (first use in this
But DIR doesn't seem to work with my i810 chipset. I'm attaching my
'dmesg' and 'XFree86.0.log'. Any help would be nice. :)
(logs compressed because of the 40kb limit!)
glxinfo says direct rendering is disabled.
(II) I810(0): [dri] Unable to allocate backbuffer memory. Disabling DRI.
(II)
http://www.skynet.ie/~airlied/patches/dri
i810_mesa.diff
i810_drivers.diff
The only contentious piece I believe is the changes to i810_accel.c that
do the draws to both front and back buffers, but as I know these aren't
good enough to do complete page flipping, so I've no problem not commiting
do the draws to both front and back buffers, but as I know these aren't
good enough to do complete page flipping, so I've no problem not commiting
these if people think they aren't helping anything and just cluttering up
code..
You're already using a shadow type mechanism, right?
He looks to have something here, alright.. the key can be zero, I'm just
updating to trunk at the moment to see if I can reproduce it..
the radeon_dri.c has a similiar issue but it isn't as serious in their
case, they check for freeing the AGP memory if (info-agpMemHandle) they
use the return
and of course
d) revert back to using memory-memory, requires whoever switched us to
key to explain :-)
Okay this was done by David Dawes back in April, and was taken from the
XFree trunk, it looks like it is needed. so one of the other three
approaches is needed...
Dave.
I'd lean towards using ~0 as the error value and keeping the existing
types, etc.
potential patch at:
http://www.skynet.ie/~airlied/patches/dri/i810_drm_agp.diff
I wonder if we should change the drmAgpAlloc function to set the handle to
DRM_AGP_NO_HANDLE?
Other drivers will need some fixin
Yes, that would be cleaner.
patch for not only the i810 but also the fixes for radoen/r128/mga
drivers, along with the changes to xf86drm.[ch] ...
http://www.skynet.ie/~airlied/patches/dri/agp_drm.diff
I think XFree86 tree is going to need something along these lines also,
but I don't have
sent this from wrong address..
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / [EMAIL PROTECTED]
pam_smb / Linux DECstation / Linux VAX / ILUG person
-- Forwarded message --
Date: Wed, 9 Jul 2003 08:56:17 +0100 (IST)
From: Dave Airlie [EMAIL PROTECTED
On Wed, 9 Jul 2003, Keith Whitwell wrote:
if no-one screams I'll apply it tomorrow...
Looks like David has already ported applied it to XFree86.
yeah but I'm hanging on bug 484 to make sure he is correct.. read 484,
David believes there is a drm/driver issue... I'm not 100% convinced it
is
Hi Alan (et dri-devel),
In your -ac1 release you mention that you have a todo to look at the
horribly out of date 2.5 DRM layer,
AFAIK Linus is fairly in sync with the DRI tree on sf.. any recent changes
I've made are in -test1, the 2.4 tree is probably more out of date (the
agp key stuff isn't
2.4-test works for the cards I've got, 2.5 crashes for radeon and seems
to have i810 problems. I've not looked deeply into it yet since with
2.6.0 test I've got other radeon related problems that make X crash
without DRI even.
I think the latest Linus update should fix the i810 issue that
i might be able to get time to move the i810 to texmem soon, firstly as
Keith has let me know, I need to move the i810 to using its own texture
formats (it's still stuck back in the mesa3.4 days)...
so is there a set of comphrensive tests that I can run before and after to
make sure that I
http://www.skynet.ie/~airlied/patches/dri/i810_tex_upload.diff
I used the texenv demos from Mesa 5.0 to test this, I tested it with the
old driver and this one, and they both look the same..
however neither of them show the intensity row like my Nvidia card on my
main desktop .. on the i810 I
I used the texenv demos from Mesa 5.0 to test this, I tested it with the
old driver and this one, and they both look the same..
Have you tried it with anything else? Quake3? Think Tanks demo? Any
of the other Mesa demos?
well I've got a very limited test system, it's NFSrooted of my
this is something to do with double buffering no sure what is going wrong
though, probably getting a doubled buffered visual and using it as single
or somthing...
adding
glutInitDisplayMode(GLUT_RGB | GLUT_DOUBLE );
to the main before CreateWindow
and
glutSwapBuffers();
to the end if
Okay I've updated Matthew's DRM compatibility fix for the top of DRI tree,
http://www.skynet.ie/~airlied/patches/dri/i810_compat.diff
I'll apply it in a couple of days as it seemed to be agreed previously
that it solves the problem..
Dave.
--
David Airlie, Software Engineer
I'm running my own internal application (lots of texturing) and I'm
crashing out in the i810UploadTexImages, trying to upload a level 11
mipmap, but the i810tex.h has MAX_TEXLEVELS set to 10, so of course I'm
corrupting memory earlier when assigning the pointers in i810SetTexImages,
the i830
Can anyone do this test for me? just run the
/usr/X11R6/lib/xscreensaver/glplanet on an i830 or above chipset and tell
me if you can see through the earth, (i.e. it looks transparent)
Either let me know or add it to bug 555 ...
Dave.
--- Additional Comments From [EMAIL PROTECTED]
okay ignore parts of that that cast stuff.. that was some tiredness
sneaking in.. hw_status_page is a void *... I know this now :-)
so just look at the module changes and tell me if they are okay for 2.6..
Dave.
On Fri, 8 Aug 2003, Dave Airlie wrote:
Okay my first patch is up at
http
Okay my first patch is up at
http://www.skynet.ie/~airlied/patches/dri/drm_i810_diff1.diff
This takes any obvious changes from the 2.4.20 kernel and 2.4.20-19.8 I
have on my PC, my only issue is whether this breaks in a 2.6 kernel (I
don't have 2.6 time on my hands yet :-)... is all the module
On Fri, 8 Aug 2003, Michel Dänzer wrote:
BTW, doesn't the solution for the incompatibility discussed in
http://www.geocrawler.com/mail/thread.php3?subject=%5BDri-devel%5D+i810+DRM+compatibility+fixlist=680
work after all?
i can adapt that patch and put it in the dri tree, I wasn't aware of
On Mon, 11 Aug 2003, Brian Paul wrote:
or b) up MAX_TEXLEVELS - but I assume this is hardware limitation, I'll
read my i810 data sheet.. but Keith do you remember?
The ctx-Const.MaxTextureLevels field should be set to the appropriate
value during context initialization in the driver.
okay I'm happy to apply the i810 portion and will do so soon, someone else
want to look after the other pieces or should I do them also?
Dave.
On Thu, 14 Aug 2003, Linus Torvalds wrote:
Ok,
I just did another kernel merge to pick up the i810 compatibility bits,
and decided it is time to
Okay I've applied my piece along with a number of other similiar
whitespace cleanups .. to align with the kernel style ..
Dave.
On Fri, 15 Aug 2003, Dave Airlie wrote:
okay I'm happy to apply the i810 portion and will do so soon, someone else
want to look after the other pieces or should I
In i810_dri.h there is a warning..
/* WARNING: Do not change the SAREA structure without changing the kernel
* as well */
for texmem I want to apply the same patch as..
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/i810/i830_dri.h.diff?r1=1.6r2=1.7
Okay I've gotten around to updating the i810 driver to texmem interface...
http://www.skynet.ie/~airlied/patches/dri/i810_texmem.diff
I've a couple of issues perhaps someone can help with:
1. In texstate.c UpdateTexUnit for most drivers (except i830) the
following appears:
driUpdateTextureLRU(
I recently got from ATI Embedded, an eval kit for the M7 and M9 and these
cards have dual DVI, granted they don't fit in a PC case too well ( one
connector comes out the top of the card :-), but they are only eval boards
for embedded designers..
Dave.
On Mon, 1 Sep 2003, Alex Deucher wrote:
driUpdateTextureLRU( (driTextureObject *) t ); /* XXX: should be locked */
I've taken this approach as well.. but should it be locked? if so how? is
the i830 correct should I try to do something similiar?
Because this function call modifies the global (ie shared memory) LRU, it
should be
If I use a lot of textures my program should still run but run slower? it
shouldn't show white textures.. which is what it does if I lower the
videoram to 16MB, I got this before the texmem change as well if I ran
with a low VideoRam setting ..
Yes, it should just run slower. I'm
Does switching to a VT before suspend and switching back after help any?
Dave.
On Tue, 2 Sep 2003, Robos wrote:
Hi dear developers :)
Thanks a lot for your efforts! Now my (newbie) question:
my i830 dri powered xserver sometimes restarts after suspend-to-ram (loosing
all open windows)
dri.freedesktop.org sound good?
I love the idea of moving to freedesktop.org right now to deal with the
anonymous cvs issue, provide cvsup, and probably a more responsive set
of admins. Is there consensus on this?
I'm all for it, if there's a solution for anonymous CVS.
I'm with
On which server are you doing these commits? From the looks of it,
you're doing them on the SourceForge server. I thought we weren't going
to do that anymore. Is the freedesktop server ready for prime-time
(i.e., does it have the latest CVS ,v files)?
I guess it doesn't matter at the
Okay there is one in my a/c on freedesktop.org with Sep 12 00:20 on it,
but I'm sure it is from the backup server not the primary.. so it is
probably missing 24 hrs of commits.. the history file in CVSROOT is
probably the best place to start...
god knows how long it will be until sf update the
I applied the radeon.h and the Kconfig patches (redone, since whitespace
got mangled in the email). I've posted a more agressive whitespace
cleanup of i810_dma.c. I don't want to commit such a big whitespace
diff without the i810 maintainer's approval.
Hmm. These problems only arise because of the way the merge was done? Why
not just document the right way to do the merge?
I'd agree with Keith the proper way to merge needs documenting, CVS vendor
import is what is needed, the XFree CVS is vendor imported into our DRI
tree, the changes
I've noticed an issue with the i810 chipset that I'm wondering if anyone
can shed light on it..
I've it narrowed down to the fact that the texture upload code never gets
called for my texture, so the card doesn't know what to display, hence it
displays white space.
To repeat - get an i81x (may
I'm trying to valgrind my application and in the process DRI :-),
However I can't get over the Mesa MMX checks, is there any env variable I
can set so Mesa doesn't do all the stuff that requires SIGFPE and I can
force it to use a certain type of instruction set?
I've been just setting
Does the r100 support the rectangle textures extension?
or is the driver borked? I have a CVS from a week or so ago and texrect
seems to now function correctly... is this a chip limitation or driver
bug?
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at
in the i810/5 manual I have, it mentions bit 31 of dword 2 the MAP_INFO
register allows non power of dimensions, and bit 14 of MAP_COORD_SETS is
whether the set is normalized or not ..
does anyone know if this is possible? I've hacked together
NV_texture_rectangle support but it doesn't seem to
Hi all,
I've just implemented output for ffmpeg to opengl using
rectangular ycbcr textures, and the speed is quite good (compared to
non-ycbcr mipmapped textures :-), but now I've
noticed of course I can't use it on the NVIDIA (*evil*) closed source
drivers... (a couple of developers
Well I've traced this a bit, an operation appears to be hanging the
chipset,
Keith, maybe you can tell me, in i830_span.c you no longer have a HW_LOCK
or HW_UNLOCK defined for the i830 has something happened elsewhere that
makes these unnecessary,
what blender seems to be doing is loading up a
the i810 got broken by the texture changes over the last few days, the
imesa-i810Screen pointer wasn't setup before the call to
mesa_create_context and it in turn called i810SetTexFilter which used
IS_I815 which used i810Screen, I've checked in a fix (I've just moved all
the pointer assignments
There is something wrong with the i810 driver at the moment, when I just
run an X server, run anything that exits, when the X server recycles
something is being kept allocated across the recycle and a drmAgpBind
fails on the server coming back up,
however when that fails the clean up calls
btw the i810 bug is triggered by setting VideoRam to a big number (65536
in my case makes it fail on the recycle...)
Dave.
On Mon, 2 Feb 2004, Dave Airlie wrote:
There is something wrong with the i810 driver at the moment, when I just
run an X server, run anything that exits, when the X
I would, but I can't.
Maybe Eric can do it, but I think there should be others with Eric's
access ability so these others can do it too.
I think contacting keithp if Eric is away...
Dave.
Alan.
---
The SF.Net email is sponsored by
can you send me also the i810 line from your dmesg?
dmesg | grep i810 should do it ..
sarg has a fairly old i810 driver, something must have broken since then
..
Dave.
OpenGL renderer string: Mesa DRI I810 20010321
OpenGL version string: 1.2 Mesa 3.4.2
-- Marko Dimiskovski
Just to follwup I can run blender with some artefacts but nothing serious
on
OpenGL renderer string: Mesa DRI I810 20020221
OpenGL version string: 1.2 Mesa 4.0.4
which is XFree 4.3.0 from Fedora Core One, also using the latest DRM
[drm] Initialized i810 1.4.0 20030605 on minor 0: Intel i815 GMCH
Since Keith's tnl_dd_dmatmp.h patches on the 11 Dec last year, the
poor i810 has been seriously fubar, I've just gotten time to look at it
now (well I've been staring at it on and off for weeks with a blank)
The fix is up at
http://freedesktop.org/~airlied/i810_render_fix.diff
I've taken it
Just to follwup I can run blender with some artefacts but nothing serious
on
OpenGL renderer string: Mesa DRI I810 20020221
OpenGL version string: 1.2 Mesa 4.0.4
which is XFree 4.3.0 from Fedora Core One, also using the latest DRM
[drm] Initialized i810 1.4.0 20030605 on minor 0: Intel i815
Can someone run
./manytex -randomsize -mipmap
from the Mesa progs/tests on an i830 or above with the latest DRI and tell
me does it look the same as LIBGL_ALWAYS_INDIRECT=y case?
Some of the textures are corrupting on the i810 and I want to see if it is
just another case where something got
however, when I ran glxgears, I get a libGL error saying it couldn't load
the drm and it was reverting to indirect rendering :/
do you have your board agp module installed? and insmodded? this in't done
automatically since 2.6 kernels .. for Intel you need modprobe intel-agp
somewhere..
This is GL_LINE_LOOP? That makes sense.
Interesting - this should only be a heuristic to choose the fastest path, not
have any correctness value. Correctness should be ensured by
i810_validate_render, from t_dd_dmatmp.h. Can you try find out what's going
wrong with that?
okay I've
I see the code uses LINE_STRIPS to LINE_LOOP but it seems to be
in-correct, well it locks the card, I've no idea if it is correct or not!!
Hi Keith,
To my untrained eye it looks like the test at the start of the
render_line_loop_verts is incorrect, but maybe I am just covering up the
problem,
Hi Keith,
To my untrained eye it looks like the test at the start of the
render_line_loop_verts is incorrect, but maybe I am just covering up the
problem, with this change blender and tri work without my previous
patch... but maybe I'm just moving the issue :-)
patch below..
apologies to
I think I'll give up for today and go at it again later, perhaps the i810
just can't do this in hardware and I need to fallback or perhaps the
number of vertices being output is out by one .. who knows :-)
Okay I found it and checked in the fixes for it, the macro expansion was
catching the
I noticed it came up during the IRC meeting this week about moving the
mach64 up to the top of tree,
So how should this be done in terms of CVS, the mach64 driver as is
insecure, so I'd rather not put into an official tree until those issues
are sorted out, I know Jose has some ideas on these
track him down at some point, but for now I'd like to bring the current
branch up to the top of tree at least,
So should I use the mesa tip and start a new mach64 branch on the DRI tree
or should I make a branch on both trees?
oh yeah I'm unsure who brought it up on IRC so if you are on
tomorrow (I'm GMT+10, should probably use .au a/c :-)
I'll work on the XFree bits and the DRM should be similiar enough soon..
I think it should be fine to go in at Mesa head.
Okay what about the DRI tree bits? DRM and changes to ATI driver?,
should I go with mach64-0-0-7 or should I
Okay everything should be checked in and building, it doesn't work yet
though :-)
I'll hopefully get time over the next few days to hack on it again, I'm in
the middle of moving apartments and work only pay me the odd hack to
i810/radeon stuff, the mach64 is personal (as my laptop has it), if I
Okay I've checked in the DRM and Xserver changes to the above branch, I've
added the PCI ids I think are correct for the chip variations,
I'll hopefully get around to testing it in the next couple of days, (just
have to drag out the laptop :-)
If anyone else has a chance feel free to give
It's great that you are picking this up. It's been on my todo list for a
long while but free time is nonexistant for me these days (full time grad
student + half time research assistant = - half time DRI developer?!)
well a few things came together, I got specs at work for the rage pro that
Okay the last few fixes make tuxracer and glxgears work again, so the new
branch should be as useable as the old one, I think there are still a few
cleanups in the native vertex code (using macros for a few things), and
then a texmem converison might be in order.
But it's good enough for me
While I'm at it (see driinterface-0-0-3-branch mails) I could update the
snapshot scripts to build mach64-0-0-7-branch snapshots.
please do it, I'm sure a bit more testing would help a lot ...
Thanks,
Dave.
Dave.
Felix
---
So should we just work on getting everything running on newtree then and not
worry about the security issues for now?
Sounds good to me, I'll look into disabling DMA by default, if we have the
option we are okay, my only issue is though should there be something in
the DRM that it affects? I
Okay I wasn't as complete as I thought, the Mesa and the DRM I was using
were from the branch but I never updated my 2d driver, it was still the
old branch... so then I noticed something else which might cause problems
with the snapshots
When I updated and using the XFree86 from the snapshot
When I updated and using the XFree86 from the snapshot directory, I was
missing an I2C symbol, the ati driver in DRI CVS seems to need a newer
version of libi2c.a, mine was from Fedora Core 1...
The 2d driver builds now but 3d seems to crap it out .. it'll be a day or
two until I figure it
-X starts up fine now, window manager comes up, etc.
-xvinfo reports xv working, playing mpeg with mplayer confirms this.
-glxinfo reports correct info
-glxgears locks up. Rest of X is locked, but mouse can be moved around. I
can ssh in, but can't seem to kill the X server. A reboot is
As for the glxgears thing, I got some output from it when I ran it with gdb
from an ssh session:
glxgears: vblank.c:338: driWaitForVBlank: Assertion `interval != (unsigned)-1'
failed.
try updating from CVS both trees, I fixed this I just can't remember which
tree it went into :-) I think
I added daenzer's package repository to my sources.list
( http://people.debian.org/~daenzer/dri-mach64-unstable/ ) and installed
the mach64 patched packages to enable DRI support and XV.
The drm-modules didn't compile (due i think to 2.6 kernel), so i patched
it again with John Flinchbaugh's
What is the status of mach64 dri support on freebsd 5.2 ?
nobody has tested it for a while, so I say it suffers from bitrot...
mach64-0-0-7 is the DRI branch to go with, and Mesa head, the code should
all be there, just needing some updates for FreeBSD 5.2,
I'll look into it over the next
Thank you! It dies in xc/programs/Xserver/GL/mesa/X/xf86glx.c :
xf86glx.c: In function `__MESA_setVisualConfigs':
xf86glx.c:481: error: `kernel8' undeclared (first use in this function)
xf86glx.c:481: error: (Each undeclared identifier is reported only once
xf86glx.c:481: error: for each
I was building mach64 drm for 2.6.3. I had the worst time convincing
Makefile.linux and inturn Makefile.kernel that it was not lessthan25 and
lessthan2552. I finaly gave up once I saw I had to gointo all the .h and
.c files and add #defines there as well. Also I don't have a mach64 pro
Hi,
I've just tried getting a solo Mesa working on 2.4.25, latest DRM
from DRI CVS and top of tree Mesa on r100,
my framebuffer console comes up, but when I start the server the screen is
corrupted, when I run the test app I can see the garbage on screen change
so it looks close to
Hi,
I've just tried getting a solo Mesa working on 2.4.25, latest DRM
from DRI CVS and top of tree Mesa on r100,
I got it working on 2.6.3 in the end, there must be some issue with the fb
in 2.4.25 or something .. I'll start looking into it soon..
Dave.
--
David Airlie, Software
Send your cards PCI ids to the list,
Mike what card have you the DRM shouldn't load for any card that doesn't
have the triangle engine really..
Dave.
On Thu, 11 Mar 2004, Mike Mestnik wrote:
At first I thought it just might have been my system. In debuging the
problem I found ought that my
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
-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
--- Dave Airlie [EMAIL PROTECTED] wrote:
Send your cards PCI ids to the list,
Mike what card have you the DRM shouldn't load for any card that doesn't
have the triangle engine really..
Dave.
On Thu
The current miniglx fakes up some DDX version numbers but these only work
for the radeon drivers, (4.0) is used, but the i810 drivers is only on
version 1.0,
Is there any need for this to be checked at all should the _SOLO defines
in utils.c:driCheckDriDdxDrmVersions be extended to cover the DDX
I've fixed up the mach64-0-0-7-branch it should build and run again..
haven't tested it yet, no enough disk space on my laptop.. tomorrow
hopefully..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG
This was installed from a snapshot. Snapshots up to March 2 worked,
anything after that did not have working direct rendering. But since the
snaps are generated from the head... I've seen this error posted here
before but I haven't seen a resolution, maybe I missed it.
Ian, does this
I've checked in the changes for the mach64 to use the new interface, I
haven't turned it on as I had to change some stuff I'm unsure off...
I've had to set
modes-drawableType = GLX_WINDOW_BIT | GLX_PIXMAP_BIT;
the r200 just had the GLX_WINDOW_BIT ..
Apart from that, 24-bit needs looking at..
anything after that did not have working direct rendering. But since the
snaps are generated from the head... I've seen this error posted here
before but I haven't seen a resolution, maybe I missed it.
Ian, does this look at all like it could be related to your libGL, etc.
changes?
yup
I've thrown together a really simple script to make the DRM tree into a
Linux kernel type setup..
its in the DRM tree under scripts/create_lk_drm.sh
usage is from the top of of the DRM and you provide the output dir and
either 2.4 or 2.6 to produce the correct type of tree..
I'm sure there are
Hi,
The patch you've been carrying for a while has a number of bogons,
like duplicating pci.ids inside the radeon driver for no good reason.
Davej can you expand on this a bit, Linus was involved in the discussion
on this way back when..
thread at:
1 - 100 of 1423 matches
Mail list logo
