Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

On Tue, Oct 28, 2003 at 02:09:40PM -0800, Jon Smirl wrote: > Another possible solution to the boot time problem would be to write a > disposable device driver. The disposable driver would set the mode/EDID and run > the console until user mode started; then self destruct. that doesnt sound very a

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

On Mon, Oct 27, 2003 at 06:13:32PM -0800, Linus Torvalds wrote: >.. > So the thing should really just have > - discovery and attach/detach > - interrupt event notification (and it can't just be "an interrupt >happened" - the interrupt driver actually has to know enough to ACK the >inter

[Dri-devel] dri-solo?

I saw a few references to "dri-solo" on the mesa list, but didnt get to read much on what it actually is. What is it supposed to be? I grepped through some of the recent dri-devel IRC logs, but didnt see anything there either. --- This SF.net

Re: [Dri-devel] Re: [PATCH] CodingStyle fixes for drm_agpsupport

On Mon, Aug 11, 2003 at 10:59:41AM -0700, Larry McVoy wrote: >... > It is inconsistent, on purpose. It's essentially like perl's > > return unless pointer; > > which is a oneliner, almost like an assert(). perl is EEevil > Maybe this will help: I insist on braces on anything wi

Re: [Dri-devel] Re: [PATCH] CodingStyle fixes for drm_agpsupport

On Thu, Aug 14, 2003 at 07:47:11AM -0700, Larry McVoy wrote: > ... > Indeed I have. And there is a reason that we have a policy at BitMover > where "formatting changes" are prohibited and we make people redo their > changesets until they get them right. > > In other words, you are welcome to writ

Re: [Dri-devel] Re: Sorting PCI Radeons out from AGP Radeons

On Tue, Jul 29, 2003 at 09:44:48PM +0200, Michel Dänzer wrote: > The DDX driver needs to know to decide whether to enable the DRI with > PCI GART or disable it, but the kernel might be in a better position to > find out (though some XFree86 hackers might disagree :)... well, seeing as how using AG

Re: [Dri-devel] Configuration per application

On Tue, Jun 24, 2003 at 10:01:47PM +1000, Damien Miller wrote: > Felix Kühling wrote: > > Hi, > > > > I have some questions about OS specific ways to find out the name of a > > running programme outside function main. > > extern chat *__progname; > > works on OpenBSD, NetBSD and Linux. it defi

Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)

On Mon, Jun 02, 2003 at 09:14:23AM -0600, Jens Owen wrote: > > Modified files: > > xc/xc/lib/GL/mesa/src/drv/r200/: > > Imakefile.inc > > > > Revision ChangesPath > > 1.5 +1 -1 xc/xc/lib/GL/mesa/src/drv/r200/Imakefile.inc > > After doing a little diggi

Re: [Mesa3d-dev] Re: [Dri-devel] Mesa tree re-org

On Mon, Jun 02, 2003 at 05:29:54PM -0600, Brian Paul wrote: > Keith Whitwell wrote: >... > > One thing that is a bit confusing is that some drivers are just drivers, > > wheras others are combinations of drivers and window system interfaces. > > It would be nice to have just drivers here and mov

Re: [Dri-devel] Re: sched_yield()

On Thu, May 29, 2003 at 10:52:15PM -0700, Linus Torvalds wrote: > > On Thu, 29 May 2003, Ian Romanick wrote: > > > > You're right. We do _really_ want to use futex'es. However, I don't > > think they're available on *BSD or Solaris. > > ... > And once you have a nice wrapper and they look lik

Re: [Dri-devel] Re: SPAM : DRI Devel ratio

On Tue, May 27, 2003 at 09:38:31PM -0700, Russ Dill wrote: > I was being sarcastic, his message was encoded with koi8-r, which, along > with being html, is one of the indescriminate reasons people block email > (and get a good number of false positives) however, foreign language encoding is separa

Re: [Mesa3d-dev] Re: [Dri-devel] Re: [forum] Notes from a teleconference held 2003-3-27

On Fri, Apr 04, 2003 at 10:34:05PM +0100, Keith Whitwell wrote: > >[Philip Brown writes] > > So to truely create something akin to nvidia's UDA libs/interface, would > > involve porting support for 3d hardware currently handled by DRI, over to > > Mesa, and making mesa

Re: [Dri-devel] Re: [forum] Notes from a teleconference held 2003-3-27

