Re: [Devel] Re: Another voice
David Dawes writes: > On Sun, Jan 12, 2003 at 02:25:35PM -0800, [EMAIL PROTECTED] wrote: > >Specifically, there are people in Gnome chomping at the bit to help with > >the xfree86 bug setup and triage problem, with experience at running > >the Gnome bugzilla system. > > >Only time will tell how well this will work out, but my strong belief is > >that the current situation doesn't scale, and our usage is likely to > >go up greatly this calendar year as the open source desktop has finally > >reached critical mass of applications and is beginning to be actively > >marketed. > > I recall you saying the same thing a year ago. You didn't provide > anything to backup your assertions then either. > > BTW, while I have you here, can you tell me when the bugs introduced > with the integration of RandR into the core XFree86 server will be > fixed? A particular case is rotation support being broken (kinda > ironic given that the second "R" is for "Rotate"). I don't know > how much longer the 4.3.0 release can be delayed waiting for this > to be fixed, so if it isn't fixed soon, RandR will have to be > disabled by default in 4.3.0. You don't seem to have your priorities > straight -- you seem more interested in establishing a bug tracking > system to track other people bugs than fixing bugs in your own code. > I have been experimenting with this over the Christmas holidays: The reasoun why RandR breaks our old implementation of rotation is that RandR overwrites the screen size values we have set in fbScreenInit() after ScreenInit(). We could whack them again by adding a ScreenCreateResources() however this may not go well with RandR. To make RandR rotation work one needs layer support. I have a sample implementaion (it takes two lines per driver) however this is too experimental to bee added to 4.3 I'm afraid. It is also not clear how this may affect dual depth frame buffers like the 8+24 bpp support in the MGA driver. I didn't have time to look into that, yet. Cheers, Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
David Dawes writes: > On Sun, Jan 12, 2003 at 11:01:01PM +0100, Fernando Herrera wrote: > >Sun, Jan 12, 2003 at 04:15:15PM -0500, David Dawes escribió: > > > >>So it's OK for Linux kernel developers to object to having a bug tracking > >>system imposed on them but not OK for XFree86 developers? If that's > >>what you're telling me, then I have nothing more to say on this topic. > > > >No, Maybe I have explained myself wrongly. Linux kernel is > > No I think you explained yourself very clearly, and I find your > attitude personally insulting. You're telling me that it's OK for > the great gnome hoard to impose it's desires on me because I'm not > Linus. > > >developed in a very personal way, the Linus way. It's his project, and > > So it's OK for Linus to develop a project he founded in his own > personal way, but not OK for me to do the same with a project I > co-founded and have spent a large part of my adult life on? > > What nobody has explained to me yet is why gnome in particular has > such a great interest in this. I'd appreciate an open and candid > explanation. > I would say the XFree86 project is much more like the Linux kernel than like the gnome project. There are very few parts in XFree86 which you want to identify as separate 'products', the only things that come to my mind are the drivers, applications - like xterm - and the libraries. Many of these parts don't even have their maintainer (look at how many drivers are orphaned at the moment). If we look at the servers itself: it is well comparable to the linux kernel. A single person (or a small experienced group) has to make sure that all parts work together well and that modifications to one part don't affect the functionality of the others. That's why commit access is limited to a few people. Even with these few merging conflicts cannot always avoided. I'd be willing to try to work with a bug tracking system. But - like David - I will immediately stop using it when I discover that it consumes my time instead of saving it. If we were going to have a bug tracking system we'd need somebody to preprocess the entries and collect all necessary information from the reporters before the bugs are escalated to the engineers. There is no use having reports like 'KDE application k... has rendering errors when doing this-and-that'. We'd need something like: 'XRequest X... causes rendering errors under these circumstances' Note that this person needs to have a lot of experience. I do understand that desktop projects have great interest in an interface into XFree86. However one needs to keep in mind that the crowd of active XFree86 developers is small compared to the people working on GNOME or KDE. The reason was given in this discussion already: the learning is quite steep. Part of this is due to the fact that there so few separate 'products'. That documentation for the internal APIs (except for the driver API) is largely non existant only adds to that. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Bugzilla [Was: Re: Another voice]
Matt Wilson writes: > On Sun, Jan 12, 2003 at 07:21:04PM -0500, Georgina Economou wrote: > > > > So Matt am I to take it that Redhat is looking to push forward with > > its Bugzilla and thus get more experience and in the end paid work > > with it like VA did with Sourceforge? That sounds very sensible > > though I think your approach a bit bizarre and off-putting. > > I don't understand. We're interested in seeing Open Source projects > succeed. This involves growing contributor bases, etc. Although > XFree86 development applies to many operating systems, it's success is > key to Linux's success. We've never really thought much of trying to > build a business around consulting groups on how to be successful Open > Source projects... > Asking OpenSource projects for money to get consulted? I don't think you'd get any business from XFree86 either :-))) BTW: XFre86 has been around quite a bit longer than RedHat has been in OpenSource community. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
Matt Wilson writes: > > I'm not attempting to bully anyone, nor have I argued that you or any > other member (individual or corporate) of XFree86. However, there are > plenty of volunteers that are offering to set up and maintain a bug > tracking system for you. I think that such a project would be much > more successful if it were endorsed by XFree86 and integrated into the > development policy for the project. > Sorry, this is not how it goes. We won't be willing to adopt anything blindly. There is a German saying applying here: 'Never buy a cat in the bag!' 1. First there should be a proposal 2. Secondly there should be a test implementation as proof of concept we can work with and see how well it goes. 4. Thirdly this should be evaluated - if we think it is usable at all. - what modifications we would like to see. 5. The modified system needs to get retested and reevaluated. 6. This is the earliest stage we can talk about a more or less formal policy. Up to now it is not even clear who should be able to submit to this bug tracking system: Should it be internal only? Should only projects like GNOME, KDE etc and distributions like RedHat, SuSE, Mandrake be able to submit bugs? Or should it be open to the general public? Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
David Dawes writes: > > It's as simple as me not liking the tools I use during my spare > time being imposed on me by groups that have more to gain from my > using them than I do. This big clamour is not coming from the end > user community, but from groups like gnome, and distros like Red > Hat, and hardware vendors like HP. Well, you saw what IBM did to > get kernel bug tracking. If you guys want it badly enough, maybe > you should put up the resources on an ongoing basis to make it > happen rather than trying to bully volunteers into doing it for > you. You'd be doing quite a service to the community. > Yes, good point! It has bugged me for quite a while that many companies who take huge advantage of our work have done virtually nothing to sponsor manpower. If there is really that much interest in the Linux desktop as Jim always likes to point out those companies will make some revenue with selling desktop products. Therefore it would be in their own interest to invest some manpower in our project. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Bugzilla [Was: Re: Another voice]
On Mon, Jan 13, 2003 at 11:09:21AM +0100, Egbert Eich wrote: > Asking OpenSource projects for money to get consulted? > I don't think you'd get any business from XFree86 either :-))) Of course not - which is why I was so confused by the comment in the first place. Cheers, Matt [EMAIL PROTECTED] -- Matt Wilson Manager, Base Operating Systems Red Hat, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
this list is archived
Title: this list is archived you can read this list on http://mail-archive.com, starting now.
Re: [Devel] Re: Another voice
On Sun, 12 Jan 2003, Georgina Economou wrote: > From: "David Dawes" <[EMAIL PROTECTED]> > > On Sun, Jan 12, 2003 at 10:24:54AM +, Andrew C Aitchison wrote: > > >* Read access to the patch@ and fixes@ lists would be helpful, then > > >we would all have an idea of the backlog. > > It's been there for the asking for members for a long time. Few asked. > You know I never for the life of me understood that. I would have thougtht > that every developer would be interested and see if their patch bumped horns > with another. > As former postmaster I received, I think, a total of two requests. Weird. I think I looked at it once, but felt that most patches would be outside my areas of interest, and a mailing list wouldn't give me the information I wanted when I wanted it. I'd have to archive all postings and grep them later. Having the information in a database (such as bugzilla), and perhaps including information such as when it was integrated, would make it more useful to me. Since I don't have comit access I didn't see the point of just reading patches. Also, IIRC, the CVS-comit logs were better advertised than the patch mailings, but I found that they had virtually zero content. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Sun, 12 Jan 2003, Georgina Economou wrote: > Well there's still http://mail-thearchive.com. What ever did happen to marc > on this one? Indeed devel and xfree86 appear to be at http://www.mail-archive.com/index.php?hunt=xfree86 The xfree86 list has appeared on http://marc.theaimsgroup.com/ (under misc, rather than GUI with the other X lists). It appears that no-one has asked for devel to be added there yet. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another voice
On Sat, 11 Jan 2003, G O Economou wrote: >http://www.advogato.org/person/mharris/ > >There are allot of interesting comments here by Mike, >particularly his interest in forking XFree86 and creating his >own work. You seem to have some deep misconceptions. The only things I've mentioned on there are my decision to branch the Radeon driver and to contribute stuff back to the XFree86 project. How that is seen as a fork of the entire project, I'm unsure. I'll be the first to admit that I'd be completely unable to fork the entire XFree86 project on my own, and that it would be a very large amount of work without any guaranteed gains in return. Some other people have commented after reading my page in some public forums that it was a fork of XFree86, however those people clearly don't posess reading comprehensions skills. Or perhaps, since I'm so long winded quite often, they read what they wanted and made some very false assumptions about what the rest said. I think you might want to go back to the page above and re-read the complete entries of what I actually said. You'll see that I discuss branching the Radeon driver and contributing code back to the XFree86 project. You'll also see that I respect vendors whom contribute code to the project, such as ATI, very greatly, and that I want them to feel that their contributions are very welcome in order to make them feel like continuing to contribute in the future. Since I do not have CVS access to the XFree86 repository, I have no way of commiting the code to the repository (after cleanups and code review, testing, bug fixing, etc. of course) however I do have the ability to contribute nonetheless. I have the ability to take the patches that ATI has contributed, and patch them into the open source code of the XFree86 project myself, test the code, provide sample drivers for users to also test, give me feedback on, debug, do more testing, perhaps talk to ATI, or to other developers whom have worked on the ATI driver. When I have something that I think is a well tested driver, or I can break the thing down into bits and pieces and submit smaller patches, I can help to save the time of David Dawes, or someone else who ends up commiting the changes. What you are suggesting, is that I not be allowed to do this, and that my motivation to take the initiative and do the work myself is somehow "wrong". >At least I think interestingand BTW doesn't the ATI >maintainer work for Redhat? As far as I know, the ATI driver maintainer is Marc Aurele La France, and while he's done some great work on the ATI drivers, we haven't tried to hire him to my knowledge. Or you could be refering to Kevin Martin. He works for Red Hat however, in our Professional Services department. He is not involved in Red Hat Linux OS engineering with respect to XFree86. Kevin's involvement with the XFree86 project, and his contributions to it, as far as I know are on his own personal private time as a volunteer, much like that of the other people on the XFree86 project's core team. You'd have to ask Kevin personally for the details of what his job role is here at Red Hat, but it isn't related to commiting Radeon drivers to XFree86 CVS as far as I know, if that is what you were insinuating above. Kevin is a nice guy from the times that I've chatted with him in the past, and I plan on talking with him in the next day or so about some developmental questions. Perhaps he can offer me some suggestions for Radeon driver development as well. My job at Red Hat is to make XFree86 a stable GUI platform for our OS products. I don't just do the baseline minimum of what is required of me in order for Red Hat to ship the OS however. I have become personally interested in the code, and in the project and ALL of what I do in my personal time with respect to X development, and a large amount of what I do for work both are focussed on things that I personally try to do to help out the XFree86 project, and the various users who use it, not just Red Hat Linux users. If you read the thoughts I've mentioned on my advogato page without a personal bias or pre-judgment, I think it is quite clear that my own interests lay in helping to build up a community of developers to help the project, and to getting various people working on the project in isolation to work more directly with each other - throwing away personal bias, and breaking down walls such as "you work for vendor A, I don't like you" way of thinking. I have personal thoughts and ideas on contributions I can make back to the project, and to the community of users who use XFree86. I'm not going to let any other developers discourage me from that personal goal. For now, I'm starting by working on getting a Radeon driver out to XFree86 users that contains code contributed months ago, but isn't available for users to test - many users whom would like to use their video cards in Linux before t
Re: Another voice
On Sat, 11 Jan 2003, David Dawes wrote: >>There are allot of interesting comments here by Mike, particularly his >>interest in forking XFree86 and creating his own work. At least I think >>interestingand BTW doesn't the ATI maintainer work for Redhat? > >Definitely interesting. > >One main point I would like to answer now is the issue of the developer >page on the web site. New membership was basically closed down temporarily >while the whole membership/developer situation was being reviewed. > >After this message goes out, [EMAIL PROTECTED] will be converted to >a public mailman list -- so if you want to subscribe, go to >http://www.xfree86.org/mailman/listinfo/devel/ > >In the interests of openness, there won't be any private list to replace >it, and the whole issue of joining XFree86 as a developer will be moot. David, this is wonderful news. I'm very pleased to see this change happen. I've wondered for a long time why the private devel list was private, considering almost if not all of the discussions that have taken place on it in all the time I've been on it have not really been something that private. I hope that the XFree86 core team members will continue to use the list now for the same purposes it has been used in the past. By active participation between existing core team members, other existing member developers, and also new potential developers, it may be possible to create a lot more people interested in contributing to the project. So this is very good news. >BTW, as far as bug tracking goes, there's nothing stopping >anyone setting up and maintaining a bug tracking system on >behalf of XFree86. You really have to understand that forcing >volunteers to do anything is impossible though, so the >effectiveness of such a system is something that will only be >discovered by doing it. That's always been understood. I would not want someone to try and force me to use something any more than one of you developers on the core team would want someone else to try and force you. We all of course volunteer our time to work on things that we personally feel like working on, and part of that is having control of how our own time is spent. It would be wrong for anyone to try to force a developer to use bugzilla against his/her will, and would potentially be insulting. >As far as commit access goes, frankly, if those asking for it >could establish a record of submitting complete and correct >patches that didn't need review (and Mike, your record on this >isn't anything to boast about), then you might have a better >shot at it. Well David, out of all of the patches I've submitted to XFree86.org that I've written personally myself, the percentage of them that were applied to CVS is pretty high, and almost all of those without any modification or with minor formatting modifications, or a some other similar very trivial change. When patches are committed, before I drop them, I manually examine each diff line by line in order to see if the patch was applied without modification or not, and to ensure it was done correctly without things getting lost. I also do this detailed patch drop review in order to try and understand any modifications that have been made to a patch - to learn of course. In the past I have also submitted various patches found on mailing lists, and things people have sent me that fixed something for them. A great deal of said patches I merely passed along upstream in hopes that they might be useful to the project after someone did a good code review. This was somewhat of a mistake of course, as I had no idea what was expected, and found out quite some time later that my processes and procedures for submitting patches was not entirely the best. As you'll recall, as soon as this was brought to my attention, I emailed you directly and asked you what you expected in patches, and what you expected to accompany them, etc. I immediately modified my methods, and since then, most of the patches I've submitted have been of my own writing, or have been much more closely scrutinized. Also, if I can't vouch for a patch's correctness, I tend to get the person who wrote it to submit it instead, be they some random person off the net, some other X developer, or some other Red Hat developer. I've refused TONNES of patches sent to me, and have referred numerous people to submit things directly to [EMAIL PROTECTED] I've also refused to apply things until they hit CVS so that I'm guaranteed that all people who use XFree86 benefit from a patch, and not just Red Hat users. Other patches I've submitted include various i18n stuff, some written by other people at Red Hat, and some of it which was code developed by someone off the net, bounced from distro to distro to distro and ended up at us, having no idea who originally wrote it, and having no familiarity with the area of code it touched, but being told that "it fixes Chinese" or sim
Re: [Devel] Re: Another voice
On Sun, 12 Jan 2003, Vladimir Dergachev wrote: >> I'm very happy to hear this! I hope we can get more of a developer >> community going, like I've been feeling in #xfree86 recently. However, >> I still think the specs are valuable (I've used a couple of them, and >> expect to again) even if the current set is limited. Are there any > >I quite agree. The fact is that without hardware specs there is >truly little reason why someone would be interested to working >with XFree86 code instead of writing a userland app. Granted, >XFree86 offers network transparency, but why bother working >within Xserver for a prototype app ? And people who do not get a >chance to work on a toy project within X tree are much less >likely to contribute. Where hardware is concerned, such as the video drivers, I would agree. More often than not, having the hardware documentation is required, or is at least quite helpful. However, the entire XFree86 sources contain libraries, extensions, applications, fonts, documentation, and many other things - all of which other potential developers could volunteer to work on too, without requiring hardware documentation. >> One thing that I think would help a lot here would be more feedback on >> what was lacking in our patches. I know I submitted some broken ones to >> you, but when you later fixed them I didn't get a note saying "Hey, we >> support FreeBSD back to release X.X, please respect older versions." >> Anything to tell me more of what is expected for the project will help >> me submit better patches in the future. > >There is also an issue of Bazaar versus Cathedral type of development. >There is a tradeoff between quality of patches and number of people >actively working with the code. I'm not sure what you're suggesting here. Could you clarify a bit? The Linux kernel for example has a very large source code base, and has countless developers whom have worked on it under the Bazaar model, and the code is quite high quality. People write good patches, and people write bad patches regardless of what model of development is used. However, I think that due to the bazaar style of development the kernel is done under, the bad patches get weeded out much more easily, whereas with the cathedral style of development, they're more likely to simply get ignored or cast aside. Is that similar to what you mean? TIA -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Sun, 12 Jan 2003, Fernando Herrera wrote: >>So it's OK for Linux kernel developers to object to having a bug tracking >>system imposed on them but not OK for XFree86 developers? If that's >>what you're telling me, then I have nothing more to say on this topic. In that context alone, I would agree with you, however... > No, Maybe I have explained myself wrongly. Linux kernel >is developed in a very personal way, the Linus way. It's his >project, and he can do what he wants. That isn't really an argument to support your case that XFree86 should use a bug tracker. I'd say it is an argument against it. XFree86 project was of course started by David, and a few others, so one could say "XFree86 is developed in a very personal way, the David way. It's his project, and he can do what he wants." just as easily as what you've said above. On that alone, I'd even have to agree with it, and I'd probably be insulted if I were David. I completely agree that a bug tracker would be a great help to the XFree86 project, and I also believe that some people who may not think so, would change that viewpoint over time, as long as they can be shown that THEY benefit from it, and not just other people. In order to convince someone that a bug tracker is a useful thing, it is totally useless to sprout off about all of the good things bug trackers can do, that you think is good for YOU of for someone else, or some other project (or vendor or whatever). What is needed, is to listen to what THEY are saying, and to see why THEY do not want to use a bug tracker. If they have reservations about a bug tracking system, fears, or whatever - the only way to change their mind, is to show them nicely how their concerns can be properly met by your proposed solution. Otherwise people are talking past each other, and nothing changes. That isn't really co-operating or collaborating, but rather 2 people or 2 groups of people with contrarian viewpoints, each pushing their own viewpoint and ignoring the other's viewpoint. That wont work. >What many people is proposing is to adopt a good bug tracking >system for XFree86 development. From experience in other >projects, everyone can see that its adoption is good for the >global project quality. I certainly agree there, and I don't think that is the problem that needs to be solved. What needs to be done, is to show the developers that a bug tracker is not going to cause the problems they fear. If they can be shown that a bug tracker wont get in their way, then they are more likely to be more open minded to the idea of using it. I think they fear it will be a huge bug dumping ground where various users will dump bugs one after the other, and that distribution vendors will also dump all their bug reports there, and then point at XFree86.org and say "here, fix it". That is a valid fear, and can not be ignored by all of us open source developers whom think a bug tracker would be good for XFree86. Remember, we are saying bugzilla would be good *for XFree86* and also *for XFree86.org*. We _HAVE_ to show that that is TRUE *first* or else why would anyone want to listen? I don't think it is at all unreasonable to have to provide some proof of the concept to those who doubt us. >So we have bugzilla. I'm only proposing XFree86 core developers >to try it. Try to see how it can be usefull. If finally XFree86 >Team doesn't like it, we can try to find another tool, or we can >try to develop it. Again, making such a request to the XFree86.org developers is only ignoring the things they've brought forth against the bug tracker. As above >I know that using a new tool is always difficult, but please, >give it a chance! Begging doesn't work either, and probably would just be found as annoying. I appreciate you agree that a bug tracker is needed, but please make sure that it isn't a one sided argument. Making a suggestion of an idea that will benefit a project, and putting forth advantages of doing so, which only help you, but without trying to provide answers to the problems the people ask about that are against, or leaning towards being against the idea, doesn't help win their support. Let's not be one sided. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Sun, 12 Jan 2003, Andrew C Aitchison wrote: >> As far as commit access goes, frankly, if those asking for it could >> establish a record of submitting complete and correct patches that didn't >> need review (and Mike, your record on this isn't anything to boast >> about), then you might have a better shot at it. > >We *need* more developer-hours on the commit process. That would be a nice thing to have. It works marvelously for all other projects that have wider spread CVS write permissions. >Maybe we have to put up with people like Mike making a few more >mistakes while that they learn what they are doing wrong? I can't agree with you more. I, like any serious developer, certainly want to be told about my mistakes, so I can correct them, or have an opportunity to explain why I believe my changes to be correct. There's only one patch that I can think of off the top of my head which I've sent to XFree86.org which was rejected, to which I later resent an updated version back with a good explanation for why I thought it should be applied. I don't recall receiving any feedback positive or negative since. It's not a major issue however as I apply the patch to our sources regardless, as I believe it to be correct, and it harms nothing at all. Most likely I will post that patch here again in the future - now that the development list is publically open. I am then going to get much wider peer review of my patch, and instead of getting one person's opinion of it's correctness, I can get 100 people's opinion. While it may not make the patch accepted into the upstream official source even if 500 people agree, it would at least make it a case 500 separate opinions, instead of the prior case of one person's opinion in a position of power's versus one person's opinion whom is not in a position of power. I'd rather be judged by 500 peer developers for the quality of my patches and work than by one single person. >They will learn a lot faster by doing it wrong than by submitting >patches that may or may not appear months later in a very different >form. Indeed. I will say that a while back, I approached David concerning patches and what his expectations were. I have made every effort to try and meet those expectations, and have modified some of my ways of doing things further beyond what was requested, in an attempt to provide the project with better submissions. In the past, I would not only send in my own patches (which incidentally get applied unmodified almost always), but I used to submit many patches from others, usually - but not always with proper attributions on them. Some patches you find in the wild with no indication of whom the original author is. I just passed the stuff all on upstream hoping that someone there would review them for correctness, apply them, or reject them, etc. Some patches I just picked up of mailing lists as I saw them, and submitted them so they wouldn't get lost. Several of these patches as you can imagine, were not the highest quality, and many never got into the tree. Unfortunately however, many of them were wrongly I believe attributed to ME, but of no fault of my own for not being more organized with what I sent in, and without as much process and procedure in place as what I have now. I also used to send in patches that people sent into Red Hat via bugzilla. We receive many patches of which I personally am not familiar with the particular area of code that is being patched, and so I am not always personally capable of vouching for a given patch's correctness. In such cases, what should one such as myself do? Tell the person to send their patch to XFree86.org instead? People get PISSED BIGTIME! I've told people to please submit xkb patches (MANY of the ones recently sent in to [EMAIL PROTECTED] which subsequently were applied to CVS, and if need be I can provide bugzilla bug ID's of proof). People go nuts! "I am a Red hat user and you should apply my damn patch blah blah." If I send it to XFree86.org myself, then am I being judged as having vouched for it's correctness? I didn't think I was before, but after David's comments toward "my patches" before, I took a hard line about it. For a few months I have refused MANY patches submitted, and requested the person to send their patch directly to [EMAIL PROTECTED], and that if it were accepted upstream, I would apply it to Red Hat Linux also. I also have stated to people when doing this many times (and this is also bugzilla queryable for the conspiracy theorists amongst us) that by submitting the patch upstream, ALL distributions get the benefit, as does the project as a whole, and that it doesn't end up being a fix that is only seen by Red Hat users. >As others have said, feedback on problem submissions is important; >does it add much time to fire off a quick note at the point where you >find a problem with a submission ? You don't need to tell us the >
Re: Another voice
On Mon, 13 Jan 2003, Mike A. Harris wrote: > On Sat, 11 Jan 2003, G O Economou wrote: > > >http://www.advogato.org/person/mharris/ > > > >There are allot of interesting comments here by Mike, > >particularly his interest in forking XFree86 and creating his > >own work. > > You seem to have some deep misconceptions. The only things I've > mentioned on there are my decision to branch the Radeon driver > and to contribute stuff back to the XFree86 project. How that is > seen as a fork of the entire project, I'm unsure. I'll be the > first to admit that I'd be completely unable to fork the entire > XFree86 project on my own, and that it would be a very large > amount of work without any guaranteed gains in return. > Actually, there is a fork of XFree already - in dri.sf.net and another one of ati driver only in gatos.sf.net. One more wouldn't hurt, but Mike - why do you want to fork Radeon driver ? best Vladimir Dergachev ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Mon, 13 Jan 2003, Mike A. Harris wrote: > On Sun, 12 Jan 2003, Vladimir Dergachev wrote: > > >> I'm very happy to hear this! I hope we can get more of a developer > >> community going, like I've been feeling in #xfree86 recently. However, > >> I still think the specs are valuable (I've used a couple of them, and > >> expect to again) even if the current set is limited. Are there any > > > >I quite agree. The fact is that without hardware specs there is > >truly little reason why someone would be interested to working > >with XFree86 code instead of writing a userland app. Granted, > >XFree86 offers network transparency, but why bother working > >within Xserver for a prototype app ? And people who do not get a > >chance to work on a toy project within X tree are much less > >likely to contribute. > > Where hardware is concerned, such as the video drivers, I would > agree. More often than not, having the hardware documentation is > required, or is at least quite helpful. However, the entire > XFree86 sources contain libraries, extensions, applications, > fonts, documentation, and many other things - all of which > other potential developers could volunteer to work on too, > without requiring hardware documentation. > They could volunteer to work on it, yes. However a good many of open source efforts starts with need to scratch your own itch. All I am saying is that hardware-independent itch can be scratched without messing with Xserver internals. > > >> One thing that I think would help a lot here would be more feedback on > >> what was lacking in our patches. I know I submitted some broken ones to > >> you, but when you later fixed them I didn't get a note saying "Hey, we > >> support FreeBSD back to release X.X, please respect older versions." > >> Anything to tell me more of what is expected for the project will help > >> me submit better patches in the future. > > > >There is also an issue of Bazaar versus Cathedral type of development. > >There is a tradeoff between quality of patches and number of people > >actively working with the code. > > I'm not sure what you're suggesting here. Could you clarify a > bit? > > The Linux kernel for example has a very large source code base, > and has countless developers whom have worked on it under the > Bazaar model, and the code is quite high quality. People write > good patches, and people write bad patches regardless of what > model of development is used. However, I think that due to the > bazaar style of development the kernel is done under, the bad > patches get weeded out much more easily, whereas with the > cathedral style of development, they're more likely to simply get > ignored or cast aside. > > Is that similar to what you mean? This seems to be another angle ;) My point was that the easier it is for patches to go in the more attractive the project looks to new developers. best Vladimir Dergachev > > TIA > > > -- > Mike A. Harris > > > > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another voice
On Mon, 2003-01-13 at 16:10, Vladimir Dergachev wrote: > On Mon, 13 Jan 2003, Mike A. Harris wrote: > > > On Sat, 11 Jan 2003, G O Economou wrote: > > > > >http://www.advogato.org/person/mharris/ > > > > > >There are allot of interesting comments here by Mike, > > >particularly his interest in forking XFree86 and creating his > > >own work. > > > > You seem to have some deep misconceptions. The only things I've > > mentioned on there are my decision to branch the Radeon driver > > and to contribute stuff back to the XFree86 project. How that is > > seen as a fork of the entire project, I'm unsure. I'll be the > > first to admit that I'd be completely unable to fork the entire > > XFree86 project on my own, and that it would be a very large > > amount of work without any guaranteed gains in return. > > > > Actually, there is a fork of XFree already - in dri.sf.net and another one > of ati driver only in gatos.sf.net. I agree that the latter can be considered a fork, but the former definitely isn't - the DRI and XFree86 repositories are regularly synchronized. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
[Egbert Eich] > Up to now it is not even clear who should be able to > submit to this bug tracking system: > Should it be internal only? > Should only projects like GNOME, KDE etc and distributions like > RedHat, SuSE, Mandrake be able to submit bugs? > Or should it be open to the general public? It should be open to the general public, but require a working email address to submit and modify bug reports. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
> Sender: [EMAIL PROTECTED] > From: Egbert Eich <[EMAIL PROTECTED]> > Date: Mon, 13 Jan 2003 11:10:14 +0100 > To: [EMAIL PROTECTED] > Subject: Re: [Devel] Re: Another voice > - > Matt Wilson writes: > > > > I'm not attempting to bully anyone, nor have I argued that you or any > > other member (individual or corporate) of XFree86. However, there are > > plenty of volunteers that are offering to set up and maintain a bug > > tracking system for you. I think that such a project would be much > > more successful if it were endorsed by XFree86 and integrated into the > > development policy for the project. > > Matt, I'm *very* uncomfortable with saying a bug tracking system should become policy for any project unless/until a project has a pretty universal buy in that it should be that way. We're a *very* long way from that point. > > Sorry, this is not how it goes. We won't be willing > to adopt anything blindly. There is a German saying > applying here: > 'Never buy a cat in the bag!' > > 1. First there should be a proposal Seems like that's what some of us have been making, though we haven't fleshed it out completely yet. Without discussion, it is difficult to make it concrete. Ergo, the discussion. > 2. Secondly there should be a test implementation >as proof of concept we can work with and see >how well it goes. Entirely agree. > 4. Thirdly this should be evaluated > - if we think it is usable at all. > - what modifications we would like to see. Entirely agree. > 5. The modified system needs to get retested and reevaluated. Entirely agree. > 6. This is the earliest stage we can talk about a more or >less formal policy. Entirely agree. Any policy, however, can/should only occur if there is nearly complete consensus. We're a long way from that, if ever. > > Up to now it is not even clear who should be able to > submit to this bug tracking system: Very good questions on which multiple opinions are solicited. > Should it be internal only? > Should only projects like GNOME, KDE etc and > distributions like RedHat, SuSE, Mandrake be able to > submit bugs? > Or should it be open to the general public? > I personally argue for openness, with a couple major caveats: o The verbiage around bug submission should be carefully crafted to try to help with the triage process between projects (e.g. if your server crashes, its definately an XFree86 bug; if it is bad rendering, asking people to verify it is specific to a particular piece of hardware, else report to the appropriate project's bug system, and so on. o the states of a bug inside the database allow for triage, with states like "bug verified", duplicate, etc. I suspect/expect many developers might ignore problems until they've been marked verified. That's the point of a triage process: to bounce the problem the right direction so that not all bugs get looked at by all people (or no people). One could go through an evolutionary process, from developers, to invited others, to fully open. The question still is: is there enough interest among the developer community to it be worth the investment to get it set up? If no-one is going to use it, why bother? On the other hand, if enough of us say, as I do, that we're dropping too many problems on the floor and such a system might be useful if it gets established correctly, I think there is enough resources to start getting it set up. But those resources should go elsewhere if there is no interest. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
programming question: Window Information
I would like to gather inforamtion about all the
running X applicaiotns.
Thus I do
Window root = RootWindow (dpy, screenno);
XQueryTree (dpy, root, &dummywindow, &dummywindow,
&children, &nchildren);
for (i = 0; i < nchildren; i++) {
if (XGetWindowAttributes(dpy, children[i],
&attr) && (attr.map_state == IsViewable)) {
XFetchName(dpy, children[i], &win_name);
printf("Window ID: 0x%lx\n",children[i]);
}
}
I thought that win_name will contain the name of the
window, but it is always null,
what am I doing wrong?
Thanks!
=
__
Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino
http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
RandR status
I'm sorry if this is a FAQ: Is RandR going to be in 4.3? If so, are there any changes/additions to be made in the drivers in order to support RandR? If so, is there any documentation available on how to do this? Thomas -- Thomas Winischhofer Maintainer of XFree86 SiS driver Vienna/Austria mailto:[EMAIL PROTECTED]http://www.winischhofer.net/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
Around 10 o'clock on Jan 13, Egbert Eich wrote: > To make RandR rotation work one needs layer support. I have a > sample implementaion (it takes two lines per driver) however > this is too experimental to bee added to 4.3 I'm afraid. I have done a more complete investigation in September and decided that the changes needed were significantly more extensive than could be reasonably accomplished in the timeframe available. As resize presents the largest application visible effect from the extension, and also significant value for existing users, I thought providing just resize was of enough benefit that it should be included even if the rotate portion wasn't possible in the current timeframe. Another factor in my thoughts was the work Mark is doing related to 5.0 driver interfaces; early discussions lead me to believe that rotation in that environment would be significantly easier and more functional, so it seemed to me that making significant changes in the 4.x architecture to support a feature of marginal current utility made less sense than perhaps waiting for a different driver architecture which would make the task easier. With the release of tablet PCs that essentially require rotation for their intended use, I may have to reevaluate this position. I was hoping that the video chips in use for those devices would support hardware rotation as some PDA chipsets do, but it doesn't appear to the be case. The acer and toshiba tablets use the silicon motion chip which provides accelerated rotated blts, but not actual rotated frame buffer support. The accelerated rotated blts are used to make a shadow frame buffer implementation significantly faster, and I would want any XFree86 RandR rotation support to take advantage of this. But, I feel that it's far too late in the 4.3 release process to even consider work of this nature. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RandR status
> Sender: [EMAIL PROTECTED] > From: Thomas Winischhofer <[EMAIL PROTECTED]> > Date: Mon, 13 Jan 2003 16:59:55 +0100 > To: [EMAIL PROTECTED] > Subject: RandR status > - > I'm sorry if this is a FAQ: > > Is RandR going to be in 4.3? Yes, but it may be disabled by default unless we can get a bug fixed in a non-intrusive way. Right now, it is breaking support for rotation in drivers that support rotation from the config file. The current implementation is resize only in the XFree86 server; there are full implementations in the kdrive server. > > If so, are there any changes/additions to be made in the drivers in > order to support RandR? Not really at this time. The intent is to just use the current interfaces for resolution change, and follow up with a more complete infrastructure in the release after this. > > If so, is there any documentation available on how to do this? > As resize can be done with existing interfaces, no. We'll have to add interfaces to support reflection, rotation, etc, in the future. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RandR status
> Sender: [EMAIL PROTECTED] > From: Thomas Winischhofer <[EMAIL PROTECTED]> > Date: Mon, 13 Jan 2003 16:59:55 +0100 > To: [EMAIL PROTECTED] > Subject: RandR status > - > I'm sorry if this is a FAQ: > > Is RandR going to be in 4.3? Yes, but it may be disabled by default unless we can get a bug fixed in a non-intrusive way. Right now, it is breaking support for rotation in drivers that support rotation from the config file. The current implementation is resize only in the XFree86 server; there are full implementations in the kdrive server. > > If so, are there any changes/additions to be made in the drivers in > order to support RandR? Not really at this time. The intent is to just use the current interfaces for resolution change, and follow up with a more complete infrastructure in the release after this. > > If so, is there any documentation available on how to do this? > As resize can be done with existing interfaces, no. We'll have to add interfaces to support reflection, rotation, etc, in the future. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another voice
On Mon, Jan 13, 2003 at 04:27:03PM +0100, Michel Dänzer wrote: > > Actually, there is a fork of XFree already - in dri.sf.net and another one > > of ati driver only in gatos.sf.net. > > I agree that the latter can be considered a fork, but the former > definitely isn't - the DRI and XFree86 repositories are regularly > synchronized. > >From my personal point of view it'd much better if all such projects were regularly synchronized - as r7500 owner I really don't know which driver should use gatos xor dri xor xfree plain driver? ;) Even after spending a few hours on various mailing lists I know nothing more becouse much of information there contradict mutually. Becouse I lack any documentation (and I often lack also skills writing such complex drivers) I can't know whether some XYZ feature is a bug or a side-effect, or is planned, being developed or if it will never be implemented because of missing hw documentation). And often searching engines give out unsorted and huge mess. The result is: a) [mostly] I ignore the bug because I expect the developer knows about it b) I search the forums and mailing lists and (if I don't fall to a) ;) I ask there some of additional information about (and I often get flamed or no response ;) c) if contact the maintainer and supply all possible information about the problem. The c) has been the most effective option (most of problems solved or at least briefly described - unsolvable, no time ...). But it this way was prefered by hundred of people or simply used too often then ... Bugzilla may help a bit (if it was activelly maintained). I don't expect bugreports regarding x-protocol. I'm quite sure that most of reports would concern drivers. The plus is that such bugreports can be easily categorized (per driver) and seen only by interested people (driver maintainer, contributors and maybe some power-users), another that (at least some) people will stop asking about the same all over again (there are even volunteers outside projects who often help marking duplicates and nonsential bugreports). More general reports could be forwarded elsewhere. Another point of view: Bugzilla can be thus seen (and used!) as an email filter + advanced search. Thus (if set properly!) can substantively reduce the amount of mail a developer/maintainer/contributor of a smaller part has to skim through. Of course, you could subscribe into many smaller lists than devel but who does it (especially if the chance of any response is smaller?) There are also people who do care about a particular bug only... Kamil ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
ATI Mobility U1/igp320M/device 0x4336 <- X setup issue
Title: ATI Mobility U1/igp320M/device 0x4336 <- X setup issue I'm attaching the output from scanpci -v. When I run the command "XFree86 -configure" it give the message: XFree86 has found a valid card configuration. Unfortunately the appropriate data has not been added to xf86PciInfo.h. Please forward 'scanpci -v' output to XFree86 support team. from everything I've read, this card should be radeon compliant and HP told me that it acts as a PCI card, not AGP since it is an integrated chipset. I have only a very basic understanding of C. If I knew what to do, I'd be happy to make the changes myself. If it's not a trivial task to update the header file, could someone else lend a hand? Looking at hp's support forums, there are quite a few folks who would prefer more than vesa/fbdev support on their laptops. Thanks! Ben Hastings CPM/Software Test Analyst Science Direct 1-800-227-9597 x58538
Re: Another voice
On Mon, 13 Jan 2003, Vladimir Dergachev wrote: >> >http://www.advogato.org/person/mharris/ >> > >> >There are allot of interesting comments here by Mike, >> >particularly his interest in forking XFree86 and creating his >> >own work. >> >> You seem to have some deep misconceptions. The only things I've >> mentioned on there are my decision to branch the Radeon driver >> and to contribute stuff back to the XFree86 project. How that is >> seen as a fork of the entire project, I'm unsure. I'll be the >> first to admit that I'd be completely unable to fork the entire >> XFree86 project on my own, and that it would be a very large >> amount of work without any guaranteed gains in return. >> > >Actually, there is a fork of XFree already - in dri.sf.net and another one >of ati driver only in gatos.sf.net. > >One more wouldn't hurt, but Mike - why do you want to fork Radeon driver ? Sorry to mix terminology in what some might feel is pedantical, however the term "branch" the Radeon driver seems more appropriate than fork, although it is possible I may have myself used the term fork somewhere. Branch is much more accurate, as I believe the term "fork" means something more hostile and ill intentioned, and "branch" means concurrant development which gets merged back to the trunk. I don't however have access to making a branch in XFree86 CVS, and I know better than to ask for one frivolously, as David has explained how useless the quality of code I generate is, I take that to be indicative that my chances of getting CVS write priveledge to XFree86.org is quite low in the future, if ever. I don't however take offense, as the DRI project doesn't have access either, and they are a number of very talented people too. I do want to make ATI's contributed code available in a useable form to ATI users as soon as possible once ATI or someone else provides useful patches to the open source community however, and nobody is currently providing that to the community. I believe I can fulfil that role however until CVS catches up. Just takes a bit of time to do the work that's all. You don't have CVS write access, however you've managed to put together a successful driver yourself too, which makes me a bit curious why GATOS has remained a separate (and rather succesful) project from XFree86.org for so long. I've never chatted with you before about it I don't believe, but I've often wondered why GATOS has never been integrated into XFree86 or DRI. It's useful as is nonetheless, but it'd be great to see such developmental efforts get incorporated into XFree86's main codebase so more users could benefit from one-driver-does-it-all so to speak. My assumption has been all along that you've had difficulty getting others to look into merging your changes, and decided it was easier to maintain your own codebase entirely than to twist people's arms to look at your code and provide feedback. I guess now would be a good time for me to just ask. ;o) So.. any chance of GATOS getting into XFree86? ;o) I know ATI users would absolutely love this functionality, and I would too. Any comments, feedback, appreciated. Thanks, TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Mon, 13 Jan 2003, Vladimir Dergachev wrote: >> Where hardware is concerned, such as the video drivers, I would >> agree. More often than not, having the hardware documentation is >> required, or is at least quite helpful. However, the entire >> XFree86 sources contain libraries, extensions, applications, >> fonts, documentation, and many other things - all of which >> other potential developers could volunteer to work on too, >> without requiring hardware documentation. > >They could volunteer to work on it, yes. However a good many of open >source efforts starts with need to scratch your own itch. All I am saying >is that hardware-independent itch can be scratched without messing with >Xserver internals. Absolutely. >> The Linux kernel for example has a very large source code base, >> and has countless developers whom have worked on it under the >> Bazaar model, and the code is quite high quality. People write >> good patches, and people write bad patches regardless of what >> model of development is used. However, I think that due to the >> bazaar style of development the kernel is done under, the bad >> patches get weeded out much more easily, whereas with the >> cathedral style of development, they're more likely to simply get >> ignored or cast aside. >> >> Is that similar to what you mean? > >This seems to be another angle ;) My point was that the easier it is for >patches to go in the more attractive the project looks to new developers. I couldn't agree with you more. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On 13 Jan 2003, Petter Reinholdtsen wrote: >Date: 13 Jan 2003 16:41:24 +0100 >From: Petter Reinholdtsen <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Reply-To: [EMAIL PROTECTED] >Content-Type: text/plain; charset=us-ascii >Subject: Re: [Devel] Re: Another voice > >[Egbert Eich] >> Up to now it is not even clear who should be able to >> submit to this bug tracking system: >> Should it be internal only? >> Should only projects like GNOME, KDE etc and distributions like >> RedHat, SuSE, Mandrake be able to submit bugs? >> Or should it be open to the general public? > >It should be open to the general public, but require a working email >address to submit and modify bug reports. Absolutely. Bug reports submitted without a real email address are 99% of the time completely and totally useless. I would strongly oppose any notion to allow anonymous bug reporting such as sourceforge's [EMAIL PROTECTED] type of bug reports. Such bug reports suck because XFree86 related bug reports often require someone to ask for more information before something can be investigated, and if the person doesn't have a real email address, there is no way of saying back "I need to know foo", at which point such bug reports are no better than the previously private [EMAIL PROTECTED] bug report address. I believe bugzilla requires valid logins for everyone already though, so that's not a problem, or shouldn't be. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Mon, 13 Jan 2003 [EMAIL PROTECTED] wrote: >One could go through an evolutionary process, from developers, to invited >others, to fully open. That's an idea I hadn't thought of, one which could be good too possibly. It would remove the potential threat of incoming bug reports of the form: = My server no works can for the problem help? It is Acer video and is to the KDE no works when I run. = (A real email I've received) We've all seen those type of reports, and we all know how completely and totally useless they are. But, I think also that once enough people get involved, such reports can be trivially triaged, or volunteers can extract more infor that is useful from someone until there is a valid report to be looked at by a developer. >The question still is: is there enough interest among the >developer community to it be worth the investment to get it set >up? If no-one is going to use it, why bother? On the other >hand, if enough of us say, as I do, that we're dropping too many >problems on the floor and such a system might be useful if it >gets established correctly, I think there is enough resources to >start getting it set up. But those resources should go >elsewhere if there is no interest. Personally, I'd love to see interest from core developers to at least poke their toe in the water, and some of them have already suggested they'd give it a shot and if it worked out ok, they'd use it. I think that a bug tracking system would be a benefit all around however, as various distribution users, vendors, and also stray do it yourself people could all look for answers in one spot, and could report distribution non-specific bugs in one spot. There are benefits IMHO for all groups involved by having a centralized bug tracker, and avoiding duplication of effort, etc. I volunteer to spend time working with publically reported bugs in a central database either way. I do triage in our own bugzilla for XFree86 related issues, and it's not likely much more work for me to snoop through a public database looking for more duplicates too, and providing help to people in the public database having the same problem perhaps as one of our users. The more people who do that, the more useful stuff we can supply to other X developers, including the core team. I'd very much like to see a bugzilla be something we can use to give the core team something good. More patches, more widely tested patches, more useful feedback, you name it. I hope they want to use it too of course, but that's only if they find it beneficial to personally do so. If they don't in the end (however I have faith that they will once they see it in action) it would still benefit non-core members by being able to access a central bug database and work together with each other IMHO. I'd be interested also in hearing feedback and comments from Debian, Mandrake, SuSE, Gentoo, FreeBSD, NetBSD, OpenBSD, Caldera, and other Linux and BSD distribution XFree86 package maintainers, and other developers also. I've talked personally with some of them already, but the more who get involved the better. We all benefit, and everyone's feedback is very valuable. Take care, TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RandR status
On Mon, 13 Jan 2003, Thomas Winischhofer wrote: >Date: Mon, 13 Jan 2003 16:59:55 +0100 >From: Thomas Winischhofer <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Reply-To: [EMAIL PROTECTED] >Content-Type: text/plain; charset=us-ascii; format=flowed >Subject: RandR status > >I'm sorry if this is a FAQ: > >Is RandR going to be in 4.3? R is in CVS already and has been for a while now. We've found out yesterday that the andR part doesn't work however. >If so, are there any changes/additions to be made in the drivers in >order to support RandR? Egbert suggested in the last day or so that a 2 line patch might be needed, but that such change might be too experimental for 4.3.0. >If so, is there any documentation available on how to do this? Keith or Jim would be best to answer that.. Take care, TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another voice
On Mon, 13 Jan 2003, Kamil Toman wrote: >Bugzilla may help a bit (if it was activelly maintained). I >don't expect bugreports regarding x-protocol. Indeed, such type of bug report is extremely rare. >I'm quite sure that most of reports would concern drivers. I can back that up with my own experience. Almost all bug reports that come into our database are either: 1) Driver related 2) Configuration related 3) App related There are other bug categories too of course, and it would be interesting to divide up X into different categories, then go through and get statistics on those categories. >The plus is that such bugreports can be easily categorized (per >driver) and seen only by interested people (driver maintainer, >contributors and maybe some power-users), another that (at least >some) people will stop asking about the same all over again >(there are even volunteers outside projects who often help >marking duplicates and nonsential bugreports). More general >reports could be forwarded elsewhere. Yep. That is basically what I see on a day to day basis. >Another point of view: Bugzilla can be thus seen (and used!) as >an email filter + advanced search. Thus (if set properly!) can >substantively reduce the amount of mail a >developer/maintainer/contributor of a smaller part has to skim >through. Of course, you could subscribe into many smaller lists >than devel but who does it (especially if the chance of any >response is smaller?) There are also people who do care about a >particular bug only... Indeed. Some developers just read the bugzilla emails, and prefer to work with stuff in that context, only using the web interface when they need to. I use both myself. I sometimes use my email folder for quick searches, and to flag bug reports in pine with a * for looking at later today. There are many ways of using the tool though as there are developers that use it. ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On 12 Jan 2003, Eric Anholt wrote: >> You know I never for the life of me understood that. I would have thougtht >> that every developer would be interested and see if their patch bumped horns >> with another. >> As former postmaster I received, I think, a total of two requests. Weird. >> >> Georgina > >Who's the new postmaster? I sent in my request to be added to patch@ >six days ago, but no response so far. > >Also, is there any reason for the standard patch-queue list to be >private? If it's destined for the public source tree, why not make it >subscribable through mailman, too? Which would also have the benefit of patches being useable and testable by other people in the wild without waiting for XFree86.org to have volunteer time to review and possibly apply a patch. Also, someone might submit a patch, that isn't perfectly correct, have it sit in the patch queue for 1 month, or possibly 4 or more months, and in the mean time change hardware or circumstance and not care about the issue any more. Then if an XFree86.org CVS commiter goes to review it, and finds something that needs fixing (but isn't able or perhaps willing to do it themselves), assuming they do try to notify the person who submitted it - what if the person's email address is no longer valid? What if they do contact the person and the person no longer cares? Publically visible patches, mean that other people can test them and use them right away and provide feedback on wether or not the patch does what it says it does. Some people will also be able to vouch for the correctness of the patch. This would relieve some of the things that people who apply patches to the repository need to do first, and it would also get more patches more widespread testing. How much end user testing do patches get that were submitted 6 months before they were applied, and then a release shipped only a couple of months or so later? Perhaps between the time it was applied and the time it shipped, nobody even tested it. Also, more and more desktop oriented users are springing up. They aren't really compile-it-yourself types, so if they report a bug, they might not see if it is fixed until the next release (or erratum) from their given distro comes out. By having patch lists public, it enables more people who are compile savvy to test things earlier, and allows more feedback to be given to the tree maintainers of what is good, and what sucks, helping them to trim down their workload by calling crap crap earlier in the cycle. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Sun, 12 Jan 2003, Mark Vojkovich wrote: > Is a bug tracking system necessarily imposing? Perhaps it's not >well understood what's really involved with one. Keeping track >of what is broken and when it gets fixed seems like a good idea >to me. What does this impose on developers? Nothing is imposed on developers at all. If we were to hypothesize that tomorrow, all of a sudden a bugzilla database sprung up for XFree86, I think it would take a while - not long, for it to get set up, organized, get the quirks out, and start getting useful data input. There are already tonnes of volunteers knocking on the door to triage, and help maintain such a thing. I can't speak for anyone but myself, but all I'd request, would be for people to look at such an effort with an open mind, and to at least voluntarily "try" it on their own free will, and provide whomever would be running it with feedback about what they like/dislike, and such. In other words, all that is really being requested, is open mindedness, and open co-operation to try new things that are likely to help the project. > I think frivilous bugs and non-bugs being reported could be >a potential time waster. Yes, they can be a bit of a time waster. That's why developers would not at all be expected to do anything they do not want to do voluntarily. The whole idea is _completely_ volunteer based. Volunteer as in, people contribute to the bug database only if they want to, and how much they want to, and they only do _what_ they want to also. I for one would be the first person to tell someone to take a long jump off a short dock if they demanded anything of me. I'm sure many people reading this email will vouch that I do that right now in fact. In fact, I volunteer to be the person who tells other people to take a long jump off a short dock, if they make any demands on other developers also. ;o) >Who gets to file bugs? It might be a good idea to discuss that with the various people whom would actually volunteer to help out at the beginning, and also receive input from those who aren't willing to volunteer, but are willing to look at it with an open mind. Personally, I think having the database be open to the public is a good idea, and it has proven to be a good idea with many other large projects. As long as there are people to triage, and trim out the riff raff and useless crap (like 90% of the bug reports traditionally received on the existing bug report mechanism), and people volunteering to help get bug reporters to provide proper information and details until there is something useable for a developer to look at. Many people have volunteered already to participate in such an effort, and many of those volunteers already do triage on other existing bugzilla databases out there. >Who determines whether they are legitimate or not? I suppose anyone can do that. If a developer says "this is not a valid bug report", that is pretty close to the final word in lieu of more details from the reporter or someone else. Some bug reports are rediculously useless - no question. When I get those, if I can't get information out of someone that is useful, their bug report hits the can. >Does a bug tracking system necessarily complicate the work that >some developers do? I can speak from both sides of the fence on that one. I used to HATE bugzilla (and I can hunt down my email postings on this subject for proof if need be ) until a short while after I begun maintaining X for Red Hat. I get bug reports via email still, and I also get bug reports from the XFree86 bug report list. I can say, without a question, the quality of the bug reports received on the [EMAIL PROTECTED] bug submission list, is close to zero on 60-90% of all submissions. Bugzilla bug reports concerning XFree86 on the other hand, generally have a much higher information to noise ratio, and since there is a simple method of 2 way communication involved, I can easily ask the person for more information. Also, _anyone_ else can also ask the person for more information, and many people do, including other employees, other users, and a few people who just seem addicted to helping with bugzilla. There are a heck of a lot of volunteers out there though that take care of some of the tedious boring stuff like finding duplicates and closing them as such, closing already fixed issues, requesting more information, and the variety of other things that bug tracking needs doing. I delete bug reports sent via email directly to me on first sight, and I also delete emails unread where someone has replied to the email message bugzilla sends out that specifically says "do not reply to this email". I do so because if I respond, then I have to email back and forth with the person, and remember their situation, store the emails that are related to their problem, and stand on my head simply because they can't read "do not reply via ema
Re: [Devel] Re: Another voice
On Sun, 12 Jan 2003, Georgina Economou wrote: >What about areas that come in that are distro specific, does that go to the >distro maintainer of to XFree86? If a bug is reported, and the reporter indicates they are using FooLinux, if it can be shown that it is easily a FooLinux specific problem, then there are 2 possibilities I can see: 1) The report has no useful purpose in the bug tracker, and could be closed something like: " This appears to be a FooLinux specific problem you are having, which should be reported to FooLinux in their own bugtracker (optional hyperlink to FooLinux's bug tracker). After filing a bug report at FooLinux, please add a link to that report here so that other users searching for bugs can find your link to FooLinux's bug tracker also" Or, if someone just doesn't feel like going to that level of detail, even just a "This is a FooLinux specific problem you're having, and not a generic XFree86 problem. Please report it to them instead." Of course, more friendlier responses are always more beneficial to users. Perhaps canned replies should even be present for people to choose. Another option is: 2) Add distro specific maintainer to CC list or reassign bug to him/her. Presumeably, all people who maintain X at various different distributions and OS's out there, will want to have bugzilla accounts on the XFree86 bug tracking system. They should be carbon copied on bug reports that are known to be distro specific, or that one suspects might be distro specific. I can't speak for other distribution maintainers, but I for one don't want Red Hat specific bugs clogging up a public project bug tracker any more than I want to read distro specific bugs from some other distribution. I doubt anyone else would either. >Is the XFree86 bugzilla now repsonsbile for all distro bugs, Not by a long shot. How could/would they be? >and there are lots? That's a hard question to answer. Some bug reports are simply "packaging" errors, or errors related to packaging defects. Those such issues, are obviously distro specific, and for the case of RHL, I would expect them to get assigned to me (either by someone else who spots it, or by myself noticing it), in which case I would want it moved to our bugzilla and would probably do so myself, and close out the upstream report, crossreferencing it with our database. This is basically what happens with projects like GNOME et al. I believe. Distributions _want_ to know what bugs they have, so they can fix them and make better products for users. To quantify it however is rather difficult. I suppose someone could volunteer a day or so of time to go through a given distro's database and try to fairly quantify such bug reports to get an idea. It'd be a boring job to perform just to get the statistics though. I'm not sure the stats would be all that valuable though. Any public tracker will definitely end up getting distro specific reports. It's the job of distro maintainers, and bug triage people to strip those out of the public database, and either reassign them to the known distro person, or close them out and refer the person to their own distro's tracker. Having a FooLinux specific bug report in a common bug database isn't going to get it fixed for FooLinux users, and isn't going to be useful to anyone else, so FooLinux doesn't benefit at all from such. On a different note however, I've seen a great many bugs get reported to [EMAIL PROTECTED] in the past and in looking at many of them, I see they are reported by Red Hat Linux users. Many such reports do not contain enough information to determine wether or not they are distro specific or not, however percentagewise, I would say most are not, and are common driver problems instead. I respond privately to many of these people however it is a tedious process via email. It is much much simpler via bugzilla, and so often, my response to them is to file their report in Red Hat bugzilla. That way I can at least attempt to do troubleshooting with them in a sane manner that is viewable and trackable by others. In such cases, if a bug turns out to be RHL specific, then obviously, it's mine. If not, then it's whoever-out-there-including-myself gets to fix it first based on their various priorities. With a bugzilla for X, the process is similar but also easier to manage. I'd be getting emails still of incomig reports, but can simply click on the hyperlink, bring it up in central bugzilla, ask a couple of questions, and then perhaps fix it and send in a patch, perhaps say "this is a Red Hat bug" and close it, crosslinking it to our bugzilla, or acknowledge the problem if I can verify it, and whoever down the road, myself included can get to it and fix it, then more people benefit sooner. >How would bugzilla handle issues where the changes came in from >after the merge from the XFree86 CVS? Would it
Problem on RH Linux 7.3
Hi guys, I have a programming problem on RH Linux 7.3. I wrote a X-motif program. It works fine on Solaris 7 or 8, and windows system if an X server is installed. So I wounder if it is the problem for XFree86 server. I want the background color of text to be blinking. If I just simply change the background color and redraw it by myself. It will have a performance problem( say 100 blink text ). So my solution is define a private colormap. Every time I need a blink effect, I redfine the background color in colormap, and then call XStoresColors and XFlush, let X server to redraw it. I just simply change the black color to white and non-black color to black. Does anyone has done the same thing as I do?? If you know the answer, please tell me!! Thanks, Lee Yu _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
> > >> The Linux kernel for example has a very large source code base, > >> and has countless developers whom have worked on it under the > >> Bazaar model, and the code is quite high quality. People write > >> good patches, and people write bad patches regardless of what > >> model of development is used. However, I think that due to the > >> bazaar style of development the kernel is done under, the bad > >> patches get weeded out much more easily, whereas with the > >> cathedral style of development, they're more likely to simply get > >> ignored or cast aside. > >> > >> Is that similar to what you mean? > > > >This seems to be another angle ;) My point was that the easier it is for > >patches to go in the more attractive the project looks to new developers. > > I couldn't agree with you more. > Personal experience: I had a simple patch to fix a typedef in the kernel, mailed to Alan Cox; reply less than 5 minutes later: 'applied to my pool'. Appeared in the next Linux release 3 days later. These days, with bitkeeper, the patch would be widespread almost instantly. This is *strong* incentive to contribution. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
Keith Packard writes: > Around 10 o'clock on Jan 13, Egbert Eich wrote: > > > To make RandR rotation work one needs layer support. I have a > > sample implementaion (it takes two lines per driver) however > > this is too experimental to bee added to 4.3 I'm afraid. > > I have done a more complete investigation in September and decided that the > changes needed were significantly more extensive than could be reasonably > accomplished in the timeframe available. > > As resize presents the largest application visible effect from the > extension, and also significant value for existing users, I thought > providing just resize was of enough benefit that it should be included > even if the rotate portion wasn't possible in the current timeframe. What about rotation? I have added rotation using layer support and it didn't seem to be difficult. I have not spent any thoughts on setups which suport more than a single depth in hardware. They will most likely not work as they presently require cfb code which may not work well with shadow and layer. However this shouldn't be a problem: the driver just doesn't initialize layer if it sets up such a mode. > > Another factor in my thoughts was the work Mark is doing related to 5.0 > driver interfaces; early discussions lead me to believe that rotation in > that environment would be significantly easier and more functional, so it > seemed to me that making significant changes in the 4.x architecture to > support a feature of marginal current utility made less sense than perhaps > waiting for a different driver architecture which would make the task > easier. I neither found the modifications I made difficult nor significant. I fact I was able to add layer support without having to modify any other code. I just made some changes to the ramdac code to allow for HW cursor rotation. This however isn't really necessary as one just needed to disable the HW cursor when rotation is on. > > With the release of tablet PCs that essentially require rotation for their > intended use, I may have to reevaluate this position. I was hoping that > the video chips in use for those devices would support hardware rotation > as some PDA chipsets do, but it doesn't appear to the be case. > > The acer and toshiba tablets use the silicon motion chip which provides > accelerated rotated blts, but not actual rotated frame buffer support. The > accelerated rotated blts are used to make a shadow frame buffer > implementation significantly faster, and I would want any XFree86 RandR > rotation support to take advantage of this. But, I feel that it's far too > late in the 4.3 release process to even consider work of this nature. > I don't know how many chipsets do support rotated blits. However a pure SW implementation would be better than nothing. The delayed framebuffer updates in your shadow code help a lot to give the rotated version a snappy look and feel. It feels by far snappier than what we currently have. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
> > >> The Linux kernel for example has a very large source code base, > >> and has countless developers whom have worked on it under the > >> Bazaar model, and the code is quite high quality. People write > >> good patches, and people write bad patches regardless of what > >> model of development is used. However, I think that due to the > >> bazaar style of development the kernel is done under, the bad > >> patches get weeded out much more easily, whereas with the > >> cathedral style of development, they're more likely to simply get > >> ignored or cast aside. > >> > >> Is that similar to what you mean? > > > >This seems to be another angle ;) My point was that the easier it is for > >patches to go in the more attractive the project looks to new developers. > > I couldn't agree with you more. > Personal experience: I had a simple patch to fix a typedef in the kernel, mailed to Alan Cox; reply less than 5 minutes later: 'applied to my pool'. Appeared in the next Linux release 3 days later. These days, with bitkeeper, the patch would be widespread almost instantly. This is *strong* incentive to contribution. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
- Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Egbert Eich" <[EMAIL PROTECTED]> Sent: Monday, January 13, 2003 10:45 AM Subject: Re: [Devel] Re: Another voice > > Sender: [EMAIL PROTECTED] > > From: Egbert Eich <[EMAIL PROTECTED]> > > Date: Mon, 13 Jan 2003 11:10:14 +0100 > > To: [EMAIL PROTECTED] > > Subject: Re: [Devel] Re: Another voice > > - > > Matt Wilson writes: > > > > > > I'm not attempting to bully anyone, nor have I argued that you or any > > > other member (individual or corporate) of XFree86. However, there are > > > plenty of volunteers that are offering to set up and maintain a bug > > > tracking system for you. I think that such a project would be much > > > more successful if it were endorsed by XFree86 and integrated into the > > > development policy for the project. > > > > > Matt, I'm *very* uncomfortable with saying a bug tracking system should become > policy for any project unless/until a project has a pretty universal > buy in that it should be that way. We're a *very* long way from that point. > > > > > Sorry, this is not how it goes. We won't be willing > > to adopt anything blindly. There is a German saying > > applying here: > > 'Never buy a cat in the bag!' > > > > 1. First there should be a proposal > > Seems like that's what some of us have been making, though we haven't > fleshed it out completely yet. Without discussion, it is difficult > to make it concrete. Ergo, the discussion. > > > 2. Secondly there should be a test implementation > >as proof of concept we can work with and see > >how well it goes. > > Entirely agree. > > > 4. Thirdly this should be evaluated > > - if we think it is usable at all. > > - what modifications we would like to see. > > Entirely agree. > > > 5. The modified system needs to get retested and reevaluated. > > Entirely agree. > > > 6. This is the earliest stage we can talk about a more or > >less formal policy. > > Entirely agree. Any policy, however, can/should only occur if there is > nearly complete consensus. We're a long way from that, if ever. > > > > > > Up to now it is not even clear who should be able to > > submit to this bug tracking system: > > Very good questions on which multiple opinions are solicited. > > > Should it be internal only? > > Should only projects like GNOME, KDE etc and > > distributions like RedHat, SuSE, Mandrake be able to > > submit bugs? > > Or should it be open to the general public? > > > > I personally argue for openness, with a couple major caveats: > > o The verbiage around bug submission should be carefully crafted to > try to help with the triage process between projects (e.g. > if your server crashes, its definately an XFree86 bug; if it is bad > rendering, asking people to verify it is specific to a particular > piece of hardware, else report to the appropriate project's bug system, > and so on. > > o the states of a bug inside the database allow for triage, with > states like "bug verified", duplicate, etc. I suspect/expect many developers > might ignore problems until they've been marked verified. That's the point > of a triage process: to bounce the problem the right direction so that not > all bugs get looked at by all people (or no people). > > One could go through an evolutionary process, from developers, to invited > others, to fully open. > > The question still is: is there enough interest among the developer community > to it be worth the investment to get it set up? If no-one is going to use > it, why bother? On the other hand, if enough of us say, as I do, that > we're dropping too many problems on the floor and such a system might > be useful if it gets established correctly, I think there is enough > resources to start getting it set up. But those resources should go > elsewhere if there is no interest. And who would determine the 'no interest'?. Is this mutual or some arbitary self-appointed person? Georgina > >- Jim > > -- > Jim Gettys > Cambridge Research Laboratory > HP Labs, Hewlett-Packard Company > [EMAIL PROTECTED] > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
- Original Message - From: "Mike A. Harris" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 13, 2003 12:34 PM Subject: Re: [Devel] Re: Another voice > On Sun, 12 Jan 2003, Georgina Economou wrote: > > > > >I could see how one distro could use bugzilla very well against > >another's for slick marketing > > More conspiracy theories? ;o) A common theme lately. ;o) > > Anyway, if a bug is distro specific, then IMHO it is rather > obvious, and even if some distro was crooked as you seem to > suggest, there would be enough other people involved that were > not from the crooked distro to kick their ass. Slashdot is a > good place to report such violations. > No Mike, I am talking about who controls the reports and who sees them. Who owns the data? This is RHAT's baby, Bugzilla, so I take it that they would be a serious Admin to this and would have the ability to pull data as they want, without asking XFree86 for it. I can see that RHAT would then claim that they have less bugs per bugzilla reporting etc and so forth and then would make lists like: Top Buggy Code Top Bug Squatter and other absurdities ad nauseam. My concern is where does an extent example exist of how Bugzilla is being used by a non-RHAT owned project, like XFree86. And finally, if RHAT has Bugzilla on their own distro right now, why do you need us at all? You already have the setup, the information etc. I don't see why we need to be involved, either using or reporting to it. Tell me or preferably show me how I am wrong. Georgina ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Mon, 13 Jan 2003 [EMAIL PROTECTED] wrote: >> >This seems to be another angle ;) My point was that the easier it is for >> >patches to go in the more attractive the project looks to new developers. >> >> I couldn't agree with you more. >> > >Personal experience: > >I had a simple patch to fix a typedef in the kernel, mailed to Alan Cox; >reply less than 5 minutes later: 'applied to my pool'. Appeared in the next >Linux release 3 days later. These days, with bitkeeper, the patch would be >widespread almost instantly. > >This is *strong* incentive to contribution. I have had many similar experiences with different projects as well. Most projects like that have more heirarchial tree structures of developers though I find than a flat list. I think it's a difference that shows up more in the bazaar type of development more naturally than it could in the cathedral style. Perhaps the age old bazaar style motto: Release early, release often. Could be also enhanced with: Patch early, patch often. I know that many people don't contribute code simply because they've been ignored, or FEEL they've been ignored, and have no incentive to attempt to try and contribute again. So I can certainly relate to what you're saying also. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
Mark Vojkovich wrote: .. > >Where I work, bug tracking is necessarily tied to source control > in rather strict ways. Ways that I don't necessarily like, and > would not want to see XFree86 emulate. But I can envision non- > intrusive bug tracking. > > Mark. This might be a good topic for discussion. In the MediaGX driver, bugs have appeared and disappeared without any obvious coding changes. I have much less time than I devoted to the initial 4.X driver but a good tracking system might help. I found it too discouraging to work on the driver when changes elsewhere in the server changed the behaviour. Devoting more time might be the obvious solution but I prefer to focus on maximizing the results of whatever time I happen to devote. Richard ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: [Devel] Re: Another voice
All, I'm not sure what started all this, seems like we need a new paradigm. Maybe its time to *really* open source X. A foundation of some sort? I just hacker, so I'll go with whatever works. ..Just an idea. T ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Mon, 13 Jan 2003, Georgina Economou wrote: >> >I could see how one distro could use bugzilla very well against >> >another's for slick marketing >> >> More conspiracy theories? ;o) A common theme lately. ;o) >> >> Anyway, if a bug is distro specific, then IMHO it is rather >> obvious, and even if some distro was crooked as you seem to >> suggest, there would be enough other people involved that were >> not from the crooked distro to kick their ass. Slashdot is a >> good place to report such violations. >> > >No Mike, I am talking about who controls the reports and who >sees them. Well, that is up to whomever maintains the bugzilla database officially ultimately. They can put different private bug report categories in if they think it is useful and/or necessary. >Who owns the data? This is RHAT's baby, Bugzilla, so I take it >that they would be a serious Admin to this and would have the >ability to pull data as they want, without asking XFree86 for >it. Who owns bug report data? That's kindof funny. It's public bug report data, who cares really. Who "owns" gnome.org's bug report data? Does anyone? Does anyone even care, or have they ever even considered the concept? I don't know about you, or what other's think, but the concept you put forth is quite a foreign one to me. >I can see that RHAT would then claim that they have less bugs >per bugzilla reporting etc and so forth and then would make >lists like: Top Buggy Code Top Bug Squatter and other >absurdities ad nauseam. My concern is where does an extent >example exist of how Bugzilla is being used by a non-RHAT owned >project, like XFree86. Oh of course. Red Hat just can't wait to do all of these evil things, so they can make money selling XFree86 bug report data on CDROMs in magazines. >And finally, if RHAT has Bugzilla on their own distro right now, >why do you need us at all? You already have the setup, the >information etc. I don't see why we need to be involved, either >using or reporting to it. Tell me or preferably show me how I >am wrong. I've already said this many times. This has nothing to do with Red Hat. You just can't let that go, can you. *I*, *me*, Mike Harris, would like to work with the rest of the community that exists out there of XFree86 users, regardless of what OS they use, regardless of what distribution they use, in particular maintainers of other OS's and also other X developers whom aren't at a particular vendor or anything, but are just contributing to the open source of it all. I would like to get everyone working TOGETHER, because basically "united we stand, divided we fall". That's not a new way of thinking you know. In fact, it is the entire concept that brought open source into being in the first place. People working together towards a common goal. Right now, we don't have that with XFree86 as much as we could have. We've got many large groups of people using XFree86 in different distros and OSs with no collaboration between those distros on tracking bugs, fixing problems, sharing patches, and other similar co-operative and collaborative development. We've got "each man for himself", and I personally think that sucks. Every other distro X maintainer I've talked to so far also thinks that sucks. The entire open source community who is aware of this whole discussion thinks that sucks. My hope of course, is that XFree86.org IS interested and does want to participate in an open manner. However, wether XFree86.org decides to care about this at all or not, I still do care, and other maintainers and developers do care also. Everyone stands to gain from collaboration. If one group doesn't want to participate - fine. The other groups of people who do, can still benefit. Perhaps not as much with one group not present, but it can still be beneficial to everyone. Red Hat bugzilla, is Red Hat bugzilla. That doesn't help Debian out much now does it. Not if they have to poll our bugzilla, Mandrakes bugzilla, FreeBSD's bugzilla, and 40 others. It doesn't help us out either to have to poll Debian's bugzilla, Mandrake's, etc.All for what are common XFree86 bugs, common problems, patch submissions, and other things we all share anyway right now, just in a very extremely inefficient manner. I have to download Debian stuff and unpack it, and hunt through it to look for patches. Not being a Debian person myself, it's a bit awkward but not complex or impossible by far. It is a bit of work though. Debian also has to go out and poll Red Hat, Mandrake, etc. RPM packages for patches in hopes to find fixes for issues that they might not have fixes for. It is a lot of extra work to have to go out, get this stuff, pull it in, and have no collaborative feedback between each other about what any of it does. Users don't have a way of querying for XFree86 bugs. They have a way of querying 15 separate distro specific bug databases in hopes they find the problem t
Re: [Devel] Devel mailing list changes.
On Sun, 12 Jan 2003 09:14:19 +, David Woodhouse wrote: > >Please could we drop the [Devel] which serves no useful purpose and >just obscures the _real_ subject line? I'm very surprised anyone would object to this. This tag, which is common to mailman lists, is enormously useful for e-mail filtering. It certainly helps me distinguish mailing list messages from the depressingly vast array of e-mail I already get just by scanning my inbox. -- - Tim Roberts, [EMAIL PROTECTED] Providenza & Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Xterm on Mac OSX
Title: Xterm on Mac OSX Hello, Installing X11 on a Mac under OS 10.2.3 gave a problem related to typing inside xterm from a french keyboard. For typing ‘m’ I have ‘;’. Changing keyboard to US via software, does not change anything. Therefore, my question: does XFree86 4.2.1 support french keyboards? regards -- Hans Mittendorf-Labiche
Re: [Devel] Devel mailing list changes.
On Mon, Jan 13, 2003 at 11:00:01AM -0800, Tim Roberts wrote: > I'm very surprised anyone would object to this. This tag, which is common to > mailman lists, is enormously useful for e-mail filtering. It certainly helps > me distinguish mailing list messages from the depressingly vast array of e-mail > I already get just by scanning my inbox. The List-Id header is there precisely for the purpose of mail filtering, and if you're overwhelmed by email, you might want to use it. :-) On top of that, a subject tag of "Devel" is really not very useful; I subscribe to dozens of development lists, and "Devel" is fairly ambiguous. :-) Those of us who do filter our mail into separate folders and still read email on a 80x24 terminal would really like the screen line real estate back. :-) -- Edward S. Marshall <[EMAIL PROTECTED]> http://esm.logic.net/ Felix qui potuit rerum cognoscere causas. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
No Digests?
After coming in to find 170-odd messages from the new [Devel] list in my inbox, I decided to switch to digest mode. However, mailman tells me that "the list administrator has disabled digest delivery for this list". Any particular reason why this is so? -- - Tim Roberts, [EMAIL PROTECTED] Providenza & Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xterm on Mac OSX
Hans Mittendorf wrote (in a message from Monday 13) > Hello, > > Installing X11 on a Mac under OS 10.2.3 gave a problem related to typing > inside xterm from a french keyboard. For typing m¹ I have ;¹. > Changing keyboard to US via software, does not change anything. Therefore, > my question: does XFree86 4.2.1 support french keyboards? > Are you referring to XDarwin or the X11 package from Apple ? XDarwin has a global preference to set the keyboard layout, but it needs to be restarted to take effect. AFAIK Apple's X11 need a command line option to speficy the keyboard layout. Both X server can't change their layout from the main OS X menu bar. If you want to change your keyboard dynamically (ie without restarting X) on Mac OS X, you can use xmodmap(1). Appended below is set of xmodmap commands to set up an french layout keyboard. For more information see the xmodmap manual page. -- cut -- keycode 234 = Mode_switch remove mod1 = Alt_L remove mod1 = Alt_R add mod1 = Meta_L !add mod3 = Mode_switch !keysym Alt_L = Mode_switch Alt_L keycode 61 = at numbersign keycode 38 = ampersand 1 keycode 39 = eacute 2 keycode 40 = quotedbl 3 keycode 41 = apostrophe 4 keycode 42 = parenleft 5 keycode 43 = paragraph 6 keycode 44 = egrave 7 keycode 45 = exclam 8 keycode 46 = ccedilla 9 keycode 47 = agrave 0 keycode 53 = parenright degree keycode 54 = minus underscore keycode 50 = BackSpace Delete keycode 28 = A keycode 34 = Z keycode 55 = dead_circumflex dead_diaeresis keycode 56 = dollar asterisk keycode 12 = Q keycode 59 = M keycode 60 = ugrave percent keycode 58 = grave sterling keycode 108 = less greater keycode 37 = W keycode 24 = comma question keycode 62 = semicolon period keycode 63 = colon slash backslash bar keycode 64 = equal plus -- cut -- Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
- Original Message - From: "Mike A. Harris" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 13, 2003 9:38 AM Subject: Re: [Devel] Re: Another voice > On Sun, 12 Jan 2003, Andrew C Aitchison wrote: > > >> As far as commit access goes, frankly, if those asking for it could > >> establish a record of submitting complete and correct patches that didn't > >> need review (and Mike, your record on this isn't anything to boast > >> about), then you might have a better shot at it. > > > >We *need* more developer-hours on the commit process. > > That would be a nice thing to have. It works marvelously for all > other projects that have wider spread CVS write permissions. > > > >Maybe we have to put up with people like Mike making a few more > >mistakes while that they learn what they are doing wrong? > > I can't agree with you more. I, like any serious developer, > certainly want to be told about my mistakes, so I can correct > them, or have an opportunity to explain why I believe my changes > to be correct. > > There's only one patch that I can think of off the top of my head > which I've sent to XFree86.org which was rejected, to which I > later resent an updated version back with a good explanation for > why I thought it should be applied. I don't recall receiving any > feedback positive or negative since. It's not a major issue > however as I apply the patch to our sources regardless, as I > believe it to be correct, and it harms nothing at all. > > Most likely I will post that patch here again in the future - now > that the development list is publically open. I am then going to > get much wider peer review of my patch, and instead of getting > one person's opinion of it's correctness, I can get 100 people's > opinion. While it may not make the patch accepted into the > upstream official source even if 500 people agree, it would at > least make it a case 500 separate opinions, instead of the prior > case of one person's opinion in a position of power's versus one > person's opinion whom is not in a position of power. > > I'd rather be judged by 500 peer developers for the quality of my > patches and work than by one single person. > > > >They will learn a lot faster by doing it wrong than by submitting > >patches that may or may not appear months later in a very different > >form. > > Indeed. I will say that a while back, I approached David > concerning patches and what his expectations were. I have made > every effort to try and meet those expectations, and have > modified some of my ways of doing things further beyond what was > requested, in an attempt to provide the project with better > submissions. > > In the past, I would not only send in my own patches (which > incidentally get applied unmodified almost always), but I used to > submit many patches from others, usually - but not always with > proper attributions on them. Some patches you find in the wild > with no indication of whom the original author is. I just passed > the stuff all on upstream hoping that someone there would review > them for correctness, apply them, or reject them, etc. Some > patches I just picked up of mailing lists as I saw them, and > submitted them so they wouldn't get lost. Several of these > patches as you can imagine, were not the highest quality, and > many never got into the tree. Unfortunately however, many of > them were wrongly I believe attributed to ME, but of no fault of > my own for not being more organized with what I sent in, and > without as much process and procedure in place as what I have > now. > > I also used to send in patches that people sent into Red Hat via > bugzilla. We receive many patches of which I personally am not > familiar with the particular area of code that is being patched, > and so I am not always personally capable of vouching for a given > patch's correctness. > > In such cases, what should one such as myself do? Tell the > person to send their patch to XFree86.org instead? People get > PISSED BIGTIME! I've told people to please submit xkb patches > (MANY of the ones recently sent in to [EMAIL PROTECTED] which > subsequently were applied to CVS, and if need be I can provide > bugzilla bug ID's of proof). People go nuts! "I am a Red hat > user and you should apply my damn patch blah blah." > > If I send it to XFree86.org myself, then am I being judged as > having vouched for it's correctness? I didn't think I was > before, but after David's comments toward "my patches" before, I > took a hard line about it. For a few months I have refused MANY > patches submitted, and requested the person to send their patch > directly to [EMAIL PROTECTED], and that if it were accepted > upstream, I would apply it to Red Hat Linux also. I also have > stated to people when doing this many times (and this is also > bugzilla queryable for the conspiracy theorists amongst us) that > by submitting the patch upstream, ALL distributions get the > benefit, as does
Re: [Devel] Re: Another voice
- Original Message - From: "Mike A. Harris" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 13, 2003 11:52 AM Subject: Re: [Devel] Re: Another voice > On Mon, 13 Jan 2003 [EMAIL PROTECTED] wrote: > > >One could go through an evolutionary process, from developers, to invited > >others, to fully open. > > That's an idea I hadn't thought of, one which could be good too > possibly. It would remove the potential threat of incoming bug > reports of the form: > > = > My server no works can for the problem help? It is Acer video > and is to the KDE no works when I run. > = > > (A real email I've received) > > We've all seen those type of reports, and we all know how > completely and totally useless they are. But, I think also that > once enough people get involved, such reports can be trivially > triaged, or volunteers can extract more infor that is useful from > someone until there is a valid report to be looked at by a > developer. > > >The question still is: is there enough interest among the > >developer community to it be worth the investment to get it set > >up? If no-one is going to use it, why bother? On the other > >hand, if enough of us say, as I do, that we're dropping too many > >problems on the floor and such a system might be useful if it > >gets established correctly, I think there is enough resources to > >start getting it set up. But those resources should go > >elsewhere if there is no interest. > > Personally, I'd love to see interest from core developers to at > least poke their toe in the water, and some of them have already > suggested they'd give it a shot and if it worked out ok, they'd > use it. > I have not seen this comment. Who are these people to whom you are referring? Georgina > I think that a bug tracking system would be a benefit all around > however, as various distribution users, vendors, and also stray > do it yourself people could all look for answers in one spot, and > could report distribution non-specific bugs in one spot. There > are benefits IMHO for all groups involved by having a centralized > bug tracker, and avoiding duplication of effort, etc. > > I volunteer to spend time working with publically reported bugs > in a central database either way. I do triage in our own > bugzilla for XFree86 related issues, and it's not likely much > more work for me to snoop through a public database looking for > more duplicates too, and providing help to people in the public > database having the same problem perhaps as one of our users. > > The more people who do that, the more useful stuff we can supply > to other X developers, including the core team. I'd very much > like to see a bugzilla be something we can use to give the core > team something good. More patches, more widely tested patches, > more useful feedback, you name it. I hope they want to use it > too of course, but that's only if they find it beneficial to > personally do so. If they don't in the end (however I have faith > that they will once they see it in action) it would still benefit > non-core members by being able to access a central bug database > and work together with each other IMHO. > > I'd be interested also in hearing feedback and comments from > Debian, Mandrake, SuSE, Gentoo, FreeBSD, NetBSD, OpenBSD, > Caldera, and other Linux and BSD distribution XFree86 > package maintainers, and other developers also. I've talked > personally with some of them already, but the more who get > involved the better. We all benefit, and everyone's feedback is > very valuable. > > Take care, > TTYL > > -- > Mike A. Harris > > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
- Original Message - From: "Terrance A. Davis" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 13, 2003 1:06 PM Subject: RE: [Devel] Re: Another voice > All, > > I'm not sure what started all this, seems like we need a new paradigm. > > Maybe its time to *really* open source X. A foundation of some sort? Terrance could you elaborate on this? Georgina > > I just hacker, so I'll go with whatever works. > > ..Just an idea. > > T > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Devel mailing list changes.
>>Please could we drop the [Devel] which serves no useful purpose and >>just obscures the _real_ subject line? > >I'm very surprised anyone would object to this. This tag, which is common to >mailman lists, is enormously useful for e-mail filtering. It certainly helps >me distinguish mailing list messages from the depressingly vast array of e-mail >I already get just by scanning my inbox. That is why all GNU mailman mailing lists have a header line: X-BeenThere: [EMAIL PROTECTED] Other mailing list managers have the X-BeenThere line as well, or the X-Mailing-List line, or List-Id. As simple as it is to search the subject for [listname], it is to search for the designated X-BeenThere line, however searching for the X-BeenThere has the additional benefit of not cluttering up the subject line. This of course is one of the age old ongoing and neverending internet mailinglist flamewar discussion topics which endlessly rage on when they're brought up, and tend to be about 50% for and 50% against and end only when someone invokes Godwin's law or the list maintainer makes their official say in the matter final and requests the entire thread be dropped. ;o) Having been involved in these types of pointless 50/50 flamewars myself in the past one too many times, I decided a long time back to do something about it myself, but from my end. I procmail out the offending [listname] myself on lists that put it there. It only takes me a minute to set it up in procmail, and it gives an eternity of Subject line enjoyment from then onward, while all the people who like the [listname] weirdness get to enjoy their preference as well. ;o) For those who are as annoyed as I am by GNU mailman defaulting to putting [listname] in subject line headers, and most mailing list admins simply sticking to the defaults, here is the procmail rule that will undo this GNU braindamage should you find yourself receiving email that does this. ;o) Add this to your ~/.procmailrc # [EMAIL PROTECTED] mailing list :0 fhw * ^X-BeenThere:.*[EMAIL PROTECTED] | sed -e '/^Subject:/ s/\[Devel\] *//g' :0 A: devel For those not familiar with procmail and whom think the above looks insane, or resembles the lower half of sendmail.cf, what it does, is strip the [listname] out of the subject, multiple times if present, and then file it in the folder named "devel" (at the very bottom). The very top line by the way is merely a comment. To make it work with other mailing lists, simply change the comment at the top, the line that has X-BeenThere to reflect the mailing list at hand, and the subject line in between the []'s as well as the folder name at the very bottom. Enjoy many lists whom use the subject line listname annoyance in complete peace and harmony, and without getting sucked in to 50/50 flamewars. This leaves you tonnes more time to participate in other, much more worthy flamewars that might also seem equally pointless, but for which procmail can't help. ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another voice
> > > XFree86 project on my own, and that it would be a very large > > > amount of work without any guaranteed gains in return. > > > > > > > Actually, there is a fork of XFree already - in dri.sf.net and another one > > of ati driver only in gatos.sf.net. > > I agree that the latter can be considered a fork, but the former > definitely isn't - the DRI and XFree86 repositories are regularly > synchronized. This depends on your definition of fork. Btw GATOS code is synced with XFree86 cvs periodically and some code from GATOS did make it into XFree86 CVS. best Vladimir Dergachev > > > -- > Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI project member / CS student, Free Software enthusiast > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Mon, 13 Jan 2003, Georgina Economou wrote: [Extremely large nontrimmed quote snipped] >> Since I am a member however, I get both of these lists >> automatically and can't be sure if they're public now or not. > >A member? A member of what? The public lists? Not sure to what >memberhsip you are referring. Sorry.. XFree86.org member is what I was refering to. Prior to the recent list changes and whatnot, only XFree86 member developers to my knowledge had the ability to subscribe to the fixes@ and patches@ mailing list addresses. I asked other people and they were of the same assumption. Just seeking clarification of wether or not the general public has access to subscribe to the 2 patch mailing lists now or not after David declared the private lists to be no longer private. Since I've received them all along, as an XFree86.org member developer, and still do, it's easier to ask than to try and test because if I attempted to subscribe, being already a member, it would likely succeed. Thanks in advance, TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Mon, 13 Jan 2003, Georgina Economou wrote: >> Personally, I'd love to see interest from core developers to at >> least poke their toe in the water, and some of them have already >> suggested they'd give it a shot and if it worked out ok, they'd >> use it. >> > >I have not seen this comment. Who are these people to whom you are >referring? Mark Vojkovich and Egbert Eich have made comments in the thread that were rather encouraging that they would be open to consider trying it, but only if it made them no more work or hassles. There were slighter hints from others as well. [SNIP] -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
[about bug database system] > I'd be interested also in hearing feedback and comments from > Debian, Mandrake, SuSE, Gentoo, FreeBSD, NetBSD, OpenBSD, > Caldera, and other Linux and BSD distribution XFree86 > package maintainers, and other developers also. I've talked > personally with some of them already, but the more who get > involved the better. We all benefit, and everyone's feedback is > very valuable. I'm for it. I already go through the open PRs (GNATS database problem reports) we have periodically for X issues and work on narrowing them down. I would happy to work on a bugzilla database, which seems much more advanced. It would be valuable to me to be able to look at bugs and patches from other package maintainers. Currently I have to do this by snooping through mharris's SRPMS, and I haven't had a chance to look at what other distributions are doing. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another voice
> >> mentioned on there are my decision to branch the Radeon driver > >> and to contribute stuff back to the XFree86 project. How that is > >> seen as a fork of the entire project, I'm unsure. I'll be the > >> first to admit that I'd be completely unable to fork the entire > >> XFree86 project on my own, and that it would be a very large > >> amount of work without any guaranteed gains in return. > >> > > > >Actually, there is a fork of XFree already - in dri.sf.net and another one > >of ati driver only in gatos.sf.net. > > > >One more wouldn't hurt, but Mike - why do you want to fork Radeon driver ? > > Sorry to mix terminology in what some might feel is pedantical, > however the term "branch" the Radeon driver seems more > appropriate than fork, although it is possible I may have myself > used the term fork somewhere. Branch is much more accurate, as I > believe the term "fork" means something more hostile and ill > intentioned, and "branch" means concurrant development which gets > merged back to the trunk. First it forks than it merges.. I am pretty sure the fork is more noticable ;) > > You don't have CVS write access, however you've managed to put > together a successful driver yourself too, which makes me a bit > curious why GATOS has remained a separate (and rather succesful) > project from XFree86.org for so long. I've never chatted with > you before about it I don't believe, but I've often wondered why > GATOS has never been integrated into XFree86 or DRI. It's useful > as is nonetheless, but it'd be great to see such developmental > efforts get incorporated into XFree86's main codebase so more > users could benefit from one-driver-does-it-all so to speak. Historically, GATOS first started with a standalone program and we had to switch to messing with drivers when XFree86 4.x.x was released (as we couldn't play the tricks with video driver by telling it to use less memory than was available). Of course, there were a number of other advantages to this as well (not the least being at least partial compatibility with systems other than Linux). > > My assumption has been all along that you've had difficulty > getting others to look into merging your changes, and decided it > was easier to maintain your own codebase entirely than to twist > people's arms to look at your code and provide feedback. I guess > now would be a good time for me to just ask. ;o) > > So.. any chance of GATOS getting into XFree86? ;o) This question gets asked very often. The answer is that part of GATOS is already there. The part that isn't is TV-in and hardware Xv for mach64 cards. And it was submitted but it takes quite a while to get in. The major reason for this is that ATI driver maintainer and me have different priorities: My impression is that ATI driver maintainer (Marc please correct me) is primarily interested in * clean and working code that is easy to maintain which, IMO, is a worthy goal. My priorities are: * robust (non-crashing) driver that supports new features * experimentation with new approaches to programming and new features These two do imply "clean and easy to maintain" but in a significantly different way. Also both of us are quite short on spare time. Lastly there is one more issue with GATOS radeon code - to make video capture possible we need PCI DMA. Unfortunately, due to imprecision in ATI documentation the early radeon DRM driver was designed in such a way that it conflicts with PCI DMA into lower 64 meg of RAM (or whatever the size of AGP aperture is). The changes required will break compatibility with earlier modules, something that DRI maintainers are not willing to accept. (and I do not know DRI part of things well enough to make a workaround.. though this might change with 4.3.0 code - the DRI code is a lot cleaner) On the positive side GATOS code does present a valuable contribution in the form of code that is known to work even if the maintainer decided to rewrite the whole of it. Some of the hardware knowledge was not so easy to come by (and is not well described in ATI docs). best Vladimir Dergachev > > I know ATI users would absolutely love this functionality, and I > would too. > > Any comments, feedback, appreciated. > > Thanks, > TTYL > > -- > Mike A. Harris > > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Mon, 13 Jan 2003, Mike A. Harris wrote: > On Mon, 13 Jan 2003 [EMAIL PROTECTED] wrote: > > >One could go through an evolutionary process, from developers, to invited > >others, to fully open. > > That's an idea I hadn't thought of, one which could be good too > possibly. It would remove the potential threat of incoming bug > reports of the form: > > = > My server no works can for the problem help? It is Acer video > and is to the KDE no works when I run. > = > > (A real email I've received) > > We've all seen those type of reports, and we all know how > completely and totally useless they are. But, I think also that > once enough people get involved, such reports can be trivially > triaged, or volunteers can extract more infor that is useful from > someone until there is a valid report to be looked at by a > developer. > Actually they are not totally useless. There is someone on the other end who committed to communicate with you and wants to try to fix whatever is bothering him. Also, judging from the grammar the person is not very comfortable with the English language, it is possible s/he is quite good technically but chose just a few words because of difficulty with English. My typical response is to ask for more thorough description, logs and output from select utilities (be sure to include one that requires root access) and suggest to look at man pages for explanation. If the person does not know they have chance to learn (a good thing IMO) and if they do there is a useful bug report. Speaking of useless reports the ones that really bug me is when there is a good description and I have no idea what causes it and cannot reproduce the problem either. Sometimes even logging into remote machine does not help. *this* would really benifit from being on the web so a lot more people can take a look. best Vladimir Dergachev ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
ATI card addition to xf86PciInfo.h
I'm attaching the output from scanpci -v. When I run the command "XFree86 -configure" it give the message: XFree86 has found a valid card configuration. Unfortunately the appropriate data has not been added to xf86PciInfo.h. Please forward 'scanpci -v' output to XFree86 support team. from everything I've read, this card should be radeon compliant and HP told me that it acts as a PCI card, not AGP since it is an integrated chipset. I have only a very basic understanding of C. If I knew what to do, I'd be happy to make the changes myself. If it's not a trivial task to update the header file, could someone else lend a hand? Looking at hp's support forums, there are quite a few folks who would prefer more than vesa/fbdev support on their laptops. Thanks! Ben Scanpci -v below (the device 0x4336 is the piece of concern, I believe): pci bus 0x cardnum 0x00 function 0x00: vendor 0x1002 device 0xcab0 ATI Device unknown STATUS0x2230 COMMAND 0x0006 CLASS 0x06 0x00 0x00 REVISION 0x13 BIST 0x00 HEADER 0x00 LATENCY 0x20 CACHE 0x00 BASE0 0xd408 addr 0xd400 MEM PREFETCHABLE BASE1 0xd058 addr 0xd050 MEM PREFETCHABLE BASE2 0x8091 addr 0x8090 I/O pci bus 0x cardnum 0x01 function 0x00: vendor 0x1002 device 0x700f ATI Device unknown STATUS0x0220 COMMAND 0x0007 CLASS 0x06 0x04 0x00 REVISION 0x01 HEADER0x01 LATENCY 0x63 PRIBUS0x00 SECBUS 0x01 SUBBUS 0x01 SECLT 0x44 IOBASE0x9100 IOLIM 0x9fff SECSTATUS 0x0220 NOPREFETCH_MEMBASE 0xd010 MEMLIM 0xd01f PREFETCH_MEMBASE 0xe000 MEMLIM 0xefff NO_FAST_B2B NO_SEC_BUS_RST NO_M_ABRT VGA_EN ISA_EN NO_SERR_EN NO_PERR_EN pci bus 0x cardnum 0x02 function 0x00: vendor 0x10b9 device 0x5237 ALI Device unknown CardVendor 0x103c card 0x0024 (HP, Card unknown) STATUS0x0290 COMMAND 0x0017 CLASS 0x0c 0x03 0x10 REVISION 0x03 BIST 0x00 HEADER 0x00 LATENCY 0x40 CACHE 0x00 BASE0 0xd000 addr 0xd000 MEM MAX_LAT 0x50 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x09 BYTE_00x1f BYTE_1 0x00 BYTE_2 0x00 BYTE_3 0x00 pci bus 0x cardnum 0x06 function 0x00: vendor 0x10b9 device 0x5451 ALI Device unknown CardVendor 0x103c card 0x0024 (HP, Card unknown) STATUS0xc290 COMMAND 0x0007 CLASS 0x04 0x01 0x00 REVISION 0x02 BIST 0x00 HEADER 0x00 LATENCY 0x40 CACHE 0x00 BASE0 0x8401 addr 0x8400 I/O BASE1 0xd0001000 addr 0xd0001000 MEM MAX_LAT 0x18 MIN_GNT 0x02 INT_PIN 0x01 INT_LINE 0x05 pci bus 0x cardnum 0x07 function 0x00: vendor 0x10b9 device 0x1533 ALI M1533 Aladdin IV CardVendor 0x10b9 card 0x1533 (ALI, Card unknown) STATUS0x0210 COMMAND 0x000f CLASS 0x06 0x01 0x00 REVISION 0x00 BYTE_00xea0bd301 BYTE_1 0x00 BYTE_2 0x8072030 BYTE_3 0x pci bus 0x cardnum 0x08 function 0x00: vendor 0x10b9 device 0x5457 ALI Device unknown CardVendor 0x103c card 0x0024 (HP, Card unknown) STATUS0x0290 COMMAND 0x0003 CLASS 0x07 0x03 0x00 REVISION 0x00 BIST 0x00 HEADER 0x00 LATENCY 0x40 CACHE 0x00 BASE0 0xd0002000 addr 0xd0002000 MEM BASE1 0x8801 addr 0x8800 I/O MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x03 BYTE_00xc0220001 BYTE_1 0x00 BYTE_2 0x80723a8 BYTE_3 0x pci bus 0x cardnum 0x0a function 0x00: vendor 0x1217 device 0x6972 Device unknown STATUS0x0410 COMMAND 0x0087 CLASS 0x06 0x07 0x00 REVISION 0x00 BIST 0x00 HEADER 0x02 LATENCY 0xa8 CACHE 0x00 BASE0 0x8000 addr 0x8000 MEM BASE1 0x02a0 addr 0x02a0 MEM BASE2 0xb0050200 addr 0xb0050200 MEM BASE3 0x8100 addr 0x8100 MEM BASE4 0x8110 addr 0x8110 MEM BASE5 0x1c00 addr 0x1c00 MEM BASEROM 0x307d addr 0x decode-enabled MAX_LAT 0x05 MIN_GNT 0x80 INT_PIN 0x01 INT_LINE 0x05 BYTE_00x24103c BYTE_1 0x00 BYTE_2 0x8072720 BYTE_3 0x pci bus 0x cardnum 0x10 function 0x00: vendor 0x10b9 device 0x5229 ALI M5229 TXpro CardVendor 0x103c card 0x0024 (HP, Card unknown) STATUS0x0290 COMMAND 0x0005 CLASS 0x01 0x01 0xb0 REVISION 0xc4 BIST 0x00 HEADER 0x00 LATENCY 0x20 CACHE 0x00 BASE4 0x8081 addr 0x8080 I/O MAX_LAT 0x04 MIN_GNT 0x02 INT_PIN 0x01 INT_LINE 0x00 BYTE_00xf00 BYTE_1 0x00 BYTE_2 0x00 BYTE_3 0x00 pci bus 0x cardnum 0x11 function 0x00: vendor 0x10b9 device 0x7101 ALI Device unknown CardVendor 0x103c card 0x0024 (HP, Card unknown) STATUS0x0200 COMMAND 0x CLASS 0x06 0x80 0x00 REVISION 0x00 BYTE_00x4204 BYTE_1 0x00 BYTE_2 0x8072e10 BYTE_3 0x pci bus 0x cardnum 0x12 function 0x00: vendor 0x100b device 0x0020 NS Device unknown CardVendor 0x3c08 card 0x2400 (Card unknown) STATUS0x0290 COMMAND 0x0007 CLASS 0x02 0x00
Re: [Devel] Re: Another voice
Mike A. Harris wrote (in a message from Monday 13) > I'd be interested also in hearing feedback and comments from > Debian, Mandrake, SuSE, Gentoo, FreeBSD, NetBSD, OpenBSD, > Caldera, and other Linux and BSD distribution XFree86 > package maintainers, and other developers also. I've talked > personally with some of them already, but the more who get > involved the better. We all benefit, and everyone's feedback is > very valuable. In my opinion, a bug tracking system would help, but as others already said, setting up and maintaining such a system in a useful state is a really time-consuming task. The Gnats systems used in OpenBSD (and in other BSDs too) is not perfect, but it has been proven itself useful in a few occasions, although not all submitted PRs get handled. On the other side, I've seen other projects where the bug tracking system totally failed : no one would take the time to fill reports and anyways no developper ever bothered to look at the few reports that were filed. A bug tracking software per itself doesn't prevent bug reports from staying unanswered for weeks nor does it automagically insure that fixes are correct. Only the work of the people reviewing and editing the contents of the database can produce those effects. If some people are seriously volunteering to go through a specification and review process to setup a system that will be bring something the project, let's start it. If done right it will help to focus developper attention on things that need fixing. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: [Devel] Re: Another voice
Well, there's some changes happening... I've used X and been a promoter since Rev 9, and I have some of J Gettys personally coded stuff around just for grins -- We've all been waiting for X to 'grow up', and with Linux becoming a viable desktop alternative for at least the literate masses, perhaps its time for the community to form an official foundation or working group to guide it. Just seems like if we are changing everything, lets change everything. ..like I said, I'm for whatever works. While I'm at it, this group is responsible for making it a viable alternative, and you all should take a bow. end of 2 cents worth. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Georgina Economou Sent: Monday, January 13, 2003 1:28 PM To: [EMAIL PROTECTED] Subject: Re: [Devel] Re: Another voice - Original Message - From: "Terrance A. Davis" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 13, 2003 1:06 PM Subject: RE: [Devel] Re: Another voice > All, > > I'm not sure what started all this, seems like we need a new paradigm. > > Maybe its time to *really* open source X. A foundation of some sort? Terrance could you elaborate on this? Georgina > > I just hacker, so I'll go with whatever works. > > ..Just an idea. > > T > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another voice
On Mon, 13 Jan 2003, Vladimir Dergachev wrote: > > So.. any chance of GATOS getting into XFree86? ;o) > This question gets asked very often. The answer is that part of GATOS is > already there. The part that isn't is TV-in and hardware Xv for mach64 > cards. And it was submitted but it takes quite a while to get in. The > major reason for this is that ATI driver maintainer and me have different > priorities: > My impression is that ATI driver maintainer (Marc please correct me) is > primarily interested in >* clean and working code that is easy to maintain > which, IMO, is a worthy goal. > My priorities are: >* robust (non-crashing) driver that supports new features >* experimentation with new approaches to programming and new features > These two do imply "clean and easy to maintain" but in a significantly > different way. > Also both of us are quite short on spare time. That, pretty well, sums it up. And more of GATOS will be merged shortly. I know I promised earlier to get the merge done before 4.3, but that just didn't happen, sorry. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: programming question: Window Information
On Mon, 13 Jan 2003 16:43:14 +0100 (CET) Krasi Zlatev <[EMAIL PROTECTED]>
babbled:
> I would like to gather inforamtion about all the
> running X applicaiotns.
> Thus I do
> Window root = RootWindow (dpy, screenno);
> XQueryTree (dpy, root, &dummywindow, &dummywindow,
> &children, &nchildren);
>
> for (i = 0; i < nchildren; i++) {
> if (XGetWindowAttributes(dpy, children[i],
> &attr) && (attr.map_state == IsViewable)) {
> XFetchName(dpy, children[i], &win_name);
> printf("Window ID: 0x%lx\n",children[i]);
> }
> }
>
> I thought that win_name will contain the name of the
> window, but it is always null,
> what am I doing wrong?
short answer and you'll figure it out yourself:
xwininfo -tree -root
:)
long answer:
x loves windows. it isnt single level like mac os (a root and then windows).
it's a big big big VRY deep tree. client window will be 2 or 3, maybe 4
levels down (this may vary depending on how deep your wm likes to reparent
client windows within its scheme of things).
you need to keep traversing the tree down as far as you can go (ALL the way...
do NOT just stop at the first window with a title... it IS possible that client
windows can be managed within other client windows... ie MDI style). :)
--
--- Codito, ergo sum - "I code, therefore I am"
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
[EMAIL PROTECTED]
Mobile Phone: +61 (0)413 451 899Home Phone: 02 9698 8615
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Mon, Jan 13, 2003 at 11:10:14AM +0100, Egbert Eich scrawled: > Matt Wilson writes: > > I'm not attempting to bully anyone, nor have I argued that you or any > > other member (individual or corporate) of XFree86. However, there are > > plenty of volunteers that are offering to set up and maintain a bug > > tracking system for you. I think that such a project would be much > > more successful if it were endorsed by XFree86 and integrated into the > > development policy for the project. > > Sorry, this is not how it goes. We won't be willing > to adopt anything blindly. There is a German saying > applying here: > 'Never buy a cat in the bag!' > > 1. First there should be a proposal There has been. > 2. Secondly there should be a test implementation >as proof of concept we can work with and see >how well it goes. I've said before that I'm willing to set up debbugs+PTS/Bugzilla. IMHO Bugzilla would be better for this situation. > 4. Thirdly this should be evaluated > - if we think it is usable at all. > - what modifications we would like to see. > 5. The modified system needs to get retested and reevaluated. > 6. This is the earliest stage we can talk about a more or >less formal policy. I see no real reason to stick this much to a formal process. > Up to now it is not even clear who should be able to > submit to this bug tracking system: > Should it be internal only? NO, NO, NO, NO, NO, NO AND NO. > Should only projects like GNOME, KDE etc and > distributions like RedHat, SuSE, Mandrake be able to > submit bugs? This is one of the worst ideas I've heard yet. > Or should it be open to the general public? Yes, but with Bugzilla you can have open submissions, but only certain users able to set bugs to CONFIRMED, etc. Maybe if we handed the latter out to only clueful people ... :) d, KDE developer and current Debian XFree86 4.3 dude, so excuse the bias -- Daniel Stone <[EMAIL PROTECTED]> Developer, Trinity College, University of Melbourne msg00073/pgp0.pgp Description: PGP signature
Re: [Devel] Re: Another voice
On Mon, Jan 13, 2003 at 11:10:14AM +0100, Egbert Eich wrote: > Matt Wilson writes: > > > > I'm not attempting to bully anyone, nor have I argued that you or any > > other member (individual or corporate) of XFree86. However, there are > > plenty of volunteers that are offering to set up and maintain a bug > > tracking system for you. I think that such a project would be much > > more successful if it were endorsed by XFree86 and integrated into the > > development policy for the project. > > > > Sorry, this is not how it goes. We won't be willing > to adopt anything blindly. There is a German saying > applying here: > 'Never buy a cat in the bag!' > > 1. First there should be a proposal > 2. Secondly there should be a test implementation >as proof of concept we can work with and see >how well it goes. > 4. Thirdly this should be evaluated > - if we think it is usable at all. > - what modifications we would like to see. > 5. The modified system needs to get retested and reevaluated. > 6. This is the earliest stage we can talk about a more or >less formal policy. > > Up to now it is not even clear who should be able to > submit to this bug tracking system: > Should it be internal only? > Should only projects like GNOME, KDE etc and > distributions like RedHat, SuSE, Mandrake be able to > submit bugs? > Or should it be open to the general public? I agree with your points here Egbert. Someone needs to step forward to collate these ideas and put the initial system together. We seem to have people stepping forward with ideas and a few who claim that they'll do the initial work on setting up, but nothing ever happens. My own personal opinion lies with the fact that if this is setup, who will have the staying power to maintain it. Most of the XFree86 Core Team have been around a long time and seen various developers come and go around the project. It's obvious to me that some developers will use it, and others may not, or even may not all the time. Therefore that 'team' who has to maintain it need to be able to stick around for it to be of long term use. If these 'bug' maintainers come and go, I can see the whole process collapsing into one big heap of unusable data. Additionally the maintainers need to qualify the bug reports before it gets to core developers who need to spend precious time isolating the problem and coming up with the patch. If this process is too time consuming, these reports will be left untouched. And one of the most frustrating problems of all, is bug reports to core developers who don't have access to the hardware. I know this is some of the pro's of having a bug database in that someone can look at what needs fixing who has the appropriate hardware, but seldom is this the case - having several people report problems to me that cannot be fixed without some severe manpower in fixing it. I don't think I've heard any of the XFree86 Core Team denouncing a bug database, just the fact that if it consumes much of their precious time then things will stagnate. If there is a team here who want to set one up and maintain independently of XFree86, then there's nothing stopping them. Even doing it this way, may well get the momentum, in that lots of things would be ironed out, and provide something workable for the future. There's been several conversations of this in the past and nothing fruitful has come of it just because the XFree86 Core Team don't push for it, and so others see that as counter-productive. Don't. Someone needs to put their own effort in. Even if the XFree86 Core Team don't participate in this bug database it should in no way effect it's usefulness to those who want one. If someone enters a bug report, then it's perfectly possible for someone completely new to the project to fix the bug and submit a patch to XFree86 without any involvement of the Core Team, apart from actually committing the fix, then enter onto the bug database 'Fixed - appending commit' in the bug report. Step forward those who want it and start doing it. If it can be shown to be productive then there's something more to discuss, but we're covering the same ground again and again. Get going on it and prove it works, but don't expect everyone to use it and live with that fact - it's open source and you can't force people into a way of working Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ATI card addition to xf86PciInfo.h
On Mon, 13 Jan 2003 15:29:18 -0500, [EMAIL PROTECTED] wrote: > >When I run the command "XFree86 -configure" it give the message: >XFree86 has found a valid card configuration. >Unfortunately the appropriate data has not been added to xf86PciInfo.h. >Please forward 'scanpci -v' output to XFree86 support team. > >from everything I've read, this card should be radeon compliant and HP told >me that it acts as a PCI card, not AGP since it is an integrated chipset. That's not accurate; the Radeons are AGP devices. The fact that it is integrated is irrelevant. However, for the most part, there is no difference. AGP is just a fancier version of PCI. >I have only a very basic understanding of C. If I knew what to do, I'd >be happy to make the changes myself. If it's not a trivial task to update >the header file, could someone else lend a hand? Looking at hp's support >forums, there are quite a few folks who would prefer more than vesa/fbdev >support on their laptops. As I recall, there is work going on to eliminate this problem by allowing our drivers to claim a whole range of PCI IDs, eliminating the need for xf86PciInfo.h. Is that work present in 4.3.0? -- - Tim Roberts, [EMAIL PROTECTED] Providenza & Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Sun, Jan 12, 2003 at 07:36:57PM -0500, Matt Wilson wrote: >As for providing resources - we've done this for many projects that >have approached us. For example: > >[msw@sid openoffice]$ host bugzilla.gnome.org >bugzilla.gnome.org has address 209.116.70.84 >[msw@sid openoffice]$ whois [EMAIL PROTECTED] >(snip out big reply pointing to Red Hat, Inc.) >[msw@sid openoffice]$ host stage.mozilla.org >stage.mozilla.org is an alias for hemosaur.mozilla.org. >hemosaur.mozilla.org has address 66.187.233.204 >[msw@sid openoffice]$ whois [EMAIL PROTECTED] >(snip out big reply pointing to Red Hat, Inc.) > >These resources come out of projects finding themselves in need and >requesting assistance. Thus far the only thing I hear from you is >that XFree86 doesn't need a bug tracker... Hosting isn't the type of resource I'm referring to -- we're fine on that thanks. I mean the much more difficult to find (non-volunteer) people resources needed to make a bug tracking system really work without sapping development resources -- like IBM is doing with the Linux kernel. If you're offering something like that, then I'm all ears. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ATI card addition to xf86PciInfo.h
On Mon, 13 Jan 2003, Tim Roberts wrote: [...] > As I recall, there is work going on to eliminate this problem by allowing our > drivers to claim a whole range of PCI IDs, eliminating the need for > xf86PciInfo.h. Is that work present in 4.3.0? > xf86PciInfo.h isn't needed. I stopped adding NVIDIA cards to it a while ago. I'm not really sure why we even have an xf86PciInfo.h. The burden supporting a particular device ID is, and I believe always has been, in the driver. Merely adding a PCI ID to xf86PciInfo.h doesn't add support for that PCI ID. Drivers still have to explicitly specify PCI IDs to tell the core server that it supports them. I don't think there's any ongoing work to resolve that. I have, however, worked around this in the "nv" driver. Basically I construct the list that gets passed from the driver to the core server based on what cards are currently in the system. The "nv" knows which of these cards it can support without needing a static list of PCI IDs. I still keep a static list of PCI IDs for informational purposes (to print out the marketting name for it), but I can support a chip if it's not in that list. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
[Georgina Economou] > No Mike, I am talking about who controls the reports and who sees > them. Who owns the data? This is RHAT's baby, Bugzilla, so I take > it that they would be a serious Admin to this and would have the > ability to pull data as they want, without asking XFree86 for it. How do you manage to come up with these ideas? They seem pretty far fetched to me. BTW: Bugzilla is Mozillas baby, no redhats. (How can I know? I'm just a random Debian developer...) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Mon, Jan 13, 2003 at 02:30:05PM -0500, Mike A. Harris wrote: >Just seeking clarification of wether or not the general public >has access to subscribe to the 2 patch mailing lists now or not >after David declared the private lists to be no longer private. I declared the "devel" list to be no longer be private, but then that was the only private member discussion list, and I said that there would be no new private members discussion list to replace devel. Also, I've since stated at least twice on this thread that a decision about the patch and fixes lists hasn't been made yet. Before berating others for not reading what you write (and there's so much of it that people can surely be forgiven for skimming just a little), maybe you should do likewise? David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ATI card addition to xf86PciInfo.h
On Mon, 13 Jan 2003 16:12:21 -0800 (PST), Mark Vojkovich wrote: >On Mon, 13 Jan 2003, Tim Roberts wrote: > > [...] > >> As I recall, there is work going on to eliminate this problem by allowing >> our drivers to claim a whole range of PCI IDs, eliminating the need for >> xf86PciInfo.h. Is that work present in 4.3.0? > > xf86PciInfo.h isn't needed. I stopped adding NVIDIA cards to it >a while ago. I'm not really sure why we even have an xf86PciInfo.h. >The burden supporting a particular device ID is, and I believe always >has been, in the driver. Merely adding a PCI ID to xf86PciInfo.h >doesn't add support for that PCI ID. What you say is true, EXCEPT for "XFree86 -configure". At least as late as 4.2.1, the automatic configuration stuff will refuse to run if the PCI id is not in xf86PciIfno.h. Does your nv hack solve that? -- - Tim Roberts, [EMAIL PROTECTED] Providenza & Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: No Digests?
On Mon, Jan 13, 2003 at 11:19:29AM -0800, Tim Roberts wrote: >After coming in to find 170-odd messages from the new [Devel] list in my inbox, >I decided to switch to digest mode. However, mailman tells me that "the list >administrator has disabled digest delivery for this list". Any particular >reason why this is so? > Devel never has had a digest, so this should not be considered abnormal. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Devel mailing list changes.
On Tue, Jan 14, 2003 at 01:05:45AM +, David Woodhouse wrote: >Like Reply-To:? Now the status of the list has changed, is the decision to >have a Reply-To: header added also up for reconsideration? :) We have to draw a line somewhere :-) David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Sun, Jan 12, 2003 at 02:25:35PM -0800, [EMAIL PROTECTED] wrote: >Specifically, there are people in Gnome chomping at the bit to help with >the xfree86 bug setup and triage problem, with experience at running >the Gnome bugzilla system. > >Only time will tell how well this will work out, but my strong belief is >that the current situation doesn't scale, and our usage is likely to >go up greatly this calendar year as the open source desktop has finally >reached critical mass of applications and is beginning to be actively >marketed. > >This being said (and we use bugzilla in the handhelds project), >getting bugzilla well set up for a project (proper products, etc) is >some work and > >Another, extremely high performance place to host a bugzilla is >available (a machine on a 100 megabit link one hop away from a gigabit >Internet II connection); it has bugzilla installed already, and may >be better than a site in Spain. > >Should I tell them to go ahead and see if we can get something set up >that may be usable as an experiment? No. I do not think that that will be necessary. I would like to view what is currently available elsewhere first. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Sun, Jan 12, 2003 at 06:14:31PM -0500, Jeff Garzik wrote: >On Sun, Jan 12, 2003 at 06:06:31PM -0500, Matt Wilson wrote: >> On Sun, Jan 12, 2003 at 05:48:36PM -0500, David Dawes wrote: >> > On Sun, Jan 12, 2003 at 11:01:01PM +0100, Fernando Herrera wrote: >> > >Sun, Jan 12, 2003 at 04:15:15PM -0500, David Dawes escribi?: >> > > >> > >>So it's OK for Linux kernel developers to object to having a bug tracking >> > >>system imposed on them but not OK for XFree86 developers? If that's >> > >>what you're telling me, then I have nothing more to say on this topic. > >A note of clarification, > >The Linux kernel Bugzilla is optional for kernel developers. > >If someone is proposing that XFree86 developers _must_ use Bugzilla, >that's really not something that can be imposed. > >But if there are volunteers out there willing to maintain a bug >database, hey, "more power to 'em", right? Developers can always ignore >the Bugzilla, after all :) > And right now that is my inclination. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ATI card addition to xf86PciInfo.h
On Mon, 13 Jan 2003, Tim Roberts wrote: > On Mon, 13 Jan 2003 16:12:21 -0800 (PST), Mark Vojkovich wrote: > > >On Mon, 13 Jan 2003, Tim Roberts wrote: > > > > [...] > > > >> As I recall, there is work going on to eliminate this problem by allowing > >> our drivers to claim a whole range of PCI IDs, eliminating the need for > >> xf86PciInfo.h. Is that work present in 4.3.0? > > > > xf86PciInfo.h isn't needed. I stopped adding NVIDIA cards to it > >a while ago. I'm not really sure why we even have an xf86PciInfo.h. > >The burden supporting a particular device ID is, and I believe always > >has been, in the driver. Merely adding a PCI ID to xf86PciInfo.h > >doesn't add support for that PCI ID. > > What you say is true, EXCEPT for "XFree86 -configure". At least as late as > 4.2.1, the automatic configuration stuff will refuse to run if the PCI id is > not in xf86PciIfno.h. > > Does your nv hack solve that? > I don't know anything about "-configure". And I can't put PCI IDs in xf86PciInfo.h if I don't know what they are. The point of my nv hack was to support cards that haven't come out yet. MArk. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Sun, Jan 12, 2003 at 05:50:00PM -0800, [EMAIL PROTECTED] wrote: >> Would this also see what patches have come in and see where they are >> applicable? >> What about areas that come in that are distro specific, does that go to the >> distro maintainer of to XFree86? > >Clearly, a distro maintainer. > >Part of the triage process is identifying things that are not >the project's fault. > >> Is the XFree86 bugzilla now repsonsbile >> for all distro bugs, and there are lots? > >Nope. There are clearly times XFree86 should say: this shouldn't be fixed >in XFree86: the distro should fix their breakage. For example, I think >it would be correct to do this when a distro has a distro specific compiler >bug: making XFree86's code worse forever for a transient problem >is a *very* bad idea. > >In my personal experience, I build XFree86 on both RH and Debian, typically >with no problems on either. The problem I see here is that XFree86 is not only a Linux-based system and this triage method would give Linux bugs a leg up over OSs. This would skew all work done on XFree86 to Linux at the expense of other, not has heavily supported, platforms. Another problem I forsee is that the bugs would be geared towards new or newer hardware, because most of the people reporting bugs have just gotten their Tablet, Laptop or whatever. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
A On Sun, Jan 12, 2003 at 08:59:34PM -0500, Vladimir Dergachev wrote: >> > >I'd not in a position to accuse anyone, but I'm reminded of the saying: >> > >"The best is the enemy of the good". >> > > >> > >* Read access to the patch@ and fixes@ lists would be helpful, then >> > >we would all have an idea of the backlog. >> > >> > It's been there for the asking for members for a long time. Few asked. >> > >> >> You know I never for the life of me understood that. I would have thougtht >> that every developer would be interested and see if their patch bumped horns >> with another. >> As former postmaster I received, I think, a total of two requests. Weird. > >I can share a different perspective: from my point of view the patch@ and >fixes@ lists were for people who have commit access, so it never occured >to me to apply for it in the first place. > >I might be wrong here, but my impression was that XFree86 had voting and >non-voting members and being the one of the second kind I pretty much >assumed that all I have is access to ftp server, documentation and >internal mailing lists like video@ or devel@. (CVS was created later on). XFree86 has always used CVS even when I was it's lone committer. The sole privilege of a voting over a non-voting member is the ability to elect the board. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Sun, Jan 12, 2003 at 09:14:41PM -0500, Jeff Garzik wrote: >On Sun, Jan 12, 2003 at 07:23:37PM -0500, David Dawes wrote: >> Since you mention those $200 Walmart systems, has anyone actually >> seen one? They don't have them in any Walmart I've been to -- only >> the $600+ HP and eMachines systems. Yes I have seen the same. Thanks for the info. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Mon, Jan 13, 2003 at 11:10:14AM +0100, Egbert Eich wrote: >Matt Wilson writes: > > > > I'm not attempting to bully anyone, nor have I argued that you or any > > other member (individual or corporate) of XFree86. However, there are > > plenty of volunteers that are offering to set up and maintain a bug > > tracking system for you. I think that such a project would be much > > more successful if it were endorsed by XFree86 and integrated into the > > development policy for the project. > > > >Sorry, this is not how it goes. We won't be willing >to adopt anything blindly. There is a German saying >applying here: >'Never buy a cat in the bag!' And in English we would say "Never buy anything sight unseen". David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Bugzilla [Was: Re: Another voice]
On Mon, Jan 13, 2003 at 11:09:21AM +0100, Egbert Eich wrote: >Matt Wilson writes: > > On Sun, Jan 12, 2003 at 07:21:04PM -0500, Georgina Economou wrote: > > > > > > So Matt am I to take it that Redhat is looking to push forward with > > > its Bugzilla and thus get more experience and in the end paid work > > > with it like VA did with Sourceforge? That sounds very sensible > > > though I think your approach a bit bizarre and off-putting. > > > > I don't understand. We're interested in seeing Open Source projects > > succeed. This involves growing contributor bases, etc. Although > > XFree86 development applies to many operating systems, it's success is > > key to Linux's success. We've never really thought much of trying to > > build a business around consulting groups on how to be successful Open > > Source projects... > > >Asking OpenSource projects for money to get consulted? >I don't think you'd get any business from XFree86 either :-))) > >BTW: XFre86 has been around quite a bit longer than RedHat >has been in OpenSource community. > Yes. About as long as Linux itself. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
On Mon, Jan 13, 2003 at 02:12:27PM +, Dr Andrew C Aitchison wrote: >On Sun, 12 Jan 2003, Georgina Economou wrote: > >> Well there's still http://mail-thearchive.com. What ever did happen to marc >> on this one? > >Indeed devel and xfree86 appear to be at > http://www.mail-archive.com/index.php?hunt=xfree86 > >The xfree86 list has appeared on > http://marc.theaimsgroup.com/ >(under misc, rather than GUI with the other X lists). >It appears that no-one has asked for devel to be added there yet. This is something that we must ask for? Well I am glad it is now done. Thanks for the info. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Bugzilla [Was: Re: Another voice]
David, I think your comments about bugs in Bugzilla skewing towards Linux and new hardware were right on the money. ...but don't you think such skew is statistically inevitable? There are IMO two desires here, and I argue they do not conflict: - Making sure XFree86 does become unduly influenced by Linux use. - Utilizing strength in numbers, let the vast Linux army test XFree86 heavily and fix core bugs, and add core enhancements, that have a positive effect on all XFree86 users. As much as I would personally love to see bug reports for ancient PCI S3's with ancient RAMDACs [no, I'm not kidding], or someone else would love to see bug reports and testing for statistics just isn't on the favorable side there. AFAICS that's just reality and not fixable :( With all due respect, Jeff ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another voice
On Mon, Jan 13, 2003 at 09:00:56AM -0500, Mike A. Harris wrote: >On Sat, 11 Jan 2003, G O Economou wrote: > >>http://www.advogato.org/person/mharris/ >> >>There are allot of interesting comments here by Mike, >>particularly his interest in forking XFree86 and creating his >>own work. > >You seem to have some deep misconceptions. I read your article and saw it the same way. I think that this is typical of you, you speak out of both sides of your mouth. You are saying a lot of things in this thread differently than you did in that diary entry of yours. The only things I've >mentioned on there are my decision to branch the Radeon driver >and to contribute stuff back to the XFree86 project. And this would have to be approved by the same said Radeon maintainer. I am not sure what that woould buy you. >>At least I think interestingand BTW doesn't the ATI >>maintainer work for Redhat? > >As far as I know, the ATI driver maintainer is Marc Aurele La >France, and while he's done some great work on the ATI drivers, >we haven't tried to hire him to my knowledge. > >Or you could be refering to Kevin Martin. He works for Red Hat >however, in our Professional Services department. He is not >involved in Red Hat Linux OS engineering with respect to XFree86. > Kevin is the Radeon maintainer, not Marc. If you knew more about this Project you would know that. > >I've got other ideas and thoughts too, such as the bugzilla idea, >but I'm not the only one who wants these things. And who are these other people if this is not coming from within the Project? Why, as Alan says later, don't they just do it and be done with it. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another voice
On Mon, Jan 13, 2003 at 09:33:34AM -0500, Mike A. Harris wrote: >On Sat, 11 Jan 2003, David Dawes wrote: > >>>There are allot of interesting comments here by Mike, particularly his >>>interest in forking XFree86 and creating his own work. At least I think >>>interestingand BTW doesn't the ATI maintainer work for Redhat? >> >>Definitely interesting. >> >>One main point I would like to answer now is the issue of the developer >>page on the web site. New membership was basically closed down temporarily >>while the whole membership/developer situation was being reviewed. >> >>After this message goes out, [EMAIL PROTECTED] will be converted to >>a public mailman list -- so if you want to subscribe, go to >>http://www.xfree86.org/mailman/listinfo/devel/ >> >>In the interests of openness, there won't be any private list to replace >>it, and the whole issue of joining XFree86 as a developer will be moot. > >David, this is wonderful news. I'm very pleased to see this >change happen. I've wondered for a long time why the private >devel list was private, considering almost if not all of the >discussions that have taken place on it in all the time I've been >on it have not really been something that private. Well right there you missed something. Everything on the private devel was private. There was nothing there that could be repeated, nor still can for that matter. Everything said there was done and spoken in confidence and honour. > >In the past I have also submitted various patches found on >mailing lists, and things people have sent me that fixed >something for them. A great deal of said patches I merely passed >along upstream in hopes that they might be useful to the project >after someone did a good code review. This was somewhat of a >mistake of course, as I had no idea what was expected, and found >out quite some time later that my processes and procedures for >submitting patches was not entirely the best. > That is correct. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Devel mailing list changes.
[EMAIL PROTECTED] said: > I'm very surprised anyone would object to this. This tag, which is > common to mailman lists, is enormously useful for e-mail filtering. > It certainly helps me distinguish mailing list messages from the > depressingly vast array of e-mail I already get just by scanning my > inbox. If for some reason you don't want to filter list mail into a separate folder for each list, and you _really_ want the subject noise, it's trivial to do -- just insert a mail filter on the SMTP sender of the mail list everyone else does, only have it insert whatever you like into the Subject line instead of filing into an appropriate folder. But please make sure you remove the noise again if you reply to such mails. The fact that GNU mailman ships with this crap on by default is a serious bug, IMHBCO. It's not 50/50, because adding it locally is so much easier than removing it locally, for those users who have a strong preference either way. It is far more of a problem to _remove_ the noise if it's been added by a misguided mail admin. You can manage to remove it for the majority of posts, but when a message is cross-posted to another such list, you get its crap also polluting the subject line too, and you can't easily filter that out. [EMAIL PROTECTED] said: > The List-Id header is there precisely for the purpose of mail > filtering, [EMAIL PROTECTED] said: > That is why all GNU mailman mailing lists have a header line: > X-BeenThere: [EMAIL PROTECTED] Both of these give false positives. Consider the situation where you have such a filter in place, but have unsubscribed from the list or are reading it with 'grep' because you've been out of the office. Your colleague/friend/cat sees a message he knows you need to see, but will probably miss due to the circumstances above. He bounces it to you, headers intact, or to another internal mailing list or something. Your mail filter then sticks it in the folder for the original list and you still don't see it. It's rare, but it's happened to me at least once, before I fixed my filters. The only 100% reliable way to filter such mail is on the SMTP reverse-path, which depending on your MTA is usually either the Sender: or Return-Path: header by the time it gets to your procmail filter. :0w:$MAILDIR/lists/Xdev/.procmail-lock * ^Return-Path:.*[EMAIL PROTECTED] |$HOME/bin/MHstore +lists/Xdev Not that it really matters _that_ much, but if you're encouraging people to filter sensibly, you might as well give a 100% reliable solution. [EMAIL PROTECTED] said: > Enjoy many lists whom use the subject line listname annoyance in > complete peace and harmony, and without getting sucked in to 50/50 > flamewars. As I said, it's not 50/50. It's been fixed on this list now, thankfully. > This leaves you tonnes more time to participate in other, > much more worthy flamewars that might also seem equally pointless, > but for which procmail can't help. ;o) Like Reply-To:? Now the status of the list has changed, is the decision to have a Reply-To: header added also up for reconsideration? :) /me runs... -- dwmw2 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ATI card addition to xf86PciInfo.h
On Mon, 13 Jan 2003 [EMAIL PROTECTED] wrote: > I'm attaching the output from scanpci -v. > > When I run the command "XFree86 -configure" it give the message: > XFree86 has found a valid card configuration. > Unfortunately the appropriate data has not been added to xf86PciInfo.h. > Please forward 'scanpci -v' output to XFree86 support team. > > from everything I've read, this card should be radeon compliant and HP told me that >it acts as a PCI card, not AGP since it is an integrated chipset. > > I have only a very basic understanding of C. If I knew what to do, I'd be happy to >make the changes myself. If it's not a trivial task to update the header file, could >someone else lend a hand? Looking at hp's support forums, there are quite a few >folks who would prefer more than vesa/fbdev support on their laptops. > > Thanks! > Ben > What system is this ? Is it a notebook with integrated graphics ? best Vladimir Dergachev ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Devel] Re: Another voice
Quoting Alan Hourihane <[EMAIL PROTECTED]>: > > Sorry, this is not how it goes. We won't be willing > > to adopt anything blindly. There is a German saying > > applying here: > > 'Never buy a cat in the bag!' > > > > 1. First there should be a proposal > > 2. Secondly there should be a test implementation > >as proof of concept we can work with and see > >how well it goes. > > 4. Thirdly this should be evaluated > > - if we think it is usable at all. > > - what modifications we would like to see. > > 5. The modified system needs to get retested and reevaluated. > > 6. This is the earliest stage we can talk about a more or > >less formal policy. > > > > Up to now it is not even clear who should be able to > > submit to this bug tracking system: > > Should it be internal only? > > Should only projects like GNOME, KDE etc and > > distributions like RedHat, SuSE, Mandrake be able to > > submit bugs? > > Or should it be open to the general public? > > I agree with your points here Egbert. I believe such possible bug track system should at least: o Be very lighweight, I don't want to wait 30+ seconds for every small iteration (for example rebuilding the interface based on a selected list entry) while doing a query in a server in the other side of the globe. o Only allow submits if at least a clear description of how to reproduce the problem is present. Also, some padronized way to query the hardware, configuration, os, and log files must exist and be attached to the pr. Bugs reports with an optional proposed patch would have higher precedence. o Require a valid bug reporter email. Needless to say, the major interest of XFree86 developers is to have a very stable implementation, but since a lot (most) work is done as a volunteer effort, just filling bug reports won't be enough, and saying that a XFree86 developer/contributor is lazy or unresponsible because he cannot handle the 300+ bogus assigned prs won't help either. > Someone needs to step forward to collate these ideas and put the > initial > system together. We seem to have people stepping forward with ideas > and a few who claim that they'll do the initial work on setting up, > but nothing ever happens. > > My own personal opinion lies with the fact that if this is setup, who > will have the staying power to maintain it. Most of the XFree86 Core > Team > have been around a long time and seen various developers come and go > around > the project. It's obvious to me that some developers will use it, and > others may not, or even may not all the time. Therefore that 'team' > who > has to maintain it need to be able to stick around for it to be of > long term use. If these 'bug' maintainers come and go, I can see the > whole > process collapsing into one big heap of unusable data. Even if a bug report system is not done at this "round", I would at least like to see some work about categorizing XFree86 development/ maintenance areas, like: xserver, driver, design, extensions, documentation, libraries, xtest, security, i18n, etc; and the various subdivisions. > There's been several conversations of this in the past and nothing > fruitful has come of it just because the XFree86 Core Team don't push > for it, and so others see that as counter-productive. Don't. Someone > needs to put their own effort in. > > Even if the XFree86 Core Team don't participate in this bug database > it should in no way effect it's usefulness to those who want one. If > someone > enters a bug report, then it's perfectly possible for someone > completely > new to the project to fix the bug and submit a patch to XFree86 > without > any involvement of the Core Team, apart from actually committing the > fix, > then enter onto the bug database 'Fixed - appending commit' in the bug > report. > > Step forward those who want it and start doing it. If it can be shown > to be productive then there's something more to discuss, but we're > covering the same ground again and again. > > Get going on it and prove it works, but don't expect everyone to use > it > and live with that fact - it's open source and you can't force people > into a way of working I would like to see some sort of bug tracking system, but only after it has been extensively tested, and only if it proves to be really useful. In the several years I have been involved with XFree86 (some times I got a bit "distant", must agree) what I see is that developers are working in specific/specialized areas, while David Dawes almost alone handles patches and bug reports at "random" parts of XFree86, and also does a large amount of specific/specialized work, so, he is the best person to evaluate it. Hope that after this thread finishes, something useful remains... Paulo ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
