[Dri-devel] Re: User sponsored drivers
On Tue, 15 Jul 2003, Alex Deucher wrote: This proposal comes up periodically on this and other xfree lists, but never really goes anywhere. Why not raise money from the open source community to fund open source driver development? It is very difficult to convert money into code. It's probably easier to raise the money than it is to find a way to convert that into code. Mark. --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [forum] Re: [XFree86] Invitation for public discussion aboutthe future of X
On Thu, 20 Mar 2003, Alan Hourihane wrote: On Thu, Mar 20, 2003 at 11:37:34 +, Keith Whitwell wrote: XFree86 BOD wrote: It has been brought to the attention of the XFree86 Core Team that one of its members, Keith Packard, has been actively (but privately) seeking out support for a fork of XFree86 that would be led by himself. He is also in the process of forming a by-invitation-only group of vested interests to discuss privately concerns he has about XFree86 and the future of X. He has consistently refused to even disclose these concerns within the context of the XFree86 Core Team, which makes his membership of that team unviable. As a consequence, Keith Packard is no longer a member of the XFree86 Core Team. What specifically does the XFree86 bod see as being wrong with the idea of a 'by-invitation-only group' managing X server development? Isn't that exactly what the core team xfree86 BOD have been doing all along? Not exactly. Long ago, that was probably right, but these days you could probably see the Core Team as a bunch of committers to the CVS, obviously with their own areas of technical knowledge as well. And yes, we've met on occasion, but more in the reality of a coding frenzy to work on what we wanted to work on. More recently to talk about XFree86 5.0, of which I've sent what I wrote down to this list already. As for the BOD list, the Core Team doesn't know what goes on within that list either, not that it bothers me at all. The secret society aspect of the core and BOD is really not accurate. It's not really clear to me that our BOD does anything at all. In fact, other than the recent business with Keith Packard, the last time I remember them doing anything was the statement on XFree86's official opinion on the X.org X11R6 licesing fiasco. I don't see how any publicly elected BOD is going to change anything. The simple matter is that there's seems little for an advisory board to do. I'd just assume keep our current useless BOD than get a new useless BOD. XFree86's direction IS dictated primarily by its contributors. The fact that it's not perceived that way is merely a marketing problem. I'm not being cynical. I just don't know how to communicate things in a way that's not direct so that's the way it comes out. I will second Alan's statement that the core is really not much more than the list of people which have CVS commit access. Being a core member is somewhat symbolic. It is granted only after a long history of significant (actually substantial is more accurate) contributions to the XFree86 project. There are more people being considered for core status now. Think of it as the five-year plaque. Personally I am in favor of changing the core structure to behave more like Linux kernel's lieutenants. It doesn't really change the operation of the core much - it mostly just changes the names you assign to it. In my opinion XFree86 behaves much like Linux kernel already, it's just that the execution is flawed, particuarlly where application of patches are concerned, and that's something I'd like to see us work on. Maybe the core team bod could explain what is being hinted as a new spirit of openness and how that is proposed to effect the XFree86 development process and strategy? Will it mean forinstance an end to the sort of behind-closed-doors discussions that appear to have lead to this announcement? You'd be surprised if you saw what is actually discussed on the Core Team lists. Not much at all, apart from recent events that led up to this email. I have to say, that a lot of the Core Team is still in the dark on why Keith decided to divert his attention away from XFree86 in the way that has transpired. We're as much in the dark as you Keith Whitwell (thought I'd better add your surname to avoid confusion). I too am in the dark. I do not understand why Keith Packard, a core member himself, chose to not use that position of influence within the XFree86 project to fix these problems. I don't see how a fork would do anything but cause resentment and deprive both projects of a focused effort. Please forgive my somewhat cynical tone... The best strategy to fight a fork would be to open up XFree thereby make forking unnecessary. It seems like that is whats being attempted, but can the leopard change its spots? Sometimes I wonder if it knows it has them. Apart from when I was a teenager, I can remember having spots. OK - some concrete proposals, with cynicism turned off: - Make BOD minutes public That would be good, if I knew there were any minutes, which I don't think there are. - Open all core team meetings to the public, and if feasible post minutes, transcripts or even audio feeds. As for my 'XFree86 5.0 TODO' email, that's what was intentional. - Extend CVS access to regular contributors. Use scripts or
Re: [Xpert]Re: [Dri-devel] r200 and libxaa
On Sun, 20 Oct 2002, Jens Owen wrote: José Fonseca wrote: On Wed, Oct 16, 2002 at 04:52:59PM +1000, Simon Bland wrote: I've seen ppl mention the libxaa.a from Fonseca seems to fix the problem with the screen blanking. Thing is I can't seem to find this libxaa.. Can anyone point me in the right direction for this? And can anyone confirm that this does seem to fix the screen blanking problem with the Radeon 8500. Initially I hosted on my website because there was no certain that it would help. But now that I know it does I've moved it to http://dri.sf.net/snapshots/extras/libxaa.a.bz2 and wrote a README.Sig11 on http://dri.sf.net/snapshots/ . Can anyone on Xpert comment on XAA binary incompatability? Does this just affect Forward compatability, i.e. older X environments with newer binary drivers? I don't know why you'd be using a different XAA module in the first place. There haven't been any known bugs in XAA in a long time. I'm not sure we have any compatibility rules for anything other than driver interfaces. XAA interacts with more than the driver, it interacts with other modules and the core server. There may be some explicit assumptions that you are not mixing core modules. Precautions have not been made to allow mixing of an XAA module with a server of a different vintage. As for drivers, you can use a driver older than the server and it will generally work. You can use a driver newer than the server only if the driver doesn't use any entry points or exports newer than the server, and even if that part is safe you usually need to pass the -ignoreABI flag. But I don't think we have any goals of binary compability between core modules. Mark. --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xpert]Re: [Dri-devel] r200 and libxaa
On 21 Oct 2002, Michel Dänzer wrote: On Mon, 2002-10-21 at 02:05, Jens Owen wrote: José Fonseca wrote: On Wed, Oct 16, 2002 at 04:52:59PM +1000, Simon Bland wrote: I've seen ppl mention the libxaa.a from Fonseca seems to fix the problem with the screen blanking. Thing is I can't seem to find this libxaa.. Can anyone point me in the right direction for this? And can anyone confirm that this does seem to fix the screen blanking problem with the Radeon 8500. Initially I hosted on my website because there was no certain that it would help. But now that I know it does I've moved it to http://dri.sf.net/snapshots/extras/libxaa.a.bz2 and wrote a README.Sig11 on http://dri.sf.net/snapshots/ . Can anyone on Xpert comment on XAA binary incompatability? Does this just affect Forward compatability, i.e. older X environments with newer binary drivers? The problem appeared when I merged radeon driver fixes by Kevin E. Martin from XFree86 CVS to DRI CVS. They involved adding new fields to the XaaInfoRec struct; the fact that they were added in the middle of that struct caused the DRI binary snapshots, which were built against the new version of that struct but ran with an XAA module built against the old version, to crash and burn. I moved the new fields to the end of the struct, bumped the minor XAA version and added code to the radeon driver to only access the new fields if it's dealing with the new XAA. That worked as expected when I tested it here by copying libxaa.a from my Debian 4.2 installation into my DRI tree, which makes me suspect that the remaining problem with the snapshots is due to toolchain incompatibilities or something along those lines. I don't know why people do this. This change just broke NVIDIA's and ATI's binary drivers too. Any changes to structures that are referenced by drivers need to go at the end of the structures. Mark. --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xpert]Re: [Dri-devel] r200 and libxaa
On Sun, 20 Oct 2002, Jens Owen wrote: Mark Vojkovich wrote: On 21 Oct 2002, Michel Dänzer wrote: The problem appeared when I merged radeon driver fixes by Kevin E. Martin from XFree86 CVS to DRI CVS. They involved adding new fields to the XaaInfoRec struct; the fact that they were added in the middle of that struct caused the DRI binary snapshots, which were built against the new version of that struct but ran with an XAA module built against the old version, to crash and burn. I moved the new fields to the end of the struct, bumped the minor XAA version and added code to the radeon driver to only access the new fields if it's dealing with the new XAA. That worked as expected when I tested it here by copying libxaa.a from my Debian 4.2 installation into my DRI tree, which makes me suspect that the remaining problem with the snapshots is due to toolchain incompatibilities or something along those lines. I don't know why people do this. This change just broke NVIDIA's and ATI's binary drivers too. Any changes to structures that are referenced by drivers need to go at the end of the structures. Mark, I'd like to see driver level binary compatability continue, too. I'm not certain if Michael's changes have made it back to XFree86's CVS. I posted to this thread (and copied Xpert) because I read some posts to dri-devel that implied Michel's fixes weren't enough to restore driver compatability (old drivers, new XFree86 core and modules). If I'm mistaken, please let us know. I just changed the header file in CVS to move the changes to the end. I think that's all that's needed to restore binary compatibility with the old XAA module. I don't see anything else in there that has changed recently that would break things. Mark. --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Xpert]XFree86 NDA documentation
On 30 Jan 2002, Jose Fonseca wrote: I've decided to add some pertinent comments from Mike Harris regarding the availability of documentation under NDA to the DRI Devel FAQ ( http://mefriss1.swan.ac.uk/~jfonseca/dri/faq/html/hardware.html#ATI-SPECS ) In the comments Mike makes strong reference to join as XFree86 developer as a mean to obtain NDA documentation that is shared to all XFree86 developers, but it was mentioned in the last IRC meeting that this is no longer true. The fact is that the XFree86 developer page (http://www.xfree.org/developer.html) makes no mention to this and I would like to know if this still holds true or not. At one time, the XFree86 project had some chip docs under NDA and you had to officially become an XFree86 member (join our corporation) to have access to it. Times have changed. I don't know of any documentation that the XFree86 project keeps that isn't available elsewhere. There are still alot of individuals and projects that have NDA'd documentation, but these are not NDAs with the XFree86 Project Inc. XFree86 doesn't really sign NDAs anymore because it hasn't been necessary. Mark. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Rage 128 + bttv patches
On Thu, 20 Sep 2001, Michel Dänzer wrote: [ CC: to Mark to get the most competent comments on XAA ] Gerd Knorr wrote: the indirect buffers aren't flushed often enough. When I move a window with amiwm, the contents don't move at first. Only when I move it again do the contents appear in the current place. A quick comparison with the Radeon code didn't reveal any obvious difference, so I wonder what's wrong? I've noticed this too. Very good visible with mutt, when walking the mail index up and down. Killing all x clients which update the screen regular intervals (xload, xclock + friends) gives even better results. The FLUSH_RING machro does submit the buffer to the kernel. It is used by R128CCEWaitForIdle, which in turn is hooked into XAAInfoRecPtr-Sync. Maybe this is simply the wrong place? Don't know much about the XAA architecture... Hmm, yes and no. XAAInfoRecPtr-Sync is used to synchronize between accelerator and CPU access to the framebuffer, so while R128CCEWaitForIdle looks good to me, it's never called as long as there is no CPU access to the framebuffer. Mark, is there a way to flush DMA buffers after a batch of XAA operations right now? If not, could it be added easily? Wrap the BlockHandler and flush there. It gets called before the X-server goes back to waiting on its file descriptors. Mark. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