On Fri, Apr 04, 2003 at 10:09:00PM +0100, Keith Whitwell wrote: > Philip Brown wrote: > > Are you perhaps envisioning pushing Mesa to evolve into something > > like the nvidia UDA API? Where there is suddenly a single, unified > > cross-hardware/OS platform for all 3d-acc

Re: [Dri-devel] Re: [forum] Notes from a teleconference held 2003-3-27

On Fri, Apr 04, 2003 at 08:43:31AM -0700, Jens Owen wrote: > Possible > Future: Mesa Tree -+--> XFree86 Tree > - API Focus|- X/3D Integration > - 3D HW Focus |- Complete Window System Focus > | > +--> Alternate

[Dri-devel] correction to utah-glx comparison

Sorry about the lag of this, but I never like to give out false information. So this is a correction to some things I said about utah-glx in the weekly dri-devel irc conference two weeks ago: utah-glx can handle multiple GLX contexts just fine. There is no extra code needed to be written for that

Re: [Dri-devel] UT2k3 playability status?

On Sun, Mar 30, 2003 at 02:27:46PM +0100, Ian Molton wrote: > Theres *TONS* of other hardware [than video cards] that has open source > drivers that *totally* rock. and the other hardware is a lot simpler to interface to. Kinda like the difference between writing a image display program, and writ

Re: [Dri-devel] Server-side GLX / DRI issues

On Wed, Mar 26, 2003 at 12:22:48PM -0800, Ian Romanick wrote: > ... The memory management code that is in the 3D driver (for doing > the allocations and communicating with the DRM) really has to be there. > Moving it into the X server would really hurt performance. There's > really only four

Re: [Dri-devel] Server-side GLX / DRI issues

On Wed, Mar 26, 2003 at 11:18:18AM -0800, Ian Romanick wrote: > Philip Brown wrote: > > > > > > New client comes in. Requests new corse chunk o' VRAM from GLX > > Oops. we've used up the 16 megs pre-allocated. > > Used to be 11 megs free, but X

Re: [Dri-devel] Server-side GLX / DRI issues

On Wed, Mar 26, 2003 at 09:14:37AM -0800, Ian Romanick wrote: > Philip Brown wrote: > > Consider the GLX_dri_reserve_mem as equivalent to sbrk() > > Then have a more local memory allocator for subdividing the large chunk. > > That's going to be a lot more efficient

Re: [Dri-devel] Server-side GLX / DRI issues

On Wed, Mar 26, 2003 at 12:10:48AM -0800, Ian Romanick wrote: > Philip Brown wrote: > > Well, okay, there needs to be a little extra handholding between server and > > client. So, you add a GLX_dri_reserve_mem extension or something that > > reserves video memory by proxy.

Re: [Dri-devel] Server-side GLX / DRI issues

On Tue, Mar 25, 2003 at 11:21:22PM -0800, Ian Romanick wrote: > Philip Brown wrote: > > On Tue, Mar 25, 2003 at 05:07:38PM -0800, Ian Romanick wrote: > >>The idea is that the X server and the 3D driver can use the same memory > >>manager for off-screen memory. That

Re: [Dri-devel] Server-side GLX / DRI issues

On Tue, Mar 25, 2003 at 05:07:38PM -0800, Ian Romanick wrote: > Philip Brown wrote: > > The core X server should not be making calls into extension modules. > > Extension modules should be making calls to xfree-exported functions. > > If there arent sufficient xfree-exported

Re: [Dri-devel] Server-side GLX / DRI issues

On Wed, Mar 26, 2003 at 12:37:08AM +, Alan Cox wrote: > On Tue, 2003-03-25 at 23:15, Philip Brown wrote: > > There are already AGP (and memory alloc) related calls in the X server > > framework; xf86BindGARTMemory(), xf86EnableAGP(), etc. > > > > The core X server

Re: [Dri-devel] Server-side GLX / DRI issues

On Tue, Mar 25, 2003 at 12:37:17PM -0800, Ian Romanick wrote: > > This could also pave the way for the X server to use the new memory > manager that is being developed. We could make some sort of a conduit > for the X server to call into the DRI driver to allocate graphics / AGP > memory. The

Re: [Dri-devel] Server-side GLX / DRI issues

On Tue, Mar 25, 2003 at 09:48:21PM +, Keith Whitwell wrote: > > Utah did have some stuff going for it. It was designed as a server-side-only > accelerated indirect renderer. My "innovation" was to figure out that the > client could pretty easily play a few linker tricks & load that ser

Re: [Dri-devel] Re: XFree86 bugzilla available

