>
> Does anbody know why drm is using vmalloc_32 instead of vmalloc when
> allocating SHM maps?
I may be wrong but maybe for mixed 64/32-bit kernel/userspace systems, did
it ever use vmalloc?
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux k
> static int i830_map_buffer(drm_buf_t * buf, struct file *filp)
> {
> drm_file_t *priv = filp->private_data;
> drm_device_t *dev = priv->head->dev;
> drm_i830_buf_priv_t *buf_priv = buf->dev_private;
> drm_i830_private_t *dev_priv = dev->dev_private;
> const struct f
Hi,
I'd like to upstream the mach64 drm at some point, I believe the command
stream is now secure from having the client change it after submission,
however I'm not sure we are actually check the blit's are legal and not
doing anything...
I'll have to dig the datasheets out I suppose and have
> I was looking at the various options in the radeon man page and came
> across the BusType option. I had tried both leaving that option out,
> and setting the option to "PCIE". This morning, I decided to try
> setting it to "PCI" though, according to the man page, "PCIE" simply
> falls back to
: fd62459b11c39a58e5b45b8af30a8217d5ce0e1b libdrm-2.3.0.tar.gz
http://dri.freedesktop.org/libdrm/libdrm-2.3.0.tar.bz2
MD5: 01a1e1ee0268a2403db42fa630036ab2 libdrm-2.3.0.tar.bz2
SHA1: af2e8d6e3ad6b906b4d6f1b2ada2d523188c28ea libdrm-2.3.0.tar.bz2
Dave Airlie:
libdrm: add support for server side
Does the DRM git tree work would also be interesting,...
I haven't merged up Michel's drawable/blank changes for 2.6.19 as they
were much too new for it, but do we have a backwards compat issue perhaps
or something similiar?
Dave.
On Wed, 18 Oct 2006, Keith Whitwell wrote:
> This is all a li
>> Is there anything I can do to give further debug info?
>
> strace the ioctl that your app is calling... see what it returns, see why
> it returns twice...
Do you use intelfb (just as an aside...)?
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
L
>>> I thought I made it pick only one of the pipes. Did I mess up?
>>
>> Your code looks fine to me, not sure how it ends up with both enabled...
>
> Is there anything I can do to give further debug info?
strace the ioctl that your app is calling... see what it returns, see why
it returns twice..
On 9/22/06, Ryan Richter <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 21, 2006 at 11:54:01PM -0500, Stephen Olander Waters wrote:
> > Here is the bug I'm working from (includes hardware, software, etc.):
> > https://bugs.freedesktop.org/show_bug.cgi?id=6111
> >
> > DRI will work if you set: Option "Bus
>> 0x1002 0x4c42 0 "3D Rage LT Pro AGP-133"
>> 0x1002 0x4c44 0 "3D Rage LT Pro AGP-66"
>> +0x1002 0x4759 0 "Rage 3D IICATI 3D RAGE IIC AGP(A12/A13)
>
> The formatting looks really strange.
>
> Also Rage IIC doesn't have a setup engine so AFAIK it should not be
> listed in the drm.
The bug has b
>
> Obviously, we are interested in making use of the new DRM memory manager
> on that hardware. Now if I understand how it works correctly, this new
> memory manager allocates opaque handles which are not to be used as
> offset in memory, because they are not. Therefore, a translation from
> the h
Did you build you kernel with CONFIG_DRM=y? if so don't.
to use DRM CVS you need to make sure in-kernel DRM isn't built-in.
If not I'm confused.
Dave.
On Tue, 25 Jul 2006, Michel D�nzer wrote:
Building DRM git against 2.6.17, I get:
Building modules, stage 2.
MODPOST
*** Warning: "drm
> I have a question in mind that why we Are moving all to git ?
>
> For me it has no good, i have to download everything from the buttom to the
> top. The conversion I found on web is for the source that will be placed on
> server only, no client site source conversion I can found.
> For me it is
I'm in the process of moving DRM CVS to git, can people avoid using CVS from
now on...
When I get the last admin help the repo will be (in a few hours):
git://anongit.freedesktop.org/git/mesa/drm
I've decided to put the drm under the mesa project on fd.o as the dri project
is pretty much reti
>
> Can we do this without upping the driver majors? we may have to add
> setparam support... my problem is after this change, old 2D driver may
> not work anymore with this DRM, so if I upgrade my kernel it will break
> things that currently work... we managed to mostly avoid this with the
> 64-bi
>>
> I just did this and fixed the SiS and Unichrome 3D drivers, bumping their
> drm device driver majors. The fixes tend to be very small. The intel drivers
> should also be OK.
Can we do this without upping the driver majors? we may have to add
setparam support... my problem is after this chan
>
> I'd like to bring in the hashed map lookup from the drm-ttm-branch to CVS. It
> changes the drmmap() map lookup from a linked list search to a hash lookup.
>
> This means that the user_token that identifies the map in user space becomes
> an arbitrary hash key in the range 0x1000 to 0x900
> While grep'ing through shared-core/drm_pciids.txt, I found out that there are
> some duplicate entries for Intel chipsets. The attached patch remove the dups
> and move the i915 section below the i810 and i830 sections. I'm not sure if
> this is really important or not, but dropping a note wi
Hi,
As the ATI driver lacks a clear maintainer and really wants to
live in git I've migrated it.
The git URL is
git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati
I'm awaiting admin intervention to do a few other things (non-admin
shouldn't try to migrate things it is too muc
> Both i915 and radeon memory managers could probably be moved over to the new
> code, but then only using the functionality in drm_mm.c and not drm_sman.c.
> I'll have a look. However, I'd rather focus on getting the ttm branch in a
> usable state and start moving drivers over to that function
I'll have a look. However, I'd rather focus on getting the ttm branch in a
usable state and start moving drivers over to that functionality, eventually
obsoleting the code in drm_sman.c.
Oh no worries don't let me detract from the real problem, I just wondered
having looked in those files be
New semantics:
The new manager always aligns to 16 bytes, except when it is bypassed by
the SiS fb module.
Yes you're right. The core functions support any alignment so the constraints
are device specific.
Just another question, could this code be used to replace all or
parts of i915_m
No.
and ATI hate you for trying :-)
see numerous archive posts about this..
Dave.
On Thu, 25 May 2006, Pekka Enberg wrote:
Hi,
I am running Ubuntu Linux on Intel-based iMac and was wondering if I
could use the r300 driver for 3D. The card is a PCI Express ATI Radeon
Mobility X1600 (M56P).
Is it PCI Express carD? if so suspend/resume is a fixed bug in Xorg CVS,
you need to get that stable ati driver and install it on Xorg7.0, if you
are running Fedora it should be in updates-testing I think and Ubuntu has
it in dapper..
Dave.
On Tue, 2 May 2006, curt manucredo (hansycm) wrote
On 3/25/06, Luca Dionisi <[EMAIL PROTECTED]> wrote:
> I'm having problems with Xorg built from cvs sources very recently.
> I've also built from cvs sources libdrm and the latest kernel (2.6.16)
> with the drm enabled for my card (radeon)
> I don't know for sure, but I think my problem is with the
I think that's what drm_lock.c:drm_notifier is for.. block_all_signals is
only used by the DRM from what I can see just for this reason..
Dave.
On Mon, 20 Mar 2006, Keith Whitwell wrote:
I believe that on Linux, there is actually some code in the kernel to put on
hold various sorts of signa
Based on X300 but isn't... it doesn't work yet due to having a
different memory controller.. I've no idea how long it will take for
someone to fix that or for me to get one long enough to play with it..
Any possibility someone could enlighten me with ways to "play around"
with my 200M? I'd lo
I have a ATI radeon chipset based motherboard with vga
integrated based on X300 hardware. The ID of my card (vendor 0x1002, id
0x5a61) isn't yet in the drm_pciids.txt so I mail what I know about this
hardware:
Based on X300 but isn't... it doesn't work yet due to having a different
To test last features of DRI drives, you should need lastest drives of X
tree, but to test latest Mesa3D it self you don't need it latest X.
There is no DRI drivers in X tree anymore.. there is no Mesa in X tree
anymore... there is no X tree anymore..
Dave.
--
David Airlie, Software Engine
tree (20060226). This now has the latest and greatest changes in Xorg
CVS that the monolithic tree did not have. Among other things this means
that i915 should now work again, with rotation support. It also has
Benjamin Herrenschmidt's memory mapping changes that should solve lockup
problems on
> > 2) With current drm CVS: When starting Xgl I get
> >
> > [4296305.078000] [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset
> > failed range check (reg=4e28 sz=1)
> > [4296305.078000] [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed
and I may have missed a patch chunk.. should b
> 1) The patch doesn't apply against DRM cvs (Feb 18th)
DRM CVS has the patch so patching is pointless..
Dave.
>
> 2) With current drm CVS: When starting Xgl I get
>
> [4296305.078000] [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset
> failed range check (reg=4e28 sz=1)
> [4296305.07800
The kernel DRM has fixes for this I just haven't ported them back to CVS
yet...
Dave.
On Sat, 18 Feb 2006, Felix Kühling wrote:
> Hi,
>
> does anyone object to applying this patch to linux-core/drmP.h:
>
> --- drmP.h2 Jan 2006 05:54:10 - 1.172
> +++ drmP.h18 Feb 2006 18:46:54
> Hi. New to hacking on the DRM so I may be seeing something wrong:
> drm_bufs.c:drm_addbufs_pci doesn't set buf->bus_address. Is this correct or
> a bug? If it's correct, what should I be using to pass the system memory
> address to the card for DMA?
>
Try the attached patch, I haven't tested
>
> Well, I did not know about the GART problem. So this means that
> RV370s and XPRESS will be listed both separately in the driver in the
> future? They certainly don't function as an RV350 and of course they
> aren't quite compatable then.
The RV350 and RV370 are more or less programatically
> One can hope that despite the newness of X1600 chip some of the basics (like
> video mode setup) would remain similar enough to have partially functioning 2d
> driver.
The memory, PLL and 3d parts are pretty much the same, the 2D core is very
very different, I'll be getting one soon, expect som
> libGL error: drmMap of framebuffer failed (Invalid argument)
> libGL error: reverting to (slow) indirect rendering
I've been wondering about this, I mentioned it to Alan + Keith at XDC,
I've had to patch my libdrm to be okay with an 0 length mmap,
Something like I'm sure TG have done somethin
On 1/31/06, Dominik Brodowski <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Something strange goes on when I try to switch more than two times between
> gnome themes using gnome-theme-manager: the X server is killed -- that also
> happens with 2.6.15, and that is surely an userspace bug, and the login
> man
> > This is due to snapshots building X.org drivers from the monolith tree,
> > the monolith tree is dead so no new devel is done in it.. TG commited
> > changes to the i810 driver for rotate which changed the size of rec...
> >
> > re-doing snapshot to use the modular tree is a bit of work though
;
> Thanks!
>
> Koby
>
> Quoting Dave Airlie <[EMAIL PROTECTED]>:
>
> >
> > This is due to snapshots building X.org drivers from the monolith tree,
> > the monolith tree is dead so no new devel is done in it.. TG commited
> > changes to the i810 driver f
This is due to snapshots building X.org drivers from the monolith tree,
the monolith tree is dead so no new devel is done in it.. TG commited
changes to the i810 driver for rotate which changed the size of rec...
re-doing snapshot to use the modular tree is a bit of work though..
Dave.
On Wed,
> DRI, from Mesa CVS, still builds, but falls back to indirect rendering since
> it needs DRM 1.22.x to run.
>
> Isn't it possible to only make newer functionality in the DRI drivers depend
> on newer DRM? This way, users stuck with a particular version of the DRM
> still have functional DRI drive
> Kay pointed out today that the drm code creates a "dev" file in sysfs,
> yet doesn't tell the driver core about it. Normally this would be just
> fine, as you are exporting the value in the proper style, but now there
> are programs that are only watching the hotplug/uevent netlink messages
> an
Hmm is that a PCI card or AGP?? I just got a PCI 7000 and I checked the
fixes in to make it work into the kerne, must check they went into DRM
CVS..
Dave.
On Tue, 17 Jan 2006, Helge Hafting wrote:
> For years, this card would simply hang the pc a few seconds after
> starting up X with DRI:
> 0
> the module section of xorg.conf, then it works fine. The wierd thing
> is that occasionally (say 1/20 attempts) the xserver will start (with
> dri enabled). Once it gets that far it seems perfectly stable to use,
> including 3d.
>
> More details are here:
> http://bugs.debian.org/345729
> ht
> dri enabled). Once it gets that far it seems perfectly stable to use,
> including 3d.
does either
Option "ColorTiling" "false"
or
Option "DynamicClocks "false"
help at all?
Dave.
>
> More details are here:
> http://bugs.debian.org/345729
> http://lists.freedesktop.org/archives/xorg/2006
> > I have update my kernel to 2.6.15-mm2 and installed udev.
> > I have agpgart compiled into the kernel while drm is a module.
> >
> > The following two lines are the end of dmesg output, nothing else in
> > that output is related to agpgart or drm.
> >
> > [drm:drm_fill_in_dev] *ERROR* Cannot i
> Hey all,
> I took these register dumps from my Radeon Xpress 200M using the hw_script
> program and the read_radeon_pcie.scp script. One is from a clean startup, and
> the other one was taken from an X session. If there's anything else I can do,
> let me know, I'm eager to help.
So these chip
> >
> >>Dave Airlie: Can we get those DRM changes pushed into 2.6.15 or is it
> >>too late for that?
> >
> > 2.6.15 has been released yesterday.
>
> D'oh!
>
> Dave Airlie: Can we get those DRM changes pushed into 2.6.15.1 or are
> the cha
> Attempt to run Operation Flashpoint with wine gives me following error:
> $ date; wine FLASHPOINTRESISTANCE.EXE; date
> Wed Dec 28 17:37:19 EET 2005
> DRM_RADEON_TEXTURE: return = -11
>offset=0xd2a23000
>image width=1024 height=1024
> blit width=1024 height=2048 data=0x2edcf200
> Wed
>
> Reverting that one change seems to have done the trick:
>
okay I reverted it in CVS..
Ben is going to come up with a better way to do this stuff..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
-
>
> [drm:radeon_check_and_fixup_packets] *ERROR* Invalid depth buffer offset
> [drm:radeon_emit_packets] *ERROR* Packet verification failed
> [drm:radeon_cp_cmdbuf] *ERROR* radeon_emit_packets failed
Hi Chris,
Can you test with DRM CVS with this reverted?
http://cvs.freedesktop.org/dri/drm/shared
vers, the CVS tree still has this, at some point I'll start fixing up
the kernel to support fb and drm devices on the same PCI device...
> I wanted to get myself linux kernel updated to latest DRI code, but I
> don't know what to do to be generally productive, i.e. so those patchese
> Anyhow, I was wanting to volunteer my services and my Radeon Xpress 200M for
> development work on this project. I have some kernel hacking/driver
> development experience, but that was on a device with open specifications, so
> I wanted to ask the following questions:
> 1) What do we curren
>
> > I have been working on adding vblank synchronization to the i915 driver and
> > I'm running into a performance problem. I was hoping someone that has done
> > this type of thing before might have run into this problem with another
> > driver.
You might like to take a look at
https://bugs.fre
> I have been working on adding vblank synchronization to the i915 driver and
> I'm running into a performance problem. I was hoping someone that has done
> this type of thing before might have run into this problem with another
> driver.
How have you added it? by changing the page flip path?? (a
> On a quick glance (though I'm not familiar with that driver), it looks to me
> like introducing texture rectangle caused mipmaps to be disabled for
> compressed textures.
oops, my bad.. I've checked in the fix.. thanks,
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied /
I was just getting Xglx GLX support working again, Xglx builds it GLcore
using the USE_MGL_NAMESPACE, however my r300 driver was calling the GLcore
version of a the glapi functions and variables..
The patch below is required, the glapi.h changes are probably okay, the
glapi.c changes I'm not 100%
> >
>
> Still looking at small test program.. but changing the GL_QUADS to two
> GL_TRIANGLES seems to solve the problems.. mayve the M7 has some
> degnerating problems..
Or maybe it doesn't support HW quads as ajax pointed out, and the sw quads
have some problems..
Dave.
--
David Airlie, Softw
>
> As long as the texcoords at all four corners are being translated the same
> amount, I wouldn't expect any differences in interpolation along the shared
> edge for the two triangles.
>
> If you've got a simple test program, perhaps some of us can test w/ different
> hardware.
>
Still looking a
If you take a look at
http://www.skynet.ie/~airlied/butns.png
you'll see the same texture being drawn in two places, however the second
one is corrupt along the triangle join line...
the only difference between the two is the glTranslate called before them
moves the centre point to a different p
>
> No ctx->FragmentProgram._Current!!
> drmRadeonCmdBuffer: -22 (exiting)
>
> dmesg shows:
>
> [drm] Loading R300 Microcode
> [drm:r300_emit_carefully_checked_packet0] *ERROR* Register 4500 failed check
> as flag=00
> [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed
>
My bad, texrect nee
> >
> > I'm a bit rusty on the DRM but it looks like the changes are minor so
> > I may do the updates unless someone beats me to it, or indicates
> > there's a reason for things as they are.
>
> I'm still catching up on email from the holiday weekend, but I plan to import
> a new libdrm into the
>
> Current cvs does not build as part of kernel. There are
> major changes since in-kernel version. I want to
> build in kernel space by kernel make together with other
> drivers.
Get current CVS, don't worry about the kernel, you don't want to bother
>
> 20050718 snapshot is close and builds af
> I like to upgrade mach64 driver for inclusion in kernel and
> desire a datasheet.
You'll need to get ATI to give you it, off late ATI have been ignoring
most requests from individual developers
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
> I like to upgrade mach64 driver for inclusion in kernel and
> pull relevant version from cvs.
There isn't one.. just fix the mach64 in CVS to be secure and it will
magically get merged to the kernel at some point after that when I've had
it reviewed to check it is secure..
Dave.
--
David Air
>
> I made a fix to the locking code in main drm a couple of months ago.
>
> The X server tries to get the DRM_QUIESCENT lock, but when the wait was
> interrupted by a signal (like when you move a window around), the locking
> function returned without error. This made the X server release other
>
Looks good.. but dude diff -u plz
I can't read context diffs to save my life...
Dave.
On Wed, 23 Nov 2005, vehemens wrote:
> I appear to of eliminated my remaining lockups by also idling the 2D engine in
> radeon_cp_indirect which is being called from the xserver. Here is my latest
> patc
> > Log message:
> > Fix cpu_to_le32 same as kernel not sure it is correct for ppc
>
> Looks correct, but as the PCIe GART table is in the framebuffer, the
> card's byte swapping needs to be disabled for this.
Yes thats what I wanted paulus/benh to check out, I was unsure how the
swappers were
>
> As a side note, I wonder it it wouldn't be worth defining a dedicated
> macro for this one DRM_INFO() call, as you seem to be willing to have
> the very same format for all drivers.
You should really look at DRM CVS, where this code is cut down
considerably and is going to be pushed into the k
> I got a warning and while going to fix it, I discovered some issues with the
> code (including raciness).
>
> While compiling 2.6.14 for x86_64, I got:
>
> CC [M] drivers/char/drm/drm_bufs.o
> /home/paolo/Admin/kernel/6/VCS/linux-2.6.14/drivers/char/drm/drm_bufs.c: In
> function `drm_addmap_io
The current CVS has changed the whole way this is called.. I'll be putting
that patch into git for 2.6.15 soon..
Dave.
On Fri, 28 Oct 2005, Jean Delvare wrote:
> Hi David, all,
>
> Looks like the PCI names database removal was done in a rush on the
> drm front. I propose the following cleanup.
>
> I guess I don't see a problem with putting it in libdrm. I had just
> assumed that the user-mode portion would end up living in
> src/mesa/driver/dri/common or some place similar. There are some
> advantages to putting it in libdrm, though (e.g., easier for EXA to use it).
Well the X server
>
> So, something like Get/Set/UnsetAttribute() perhaps.
>
> But also, thinking about the use of these regions for DMA, synchronization is
> important. I saw the SetFence() entrypoint, there's no way to retire these
> fences, eg a FinishFence().
>
> You've probably seen this one:
>
> http://oss.s
I've been thinking a bit about this, and while I think Ian's work on the
memory manager has merit I'm starting to think we are really putting the
cart before the horse in some ways
My thinking on this is that the memory manager needs to live in libdrm,
not like the current bits in Xorg DDX, b
> Does this patch help? It's somehwat overkill I guess always updating the
> texture matrix when the _NEW_TEXTURE flag is set (though the r200 driver does
> exactly that, not quite sure yet why), but I think currently the
> update_texturematrix function may not get triggered if a texrect texture
>
Hi Roland,
Just to reconfirm what I said on IRC, I put my M7 back into my
machine and my internal application is defintely broken with the latest
radeon texrect changes...
I'll leave the M7 in for a few days and I'll have a look at the code if I
get a chance..
Dave.
--
David Airlie, S
>
> Thanks! I downloaded and compiled xorg and mesa from cvs today. Now if
> I try to start X with dri active the computer locks up, and it's a
> hard lock-up -- I can't ssh into the machine. Nothing special appears
> in the syslog, and the xorg log does still say that dri is disabled
> for some re
> >
> > I plan to release Mesa 6.4 fairly soon. That'll get imported into
> > the
> > X.org tree.
>
> On http://dri.freedesktop.org/wiki/Building is write "The Mesa drivers
> now require libdrm to be installed."
> This is correct for Mesa 6.4 or libdrm will stay only on Mesa HEAD ?
No both of the
> DXT apears very stable (does not crash/lockup) but I experience corruption
> (dansing colored tiles) when (semi)transparency is used in a DXT game
> Neverwinter Night.
>
> http://megahurts.dk/rune/stuff/image_DXT_transparency_err.jpg
>
Yeah I've got NWN here.. must put in on my laptop at some p
> > is loaded before the radeon kernel module.
> >
> > I get this error with linux-2.6.13 and 2.6.9 both with agpgart and
> > uninorth driver built in. The drm module is from cvs, and I've tried
> > with xorg-6.8.99.15 and cvs. I'm running on a powebook5,2 with r300
> > card. You can find some logs
>
> I think the single most important point is to explicitly disallow
> vendor-supplied libGL binaries in the LSB. Every other LSB componenet
> relies on a single backing implementation for a reason, and in practice
> the Nvidia libGL just causes endless pain where people acceidentally
> link agai
I was talking to Ben on IRC about this and I realised I wasn't really sure
about this..
At the moment we allow the DRI client full r/w access to the framebuffer
if I'm not mistaken (for software fallbacks and the like)..
If I put the PCIE GART table into fb memory (which I've no choice in), the
>
> ok so this brings the question: how does naming it DRM_ARRAY_SIZE make
> it more portable than naming it ARRAY_SIZE?
> If *BSD doesn't have ARRAY_SIZE, then surely naming it ARRAY_SIZE is
> easy for them to provide (after all they need to provide it already just
> called DRM_ARRAY_SIZE); if th
> > Can you try it now , I added __ATTR to the backwards compat header file...
>
> Where?
>
Sorry it should be in drm_compat.h now.. I hadn't noticed the commit
failed because my tree wasn't up to date..
Dave.
---
SF.Net email is sponsored b
On Sun, 25 Sep 2005, Dieter Nützell wrote:
> Worked for ages.
> What shall I do, since I have a brand new Radeon 9550?
> Yes, my system would be updated to SuSE 10.0 (2.6.13+), soon.
>
Can you try it now , I added __ATTR to the backwards compat header file...
it should build I think..
Dave.
-
>
> drivers/char/drm/drmP.h defines a macro DRM_ARRAY_SIZE(x) for
> determining the size of an array. kernel.h already provides one.
>
> Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
Nak.
We have DRM_ for cross platform reasons in DRM, I could in theory get rid
of all of them in the kernel,
>
> > But the *fb drivers do provide a nomtrr option in many cases. (But I'd
> > like to remove it from them too :-) or at least default those to off)
>
> Sounds sane. Nvidia posted some patches a while ago that seem to be
> getting kicked around a bit again to add support for PAT (per page
> attri
> >
> > Not sure what to do there.. have to ask the fb devel guys..
>
> Ben ?
I'm not sure if Antonio Daplas is on this list.. they are all on
[EMAIL PROTECTED]
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILU
> > I don't think we can really just nuke support for them, maybe we should
> > fix the support if we can... the problem I have is removing them will
> > signiciantly slow down a lot of working systems.. if the X server doesn't
> > do the correct thing..
>
> Problem here Dave is that there are pr
> It doesn't have the intimate knowledge needed to properly configure
> MTRR's and fails in many cases.
I don't think we can really just nuke support for them, maybe we should
fix the support if we can... the problem I have is removing them will
signiciantly slow down a lot of working systems..
>
> I was going to suggest that this might be related to Paul MacKerras'
> texture upload fixes for r300 on big endian machines, but they don't
> seem to be in DRM CVS yet. Are they only in the kernel yet? Which DRM
> are you using?
>
They should be in DRM CVS, they came along with the r300 impor
> I should have some time next month.
>
> > Well, you get the idea - there is still much fun to be had with this
> > driver :)
>
> Sure, much fun would come from a proper memory manager *if* it never gets
> done.
I'm hoping to get s3tc/texrect support for r300 over the next while, the
textu
>
> Hi!
> Where can we get the new code?
> Thanks!
X.org CVS and DRM CVS, the Mesa driver needed no work.
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
---
> > >
> > > I'm hoping I didn't break standard PCI GART on r128...
> > Can it be checked on plain AGP r128 card (with Option "BusType" "PCI")?
Yes BusType on r128 should be good enough to check I didn't break it...
I didn't implement table in FB for r128... I've no idea if it would work
or not..
Okay I've completed the PCIE support for the r3xx and r4xx radeon cards,
It needs a new DRM and DDX, as I've had to move the PCI GART table into
framebuffer RAM, so the DDX needed an update.
Also for normal non-PCIE radeons, this code should work to move the GART
table into FB as well which mig
On Thu, 8 Sep 2005, Daniel Estévezz wrote:
> El Jueves, 8 de Septiembre de 2005 00:38, escribió:
>
> > You should use David Airlie kernel DRM (which is in current Linus
> > "git" top of tree) along with the following patch in case it didn't
> > make it yet:
>
> OK. I have downloaded the project li
>
> > If other people has got to compile it, the problem should be in my
> > computer. Where could be the problem? hardware? compiler? kernel? a
> > corrupted file in my CVS tree? which one?
>
> try this patch (works for me):
I've just checked this in to X.org tree..
Thanks,
Dave.
--
David Airl
> >
> > Support for ATI_fs will be enabled automatically if texture_units is set
> > to 6 (there is simply no useful way to expose this with less units).
>
> Are these really related? My understanding is that texture_units is
> about the number of 'traditional' GL texture units exposed, and that
>
With the root only/master split the flags looked ugly
Any objections to a cleanup along the lines of this patch?
Index: bsd-core/drmP.h
===
RCS file: /cvs/dri/drm/bsd-core/drmP.h,v
retrieving revision 1.68
diff -u -r1.68 drmP.h
801 - 900 of 1512 matches
Mail list logo
