Is anyone against just including mach64 in the trunk? I know it' still
unsecure and unstable, but so is savage and that's in the trunk. We
don't have to build it by default. plus it would avoid having to
update the makefiles on the branch everytime mesa changes and the trunk
gets
Hi all,
I've gotten all the patches that have gone into 2.6 into the DRM
module except one,
there is a patch in 2.6 to add sysfs support to the DRM, it is at
http://dri.freedesktop.org/~airlied/drm-2.6.diff
It is a bit intrusive and I can't see an easy way to wrap it ...
How have we
It is a bit intrusive and I can't see an easy way to wrap it ...
How have we dealt with these sorta major ones before? and at what point
should we just branch the DRM so 2.4 and 2.6 are separate tracks? (I might
start another e-mail in a minute...)
Okay I talked with Michael Danzer on IRC
Second:
What about this ksymoops?
I could catch it for the first time when the system hangs after running UT2003
only some FEW seconds.
hmm .. might be a pre-emption issue in the drivers somewhere, try it with
pre-empt turned of .. or maybe just UP and see if it still happens..
Dave.
BTW, I'm going to start working on the DRM driver soon. I'm not sure
where to make my changes, in the xc module or in the new drm module. Has
the transition been formally completed? I havn't heard anything definite
yet. But apperently some people are already committing stuff in the new
Hi all,
In a first attempt to bring the DRM in 2.6 in line with the latest
developments in DRM CVS, I'm going to try and split the latest DRM stuff
up into patches and submit them,
I've setup a temporary BK repo at http://freedesktop.org:1234/drm-2.6/
and it contains a first changeset to
I've setup a temporary BK repo at http://freedesktop.org:1234/drm-2.6/
Yes, that works. Anything which you put into that bk tree will
automagically appear in my test kernels. When we're happy with it you can
ask Linus to merge it into the top-level tree.
Okay I've pushed all the first
I'd say let it be checked out in Andrews tree for a while and then I'll
ask Andrew to push it all onto Linus...
I'm finished mostly, all major difference between the DRM CVS and 2.6 are
in the bk tree http://freedesktop.org:1234/drm-2.6, I'll move it onto
bkbits when it arrives back on the
Thanks again for your work on this Dave.
BTW, what's your (and everyone's, for that matter) opinion on
video-reset and the libsysfs copy being in the drm module? I still don't
see the point of the former being there, much less the latter.
I think libsysfs should be killed out of the drm
While working on the DRM merge, I picked up on a tool called cvsmonitor,
I have it running on my skynet a/c at:
http://www.skynet.ie/~airlied/cgi-bin/cvsmonitor/cvsmonitor.pl
and have imported the DRM module into it from fd.o, it gives very good
changeset information and was invaluable compared
3) It implements the normal Linux mechanism for associating a device driver with
the hardware; that's what caused the changes in the PCI ID tables. If it
discovers that an FB driver is already loaded it stops probing and reverts to
the old scheme.
My main worry is that this stuff break BSD
Hi,
I've a Radeon M7 running at 800x600-32bit, and have built solo and
X/DRI drivers out of the same tree, when I run the manytex (one from
miniglx and other from tests) under X/DRI the screen is rock solid and
manytex runs, however under solo, I get some odd flicker across the top
60
Has anyone any ideas what could be causing this? I've got the RRG for the
M7 here but its pure needle in a haystack stuff :-)\
just noticed the solo drivers have pageflipping on by default, we probably
need some way to pass options to the server from miniglx.conf like an
options=x=y,a=b line
As Alan pointed out on IRC, it won't. But providing the means to do it
cleanly is certainly good basically. The question is exactly where it
belongs. I suggested to do this work on a branch for the time being, and
got zero feedback. I don't know what that's supposed to mean; some
people
I had a good fix for this in one of my patches. Only BSD needs the names
but both need the IDs and linux even had a hotplug struct. This was geard
and enginered with both OSes being treated as eaquils and other OSes made
easy to acommidate. What I did was had some macroes that took
My problem with your changes is that I really don't know how to evaluate them.
Secondly, there seem to be people who know what they're talking about who have
real objections to some of them.
I think Keith has put it the best, most of my concerns about this work are
that it is maybe before its
On Thu, 15 Apr 2004, Nathanael Nerode wrote:
This is a diff for drivers/char/drm to make r128 use userland-loadable
firmware. It's completely untested (since I don't *have* an r128, I don't
see any way to test it), but I bet it'll work; the firmware loading interface
seems remarkably easy to
AFAIK X.org also imported 4.3.99.902 for their version (at least the release
notes indicates that 4.3.99.902 was merged unconditionally,
http://freedesktop.org/cgi-bin/viewcvs.cgi/xc/RELNOTES?root=xorg), so if
indeed some files would be covered under the new license even for this version
The infamous CP microcode is needed. AFAIK, Benjamin Herrenschmidt got
it from ATI.
the BeOS driver has some r300 microcode in its sources...
http://www.bebits.com/appver/2938
download the r5 source at look at CPMicroCode.h in the file...
no idea what it is of course it might be 2d only or
Okay I've come up with a method for generating the pci ids stuff for the
DRM for Linux and BSD,
put a txt file in shared or the format
[cardname]
vendid devid namestring
have two scripts in the scripts directory ones to create a linux
drm_pciids.h file of the format
#define cardname_PCI_IDS \
These PCI changes duplicate things that are in framebuffer. Shouldn't we be
having a giant argument about them? I would think that is worse that DRM is is
duplicating something in FB. The two IOCTLs I needed for reset don't exist in
either FB or DRM. Anyway I think these changes need to go
already loaded and has the PCI ID registered.
You want to use the kernel probe scheme first. If the kernel probe suceeds
it
will mark the hardware in use. The fallback scheme is a trick to use the
hardware without informing the kernel.
yes but it is also the current behaviour
The patch looks good. However, doesn't drm_pci_id_list need to be updated for
BSD to add the 2 new fields? Other than that, it looks good to me.
nope that's why there are two scripts, the bsd generates the info bsd
wants, the linux one generates the info linux wants..
so Linux no longer
You could still generate a string to help with debug. Something like Radeon QX
by converting the PCI ID to ASCII. Later when you get the family you could
generate Radeon R250 QX for the string.
well if someone builds their kernel with pci strings turned off I persume
they know what they are
In the Linux kernel there is a drm for the Sun Creator3D card this card is
in no way related to PCI/AGP .. I've no idea how all the changes we are
making to the DRM affect this type of card...
I'll import the ffb files into our tree just for completeness but we can't
build it it only works on
Ick, you can't use int as an ioctl structure member, sorry. Please
use the proper __u16 or __u32 value instead.
I just looked at drm.h and nearly all the ioctls use int, this file is
included in user-space applications also at the moment, I'm worried
changing all ints to __u32 will break some
care to comment?
Is this a case where somebody is *really* including kernel headers in userspace
and we need to smack them, or are they using a copy that's been sanitized
(and possibly fixed)?
hmm drm.h is used by all drm users and it hasn't really been sanitised..
we probably do need to
is the installed 64-bit user base small enough that we can make them take one
for the team, so to speak?
yeah I'm getting the feeling a flag day may be necessary
---
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up
Or is the installed 64-bit user base small enough that we
can make them take one for the team, so to speak?
With cheap 64-bit processors coming out from AMD and
Intel the base is growing faster than ever, so better
get on with it yesterday :)
--j
with that in mind I'll
The new PCI probing code seems to break the mach64 driver, it looks like
the pci_alloc_consistent is returning a different buffer when the driver
uses the new probing scheme, this is messy to debug for me until I get
another machine I can connect to my laptop to debug it...
If i make the system
although I'm sure debian are correct, I don't think this change is
appropriate for a stable release, it adds extra user space requirements..
so I won't be applying it in its current form, I might try firmware
loading and fall back to using the in-built microcode, it won't satisfy
Debian but
It looks good to me.
Dave.
confirmation of the patch before I apply it. (I applied the other three).
Can someone take a look at this?
In the future DRI-related patches should probably be sent to the dri-devel
list.
-Brian
Tilman Sauerbeck wrote:
Hi,
the attached patch fixes a
cvs -d:pserver:[EMAIL PROTECTED]:/cvs/mesa co -D 2004-03-28 Mesa
Besides that one bit it should build fine.
/me pokes the mach64 maintainers. ISTR some discussion about merging mach64
anyway, even though it's insecure, perhaps with Big Fat Warning Signs or
defaulting to mmio mode (which is
I've fixed this and checked in, the .S files needed special lines in the
Imakefile for radeon/r200
Dave.
On Tue, 27 Apr 2004, Dieter Nützel wrote:
Or xf86drm.c buf free changes?
Sorry, no more time for testing, tonight.
-Dieter
---
In Keiths bunch of changes to make the drivers build in Mesa tree he
changed the i810_dri .h from using drm_+clip_rect_t to XF86DRIClipRectRec,
this break solo, if I change it back it'll probably break dri target...
which is correct?
Dave.
--
David Airlie, Software Engineer
Hi all,
please review:
http://freedesktop.org/~airlied/drm_pci_mods.diff
This patch starts importing some of Jon Smirls work to the DRM tree, it is
2.6 only at the moment, I'll fix 2.4 for checkin...
It makes the DRM use the Linux PCI code, and is a first step on the way to
hotplug support...
1) drm_probe can fail. Should it check for errors before setting fb_loaded=1?
not sure, the fb is still loaded whether the probe fails or not .. some
other driver exists on that device..
2) Does this work? DRM(fb_loaded=1); or should it be DRM(fb_loaded)=1?
it works but is also a typo :-)
I've thought of another way to do this I think, will re-generate patch
later, btw you may not know this put if you use pci_get_device, and it
finds a device, you have to use pci_dev_put on it if you don't want it ..
I'll do a bit of re-writing and re-submit..
okay next revision of the patch
why do I get the impression we are discussing kgi or at least the goals of
kgi? without mentioning it ..is kgi a bad word around these parts? :-)
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
I finally got to look at this patch, the patch puts the options in
atioption.c in a different order than in atioption.h
this stops tv out from working properly with the previous patch, there is
an updated patch at
http://freedesktop.org/~airlied/mach64-tvout-070504.diff
it still doesn't look
I only find pci_get_subsys, one time in drm/linux/drm_drv.h !
okay I've checked in some fixes (untested) for 2.4 compat now ..
Dave.
best regards,
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
But when I do glxinfo it reports the software driver:
OpenGL renderer string: Mesa GLX Indirect
aet LIBGL_DEBUG to all and see if it prints anything..
Dave.
Or did someone fix the software render? I used to get about 3FPS with it.
Maybe something is broken in the DRI into xorg server
Hi,
I've just gotten an i865 system are there any docs out there for
programming the 3d end of this? Intels site for that chipset has no
programmers reference beyond the datasheet which doesn't say muc about 3D
stuff..
Are these docs available non-NDA?
Dave.
--
David Airlie, Software
It has been pointed out to me by Andrew and Fernando Pablo Lopez-Lezcano
that we do a lot of sleeping in code that probably should reschedule
rather than sleep,radeon_do_wait_for_idle being a prime example, this has
a DRM_UDELAY(1), this messes up audio latencys,
Now I'm not sure that wholesale
Doesn't this work with the i830 driver? AFAIK i830 and i845G both use the same
graphic core (intel extreme graphics). i855G/i852G/i865G use intel extreme
graphics 2, which afaik is exactly the same, except it's clocked slightly
higher (266Mhz vs. 200Mhz). At least some people have docs...
The attached patch provides s3tc (and broken fxt) texture compression
support on the i8xx (x30) chipsets,
You need to apply the radeon/r200 patch from Roland first, Roland do you
want to merge this patch into yours?
So far I've tested this with texcmp - thats how I know FXT doesn't work,
do we
This only happens with 2.6 kernels. Prior do the lockup, everything
works (I can see it through ssh), but the display gets blank, and never
comes back.
doesn't happen for me,
00:02.0 VGA compatible controller: Intel Corp. 82865G Integrated Graphics
Device (rev 02)
[drm] Initialized
Hmm... CVS HEAD advertises 20021108:
http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/drm/linux/i830.h?rev=1.13view=
auto Look for #define DRIVER_DATE.
Yes, the driver in the freedesktop.org tree is *ancient*. That's why he said
to try an updated driver from dri.sf.net. :)
not sure if
I have one question though, how is RGB_DXT1 and RGBA_DXT1 going to work?
As far as I can see, there's no difference at all between these two
formats as far as the driver is concerned, which can't be correct
(pixels which need to get decompressed as black, fully opaque for
RGB_DXT1 need to be
I haven't followed DRI closely, so this may be a FAQ or just a stupid
question, but why is the DRI module in the 2.6.6 kernel almost two years old?
there are 3 components to a 3d driver, DRM, DRI and DDX :-),
DRM - lives in kernel - the i830 DRM hasn't needed any major changes in
the two
Suse 9.0).
I tested a texture and a long anti-aliased line strip.
This is both with r100 and r200.
I don't think DRI has become slower since that older version, so I haven't
tested X with a recent DRI. I think the problem must be in the adaptations
made for mesa solo.
Any opinions on
The idea is to reduce the kernel mod to nothing more then device
enumeration and detection.
However you solve it.. I don't care about how the kernel driver --
userspace driver interface is defined or implemented. I just don't think
there should be one interface for all devices, as it is
The final file shuffling step will be to make the DRI tree and the Mesa tree
use the libdrm.a build in the drm module. Right now we have *3* copies of the
same code. There is a copy in each of: drm/libdrm, xc/xc/lib/GL/dri/drm, and
src/mesa/drivers/dri/dri_client. That's just nuts (but I
should I be able to using FC2, set LIBGL_DRIVERS_PATH to my Mesa built
drivers and have it work, or is that interface not one that stays stable?
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -150064480 (LWP 4593)]
0x007f189e in memset () from /lib/tls/libc.so.6
(gdb)
I thought this was a trivial change there is a bit of cut and pasting to
do, it'll have to wait until this evening when I can test it..
Dave.
On Mon, 31 May 2004, Felix Kühling wrote:
After the build problem in i8x0 was fixed two more snapshot builds
failed. Looks like mach64 has the same
After the build problem in i8x0 was fixed two more snapshot builds
failed. Looks like mach64 has the same problem. Does someone has a hand
free to fix it?
Okay I've just checked in a load of untested fixes for the mach64 so it
builds.. I'll build it at home and test it later..
Dave.
Hi Eric,
you commited some changes to the DRM in a merge from FreeBSD-current, you
made changes to the SIS driver that look like they will break 64-bit Linux
systems, although we intend doing this, I would prefer to have it all
together in one place ..
I'm also not convinced the changes are
BUT nothing uses it. Since it's broken, I'd like to remove all traces of it
(from both user mode and kernel mode). Is there any reason not to? If we
need that functionality later, we can design a better interface for it that
will less fragile.
The DDX in Xorg should work fine with the DRI modules assuming they
applied the patches. If not then Mike Harris has the right driver
bits in the current Fedora 1 XFree86 4.3.x tree. I've not had time to
finish up the 2.6/Xorg porting (real world got in the way) but plan to
do so at some
in DRM(agp_acquire) should be removed altogether in a 2.6 kernel
because its vmap() takes 4 arguments; however, only the guards seem to
have been removed, which causes this function to erroneously fail if
the AGP aperture can't be directly accessed by the CPU.
Looks like. Removing it
I've fixed the FXT support but DXT1 RGB is still knackered and probably
won't be fixed...
http://www.skynet.ie/~airlied/patches/dri/i830_texcmp.diff
Roland can you update your patch with this verson?
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at
I have a big problem, because the compilation of the mach64 module runs into
some errors.
Here is the output of make using this command: make
LINUXDIR=/usr/src/kernel-source-2.6.6 DRM_MODULES=mach64 2 error.log
have you actually build the kernel? it you built the kernel using
I've changed it to include /usr/include/endian.h rather than Xarch, it
should work... but I can't test it until I get back to my laptop...
Dave.
On Sun, 6 Jun 2004, Jon Smirl wrote:
The mach64 driver includes Xarch.h. In the mesa-solo model it can't do this
since there is no X around. Is
I'm afraid that's glibc specific.
If I use sys/endian.h on FreeBSD can I do the same thing?
it'll look messy but to avoid the X includes we should do it ..
#ifdef __linux__
#include endian.h
#else
#include sys/endian.h
#define __BYTE_ORDER BYTE_ORDER
#define __LITTLE_ENDIAN LITTLE_ENDIAN
Can you fix the 500 compiler warnings while you're in there?
I actually have the fixes for all those warnings in a tree already,
however they defo require testing as they are to do with building the
vertex info for sending to the card..
Dave.
--- Dave Airlie [EMAIL PROTECTED] wrote
but with the current DRM interface =1.1 the devname is not being
set in DRM(set_busid).
Attached is patch to fix.
thanks applied to CVS, I'll push to bitkeeper for Linus inclusion later..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
In glheader.h there is a check to set MESA_BIG_ENDIAN vs
MESA_LITTLE_ENDIAN
it has a line /* fix me for non-Linux big-endian! */
Has anyone ever checked Mesa on BSD on big-endian?
I'm going to use this macro in the mach64, and I'll let someone fix this
include..
Dave.
--
David Airlie,
test at the end won't do the _tnl_install_attrs because v0 is the same
as it was before, even though the tnl code would have changed to emit
the specular instead of the pad.
Huh... Well spotted. One possibility is to record the old value of 'index'
and use that in addition to the two
This file is pretty much a copy of tnl_dd/t_dd_vbtmp.h with what looks
like some experimental MACH64_PREMULT_TEXCOORDS code I think,
Is this experiment finished? the code isn't use as mach64 has a native
vertex format code.. that is still faster..
Could t_vertex be used for the native vertex
That's ugly, and probably unnecessary. I'll take a look.
they should be all gone .. I fixed and actually tested for once the other
night..
Dave.
- ajax
---
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC:
I'll fix this in the DRM bk tree and push to Linus...
Dave.
On Thu, 10 Jun 2004 [EMAIL PROTECTED] wrote:
On Wed, Jun 09, 2004 at 03:53:40PM -0700, Robert T. Johnson wrote:
gamma_dma_priority and gamma_dma_send_buffers both deref d-send_indices
and/or d-send_sizes. When these functions
gamma_dma_priority and gamma_dma_send_buffers both deref d-send_indices
and/or d-send_sizes. When these functions are called from gamma_dma,
these pointers are user pointers and are thus not safe to deref. This patch
copies over the pointers inside gamma_dma_priority and
Okay I've checked in the FXT1 portions of my i830 patch, and placed an
updated DXtn patch at
http://www.skynet.ie/~airlied/patches/dri/i830_texcmp.diff
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG
When I run nwn with the i830 advertising GL_EXT_texture_compression_s3tc,
either by making the lib available or forcing the option in drirc, I get a
wierd lighting interaction..
http://www.skynet.ie/~airlied/dri/screen/NWNa.jpg
vs with s3tc off.
Oh yes, and it wouldn't be outside the realms of possibility to consider
supporting the i810 in this driver as well, though that might take a little
bit of hammering on stuff.
I might get time to take the hammer out in a few weeks, one i810 board is
running DOS, the other has a radeon in
I first tried installing the binaries from the dri project, but when I tried
to restart X I got error messages saying it couldn't open the virtual console.
So I uninstalled, got the dri/drm/mesa sources and built/installed. X starts
fine, and DRI is now a listed extension. glxinfo runs.
radeon/r200 have some 32 Byte alignment restrictions for all textures), though
I just noticed a small error in the patch:
+ case MESA_FORMAT_RGB_DXT1:
+ t-texelBytes = 2;
+ textureFormat = (MAPSURF_COMPRESSED | MT_COMPRESS_DXT1);
+ break;
+ case MESA_FORMAT_RGBA_DXT1:
+
So? My sister still uses a P120, and is happy with it. Why should she be
forced to upgrade?
I think that is a bit petty really, please try and keep this
discussion some way in the bounds of logic, at some point you have to
throw away older systems, X works on these systems now, we want to
texcmp isn't working for me but I can't see what is wrong on my machine,
something may have broken it recently...
it no longer for me prints the extra info ..
can someone test it on a radeon?
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb
the code that works out the offsets and stuff is bogus for the i830
with compressed textures... I've no idea what it should look like really
:-) the intel hardware stores things differently than other things, and
relies on the pitch and stuff.. I've no docs (and the NDA my company is
under
On my i830 I'm getting libGL visuals errors for 4 visuals and they are all
for visuals with 0 depth bits...
I've applied the following to my i830_screen.c
@@ -474,7 +475,7 @@
int depth_buffer_modes[2][2];
- depth_buffer_modes[0][0] = depth_bits;
+ depth_buffer_modes[0][0] = 0;
Hi all,
I'm not sure anyone has noticed this but I believe a fair few Imakefiles
in the XFree86 tree recently sprouted XFree86 licenses... a lot of ones
from the DRI project or from the PI days...
Now I'm not copyright holder on any of these files, but I also believe the
XFree86 project is not
If you're going to poke around much in that part of the driver, you might
consider converting it to use driFillInModes instead of the driver-specific
fill_in_modes function. :)
I've just checked in the fix for my issue and a conversion to use
driFillInModes..
Dave.
Okay finally after using a pen and paper to draw some pictures I've gotten
compressed textures to work with Neverwinter nights!!
http://www.skynet.ie/~airlied/patches/dri/i830_texcmp.diff
Now I can get back to playing it :-)
It also proves you probably don't need the docs most of the time,
If I don't use gcc -O2 flag to compile dri driver,quake3 can run smoothly.
But when I enable -O2 flag,the driver is broke.
Quake3 always displays the last frame of the last q3 startup until the menu
comes up.
also details of graphics card, source tree you are building from ..
Dave.
I've get that for r200 too. Seems to be related to the t_vertex.c codegen
addition. Maybe t_vertex_c.o doesn't get linked in?
Yes, it's my fault. I can't wait until we can stop trying to track Mesa
directly from DRI cvs.
I'll commit the fixes once I've rebuilt a DRI tree.
not sure
On Thu, 8 Jul 2004, Bill Gou wrote:
Hi there,
I'm running X.org 6.7, kernel 2.4.24. Whenever I load the i830 module compiled from
dri
snapshot, I get a kernel oops. Below is the ksymoops and 'lspci -v'output.
that's interesting, looks like something wierd with the two PCI devices
being
On Thu, 8 Jul 2004, Bill Gou wrote:
Hi there,
I'm running X.org 6.7, kernel 2.4.24. Whenever I load the i830 module compiled from
dri
snapshot, I get a kernel oops. Below is the ksymoops and 'lspci -v'output.
I can see the issue, I just have to think of a clean way to fix it ...
I've
About 15 people sent me e-mail with that link. :) The one thing I didn't see
was how to put that note in a library. Is there some special section
attributes in the source or is there some linker magic?
Take a look at the .S file that is linked from
http://tardis.csn.ul.ie/283
something
Can you load the original i830 module from 2.4.24? and let me know if
direct rendering gets enabled, (send the Xorg.0.log ...) I'm try to narrow
down if this is totally the drm's fault :-)
Dave.
[drm] Initialized i830 1.3.2 20021108 on minor 0: Intel Corp. 82852/855GM Integrated
Graphics
First I built the i830 module from 2.4.24. Then I tried to unload the
current module which was built from dri cvs, the kernel gave me an oops.
See attachment for the decoded oops.
okay there is something wrong with the unload but I can't see it straight
away, can you insmod the i830 from the
[drm:i830_ctxbitmap_init] drm_ctxbitmap_init : 0
[drm] Initialized i830 1.3.2 20021108 on minor 1: Intel Corp. 82852/855GM Integrated
Graphics Device (#2)
[drm:drm_cleanup]
[drm:i830_takedown]
[drm:i830_stub_unregister] 0
inter_module_unregister: no entry for 'drm'kernel BUG at
Is the i830 driver considered to be dead, should any future work go
towards the i915 one?
just like to get a semi-official idea? if so we need to import the up to
date DDX into the DRI tree and start releasing the snapshots for the i915
driver..
I'm bringing over some fixes for the i915 from
the second device..
Dave.
On Thu, 15 Jul 2004, Bill Gou wrote:
Dave Airlie wrote:
I've checked in a fix for this load/unload it probably won't help your
main situation yet but I'd appreciate if you could check it the module
load and unload, if that works I'll try and fix your specific problem
I know we spoke of this before and a big bunch of these just appeared in
the mainline tree and I want to merge them back into CVS...
For now my thinking is BSD doesn't use __user so we just go ahead and use
it and if later it stars being used for something else on another platform
we can
The module couldn't be unloaded. I tried to unload it right after loading, rmmod
complains
i830: Device or resource busy. lsmod shows:
Module Size Used byTainted: PF
i830 66620 1
jeez this is annoying me :-), there was a bug with my ++ and --
again please, found another error in the logic, this is like programming
by numbers!!! thanks be to God you found these issues before I submitted
this for the kernel :-)
Still the same. This is the debug msg:
[drm] Debug messages ON
[drm:drm_probe]
[drm:i830_stub_register]
also as far as I know the unichrome driver is in-secure it suffers I think
the same issues as the savage and mach64 with its DDX setting up in-secure
buffers...
have a look at
http://dri.sourceforge.net/IRC-logs/20040628.txt
if this is so I recommend the via stuff goes in under devel for now ..
The intricacies of inter module registration were not at first apparant..
the latest fix only does an inter module get/put for the first device in
each driver...
let me know how this one gets on ..
Dave.
Still can't unload it. It seems the problem is that the kernel thought the driver is
I've just checked in the basics of the i915 DRM for FreeBSD but nothing
happens... I'm running FreeBSD 5.2.1,
After I kldload i915.ko I see nothing in the dmesg... am I missing
something? or as the AGP driver stolen the card?
Regards,
Dave.
--
David Airlie, Software Engineer
101 - 200 of 1423 matches
Mail list logo