On Fri, Mar 21, 2003 at 10:28:03PM +0100, Michel Dänzer wrote: > On Fre, 2003-03-21 at 22:24, Philip Brown wrote: > > On Fri, Mar 21, 2003 at 09:45:40PM +0100, Michel Dänzer wrote: > > > >Jose Fonseca writes > > > > Also, what's the general mai

Re: [Dri-devel] Re: XFree86 bugzilla available

On Fri, Mar 21, 2003 at 09:45:40PM +0100, Michel Dänzer wrote: > >Jose Fonseca writes > > Also, what's the general mailing list one can subscribe to receive > > notifications everytime a bug is open? > > Currently [EMAIL PROTECTED] gets them all. [EMAIL PROTECTED] gets notification when a bug is

[Dri-devel] Re: XFree86 bugzilla available

On Thu, Mar 20, 2003 at 10:47:01PM +0200, Smitty wrote: > Hi Philip > > Are you going to put your time where your mouth is? > > I'm sure that having someone who looks after the admin of the > DRI project is a good idea. > > If only for the reason as having someone to fiddle with the > website,

Re: [Dri-devel] Re: [forum] Re: [XFree86] Invitation for public discussion about the future of X

On Thu, Mar 20, 2003 at 04:08:06PM +, Keith Whitwell wrote: > > From my selfish point of view, an XFree fork will put the DRI tree in a bit > of a difficult position - especially if the new fork gets significant distro > support and we have to somehow track both trees or go through yet anoth

Re: [Dri-devel] drmAddMap(xx,xx,xx,DRM_SHM) : "locked" ?

On Thu, Mar 20, 2003 at 10:34:11AM +, José Fonseca wrote: > On Wed, Mar 19, 2003 at 03:56:04PM -0800, Philip Brown wrote: > > I'd rather hear first what it is "supposed" to mean in the current > > implementations. The current docs say "locked in kernel memo

Re: [Dri-devel] Re: Re: XFree86 bugzilla available

On Thu, Mar 20, 2003 at 02:49:37PM +, Alan Cox wrote: >... > I guess they've been busy writing 3D drivers instead. If you know the > SF system well then this kind of info could be a real help I dont know it "well". I just poked around with it at admin-level for 10 minutes. It would be a good

Re: [Dri-devel] Re: Re: XFree86 bugzilla available

On Thu, Mar 20, 2003 at 08:14:33AM +, Keith Whitwell wrote: > > > Or, someone could just leave it as is, disable it and forget > > about it because sourceforge's bug tracking system sucks. [1] > > I don't think we ever found out how to disable it. Just another aspect of its > suckage - you

Re: [Dri-devel] Re: XFree86 bugzilla available

On Wed, Mar 19, 2003 at 09:26:21PM -0500, Mike A. Harris wrote: > ... > Bugzilla requires a valid authenticated login. Not possible to > do that with email->bugzilla at least currently. btw: I heard that some of the previously hashed out opposition to using the sourceforge bugtracker, was becaus

Re: [Dri-devel] Re: Re: XFree86 bugzilla available

On Wed, Mar 19, 2003 at 09:31:41PM -0500, Mike A. Harris wrote: > On Wed, 19 Mar 2003, Philip Brown wrote: > >Even if the decision stands to no longer field new bugs there, it would > >still be nice if someone cleaned out the bugs there that are no longer > >relevant.

Re: [Dri-devel] drmAddMap(xx,xx,xx,DRM_SHM) : "locked" ?

On Wed, Mar 19, 2003 at 11:46:13PM +, José Fonseca wrote: > On Thu, Mar 13, 2003 at 11:47:13PM -0800, Philip Brown wrote: > > The docs at > > http://dri.sourceforge.net/doc/drm_low_level.html > > > > say about drmAddMap(), for type DRM_SHM, > > > > &quo

Re: [Dri-devel] Re: XFree86 bugzilla available

On Wed, Mar 19, 2003 at 07:52:00PM +, Keith Whitwell wrote: > [...] > The sourceforge bug tracker is a broken pos. Yet tens, if not hundreds, of people seem to have reported bugs successfully with it against dri. Even if the decision stands to no longer field new bugs there, it would still be

Re: [Dri-devel] Re: XFree86 bugzilla available

On Wed, Mar 19, 2003 at 12:07:56PM +, José Fonseca wrote: > On Tue, Mar 18, 2003 at 08:04:22PM -0500, David Dawes wrote: > > An XFree86 bugzilla is now available at . > > Many thanks to Hewlett-Packard for supplying the hardware, netSweng for > > hosting, and the many

