Re: Cygwin/XFree86 Status?
David Dawes wrote: On Mon, Jan 26, 2004 at 09:53:40AM -0800, Kendall Bennett wrote: Clearly the future of XFree86 is very murky right now, as many developers have left to work on other projects such as freedesktop.org, and now with the core team disbanded it is unclear exactly how companies such as SciTech or vendors such as ATI, Via, SiS etc who do not have direct connections with someone on the XFree86 committer list can get their patches into XFree86. From what I can tell basically nothing has really changed and it is just as difficult as before to get submissions into XFree86 (witness the problems of the Cygwin developers getting their patches accepted). Submissions should be made via bugs.xfree86.org. New work should be discussed here in advance. This has been the submission policy since bugs.xfree86.org was setup, and it applies to individuals and companies alike. Anyone looking to short-circuit this public submission mechanism and the public review that goes with it will be disappointed. Interesting interpretation of how bugs.xfree86.org has been used historically. Hmm... I recall a slightly different reality: http://www.mail-archive.com/[EMAIL PROTECTED]/msg03713.html **Dunno where it goes, just that thankfully I don't receive any of it.** The way I understand bugzilla is that people have to go to the web interface looking for stuff. David Emphasis is mine. Oops, well, try again next time. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Cygwin/XFree86 Status?
Thomas Dickey wrote: On Sat, 24 Jan 2004, Martin Spott wrote: David Dawes [EMAIL PROTECTED] wrote: On Thu, Jan 22, 2004 at 10:17:30AM -0800, Kendall Bennett wrote: [...], and I am in discussions with some of the other members of the community about starting a new project to take over where the XFree86 team appears to be stuck. If you are interested let me know. The more the merrier. Wouldn't it be better to iron out the 'political issues' over the current (and pretty much working!) XFree86 Windows port (via Cygwin) instead of creating a parallel universe !? Kendall's comments were partly directed toward efforts that Cygwin is not interested in. Since he's interested they will not be, there's no issue to iron out. I'm not sure who Cygwin is, but I am just a developer and I am always interested in these sorts of things. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: core team disbands
David Dawes wrote: On Wed, Dec 31, 2003 at 11:27:15AM -0800, Richard A. Hecker wrote: David Dawes wrote: I believe that this is an acknowlegement that the core team was no longer representative of the active, experienced and skilled XFree86 developers, or a place where technical discussion happens. Such an acknowledgement could have been derived long ago from the dissention within the project. I advocated this move earlier in the year, but a majority of the core team didn't agree with me at that time. Fortunately that changed. It sounds like it is a good thing... but still, what does it mean? People forking the codebase and others simply choosing to donate their skills and time elsewhere would have been enough of a clue. I don't see a problem with forked code bases, etc. I believe that variety and competition are healthy. Why force eveyone into the same mould? Giving people choices as to where and how they apply their skills can only increase the overall level of contributions. Everyone can choose the project that best suits them, or if none do, create their own. Anything else stifles creativity and innovation. Sure, choice is good... but forcing people to provide an alternate code base just because the primary code base is difficult to work with isn't good... it causes duplication of effort and animosity that otherwise would not be there. So, the question is, does the disbanding of the core team mean that the tree will be easier to contribute to directly, or is it just an internal change? Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: A credits section for the 4.4 release notes
David, Upon first inspection it looks like all of the names of people that contributed Cygwin-related patches are there. Thanks, Harold David Dawes wrote: I was going to announce this after Christmas, but maybe today is better. I'm proposing to add a Credits section to the Release Notes for the XFree86 4.4 release. I have a sample/draft at: http://www.xfree86.org/~dawes/pre-4.4/RELNOTES5.html Remember this is a sample only, it is intended to give an idea of how it might look. It is by no means complete. The idea is that notable new stuff (features and fixes) for which the contributors and/or integrators have provided details for section 2 of the Release Notes would be itemised in the Credits section. Section 2 can be viewed at: http://www.xfree86.org/~dawes/pre-4.4/RELNOTES2.html Comments are welcome. So are submissions of material and of course additions/fixes to the list of contributors. The bulk list in the draft was ripped from the post-4.3.0 CHANGELOG entries. There are bound to be some errors and omissions given that we have had contributions from more than 250 people for this release, so if you are not listed just send me the details. I prepared this just after the RC2 cut, so submissions since then aren't yet reflected in the list. David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Proper attribution of patches
The following CVS commit, made by Thomas Dickey, has no indication that Thomas was either a) not involved at all in the patch or b) that Thomas found Ralf Habacker's patch and committed a modified version of that patch. The CVS log message says: fixes for _XtInherit on cygwin. The hw/xfree86/CHANGELOG files says: XFree86 4.3.99.903 (xx December 2003) + 699. Fixes to build/run on cygwin (Thomas Dickey). I know that this patch was based at least in part (if not entirely) on Ralf Habacker's patch for the same, since it includes a more than twenty line comment from Ralf along with his name at the bottom: http://cvsweb.xfree86.org/cvsweb/xc/lib/Xt/Initialize.c.diff?r1=3.21r2=3.22f=h Given the fact that XFree86 has shown little support for Cygwin in the past coupled with the fact that Cygwin/X is no longer associated with XFree86, I request that you take care to properly attribute patches from members of the Cygwin/X community. Thank you, Harold Hunt Thomas Dickey wrote: CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/12/22 13:10:25 Log message: fixes for _XtInherit on cygwin. Modified files: xc/lib/Xt/: Initialize.c Vendor.c Revision ChangesPath 3.22 +61 -1 xc/lib/Xt/Initialize.c 1.8 +21 -2 xc/lib/Xt/Vendor.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Proper attribution of patches
Thomas Dickey wrote: On Tue, 23 Dec 2003, Harold L Hunt II wrote: The following CVS commit, made by Thomas Dickey, has no indication that Thomas was either a) not involved at all in the patch or b) that Thomas found Ralf Habacker's patch and committed a modified version of that patch. The CVS log message says: fixes for _XtInherit on cygwin. The hw/xfree86/CHANGELOG files says: XFree86 4.3.99.903 (xx December 2003) + 699. Fixes to build/run on cygwin (Thomas Dickey). I know that this patch was based at least in part (if not entirely) on Ralf Habacker's patch for the same, since it includes a more than twenty line comment from Ralf along with his name at the bottom: http://cvsweb.xfree86.org/cvsweb/xc/lib/Xt/Initialize.c.diff?r1=3.21r2=3.22f=h I'm aware of that. Your commit didn't mention this either. Our change log is in our release notes, where the changes were attributed to Ralf Habacker: http://sources.redhat.com/ml/cygwin-xfree-announce/2003-10/msg8.html Do you have point? XFree86 should be taking care not to steal credit for our patches by committing them without proper attribution. Harold Hunt ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Proper attribution of patches
Thomas Dickey wrote: On Tue, 23 Dec 2003, Harold L Hunt II wrote: Your commit didn't mention this either. Our change log is in our release notes, where the changes were attributed to Ralf Habacker: tsk, tsk: the actual commit on the code change bears only your name. A casual reader of that commit (and of this thread) would gain the false impression that you did the work. Try to make a point the next time you choose to waste my time. You put *your* name in the change log message, making an active claim that you did the work. It's okay to shy away from admitting that you are wrong and that you did a despicable thing; it doesn't bother me. Of course, others may not view you so favorably. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Proper attribution of patches
Thomas Dickey wrote: On Tue, 23 Dec 2003, Harold L Hunt II wrote: XFree86 should be taking care not to steal credit for our patches by committing them without proper attribution. your standards are inconsistent: your committing the change rather than offering commit access to someone who solved a problem that (according to the email thread) that had stopped you for some _months_ indicates that your whole aim on this is to get credit for yourself. You must be right, you're always right. Take a look at the bug I filed months ago: http://bugs.xfree86.org/show_bug.cgi?id=804 === Patch will be attached shortly. Only effects Cygwin. Build tested, run-time tested. Change log entry: Enable shared build of Xt, Xaw, Xaw6, and Xmu libraries on Cygwin (Ralf Habacker). === Oops, looks like I was not trying to steal credit on that one. Lets see, that makes three places where I gave proper credit for the patch and thanked Ralf for fixing it: 1) The Cygwin/X mailing list, 2) The change log for the updated packages, and 3) Bug 804 on bugs.xfree86.org. At last count, the number of places where you gave proper credit was: 0. The policy of the xoncygwin tree on SourceForge was that anyone that wanted access could have it; Ralf didn't want it since he was busy working on porting KDE to Cygwin/X. Lets get back to the topic at hand: your blatant attempt to steal credit and refusal to acknowledge that you did so. I noted that the comment in the code was properly attributed, no further action was needed. No, that is not good enough. You should amend your change log entry to attribute the patch to Ralf and you should apologize to the X community at large for being so sloppy with attributing credit. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Proper attribution of patches
Thomas Dickey wrote: On Tue, 23 Dec 2003, Harold L Hunt II wrote: Thomas Dickey wrote: On Tue, 23 Dec 2003, Harold L Hunt II wrote: Your commit didn't mention this either. Our change log is in our release notes, where the changes were attributed to Ralf Habacker: tsk, tsk: the actual commit on the code change bears only your name. A casual reader of that commit (and of this thread) would gain the false impression that you did the work. Try to make a point the next time you choose to waste my time. You put *your* name in the change log message, making an active claim that you did the work. get to the point. or is logic beyond your capabilities? All you can focus on is that I didn't put _your_ name on the change. A shame. I have stated numerous times that the patch is attributed to Ralf Habacker. Do not claim that you think I am asking for my name to be on the patch; I have not done so, I am not doing so, and I will not do so. Put Ralf's name in the change log!!! Get that? Put Ralf's name in the change log!!! But given your previous behavior, entirely expected. Very mature Thomas. Your so-called announcement was followup email to the _same_ people who had been able to watch the discussion of the problem. That's not an announcement. hmm - no overall changelog entry for the project, no webpage giving project news. Just a mailing list (subscription-only ;-). I gave you a link to that change log entry. Please, stop trying to change the topic away from the fact that you are trying to steal credit for Ralf's patch. Give Ralf credit for the work that he did and stop your silly attempt to save face by arguing with me. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Proper attribution of patches
Alan Hourihane wrote: On Tue, Dec 23, 2003 at 02:02:20PM -0500, Thomas Dickey wrote: On Tue, 23 Dec 2003, Harold L Hunt II wrote: The following CVS commit, made by Thomas Dickey, has no indication that Thomas was either a) not involved at all in the patch or b) that Thomas found Ralf Habacker's patch and committed a modified version of that patch. The CVS log message says: fixes for _XtInherit on cygwin. The hw/xfree86/CHANGELOG files says: XFree86 4.3.99.903 (xx December 2003) + 699. Fixes to build/run on cygwin (Thomas Dickey). I know that this patch was based at least in part (if not entirely) on Ralf Habacker's patch for the same, since it includes a more than twenty line comment from Ralf along with his name at the bottom: http://cvsweb.xfree86.org/cvsweb/xc/lib/Xt/Initialize.c.diff?r1=3.21r2=3.22f=h I'm aware of that. Your commit didn't mention this either. Do you have point? Thomas, If you did get this code directly from Cygwin/X's tree then I'd of expected at least the credit to be apportioned to Harold at the very least, rather than putting your name against it. Ralf's name could have been corrected later, with a follow email from Harold. It's a simple change to put that right in the CHANGELOG. So I'll do that. Thanks Alan! Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Proper attribution of patches
Thomas Dickey wrote: On Tue, 23 Dec 2003, Harold L Hunt II wrote: Thomas Dickey wrote: On Tue, 23 Dec 2003, Eric Anholt wrote: The only responsible thing for you to do would be to correct the ChangeLog to attribute it to the patch's author. well that's polite enough. unlike Harold. I have not been rude in this discussion. rofl: get someone (intelligent patient) to read your first posting and explain it to you. I don't have the bandwidth. I wouldn't laugh so hard. You have made a fool of yourself in public and discredited your own reputation. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Proper attribution of patches
Thomas Dickey wrote: On Tue, 23 Dec 2003, Harold L Hunt II wrote: No, that is not good enough. You should amend your change log entry to attribute the patch to Ralf and you should apologize to the X community at large for being so sloppy with attributing credit. yes, you're right. Thanks. now I'll have to scrutinize your commits more closely to see who actually did the work. Hold on. Lets assume that I had made the change. So, we are assuming, hypothetically, that the patch should have been attributed to me. In that case you are still in the wrong because you attributed the patch to yourself, not to me (even though I did not make the change). You cannot escape the fact that *you* *took* credit for the patch; you did not assign it to the wrong person due to a mistake in interpreting the change log entries, you actually *took* credit for yourself and didn't mention the fact that you got the patch from another project. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Proper attribution of patches
Thomas Dickey wrote: On Tue, 23 Dec 2003, Harold L Hunt II wrote: been corrected later, with a follow email from Harold. It's a simple change to put that right in the CHANGELOG. So I'll do that. I had that on my next set of commits. Then why not say so earlier? There was no point in doing so. Sure there was: you would not have exposed yourself as a hypocrite by doing exactly that which you denounce on your home page (pointed out by Daniel Armburst). You lambast those egotistical plagiarists that steal credit for patches by not properly attributing them to their authors, yet you did the same thing and threw a tantrum when I pointed it out: http://dickey.his.com/gnu-patches/gnu-patches.html This is a collection of some of the patches which I have made to GNU programs. I have submitted these patches to the appropriate maintainers, but received no acknowledgment. That is, they were ignored. In a few other cases, I have seen my changes incorporated without credit, but that is another matter. The former (nonexistent or non-responsive maintainers) are preferable to the latter (egotistical plagiarists). [...] You own self interest would have been the point in coming clean earlier. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Cygwin/XFree86 - No longer associated with XFree86.org
It seems that David Dawes has made his decision not to let the Cygwin/XFree86 project commit patches directly to the XFree86.org CVS tree; he doesn't seem to want to go on record saying this, but he has written several messages during this discussion about ftp servers, cvs servers, etc., while making no attempt to provide a direct answer to my question. Had he intended otherwise he could have easily said, Gotta wait until the next board meeting, or Sorry, server died, gonna have to wait a couple days. I can only interpret his ignoring the issue as a passive refusal to grant Cygwin/XFree86 CVS commit access. In the interests of providing a more open development model, the Cygwin/XFree86 project will no longer be maintaining code in the XFree86.org CVS tree. Maintaining code in XFree86.org's CVS tree provides little benefit in relation to the amount of time required to do so; XFree86.org is passively unwilling to work with Cygwin/XFree86 to reduce the amount of time required. What this means for Cygwin/XFree86 users and developers === 1) No major changes to the files currently distributed with Cygwin/XFree86 for at least a month. 2) The Cygwin/XFree86 mailing lists and project pages will stay at cygwin.com. 3) Builds will continue to be made from the 4.3.0 snapshot, patched with the latest Cygwin/XFree86 patches. 4) A 4.4.0 snapshot may be pulled to make builds from. 5) Patches for Cygwin-specific code will no longer be sent to XFree86.org. Non Cygwin-specific patches should still be sent, to be dealt with as XFree86 pleases. 6) Alternatives are being evaluated for hosting Cygwin/XFree86 code in CVS. Hosts that can provide CVS commit access for at least five Cygwin/XFree86 developers will be given priority. What this means for Cygwin == Nothing. Nada. Zilch. They were not involved in this at all. What this means for XFree86 === Some will say nothing. Some will say good riddance. Some will say this is the beginning of the end. Who knows? Who cares? Let /. figure it out. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Cygwin/XFree86 - No longer associated with XFree86.org
Alan Hourihane wrote: On Mon, Oct 27, 2003 at 11:35:20AM -0500, Harold L Hunt II wrote: 6) Alternatives are being evaluated for hosting Cygwin/XFree86 code in CVS. Hosts that can provide CVS commit access for at least five Cygwin/XFree86 developers will be given priority. Harold, I thought you already had the CVS for Cygwin/XFree86 sorted out, by using what you'd already setup in http://sf.net/projects/xoncygwin ? It is something I am looking into. It all depends on if we want to have to import and maintain the clients. You and Alexander Gottwald (and myself) have already been using this for quite some time now. Couldn't you give Kensuke et al commit access there rather than seeking out yet another repository ? Looking into it. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Cygwin/XFree86 Bugs?
Craig, Craig Groeschel wrote: I'm afraid your rants and threats won't do much good there though. Great. Shoot the messenger. (btw, No one is ranting or threatening. Just being lucid and assertive. IMHO.) Thanks for your support. I have tried, and failed on occasion, to maintain my composure. I have noticed a lot of drama and negativity on this list too. I don't have experience with other free software projects so I don't know whether this is the case everywhere. [snip] I guess what I am saying is I think XFree86 has a tremendous opportunity here. And I for one will be watching to see the outcome. I send my best wishes to all parties. Thanks again for your support. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Cygwin/XFree86 - Staying or leaving XFree86.org? [Was: Re: Cygwin/XFree86 Bugs?]
David Dawes wrote: On Sun, Oct 26, 2003 at 12:37:29PM -0500, Harold L Hunt II wrote: Michel Dänzer wrote: Well, you know, XFree86's disregard for offers to help made by developers that have been with the project for over two years are certainly part of the problem. Err, this is about bug triage, which you can do just as well as everybody else. No, this is about my submitting Cygwin-specific bugs that can't actually be assigned to me for committing them, even though I am the expert on Cygwin/XFree86. This thread started to point out the hypocrisy of the situation and to see what the official response to this was. When I discussed this with you privately a while ago all I got were disrespectful and insulting responses. Now there is more of the same. As a volunteer myself, I don't have to take this type of attitude from you or from anyone else. And I won't. David, I mentioned that failure to commit my patches in a timely manner causes me to have a hard time figuring out which have been committed and which haven't (this was when I was sending patches to [EMAIL PROTECTED]). You probably never saw this system from the standpoint of a non-commit developer. The problem here is that you send a patch to the list, it randomly gets committed by someone (you don't know who in advance, so you have to track everyone's committs), then you have to figure out who committed it (if anyone) and if it was done correctly. The system was a mess and did not aid non-commit developers in tracking their patches. Your response to this comment was that I was unorganized and that it cause by my lack of attention to detail. Was that a respectful and non-insulting response to my message? Is this my formal message to piss off? Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Cygwin/XFree86 Bugs?
David Dawes wrote: On Sun, Oct 26, 2003 at 02:34:02PM -0500, Harold L Hunt II wrote: Thomas Dickey wrote: On Sat, 25 Oct 2003, Harold L Hunt II wrote: Seriously, I don't know why I waste my time submitting patches that are specific to my platform and then wait up to three weeks for them to be committed. It is a waste of my time and an insult that I am made to do well, when you graduate and (presumably) find a real job, you'll have a chance to get an idea of where time goes. the patches _are_ applied, right? Thanks for your amazing support Thomas. You don't know anything about me, so you can keep your blanket statements about where you time goes to yourself. By the way, how often do you have to go to the doctor's office? How often do you have to get prescriptions refiled? How often do you have to change the tubing for a medical device that is attached to you? Huh? Didn't think so. So, please take this as kindly as possible when I say: Go fuck yourself. The funny thing here is that I am volunteering to take care of my own patches and I am personally insulted that my offer is being ignored. Nobody is going to take you seriously if all you can do is be rude and insulting. Excuse me, Thomas Dickey stepped *way* out of line here. This is a side conversation, but since he made his insult public, I made my response public. As for the core of this thread, I am trying very hard not to be rude and insulting. Look, everyone knows that you like the development model that you have going here (else, it wouldn't be setup this way). How would you suggest I word a request that you change that development model in such a way that it would not be inflamatory towards you or XFree86? It can't be done. That is part of the problem: Any way that I, or another developer, assertively requests CVS access is met with a flame fest. That is not a sign of a healthy organization that is looking to attract developers. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Cygwin/XFree86 - Staying or leaving XFree86.org? [Was: Re: Cygwin/XFree86 Bugs?]
Thomas Dickey wrote: On Sun, 26 Oct 2003, Peter Firefly Lund wrote: On Sun, 26 Oct 2003, David Dawes wrote: When I discussed this with you privately a while ago all I got were disrespectful and insulting responses. Now there is more of the same. Err... No. He was quite reasonable, in my opinion. He thought he was, but when I get email from people phrased that way, I don't appreciate it. Thomas Dickey, You sent me the biggest insult I have ever received in my life. How can you not realize that? How can you do anything except apologize for your extremely rude message? Please, never, ever, respond to another word that I write until you correct yourself. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Cygwin/XFree86 - Staying or leaving XFree86.org? [Was: Re: Cygwin/XFree86 Bugs?]
Marc Aurele La France wrote: On Sun, 26 Oct 2003, Peter Firefly Lund wrote: On Sun, 26 Oct 2003, David Dawes wrote: When I discussed this with you privately a while ago all I got were disrespectful and insulting responses. Now there is more of the same. Err... No. He was quite reasonable, in my opinion. On the contrary. Implying that XFree86 owes him anything, be it a personal/family life or the right to commit, is not reasonable at all. Saying give me what I want to be a volunteer! simply doesn't cut it. Marc, I am not implying that anyone owes me anything. XFree86 owes me nothing. I am asking to do *more* not *less* for the XFree86 project. Committing my own Cygwin-specific patches not only saves me time, but it saves all other XFree86 committers time as well. How is that implying that XFree86 owes me something? Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Cygwin/XFree86 - Staying or leaving XFree86.org? [Was: Re: Cygwin/XFree86 Bugs?]
Daniel Stone wrote: On Sun, Oct 26, 2003 at 03:51:05PM -0700, Marc Aurele La France wrote: On Sun, 26 Oct 2003, Peter Firefly Lund wrote: On Sun, 26 Oct 2003, David Dawes wrote: When I discussed this with you privately a while ago all I got were disrespectful and insulting responses. Now there is more of the same. Err... No. He was quite reasonable, in my opinion. On the contrary. Implying that XFree86 owes him anything, be it a personal/family life or the right to commit, is not reasonable at all. Saying give me what I want to be a volunteer! simply doesn't cut it. I've tried to stay out of this ... From my (impartial; I'm not taking sides) reading, he was saying, if you want me here, it's on my terms, which includes CVS. No CVS, no me. He was (AFAICT) placing conditions on his continued participation in a volunteer activity, not making demands of other volunteers. Daniel, Thank you. It is nice to know that what I am writing can be read as I have intended it to be read. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Problems with shared lesstif and shared Xt on Cygwin/XFree86
Torrey, Looks like you may have had the same sort of trouble that we are now having with regards to building a shared version of the lesstif libraries that link to a shared version of the Xt library. The particular error message, when starting a lesstif app is: XmManager ClassInitialize: XmeTraitSet failed Nicholas Wourms has been looking into this problem (his notes are below) and he seems to think that an OS/X-specific fix may have been made to one of the XFree86 libs to alleviate this problem with lesstif. Do you recall anything related to this problem? If so, could you describe the fix or point us to a message describing the fix? Thanks in advance, Harold *SIGH* I spoke too soon, after building nedit and trying some other tests, I'm experiencing the XmManager ClassInitialize: XmeTraitSet failed problem. Apparently the MacOSX people went through this ordeal last year, but unfortunately that doesn't help us. They had two solutions: 1) Pass -force_flat_namespace which is part of OSX's proprietary linker. 2) Downgrade to XFree86-4.1 libs of some sort or upgrade to latest cvs. Of course, in-depth information on why this is happening is nonexistant, all I could find were: http://oroborosx.sourceforge.net/faq.html#q5p1 http://www.geocrawler.com/mail/msg.php3?msg_id=8230372list=8629 Given that information, I'm willing to bet that an OSX-only fix was checked in sometime after July of last year to resolve this. Finding out what it is will be difficult I'm willing to bet. Of course it could just be Xt misbehaving or an auto-import/psuedo-ops failure. Heh, oh well, I'm going to further investigate this tommorrow... Sorry that it isn't working properly :-(. One last thought, perhaps we should CC Brian Ford in on this since another fresh perspective might be good. Cheers, Nicholas ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Cygwin/XFree86 Bugs?
Michel Dnzer wrote: On Wed, 2003-10-22 at 17:13, Egbert Eich wrote: Marc Aurele La France writes: [EMAIL PROTECTED] is an ML anyone can subscribe to. I am, and, I believe, so is Egbert. No, not currently. I usually go to the web interface and look at the open bugs, process new ones that can be handled quickly, or try to assign them to an expert on the specific area. There are a lot more areas than we have experts - in these cases I try to work on the ticket myself. This, and the low quality of some of the submissions, consumes a considerable amount of time. Indeed, you're doing most of the bugzilla work alone; it's a pity there aren't more people helping with that. Well, you know, XFree86's disregard for offers to help made by developers that have been with the project for over two years are certainly part of the problem. Seriously, I don't know why I waste my time submitting patches that are specific to my platform and then wait up to three weeks for them to be committed. It is a waste of my time and an insult that I am made to do this while other platform maintainers made the luck of the draw and get to commit their patches directly. Here it is: Let me commit my own patches within two months or I am going to let xc/programs/Xserver/hw/xwin die; I will stop sending updates, I will request that you remove hw/xwin and stop advertising that you support Cygwin. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Problems with shared lesstif and shared Xt on Cygwin/XFree86
Thanks Torrey. I tried a build without $(SMLIB) and $(ICELIB) in SharedXtReqs, but it fails to link due to unresolved symbols (all symbols must be resolved at library link time in DLLs on Windows). I will have to consult with the rest of the Cygwin people to see what we should do now. Thanks again, Harold Torrey Lyons wrote: The issue on Mac OS X is that most shared libraries want to be built as two-level namespace images. Two-level namespace images have significant advantages in loading speed, but they require that they have no unresolved symbols when linking the library. This is why the darwinLib.tmpl contains a complete list of every library's dependencies. Unfortunately this causes a problem with two shared libraries, Xt and Xfont. The problem is that these libraries are designed to have certain symbols undefined and to have theses references resolved at application link time by one of various other library choices. In the case of Xt, SM and ICE provide the default resolution of these symbols in darwinLib.tmpl (and cygwin.tmpl), but symbols with the same names from lesstif should be used instead when the application is linked with it. Two-level namespace libraries don't allow you to do that since all symbols get resolved at library link time, not application link time. Thus we fixed this problem by building libXt and libXfont as flat namespace images, which have the same linking semantics that most people on other *nixes are used to. In your case, I suspect that including $(SMLIB) and $(ICELIB) in the following line from cygwin.tmpl is causing your problem: #define SharedXtReqs $(LDPRELIB) $(SMLIB) $(ICELIB) $(XLIBONLY) If Cygwin's linker does not complain when you removed these two, you should be fine. As it is all of the references which are supposed to remain undefined are likely being satisfied at library link time so nothing from lesstif is being included at application link time. --Torrey At 2:43 AM -0400 10/25/03, Harold L Hunt II wrote: Torrey, Looks like you may have had the same sort of trouble that we are now having with regards to building a shared version of the lesstif libraries that link to a shared version of the Xt library. The particular error message, when starting a lesstif app is: XmManager ClassInitialize: XmeTraitSet failed Nicholas Wourms has been looking into this problem (his notes are below) and he seems to think that an OS/X-specific fix may have been made to one of the XFree86 libs to alleviate this problem with lesstif. Do you recall anything related to this problem? If so, could you describe the fix or point us to a message describing the fix? Thanks in advance, Harold *SIGH* I spoke too soon, after building nedit and trying some other tests, I'm experiencing the XmManager ClassInitialize: XmeTraitSet failed problem. Apparently the MacOSX people went through this ordeal last year, but unfortunately that doesn't help us. They had two solutions: 1) Pass -force_flat_namespace which is part of OSX's proprietary linker. 2) Downgrade to XFree86-4.1 libs of some sort or upgrade to latest cvs. Of course, in-depth information on why this is happening is nonexistant, all I could find were: http://oroborosx.sourceforge.net/faq.html#q5p1 http://www.geocrawler.com/mail/msg.php3?msg_id=8230372list=8629 Given that information, I'm willing to bet that an OSX-only fix was checked in sometime after July of last year to resolve this. Finding out what it is will be difficult I'm willing to bet. Of course it could just be Xt misbehaving or an auto-import/psuedo-ops failure. Heh, oh well, I'm going to further investigate this tommorrow... Sorry that it isn't working properly :-(. One last thought, perhaps we should CC Brian Ford in on this since another fresh perspective might be good. Cheers, Nicholas ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Cygwin/XFree86 Bugs?
Egbert Eich wrote: Marc Aurele La France writes: [EMAIL PROTECTED] is an ML anyone can subscribe to. I am, and, I believe, so is Egbert. No, not currently. I usually go to the web interface and look at the open bugs, process new ones that can be handled quickly, or try to assign them to an expert on the specific area. There are a lot more areas than we have experts - in these cases I try to work on the ticket myself. This, and the low quality of some of the submissions, consumes a considerable amount of time. Good point. I am the defacto expert for Cygwin/XFree86, considering that I have been contributing to the project for 3 years now and leading the project for going on 2 years. You might think that I should therefore be able to commit my own patches that were Cygwin-specific, but that is not the case. I do not think that Egbert should have to be burdened with committing Cygwin-specific patches. Can I please finally be given CVS commit access with the understanding that I am a moron and that I will only commit things that are Cygwin-specific, with all other non-Cygwin-specific patches sent via bugs.xfree86.org? At the first sign of my veering off course you could feel free to revoke my access. I think I have already proven that I am dedicated to the XFree86 project and that I am knowledgible enough to know where the line is between patches for my own platform and patches that may break the build on other platforms. Thanks, Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [PATCH] Export symbol lists on Linux
I wouldn't be opposed to just wiping out the #ifdef __CYGWIN__ stuff and starting fresh with a test build. I can always put back any platform-specific #if's that turn out to still be valid. Harold David Dawes wrote: On Wed, Oct 15, 2003 at 11:00:23PM +0200, Jakub Jelinek wrote: On Wed, Oct 15, 2003 at 03:06:46PM -0400, David Dawes wrote: For libGL.so, as anonymous version scripts accept wildcards, I think we should use gl* wildcard, as it is too error-prone to list all the gl* functions. Will the wildcard method work for the platforms that currently use the -def.cpp lists? The GL and GLX APIs should be well-defined. No idea about Cygwin and OS2, for now I've just used it in 2 places in GL-def.cpp but it can be expanded. Attached is a first version of the patch against CVS HEAD, which builds, covers all undefined symbols by XFree86 programs/shared libraries which used to be satisfied by the XF86 shlibs and similarly all 5870 programs/shlibs on my disk. The lnxLib.rules changes should work both with old binutils (where version script simply will not be used and all symbols exported) and newer binutils (2001-12-18 and later) where it will be used. I think it is more important first to make sure there are no symbols which ought to be exported but are not than to make sure that no symbols which are not supposed to be exported are visible. That way we can ensure XFree86 will continue working; in later steps symbols can be removed from the export libs as they are analyzed. I've made lots of *-def.cpp changes keyed from __linux__ for now (well, typically OS2 and linux has very similar export sets), because I have no idea what OS2 and Cygwin needs/doesn't need to export and don't want to break them. Also, X11-def.cpp apparently contains two sets of symbols, one for !OS2 !Cygwin !linux (no idea what platform which uses *-def.cpp is it), one for those 3. Either one set should be killed if it is unused, or merged with the other set. The !OS2 !Cygwin symbols appear to have been in the version of these files imported from X11R6.0. I don't know their origin, but they might have been for Win32 builds. The lists need to be divided into the API-defined symbols, platform-independent exceptions that applications and/or other libraries appear to be using, and platform-specific exceptions determined from examination of the relevant library source (some of the symbols in the existing -def.cpp files marked as platform specific are not). We definitely don't want to keep multiple lists. Some symbols that are currently commented out in a platform-specific way, like: -#ifndef __UNIXOS2__ +#if !defined(__UNIXOS2__) !defined(__linux__) XftDrawCorePrepare #endif should be removed because they no longer exist. That's where checks against the API specs (when they exist) and the public library headers and source code are needed. Has anyone done a comparison of these lists against the API specs yet? IMO this is the most significant part of this exercise, combined with the data you have collected from a set of existing applications. David ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Cygwin/XFree86 Bugs?
David Dawes wrote: On Tue, Oct 21, 2003 at 10:04:55PM -0600, Marc Aurele La France wrote: On Tue, 21 Oct 2003, David Dawes wrote: On Tue, Oct 21, 2003 at 06:34:53PM -0400, Harold L Hunt II wrote: What happens when I assign patches in the Cygwin Xserver project to [EMAIL PROTECTED]? Does an email go out to everyone with CVS commit access? Is there a single person that receives this email? Should I be assigning patches to a specific person to ensure timely commits? Dunno where it goes, just that thankfully I don't receive any of it. The way I understand bugzilla is that people have to go to the web interface looking for stuff. [EMAIL PROTECTED] is an ML anyone can subscribe to. I am, and, I believe, so is Egbert. Learn something new every day :-). Looks like the subscriber list is publicly viewable (and very small). Where? I see nothing here: http://xfree86.org/lists.html I also get nothing when I try to forge a link to the list: http://www.xfree86.org/mailman/listinfo/developer/ Is there a different mailing list server for bugs.xfree86.org? So, who wants to handle a high volume of patches specific to Cygwin after the 4.4.0 branch? Any volunteers? I would appreciate someone that can commit to a 24 to 48 hour turnaround on committing submitted patches that don't touch other platforms. Thanks, Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RFC Marking private symbols in XFree86 shared libraries as private
Jakub, I just noticed this thread today. If this will have problems, then they will definitely be visible on Cygwin. So, I ask that I please be included in the testing process before this is committed, if it ever is. I would gladly do test builds under Cygwin to confirm that the new scheme works. Harold Jakub Jelinek wrote: On Thu, Oct 09, 2003 at 09:01:15PM -0400, David Dawes wrote: Well, both version script and __attribute__((visibility (hidden))) can be used at the same time. Anonymous version script works in 2001-12-18 and later binutils and AFAIK in Solaris linker. No idea about other arches. If you think we should list all exported symbols, then maybe we could introduce .sym (or .api) files for each library which would list exported symbols one per line and Imakefile hacks to generate version scripts/whatever else on the fly and use it during linking. That sounds like a good approach. There are two ways that this is already done for some platforms. OS/2 and Cygwin use files like X11-def.cpp to list the exported symbols. Those lists might be a good starting point, but I suspect that more symbols are exported than are documented in the API specs. Also, X11R6.3 added export description files (like libX11.elist), together with scripts for a few platforms like Solaris, HPUX and AIX to process them. The .elist files are only provided for libX11 and libXt, and they simply export all globals. I don't know if the basic mechanism is worth reusing -- you should look at it and see what you think. They don't provide any useful information about what symbols should be exported for each library though. I'd say it would be better to reuse *-def.cpp files (didn't know something like that existed). They are preprocessed, so it is easy to add __linux__, whatever else, also arch specific symbols, whatever necessary. Transforming *-def.cpp files to anonymous version scripts should be trivial, whether done in lnxLib.rules, sunLib.rules or some special script. Given that there are just a handful of -shared links in whole XFree86 build, perhaps the rule can (in lnxLib.rules) first check whether ld actually supports anynymous version scripts and only use them if it does. Second thing is how to define Imakefile macros which will enable __attribute__((visibility (hidden))) and/or version scripts. Should they be just user settable, defaulting to no, or should imake do the autodetection (for that it needs an autoconf like test, since e.g. even when you have GCC 3.3 and later, still visibility attribute doesn't have to be supported if that GCC was compiled against old binutils, etc.)? What happens if you use the visibility attribute with a gcc 3.3 that doesn't have it enabled? If it's simply ignored, then it shouldn't be an issue. Otherwise, is there no pre-defined macro so that you can test for it in the source? There is no predefined macro, the attribute is ignored if not supported, but with a warning: If it is GCC which has visibility attribute support but that attribute is not supported in its particular configuration (linked against old binutils, not using binutils or architectire which doesn't support it), you get: visibility attribute not supported in this configuration; ignored warning, if it is GCC without visibility attribute support (e.g. older releases), you get: `visibility' attribute directive ignored warning. I don't know how much XFree86 relies on being warning free. GCC 3.3+ on Linux will typically be configured such that this attribute is supported and give no warning (dunno about *BSD etc.), so it would issue warnings just in a few configurations. Jakub ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Wrong order of a timeouts processing in WaitForSomething.
David, David Dawes wrote: On Sun, Sep 21, 2003 at 12:13:10AM -0400, Harold L Hunt II wrote: The only suggestion I have is that the function prototypes in include/os.h should follow the conventions of all other prototypes in os.h, using #if NeedFunctionPrototypes: extern void SetScreenSaverTimer( #if NeedFunctionPrototypes void #endif ); #ifdef DPMSExtension extern void SetDPMSTimers( #if NeedFunctionPrototypes void #endif ); #endif Actually, we're going the other way and on the trunk all of the NeedFunctionPrototypes references have been removed in os.h. I missed that. Sorry for the noise. Thanks for taking the time to debug this properly... I hope that there Yes! Hopefully the screen saver/DPMS cleanup will reduce the likelihood of further subtle bugs that have plagued that code for a while. Cleanup is good. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Matthieu, The new file, prngc.c, uses sockaddr_storage. However, I know that at least Cygwin does not have sockaddr_storage. No alternative is provided and no conditional compilation is in effect to fall back to previous functionality when sockaddr_storage is not available. This breaks the build on Cygwin. What can be done to fix the build on platforms that do not have sockaddr_storage? I already tried using sockaddr instead, but that is missing fields that are contained in sockaddr_storage. Any other ideas? Harold Matthieu Herrb wrote: CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/09/16 22:48:34 Log message: 447. In xdm, use better pseudo-random number generators to generate magic cookies. Add support for EGD and other compatible entropy gathering daemons. (Oswald Buddenhagen from KDE, Matthieu Herrb). Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG xc/config/cf/: OpenBSD.cf X11.tmpl darwin.cf xc/programs/xdm/: Imakefile dm.c dm.h dm_auth.h genauth.c mitauth.c resource.c session.c xdm.man xdmauth.c Added files: xc/programs/xdm/: prngc.c Revision ChangesPath 3.2858+4 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG 3.91 +2 -2 xc/config/cf/OpenBSD.cf 1.220 +7 -1 xc/config/cf/X11.tmpl 1.40 +2 -1 xc/config/cf/darwin.cf 3.58 +8 -3 xc/programs/xdm/Imakefile 3.23 +10 -2 xc/programs/xdm/dm.c 3.32 +6 -1 xc/programs/xdm/dm.h 1.3 +10 -2 xc/programs/xdm/dm_auth.h 3.18 +324 -137 xc/programs/xdm/genauth.c 1.6 +8 -2 xc/programs/xdm/mitauth.c 3.12 +20 -1 xc/programs/xdm/resource.c 3.35 +6 -2 xc/programs/xdm/session.c 3.25 +15 -1 xc/programs/xdm/xdm.man 1.6 +8 -2 xc/programs/xdm/xdmauth.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: C version of ucs2any.pl
Matthieu (and Matthias), Matthias Scheler wrote: On Thu, Sep 18, 2003 at 10:58:19PM +0200, Matthieu Herrb wrote: It seems to me that the C langage version of ucs2any.pl developped by Ben Collver and other NetBSD developpers is now stable enough to be included in XFree86. Two comments: 1.) While it is stable enough it is quite slow due to excessive and ineffecient use of regular expressions. 2.) A while ago I reported the fonts get build twice. We could confirm that problem in the meantime and found out that it was related to using a C version of ucs2any. Tatoku Ogaito finally fixed it by adding includes :: ucs2any to xc/fonts/util/Imakefile. Fonts get built twice on Cygwin as well. In fact, they probably get built twice on all platforms. The xc/fonts/util/Imakefile already has includes:: ucs2any in it in the version that I am compiling; yet, ucs2any is still run for each font during both the includes step and later during the all step. It seems that Tatoku Ogaito's patch (if his patch was to add the includes:: dependency) was included but it does not fix the problem. The root problem here is that ucs2any is being deleted and rebuilt, because of its dependencies, during the all stage of compilation. It breaks down like this: = 1) ucs2any is built using SimpleProgramTarget 2) SimpleProgramTarget calls ComplexProgramTarget 3) ComplexProgramTarget calls ProgramTargetHelper as such: ProgramTargetHelper(program,SRCS,OBJS,DEPLIBS,$(LOCAL_LIBRARIES),NullParameter) 4) ProgramTargetHelper sets up the dependencies as follows: ProgramTargetName(program): $(objs) $(deplib) 4) DEPLIBS is, in this case: $(DEPXAWLIB) $(DEPXMULIB) $(DEPXTOOLLIB) $(DEPXLIB) 5) The DEPLIBS have not yet been built during the includes stage. Why ucs2any is still built when its dependencies have not been built is sort of a mystery to me. In any case, ucs2any is built and run during the includes stage. 6) The DEPLIBS are built during all and upon return to the font/util directory during all, ucs2any is deleted and rebuilt since the DEPLIBS have a more recent timestamp. 7) All of the bdf files are thus rebuilt since the ucs2any timestamp has been updated. Building the fonts takes a really long time. Maybe my opinion doesn't matter, but I think that this patch needs to be corrected so that the fonts aren't built twice. I can think of at least one way to do this, which would be to call AllTarget and ProgramTargetHelper directly from xc/fonts/util/Imakefile, passing nothing as DEPLIBS. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: C version of ucs2any.pl
David Dawes wrote: On Fri, Sep 19, 2003 at 02:01:00PM -0400, Harold L Hunt II wrote: Matthieu (and Matthias), Matthias Scheler wrote: On Thu, Sep 18, 2003 at 10:58:19PM +0200, Matthieu Herrb wrote: It seems to me that the C langage version of ucs2any.pl developped by Ben Collver and other NetBSD developpers is now stable enough to be included in XFree86. Two comments: 1.) While it is stable enough it is quite slow due to excessive and ineffecient use of regular expressions. 2.) A while ago I reported the fonts get build twice. We could confirm that problem in the meantime and found out that it was related to using a C version of ucs2any. Tatoku Ogaito finally fixed it by adding includes :: ucs2any to xc/fonts/util/Imakefile. Fonts get built twice on Cygwin as well. In fact, they probably get built twice on all platforms. The xc/fonts/util/Imakefile already has includes:: ucs2any in it in the version that I am compiling; yet, ucs2any is still run for each font during both the includes step and later during the all step. Maybe removing the includes part of MakeTruncatedUCSBdfFont and MakeBdfFontFromUCSMaster would be sufficient? I don't remember why the conversion was done in the includes phase instead of the all phase, but removing the includes part from those rules worked here when I just tested it. David, Hmm... I don't know enough about how the fonts are built to say whether or not that is a good idea. However, I can say that changing SimpleProgramTarget(ucs2any) to the following stops ucs2any from being rebuilt when the DEPLIBS are built: NormalProgramTarget(ucs2any, ucs2any.o, , , ) ucs2any doesn't depend on any X libs so this seems to be fine. I build tested this on Cygwin without problems and confirmed that the fonts were only passed through ucs2any once. If it does need to be done in the includes phase, for example, because a host version of ucs2any is needed to do the conversion when cross-compliling, but a target version of ucs2any needs to get built later for installation, then I'd just remove $(UCS2ANY) as a dependency in MakeBdfFontFromUCSMaster(). If a dependency is still desired, make it be the source rather than the binary. BTW, how are things like host vs target imake binaries handled when cross-compiling? I think this are questions for Matthieu, right? Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: C version of ucs2any.pl
Matthieu, I appreciate the notification in advance of committing something like this. I am doing a build test right now on Cygwin. I will let you know if I find any problems. Harold Matthieu Herrb wrote: Hi, It seems to me that the C langage version of ucs2any.pl developped by Ben Collver and other NetBSD developpers is now stable enough to be included in XFree86. I've put a patch against the current XFree86 CVS version at http://www.xfree86.org/~herrb/ucs2any.diffs for those who'd like to review it. I plan to commit that in the next days if no problems are found. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: C version of ucs2any.pl
Matthieu, I found two things: 1) In ucs2any.c the libgen.h header is included only to provide basename, while a local definition of basename is provided for those platforms that don't have it. However, libgen.h is still included even on those platforms that define NEED_BASENAME. Thus, the build is broken on platforms that don't have libgen.h, regardless of whether NEED_BASENAME is defined or not. The #include libgen.h needs to be protected with #ifndef NEED_BASENAME, like so: #ifndef NEED_BASENAME #include libgen.h #endif 2) The zitoa function is defined statically but it isn't used within ucs2any.c. Is there any reason it should be included if it isn't in use? Harold Matthieu Herrb wrote: Hi, It seems to me that the C langage version of ucs2any.pl developped by Ben Collver and other NetBSD developpers is now stable enough to be included in XFree86. I've put a patch against the current XFree86 CVS version at http://www.xfree86.org/~herrb/ucs2any.diffs for those who'd like to review it. I plan to commit that in the next days if no problems are found. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Todd T. Fries wrote: Penned by Daniel Stone on Wed, Jul 30, 2003 at 04:51:49PM +1000, we have: [..] | I did suggest this (mv hp,v hp.old,v). If you guys care about history at all, aka the ability to checkout files in the past, you would not suggest nor impement this suggestion. Does history matter when some people simply cannot checkout a tag set because of a mistake that was made? The balanced response here is that the history is not as important as making sure that all developers can move forward. Of course, we do this only in rare circumstances, but this is one of them. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Thomas E. Dickey wrote: On Wed, 30 Jul 2003, Harold L Hunt II wrote: Todd T. Fries wrote: Penned by Daniel Stone on Wed, Jul 30, 2003 at 04:51:49PM +1000, we have: [..] | I did suggest this (mv hp,v hp.old,v). If you guys care about history at all, aka the ability to checkout files in the past, you would not suggest nor impement this suggestion. Does history matter when some people simply cannot checkout a tag set because of a mistake that was made? The balanced response here is that the history is not as important as making sure that all developers can move forward. Of course, we do this only in rare circumstances, but this is one of them. I fetch older versions all the time - on xfree86, I did that, for instance to narrow down the range of dates for a bug introduced into the mouse driver. Having a known working version of something lets you cut down on the effort to isolate a bug. (Moving forward doesn't use the archives for anything except an odd backup format). What's the problem here? Go look at HEAD! HEAD checks out just fine and has already had the hp file moved out of the way. Your argument is moot. The only problem is that the decision that was made and applied to HEAD has not been applied to xf-4_3-branch. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Egbert, My main question here is why does HEAD not have hp while xf-4_3-branch still does? I can checkout HEAD, but I cannot check out xf-4_3-branch because hp is in the way. Do the changes that you applied to HEAD need to be applied to xf-4_3-branch as well? Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Egbert, I don't see a way how you can work around this as there seems to be no way to exclude files from checkout/update. One could create an alias module in the CVS repositry which excludes the HP directory. Like xc-win -a !xc/programs/xkbcomp/geometry/HP xc Then doing a cvs checkout xc-win may work. However I suspect that a 'cvs update' will still fail as this doesn't know about the module concept. Does this mean I can only get HEAD and new branches from it? I just tried to get the xf-4_3-branch and it has the same problem as the xf-4_3_0_1 tag. I just did this: [EMAIL PROTECTED] ~/x-devel/4.3 $ export [EMAIL PROTECTED]:/cvs [EMAIL PROTECTED] ~/x-devel/4.3 $ export CVS_RSH=ssh [EMAIL PROTECTED] ~/x-devel/4.3 $ cvs -z3 checkout -r xf-4_3-branch xc cvs-checkout.log 21 I got: U xc/programs/xkbcomp/geometry/hp U xc/programs/xkbcomp/geometry/keytronic U xc/programs/xkbcomp/geometry/kinesis U xc/programs/xkbcomp/geometry/macintosh U xc/programs/xkbcomp/geometry/microsoft U xc/programs/xkbcomp/geometry/nec U xc/programs/xkbcomp/geometry/northgate U xc/programs/xkbcomp/geometry/pc U xc/programs/xkbcomp/geometry/sony U xc/programs/xkbcomp/geometry/sun U xc/programs/xkbcomp/geometry/winbook cvs [checkout aborted]: could not chdir to xc/programs/xkbcomp/geometry/HP: Not a directory Does that mean that xf-4_3-branch will never work for Cygwin and that there is nothing we can do to ever fix this? If so, that is really a bummer. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
David Dawes wrote: On Wed, Jul 30, 2003 at 01:09:50PM -0400, Harold L Hunt II wrote: Egbert, I don't see a way how you can work around this as there seems to be no way to exclude files from checkout/update. One could create an alias module in the CVS repositry which excludes the HP directory. Like xc-win -a !xc/programs/xkbcomp/geometry/HP xc Then doing a cvs checkout xc-win may work. However I suspect that a 'cvs update' will still fail as this doesn't know about the module concept. Does this mean I can only get HEAD and new branches from it? I just tried to get the xf-4_3-branch and it has the same problem as the xf-4_3_0_1 tag. I just did this: [EMAIL PROTECTED] ~/x-devel/4.3 $ export [EMAIL PROTECTED]:/cvs [EMAIL PROTECTED] ~/x-devel/4.3 $ export CVS_RSH=ssh [EMAIL PROTECTED] ~/x-devel/4.3 $ cvs -z3 checkout -r xf-4_3-branch xc cvs-checkout.log 21 I got: U xc/programs/xkbcomp/geometry/hp U xc/programs/xkbcomp/geometry/keytronic U xc/programs/xkbcomp/geometry/kinesis U xc/programs/xkbcomp/geometry/macintosh U xc/programs/xkbcomp/geometry/microsoft U xc/programs/xkbcomp/geometry/nec U xc/programs/xkbcomp/geometry/northgate U xc/programs/xkbcomp/geometry/pc U xc/programs/xkbcomp/geometry/sony U xc/programs/xkbcomp/geometry/sun U xc/programs/xkbcomp/geometry/winbook cvs [checkout aborted]: could not chdir to xc/programs/xkbcomp/geometry/HP: Not a directory Does that mean that xf-4_3-branch will never work for Cygwin and that there is nothing we can do to ever fix this? If so, that is really a bummer. Be a little patient. This problem will be fixed, and in a way that minimises the impact on the history loss. David David, Okay. For now I checked out xf-4_3-branch on a linux machine, tarred it, copied it to my Cygwin machine, and untarred it. This gives me a working repository, but ideally we will eventually fix this or at least try to prevent it from happening too often in the future. Thanks to everyone for their help, Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Egbert, I cannot checkout xf-4_3_0_1 because of this whole hp/HP issue. The following is from my cvs checkout log: cvs server: Updating xc/programs/xkbcomp/geometry U xc/programs/xkbcomp/geometry/Imakefile U xc/programs/xkbcomp/geometry/README U xc/programs/xkbcomp/geometry/amiga U xc/programs/xkbcomp/geometry/ataritt U xc/programs/xkbcomp/geometry/dell U xc/programs/xkbcomp/geometry/everex U xc/programs/xkbcomp/geometry/fujitsu U xc/programs/xkbcomp/geometry/hp U xc/programs/xkbcomp/geometry/keytronic U xc/programs/xkbcomp/geometry/kinesis U xc/programs/xkbcomp/geometry/macintosh U xc/programs/xkbcomp/geometry/microsoft U xc/programs/xkbcomp/geometry/nec U xc/programs/xkbcomp/geometry/northgate U xc/programs/xkbcomp/geometry/pc U xc/programs/xkbcomp/geometry/sony U xc/programs/xkbcomp/geometry/sun U xc/programs/xkbcomp/geometry/winbook cvs [checkout aborted]: could not chdir to xc/programs/xkbcomp/geometry/HP: Not a directory I *can* checkout HEAD, so maybe the patch below needs to be applied to the xf-4_3_0_1 branch as well? Note, I do get an hp file when I checkout xf-4_3_0_1, but then it tries to download the HP directory and freaks out on Cygwin. Is this the way that all other platforms work due to cvs, or is this specific to my platform because you can't have two files with the same name but different case? Harold Egbert Eich wrote: CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/06/20 06:15:33 Log message: - moving xkbcom/geometry/HP to xkbcom/geometry/hp doesn't seem to be possible as CVS doesn't allow a directory to have the same name as a deleted file. Added files: xc/programs/xkbcomp/geometry/HP/: Imakefile hp omnibook ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: fast way to check local X is running
Specify :0.1 (note: no hostname) as the DISPLAY. That will use UNIX domain sockets, which I am assuming that X using when you pass NULL. Harold Andriy Rysin wrote: Just found that if I use 'localhost:0.1' form, XOpenDisplay tries to connect with TCP stream, while if DISPLAY is NULL it choses fastest method it can find. And actually running just 'xlsfonts' with X down gives error right away. The problem is that I have to check for screen 0.1. Is there any way to use XOpenDisplay specifying screen 0.1 without forcing it to TCP mode? Thanks, Andriy Andriy Rysin wrote: I've got a server program trying to connect to local X server on command. If X runs everything is fine but if not timeout for XOpenDisplay is pretty long. I tried to run 'xlsfonts -display localhost:0.1' when X server is down and got about 6 sec delay. It's probably reasonable for remote X server because of network delays but for localhost there is probably a faster way. Delay is crucial in my case - I need to know if X is down in less than 2 sec, is there any mean to know really quick if local server is down? Thanks in advance, Andriy ___ 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: Repeating Keystrokes in X
Mark, Have you tried running 'xset r off'? Harold Mark Cuss wrote: Hello I'm not sure if this is an X problem or not - if not, please let me know... I have a Toshiba Satellite 2450 notebook on which I've recently installed RedHat 8. Everything works OK, except that sometimes in X when I type (in a terminal or anywhere else), my keystrokes are doubled up (ie - pressing s once results in 2 of them in the terminal). This can happen every 10th keystroke or so... This doesn't seem to happen when X isn't running, so I think it may be an X thing. I've attached my config file - I couldn't find anything out of the ordinary in here... If anyone has any suggestions I'd appreciate them... Thanks Mark Mark Cuss, B. Sc. Real Time Systems Analyst CDL Systems Ltd Suite 230 3553 - 31 Street NW Calgary, AB, Canada Phone: 403 289 1733 ext 226 Fax: 403 282 1238 www.cdlsystems.com http://www.cdlsystems.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Turning off key repeats from the server? [WAS: Re: Repeating Keystrokesin X]
Mark Vojkovich wrote: This is a kernel problem. /dev/console is returning duplicate key releases and XFree86 doesn't filter it out and sends duplicate key release events to the clients. I'm told it's fixed in some newer kernels. It seems to be specific to the Toshiba notebooks. Mark. I am interested by this key repeating problem because Cygwin/XFree86 has had, for a long time now, a problem where one call to mieqEnqueue results in two or more keys showing up on the screen. We have recently determined that this is due to the keyboard repeat mechanisms in the common X Server code, but I can't seem to find a way to disable it from the X Server in a manner similar to the way that 'xset r off' can disable it from the X Client side. Any ideas on how to essentially perform 'xset r off' without a client connection? I have searched and searched for a method to do this to no avail. Thanks in advance for any pointers, Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: repeated X restarts with i810 not freeing sys resources?
patrick charles wrote: On Thursday 13 February 2003 09:03 pm, David Dawes wrote: On Thu, Feb 13, 2003 at 02:11:40PM -0700, patrick charles wrote: On Wednesday 12 February 2003 10:20 pm, David Dawes wrote: On Tue, Feb 11, 2003 at 02:51:04PM -0700, patrick charles wrote: On Saturday 08 February 2003 05:41 pm, David Dawes wrote: On Sat, Feb 08, 2003 at 01:07:25PM -0700, patrick charles wrote: How would I communicate this? Somebody on XFree86 working with or have contact with the appropriate people in kernel/agpgart development? First of all, how are you killing the X server? I haven't seen this behaviour when the X server exits normally, and I've done a lot of testing where 32MB is allocated per run on machines with only 128MB of physical memory. There are people here familiar with the kernel agpgart driver. Note that just because top shows that there's little memory free doesn't mean that the agpgart driver isn't freeing it. Also the agpgart driver allocates physical pages, never swap. I'm not sure what the symptoms are when it can't get any free physical pages. On my test system the free memory indicated by top does go up when the X server exits, and this is on an otherwise idle system. So, I'd suggest starting a bare X server (run just 'X') on an otherwise idle system, see what top reports, then exit it cleanly (CtrlAltBackspace), and see if the free memory amount changes. Check the X server log to confirm how much memory was allocated via the agpgart mechanism (look for the lines containing Allocated). If that looks OK, then try the same thing you tried before but with a bare X server and an idle system. David David, I ran some tests as you suggested. I started up a bare X server using the command 'X' on an idle system. I then exited cleanly using ctrl-alt-bak. I recorded the amount of physical RAM free before and after the X start. I repeated this process. After 13 iterations, the machine became very sluggish. After 16 iterations, the machine hung. Still looks like X (or, the agpgart driver?) is not freeing resources. The machine gradually ran out of physical RAM. I just tried repeating this with what I think should be an even more demanding configuration: 845G system with 128MB physical memory, 1MB stolen memory (preallocated video memory), X configured to use 32MB video memory, so just over 31MB of physical memory needs to be allocated at each server start. After several iterations, I got to a pattern where the free memory after the server starts is 2MB, and the free memory when it exits is 41MB. I went as far as 25 iterations without any change in this pattern and without any slowdown. This is with RH 7.3, using the default kernel plus an agpgart driver patched for correct 845G support. The 2.4.20 kernel should already have the correct 845G agpgart support. The source for the agpgart driver I'm using can be found at http://www.xfree86.org/~dawes/intel-85x/agpgart-85x.tar.gz, in case that makes a difference. David Ok. To simplify my environment, I did a fresh install of Red Hat 8.0. I then installed kernel 2.4.20-2.21 and XFree86-4.2.99.3-20030115, taken as RPM's from the RH81 'phoebe' beta, required for the i845 support. So, I now have a 'clean' setup which doesn't contain any of the pieces which I previously downloaded/built from various cvs repositories. On this machine (which has quite a few services running since it is a default 8.0 workstation-type install), it only takes 6 restart iterations of X before the system hangs. I (unfortunately) have 4 of these brand new GX60 machines. I see the exact same behavior on all of them. Therefore, I don't think the problem is specific to a particular system. By using the RH RPM's, also doesn't appear that the problem stems from something peculiar in my build environment. You tried on an i845G and can't reproduce, but you are using RH7.3? Yep, RH7.3 with its default kernel plus the agpgart driver referenced above. Could you try your setup using that agpgart driver? That might help narrow down if the problem lies there or elsewhere. I don't see how the problem could be anywhere other than the kernel or agpgart driver. David i replaced agpgart.o with one recompiled from agpgart-85x.tar.gz % uname -a Linux localhost.localdomain 2.4.20-2.21 #1 Wed Jan 15 20:31:35 EST 2003 i686 i686 i386 GNU/Linux % ls -l /lib/modules/2.4.20-2.21/kernel/drivers/char/agp -rw-r--r--1 root root64920 Feb 14 12:21 agpgart.o -rw-r--r--1 root root23738 Jan 15 18:38 agpgart.o.gz.bak I am still seeing the same behavior. Yeah, you replaced the file, but did the new module get installed? Run lsmod as root: lsmod | grep agpgart Send in the results of that. Handling the easy stuff, :) Harold thanks, -pat ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel
RE: Fw: If you were writing a Windows and X clipboard integration manager...
Mike, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mike A. Harris Sent: Friday, January 31, 2003 2:46 AM To: [EMAIL PROTECTED] Subject: RE: Fw: If you were writing a Windows and X clipboard integration manager... On Thu, 30 Jan 2003, Harold L Hunt II wrote: See also this thread: https://listman.redhat.com/pipermail/xdg-list/2002-November/000881.html And Keith's X extension to monitor selection changes, though this won't be in 4.3. Wow! That looks really cool and it is already in the tree as xfixes, right? No, it was checked into CVS prior to the November feature cut off date, but has subsequently been removed from CVS, so it wont be in 4.3.0, and unfortunately maybe never. Oh... heh... well, I haven't updated my CVS tree in awhile, so I actually still have the directory with xfixes in it :) Even if the code never gets officially accepted I could at least use it, or a derivative of it, to fix the clipboard problems for Cygwin/XFree86. The extension doesn't have to be perfect for me, since I know that my clipboard integration manager will always be working with the built-in version of that extension. Even though that extension isn't in the XFree86-proper release, I might play around with it for the Cygwin-specific release. It sounds like the selection monitoring portions of the extension will fix my problems with PRIMARY completely! This is very exciting! Keith might have a diff perhaps or tarball, not sure though. Thanks for your input, Harold Hunt -- 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: If you were writing a Windows and X clipboard integration manager...
Andrew, Thanks for responding. Yes, there are at least 3 clipboard/cut-buffer mechanisms. We originally set out to watch for CUT_BUFFER0 to change, at which point we would copy it to the Windows clipboard. That seemed fine, except that non-U.S. users screamed bloody murder because CUT_BUFFERs do not let you get non ascii/latin1 encoded text. Also, some users claim that not all X applications paste data to CUT_BUFFER0. Thus, we changed to grabbing ownership of CLIPBOARD at startup. Then, when any application takes ownership of CLIPBOARD, we copy their text to the Windows clipboard and reassert ownership of CLIPBOARD. Our main problem is that last step. It causes X clients to unhighlight the selected region of text. On the other hand, if we do not reassert ownership of CLIPBOARD we will never know if it has changed again. There is supposedly some mechanism for a clipboard manager that has something to do with the CLIPBOARD_MANAGER atom. I have about 4 books and countless PDFs (including the ICCM) on X and I have read and reread what all of them have to say about the clipboard, and non of them tells you how to use CLIPBOARD_MANAGER. I came up with the idea that we could continue to copy text from the CLIPBOARD atom, but instead of reasserting ownership we could simply watch CUT_BUFFER0 for changes and copy from CLIPBOARD when CUT_BUFFER0 changes. People told me that this was not a good idea because not all applications touch CUT_BUFFER0 when they highlight or copy text. Could someone that has seen a lot of X applications tell me if watching CUT_BUFFER0 will work for 99% of X applications... because if it does it will certainly be better than our current solution of not working correctly with 100% of X applications. Thanks again for your input, Harold Dr Andrew C Aitchison wrote: On Thu, 30 Jan 2003, Harold L Hunt II wrote: ...how would you do it, in 150 words or less? Seriously, I have been working on this for over a year and I would love to hear some of the ideas that people have because I am completely stumped on how to make such a clipboard manager work properly. I'd be completely lost describing it in 150 words just for X. IIRC there are at least 3 clipboard/cut-buffer mechansims (no I can't remember them all). xprop -root lists 8 CUT_BUFFERX strings (and an atom called _MOTIF_CLIP_FORMAT_ACROBAT_SELECTION) There are about 5 (OK maybe only 3) ways of indicating a clipboard string in a non ascii/latin1 encoding, some of which can't be used by clients in different locales. Throw in MS Windows, and I'd be unhappy unless you can preserve the ability of X to mark in one window and paste in another, using only the mouse. I doubt I'd consider a windowing system without it, at least one based on keyboard+mouse, or even a stylus. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: If you were writing a Windows and X clipboard integration manager...
Owen, Owen Taylor wrote: Harold L Hunt II [EMAIL PROTECTED] writes: ...how would you do it, in 150 words or less? Seriously, I have been working on this for over a year and I would love to hear some of the ideas that people have because I am completely stumped on how to make such a clipboard manager work properly. You really want a server extension (or you could do it in the server, but that would prevent you from using existing client code to retrieve the clipboard contents ... a non-trivial task.) Ah ha! Now there is a new idea that I had not thought of yet. This could be promising. Are you saying that I could write a server extension that only Cygwin/XFree86 uses and that such an extension would give me access to the internals that I need? Or, are you saying that there needs to be a new generic server extension that all clients need to support in order for us to play nicely with them? See discussion from: https://listman.redhat.com/pipermail/xdg-list/2002-November/000881.html The extension discussed there will *not* be part of XFree86-4.3, but is the right way of doing it and likely will make it in at some future point. Very interesting. I will read up on that. It would be nice if someone responded this time... [ Hint, demanding a response is a really good way to discourage people from responding ] Of course. You'll notice in my first message that I did not make such an observeration. I got precisely 0 responses. This time I made that observation and I have gotten 2 extremely helpful replies. Sounds like your hint doesn't hold up :) You also have to understand that over the past two years, or so, I have probably written 8 new emails to this mailing list, of which 4 or more were completely ignored. That doesn't really seem very polite to me, since I only write to this mailing list after I have spent several months searching for an answer on my own. So yeah, you could call me frustrated :) Thanks again for your response, Harold Hunt Regard,s Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Fw: If you were writing a Windows and X clipboard integrationmanager...
Havoc, Havoc Pennington wrote: On Thu, Jan 30, 2003 at 03:11:08PM -0500, G O Economou wrote: In fact, I have made 8 releases :) I originally copied text from CUT_BUFFER0, which worked fine for me. As soon as I released this people started complaining about what it did not do (namely, it didn't handle non-U.S. text). CUT_BUFFER is completely obsolete and totally broken. Most newer apps don't even use it. Right, that is what most people keep telling me. However, I am a pragmatic guy. If the current effect is that 99% or even 75% of applications at least bump a CUT_BUFFER when the cut/copy text to the clipboard, then I could at least use this as a signal that I need to grab text from CLIPBOARD. The problem I have is that almost every commercial X Servers for MS Windows in existence has solved the problem of clipboard integration without causing X clients to unhighlight the current selection. Thus, I know that the problem is solveable. Worse, my users know that the problem is solveable and they keep asking me to solve it. Here is some background information: http://www.freedesktop.org/standards/clipboards.txt Of course you should also read the ICCCM before you do anything here. Oh, I have read it. In fact, I have had it mirrored for a long time: http://www.msu.edu/~huntharo/xwin/docs/xwindows/ICCCM.pdf Unfortunately, the ICCCM is about as vague as you can write a document without inspiring people to put down what they are doing, buy a gun, actively seek you out, and shoot you dead without bothering to drag you out into the street. Case in point, the whole MANAGER... the discussion of which leaves me completely clueless as to i) whether this would actually help me or not and ii) how to use it: http://tronche.com/gui/x/icccm/sec-2.html#s-2.8 See also this thread: https://listman.redhat.com/pipermail/xdg-list/2002-November/000881.html And Keith's X extension to monitor selection changes, though this won't be in 4.3. Yes, that works very worthwhile... but I hope it does not require that all client support the extension. I will figure that out when I read the docs on it later. Thanks so much for your thoughtful response, Harold Hunt Havoc ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Internal client connections to the X Server (for integrating the Windows and X clipboards)
I have been working on a small X Client called xwinclip for the Cygwin/XFree86 project (http://xfre86.cygwin.com) for over a year now. The aim of this program is to provide integration between the Windows clipboard and the X clipboard, but so far the results have been less than stellar. There are several commercial X Servers for MS Windows that have several desirable features that we have been unable to reproduce: 1) Not having to reown the XA_PRIMARY atom when the selection changes in X. We copy the X selection to the Windows clipboard whenever it is changed, but the only way to receive future change notification seems to be to retake ownership of the XA_PRIMARY atom. This causes the selected text, in say xterm, to become unselected. Many programs have features that allow you to manipulate selected text, so this is obviously a problem. None of the commercial X Servers have this problem. We have tried an alternative of only stealing ownership of XA_PRIMARY when our X Server loses the focus in Windows... but non of the commercial X Servers even does that; they NEVER steal ownership of XA_PRIMARY. 2) Since we are running an X Client to perform the clipboard integration we have problems with security on XDMCP sessions. The problem is that the local xwinclip client cannot connect to the local X Server unless you run xhost within you XDMCP session and specifically allow connections from the localhost. None of the commercial X Servers for Windows requires any special handling of the clipboard support for XDMCP sessions. These two problems have been largely unsolvable for me. Recently (i.e. this week) I integrated the functionality of xwinclip into the X Server executable, with the clipboard manager running in a separate thread than the X Server. Now that I have done this, I started thinking that there has to be an easier, perhaps internal, way to both monitor the updating of the selection and to prevent our clipboard manager's connection from being rejected. I remembered seeing somewhere in the X Server source code references to a fake connection number or something of that sort. I was wondering if there is a mechanism whereby the X Server can call functions in the X Client interface without actually having to authenticate with itself. If that was possible, it would seem that at least our authentication problem would be taken care of. So, does anyone know if that exists or have I been missing too much sleep lately? :) Any hints, tips, suggestions, or anything else related to the above two issues would be greatly appreciated. Thanks in advance, Harold Hunt Cygwin/XFree86 Project Leader ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
