I'm a bit behind on this area, the patch looks fine, I'm just wondering
should it intersect with the drm_pci.c stuff for the mach64
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
-
>
> drm_pci_alloc allows limiting the maximum address. Would it be too
> hackish to pass this via map->offset to the drm_addmap ioctl?
Probably no need for the Xserver maps to care about a max address I'd hate
to overload anything in the addmap ioctl...
Dave.
--
David Airlie, Software Engineer
>
> I wasn't doing anything too taxing at the time - just
> taking a trip to Pluto and Charon via 'celestia'.
>
> (And although I say "locked up the X server", I was
> still able to move the mouse cursor around. However,
> the cursor graphic stopped changing, and the screen
> was no longer being up
>
> It seems this was related to limiting the max_address. Anythingh other
> than 0xUL makes pci_alloc_consistent allocate pages with GFP_DMA
> which is intended for ISA DMA < 16MB. I don't think we're ever going to
> need this in a DRM driver. I attached an updated patch that uses
> drm_p
>
> This patch looks to be along similar lines, but for buffers in video
> memory. Is it worth including?
>
> https://bugs.freedesktop.org/show_bug.cgi?id=1668
I'll probably check this in the next couple of days.. I'm just catching up
on any drm bugs logged now...
Dave.
--
David Airlie, Softwa
> There are also three client-side pieces: libGL, *_dri.so, and (uh-oh) drm.
> 'drm' here is libdrm, which lives in /cvs/dri/drm and is occasionally
> imported into X as hw/xfree86/os-support/$(uname)/drm. libdrm is identical
> on both sides, modulo wrapping some things like malloc to use either
> >
> I know, this causes a problem for any one building Xfree86 DRI. We need
> to fold the DRI xc tree into Xfree86 or stop using Xfree86 alltogether.
> I'm talking about 2d Xdrivers, where current MergedFB is built. I think
> these can be built with the Mesa/lib/r200_dri.so files that live in
Okay I've rebuilt the via drm tree (bk://drm.bkbits.net/drm-via)
It should work but I've no way to test it, I think the drm is close to
secure now if not already, and if I get the nod from the people who know
these things (Thomas, Erdi and Keith - consider yourselves the people),
I'll try and hav
Okay some people have commented on the DRM CVS of late, and are unsure of
what is happening with it,
I'm very willing to drop the shared and linux directories into an archived
area but that will stop all support for Linux 2.4,
but at the moment I'm getting the impression more people are using th
> > > I'm using via drm CVS as of Dec 30th 2004 and Unichrome r28 / r29
> > >
> > > Does anyone on this list know more about this issue?
> Thanks for the info. I'll try to update drm and recompile. Could be that the
> binary was left over in some way..
Make sure if you are using drm-core than yo
>
> After think a little and put dri working with kernel 2.4.
> The only solution, that I see, to not private users of savage with
> kernel 2.4, have dri. Is do 2 directory on Xorg tree, one with the code
> before 2005-01-01 and other for kernel 2.6
Not really a good idea, the old code was not re
>
> Ok I accept that, about releaseable and dodgy DRM drive, I agree.
>
> but just a tough, about security, nowadays it common say, errors are
> security problems, I don't see how could drm be insecure.
Well if you have a multi-user machine, and they have access to the
insecure drm, they can write
I've done a cut-n-paste job on the r200 client storage stuff and made a
radeon version..
http://www.skynet.ie/~airlied/patches/dri/radeon_client_storage.diff
It builds I don't have a radeon here I can test it on .. when I get back
into work I'll test it and commit it if no-one has any problems w
>
> The env var still has the R200 prefix, otherwise it seems fine.
> However, is this actually useful? IMHO, this is just dead code which will
> never get used normally. At least I don't know any single app which would use
> the extension - they definitely prefer things like ARB_vertex_array_objec
Hi Alan,
you checked in some changes to the i915 drm but the changelog looks like
you did more did you miss some changes in the checkin?
mainly it says added resume functionality but the patch just changed a
function name added the pci id and bumped the driver version...
Dave.
--
David Ai
Hi,
I've just noticed that Alan has checked some changes into
extras/drm in the Xorg tree, I'm sure these are needed to build the latest
drivers but I'm just wondering how we should approach these things in
future?
When we next import a DRM from the main tree will we have to much about
wi
>
> > When we next import a DRM from the main tree will we have to much about
> > with CVS admin to put things back on the vendor branch?
>
> You shouldn't have to muck about with CVS admin. I don't understand
> this. Using 'cvs import' and fixing conflicts should be fine.
I've found with doing ve
>
> The 4 level code is already in Linus bk which also has the 2.6.10
> kernel version. I don't see a good fix for this. I'll complain on
> lkml.
I usually fix this by not supporting Linus trees in CVS until they are
released :-), also why I don't put -mm patches in either it's too much
hassle
Just to update, I've looked at the fragment shader stuff and the
documentation I have isn't enough to implement the spec, we only have
access to the second stage registers (PP_CNTL - states second or only pass
registers)
I'm going to use the r300 stuff to start reverse engineering the fglrx
s
> I'm following DRI devel the mailing lists and have not seen anything on
> the Mach64 driver lately, especially on the security issues. Any
> progress? Is Mach64 in Xorg-6.8.1? I'm running Debian with XFree86-4.3.0
> and self compiled xlibmesa-dri xserver-xfree86 packages. Unless the
> switch to
> Well, when I went to load the kernel module I compiled from the
> /drm directory, I get this:
>
> radeon: Unknown symbol drm_open
> radeon: Unknown symbol drm_fasync
> So what am I doing wrong this time? :-)
>
insmod drm.ko first..
Dave.
>
>
On Thu, 13 Jan 2005, Roland Scheidegger wrote:
> Ok, here's a new version. It also contains a supposed patch for
> mergedfb-pageflip (untested, but I need that for color tiling, otherwise I'd
> need to redo the crtc address calculation in the drm).
This looks great, just an aside question, how mu
> After an S3 suspend/resume cycle I find that programs trying to
> access /dev/dri/card0 lock up. (the program I am using is viewmol, but
> it happens for others too). I can't stop the program with Ctrl-C, only
> kill works on it.
>
> I write to the i830 developer, Keith Whitwell. He replied that
> Is it possible to run 32bit OpenGL applications on an AMD64 with DRI
> support? 64bit applications are working fine, but 32bit apps always
> use software rendering on my machine (Radeon 7500).
> It looks like an kernel issue. So my question is, if there are any kernel
> patches available to solv
> > I have an application that has been running for 2-3 days no worries
> > with vblank_mode=0, but of course chews CPU and tears the screen, I
> > recently started running it with vblank_mode=2 or 3 and it hangs
> > in the glXSwapBuffers after a few hours, it looks like it is repeatedly
> > calli
>
> Have you ruled out simple logic bugs causing a spurious failure?
well I'm doing a code review of the code over the next while also, I do
wonder is thers some amount of interrupts that I'm failing after or if
there is maybe some small race in the interrupt handling.., so
consistency tests are
> This is not a driver bug. Doom3 with r_renderer arb simply does look
> that awful. At least I've tried it with some other OS, and it looked
> exactly the same. AFAIK noone has the required documentation to
> implement the ati fragment shader extensions, which are required to
> enable other r_ren
> [1] current mesa CVS appears to use a number of constants mostly related to
> HYPERZ without defining them. Perhaps I should have followed build
> instructions exactly. I have a patch that gets me through the compilation (it
> is not something to commit, rather to give an idea where the problems
Hi all,
On error a lot of DRI drivers do an exit and just leave, this
means you have to setup a break on exit to debug these cases which can be
a bit of a pain if you forget.. I wonder how to people feel about
changing these exits to aborts so the app gets a signal and then can be
backtrac
> Almost certainly. Last time I glossed over it, there definitely seemed to be
> some registers missing which would need to be emitted. Though it might be
> easier to just put everything in one single big block and emit that instead,
> since it looks like everything fragment shader related has con
Further on this.. actually tcl looks to be involved as well, I found
another bug unrelated to the vblank_mode in a certain screen of my
application, entering the screen and leaving it twice in a row, causes a
chip lockup, disabling TCL makes it go away
so does anyone know offhand from experie
I'm getting some TCL issues on the radeon M7 with my app which is a heavy
user of triangle strips...
a dump with prim debugging shows..
radeonAllocEltsOpenEnded: header 0xc0002300 vfmt 0x80040088 prim 214
vtxfmt prim 1: GL_TRIANGLE_STRIP 3..6
vtxfmt prim 0: GL_TRIANGLE_STRIP 0..3
radeonEmitState
Okay the radeon has been unstable since Eric's changes back on Sept 25th
in its current configuration, even on single app solo configs...
I've rebuilt my driver with OLD_PACKETS set to 0 and MAOS_VERTS to 0,
which makes it look like an r200 and it seems stabler (well gears and
ipers work...)
I'v
>
> I think Erics fixes back in Sept time frame fix any issues that stopped us
> from switching OLD_PACKETS off..
maybe I speak too soon.. ut2003 seems to take my card out ...
this is most annoying :-)
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.i
> It's strange you get better results with OLD_PACKETS and MAOS_VERTS set to 0.
> I've tried that on my 7200sdr just very recently, and with that quake3 locks
> up usually within a few ms, sometimes it will live some seconds...
> But with OLD_PACKETS and MAOS_VERTS, it seems to run stable.
> glxge
Okay it was an old bug resurfaced by the looks of it.. there used to be
code written by Felix in the radeon driver to always emit a zbs atom no
matter what, I've spent two days staring at the driver and the attached
patch looks to fix the gears crapping out ...
I've played q3, ut2003 and ut2004 a
> yes, your patch fixed the glxgears-lockup for me, too. Thanks!
> It looks like this is only necessary on RV200 based chips, maybe a comment in
> the source about this behavior might be usefull, otherwise this workaround
> will get removed in the future again... because other radeons work well
>
build in the linux-core directory not the linux-2.6..
Dave.
>
> savage: Ignoring new-style parameters in presence of obsolete ones
> mtrr: 0xf000,0x100 overlaps existing 0xf000,0x80
> mtrr: base(0xf200) is not aligned on a size(0x500) boundary
> [drm] Initialized savage 1
> > docs mention it) ... is it acting like a nop or does it do something ...
>
> This might affect/cure R100's as well. I was recently trying to help
> someone
> with lockups on their Radeon 7200 when using Mesa CVS but without
> success.
> Testing with my old Radeon DDR also caused lockups.
>
> I'
Eric mentioned to me that the drm-core setversion was busted, I think I've
fixed it .. could anyone that has non core okay but core issues give it a
try to see if it fixes things..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECs
I've noticed fglrx advertises this for the r200, and doom 3 wants it...
So after I manage to beat fragment_shader into shape, going to have a look
at how to get ARB_vp working.. r300 guys you have something going on this
already?
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~a
> are *completely* different from those on the R300. Now maybe the R200 has
> both a dedicated fixed function pipeline *and* a programmable processor,
> but unless that is the case, I assume fglrx on R200 tries to map ARB_vp
> onto fixed function when it can, and falls back to software otherwise.
> initializer element is not constant
> /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:112: error: (near
> initialization for `driver.pci_driver')
> make[2]: *** [/usr/home/adamk/saved/source/drm/linux-core/radeon_drv.o] Error
> 1
> make[1]: *** [_module_/usr/home/adamk/saved/source/drm/l
Currently the r200 driver has TFACTOR_0 packet, which takes 6 constants,
however there are actually 8 constant registers used in ATI_fs and the two
extra are just after the the other 6
So what is the best way to approach adding thse two,
a) define a new packet for just 2 elements.. makes cons
> b) define a new packet for 8 elements, make driver use it everywhere,
> leave old code in DRM for backwards compat... (not sure this is possible,
> as it uses the register address to work things out...)
>
actually this is what I've done for the pixshader vs fragshader
instructions. which overlap
> > > The thing is that I don't see this with the old drm (Running for a
> > > reasonable amount of time), but on the other hand I can't see what in drm
> > > CVS could be causing this.
> > >
As anyone seen this in non via drivers? core has been in -mm and is now in
bk and I've gotten no problems
>
> Good point. That's my change in non-core which hasn't been propogated to
> core. It's just a cleanup & I wouldn't have expected either version to be
> crash-prone.
>
> I don't think the irq handler gets much of a workout unless you sync-to-vblank
> at the moment.
it may not be that.. but I w
> Cool. Is the savage driver included?
I'll push it in the next while .. I'm trying to stabilise core in kernel
first..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
On Mon, 31 Jan 2005 01:36:50 +0100, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This patch contains the following cleanups:
> - make needlessly global functions static
> - remove the following unused global functions:
> - drm_fops.c: drm_read
> - i810_dma.c: i810_do_cleanup_pageflip
> - i830_dma
> r200_ioctl.c: In function `r200PageFlip':
> r200_ioctl.c:571: error: structure has no member named `tiling_enabled'
> r200_ioctl.c: In function `r200Clear':
> r200_ioctl.c:635: error: `RADEON_USE_COMP_ZBUF' undeclared (first use in
> this function)
> r200_ioctl.c:635: error: (Each undeclared iden
> Though if r200 and r300 are going to be unified, I'd definitely suggest
> that radeon gets unified too. The code which can be shared between r200
> and r300 is likely going to be pretty much the same as the code which
> can be shared between radeon and r200, I think. In fact, if one would now
>
Okay can we open a bug on this, attaching xorg.conf and Xorg.0.log to
it...
I'm running r200, both 8500LE and 9200 cards at home and work without
issue, except a recent bug report where if you run
gears/euphoria/gtk-pixbufdemo it locks after a good while (hours...) as
tracking that sort of bug ta
>
> I fully support the idea of enabling gart texturing on the r200 driver. If
> the old client texturing code can be kept around as an X config option, so
> much the better, but it shouldn't stand in the way of gart texturing given the
> data above.
I think this is all in the client side of the
idr mentioned this is possible on the r100, all the info is actually in
the docs from what I can see, so only the Mesa side would need to be
done...
Anyone with R100 DDK, 7.7.10 and code in lib\3D\embm.c and chap7\bumpmap\
Probably wouldn't be that hard to implement
Dave.
--
David Airlie,
>
> But what if you mix clients with different configuration? That's why it
> has to be an X server option I think.
Yes figured this out chatting on IRC today... need to look at it again...
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb /
>
> A better scheme for a movie player would be to create a single texture
> and then keep replacing it's contents. Or use two textures and double
> buffer. But once created these textures would not move in the LRU list
> unless you started something like a game in another window.
if we supported
> > it. Instead mark it's page table entries as copy on write. Get the
> > physical address of the page and set it into the GART. Now the GPU can
> > get to it with zero copies. When you are done with it, check and see
> > if the app caused a copy on write, if so free the page, else just
> > remove
I'm just looking through the docs this evening and I noticed the
TXOFFSET_0 register has endian swapping for textures in hardware,
This allowed me to remove some swizzling in my own application along with
client side texturing... (i.e. more speed less processing..)
I'm thinking about how these c
> >
> > I'm thinking about how these could be used in Mesa drivers? would I be
> > correct in thinking the fallbacks would mess up as the Mesa copy of the
> > texture wouldn't be the same as what the card would be using?
>
> I'm not sure that the fallbacks in their current form ever actually read f
> Maybe GL_ATI_fragment_shader?
when I check in the r200 code it'll break doom for sure as I think the
vertex program stuff gets a bit messed up.. but my current version just
draws a completely black screen so not much use for anything... :-)
Dave.
> - Initializing Decls -
> --
> THe patch for this has been proposed in December 2004 to lkml and
> dri-devel
> (see http://marc.theaimsgroup.com/?l=dri-devel&m=110376607120133&w=2)
> and has been included into the -mm kernel series.
>
> It would be great if there is a patch allowing the usage of the drm cvs
> stuff for -mm ke
> No on has tried getting XGL running on top of mesa-solo. I don't know
> of any obvious reason why it shouldn't work other than no one has
> tried doing it yet. First check out that your mga mesa-solo is
> running, there are test programs in the mesa tree for this. Then try
> to get XGL running on
In your other message, you wrote:
>
> > building an Xserver on top of mesa solo is a bit of a nightmare in terms
> > of includes and defines .. as an Xserver requires all the X types to build
> > but solo has its own set of defines/typedefs that don't match what the
> > Xserver has... so calling X
>
> First off, has anyone updated the patch lately?
Nope, I think it needs to go back to the drawing board...
The biggest problem with SuSEs patch is that is was written by the looks
of it to cover the DRM and Mesa making changes to both to achieve the
solution, this isn't a way to acheive backwa
>
> 1. Lots of work that would take lots of time. To my knowledge all fbdev
>developers work in there spare free time. No one does this for a
>living.
So do most of the drm developers, I know I do and Jon Smirl does, and
Eric Anholt does and I think us three have been the largest
contribu
The r200 driver disable ycbcr texturing for non-r200 cards, like my rv280,
however I've just switched it back on and it appears to work for me except
in the case where I've a client side gart texture and using
R200_GART_CLIENT_TEXTURES...
I'll write a test soon and others can check it out..
Dave
> > however I've just switched it back on and it appears to work for me except
> > in the case where I've a client side gart texture and using
> > R200_GART_CLIENT_TEXTURES...
> Really? I've just tested this again, and the colors in yurrect/yuvsquare are
> still completely wrong (rv250).
hmm mayb
> > >
> > > Apparently the ARB rendering path on windows is exactly the same.
> > >
> > > DoomIII can't use the R200 rendering path as dri doesn't have
> > > ATI_fragment_program (?) yet. I believe there's half an implementation
> > > in existence atm...
ATI_fragment_shader it is .. but I've had n
I've synced up the glx.h in Mesa from the glx.h in Xorg, ajax suggested we
copy over the other glx header files into Mesa as well, good idea?
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
---
I know we want to kill this extension but that is no reason to not have a
demo...
I've coded up a version of yuvrect that uses AllocateMemoryMESA ... I've
had to add a new girl2.rgb file which is slightly smaller to get the
alignment requirements correct so that the driver uses client side
texturi
I've just checked in a couple of patches to radeon/r200 drivers..
1. make the texture level hack into a config option.. it is necessary to
play some games.. I bet most people have it in their trees already...
2. make ycbcr on r200 dependant on a new chipset flag.. if your chip has a
broken ycbcr
> Ok, I (finally) found it.
>
> You need the attached one-liner to set the mode. The rest is just something I
> have in my tree to make it gcc2-friendly.
>
committed thanks...
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX
>
> You also have to add the file, memops.h, to src/mesa/drivers/dri/comon
>
> I've added powerpc & ia64 for now. Let me now if other archs need this too.
>
committed...
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_
> >
> > I've added powerpc & ia64 for now. Let me now if other archs need this too.
>
> Why are you reinventing memset_io() ?
>
This is userspace :-)
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
>
> Odd. This is now happening, as well, with the drm from the 2.6.11 kernel.
> The card works fine with the drivers from XiG, however, so it doesn't appear
> to be a hardware problem.
>
wierd.. can you boot without X, and modprobe drm debug=1 then modprobe
radeon then start X? and send me on th
Hi all,
Andrew Clayton reported lockups on the dri list issues since -bk2
and bug 4337 on bugzilla.kernel.org looks like it might be the same
thing..
This leads me to think the AGP multi-bridge patches are at fault... (for
once my laziness in merging late instead of early gave a good gap
> >
> > I might get time to do a code review, my main worry is that all the
> > problems reported with those patches in -mm made it into the patchset that
> > went into Linus.. mainly things like forgetting to memset certain
> > structures to 0 and sillies like that...
>
> I saw one report wh
> > the multi-bridge stuff is definitely broken as I've seen radeon and r128
> > reports on it .. and it looks most like 2.6.11-bk2 broke things and I
> > haven't merged anything until -bk7 ...
>
> Wait, -bk2 broke things ? The big agp changes went into -bk3,
> so this seems odd.
sorry bk2-bk
On Thu, 24 Mar 2005, Jesper Juhl wrote:
>
> Parts of drivers/char/drm/ is severely broken in 2.6.12-rc1-mm1 - this is
> fair enough since it /is/ marked as broken. So, why am I writing this
> mail? Well, I /tried/ to build some of the stuff in there, saw it blow up,
> then tried to fix it, then g
>
> verify_area is deprecated, replaced by access_ok.
> Seems I missed this one when I did the big overall conversion.
>
>
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
>
In my tree for 2.6.12.. just have to fix the big clangers first..
Dave.
Hi Andrew, Dave,
I've put a couple of patches into my drm-2.6 tree that hopefully fix up
the multi-bridge on i915 and the XFree86 4.3 issue.. Andrew can you drop
the two patches in your tree.. the one from Brice and the one I attached
to the bug? you'll get conflicts anyway I'm sure. I had to mod
I've just nuked the linux-2.6 directory in drm CVS,
linux-core is good enough now I don't think we should have any regressions
and the linux-2.6 stuff wasn't building anymore and just confusing
people...
I've alos put a few patches from the kernel into linux-core so it builds
against newer kerne
On Wed, 2 Mar 2005, Nishanth Aravamudan wrote:
> Hi,
>
> Please consider applying.
>
> Description: Rather than use custom code in DRM_WAIT_ON() to do exactly
> what wait_event_interruptible_timeout() does, use the function and just
> change the return values appropriately.
I've applied this to
ye don't happen to be building with CONFIG_DRM=y?
you should never build a kernel with CONFIG_DRM=y anymore if you want to
use CVS..
Dave.
On Wed, 30 Mar 2005, Thomas Hellström wrote:
> Thomas Hellström wrote:
>
> > Benno Schulenberg wrote:
> >
> > > Hi Thomas,
> > >
> > > You wrote:
> > >
> >
>
> I'm trying to port DRM to NetBSD, for that purpose it's necessary to
> use the bus_dma(9) API instead of the vtophys hack. Therefor, I'm currently
> performing the last task which is going to be porting the DMA interface.
I think Eric may be the only person who can answer this.. I've no idea i
> I'm trying to diagnose and hopefully fix a recurring hang with my 9200SE
> (details below) and all recent DRM/DRI drivers on my desktop Linux system.
>
> I have a Duron 700 on Gigabyte 7ZM (via based) motherboard, configured for
> AGP 1x and with e.g. current Fedora Core 3 kernel (2.6.11) and X.
>
> The macro DRM_WAIT_ON changed behaviour.
> In earlier DRMs it checked every HZ for "condition" in case it was slightly
> missed.
>
> This doesn't happen anymore, which means some applications freezes for about 3
> secs, when they
> just missed an interrupt.
>
> This in itself is a little bit s
>
> I have an application that takes the hardware DRI lock and then does an
> usleep(1) while polling hardware status. Entering the polling function, I've
> verified that the lock is indeed taken
> 0x8002, with 2 corresponding to the correct DRM context. Upon exit from
> the polling function, s
> I agree, patch should be reverted. The difference between my change and
> the previous code, fundamentally, is that mine slept as long as possible
> relative to the passed in timeout until either a signal or wait-queue
> event happened; the original code, in contrast, slept for a fixed amount
>
> > 2) xf86dri.h and XF86dri.c that are part of mesa.
> > 3) Some of the dri utils from mesa, basically to handle basic drawable
> > management and locking.
> >
> > While doing this I notice that some (3) functions in XF86dri.c are
> > depending on Mesa headers and datatypes, and this does not see
>
> My issue with exposing XF86DRI* as they are now is that they're direct
> bindings to the XFree86-DRI protocol, which I don't think should be
> app-visible at all. Consider the possibility of someone wanting to write a
> DRI server that was not an X server. We should be enabling our competitio
>
>
> My point was really to move the XF86DRI functions out of Mesa dri to a
> separate library, and since libdrm.so could be used standalone and is
> conceptually different there maybe should be one libdrm.so and one
> libdriclient.so, or whatever we choose to call it.
I don't mind but conceptual
>
> So is it XFree86 license ? Pre or post 4.4.0 ? Or something else ?
>
MIT..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
---
SF.Net email is sponso
On 4/26/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Using 2.6.11.7, I'm experiencing the same problem as reported here:
> http://lkml.org/lkml/2005/3/12/99
>
> Except it happens for me after X is running. X locks up, only the mouse
> pointer moves, X spins doing this:
>
> --- SIGALRM (Ala
> In the meantime, here's a patch against current Linus "git" that I'm
> tempted to push asap so that at least 2.6.12 avoids the problem of
> overlapping which causes random stuffs to happen with lockups. The
> "issue" here is even if you don't have an r300-friendly DRM, it will
> still try to init
Just missed most of this, but we do have drm_device_is_agp(dev) in the
drm, only the CVS radeon uses this at present as the DDX can tell it
also...
But on Linux it just does..
pci_find_capability(dev->pdev, PCI_CAP_ID_AGP);
which sounds like your chip says it is AGP but is connected over a PCI
b
Okay I've been offline for a while, I did my standard CVS update on Mesa
and glxgears is busted
http://people.freedesktop.org/~airlied/brokengears.png
tcl_mode=0 looks fine..
not sure whether this is Brians framebuffer or some stuff Keith has done..
Dave.
--
David Airlie, Software Engineer
h
> > this even applicable to this version of X?
>
> If you are using bash:
> export tcl_mode=0
> glxinfo
> will show that tcl is off: NO-TCL in the renderer string.
> start your programm from this shell and it should run in sw-tcl mode.
>
> Are you using r200_dri.so compiled from current mesa-cvs re
> I reapplied Vladimir's fix and the machine doesn't lock up any more. Maybe the
> fix should be checked in to CVS again?
http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_mergedfb.c?rev=1.9&view=log
v 1.7 backs it out because it is buggy...
Dave.
--
David Airl
>
> I know, I read the checkin comment.
>
> However, is "buggy" better than "locked up hard"?
usually no... people try to fix locked up hard.. buggy always comes back
and bites you in the arse, 2 years down the road when you've forgotten
about it all..
Dave.
--
David Airlie, Software Engineer
h
601 - 700 of 1512 matches
Mail list logo