Re: [Dri-devel] using opengl without X or framebuffer

On Tue, Mar 18, 2003 at 05:46:55PM +0100, otherside wrote: > is there a way to do that ? > just open a screen (monitor) and then write to it. > i try to write a little library which opens the screen so you can draw > some polygons to it. > will DRI help me to do it ? Without a framebuffer, you ar

[Dri-devel] drmAddMap(xx,xx,xx,DRM_SHM) : "locked" ?

The docs at http://dri.sourceforge.net/doc/drm_low_level.html say about drmAddMap(), for type DRM_SHM, "A shared memory area of the requested size will be created and locked in kernel memory." Is that supposed to be the same thing as "locked in physical memory"? Because without specifying more

Re: [Dri-devel] patch for function naming consistency

On Wed, Mar 12, 2003 at 11:56:42PM +, Keith Whitwell wrote: > Well, I didn't have much to do with this code when it was written, but I'm > happy for it to stay where it is and as it is named for now. > > If someone wanted to take on a bigger task of comprehensively spring-cleaning > the rade

[Dri-devel] Re: patch for function naming consistency

On Wed, Mar 12, 2003 at 06:26:44PM -0500, Mike A. Harris wrote: > [] > IMHO, the names of functions and the file they are located in > should be based on the functionality that they are providing, and > should be grouped based on similar functionality and not based on > similarities in porti

Re: [Dri-devel] patch for function naming consistency

On Wed, Mar 12, 2003 at 10:21:17PM +0100, Michel Dänzer wrote: > On Mit, 2003-03-12 at 19:15, Philip Brown wrote: > > I just noticed that in drivers/ati, every single function related to DRI > > initialization,etc. is named RADEONDRIXxxxYyyy ... except > > RADEONPreInitDR

[Dri-devel] patch for function naming consistency

I just noticed that in drivers/ati, every single function related to DRI initialization,etc. is named RADEONDRIXxxxYyyy ... except RADEONPreInitDRI() Here's a patch to fix that, and R128PreInitDRI() I had to make the patch "by hand" this time, since cvs seems down or something. --- /tmp/radeon_

Re: [Dri-devel] drmScatterGatherAlloc missing from docs

On Wed, Mar 12, 2003 at 08:39:31AM +, Keith Whitwell wrote: > Philip Brown wrote: > > http://dri.sourceforge.net/doc/drm_low_level.html > > > > should be updated with a functional description of > > drmScatterGatherAlloc() > > Patches welcome... :-) > l

[Dri-devel] drmScatterGatherAlloc missing from docs

http://dri.sourceforge.net/doc/drm_low_level.html should be updated with a functional description of drmScatterGatherAlloc() [and probably a few other drmXXXYYY() routines that have appeared since 1999 ;-) ] --- This SF.net email is sponso

[Dri-devel] possible error in drm documentation, plus DMA question

I'm reading through http://dri.sourceforge.net/doc/drm_low_level.html int drmDMA(int fd, drmDMAReqPtr request) drmDMA can be used to reserve DMA buffers and to dispatch previously reserved DMA buffers. --

Re: [Dri-devel] C++ Framework Concern

On Wed, Mar 05, 2003 at 02:36:21PM -0800, Ian Romanick wrote: > I suppose that it is doable, but it just seems wrong. Doesn't this just > boil down to inheritance by conincidence? Expecting each driver to > duplicate the same data structures and add their unique data onto the > end, without an

Re: [Dri-devel] C++ Framework Concern

On Wed, Mar 05, 2003 at 01:08:52PM -0800, Ian Romanick wrote: > Philip Brown wrote: > > > > Also, rather than containing the struct, you could do what is done already > > in the drm level, with drm_map_t vs drm_local_map_t (and all over the X > > server code), and jus

Re: [Dri-devel] C++ Framework Concern

On Wed, Mar 05, 2003 at 10:04:40AM -0800, Ian Romanick wrote: > Philip Brown wrote: > > Are you saying that C++ somehow allows for more code sharing between > > drivers than straight ANSI C? > > It's not so much that it allows it as it makes it less painful. Look at

Re: [Dri-devel] C++ Framework Concern

On Tue, Mar 04, 2003 at 11:10:02PM -0800, Ian Romanick wrote: > Jens Owen wrote: > > Concern #3: Readability by the active contributors. I'm not the only > > old fuddy duddy in this group of developers. How much "readability" > > time do you figure the young C++ whipper snappers will save by

