[Dri-devel] dri and gatos?
Hi! Is it possible to have both the video features of my aiw radeon working and the latest (tcl) 3d working at the same time? The two don't seem to want to work at the same time for me. Steven ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: tuxkart, and bug reports..
I thought I would add my vote to the whole debate about what to do with the mailing lists and SFBT. I would like both lists to continue and for their proper uses to be enforced. I am not a developer or even a power user. I just like knowing what is going on with the development. Having a clear definition of what is appropriate to the different lists makes it a lot easier for me to read only the mail I want and not have to sort my way through large amounts of junk that I have no intrest in and can't help anyway. As for the SFBT I think it should be trashed if it isn't going to be used properly. I went looking for a easy bug to try and fix a while back and every bug I looked at didn't even exist. I do think that if a better solution could be worked out a bug database would be a great resource. It is kind of hard to sort through all the dri-devel list archive to try and find a bug that hasen't been fixed. Just my 2 cents. Steven ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
I'm not a developer and I know nothing about XML and so have no real opinion as to what the file format should be. I am however woried about comments like the ones quoted below. The notion that users dont edit config files by hand may be all fine and good in the microsoft world but last time I checked I was using linux. You can't make the same assumptions about what users want to do as you can in the microsoft world. Most linux users are "power users" and want to have complete control over everything. 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 the config file should be a much bigger concern then having a multitued of configuration programs out there. Even the best config program will have it's limits and I for one don't want to be constrained by them. Sincerily, Steven Lilly Alan Cox wrote: XML printed sensibly is ok for human editing (not ideal). Users dont edit config files however they use apps to do this. and Users want config files that work, they expect to use applications to edit them, and they also expect things like downgrading to work with the same configuration file - which XML can do. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
Jamie Guinan wrote: On Tue, 28 Jan 2003, Steven Paul Lilly wrote: I'm not a developer and I know nothing about XML and so have no real opinion as to what the file format should be. I am however woried about comments like the ones quoted below. The notion that users dont edit config files by hand may be all fine and good in the microsoft world but last time I checked I was using linux. You can't make the same assumptions about what users want to do as you can in the microsoft world. Most linux users are "power users" and want to have complete control over everything. Thus limiting the pool of potential Linux users to the very small number of "power users". I never said anything about not allowing GUI config tools. My point is that you shouldn't mess with a good thing. Make all the GUI tools you want just don't try and force the use of them. Opening things up to smooth graphical configurators makes Linux attractive to more users, and yes, that includes users who just want their applications to work without wasting time in a text editor. But I'd rather see Linux become more widely adopted than stagnate in the backwaters (not that it isn't gaining popularity these days, but it could do even better). I hear Apple is using XML for most (all?) of the OSX config files - but its still FreeBSD underneath, so how does that hurt FreeBSD power users? 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 the config file should be a much bigger concern then having a multitued of configuration programs out there. Even the best config program will have it's limits and I for one don't want to be constrained by them. I can see 3 ways this can work out: 1) The new format is tolerably readable XML, and power users learn to see around/through/between the all <>'s. 2) An XF86Config-ish format is used, with an XML layer on top that some tool boils down to the XF86Config-ish format (I think the Red Hat printer config tools do something like this). DRI won't be any the wiser. 3) The inverse of [2], where the DRI format is XML, and a tool to convert from XF86Config-ish syntax to XML is created, just to make the power users happy. number 1 sounds best to me. 3 wouldn't really make me happy. If you think about it, what *really* matters is the bytes inside DRI. The XF86Config syntax is just sugar to make it easy to get the right values in there for people handy a text editor. An XML syntax is just different kind of sugar which makes it *trivial* to write tools for people handy with a mouse. Not to mention facilitating features like preventing invalid configurations from being saved, and other stuff that comes essentially free with XML. -Jamie [ crawls back into the woodwork...] Sincerily, Steven Lilly Alan Cox wrote: XML printed sensibly is ok for human editing (not ideal). Users dont edit config files however they use apps to do this. and Users want config files that work, they expect to use applications to edit them, and they also expect things like downgrading to work with the same configuration file - which XML can do. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Bug in compilation?
Arkadi Shishlov wrote: The DRI tree no longer contains all the X stuff it needs (hasn't for a long time, actually) to build but instead relies on it to be installed on the system. There is a small glitch with current DRI compilation setup. If ProjectRoot in (otherwise default) host.def is set to something other than /usr/X11R6, for example: #define ProjectRoot /home/arkadi/opt/X11R6-DRI-mesa-4-0-4-branch Why not just go into /home/arkadi/opt/X11R6-DRI-mesa-4-0-4-branch and do a lndir /usr/X11R6 make World fails because X server linking process asks for some static libraries using absolute patch. I don't have a log file right now, but I'm sure the libraries are libXdmcp.a and libXau.a. arkadi. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Context teardown
Will all this stuff about context teardown fix the problem I'm having with my glut based program that always gives me X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 144 (XFree86-DRI) Minor opcode of failed request: 9 () Value in failed request: 0x101 Serial number of failed request: 73 Current serial number in output stream: 73 when I exit? I'm using X compiled from the dri trunk about a week ago. I don't see this when direct rendering is disabled. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] spam collection of the past few days
Is this the kind of job that has to be done on a fixed schedual or can you just setup 3 or 4 people to do it as often as they can and hopefully it gets done often enough. I'm a student so free time tends to come in spurts. I wouldn't want to have a fixed schedual, like sort the mail every weekend, but most weekends, and weekdays for that matter, I should be able to spend some time at it. Steven > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Alexander Stohr > Sent: Tuesday, June 17, 2003 10:01 AM > To: Alan Hourihane; Keith Whitwell > Cc: Michel Dänzer; Dan; Alexander Stohr; > [EMAIL PROTECTED] > Subject: RE: [Dri-devel] spam collection of the past few days > > > > I've been a bit slack with it recently, so the numbers of > > posts have just > > been sitting there. You get daily reminders of how many are > > in the queue > > waiting for your attention too. But to be managed properly > you need to > > tend to them on a daily basis. > > > > Alan > > I have no problem taking over that job on regular workdays. > A second person would be helpfull to cover that thing on > weekends. -Alex. > > > --- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU > Hosting Partner. Refer Dedicated Servers. We Manage Them. You > Get 10% Monthly Commission! INetU Dedicated Managed Hosting > http://www.inetu.net/partner/index.php > > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/d> ri-devel > > --- > > Incoming mail is certified Virus Free. > Checked > by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.488 / Virus Database: 287 - Release Date: 6/5/2003 > > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.488 / Virus Database: 287 - Release Date: 6/5/2003 --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
