[Dri-devel] Re: Typo on DRI website
Hi Liam, I think the site is ready for primetime. Do the transition all in one go when you are ready, if you need help let me know. One last comment I have, on the Contribute page, the Developer Documentation link should maybe link to an anchor on the docs page. That way the user doesn't have to scroll down to the developer docs after clicking on the link. Cheers, - Frank --- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Typo on DRI website
btw what about now? Much, much better. I have a few more comments though . ;) 1. For the mailing list info, there is a link to the old Geocrawler archives. I think that should probably be removed because SF.net has their own archives now and they also include the content from the old Geocrawler archives. You can already get to the SF.net archives by clicking on the mailing list name and then choosing archives on the following page. It might be nice to add an archive link right next to every mailing list, so for example: dri-devel [Archives] dri-user [Archives] Or just have the mailing list name and have Subscribe/Unsubscribe/Preferences/Achives next to it like SF.net does. You can just copy/paste their HTML code. 2. I really like the new font, it makes things a lot easier to read! But, the font in the left menu frame is not the same, that should be fixed. 3. On the status page you have the outstanding infrastructure status at the bottom. While that certainly is status information, I don't think it fits in with the other content of the page and is probably also not the kind of status information a user would be looking for. I suggest you move that information onto the contribute page and reorganize that page into the following topics/headings: a) We are looking for more developers : keep the first three paragraphs of the intro text as it is now. b) Where to get started? : link to the developer FAQ, pointer to mailing lists, link to IRC logs and time (just point to the FAQ questions) and link to documentation page. So basically the last 4 sentences from the current page. c) Outstanding Projects : the outstanding infrastructure status info, that would be useful for developers wondering what items still need to be done (aside from drivers of course). 4. Links on the links page should have target=_top or _new so that they don't open in a frame. The same goes for the links to the mailing lists and the links to other peoples pages on the Status page (Leif's page has the problem, I dunno about the others). 5. And my last major major gripe is the frame at the top with the big logo. It really does take up a lot of screenspace -- even at 1024x768. I really don't think it's necessary to have it there to remind people that they are on the DRI site. If you really really want to display the DRI logo I suggest two things: a) BEST --- just put the little DRI logo at the top of the left menu frame, like on the current site b) If you really want to have a big top logo on every page, insert it at the top of the page so I can scroll it out of view. Just modify the dri_header() code for that. Anyway, I think the site looks a lot better now. It's almost ready for primetime. Keep up the good work. Cheers, - Frank --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Typo on DRI website.
Hi Pawel, I think it is much too early for this kind of criticism. While the updated website is far from perfect and finished, I definetely think it is a clear improvement with respect to the former version. I don't see how it is too early for criticism. Liam has indicated several times that he would like to use the site update as is. If it is too early to criticize an apparently finished product, then when should I criticize it? A few other people had already raised the same issues as me even earlier in the game. I am simply trying to provide some _constructive_ criticism as to how the site update can be improved so that it can replace the current site. When I designed the current site it also didn't replace the previous site until all the problems had been adressed. it is important to get the message out Yes it is important to get the message out and that is what the mailing lists are for. I am pretty sure that anyone how follows dri-devel is aware of the site update. and I would consider any change that makes the website more alive (+the information can actually be found on it) a change for good. There are few things more discouraging that a unmaintained website. That's true and with my email I am trying to get things moving in that direction. If Liam would address the problems I mentioned, then maybe the site would go live soon. Some guys are trying to do something about it and IMO definetely deserve a credit for it. I do appreciate Liams effort and I am sure that everyone else does to. However, that doesn't mean I have to accept it as is, one must be allowed to make some constructive critisism. - Frank --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Typo on DRI website
Hello Ian, I would say that Effecting a full scale 'all in one go' transition is VERY hard. I would suggest letting Liam make the poage official, and continue refining the layout. I don't see how a transition in one go is very hard at all. The DRI website is fairly small, all you have to do is cut-n-paste the existing content and re-arrange it into new pages as you see fit. How do you think I made the current website? If you can't handle cutting and pasting, the you shouldn't be designing websites ... The original layout of content was so illogical that there is really no way to transition gradually and still have things make sense. Now you are contradicting yourself. You just said it was hard to make a transition in one go, now you say it is impossible to make a gradual transition. Which is it then? Liam is a braver man than I - I gave up after doing a significant amount of re-organisation, because I couldnt face the problem of doing a phased update. I don't think anyone wants a phased update. For a site as small as the DRI site, a one-go replacement makes sense. That is also what I told you originally when you asked me about it. I think that unless anyone has a MAJOR complaint about the new site, it should become the default. Well, I for one don't think so. The current site didn't replace the previous site until I had adressed all the problems people had with it. I went through several revisions of the site on a different server until it went live on dri.sf.net. I don't think the standards should be lowered just because you guys can't handle making revisions to the site before it goes live. And people do have major problems with it (at least me), in that I find the content organization even worse. See my original email with some ideas on how you can solve that problem. I must confess that I am not surprised that the developers have STILL not given Liam a complete list of supported features - despite being aske long ago by him, and several times, more recently by me. I must say that I am not surprised either. The developers have better things to do, such as actually working on the drivers (imagine that), than to compile lists of supported features. The DRI project as a whole suffers BADLY from a total lack of communication - partly caused by NDAs that should never have been settled for, keeping specs out of the hands of most developers, and partly caused by people working in ivory towers. I don't see a lack of communication at all, the dri-devel mailing list seems very much alive with ongoing discussions. At the point when VA exited from the Linux business, yeah I thought the project was in trouble. But since then people like Jose Fonseca and Leif Glass have put in a lot of effort to drive the volunteer/community side of the project forward. While the guys at Tungsten Graphics have put in a lot of work to keep the business side going. Mad props to all of them. ;) And yes, NDAs suck, but they're part of the harsh reality of this world. As Jose and Leif have shown, if you are really serious about becoming a developer you will be able to obtain documentation anyway. DRI is in serious trouble - NVidia did it alone, and I think the other manufacturers are aware of this. If the DRI project loses its USERS, then I think manufacturers will simply go elsewhere, or do it alone. I can't really comment on that, but from what I see here, DRI seems to be doing quite well. And one thing users WANT is a list of supported features for their card. You only need to look at the windows world - theres dozens of sites like Toms Hardware 'hot video card zone' 'video card shootout site blah blah'. And if anything, Un*x users are even MORE into knowing the specs and details of their system. Ah yes, the much discussed supported feature lists. While I was still actively maintaining the current site this issue came up a few times. I think in the end everyone decided that it is too much work to put together in the first place and even more so to maintain and keep current afterwards. On top of that, these users you always talk about: I have never actually received an email from them asking me about supported feature lists. I can download the linux kernel and Hack HAck Hack - its truely open, specs and all. I cannot do this with DRI - there are no specs. all I can do is poke blindly. As I said above, if you were really serious about becoming a developer you would be able to obtain documentation from the companies. Obviously you must be doing something wrong ... Cheers, - Frank --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Typo on DRI website.
Hi Liam, No offence intended but no, I just think the orignal site looks none too nice so does he AFAIK. None taken. Quite frankly (no pun intended) IRC logs are about the only thing out of place, and when I look at that page I wonder if I should remove them, however your idea to split documentation back out of help will draw attention back to them on that page meaning they can be safely removed. Ok, I would remove CVS and IRC Logs from that page. They should re-appear on the Contribute page. I must disagree on this point (I need persuasion perhaps a really good example / implementation where it works well) because help status pages are the longest pages they could benefit from it the most (at all) but I like your other suggestions so much that they are about to become shorter and the colour banding makes it a dead simple after that. If you don't want to add it then that's ok. But I still feel it is hard to get an overview of what one can find on a page. Another way to give a better overview might be to change the font to something more crisp and readable. I really like Arial or Helvetica for reading stuff on the web. You could also try increasing the font size by one. It would also be good if the titles for items on a page were a bigger font size, in addition to being bold/underlined. That would make them stand out a lot better. A few other things I can think of to change in the current site are: I think you misunderstood me, the points below apply to the current site, not your site update. They are just my ideas for what should change, but it appears you have already addressed a lot of them. I should have payed closer attention to your site update before writing them up. I'm sort of lost I understand the php header funcion and what it did / does but HTML headers? What I mean is that it should output the title for a page. On your site that would be the two horizontal bars with the title in between. So then the source for a page is basically: ? dri_header (Downloads); ? [ HTML content here ] ? dri_footer (); ? Then if you want to change the basic appearance of a page (title, header/footer) you can do it in those two functions. Also saves you from reusing the same header/footer HTML in every page over and over again. There is no About DRI page. There is currently What is the DRI text on the home page already. Junk on the home page? Please be more specific, there is obviously some confusion here are we looking at the same page? Sorry, I ment the current site, not your site update. However, looking at yours I think you should remove the stuff below the Mailing Lists section. It shouldn't really be necessary to explain the different links, I just put that on the original page as a filler. There is one downloads page already?? Although it does have IRC logs, and a CVS section (waiting on someone here). More confusion, same page? Yes, your Downloads page is good. I would remove CVS and IRC Logs. Also I would put the config files as the very last item, because I doubt many people downloads those. - remove the Report Problems stuff from the Help FAQ page since we don't use the SF.net bugtracker anyway. Will do, I read about this on the mailing list, but I'm not going to remove it just because I think nobody wants it. Thinking about this, a better idea might be to say that bugs should be reported on the dri-devel mailing list. If we do that and it results in too much traffic/crappy bug reports it can be removed later. But giving people some way to report bugs is probably a good idea. In the end this leaves us with these pages: 1. Home - with the About DRI text, a nice intro to the project I think this is how it is. 2. Status - the status of the hardware we support With 5 this is how it will be. 3. Downloads - downloads of drivers, kernel modules, and other files Pretty much identical already. 4. Documentation - all of our documentation for developers and end users This I like it was a dubious call to combine help faq documentation. 5. Contribute - information useful to developers I like this as well. 6. Help FAQ - the FAQ and links to the mailing lists and archives If 4. is done this is exactly how it will be. (in other words documentation is in there right now.) 7. Project - link to the project page Exactly as it is / was / always has been / will be. What I think - read the comments. That is how it was done I have various DRI sites eg new, old , update sitting on my HDD. Ok, I am glad we agree on the page layout. I must say I appreciate your input / opinions / requests if have been trying to obtain this sort of thing from people a while back I'd pretty much given up on getting any more than I already got. Great. I am happy you didn't take this as an insult. :) - Frank --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven.
[Dri-devel] Re: Typo on DRI website.
Two more things that really bug me... :) 1. The large top frame with the logo takes up a lot of screen space. I really don't think it's needed and it would look nicer if you removed it or made it smaller. 2. I think you should remove the border around the main logo on the home page. ie: border=0 for the IMG tag. - Frank --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Typo on DRI website.
That hasn't happened (accepted and moved) so I haven't asked. hint I think there is two problems here ... 1. Since this is an open-source project there is no single person to approve the website. Basically I don't think you will get 'approval' from the group as a whole until your new site has some major advantage that everyone is going to get excited about. Apparently right now this is not the case, either because nobody cares about the changes you are trying to make -or- because you haven't achieved those proposed changes in your site update ... 2. The main problem Ian Molton and you seem to have with the current site is that content is hard to find. That is probably a good point, but I think the way you have reorganized the content is even worse. I am looking at the your site update right now and every page is very long, with a multitude of things on a page - many of which don't really seem to be related. For example, on the downloads page IRC Meeting Logs and Binary Snapshots. Also, since the pages are very long it is hard to see what you can find on a page. Have you considered adding a horizontal line of content links to the top of the page? One link to an anchor for each major item on the page. I believe adding such a contents link line to the current site would make it much easier to navigate. For example on the current Help FAQ page there could be a line right below the title, with links to FAQ - Report Bugs - Mailing Lists. This makes it immediately obvious to anyone what they can find on that page, without having to scoll and potentially miss things. Removing the frames from the current page is also a no-brainer since the top and bottom links line for all major pages already exists. It is also easy to update those links if they change since they are inserted by a PHP header/footer function for each page. A few other things I can think of to change in the current site are: - make the PHP dri_header function output all HTML headers and the actual page title that is user visible. It doesn't do the latter right now cause I was being stupid. - put the What is the DRI text from the About DRI page on the home page. Remove the About DRI page and the existing junk on the home page. - combine the Resources and Downloads pages into one Downloads page with sections Binary Packages, Kernel Modules, Config Files, Other Libraries and Utilities Thereby remove the old kernel module sources from the new page. - add a new Contribute or Developer page that includes our call for developers from the Status page (remove that from the Status page), a link to the developer FAQ and our mailing lists, link to IRC meeting times and logs, links to the developer sections of the Documentation page. - remove the Report Problems stuff from the Help FAQ page since we don't use the SF.net bugtracker anyway. - add the content links line to each of these new pages. - remove the frames (if people really dislike them that much) In the end this leaves us with these pages: 1. Home - with the About DRI text, a nice intro to the project 2. Status - the status of the hardware we support 3. Downloads - downloads of drivers, kernel modules, and other files 4. Documentation - all of our documentation for developers and end users 5. Contribute - information useful to developers 6. Help FAQ - the FAQ and links to the mailing lists and archives 7. Project - link to the project page Ok. What do you think about that? How about changing the existing page instead of reinventing the wheel? In the time I wrote this email I could have probably done a fair bit of that work myself, but I don't have time to continuously maintain the site. It would be nice for someone to finally take over and after making those changes actively maintain the site and add some other cool features. I would also recommend that you work together with Nick Leippe. Cheers, - Frank --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Dri-devel digest, Vol 1 #1484 - 11 msgs
Hi Ian, to upload the new site you have to tar it up, then do the following: scp tarball.tar.gz [EMAIL PROTECTED]:/home/groups/d/dr/dri/htdocs/ Then login to dri.sf.net with ssh and your SF user id and untar the site into a temporary directory. Make sure its 'chmod a+r'. Cheers, - Frank On Sun, 2002-06-23 at 01:37, [EMAIL PROTECTED] wrote: Send Dri-devel mailing list submissions to [EMAIL PROTECTED] To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/dri-devel or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of Dri-devel digest... Today's Topics: 1. Re: radeon cvs problem (Keith Whitwell) 2. Re: radeon cvs problem (Dieter =?iso-8859-1?q?N=FCtzel?=) 3. radeon-20020621 install problem ([EMAIL PROTECTED]) 4. Radeon driver problem ... X dont satart! (thork) 5. website. (Ian Molton) 6. Re: website. (Jens Owen) 7. Re: How to trace switching to software rendering (Michael Schlueter) 8. Re: radeon drivers (tcl vs. non-tcl) (Zilvinas Valinskas) 9. Re: radeon drivers (tcl vs. non-tcl) (Zilvinas Valinskas) 10. Re: radeon cvs problem ([EMAIL PROTECTED]) 11. Mini HOWTO get extra ~30 fps with gears ... (Zilvinas Valinskas) --__--__-- Message: 1 Date: Sat, 22 Jun 2002 20:41:33 +0100 From: Keith Whitwell [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [Dri-devel] radeon cvs problem [EMAIL PROTECTED] wrote: If you're running XFree86 4.1, No, I'm running 4.2. Yesterday I bit the bullet and downloaded the entire source tree (quite an adventure down a phone line ...) and built from source. All worked fine this time, so there perhaps some problem with the binary packages on SF? Perhaps there's a dependence on an X11R6 module not included in the binary package? Anyhow, so now I have the radeon cvs built and working correctly, everything's wonderful (thanks to all the developers!) apart from an assertion failure I get repeatedly with our 3D ultrasound application (http://svr-www.eng.cam.ac.k/~rwp/stradx). It happens whenever I open a new window and make the new context current: radeon_vtxfmt.c:1039: radeonVtxfmtUnbindContext: Assertion `vb.context == ctx' failed. It doesn't happen with _every_ context switch, just with a particular pair of windows in the application - but it is repeatable with these two windows. The problem goes away with RADEON_NO_TCL=1 or RADEON_NO_VTXFMT=1, and doesn't appear with any other GL implementation we've tried (including mga dri). I'd be happy to test patches if anyone's interested in this one This is interesting. The code to cope with multiple contexts there hasn't had a huge amount of testing. If I download your code, how can I exercise this problem? Keith --__--__-- Message: 2 From: Dieter =?iso-8859-1?q?N=FCtzel?= [EMAIL PROTECTED] Organization: DN To: Keith Whitwell [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [Dri-devel] radeon cvs problem Date: Sat, 22 Jun 2002 21:55:15 +0200 Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] --Boundary-00=_30I4O4PKY8I7MKG15FFO Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit On Saturday 22 June 2002 21:41, Keith Whitwell wrote: [EMAIL PROTECTED] wrote: If you're running XFree86 4.1, No, I'm running 4.2. Yesterday I bit the bullet and downloaded the entire source tree (quite an adventure down a phone line ...) and built from source. All worked fine this time, so there perhaps some problem with the binary packages on SF? Perhaps there's a dependence on an X11R6 module not included in the binary package? Anyhow, so now I have the radeon cvs built and working correctly, everything's wonderful (thanks to all the developers!) apart from an assertion failure I get repeatedly with our 3D ultrasound application (http://svr-www.eng.cam.ac.k/~rwp/stradx). It happens whenever I open a new window and make the new context current: radeon_vtxfmt.c:1039: radeonVtxfmtUnbindContext: Assertion `vb.context == ctx' failed. It doesn't happen with _every_ context switch, just with a particular pair of windows in the application - but it is repeatable with these two windows. The problem goes away with RADEON_NO_TCL=1 or RADEON_NO_VTXFMT=1, and doesn't appear with any other GL implementation we've tried (including mga dri). I'd be happy to test patches if anyone's interested in this one This is interesting. The code to cope with multiple contexts there hasn't had a huge amount of testing. If I download your code, how can I exercise this problem? What about the cxbug.c
[Dri-devel] Re: Dri-devel digest, Vol 1 #1484 - 11 msgs
Oops, sorry for including all of the previous message in my reply. I probably shouldn't have sent this right after coming home from the pub! - Frank On Sun, 2002-06-23 at 02:06, Frank Worsley wrote: Hi Ian, to upload the new site you have to tar it up, then do the following: scp tarball.tar.gz [EMAIL PROTECTED]:/home/groups/d/dr/dri/htdocs/ Then login to dri.sf.net with ssh and your SF user id and untar the site into a temporary directory. Make sure its 'chmod a+r'. Cheers, - Frank --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRI website updated
So all the docs relating to DRI are on dri.sourceforge now? Yes. 1. Read through the FAQ comments and delete old/wrong/off-topic posts. There is a FAQ admin page that lets you delete comments. Anybody interested in doing this let me know and I will tell you how. This does not really need to be done, but it might be a good idea to clean up the comments. No, nobody has done this. I'm talking about the user faq. 2. Regarding the above, the FAQ admin page could be improved. Right now every comment has to be deleted by clicking a button. It would be nicer if you could mark comments to be deleted (via checkboxes) and then press one big button. Anybody that knows PHP and wants to tackle this, let me know. It would make task 1 much easier. Done. 3. It might be nice to put up a Links page with links to related projects/companies, such as: Xfree86, Mesa, FbDri, Precision Insight, Tungsten Graphics, Not done. 4. On the About DRI page it still says that the principal developers of the DRI are employed by VA Linux and a bunch of other VA Linux stuff. Anybody who can come up with an updated and nice sounding paragraph to replace that, send it in and I will put it up. Already done. - Frank ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRI website updated
I have layed out my new pages, and would like to upload them. can I get access to do this soon? I cant put a working mockup up until my server is back online - it is awaiting a USB card for the ADSL modem. Send me a tar file with your site and I will upload it to a subdir so everyone can check it out. If everyone agrees it's ready I will make it the main site. - Frank ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRI website updated
I thought from your earlier comment that you wer eno longer going to be running the site and that I would continue where you left off. Sure you can do that. But you have to get a SF account first and get added to the project. Talk to Daryll or one of the other admins about that. Until then I can upload your pages. I was going to do stuff like fill in links as I put the pages up. I suggest that you first assemble a complete site. Then everyone can review the complete site and once it's ready for primetime you can replace the current site as a whole. I don't think it's a good idea to replace individual pages one at a time. - Frank ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Website
Hi Jens, Ian and all ... I don't really care what anybody wants to do with the site. I don't have time (or much interest to be honest) to do anything more with it, other than to maintain it. So, if Ian wants to overhaul the whole thing, then he should go nuts. I've received emails from several other people promising to do the same, but then nothing came from it. It's going to be interesting to see if Ian will get it done. Basically, anyone can do whatever they want - but don't expect any help from me. :) - Frank P.S.: somebody else sent in this mockup for a new site, I guess you could use it for inspiration (not sure if the link still works): http://www.littledragon.f2s.com/pre/dri/ ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Extras package
The idea was that people who don't have XFree86 4.1 or later can just use the Extras package to upgrade their X server, instead of upgrading all of X. This worked pretty well in the past for people who had version problems with the X server being too old for the binary package. - Frank On Sat, 2002-04-20 at 02:13, José Fonseca wrote: On 2002.04.19 19:16 Frank Worsley wrote: Hi, I'm getting repeated emails from people asking for an extras package. Anybody want to volunteer to make one? All it needs to contain is an updated X server binary and a shell script that installs the binary and does suid root on it. - Frank I can add a script to build such a thing when the snapshots are being made. But what's the purpose of such a extras package? Excluding the driver modules the X server in the DRI CVS isn't changed except when is a new X release. José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Extras package
Hi, I'm getting repeated emails from people asking for an extras package. Anybody want to volunteer to make one? All it needs to contain is an updated X server binary and a shell script that installs the binary and does suid root on it. - Frank ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Announce] DRI-Devel-FAQ binary snapshots available from DRI website
You can now grab the snapshots directly by following the 'Download' link on the main DRI site. I have also updated the link for the FAQ on the documentation page to point to the new location. Cheers, - Frank ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [Announce] DRI-Devel-FAQ binary snapshots=?unknown?q?=C2=A0=3D=3FISO-8859-1=3FQ=3Favailable=3F=3D?= from DRI
I think that a README describing the general install/uninstall procedure and the state of the snapshots would be interesting indeed, and with a general note saying to never mix different drivers snapshots, i.e., always uninstall before installing a second one, as this would break the installation script (and covers the libGL case). You can find a README here: http://dri.sourceforge.net/doc/install_readme.txt I actually just emailed a note to Jens mentioning this too. :) - Frank ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [Announce] DRI-Devel-FAQ binary snapshots availablefrom DRI website
There is one thing though, the scripts are being added on a daily basis, and at some point in the future I'll add a cron job to delete all files older than, lets say, 1 month, to keep the DRI website under a reasonable size. Even if the 1 month example is too much, it's always good to have more than just the latest snapshot since the trunk could go havoc sometimes. Does the the dynamic HTML code in the download page handle this? It doesn't right now, but I will fix it so it only shows the most recent files. - Frank ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] unsubsrcibed from list
I have placed a link from the Doc page to your developer FAQ. The log of the second meeting as well as a breef summary was posted by Marcelo Magallon on the 28th. I think you should be able to pick it up on the archive. The archives don't do attachements. If somebody emails this to me I will add it to the website. - Frank ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] unsubsrcibed from list
Sounds good, have you seen the log of the first meeting I put at http://dri.sourceforge.net/DRI-IRC-meeting-20020121.txt ? Ok, I have added this. - Frank ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] unsubsrcibed from list
Ok, I will just put a link from the Documentation page to your website. That way you can just update the docs on your end. Is that ok? It would also be nice if the IRC meeting logs were available on the website. The easiest way would probably be to add a new FAQ section for that and add every new log as as question titled IRC Log from date. The first question in that section should probably be the schedule when the meetings take place. Anybody who attends the meetings and wants to post the logs let me know. - Frank On Wed, 2002-01-30 at 05:52, Jose Fonseca wrote: Frank, I've put up a developer FAQ for DRI. It's really just developer oriented so it's complementary to the existing FAQ. In the IRC meeting it was agreed that it should be on the DRI website and its source on CVS. Only the SGML source is on CVS. At this moment I still publicize in it that the most recent version is always available at http://mefriss1.swan.ac.uk/~jfonseca/dri/faq/ . I don't know if in the future we can arrange a way to keep everything in sync and change this. I would like to know what is your opinion about this. Regards, Jose Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] unsubsrcibed from list
Hi all, for some reason I got unsubscribed from the list when SF moved over to their new archives. If there was anything concerning the website that I missed please let me know. In any case, some people have stepped up to give the website a glorious new look. So, maybe in the coming months there will be a new website. I will keep you posted. :) Cheers, - Frank ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] website updated
How does the FAQ maintainer/moderator come to know what to put in the FAQ? You have to use your own judgement when it comes to this. If you see a frequently asked question while reading the mailing lists then it should probably go into the FAQ. :) FAQ comments are really intended for additional discussion of a FAQ answer or adding something useful to a question/answer. When posting a comment it says in bold letters that you should send problem reports and questions directly to the mailing lists - and *not* post them as FAQ comments. Therefore, I usually delete comments that fit any of the rules below: 1. Old, out of date or offtopic comments. 2. Comments that are a problem report or plea for help. 3. Questions as to when drivers will be released (see FAQ question #1, they usually get posted right there, although the FAQ answer says we don't announce release dates). 4. Generally rude or offensive comments (not very many of these luckily). 5. Comments complaining that we haven't released a specific driver. I don't appreciate it when people complain like that, if you don't like it then either help out or use Windows. However, I think it's OK to ask for a driver to be released or saying that you would really appreciate for a driver to be released. Use your own judgement when deciding if somebody is complaining or asking nicely. Anyway, this is just what I used to do. I haven't actually looked at the comments in a long time. Anybody interested in cleaning up, let me know. - Frank ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI website updated
Hi, I've updated the Documentation page of the website. I've copied all the docs from Precision Insight's Insight page and put them onto our site. The link to the Insight page has been removed. There are a couple of other tasks regarding the website that somebody might want to take care off... I don't really have the time right now. 1. Read through the FAQ comments and delete old/wrong/off-topic posts. There is a FAQ admin page that lets you delete comments. Anybody interested in doing this let me know and I will tell you how. This does not really need to be done, but it might be a good idea to clean up the comments. 2. Regarding the above, the FAQ admin page could be improved. Right now every comment has to be deleted by clicking a button. It would be nicer if you could mark comments to be deleted (via checkboxes) and then press one big button. Anybody that knows PHP and wants to tackle this, let me know. It would make task 1 much easier. 3. It might be nice to put up a Links page with links to related projects/companies, such as: Xfree86, Mesa, FbDri, Precision Insight, Tungsten Graphics, 4. On the About DRI page it still says that the principal developers of the DRI are employed by VA Linux and a bunch of other VA Linux stuff. Anybody who can come up with an updated and nice sounding paragraph to replace that, send it in and I will put it up. 5. Liam ([EMAIL PROTECTED]) is working on putting together a better status page with a card/chipset feature checklist. I am sure he could use some help, so anybody intersted in that can help him out. Anyway, just some ideas for little projects for anybody who wants to contribute in some way. Cheers, - Frank ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI kernel modules
I've been browsing the FAQ comments and mailing lists and it appears one of the main problems in getting the DRI to run for newbies is the confusion between which kernel modules to use. The ones from the kernel or the XFree86 ones? Most people don't realize that the modules also get provided by XFree86 and that the ones from XFree86 are the ones you should use. Usually people just grab the latest kernel and then don't understand why their modules are outdated. So, my question is: wouldn't it be easier to remove the DRI stuff completely from the stock kernel? Then there would be only one source for the modules and we wouldn't have this confusion. The modules could be made into a kernel patch that can then be downloaded from the DRI website, just like the install packages. Really it already is integrated into the install patches anyway. Has anybody thought about this before? - Frank ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Re: Card Motherboard / Chipset directory.
Ah, the status page. Possible better ways of doing it have been discussed many times before, both on and off the list. Nick Leippe, someone else and me have had quite a lengthy discussion on a nice way to organize this, including database table layout. If anybody is interested in what we came up with email me and I will forward it to you. I would do this myself, but I don't have time to write the code right now and as Daryll said I wouldn't have time to maintain it later on. Although, the system we came up with would require little active maintenance. Talking about maintaining stuff, I have added a couple questions to the FAQ yesterday and updated some existing ones. The FAQ is doing ok, with some fairly active discussions going on in the comments. Although often it is just people asking questions instead of sending those to the mailing lists. So anyway, if somebody wants to tackle this I will help you out with PHP/MySQL if you need it. But I wont start it alone. - Frank ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Re: Announcement
Finally I get some time to throw my 2 cents into this ... :) First of all I would like to say it is a shame to see you go, Gareth. You've done some really great work on this project and I think everybody appreciates it a lot!! I hope you have a good time relaxing for a while and find a good job later on - although with your skills I don't think that will be a problem. Also many thanks to all the other developers you've done great work too. Especially to Daryll and Alan for putting up with my sometimes stupid questions. :) Now Certainly, but you have to be inside to have any chance of getting this NDA. That is my impression at least. If you aren't already well known you wouldn't know what questions to ask the hardware company and you will therefore get the standard answer about secret and proprietary information which they regretfully cannot disclose to you. (If you are a member of the XFree86 project you will have access to some documentation though, but I can't see any particularly new specifications there.) If someone is truely dedicated enough to work on XFree86 code, they won't have problems getting the information they need, nor becoming a registered developer IMHO. Both are good points. But I think even if you can't get the inside info there is other work that can be done on the DRI that does not require indept knowledge of the hardware. Such as helping migrate stuff to Mesa 3.5, fixing minor bugs or improving performance. That alone would help a lot I would think. If we can take some of those easier tasks off the hands of the main developers they will have more time to work on new cutting edge stuff while we do some of the grunt work. Then, as you get better you can move up in the line. But basically, you have to start somewhere. You can't expect to work on the coolest stuff right away. The main reason IMHO is that XFree86 is very large and takes many months to be able to just navigate the source tree, and begin to understand the Imake build system, etc. As in kernel development, one must have a deep interest in overcoming the initial learning curves to get seriously involved in something like this. It certainly isn't a one-nighter thing one can just pick up. True, that would take a long time. But I don't think you have to understand the whole of XFree86. You would be working on the DRI which seems to be a more isolated part of it with less files. If you just make changes to the DRI driver files or related source files you don't have to learn the rest of the build system in detail. There are also no list of (easy) stuff that needs to be done. If such a list existed and pointed out roughly which files you would need to look at it might be a nice introduction to XFree86-hacking. On the other hand, maintaining such a list might be more troublesome for a seasoned XFree86-hacker than doing the work oneself. If you are looking for stuff to start work on why not browse the feature requests/bugs on Sourceforge. Sometimes there is some easy to fix stuff in there. Also, just pay attention to the mailing lists and look out for problems people report. Some of them are easy to fix and maybe even trivial - but as you solve those you will get a feeling for the code and can move on to greater things. If someone is truely anxious to do XFree86 work, one MAJOR area that needs doing, is porting the remaining 3.3.6 servers to the 4.x driver model. The DESIGN doc, and a few others included in the sources, coupled with perhaps some hardware specs, and some sample hardware is a good start, along with the free time to do it. I would like to hack on some of that myself but higher priority issues prevail. This is another good example for tasks that can be done which do not require insider info. Also, some people have said that there is no documentation. This is also something that people can write themselves. If there is interest I can put a little knowledge archive on the website. So, as you start working with the source you can document your steps and experiences. Then, as other people start working they can look through what you have written. This could grow into a collection of lots of little articles that could eventually be combined into a larger document. I am not saying you should write a novel here. Just write one or two pages whenever you figure something out that you feel would be valuable to other people. Ok, that's all I have to say. Cheers... - Frank ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] (no subject)
First off, apologies all around for not putting in a subject line. I kinda forgot about that! ;) I made some notes during my installation, I could possibly write something of a howto if you think it would help. Yeah, it would be very nice if you did that. More or less. this is what my drm modules directory looks like now that I have installed the 0.7 package... -rw-r--r--1 root root29688 Apr 15 17:14 gamma.o.gz -rw-r--r--1 root root34815 Apr 15 17:14 i810.o.gz -rw-r--r--1 root root39383 Apr 15 17:14 mga.o.gz -rw-r--r--1 root root39627 Apr 15 17:14 r128.o.gz -rw-r--r--1 root root 108222 May 16 19:15 radeon.o -rw-r--r--1 root root25798 Apr 15 17:14 tdfx.o.gz Wacko ... I've never seen anything like that. Then again, I've never used Mandrake. Since a lot of people seem to run Mandrake (especially 8) it would probably be worthwhile to add a check for something like this. Well, I claim to be no genius... I remember something on my slackware box though.. Quake3 for instance would run fine, but Unreal Tournament would revert to software Mesa unless I removed all traces of libGL* except those provided with whichever drivers I was using. If I remember right it was this way with both the DRI drivers for my Radeon, and Nvidia's driver for a GeForce card I have. I dunno. If we relink libGL to the correct one in /usr/X11R6/lib it shouldn't really be a problem. - Frank ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] supported resolutions matrix
Ok, since I sent this last time from Outlook without switching to plain-text mode I will try this again. As I understand it the supported resolution for 3D acceleration depends on the graphics cards memory capacity. If this is the case, and also if it is the same for all cards maybe someone would feel inclined to produce a matrix that outlines this for the DRI webpage. A lot of newbies install the DRI and then try to use it at some super-high resolution they have been using previously for 2D only. Of course it doesn't work and then they have to figure out why. A matrix explaining this on the site would be very cool. In the meantime I will add a FAQ item explaining the problem. - Frank ëׯzYX§X¬´:âuëÞX¬¶Ë(º· ~àzwÛiÿùb²Û,¢êÜyú+éÞ·ùb²Û?+-wèýÚâuëÞ
[Dri-devel] DRI beginner's guide
Since some people asked for it on the FAQ comments I've put together a pretty basic DRI Beginner's Guide. It is a rough, step-by-step guide on how to setup the DRI on a Linux system. Instead of explaining everything twice it just gives you a short explanation on what to do and points you to the other already existing documentation. You can take a look at it here: http://dri.sourceforge.net/doc/DRIbeginner.html If you think it's good enough I can add it to the Documentation page. - Frank ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] DRI installation script README
-o makes GNU tar produce a POSIX compliant tar archive when creating archives. It does nothing when untarring. Holy crapola, the 'o' does nothing? I have been using '-xvof' for as long as I can remember ... this is insanity! ;) I always thought it meant overwrite without prompting or something like that. Anyway, I will update the readme. - Frank ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] tdfx driver
The DRM module from the DRI CVS seems to work fine in 2.4.4. (The one in the kernel however does seem to be broken.) Isn't it generally best to use the module from the CVS/packages in any case, no matter if the kernel module works? Just alone for the fact that we then know that the driver module and kernel modules have matching versions? - Frank ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] status page updates
Hey, hey ... I would like to update the current status page some more. Basically I would like to know which different versions of the Radeon chip are supported, ie: VE, ME, LE ??? There's been some questions regarding that on the FAQ comments. Also, is the Rage 128 Mobility supported by the current Rage 128 driver? If it is I would like to add that to the list too. One last thing, which drivers support AGP/PCI ... and should I add that to the chipset list description? - Frank ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] status page
Treading dangerous ground. I'd remove this page, and maybe put in Daryll's suggestion of letting people leave comments on whether it worked with their system. There are too many if's and but's that different systems introduce to speculate whether it matches your legend key table. Yes, I know. Nick Leippe and me are working on something like that, but we're too busy right now. So until it's done I figured I would at least update the old page a little bit. - Frank ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] status page
Ok, after thinking about this some more I guess there's no point in keeping the page going as it is, since it doesn't make much sense. I've made a generic listing of cards, check it out at http://dri.sourceforge.net/status2.phtml and if it's ok I will replace the current page. - Frank ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] install script issues
We broke something in the install script. Don't update using the script until we include an updated one in new packages (tomorrow I guess). Also, you will need to download the Extras package if you are updating any stock XFree86 release (including 4.0.3). See the readme on the website for more info. - Frank ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