Re: [Dri-devel] 32/64bit issues in ioctl struct passing

> Wed, Mar 05, 2003 at 12:23:50AM +, Alan Cox wrote: > > "It works" is not the same as "it works cleanly". > > APIs should be fixed, concrete definitions. The struct definitions in drm.h > > are essentially part of the API (or ABI, whatever), and they are not fixed. > > They should be cleaned u

Re: [Dri-devel] DRM_READMEMORYBARRIER

On Tue, Mar 04, 2003 at 09:18:40PM +0100, Benjamin Herrenschmidt wrote: > > The purpose of this barrier isn not to ensure sequential access on > either the MMIO mapping (card registers) nor the actual ring buffer > memory mapping (could be IOs, or just real memory with PCI GART). > > It's here to

Re: [Dri-devel] 32/64bit issues in ioctl struct passing

On Tue, Mar 04, 2003 at 11:02:10PM +, Alan Cox wrote: > On Tue, 2003-03-04 at 18:12, Philip Brown wrote: > > All numeric fields passed through the ioctls, should have fixed, > > identifiable sizes. > > I guess you do need a typedef then so you can support solaris without

Re: [Dri-devel] 32/64bit issues in ioctl struct passing

On Tue, Mar 04, 2003 at 10:56:25AM -0800, Ian Romanick wrote: > Philip Brown wrote: > > So kernel will be compiled with offset=64bits, user mode will be compiled > > with offset=32bits... boom. > > > > All numeric fields passed through the ioctls, should have fi

Re: [Dri-devel] 32/64bit issues in ioctl struct passing

On Tue, Mar 04, 2003 at 11:59:50AM -0600, Andy Isaacson wrote: > On Tue, Mar 04, 2003 at 09:41:54AM -0800, Philip Brown wrote: > > On Tue, Mar 04, 2003 at 01:27:28PM +, Alan Cox wrote: > > > On all 64bit bit platforms I have met unsigned long is a 64bit quantity. > > &g

Re: [Dri-devel] 32/64bit issues in ioctl struct passing

On Tue, Mar 04, 2003 at 01:27:28PM +, Alan Cox wrote: > On Tue, 2003-03-04 at 08:22, Philip Brown wrote: > > "unsigned long" is semi-unspecified, but is reasonably assumed to be > > a 32-bit quantity. > > On all 64bit bit platforms I have met unsigned long i

[Dri-devel] 32/64bit issues in ioctl struct passing

As promised from the irc session... here's details on the little 32/64-bit issue I ran into. Its not quite a direct 32/64 bit thing in the drm itself exactly, but ambiguity can be a problem... drm_map_t.offset is "unsigned long". "unsigned long" is semi-unspecified, but is reasonably assumed t

Re: [Dri-devel] DRM_READMEMORYBARRIER

On Mon, Mar 03, 2003 at 05:42:24PM -0800, Alan Young wrote: > On Mon, 3 Mar 2003 10:48:54 -0800 Philip Brown <[EMAIL PROTECTED]> wrote: > > > > But anyway, sounds like I can NOP it out, I guess. > > You may be able to NOP it if your platform does not require

Re: [Dri-devel] Re: future of DRI? -> why no one plays with Glide3.

On Mon, Mar 03, 2003 at 02:58:01PM +, José Fonseca wrote: >... > An existing DRI driver has much more relevant information for a > developer than the hardware specs. except for the fact that the dri cvs tree, seems to have some sort of auto-applied "strip" for source code on commit. As "strip

Re: [Dri-devel] DRM_READMEMORYBARRIER

On Mon, Mar 03, 2003 at 02:48:32PM +0100, Michel Dänzer wrote: > ... > > Besides which, DRM(ioremap) seems to do the *actual* mapping to kernel > > space which still leaves the question of, what does > > DRM_READMEMORYBARRIER() do? > > As the name says, it issues a memory barrier. :) I beg to

[Dri-devel] DRM_READMEMORYBARRIER

Could someone explain what exactly DRM_READMEMORYBARRIER is supposed to do, in the kernel driver level, please? I was initially thinking that it did some kind of "enable bus memory mapping" OS call. However, it is used inconsistently. mga_drv.h and radeon_drv.h use it , each at only one place in

[Dri-devel] DRM_FREE patch

