Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 12:18:24PM +0100, Keith Whitwell wrote:
You didn't stick with that long Christoph. We're not even past first base
yet. Let's try again?
So, I've got this file "patch-2.6.8.1.bz2". Lets suppose my older brother
co
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 11:30:54AM +0100, Keith Whitwell wrote:
include a drm update. The last release RH-9 kernel has various security
and data integrity issues anyway, so you'd be a fool to keep running it.
OK, I've found www.kernel.org, and clicked on t
Nick Piggin wrote:
Keith Whitwell wrote:
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 11:23:35AM +0100, Keith Whitwell wrote:
Actually regulat users do. And they do by pulling an uptodate
kernel or
using a vendor kernel with backports. This model would work for
video drivers
aswell.
Sure
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 11:23:35AM +0100, Keith Whitwell wrote:
Actually regulat users do. And they do by pulling an uptodate kernel or
using a vendor kernel with backports. This model would work for video drivers
aswell.
Sure, explain to me how I should upgrade my RH-9
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 10:45:33AM +0100, Keith Whitwell wrote:
Umm, the Linux kernel isn't about minimizing interfaces. We don't link a
copy of scsi helpers into each scsi driver either, or libata into each sata
driver.
But regular users don't tend to pul
Christoph Hellwig wrote:
On Sat, Sep 04, 2004 at 01:51:24AM +0100, Dave Airlie wrote:
Then drm_core would always be bundled with the OS.
Is there any real advantage to spliting core/library and creating three
interface compatibily problems?
Yes we only have one binary interface, between the core an
Dave Airlie wrote:
Let me be clear that I am unwilling to support changes to the DRM that break
it's usability on other operating systems on principle.
I'm in agreement on that, ...
Maybe it's time to consider a fork of the DRM to allow a major experimentation
of the form Jon envisages to proceed
Dave Airlie wrote:
drm/linux is GPL licensed.
This just isn't true. What on earth makes you think this? Read the license
before you make these sorts of comments, you dweeb. There shouldn't be any
GPL code in there at all.
I think you mis-read Keith, he said about converting it in the future to
Jon Smirl wrote:
Would this work? drm/shared and drm/bsd directories are BSD licensed.
drm/linux is GPL licensed.
This just isn't true. What on earth makes you think this? Read the license
before you make these sorts of comments, you dweeb. There shouldn't be any
GPL code in there at all.
Kei
Ian Romanick wrote:
Dave Jones wrote:
2. 'The in-kernel AGPGART doesn't have all the features our driver
requires'.
Newsflash: I take patches.
Sifting through the ATI mashed-up agpgart is quite painful, as there are
so many changes in there ifdef'd to hell and back that its hard to see
whats real
Tony Murray wrote:
I am using drm from cvs and I fixed a few compile errors when the drm
drivers are used with 2.6.8.1 (all trivial api changes). I don't have
the hardware to test all of the drivers, but it should be fine.
Tony
diff -urN linux-2.6.8.1-drm2/drivers/char/drm/ati_pcigart.h
linux-2.6.
Dieter NÃtzel wrote:
Now I can do stuff with my r200 which I've done two years ago with my Voodoo
5500 AGP. - GREAT!
Several 'ipers', 'gloss', 'gears' and 'isosurf' run in parallel, now.
Even two quake3-smp instances run (timedemo 1; demo four) for some
seconds...;-)))
Dieter,
Have you tried thi
Stefan Dirsch wrote:
Hi
I'm using X.Org CVS (2004-08-22). AFAIK this is quite a new DRI
version or even DRI CVS release. The problem is:
Colors in OpenGL apps are mixed up with i810 DRI driver (tested with
i855).
The i810 driver doesn't work on i855 hardware - I'm not sure what you are
actually te
David D. Hagood wrote:
Keith Whitwell wrote:
Interesting but unlikely to be related to drm changes, first and
...
I hope this thread doesn't start some misconception that these changes
are breaking an existing binary interface - because one doesn't
exist! Though this is precisely m
David D. Hagood wrote:
Dave Airlie wrote:
Hi all,
I'm just wondering do we have a general feeling from a DRI
perspective on breaking the ATI driver (which is DRI based) from a drm
point of view,
The ATI proprietary driver *IS* broken right now - I am running FC2,
with X updated from the mainli
Dave Airlie wrote:
It should be possible to avoid the whole DRM(fff) thing using linker
directives to designate what symbols are exported from the final drm_xyz.o
object, in the same way that static symbols don't get exported from individual
object files.
I've thought this myself and mean to inves
Dave Airlie wrote:
-
#ifndef MODULE
/** Use an additional macro to avoid preprocessor troubles */
#define DRM_OPTIONS_FUNC DRM(options)
@@ -93,9 +82,6 @@
#undef DRM_OPTIONS_FUNC
#endif
As a general rule - if you need to check for MODULE you are usually
doing something wrong...
I think for 2.4 comp
Dave Airlie wrote:
Why do you feel it will break their code? If it does, they have the option to
either update their driver to match the new code or fork off the old code &
continue to use that. I wouldn't be suprised if they've already constructed a
fork at some point, as they seem to have done
Dave Airlie wrote:
Hi all,
I'm just wondering do we have a general feeling from a DRI
perspective on breaking the ATI driver (which is DRI based) from a drm
point of view,
From a kernel POV it isn't an issue, it seems to be an idea to break em
every so often just to keep them on their toes.
Adam Jackson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tuesday 24 August 2004 18:01, Ronny V. Vindenes wrote:
tir, 24,.08.2004 kl. 13.40 -0700, skrev Ian Romanick:
Ronny V. Vindenes wrote:
Of course, once we get to that point, I think we should get the existing
TCL paths and run every
Philipp Klaus Krause wrote:
Some time ago I sent patches that enable vertex program support
in the r200 driver (software only though) to this list.
Now I wonder if they will be integrated into the driver and how this
process works. Do the driver maintainers read this list, lok at the
patches and de
Dave Airlie wrote:
Previously all of the IOCTL calls were protected by the Big Kernel
Lock. If we break that aren't we allowing multiple callers into the
IOCTL code on SMP machines that weren't allowed in before? Doesn't
that mean that we have to check everything to make sure it is SMP
safe?
as Ala
Adam Jackson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Saturday 21 August 2004 13:11, Keith Whitwell wrote:
Adam Jackson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
We're getting an extensive amount of Wiki spam recently, from one
particular host. I'd like to hac
Adam Jackson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
We're getting an extensive amount of Wiki spam recently, from one particular
host. I'd like to hack moin.cgi a bit to blacklist this IP but since I'm not
listed as a Developer on the sourceforge page I can't ssh in.
Would one of
Sam Ravnborg wrote:
On Thu, Aug 19, 2004 at 03:26:07PM -0700, Erdi Chen wrote:
This patch adds two new ioctl's to the VIA Unichrome/Pro DRM driver:
DRM_IOCTL_VIA_DMA_INIT
DRM_IOCTL_VIA_CMDBUFFER
The first call sets up an area in AGP memory that will be used as the
ring buffer. The
Dave Airlie wrote:
That would be fine with me... Dave, AlanH, has the moment arrived?
Okay I'll stick with chopping it, what the best way to go about it - will
I just let it break naturally (that'll take about 5 mins...) or will I
actively remove it?
Removing it would be cleaner, but either way's
Alan Cox wrote:
On Mer, 2004-08-18 at 12:32, Keith Whitwell wrote:
Once again, I predict the gamma driver which reportedly doesn't work and
doesn't have any users will prove to be the stumbling block...
I would suggest the gamma driver is retired. And I think I say that as
about the
Dave Airlie wrote:
Okay take a look at
http://www.skynet.ie/~airlied/patches/dri/mtrr_removal.diff
This is how I intend dumping the __HAVE_ set of macros, I've just patched
the radeon in this patch.. any objections to this approach any neater ways
to do it?
Regards,
Dave.
This does make it a lot cl
Philipp Klaus Krause wrote:
How is functionality already implemented by Mesa added to a driver?
I want to try adding vertex program support to the r200 driver.
I took a look at the i915 driver to see what is done there. The
only things I could find where the added extensions in the extension
string
Brian Paul wrote:
Well, I could probably make the Mesa 6.1 release this weekend (since I
was planning on working anyway). I've got some memory leak fixes (see
bug 1002030) that I haven't checked into the trunk yet (but are checked
into the mesa_6_0_branch branch). I asked Kevin about checking
Brian Paul wrote:
At this point, given that the X.Org tree is still monolithic, our Mesa
usage is somewhat independent of Mesa releases in my view. I chose to
integrate the development branch because of the great advances made in
the DRI drivers in general (though we have some issues to resolve st
Arjan van de Ven wrote:
On Mon, Aug 16, 2004 at 12:42:51PM +0100, Keith Whitwell wrote:
Dave's hit the nail on the head here. If you'd like some changes, feel
free to make suggestions.
once the new intel DRM driver hits Linus' tree I want to start an experiment
to make it lo
Dave Airlie wrote:
DRM_IOCTL_ARGS, DRM_ERR, DRM_CURRENTPID, DRM_UDELAY, DRM_READMEMORYBARRIER,
DRM_COPY_FROM_USER_IOCTL etc etc existed prior to freebsd support? Oh my
god...
Heh. I actually find those ones pretty innocuous and easy to work with,
compared to some of the stuff in there. Nothing t
Arjan van de Ven wrote:
On Mon, Aug 16, 2004 at 10:43:34AM +0100, Keith Whitwell wrote:
If we can manage to support FreeBSD and Linux from one codebase, surely
supporting 2.4 and 2.6 isn't too difficult?
It for sure is possible.
However the DRM codebase proves that it's incapable of
Arjan van de Ven wrote:
On Mon, 2004-08-16 at 07:56, Dave Airlie wrote:
At the moment we are adding a lot of 2.6 stuff to the DRM under
development in the DRM CVS tree and what will be merged into the -mm and
Linus trees eventually, this has meant ifdefing stuff out so 2.4 will
still work,
which i
Philipp Klaus Krause wrote:
Since the driver supports GL_NV_texture_retangle,
GL_EXT_texture_retangle and probably soon will GL_ARB_texture_retangle
I wonder why GL_ARB_texture_non_power_of_two isn't supported.
Because nobody's done the work to support it. It shouldn't be that hard - the
main dif
Alexey Dokuchaev wrote:
On Thu, Aug 12, 2004 at 03:49:14PM +0700, Alexey Dokuchaev wrote:
On Thu, Aug 12, 2004 at 08:48:09AM +0100, Keith Whitwell wrote:
John Baldwin wrote:
On Wednesday 11 August 2004 07:07 am, Alexey Dokuchaev wrote:
Hi there,
Judging from /sys/dev/drm/ contents, and listed
Alexey Dokuchaev wrote:
On Thu, Aug 12, 2004 at 08:48:09AM +0100, Keith Whitwell wrote:
John Baldwin wrote:
On Wednesday 11 August 2004 07:07 am, Alexey Dokuchaev wrote:
Hi there,
Judging from /sys/dev/drm/ contents, and listed kernel options in NOTES,
there's currently evidence of suppor
Dave Airlie wrote:
Okay I've gotten myself a 9200 card that can do 8x, and I've a
motherboard that can do it.. now I know some people will tell me 8x is of
no practical use (but then neither is my mach64 :-)
I spotted a patch from Hui Yu via Michael at
http://penguinppc.org/~daenzer/DRI/radeon-agp8
Alexey Dokuchaev wrote:
On Wed, Aug 11, 2004 at 12:20:11PM -0400, John Baldwin wrote:
On Wednesday 11 August 2004 07:07 am, Alexey Dokuchaev wrote:
Hi there,
Judging from /sys/dev/drm/ contents, and listed kernel options in NOTES,
there's currently evidence of support for i810/830 chips in FreeBSD,
John Baldwin wrote:
On Wednesday 11 August 2004 07:07 am, Alexey Dokuchaev wrote:
Hi there,
Judging from /sys/dev/drm/ contents, and listed kernel options in NOTES,
there's currently evidence of support for i810/830 chips in FreeBSD,
which (I suspect) is the probable reason why DRI is not enabled o
Alan Cox wrote:
On Mer, 2004-08-11 at 01:29, Dave Airlie wrote:
Can the VIA DRI stuff get pushed through to the kernel with the S3
stuff please, even if we mark VIA as experimental
the DRM stuff? We need to mark as insecure, I really don't want anything
that the authors consider insecure to go anyw
Dave Airlie wrote:
The latest patch against the drmfntbl-0-0-1 branch of the DRM is at
http://www.skynet.ie/~airlied/patches/dri/drm_ftbl_latest.diff
This will be checked into the branch when fd.o gets sorted out...
It dumps:
DRIVER_CTX_[CD]TOR
HAVE_KERNEL_CTX_SWITCH
DRIVER_BUF_PRIV_T
DRIVER_AGP_BU
The key here is that distributions release new kernels at a rapid pace.
This is not X where we get a new release every five years. The standard
mechanism for upgrading device drivers in Linux is to add them to the
kernel and wait for a release.
So, people have to reboot to install a new graphics
Jon Smirl wrote:
--- Keith Whitwell <[EMAIL PROTECTED]> wrote:
Ian Romanick wrote:
Jon Smirl wrote:
The only case I see a problem is when drm-core is compiled into
the kernel. Why don't we just change the Makefile to default to
copying the CVS code into the kernel source tree and tel
Ian Romanick wrote:
Jon Smirl wrote:
The only case I see a problem is when drm-core is compiled into the
kernel. Why don't we just change the Makefile to default to copying the
CVS code into the kernel source tree and tell the user to rebuild his
kernel?
I don't think that will fly with Joe-user
Dave Airlie wrote:
Just wondering what peoples opinions on dropping some of the myriad of
typedefs in the DRM? I know the kernel has try to this direction of late,
should we follow?
I'd rather just use struct drm_device * instead of drm_device_t * ...
Oh, yes please, please remove them.
Keith
Dave Airlie wrote:
Keith,
Have Intel supplied you with any info on the zone rendering stuff
in their chipsets or if we can avail of it .. it sounds like it might be
worth a frame or two ...
I had access to it for i915, I don't think they had any issues with it. It
does look like a fair bi
Ian Romanick wrote:
Keith Whitwell wrote:
We've actually managed to do a fair bit of cleanup already - if you
look at the gamma driver, there's a lot of stuff in there which used
to be shared but ifdef'ed out between all the drivers. The
__HAVE_MULTIPLE_DMA_QUEUES macro is a
Dave Airlie wrote:
Have you been able to run the version on the i865 branch?
I've just been comparing the branchs at source level, I'm not sure I have
a DDX for FreeBSD that will use it ...
The whole tree should compile & install just fine off that branch...
shouldn't it?
Keith
Dave Airlie wrote:
Okay now I've gotten it to probe my i865 but X kills it stone dead.. I've
checked in the changes..
Have you been able to run the version on the i865 branch?
Keith
---
This SF.Net email is sponsored by OSTG. Have you noticed the
Dave Airlie wrote:
Okay at
http://www.skynet.ie/~airlied/patches/dri/drm_fn_tbl.diff
is my first attempt at swatting the low hanging fruit in the DRM,
this moves the driver macros into a function table which the driver can
work off.. i've only done the radeon on Linux (no point going too far
withou
Ian Romanick wrote:
I think this is the right place to start. A couple of these look easier
to get rid of than others. __HAVE_MTRR and __HAVE_AGP are enabled in
every driver except ffb. It should be easy enough to get rid of them.
It looks like __HAVE_RELEASE, __HAVE_DMA_READY, __HAVE_DMA_FLU
ian: what about splitting the current memory management code into a
module that can be swapped for your new version?
AFAIK, the only drivers that have any sort of in-kernel memory manager
are the radeon (only used by the R200 driver) and i830. That memory
manager only exists to support an NV_v
Philipp Klaus Krause wrote:
Since the drivers have to use software fallback instead of
hardware tcl in some cases anyways, why don't they expose
GL_ARB_vertex_blend and GL_ARB_vertex_program?
No reason not to. Bear in mind that our current implementations of these are
less optimized than the hard
Dave Airlie wrote:
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?
Oh, yes. This is something you need to look at. The
Adam Jackson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Friday 23 July 2004 00:04, Eric Anholt wrote:
The point is that the DRI is merging into X.Org and there won't be a
separate tree any more. I still need to merge the development drivers
(mach64, savage), but my testbox is down due
Adam Jackson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've got DRI and GLX working with the libdl module loader under current Xorg
CVS. It works well enough to run glxgears (both direct and indirect) and
quake3. The patch isn't quite finished, for two reasons. One, and rather
triv
Jon Smirl wrote:
Context creation in DRM is marked as needing root access. Is this to
prevent a process from doing a DOS attack by creating too many
contexts? Couldn't I do the same DOS attack simply by creating lots of
processes each with their own context?
Is there a hardware limit on contexts? I
Mike A. Harris wrote:
On Fri, 16 Jul 2004, Alex Deucher wrote:
Date: Fri, 16 Jul 2004 09:06:26 -0400
From: Alex Deucher <[EMAIL PROTECTED]>
To: Dave Airlie <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Content-Type: text/plain; charset=US-ASCII
X-BeenThere: [EMAIL PROTECTED]
Subject: Re: i830 driver s
Dave Airlie wrote:
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 s
Roland Scheidegger wrote:
Thomas Hellström wrote:
Hi!
I'm trying to compile the unichrome_dri.so driver in the xc tree with
latest Mesa cvs. When the driver is loaded I get a missing symbol
_tnl_init_c_codegen.
Something new I've left out?
I've get that for r200 too. Seems to be related to the
Sasayama wrote:
> Is there any free test suite for OpenGL? We'd like to test our DRI
> implementation, but don't need a trademark license at this time.
glean.sf.net
Keith
---
This SF.Net email sponsored by Black Hat Briefings & Training.
Atte
Eric Anholt wrote:
I am definitely in favor of the DRI X tree stuff being a branch on the
X.Org tree.
I'd prefer to look at it slightly differently:
1) I'd like to get the current work in the DRI tree to a stable state, meaning:
a) finish (or part finish) Ian's NEW_INTERFACE work
b) import a stab
Dave Airlie wrote:
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
José Fonseca wrote:
Dave,
On Wed, Jun 09, 2004 at 06:48:10AM +0100, Dave Airlie wrote:
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 f
Keith Whitwell wrote:
OK, the 3D and drm components are in CVS now. It'll be a little while
before it can be used by anyone as we need to get the DDX changes in
somewhere as well.
It's worth a look. Some features include:
- Fragment programs in hardware
- All GL rasterizatio
OK, the 3D and drm components are in CVS now. It'll be a little while before
it can be used by anyone as we need to get the DDX changes in somewhere as well.
It's worth a look. Some features include:
- Fragment programs in hardware
- All GL rasterization proceeds through some sort of fragment
Dave Airlie wrote:
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 t
Roland Scheidegger wrote:
So, when I updated radeon_maos_arrays.c and compiled that (btw really
brave souls can try it out, just define RADEON_OLD_PACKETS to 0 in
radeon_context.h and RADEON_MAOS_VERTS to 0 in radeon_maos.c, that
codepath was only enabled in april 2002 for 9 days and probably ca
Dave Airlie wrote:
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.
http://dri.sourceforge.net/doc/
Jon Smirl wrote:
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
Here's the deal. glXGetProcAddress *NEVER* returns NULL. It returns a
pointer to a dispatch function. If you request an unknown function, it
will dynamically generate a dispatch for it. Try calling
'glXGetProcAddressARB((const GLub
Alex Deucher wrote:
--- Keith Whitwell <[EMAIL PROTECTED]> wrote:
Jon Smirl wrote:
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
I'm going to try and wrap up the remaining issues preventing a
single
driver binary. As part of that, I'm going to move the Mesa copies
Keith Whitwell wrote:
Jon Smirl wrote:
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
I'm going to try and wrap up the remaining issues preventing a single
driver binary. As part of that, I'm going to move the Mesa copies of
dri_util.[ch] and glcontextmodes.[ch]. I'm also goi
Jon Smirl wrote:
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
I'm going to try and wrap up the remaining issues preventing a single
driver binary. As part of that, I'm going to move the Mesa copies of
dri_util.[ch] and glcontextmodes.[ch]. I'm also going to remove the DRI
copies. Since dri_uti
Vladimir Dergachev wrote:
Hi Nikolai,
I merged your patches - thank you very much !
I wonder if a similar approach could allow us to reset the radeon/r200 after
lockups?
There's historically been code which tried to do that, but it just never ever
worked...
Keith
Eric Anholt wrote:
I think I've noticed a problem in i830_tris.c, in i830RenderStart.
Let's say you've got fog turned on but not specular. Then v0 has
VRTX_HAS_SPEC set, and you're emitting the fog factor and a 3-byte pad.
If you then turn on specular, v0 still has VRTX_HAS_SPEC set, so the
test
André Ventura Lemos wrote:
On Mon, 2004-05-24 at 11:15, Dave Airlie wrote:
doesn't happen for me,
00:02.0 VGA compatible controller: Intel Corp. 82865G Integrated Graphics
Device (rev 02)
:00:02.1 Display controller: Intel Corp. 82852/855GM Integrated
Graphics Device (rev 02)
[drm] Initializ
Mike Mestnik wrote:
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
Assembly dispatch stubs are only generated for x86 and SPARC. It looks
like the #if test in dispatch.c is wrong, so that stubs don't even get
used on SPARC. In any case, Jakub's patch did modify the x86 assembly,
not the C version
Ian Romanick wrote:
Keith Whitwell wrote:
Ian Romanick wrote:
One thing about Jakub's patch is that, on x86, it eliminates the need
for the specialized _ts_* versions of the dispatch functions. It
basically converts the DISPATCH macro (as used in
src/mesa/main/dispatch.c) from:
#d
Alan Cox wrote:
On Gwe, 2004-05-21 at 17:48, Jon Smirl wrote:
There are two types of VTs - text and graphical. It is only practical to have a
single graphical VT because of the complexity of state swapping a graphical VT
at VT swap.
Could have fooled me. I can switch between multiple DRI using X s
Ian Romanick wrote:
One thing about Jakub's patch is that, on x86, it eliminates the need
for the specialized _ts_* versions of the dispatch functions. It
basically converts the DISPATCH macro (as used in
src/mesa/main/dispatch.c) from:
#define DISPATCH(FUNC, ARGS, MESSAGE) \
(_glapi_Dispa
André Ventura Lemos wrote:
Not at all...
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.
On Fri, 2004-05-21 at 18:07, Keith Whitwell wrote:
Do you mind if I take this to dri-devel?
What happens
Also, when the VT is switched away from the X server, I believe that the
hardware lock remains grabbed - for minutes or hours at a time.
This is a multi-user OS bug. I'l not even pretend it's a feature that we
should keep.
Just making you aware of the issues.
Keith
--
Mike Mestnik wrote:
Lets just say that this is good fault tolorance. What ever can go wrong
will, all drivers are faulty. This sounds like a good idea and should be
implemented for ordinary use or something like it.
Unless you thing we should KP on a lock being held for more then a given
time(30
Nicolai Haehnle wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It seems to me as if DRM(unlock) in drm_drv.h unlocks without checking
whether the caller actually holds the global lock. There is no
LOCK_TEST_WITH_RETURN or similar, and the helper function lock_transfer has
no check in it ei
Michel DÃnzer wrote:
On Sat, 2004-05-22 at 01:45, Mike Mestnik wrote:
--- Jon Smirl <[EMAIL PROTECTED]> wrote:
There are two types of VTs - text and graphical. It is only practical to
have a
single graphical VT because of the complexity of state swapping a
graphical VT
at VT swap.
Right now we can
Alan Hourihane wrote:
I emailed Keith regarding this a while back and he had some concerns
over the patches used, but I just wanted to bring to light both RedHat
and now Mandrake are shipping with the TLS versions of libGL and cause
the binary DRI packages to break.
Is there someone looking to inte
Holger Waechtler wrote:
Keith Whitwell wrote:
I don't think this needs to be that complex. We only need a few
working functions in the kernel:
* identification (In particular unique identifier to pass via X to
apps
so they can find the head again)
* event reporting (i.e. IRQ
I don't think this needs to be that complex. We only need a few working
functions in the kernel:
* identification (In particular unique identifier to pass via X to apps
so they can find the head again)
* event reporting (i.e. IRQs and anything else that is relevant)
* mode setting
*
Dave Airlie wrote:
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 sur
Jon Smirl wrote:
I'm looking at the OpenML spec and it covers the areas that we have been
discussing plus a lot more. But the Khronos Group doesn't appear to be very Open
Source friendly. It seems that I have to apply for membership and return signed
documents to get a Linux SDK. But some of thei
Jon Smirl wrote:
I'm looking at the OpenML spec and it covers the areas that we have been
discussing plus a lot more. But the Khronos Group doesn't appear to be very Open
Source friendly. It seems that I have to apply for membership and return signed
documents to get a Linux SDK. But some of thei
As I've said, I don't have a deep grasp of the requirements of a putative
future mode-setting API, but in the course of other reading I came across
MLdc, which is a part of the OpenML environment. This is a library API which
seems to give comprehensive control of mode-setting to an application,
Brian Paul wrote:
I guess I don't feel to strongly about the Mesa bug database. The
SourceForge tracker has been good enough for me but others much prefer
Bugzilla. I could move to Bugzilla if that's the concensus.
Keith?
Bugzilla's certainly the more usable system, but my feelings one way or
Ian Romanick wrote:
James Simmons wrote:
1: Design must provide a mechanism for basic mode setting in a
device independent manner from an application with user level
permissions. ("Basic" to be defined)
Ug. I see I'm fighting a losing battle but it doesn't matter. I
couldn't never win this figh
Sottek, Matthew J wrote:
Sottek, Matthew J writes:
I agree. I think we are on the same page. A minimal set of features
is
all that would be part of the defined mode setting API. It is just a
question of if some of the multi-head concepts are generic enough to
be part of that defined set.
That's e
Martin Spott wrote:
Vladimir Dergachev wrote:
Also, I would venture an opinion that, at the moment, the only Unices we
care about is Linux, BSD and Hurd - all open source. The current design
of XFree86 (with everything done in userspace) was motivated by the need
to support commercial Unices (li
Jon Smirl wrote:
--- Jens Owen <[EMAIL PROTECTED]> wrote:
Six years ago, most devices could not handle this type of restriction
efficiently. Things have improved on the high end; but the low end
devices, are still very similar to what we had back in the day. Even
today, I would be very cautio
Ian Romanick wrote:
Ian Romanick wrote:
The one caveat with this patch is the x86 & SSE codegen is disabled
for all TexCoord and MultiTexCoord commands. If you look at the
changes to r200_vtxfmt_c.c, you'll see that I had to make some changes
to the way those routines work.
The previous patc
301 - 400 of 1643 matches
Mail list logo