Okay Keith, here's a patch set for adding the extra size arg to DRM_FREE. (attached) It applies from the top of the 'os-support' directory. I generated it with "cvs diff -u". I believe GNU patch will ignore the extra cvs type stuff, but if not, lemme know. ? bsd/Makefile ? bsd/drm/Makefile ?

Re: [Dri-devel] Remote OpenGL

On Sun, Mar 02, 2003 at 10:33:15PM +, Martin Spott wrote: > Hello, did you know that remote display of OpenGL apps is partially > functional with DRI ? At least the client side works ! I'm currently running > FlightGear on a Linux PC against an SGI Octane functioning as X terminal. > Performanc

Re: [Dri-devel] cvs sponsor for portability patches

On Sun, Mar 02, 2003 at 08:20:52PM +, Keith Whitwell wrote: > Philip Brown wrote: > > The one nasty that I do see coming up, and I dont see an easy patch for, > > is DRM_MALLOC()/DRM_FREE() > > > > Solaris requires knowing the size of the kernel mem you are freein

Re: [Dri-devel] cvs sponsor for portability patches

On Sun, Mar 02, 2003 at 11:46:52AM +, Keith Whitwell wrote: > Philip Brown wrote: > > For example, I'd like to submit a patch set to fix the issue where > > there is _DRM_LOCK_IS_HELD() calls all over the place, but there really is > > only one syntax for it: >

Re: [Dri-devel] Re: future of DRI?

On Sun, Mar 02, 2003 at 02:26:04AM +, Alan Cox wrote: > People were saying that ten years ago. They were wrong > then, and I suspect they are wrong now. Too many people > think X11 == XFree86. XFree86 is an *implementation* > (arguably two with kdrive) of X11. Even ignoring kdrive, I'd call i

Re: [Dri-devel] Re: future of DRI? -> why no one plays with Glide3.

On Sun, Mar 02, 2003 at 12:57:42AM -0500, Daniel Vogel wrote: > I guess you also had to take away mandatory software fallbacks and the > imaging subset. In reality though, every IHV I've talked to stated their > OpenGL drivers being far more complex to maintain. > The question is does that real

[Dri-devel] cvs sponsor for portability patches

If I were to spend the time to put together some portability patches [for the kernel layer], would someone with cvs access volunteer interest to review and put them in? I can potentially see a bunch of little ones coming up, so rather than post every single one individually to the list, I thought

Re: [Dri-devel] Re: future of DRI? -> why no one plays with Glide3.

On Sat, Mar 01, 2003 at 03:05:37PM -0500, Mike A. Harris wrote: > On Sat, 1 Mar 2003, Smitty wrote: > >a V3 gets smacked around by a TNT2, > > Not with open source drivers it doesn't. got some specs on how the V3 performs, with glxgears? google only pulled up results from someone who said their

[Dri-devel] BSD kernel folks on here?

This the appropriate place to send suggestions about the bsd drm driver? There's an interesting amount of effort in the BSD side, to attempt to make a more portable framework. But it's missing a few things here and there. The first thing I've run into: there is #define DRM_OS_SPININIT(l,name) b

Re: [Dri-devel] future of DRI?

On Fri, Feb 28, 2003 at 10:29:04PM -0800, Ian Romanick wrote: > Daniel Vogel wrote: > > Does DRI have a future with neither NVIDIA nor ATI participating? > > Are people actually talking to them about why they don't use it and > > what has to be done to remedy this fact? Shouldn't this be a top prio

Re: [Dri-devel] future of DRI?

On Fri, Feb 28, 2003 at 05:15:58PM -0500, Daniel Vogel wrote: > > So, are there technical reasons for NVIDIA not to use the DRI if ATI does? > yes. NVIDIA already has their own cross-platform low level driver, with a cross-platform 3d API. It's their "UDI", Unified Driver Interface, or somethin

Re: [Dri-devel] Using DRI to implement 2D X drivers

On Fri, Feb 28, 2003 at 05:06:15PM +0100, Michel Dänzer wrote: > > I haven't look at this but if the DRM modules know > > about setting up the hardware and changing resolutions > > then there may be no need for framebuffer any more. > > You could write a generic framebuffer driver that was > > impl

Re: [Dri-devel] future of DRI?

On Fri, Feb 28, 2003 at 09:45:26PM +, José Fonseca wrote: > > Even if DRI stops being the main source of 3D drivers for Linux/BSD, it > will remain to be the main source of _open_source_ 3D drivers. That, > alone, gives DRI a competitive advantage over any other solution. Just > in the same wa

Re: [Dri-devel] Using DRI to implement 2D X drivers

On Thu, Feb 27, 2003 at 06:41:50PM -0800, Jon Smirl wrote: > > If 3D isn't important to a desktop, then why are my > windows stacked on top of each other? Why do my > buttons depress and my windows look like they have > raised borders? Edit boxes have shadows and menus look > like they raise when

[Dri-devel] question on kernel (dri)context switching

I'm wading through DRM context switches at the kernel level now. I've gotten lost a bit -- I'm missing a chunk o stuff at the (*) point. User wants a "context switch" to happen. Calls ioctl(DRM_IOCTL_SWITCH_CTX) Kernel goes into DRM(context_switch) Sets an internal "current context" Variable

Re: [Dri-devel] UT2003 crash with current trunk

On Thu, Feb 20, 2003 at 09:12:04PM +, Philip Armstrong wrote: > Using the debs at http://people.debian.org/~daenzer/dri-trunk-sid/ on > Debian unstable and the latest demo release of UT2003 (v2206 -- which > is purported to not need S3TC extensions), I get the following > traceback reported by

[Dri-devel] question on lightweight vs heavyweight locking

I've been reading http://dri.sourceforge.net/doc/hardware_locking_low_level.html and the code, obviously... so I've seen references to the "lightweight" lock. ButI have yet to figure out why there is one. The url document mentions that one supposedly exists, and that "the lightweight lock will no

[Dri-devel] sorry, ignore prev kernel message

Sorry, sorry.. missed seeing the bounds check, even though its right there. It's late where I am, and it's been a long day. --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor yo

[Dri-devel] possible kernel level robustness improvement

Just a suggestion that comes to mind as I'm crawling through the kernel-level code... [the xfree 4.2.0 version] but it looks to me like if userland passes in an incorrect context number in a call to DRM_IOCTL_LOCK, it could cause a kernel panic, due to no array bounds checking in drm_drv.h, DRM

Re: [Dri-devel] DRIInfoRec, Identifiers and DRI Configuration

On Mon, Feb 17, 2003 at 11:24:10AM -0800, Ian Romanick wrote: > >>So, what happens if I have four identical video cards in my system? > > > > why would you want different configs for them? > > There are probably as many different reasons as there are different > people that have such configurati

Re: [Dri-devel] DRIInfoRec, Identifiers and DRI Configuration

On Sun, Feb 16, 2003 at 10:52:34PM -0800, Ian Romanick wrote: > Philip Brown wrote: > > So, why not do it by PCI vendor/devid ? That sort of information is visible > > from the DRI level, I believe. I think its just another Xserver internal > > call, isnt it? > > So,

Re: [Dri-devel] DRIInfoRec, Identifiers and DRI Configuration

On Sun, Feb 16, 2003 at 05:55:55PM -0600, D. Hageman wrote: > > So, why not do it by PCI vendor/devid ? That sort of information is visible > > from the DRI level, I believe. I think its just another Xserver internal > > call, isnt it? > > I thought about PCI vendors/devid ... problem with that

Re: [Dri-devel] DRIInfoRec, Identifiers and DRI Configuration

On Sun, Feb 16, 2003 at 02:00:01PM -0600, D. Hageman wrote: > On Sat, 15 Feb 2003, Philip Brown wrote: > > I think this is a much cleaner overall design. > > After all, you dont open /dev/fbX and tell it, > > "I want you to be associated with this video card now...&q

Re: [Dri-devel] DRIInfoRec, Identifiers and DRI Configuration

On Sat, Feb 15, 2003 at 01:24:26PM -0600, D. Hageman wrote: >... We played around with using Screens and driver > names, but in the end we were looking at keying off the device identifier. > At this time I still believe that is the best thing to use, but we have > no way at this time of grabbin

Re: [Dri-devel] Security in new drivers

On Sat, Feb 15, 2003 at 01:51:57AM +, Alan Cox wrote: > On Fri, 2003-02-14 at 23:56, Philip Brown wrote: > > how is "only user joebrown can read and write /dev/dri/card0" any less > > effective when there are multiple users on the box ?? > > As well as the unix

Re: [Dri-devel] Security in new drivers

On Fri, Feb 14, 2003 at 03:23:07PM -0700, John Bartoszewski wrote: > On Fri, Feb 14, 2003 at 10:14:21PM +0100, Michel D?nzer wrote: > > Also keep in mind that access to the DRI can be controlled via ownership > > and permissions of the /dev/dri/cardX devices. > > On a private machine this is metho

[Dri-devel] CTX ioctl differences

Could someone please explain the difference between DRM_IOCTL_ADD_CTX vs DRM_IOCTL_NEW_CTX Then again, maybe DRM_IOCTL_NEW_CTX is more like DRM_IOCTL_SWITCH_CTX, reguardless of whether the name itself sounds more like ADD_CTX? --- This S

[Dri-devel] issue with DRM_IOCTL_SET_UNIQUE ioctl

I would like to request a fundamental change, to a minor part of the DRM API. I believe that the current semantics of ioctl(DRM_IOCTL_SET_UNIQUE) and ioctl(DRM_IOCTL_GET_UNIQUE), violate POSIX/SUS understanding of the ioctl command. To quote from the single unix specification version 2 (1997) htt

[Dri-devel] decoupling from xfree server code a little

I've been poking around the xfree86 server side of dri a bit ... eg: hw/xfree86/drivers/ati/radeon_dri.c and it occurs to me... why is this stuff in the core server? Why isnt it in the dri "module", rather than hacked into the main server? I've scanned through most of it, and it all looks like st

Re: [Dri-devel] Configuration file format survey

On Tue, Jan 28, 2003 at 09:56:09PM +, Sergey V. Oudaltsov wrote: > Hi > > Just one little XFree-related pro-XML story. Not from DRI, from XKB > life. You know, XKB configuration is generally held in > /usr/X11R6/lib/xkb directory and several subdirectories. All this would > be fine if the form

Re: [Dri-devel] Configuration file format survey

On Tue, Jan 28, 2003 at 03:51:26PM -0500, Jamie Guinan wrote: > >> If the XML can be kept relativly simple to read and edit then fine but >> the end user should never have to use a config tool if they don't want >> to. So please keep it as simple as possle. In my opinion the >> readability of

Re: [Dri-devel] Configuration file format survey

On Tue, Jan 28, 2003 at 01:22:55AM -0600, D. Hageman wrote: > ... > 2) The XF86Config file format does what it does very well. It isn't > necessarily what we are looking for. It also isn't exactly a library that > one can just use. It is a very custom built parser for a very specific > purpos

Re: [Dri-devel] Configuration file format survey

On Tue, Jan 28, 2003 at 07:22:33AM +0100, Sven Luther wrote: > > Another disadvantage is that parsing is so damn slow. Yeah, tell me about it. The place where I work had to buy some auxiliary processing boxes to augment the webservers. Black box "appliance" like things. SSL processing engines?

Re: [Dri-devel] Configuration file format survey

On Mon, Jan 27, 2003 at 10:37:06PM -0600, D. Hageman wrote: > On Mon, 27 Jan 2003, Philip Brown wrote: > > If you want to get experience/resume padding doing XML coding, please do it > > elsewhere. > > Please don't make this a personal attack. Public forums are not a

Re: [Dri-devel] Configuration file format survey

On Mon, Jan 27, 2003 at 06:04:19PM -0600, D. Hageman wrote: > > I think you misunderstand. We aren't replacing the XF86Config file here. > This is for DRI specific driver settings with capabilities extending to > having special options for individual programs if need be. > > Now if I am mis

Re: [Dri-devel] Configuration file format survey

On Mon, Jan 27, 2003 at 11:18:43PM +0100, Felix Kühling wrote: > If anyone has serious objections to XML, please let us know (mail to > dri-devel will suffice ;-). I object. Using xml inevitably leads to files that are completely human-unreadable, except perhaps to the original developers. Please

[Dri-devel] request for small DMA test

Would someone possibly do me the favour of either pointing me to a [very] small program that tests basic drm (Allocate DMA mem), (Read/Write DMA mem), (Free DMA mem) functionality, or, if you are feeling particularly generous,writing one? I'm not talking about excercising any specific video card

Re: [Dri-devel] patch for host.def

On Wed, Dec 18, 2002 at 12:57:45AM +, Alan Hourihane wrote: > > HasGlide3 is set to NO by default and only enabled on Linux with an i386 > or Alpha architecture. Good to know that it is fixed in later versions. I was using Solaris i386, so I was probably running afoul of old bad assumptions

Re: [Dri-devel] patch for host.def

On Wed, Dec 18, 2002 at 12:17:29AM +, Alan Hourihane wrote: > And which host.def is this a patch against ? It does not match the trunk's > versions at all. For a start there is no definition of LinuxDistribution > in the trunks host.def file. > > You shouldn't need OS level patches like this a

  1   2   >