Re: xterm "Not Responding" after wakeup from hibernate with Vista
On Wed, 2007-05-09 at 15:25 +, Scott Hussong wrote: > After running rebaseall, I got startx to work on my new HP vista laptop. > However, when I wake up from hibernate, any open xterms show "Not Responding". > > In my main cygwin window, where startx was executed, shows this: > > xterm: fatal IO error 104 (Connection reset by peer) or KillClient on X > server > ":0.0" > xinit: connection to X server lost. > > > I don't have this problem on my XPsp2 laptop. > > Anyone experience this and know a fix? Looks like the Xserver died for some reason. You should check your Xwin.log files. Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: xorg-x11-bin-dlls maintainer (ImageMagick problems)
On Thu, 2006-08-17 at 21:11 +0200, Reini Urban wrote: > Dear xorg-x11-bin-dlls maintainer, > > When do you plan to fix the broken ImageMagic package by providing the > three dll's which are not included anymore in the latest package? > The ImageMagick maintainer may add this new compatibility package to his > require line then. > > dll's cannot be just silently deleted. > > required for ImageMagick at least: >usr/X11R6/bin/cygdps-1.dll >usr/X11R6/bin/ygdpstk-1.dll > > usr/X11R6/bin/cygpsres-1.dll : >dont know which package requires this. The fact is that X.Org themselves have removed DPS support from future X11 releases because only client side libraries where ever available, and no server-side support. Additionally, I understand that Adobe has dropped DPS anyway. It could be moved to a compatibility package though as you say. But I understand that ImageMagick can be built with --with-dps=no and it would use ghostscript to deal with it's postscript rendering. It may even use ghostscript by default and never actually use DPS, but only if ghostscript isn't available, then use DPS. So I'd suggest rebuilding ImageMagick with --with-dps=no. Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Should 6.8.99.901-1 be marked experimental?
On Thu, 2006-08-17 at 13:31 -0700, James R. Phillips wrote: > Hi, > > AFAICT there is no release announcement for 6.8.99.901-1, and there are > several > bug reports requiring manual intervention or downgrades. In fact I am > experiencing lockups myself, and had to downgrade. > > This being the case (no release announcement + egregious regressions), > shouldn't 6.8.99.901-1 be marked as experimental, so people don't upgrade to > it > semi-automatically? If you haven't already, bugs should be filed at... http://bugs.freedesktop.org under the xorg component. Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Problem with starting X server
On Tue, 2006-07-18 at 23:55 +0200, Alexander Gottwald wrote: > Igor Peshansky wrote: > > This mount used to be routinely added by the X postinstall script. IIRC, > > this has been fixed in X so that such a mount is no longer required. > > Searching the list archives may unearth the relevant thread. However, the > > bug may have crept back, or may not have been propagated to the latest > > Cygwin/X release. > > I suspect that some bugfixes which were present in the CYGWIN branch on > freedesktop are missing in the branch which was the source for the > latest release. > > Most likely fonts.dir is not written in binmode. Patching mkfontscale > might help or forcing mkfontscale to work in binmode when started from > font-update. I see that the fix on the CYGWIN branch is to do this. So I'll make the change in the X.org repos. Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Looking for Cygwin/X maintainer
On Thu, 2006-03-02 at 12:09 -0500, Christopher Faylor wrote: > On Thu, Mar 02, 2006 at 05:00:48PM +0100, Corinna Vinschen wrote: > >On Mar 2 15:49, Alan Hourihane wrote: > >>On Thu, 2006-03-02 at 10:45 -0500, Christopher Faylor wrote: > >>>Our Cygwin/X maintainer seems to have disappeared so it looks like we, > >>>once again, are looking for volunteers to be the "go to person" for > >>>Cygwin/X. That would mean building new releases, handling problems in > >>>this mailing list, and keeping the cygwin-xfree web site up-to-date. > >>> > >>>If you are interested please reply to this message. > >> > >>I'm still here, but v. busy. > >> > >>So if someone does want to take over - feel free. > > > >It would really be helpful for the Cygwin/X project if somebody could > >take over. We would really appreciate if somebody with more time to > >reply to problems on this list and to look for bug-fixes etc. would > >volunteer. > > And to clarify - both Corinna and I sent Alan personal email asking for > feedback before I sent out my note. I wasn't trying to surprise Alan by > sending that note. But, yet more thoughts. Given that Chris & Corinna want a more active person to maintain Cygwin/X - I should stand down anyway. Thanks for having me. Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Looking for Cygwin/X maintainer
On Thu, 2006-03-02 at 12:09 -0500, Christopher Faylor wrote: > On Thu, Mar 02, 2006 at 05:00:48PM +0100, Corinna Vinschen wrote: > >On Mar 2 15:49, Alan Hourihane wrote: > >>On Thu, 2006-03-02 at 10:45 -0500, Christopher Faylor wrote: > >>>Our Cygwin/X maintainer seems to have disappeared so it looks like we, > >>>once again, are looking for volunteers to be the "go to person" for > >>>Cygwin/X. That would mean building new releases, handling problems in > >>>this mailing list, and keeping the cygwin-xfree web site up-to-date. > >>> > >>>If you are interested please reply to this message. > >> > >>I'm still here, but v. busy. > >> > >>So if someone does want to take over - feel free. > > > >It would really be helpful for the Cygwin/X project if somebody could > >take over. We would really appreciate if somebody with more time to > >reply to problems on this list and to look for bug-fixes etc. would > >volunteer. > > And to clarify - both Corinna and I sent Alan personal email asking for > feedback before I sent out my note. I wasn't trying to surprise Alan by > sending that note. Actually, I'll clarify. I haven't had anything in the last week or two. I did get an email from you on Feb 2nd I can see, but I've just come back from three weeks in the US, away from all things cygwin. So apologies for not replying. But in essence, if someone does want to stand up to take the maintainership - please feel free, I don't want to stand in anyone's way. Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Looking for Cygwin/X maintainer
On Thu, 2006-03-02 at 12:09 -0500, Christopher Faylor wrote: > On Thu, Mar 02, 2006 at 05:00:48PM +0100, Corinna Vinschen wrote: > >On Mar 2 15:49, Alan Hourihane wrote: > >>On Thu, 2006-03-02 at 10:45 -0500, Christopher Faylor wrote: > >>>Our Cygwin/X maintainer seems to have disappeared so it looks like we, > >>>once again, are looking for volunteers to be the "go to person" for > >>>Cygwin/X. That would mean building new releases, handling problems in > >>>this mailing list, and keeping the cygwin-xfree web site up-to-date. > >>> > >>>If you are interested please reply to this message. > >> > >>I'm still here, but v. busy. > >> > >>So if someone does want to take over - feel free. > > > >It would really be helpful for the Cygwin/X project if somebody could > >take over. We would really appreciate if somebody with more time to > >reply to problems on this list and to look for bug-fixes etc. would > >volunteer. > > And to clarify - both Corinna and I sent Alan personal email asking for > feedback before I sent out my note. I wasn't trying to surprise Alan by > sending that note. That's interesting - because I didn't get anything from either of you. Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Looking for Cygwin/X maintainer
On Thu, 2006-03-02 at 10:45 -0500, Christopher Faylor wrote: > Our Cygwin/X maintainer seems to have disappeared so it looks like we, > once again, are looking for volunteers to be the "go to person" for > Cygwin/X. That would mean building new releases, handling problems in > this mailing list, and keeping the cygwin-xfree web site up-to-date. > > If you are interested please reply to this message. I'm still here, but v. busy. So if someone does want to take over - feel free. Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Two old X11 problems
On Tue, 2005-12-20 at 18:55 -0400, Rodrigo Medina wrote: > Hi, > I will refer to two issues that have been around from two years, they are > more > X11 problems than Cygwin/X problems, but as I understand you Cygwin/X people > are close to the people that can fix them. > > 1- The xman program is not compatible with new versions of man. The >program should be modified in order to call nroff with the -c option. >See: http://sourceware.org/ml/cygwin-xfree/2004-03/msg00299.html > > 2- The us_intl keyboard of X11 is very limited. It doesn't have dead > accents, >and lacks of reversed "!" and reversed "?". The Windows US international >layout is much better. A us_intl_win layout has been proposed that > functions >like the Windows US-international. >See: http://sourceware.org/ml/cygwin-xfree/2003-11/msg00218.html Any bugs like this or Cygwin/X specific bugs too, can be filed at the Xorg bug database on http://bugs.freedesktop.org and choose xorg as the package. It would also be useful for those who actually produce patches to file bug reports and attach patches to fix problems so that they can be tracked accordingly. Thanks, Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: changes in monitor resolution
On Thu, 2005-11-03 at 11:02 +, Roger Levy wrote: > Hi, > > I use Cygwin/X on my laptop all the time, and I often switch back and > forth between my XGA laptop display and an SXGA external monitor. (I > use startxwin.bat to start the X server.) What I find is that when I > start xwin while my laptop display is active, and then switch to the > external monitor, nothing displaying through X is visible on the bottom > and right-hand sides of the display. I assume that this is because > startxwin.bat detected my monitor resolution as XGA and so configured > its resolution as 1024x768, and doesn't automatically resize when I > switch displays. I can fix this by closing the X server and then > restarting it, but then I have to close all my X clients too. > > Is there a way to either (a) automatically start X with SXGA resolution, > or (b) manually resize X after I switch monitors, without restarting it? There isn't a current way to do it. Although I've got plans to make XWin understand the RandR extension which is the rotate & resize facility. This way we can get an event of when the screen size changes and update the Xserver to handle the new size. Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Missing dll's in new package [was Re: Please upload: xorg-*-6.8.99.901]
On Thu, 2005-10-27 at 19:56 -0400, Nicholas Wourms wrote: > On 10/27/05, Alan Hourihane wrote: > > > Yep, uploading myself to sourceware now. > > > > They'll be in-place in the next hour. > > Alan, > > I've taken the opportunity to evaluate the new package. Prior > versions of Cygwin/Xorg provided the dlls and development files for > the libDPS interface. For some reason, they were omitted in this > release. I've been hunting through the Imake config files, and I > cannot understand why they weren't built. Perhaps this is a problem > in the packaging script? This test version was built from the mainline X.Org trunk code and not the CYGWIN branch. I'll be working on getting whatever changes exist on that branch over into the mainline trunk code next. If the patches are still in CYGWIN then that's the problem. Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Xorg
On Fri, 2005-10-21 at 12:04 -0500, Yaakov S (Cygwin Ports) wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Alan Hourihane wrote: > > Certainly for the RC1 candidate it's going to be based off the > > monolithic build, and still in /usr/X11R6. > > And what are your plans for future releases? To switch to the modular build without a doubt. But currently the scripts that build and package Cygwin/X are based on the monolithic tree. So that's where I'm starting from. Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Xorg
On Thu, 2005-10-20 at 17:02 -0500, Yaakov S (Cygwin Ports) wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Alan Hourihane wrote: > > Seeing as X.Org has just released their 6.9/7.0 RC1 candidate release > > I'm currently building it for a test release for Cygwin/X. > > > > I'll announce it more formally when I've completed the packaging and > > uploaded to the relevant sites. > > > > If people can test this it'll ensure we can make the transition much > > more smoothly. > > Are you using the 7.0 libtoolized packages? And what about a move to > prefix=/usr? Certainly for the RC1 candidate it's going to be based off the monolithic build, and still in /usr/X11R6. Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Xorg
Seeing as X.Org has just released their 6.9/7.0 RC1 candidate release I'm currently building it for a test release for Cygwin/X. I'll announce it more formally when I've completed the packaging and uploaded to the relevant sites. If people can test this it'll ensure we can make the transition much more smoothly. Thanks, Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Firefox on cygwinX
On Wed, 2005-10-19 at 11:32 -0400, Richard Campbell wrote: > Alan Hourihane wrote: > > On Wed, 2005-10-19 at 08:14 -0700, Charles Li wrote: > > > >> I look through the setup and can not find cl, I have > >> all the gcc installed. What else do I need? > > > > Sounds like you have Visual C++ (or equivalent) installed and that's > > where the program 'cl' comes from. It will be in your environment. > > This is not right. The Firefox configure file ends up hardcoding > cl if it detects a windows platform. You have to export CC/CXX/CPP > variables to override cl. > > See http://citations.mozdev.org/mozilla-build-win32.html > > Cygwin-X is not a supported build target. > > Gerrit Haase was working on supporting Firefox on Cygwin-X. See > this thread: > http://www.cygwin.com/ml/cygwin-xfree/2005-08/msg00071.html Thanks for the info Richard. I find it a little broken on Firefox's part to be hardcoding the compiler like that though just because it detects a Windows platform. Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Firefox on cygwinX
On Wed, 2005-10-19 at 08:14 -0700, Charles Li wrote: > I am trying to install FireFox on cygwinx. > > I got the following errors: > + > $ ./configure > loading cache ./config.cache > checking host system type... i686-pc-cygwin > checking target system type... i686-pc-cygwin > checking build system type... i686-pc-cygwin > checking for gcc... cl > checking whether the C compiler3a (cl ) works... no > configure: error: installation or configuration > problem: C compiler cannot create executables. > + > > I look through the setup and can not find cl, I have > all the gcc installed. What else do I need? Sounds like you have Visual C++ (or equivalent) installed and that's where the program 'cl' comes from. It will be in your environment. Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
RE: Tekplot application repeatedly redraws under XFree
On Tue, 2005-10-11 at 12:40 -0500, Berndt, Jon S wrote: > > Look in /usr/X11R6/bin/startxwin.sh and look for the line that says... > > > > XWin -multiwindow -clipboard -silent-dup-error & > > > > and change it to > > > > XWin -rootless -clipboard -silent-dup-error > > > > That will give you an Xserver with no window manager and then > > allow you to start the one from your IRIX box. > > > > Alan. > > That didn't seem to help. I still get the MS Windows window manager as > well as the IRIX wm. Also, after I reverted, the tekplot application > will now not plot anything at all. Then maybe you are not using startxwin.sh ?? How are you starting X ? Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
RE: Tekplot application repeatedly redraws under XFree
On Tue, 2005-10-11 at 10:20 -0500, Berndt, Jon S wrote: > > O.k. It sounds like tekplot's problem then on the way it's > > dealing with window events. > > > > Alan. > > You might be on to something, though. I started up the IRIX window > manager, 4Dwm. Most of my windows then had the standard MS-Windows > frame, and within that, the Motif-style window manager > decorations/frame. If I made a plot using Tekplot, and moved the plot > window around when it initially had the MS-Windows frame around it, then > the window would redraw once. At that time the "extra" MS-Windows style > frame would disappear, and the only remaining frame was the 4Dwm frame. > At that point, nothing I could do seemed to cause a redraww of the plot > window. I'm using rxvt. Now, I'm wondering if I ought to use only native > X-windows apps, xterms, etc. > > I'd also like to be able to start up Xwin with NO window manager, if I > can start one up on the remote machine (like 4Dwm on the remote IRIX > machine). Is that possible? Which window manager starts up when the X > server is started up on the local PC? Look in /usr/X11R6/bin/startxwin.sh and look for the line that says... XWin -multiwindow -clipboard -silent-dup-error & and change it to XWin -rootless -clipboard -silent-dup-error That will give you an Xserver with no window manager and then allow you to start the one from your IRIX box. Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
RE: Tekplot application repeatedly redraws under XFree
On Tue, 2005-10-11 at 09:24 -0500, Berndt, Jon S wrote: > > Alan Hourihane wrote: > > > Which window manager are you using Jon ? > > > > Alan. > > I'm not sure. I am using pretty much the standard startup for Xwin. How > can I find out which I'm using. O.k. It sounds like tekplot's problem then on the way it's dealing with window events. Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Tekplot application repeatedly redraws under XFree
On Tue, 2005-10-11 at 09:08 -0500, Berndt, Jon S wrote: > Greetings: > > I am using Cygwin/Xfree: > > version number:11.0 > vendor string:The Cygwin/X Project > vendor release number:60802000 > > The operating system is MS Windows XP. > > I have found that when using the Tekplot application, if I move the > window around a bit, almost always it will begin to perpetually redraw > the graph. All other applications I have tried appear to work as > expected: Netscape, Firefox, Clearcase, Nedit, etc. > > I have tried running with backing store turned both ON and OFF (as well > as save-unders) - don't know if that makes a difference. > > I have tried searching the web, readign FAQS, etc., but can't find > anything that helps. > > Any suggestions? Which window manager are you using Jon ? Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Shaped windows one logical unit out?
On Tue, 2005-08-30 at 20:35 +0100, Colin Harrison wrote: > Hi, > > Further to my 'picture tells a thousand words' series of patches:- > > Before my patch:- > http://www.straightrunning.com/test/faulty_shaped_windows.png > > after:- > > http://www.straightrunning.com/test/corrected_shaped_windows.png > > Original Patch:- > > http://cygwin.com/ml/cygwin-xfree/2005-08/msg00020.html Committed. Thanks. You might want to upload bug reports/fixes/enhancements to bugs.freedesktop.org so they can be tracked accordingly for the inclusion into X.Org. Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Build problems, still.
I've just committed a couple of fixes which should cure the immediate problems. Let me know if something still doesn't work right. Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Build problems, still.
On Wed, 2005-08-24 at 00:46 -0400, Joe Krahn wrote: > Has anyone gotten a full build to work recently? I got past the > compsize.c changes in building the GL libs, but ran into similar > problems in server GLX code. > > What is the relationship of Cygwin xc/ to the main Xorg xc/? Joe, I'm working on this at the moment. I should have it fixed later today or tomorrow. Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Spam: XFree86 maintainer
On Mon, 2005-08-22 at 13:33 +0200, Corinna Vinschen wrote: > On Aug 22 12:09, ?yvind Harboe wrote: > > I miss Alexander :-) > > > > Any word on a new cygwin-xfree maintainer? > > Unfortunately not. Is anybody willing to step up, perhaps somebody who > already looked into the xfree sources more than once? If no one steps up for the job, then I'll volunteer. But my time is limited, so I won't be able to make releases at the frequency Alexander did. Alan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: OpenGL compatibility with Cygwin/X
Have you got a copy of the XWin output when you run Tecplot. That might help me track things down. I don't think it's a problem with the application if Exceed runs perfectly well with it, so contacting their support may well be fruitless. Alan. On Fri, 2005-07-22 at 15:03 +0200, Mathieu OUDART wrote: > Thanks Alan, > > your Xwin_GL seems to greatly improve OpenGL support ! > > Most of GLUT demos now run perfectly. Only a few of them return a > "GLXBadContext" > > Unfortunately Tecplot also quit with "GLXBadContext". > I'll try to contact support about this problem. > > Be sure I'll get you informed if I find a solution. > > Regards. > > > Alan Hourihane a écrit : > > >Mathieu, > > > >I had a test version of XWin_GL on my homepage - available at > > > >http://www.fairlite.demon.co.uk/XWin_GL.exe > > > >Give that a try, and see if it helps. > > > >Alan. > > > >On Fri, 2005-07-22 at 13:31 +0200, Mathieu OUDART wrote: > > > > > >>I've already tried to run Xwin with "-depth 8" and "-fullscreen" without > >>much success. > >>So, the solution is .. to be patient ? > >>Thanks. > >> > >>Alexander Gottwald a écrit : > >> > >> > >> > >>>Mathieu OUDART wrote: > >>> > >>> > >>> > >>> > >>> > >>>>Using Xwin_GL > >>>>- glxinfo : > >>>> OpenGL vendor string: Intel > >>>> OpenGL renderer string: Intel Solano > >>>>- glxgears => OK (very fluent) > >>>>- GLUT demo => NO > >>>> GLUT: Fatal Error in (unamed): visual with necessary capabilities > >>>>not found. > >>>>- Tecplot animation => NO (X Protocol error: GLXBadContext) > >>>> > >>>>Using Exceed 3D : > >>>>- Tecplot animation => OK > >>>>- GLUT demo => OK > >>>> > >>>>Does it miss something with my Cygwin/X to get necessary extensions ? > >>>> > >>>> > >>>> > >>>> > >>>The accelerated OpenGL support does still require some work. Maybe running > >>>a different colordepth can help. > >>> > >>>bye > >>> ago > >>> > >>> > >>> > >>> > > > >-- > >Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > >Problem reports: http://cygwin.com/problems.html > >Documentation: http://x.cygwin.com/docs/ > >FAQ: http://x.cygwin.com/docs/faq/ > > > > > > > > > > > > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: OpenGL compatibility with Cygwin/X
Mathieu, I had a test version of XWin_GL on my homepage - available at http://www.fairlite.demon.co.uk/XWin_GL.exe Give that a try, and see if it helps. Alan. On Fri, 2005-07-22 at 13:31 +0200, Mathieu OUDART wrote: > I've already tried to run Xwin with "-depth 8" and "-fullscreen" without > much success. > So, the solution is .. to be patient ? > Thanks. > > Alexander Gottwald a écrit : > > >Mathieu OUDART wrote: > > > > > > > >>Using Xwin_GL > >>- glxinfo : > >>OpenGL vendor string: Intel > >>OpenGL renderer string: Intel Solano > >>- glxgears => OK (very fluent) > >>- GLUT demo => NO > >>GLUT: Fatal Error in (unamed): visual with necessary capabilities > >>not found. > >>- Tecplot animation => NO (X Protocol error: GLXBadContext) > >> > >>Using Exceed 3D : > >>- Tecplot animation => OK > >>- GLUT demo => OK > >> > >>Does it miss something with my Cygwin/X to get necessary extensions ? > >> > >> > > > >The accelerated OpenGL support does still require some work. Maybe running > >a different colordepth can help. > > > >bye > >ago > > > > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Unable to launch openGL application on cygwin/X server from S un S olaris OS
There's an old copy of some work I did a while back for XWin_GL.exe. You might want to try that. It's at http://www.fairlite.demon.co.uk/XWin_GL.exe. I should clean up what I have and get it committed at some point. Let me know if you get chance to try it and any results you get. Alan. On Fri, Nov 19, 2004 at 01:49:32PM +0100, Gautier, Valentin wrote: > Thanks for your help. > > I try to change windows colordepth but it doesn't do any change, and when I > launch XWin_GL with GLWIN_DUMP_PFD=1 , I can see that nothing is happening > when I try to launch my Solaris OpenGL application, nor there is any context > creation. I don't make any conclusion but I think it fail at the very > beginning ! > > > -Original Message- > From: Alexander Gottwald [mailto:[EMAIL PROTECTED] > Sent: vendredi 19 novembre 2004 11:47 > To: [EMAIL PROTECTED] > Subject: Re: Unable to launch openGL application on cygwin/X server from Sun > S olaris OS > > > Solaris apps like using fixed colordepths and strange visuals. Maybe you > should try > changing the colordepth of windows to any of 8bit, 16 or 24bit > > You can start XWin_GL with the environment variable GLWIN_DUMP_PFD=1. this > will print > some extra information on visual creation. > > GLWIN_DUMP_PFD=1 /usr/X11R6/bin/XWin_GL -multiwindow -clipboard > -silent-dup-error > > Maybe this will a clue what's failing. > > bye > ago > -- > [EMAIL PROTECTED] > http://www.gotti.org ICQ: 126018723
Re: Cygwin/X developement: -EMULATEPSEUDO
On Tue, Sep 14, 2004 at 04:58:45PM +0200, Alexander Gottwald wrote: > On Tue, 14 Sep 2004, Sebastian Haby wrote: > > > I started to try out Cygwin/X to remotely use a Solaris app, however, the > > app uses 8bpp Pseudocolor visual which is only > > supported in Cygwin/X when running the windows desktop in 8bpp aswell or > > fullscreen, ie. the app works just fine in these two cases. > > However I can't use any of these options and therefor need to get the > > -emulatepseudo option to work. > > Unfortunatly there has been no activity in this field for some time and > after Harold left the project there is noone left with sufficient knowledge > of the problem to start again. I can only try to outline my general knowledge > of the xserver internals. I'll try to shed some light on this for you Alexander. Basically the -pseudocolor mode in Cygwin/X doesn't work properly. Harold added it to try and let applications that need pseudocolor to work, but he also knew about the color problems. So it's nothing new that it doesn't work properly. Now, in the CVS in the trunk there are some new files called xc/programs/Xserver/fb/fbpseudocolor.[ch] which is meant to add support for pseudocolor emulation, but executing the wrapper function xxSetup(...) with the appropriate arguments. Egbert Eich wrote this code, so he may be able to shed some more light on it's usage pattern, but this is the way to go to fix the support for Cygwin/X. Alan.
Re: Takuma Murakami added to commit list
On Tue, Feb 03, 2004 at 08:42:18PM -0500, Harold L Hunt II wrote: > >On Tue, Feb 03, 2004 at 07:19:40PM -0500, Harold L Hunt II wrote: > >>>On Tue, Feb 03, 2004 at 12:23:57PM -0500, Harold L Hunt II wrote: > Takuma Murakami has been contributing patches for a few months now. To > make submitting clean patches easier for Takuma, and since we can now > provide this, I have added Takuma to the list of commiters for the xorg > tree on freedesktop.org. > > Remember, we can now give commit access to anyone that demonstrates an > interest in the success of the project by submitting a few clean > patches. If you have big plans for features, send some small patches > >>to >>get started, then we can set you up with commit access for your > continuing changes. > >>> > >>>Harold, > >>> > >>>I just want to understand what's happening with the project on > >>SourceForge > >>>that we had control over anyway and you could add new committers there > >>>anyway ? > >>> > >>>Alan. > >> > >>Alan, > >> > >>Well, the problem with the SourceForge project was that it was not where > >>our upstream changes originated from and it was not the upstream final > >>destination for our changes. We got changes from non-Cygwin specific > >>portions of the code and we made changes to non-Cygwin specific portions > >>of the code. Thus, we could not ignore the fact that we had an upstream > >>tree that we would always want to stay in sync with. > >> > >>The new xorg repository on freedesktop.org is our new upstream home. > >>That makes it less work for me to keep our work in sync with our > >>upstream tree. All we have to do now is merge from the CYGWIN branch > >>back to the CURRENT branch. Even better, I can delegate this to other > >>people that can *do* it rather than them just asking that it be done and > >>then follow it for two months waiting to make sure that it was done > >>correctly. > >> > >>It is really great and has dramatically cut down the amount of time that > >>I spend doing administrative tasks for Cygwin/X. It freed up enough > >>time that I was able to, gasp, actually start working on new features > >>again such as the improved clipboard integration. :) > >> > >>I hope that clears things up, > > > >Not really. I'm confused over what you mean by upstream. > > Lets look at this from the analogy of Linux for a minute. People make > lots of generic changes to Linux that apply to all architectures that > are supported by Linux. Now, assume that instead of supporting the > Cygwin port of X that I am supporting the Alpha port of Linux. My users > will expect me to make releases when the official Linux project makes > releases such as 2.4.0-25 or 2.6.0-1 since they want all of those > "upstream" generic changes. Similarly, people I need to make sure that > the code for my Alpha port (and any bug fixes made to generic files) > finds its way back to the "upstream" Linux tree so that the Alpha > support will be up to date. > > The SourceForge project did not help meat any of those goals. It > provided a place to develop some code in isolation, but it did nothing > to help get code back to the official tree. In fact, it created quite a > bit of work, because my 4.3.0 tree that I used for builds was different > than the XFree86 HEAD, and both of these were different from the code in > the SourceForge tree. Mind you, I am talking only about the code in the > hw/xwin directory; there were enough differences in that code alone to > make merging patches from one tree to another a bit of a chore. > > Additionally, we would frequently introduce support for new features > added to the "upstream" (or XFree86) tree, such as Kensuke's new > multi-window window manager that uses the miext/rootless extension > developed for X on X. That extension wouldn't exist in the SourceForge > tree unless we imported it... and that is a pain to do when it is under > heavy development. Since the XFree86 tree is the tree that originated > the miext/rootless code, then any bug fixes that we make to that code > have to go back "upstream" to the XFree86 tree. But if Torrey makes changes to the miext/rootless code you can either ignore them, or import them again from XFree86. > In the case of the XFree86 tree, syncing with the upstream tree was a > pain in the ass because no one would let us do things for ourselves, > even when they were platform specific fixes. We had to put patches in a > queue (and mind you, generating perfect patches is not easy, you might > have forgotten that since you had CVS commit access for so long), mind > the queue, thunk people on the heads when they ignored or misapplied our > patches, wait about two months, etc. and finally be able to cross a > single item off of our to-do list. But I see your importing tag's already from XFree86. I see you've brought in 4.3.99.16 not long ago. So there's still merging work going on. > T
Re: Takuma Murakami added to commit list
On Tue, Feb 03, 2004 at 07:19:40PM -0500, Harold L Hunt II wrote: > >On Tue, Feb 03, 2004 at 12:23:57PM -0500, Harold L Hunt II wrote: > >>Takuma Murakami has been contributing patches for a few months now. To > >>make submitting clean patches easier for Takuma, and since we can now > >>provide this, I have added Takuma to the list of commiters for the xorg > >>tree on freedesktop.org. > >> > >>Remember, we can now give commit access to anyone that demonstrates an > >>interest in the success of the project by submitting a few clean > >>patches. If you have big plans for features, send some small patches to > >>get started, then we can set you up with commit access for your > >>continuing changes. > > > >Harold, > > > >I just want to understand what's happening with the project on SourceForge > >that we had control over anyway and you could add new committers there > >anyway ? > > > >Alan. > > Alan, > > Well, the problem with the SourceForge project was that it was not where > our upstream changes originated from and it was not the upstream final > destination for our changes. We got changes from non-Cygwin specific > portions of the code and we made changes to non-Cygwin specific portions > of the code. Thus, we could not ignore the fact that we had an upstream > tree that we would always want to stay in sync with. > > The new xorg repository on freedesktop.org is our new upstream home. > That makes it less work for me to keep our work in sync with our > upstream tree. All we have to do now is merge from the CYGWIN branch > back to the CURRENT branch. Even better, I can delegate this to other > people that can *do* it rather than them just asking that it be done and > then follow it for two months waiting to make sure that it was done > correctly. > > It is really great and has dramatically cut down the amount of time that > I spend doing administrative tasks for Cygwin/X. It freed up enough > time that I was able to, gasp, actually start working on new features > again such as the improved clipboard integration. :) > > I hope that clears things up, Not really. I'm confused over what you mean by upstream. But nevermind, you've moved to freedesktop.org, so I agree with Alexander about moving the docs and deleting the XonCygwin project from SF. Alan.
Re: Takuma Murakami added to commit list
On Tue, Feb 03, 2004 at 12:23:57PM -0500, Harold L Hunt II wrote: > Takuma Murakami has been contributing patches for a few months now. To > make submitting clean patches easier for Takuma, and since we can now > provide this, I have added Takuma to the list of commiters for the xorg > tree on freedesktop.org. > > Remember, we can now give commit access to anyone that demonstrates an > interest in the success of the project by submitting a few clean > patches. If you have big plans for features, send some small patches to > get started, then we can set you up with commit access for your > continuing changes. Harold, I just want to understand what's happening with the project on SourceForge that we had control over anyway and you could add new committers there anyway ? Alan.
Re: Notes on adding accelerated OpenGL support to Cygwin/X
On Fri, Jan 30, 2004 at 06:54:57PM +0100, Alexander Gottwald wrote: > On Fri, 30 Jan 2004, Alan Hourihane wrote: > > > Apparently SciTech (Kendall Bennett) donated some code (a driver) for Mesa > > that allows it to accept the OpenGL commands from the client and call > > the equivalent Direct3D counterparts thus providing hardware that has > > a more capable Direct3D layer much more benefit. > > I've seen this too. But it seems that this driver was not updated for a long > time. The notes state that this driver was included in mesa 3.x and I've found > no evidence that anybody put hands on it later. > > But I might be wrong with this. I believe Kendall updated it for Mesa 5.x and Karl is working on getting it integrated into the current Mesa 6.x - or that's my understanding. Karl is most certainly the best person to speak to as he's got the code. Alan.
Re: Notes on adding accelerated OpenGL support to Cygwin/X
On Fri, Jan 30, 2004 at 11:11:41AM -0600, Brian Ford wrote: > On Fri, 30 Jan 2004, Alan Hourihane wrote: > > > One note Harold on this > > > > You'll find that a lot of OpenGL drivers that are used on Windows are > > seriously lagging behind in support for the hardware. That's because > > a lot of vendors don't bother updating support for OpenGL directly > > and are more interested in Direct3D. > > > That is probably because Microsoft does the same. They only ship/support > OpenGL 1.1. Everything else is an extension that needs to be loaded > manually via GetProcAddress. Exactly. An ATI and nVidia do support later versions of OpenGL via this method. > > Just run a native 'glinfo' application and you'll see that ATI and nVidia > > are pretty good in this area and provide very up-to-date OpenGL drivers. > > But others aren't so great. > > > But, you still have to jump through the GetProcAddress hoops to get there, > even with ATI and nVidia because of the base layer that Microsoft > provides. Exactly again. It's not impossible though. > > Apparently SciTech (Kendall Bennett) donated some code (a driver) for Mesa > > that allows it to accept the OpenGL commands from the client and call > > the equivalent Direct3D counterparts thus providing hardware that has > > a more capable Direct3D layer much more benefit. > > > > I think Karl Schultz on the Mesa list has the code and is integrating it, > > but I don't know the status. You may want to contact him. > > > > You won't need this to get started though, but it's certainly worth > > investigating once you've got an initial implementation. > > > This would be a good option to have, but I wouldn't make it exclusive. No, but as an option. Alan.
Re: Notes on adding accelerated OpenGL support to Cygwin/X
One note Harold on this You'll find that a lot of OpenGL drivers that are used on Windows are seriously lagging behind in support for the hardware. That's because a lot of vendors don't bother updating support for OpenGL directly and are more interested in Direct3D. Just run a native 'glinfo' application and you'll see that ATI and nVidia are pretty good in this area and provide very up-to-date OpenGL drivers. But others aren't so great. Apparently SciTech (Kendall Bennett) donated some code (a driver) for Mesa that allows it to accept the OpenGL commands from the client and call the equivalent Direct3D counterparts thus providing hardware that has a more capable Direct3D layer much more benefit. I think Karl Schultz on the Mesa list has the code and is integrating it, but I don't know the status. You may want to contact him. You won't need this to get started though, but it's certainly worth investigating once you've got an initial implementation. Alan.
Re: Proper attribution of patches
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.21&r2=3.22&f=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. Alan.
Re: screen redraw problem
JS, Can you tell us about the application - is it available anywhere so I can take a look too ? Alan.
Re: New package: gv-3.5.8-1
Can these announce messages, be left to the cygwin-announce-xfree... lists. That's what they are there for, and refrain from cross posting this stuff. Alan. On Tue, Nov 04, 2003 at 05:24:33PM +0100, Dr. Volker Zell wrote: > The gv-3.5.8-1 package has been added to the Cygwin distribution. > > o http://wwwthep.physik.uni-mainz.de/~plass/gv/ > > Description: > > `gv' is a comfortable viewer of PostScript and PDF files for the X Window System. > It uses the `ghostscript' PostScript(tm) interpreter and is based on the classic X > front-end > for `gs', `ghostview'. It is more comfortable and more powerful than `ghostview'. > > -- > > Volker Zell > > To update your installation, click on the "Install Cygwin now" link on > the http://cygwin.com/ web page. This downloads setup.exe to your > system. Once you've downloaded setup.exe, run it and select "XFree86" > and then click on the appropriate field until the above announced > version number appears if it is not displayed already. > > Note that downloads from sources.redhat.com (aka cygwin.com) aren't > allowed due to bandwidth limitations. This means that you will need > to find a mirror which has this update. > > In the US, ftp://archive.progeny.com/cygwin/ > is a reliable high bandwidth connection. > > In Japan, ftp://ftp.u-aizu.ac.jp/pub/gnu/gnu-win32/ is usually > up-to-date. > > In DK, http://mirrors.sunsite.dk/cygwin/ is usually up-to-date. > > If one of the above doesn't have the latest version of this package > you can either wait for the site to be updated or find another > mirror. > > Please send questions or comments to the Cygwin/XFree86 mailing list at: > [EMAIL PROTECTED] . If you want to subscribe go to: > http://cygwin.com/lists.html I would appreciate if you would use > this mailing list rather than emailing me directly. This includes > ideas and comments about the setup utility or Cygwin/XFree86 in general. > > If you want to make a point or ask a question the Cygwin/XFree86 mailing > list is the appropriate place.
Re: Cygwin/XFree86 - No longer associated with XFree86.org
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 ? 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 ? Alan.
Re: Generic rootless
On Mon, Oct 20, 2003 at 01:27:59PM -0400, Harold L Hunt II wrote: > Kensuke, > > Okay, I got it to build and run. It is very nice. > > What you think about renaming old '-rootless'to '-oldrootless' and > calling the new '-win32rootless' just '-rootess'? > > -win32rootless is going to cause a lot of trouble for people to > remember, and most people will get confused about the distinction > between -rootless and -win32rootless. Is there any reason to suspect > that the old '-oldrootless' will remain in use after the new '-rootless' > is available? It would seem to me that we might even want to just > replace the original rootless functionality with the new functionality > that uses the shared code. > > Anybody have some input on this? I agree Harold. Deprecate the old one and remove the code, unless there's some benefits to using it. Alan.
Re: Code reorganization heads up
On Mon, Jun 02, 2003 at 09:41:11AM -0400, Harold L Hunt II wrote: > All developers, > > I am pulling code out of winmultiwindowwindow.c and putting it into > separate files that deal with more specific tasks. This single file has > grown to over 50 KiB, so it is time to break it apart to make it more > manageable. This should have been done some time ago, but, well, it wasn't. > > Please try to hold off on any big patches until after tonight when I > release a new test version. Harold, I think it's worthwhile either doing more of this in the xoncygwin CVS or sending me a few patches to merge into the XFree86 CVS, as and when your ready. How you fixed for a 4.3.0 release ? I can do the build and produce the binaries if someone can package it up for the setup.exe application. Alan.
Re: Xv/XVideo?
On Sun, Mar 16, 2003 at 05:32:54 -0500, Harold L Hunt II wrote: > Alexander Gottwald wrote: > >Thor Johnson wrote: > > > > > >>Greetings (and mucho thanks for the -norestart option for Xhost oddities)! > >> > >>I have a new boneheaded question: > >>What is the difference between xv (as used in mplayer, ogle, etc) and > >>XVideo? > > > > > >I don't know it for sure, but it's the same. XVideo is an interface to the > >XServer to allow a fast display of video. With XVideo you can for example > >get access to the backend scaler of the graphicscard and let the > >graphicscard > >scale the video to fullscreen. > > > >But this depends on the used graphicscard and for each graphicscard you > >need > >a special driver, which we don't have for Cygwin/XFree86. > > > > You know, we might be able to quite simply add such functionality... I > believe that DirectDraw exposes the scaling support of the video card. > Shoot, even the GDI blit function can accelerate scaling (if I recall > correctly). Anyone care to find a few docs on what XVideo drivers must > provide (so I don't have to do all of the searching myself)? And also xc/programs/Xserver/hw/xfree86/doc/DESIGN too. Alan.
Re: Xv/XVideo?
On Sun, Mar 16, 2003 at 05:32:54 -0500, Harold L Hunt II wrote: > Alexander Gottwald wrote: > >Thor Johnson wrote: > > > > > >>Greetings (and mucho thanks for the -norestart option for Xhost oddities)! > >> > >>I have a new boneheaded question: > >>What is the difference between xv (as used in mplayer, ogle, etc) and > >>XVideo? > > > > > >I don't know it for sure, but it's the same. XVideo is an interface to the > >XServer to allow a fast display of video. With XVideo you can for example > >get access to the backend scaler of the graphicscard and let the > >graphicscard > >scale the video to fullscreen. > > > >But this depends on the used graphicscard and for each graphicscard you > >need > >a special driver, which we don't have for Cygwin/XFree86. > > > > You know, we might be able to quite simply add such functionality... I > believe that DirectDraw exposes the scaling support of the video card. > Shoot, even the GDI blit function can accelerate scaling (if I recall > correctly). Anyone care to find a few docs on what XVideo drivers must > provide (so I don't have to do all of the searching myself)? xc/doc is your friend. Alan.
Re: GLX
On Fri, Mar 14, 2003 at 03:09:20 +, Ed Llewellin wrote: > Dear All, > > I have an application that sits on an SGI machine which I access via > xfree86 on cygwin. When I try and open the application, I get a message > telling me that "extension GLX" is missing. I have cygwin's OpenGL > installed but I am guessing that the GLX extension is not part of this > distribution. Is there a GLX extension for cygwin? If not, does anyone > know of an X-windows environment for Microsoft Windows which supports > GLX? Ed, If you run 'xdpyinfo' you'll see that cygwin does support the GLX extension. Please check that it does so on your machine too. Alan.
Re: Thanks for donations
On Wed, Feb 19, 2003 at 10:36:16 -0500, Christopher Faylor wrote: > On Wed, Feb 19, 2003 at 02:17:45PM +0000, Alan Hourihane wrote: > >On Wed, Feb 19, 2003 at 09:09:32 -0500, Harold L Hunt II wrote: > >> To anyone who has made a donation: thanks! > >> > >> I was able to get a new 120 GB 7200 RPM hard drive for my Linux computer > >> this weekend, which was a nice upgrade from my constantly full 20 GB > >> 5400 RPM drive. I have now setup a cross compiling environment again > >> since I finally have the room to do so. > >> > >> An interesting note about the drive: The drive is a $150 Maxtor 100 GB > >> with "20 GB free" for 120 GB total... plus I got a $50 mail-in rebate, > >> bringing the total price down to $100. Their actual 120 GB drive was > >> $150 (no rebate) but had an 8 MB cache instead of a 2 MB cache. I > >> figured that the cache would be nice, but it wasn't worth a 50% price > >> increase. > >> > >> Anywho, thanks again for the donations. > > > >Just a question Harold, have you offered any donations to Kensuke or > >to Alexander for their work ? > > Hasn't Harold suggested that people could contribute links for their own > donations? I don't think it makes sense for someone to be attempting to > dole out money. What would the criteria be? Better to let the users > decide. I understand your point, but who in the user community would know who to donate too if there are multiple paypal accounts. Unless you read CHANGELOG's the user community wouldn't know who to donate to. Alan.
Re: Thanks for donations
On Wed, Feb 19, 2003 at 09:09:32 -0500, Harold L Hunt II wrote: > To anyone who has made a donation: thanks! > > I was able to get a new 120 GB 7200 RPM hard drive for my Linux computer > this weekend, which was a nice upgrade from my constantly full 20 GB > 5400 RPM drive. I have now setup a cross compiling environment again > since I finally have the room to do so. > > An interesting note about the drive: The drive is a $150 Maxtor 100 GB > with "20 GB free" for 120 GB total... plus I got a $50 mail-in rebate, > bringing the total price down to $100. Their actual 120 GB drive was > $150 (no rebate) but had an 8 MB cache instead of a 2 MB cache. I > figured that the cache would be nice, but it wasn't worth a 50% price > increase. > > Anywho, thanks again for the donations. Just a question Harold, have you offered any donations to Kensuke or to Alexander for their work ? Alan.
Re: 4.3.0 status update
On Tue, Jan 14, 2003 at 01:42:46 -0500, Harold L Hunt II wrote: > Alan, > > No recent patches were lost. I am talking about patches that I > submitted after the 4.2.0 branch. After about two weeks you stopped > committing them to both trees, even though I noted that they should be > committed to both trees. I thought I remember you telling me at one > point that you didn't have a local 4.2.0 tree anymore... I could be > wrong, but I got the impression that I shouldn't waste more time with > 4.2.0 patches, so that's what I did. Well, it doesn't take me two seconds to get another 4.2.0 tree, if you really want stuff committing there. I have to draw the line at fixes to the 4.2.0 branch as purely fixes for bugs though. So if there's still something missing, let me know. > Are you telling me instead that you will be able to apply bug fixes to a > stable 4.3.0 tree for the life cycle of that version? That would be > nice indeed. Yes. But again, purely bug fixes - no features. Alan.
Re: 4.3.0 status update
On Tue, Jan 14, 2003 at 11:02:37 -0500, Harold L Hunt II wrote: > Right, but I am being very pragmatic here. In the past it has been > difficult to submit, and get Alan to commit, dual patches for both head > and a branch. After about a month, I think Alan deletes the branch, so > patches to it seem to go to lala land. So my point is pretty much: > January 17 for fewer headaches. :) All patches you've submitted for head or branch should be there. If they're not then ping me with the patch number. If there's a delay in committing, then it's nothing to do with deleting branches etc. It's to do with my time. Alan.
Re: 4.3.0 status update
On Tue, Jan 14, 2003 at 10:24:48 -0500, Harold L Hunt II wrote: > Once I make an official release of the multi-monitor patch I can submit > both the multi-window and multi-monitor patches. As long as they are completely isolated. I'll need to review them first. > There were also some cross-compiling build warnings that I had written > in about, but no one had commented on. I will see if I can dig them up > again. Please do. I don't currently have a cross compile environment, so patches rather than bug reports are even better. > Basically, we need to get things in before Jan 17, right? After that it > means that we will have two distinctly different versions in the > branches, right? That has always been a pain in the past. The XFree86 CVS will branch to become xf-4_3_0-branch and new work will continue on HEAD. Patches to 4.3.0 will be applied to the xf-4_3_0-branch. Strictly speaking - no new features are allowed at this point, only bug fixes. So the new multi-window/monitor stuff shouldn't be allowed. But I'll see what I can do when I see the patch. Alan.
Re: 4.3.0 status update
On Tue, Jan 14, 2003 at 04:13:49 +0100, Alexander Gottwald wrote: > On Tue, 14 Jan 2003, Alan Hourihane wrote: > > > This is what David Dawes wrote about the forthcoming 4.3.0 release. > > > > Harold, Alex, and others. Can you take the time to really test the > > current CVS and get patches in now. > > Will we include the pseudo relocation patches? I've not received a comment > to my last patch. No. I think it's too early for that patch anyway. I was hoping the pseudo reloc stuff would just work without any intervention, but alas it doesn't so I wouldn't want to make such intrusive changes at this stage. Alan.
4.3.0 status update
This is what David Dawes wrote about the forthcoming 4.3.0 release. Harold, Alex, and others. Can you take the time to really test the current CVS and get patches in now. Thanks. Alan. - Forwarded message from David Dawes <[EMAIL PROTECTED]> - Here's a quick status update regarding the 4.3.0 release. With one or two exceptions, most of the submissions that came in before the feature freeze have been integrated. The remaining ones should be done over the next week, and the next snapshot tagged (4.2.99.4). Also, the bug fixes submitted in the last few days should be reviewed and integrated soon. There have been some unavoidable delays related to a combination of unresolved bugs, the Holidays, and day job commitments that some of us have, so it's looks like the release date will slip by 2-3 weeks. The current tentative schedule is: Last submission date for non-critical fixes1 February 2003 End of integration of non-critical fixes 5 February 2003 Last submission date for documentation(*) 10 February 2003 Last submission date for release notes14 February 2003 4.3.0 tagged for release 15-16 February 2003 4.3.0 available from ftp.xfree86.org 17 February 2003 4.2.99.4 snapshot tagged 17-19 January 2003 4.2.99.901 (RC1) tagged25-26 January 2003 other release candidates tagged as-needed Note the usual disclaimers: This is a tentative schedule only, and may change without notice. It's as accurate as I can make it, but don't plan your life around it! Most of the XFree86 release work is handled by volunteers on their own time, and most of us have day jobs that have to take priority over spare-time work like this.
Re: DirectColor-visual?
On Mon, Jan 13, 2003 at 07:58:07PM -0500, Harold L Hunt II wrote: > Alan, > > So would it make any sense at all to try to support it on Windows? To > the best of my knowledge, you cannot read and write the 24 bit colors > that are available. If you can't get a read/write colormap from Windows, then apart from emulating it, it'd be pretty hard to support it. There are some applications that would use it though, if it were available. There are a few graphics cards that support this mode in the *nix versions of XFree86 though. Alan.
Re: DirectColor-visual?
On Mon, Jan 13, 2003 at 07:43:40PM -0500, Harold L Hunt II wrote: > Francisco, > > Do you know what a DirectColor visual is? > > Do you know why you would need a DirectColor visual? > > Do you know of any Windows-based graphics cards that actually support > DirectColor? > > > My understanding of DirectColor is that it allows you to specify the > range of colors that will be used in a mode that is similar to > TrueColor... however, I don't know of a single Windows graphics card > that allows you to do that. I don't know of any program that utilizes > such a visual either. As such, there is no support for DirectColor in > Cygwin/XFree86. I don't expect that there will ever be DirectColor > support in Cygwin/XFree86 unless someone can explain to me that I am way > wrong. > > DirectColor seems like a lot of things in X: it was thought to be REALLY > useful when X was designed, but it turned out to be anything but useful. > I read about those things once, then I ignore them after that. > > So, anyone else know what DirectColor is? DirectColor is a read/write colormap just like PseudoColor. TrueColor is a read only colormap just like StaticColor. Direct/True giving more colors than the other two though. Alan.
Re: Default OS Versions
On Thu, Jan 02, 2003 at 11:27:43PM -0500, Harold L Hunt II wrote: > Alan, > > I doubt that this was the intended effect of using the default OS versions: > == > make[1]: Entering directory `/home/harold/x-devel/build/std' > > Building on Cygwin > (DefaultOSMajorVersion.DefaultOSMinorVersion.DefaultOSTeenyVersion). > > GCC version: 2.95 > == > > Any ideas? It works here. Are you cross-compiling ? Alan.
Re: Buildpatch for cygdps.dll
Done.
On Mon, Dec 30, 2002 at 08:09:42 -0500, Harold L Hunt wrote:
> Alexander,
>
> Good catch!
>
> Alan - do you want to commit this directly?
>
> Harold
>
> Alexander Gottwald <[EMAIL PROTECTED]> said:
>
> > Hi,
> >
> > the patch fixes some dependency problems with crosscompiling libdps.
> > The Imakefile has a build dependency for ProgramTargetName(pswrap) which
> > is pswrap.exe for cygwin, but should be pswrap when crosscompiling. This
> > caused libdps to be recompiled whenever make or make install waas called
> > for libdps. The patch changes the ProgramTargetName to
> HostProgramTargetName.
> >
> > Index: Imakefile
> > ===
> > RCS file: /cvs/xc/lib/dps/Imakefile,v
> > retrieving revision 1.15
> > diff -u -r1.15 Imakefile
> > --- Imakefile 2002/06/06 01:40:21 1.15
> > +++ Imakefile 2002/12/30 23:16:57
> > @@ -201,7 +201,7 @@
> >
> > includes:: $(DPSOPSCFILES) $(PSOPSCFILES) $(HEADERS)
> >
> > -$(DPSOPSCFILES) $(PSOPSCFILES): ProgramTargetName($(PSWRAP))
> > +$(DPSOPSCFILES) $(PSOPSCFILES): HostProgramTargetName($(PSWRAP))
> >
> > SRCS = \
> > ${COMMONSOURCEFILES} \
> > @@ -224,13 +224,13 @@
> >
> > .SUFFIXES: .psw .h
> >
> > -.psw.c : ProgramTargetName($(PSWRAP))
> > +.psw.c : HostProgramTargetName($(PSWRAP))
> > RunProgram(PSWRAP,-a -o $*.c -h $*.h $<)
> >
> > -.psw.h : ProgramTargetName($(PSWRAP))
> > +.psw.h : HostProgramTargetName($(PSWRAP))
> > RunProgram(PSWRAP,-a -h $*.h $< > /dev/null)
> >
> > -ProgramTargetName($(PSWRAP)):
> > +HostProgramTargetName($(PSWRAP)):
> > @echo "checking $@ over in $(PSWRAPSRC) first..."; \
> > cd $(PSWRAPSRC) && $(MAKE); \
> > echo "okay, continuing in $(CURRENT_DIR)"
> >
> > NP: VNV Nation - Saviour
> > --
> > [EMAIL PROTECTED]
> > http://www.gotti.org ICQ: 126018723
> >
> >
>
>
Re: new runtime pseudo-reloc in cygwin 1.3.18
On Sat, Dec 28, 2002 at 11:26:35PM +0100, Alexander Gottwald wrote: > Alexander Gottwald wrote: > > > Alan Hourihane wrote: > > > > > > But some programs (xedit, viewres, xmessage) report an runtime error > > > > Error: Unresolved inheritance operation > > > > > > I can confirm I get this too Alexander. > > > > I'll do a build without the pseudo-relocation changes and see if it happens > > there too. I hope the error resulted from an incomplete installation (in fact > > I only started the binaries from the export dir and did no install at all) > Without the reloc patch everything is fine. The problem is _XtInherit. I'm > now trying to build all libraries with the SUNSHLIB macro. maybe this works. > At least xclock started after i replaced cygXt-6.dll with a version where > SUNSHLIB was defined. Great work, let me have an extra patch when your ready Alexander. Alan.
Re: new runtime pseudo-reloc in cygwin 1.3.18
On Fri, Dec 27, 2002 at 09:49:15PM +0100, Alexander Gottwald wrote: > But some programs (xedit, viewres, xmessage) report an runtime error > Error: Unresolved inheritance operation I can confirm I get this too Alexander. Alan.
Re: new runtime pseudo-reloc in cygwin 1.3.18
On Fri, Dec 27, 2002 at 10:23:22PM -0500, Christopher Faylor wrote: > On Sat, Dec 28, 2002 at 01:40:50AM +0000, Alan Hourihane wrote: > >On Fri, Dec 27, 2002 at 09:49:15 +0100, Alexander Gottwald wrote: > >> But some programs (xedit, viewres, xmessage) report an runtime error > >> Error: Unresolved inheritance operation > > > >, just tried the binaries on my w2k box and it gives... > > > >"The application failed to initialize properly (0xc022)" > > Make sure that the binaries and dlls have chmod a+x permissions. +x was missing. Thanks for the heads up Chris. Seems we'll need to tweak the build process to chmod them. Alan.
Re: new runtime pseudo-reloc in cygwin 1.3.18
On Fri, Dec 27, 2002 at 09:49:15 +0100, Alexander Gottwald wrote: > But some programs (xedit, viewres, xmessage) report an runtime error > Error: Unresolved inheritance operation , just tried the binaries on my w2k box and it gives... "The application failed to initialize properly (0xc022)" Alan.
new runtime pseudo-reloc in cygwin 1.3.18
I'm about to commit a patch to the XFree86 CVS that uses the new relocation code in cygwin 1.3.18. This allows us to create the last few libraries as shared code. Here's the patch if people would like to test first. I've build tested the entire tree without problems, but not tested cross compiling. Alan. Index: config/cf/cygwin.cf === RCS file: /X11R6/x-cvs/xc/config/cf/cygwin.cf,v retrieving revision 3.48 diff -u -r3.48 cygwin.cf --- config/cf/cygwin.cf 28 Nov 2002 16:50:58 - 3.48 +++ config/cf/cygwin.cf 27 Dec 2002 01:06:21 - @@ -32,7 +32,7 @@ #define UseGas YES #define GnuCpp YES -#define ExtraLoadFlags -Wl,--enable-auto-import +#define ExtraLoadFlags -Wl,--enable-auto-import +-Wl,--enable-runtime-pseudo-reloc #define HasShadowPasswd NO #define HasLibCrypt YES Index: config/cf/cygwin.rules === RCS file: /X11R6/x-cvs/xc/config/cf/cygwin.rules,v retrieving revision 3.22 diff -u -r3.22 cygwin.rules --- config/cf/cygwin.rules 17 Oct 2002 08:18:17 - 3.22 +++ config/cf/cygwin.rules 27 Dec 2002 01:06:21 - @@ -7,11 +7,11 @@ #define HasSharedLibraries YES #define NeedLibInsideFlag NO #define ForceNormalLib NO -#define SharedLibXaw NO /* For these we need new binutils */ -#define SharedLibXmu NO -#define SharedLibXtNO -#define SharedLibFont NO -#define SharedLibXaw6 NO +#define SharedLibXaw YES +#define SharedLibXmu YES +#define SharedLibXtYES +#define SharedLibFont YES +#define SharedLibXaw6 YES #define SharedLibSMYES #define SharedLibICE YES #define SharedLibXext YES @@ -183,7 +183,7 @@ */ #define MakeDLLProg(libname,solist,prog,rev) @@\ - prog -shared -Wl,--out-implib=ImportLibraryName(libname,rev) -Wl,--enable-auto-import --def libname.def -Wl,--exclude-libs,ALL -o SharedLibraryName(libname,rev) solist $(REQUIREDLIBS) + prog -shared -Wl,--out-implib=ImportLibraryName(libname,rev) +-Wl,--enable-auto-import -Wl,--enable-runtime-pseudo-reloc --def libname.def +-Wl,--exclude-libs,ALL -o SharedLibraryName(libname,rev) solist $(REQUIREDLIBS) /* * MakeDll Index: lib/Xaw/Xaw-def.cpp === RCS file: /X11R6/x-cvs/xc/lib/Xaw/Xaw-def.cpp,v retrieving revision 1.2 diff -u -r1.2 Xaw-def.cpp --- lib/Xaw/Xaw-def.cpp 31 May 2002 18:45:44 - 1.2 +++ lib/Xaw/Xaw-def.cpp 27 Dec 2002 11:20:02 - @@ -133,7 +133,7 @@ XawViewportSetLocation XawWidgetArray XawWidgetCount -#ifdef __UNIXOS2__ /* xconsole */ +#if defined(__CYGWIN__) || defined(__UNIXOS2__) /* xconsole, xedit */ _XawTextGetSTRING XawTextSourceAddEntity XawTextSourceAnchorAndEntity
Re: man pages
Yup. On Thu, Nov 28, 2002 at 11:10:46AM -0500, Harold L Hunt II wrote: > Alan, > > Are you going to commit this one directly? > > Harold > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Alan Hourihane > Sent: Wednesday, November 27, 2002 12:09 PM > To: [EMAIL PROTECTED] > Subject: Re: man pages > > > It's broken. > > We need to rebuild the X tree with > > #define ExpandManNamesYES > > in cygwin.cf > > Thanks for reporting this. > > Alan. > > On Wed, Nov 27, 2002 at 04:53:23PM -, Kris Thielemans wrote: > > Hi, > > > > why are the man page names abbreviated? > > e.g. instead of typeing 'man XCreateWindow', I have to do 'man XCreWin' > > Or is there something wrong in my installation? > > > > thanks! > > > > Kris Thielemans > > (kris.thielemans ic.ac.uk) > > Imaging Research Solutions Ltd > > Cyclotron Building > > Hammersmith Hospital > > Du Cane Road > > London W12 ONN, United Kingdom > >
Re: man pages
It's broken. We need to rebuild the X tree with #define ExpandManNames YES in cygwin.cf Thanks for reporting this. Alan. On Wed, Nov 27, 2002 at 04:53:23PM -, Kris Thielemans wrote: > Hi, > > why are the man page names abbreviated? > e.g. instead of typeing 'man XCreateWindow', I have to do 'man XCreWin' > Or is there something wrong in my installation? > > thanks! > > Kris Thielemans > (kris.thielemans ic.ac.uk) > Imaging Research Solutions Ltd > Cyclotron Building > Hammersmith Hospital > Du Cane Road > London W12 ONN, United Kingdom >
Re: XFree86-f100-4.2.0-1.tar.bz2 still exists..
On Tue, Oct 15, 2002 at 11:51:16PM +0100, Alan Hourihane wrote: > On Tue, Oct 15, 2002 at 11:49:31PM +0100, Alan Hourihane wrote: > > Is there any reason why the above file still exists when > > there is a -2.tar.bz2 version now ? > > In fact there's others too in the font directories... Ignore this, I realise it's for those who wish to drop back a version with cygwin's setup.exe tool. Alan.
Re: XFree86-f100-4.2.0-1.tar.bz2 still exists..
On Tue, Oct 15, 2002 at 11:49:31PM +0100, Alan Hourihane wrote: > Is there any reason why the above file still exists when > there is a -2.tar.bz2 version now ? In fact there's others too in the font directories... Alan.
XFree86-f100-4.2.0-1.tar.bz2 still exists..
Is there any reason why the above file still exists when there is a -2.tar.bz2 version now ? Alan.
Re: XFree 4.2.1 + fontconfig-2
On Wed, Oct 02, 2002 at 11:01:37AM -0400, Harold L Hunt II wrote: > Alan, > > Everytime I a build check I do something like the following: > > cd ../ [from foo/xc] > cd build > mkdir std > cd std > lndir ../../xc > /dev/null > make CROSSCOMPILEDIR="/cygwin/bin" World > World.log 2>&1 > > > Thus, I know for sure that any built file is being rebuilt :) > > Next idea? None. Like I said, I don't have a cross compile environment and it works fine natively. Alexander - any ideas ? Alan.
Re: XFree 4.2.1 + fontconfig-2
On Wed, Oct 02, 2002 at 12:39:04PM +0200, Alexander Gottwald wrote: > On Tue, 1 Oct 2002, Alan Hourihane wrote: > > > > > Yes, then they are probably needed, so just check for me and I'll make > > the change. > > I've done a test run this morning. Without the ComplexProgramTarget_1 in > cygwin.rules it fails in programs/bitmap with "No rule for target bitmap found" > since the makefile looks like this. > PROGRAMS=bitmap ... > all: $(PROGRAMS) > bitmap.exe: ... > > With ComplexProgramTarget it builds succesfully. The Makefile is similar to this: > PROGRAMS=bitmap > all: $(foreach prog,$(PROGRAMS),prog.exe) > bitmap.exe: ... Then I'll put the #if CrossCompile in for this rule only. Thanks Alexander. Alan.
Re: XFree 4.2.1 + fontconfig-2
On Tue, Oct 01, 2002 at 08:45:00PM -0400, Harold Hunt wrote:
> Alan,
>
> Something is definitely borken:
>
> make[4]: Nothing to be done for `Makefiles'.
> make[4]: Leaving directory `/home/harold/x-devel/build/cross/doc/man/GLU'
> make[3]: Leaving directory `/home/harold/x-devel/build/cross/doc/man'
> make[2]: Leaving directory `/home/harold/x-devel/build/cross/doc'
> make[1]: Leaving directory `/home/harold/x-devel/build/cross'
> make -f xmakefile BOOTSTRAPSUBDIRS= clean
> make[1]: Entering directory `/home/harold/x-devel/build/cross'
> RemoveFile(Concat3(lib,libname,-rev.dll.a))
> /bin/sh: -c: line 1: syntax error near unexpected token
> `RemoveFile(Concat3('
> /bin/sh: -c: line 1: `RemoveFile(Concat3(lib,libname,-rev.dll.a))'
> make[1]: *** [cleandir] Error 2
> make[1]: Leaving directory `/home/harold/x-devel/build/cross'
> make: *** [World] Error 2
>
>
> What do you make of that?
Well, RemoveFile should have been expanded in the 'xmakefile' - regardless
of the Concat3() stuff.
Check your xmakefile and do 'touch Imakefile;make Makefile'.
See if that still isn't expanding, if it isn't I'll leave for Alexander
to explain as I don't have a cross compilation environment setup.
It certainly doesn't happen natively.
Alan.
Re: XFree 4.2.1 + fontconfig-2
On Tue, Oct 01, 2002 at 04:52:29PM +0200, Alexander Gottwald wrote: > On Tue, 1 Oct 2002, Alan Hourihane wrote: > > > > Can someone test a Cross Compile environment. I needed to comment > > out the ComplexProgramTarget_1 rule which isn't needed when building > > on Cygwin in my tests, but may well be needed for cross compiles. If > > so I can stick in the #if CrossCompile/#endif stuff. > > Are these recent changes? All testing I've done was only in a crosscompile > environment. Yes, then they are probably needed, so just check for me and I'll make the change. > > We're also awaiting the new cygwin dll and relevant binutils packages > > before we can turn on shared libraries for Xaw/Xt as they export > > arrays which the auto-import can't currently deal with. > > And the new binutils will help? I've run into this problem too. Yes, aparently so. Check out the cygwin archive lists for more details. Alan.
Re: XFree 4.2.1 + fontconfig-2
On Sat, Sep 28, 2002 at 05:19:53PM +0200, Alexander Gottwald wrote: > Alan Hourihane wrote: > > > When you've come to a decision on the patch, post a new one so I > > can take a look and then commit it. > > There's a new one. > > The cygwin.rules diff includes: > > - new macro SharedLibraryName > evalutes to cygName-Version.dll > - new macro ImportLibraryName > evaluates to libName-Version.dll.a > - new macro ShortImportLibraryName > evaluates to libName.dll.a > - new macro InstallLink > creates a symlink on install. Needed for symlinking ImportLibraryName() > to ShortImportLibraryName() > - new macro LinkImportLibrary > creates a link to ImportLibraryName as xc/exports/lib/libName.a > - cleaup of of old macros to use the ShareLibraryName and ImportLibraryName > macros instead of the old Concat3() composition > - added new ld option --exclude-libs All in MakeDLLProg. This should prevent > exporting of symbols which were imported from another library. > - Some macros now also need the library version to pass it to the new *Name > macros. Added rev to parameterlists. > - Installing a link libName-Version.dll.a with name libName.dll.a > > The --exclude-libs ALL is needed at my system since Xft exported symbols > from Xrender. linking a program with -Xrender -lXft failed because of > duplicate symbols. Since we're using spec files to specify which symbols > have to be exported, --exclude-libs ALL should be no problem. > > The second path changes the order of the libraries. It is now -lXrender > -lXext -lX11. This fixes an error where some symbols from libX11 were not > found when the linker resolved symbols from libXrender. I've done a test build with this and my other patches and it seems to work well in my "limited" testing. I've now committed the changes, so if others can also test as well, that'd be good. Can someone test a Cross Compile environment. I needed to comment out the ComplexProgramTarget_1 rule which isn't needed when building on Cygwin in my tests, but may well be needed for cross compiles. If so I can stick in the #if CrossCompile/#endif stuff. Thanks for the patch Alexander. We're also awaiting the new cygwin dll and relevant binutils packages before we can turn on shared libraries for Xaw/Xt as they export arrays which the auto-import can't currently deal with. There are workarounds for this, but I'm loathe to implement those kinds of fixes. Alan.
Re: XFree 4.2.1 + fontconfig-2
On Fri, Sep 27, 2002 at 07:40:44 +0200, Alexander Gottwald wrote: > Alexander Gottwald wrote: > > > #if Concat(SharedLib,libname) > > #define LibraryTargetName(libname) Concat3(lib,libname,.dll.a) > > #else > > #define LibraryTargetName(libname) Concat3(lib,libname,l.a) > > #endif > > > > But I don't know if this is either valid for imake or if it will > > break anything. And when you do a shared and a static version, the > > static version will most likely be name libName.dll.a too. > > I just checked and the above violates the cpp syntax. You can not have a > macro with a conditional which depends on a parameter. > > |#define MACRO(x) > |#if x > |#define RESULT YES > |#else > |#define RESULT NO > |#endif > > does not work. The preprocessor can not decide which one will be used later. > Those preprocessor macros are not functions. > > What does this mean for us? Imagine you have libX11 as shared library and > eg. libXt as static library (current configuration). > > a dependency like this > | program: LibraryTargetName(X11) LibraryTargetName(Xt) > which we want to resolve to > | program: libX11.dll.a libXt.a > is not possible. We'd have to build something like this > | #if SharedLibraryX11 > | #define X11lib SharedLibraryTargetName(X11) > | #else > | #define X11lib LibraryTargetName(X11) > | #endif > | ... > | program: $(X11lib) $(Xtlib) > and this must be done for all the code. > > My conclusion: We should stay with libName.a even for import libraries. > Changing it and don't being able to build a simple macro which wraps it > properly will sooner ar later cause compile problems. > > comments? Yes, The following will work Instead of program: $(X11lib) $(Xtlib) Do this DONE: $(X11lib) $(Xtlib) and at the end of the SharedLibraryTarget() stuff and other same functions do this > DONE Which will touch a file called DONE and that's the dependency. Alan.
Re: XFree 4.2.1 + fontconfig-2
On Wed, Sep 25, 2002 at 03:39:50PM +0200, Alexander Gottwald wrote: > On Wed, 25 Sep 2002, Nicholas Wourms wrote: > > > > But I don't know if this is either valid for imake or if it will > > > break anything. And when you do a shared and a static version, the > > > static version will most likely be name libName.dll.a too. > > > > Well that doesn't make any sense because on linux it builds shared > > libraries with "so" and static libs with ".a". > > The original LibraryTargetName from imake.rules could be overwritten > in cygwin.rules. So all these changes apply to cygwin only. > > > Also, the way it > > builds it makes it possible in my mind. I make puts shared objects > > in $BUILDDIR/ and static into $BUILDDIR/unshared/. It shouldn't be > > too hard to insert the logic necessary to handle archiving the > > contents properly. > > building libraries and programs which depend on another library have > a "progFoo: xc/exports/lib/libFoo.a" as rule. Replacing LibraryTarget- > Name with the Shared/Static switch from my posting will replace this > either by > progFoo: xc/exports/lib/libFoo.a > or > progFoo: xc/exports/lib/libFoo.dll.a > depending on SharedLibraryFoo set to NO or YES > > Hm, actually this is correct and what we want. > > > Also, ld can automatically generate shared import > > libraries during linking of the dll, so that might be a possible > > route to look at. > > This is already done cygwin.rules > > > > This was not the system install but only the global install in the > > > build > > > tree. > > > > > > > I'm sorry, but I don't understand what you mean here... > > running make on the xc tree will _symlink_ (and partly copy) the targets > to xc/export/lib and xc/export/bin. Make install later will _copy_ it > to the installdir. When you've come to a decision on the patch, post a new one so I can take a look and then commit it. Alan.
Re: XFree 4.2.1 + fontconfig-2
On Tue, Sep 24, 2002 at 03:06:51PM -0700, Nicholas Wourms wrote: > > --- Alan Hourihane <[EMAIL PROTECTED]> wrote: > > On Tue, Sep 24, 2002 at 10:56:54PM +0200, Alexander Gottwald wrote: > > > Nicholas Wourms wrote: > > > > > > > final outcome: > > > > -- > > > > /usr/X11R6/bin/cygXfoo.0.0.dll > > > > /usr/X11R6/lib/libXfoo.0.0.dll.a > > > > /usr/X11R6/lib/libXfoo.0.dll.a > > > > /usr/X11R6/lib/libXfoo.dll.a > > > > /usr/X11R6/lib/libXfoo.a > > > > > > Attached a patch which tweaks the makefile to build > > > > > > lib$(NAME)-$(MAJOR).dll > > > lib$(NAME)-$(MAJOR).a > > > lib$(NAME).a -> lib$(NAME)-$(MAJOR).a > > > > > > for Xft1 and Xft2 its > > > exports/bin/libXft-1.dll > > > exports/bin/libXft-2.dll > > > exports/lib/libXft-1.a -> ../../lib/Xft1/libXft-1.a > > > exports/lib/libXft-2.a -> ../../lib/Xft/libXft-2.a > > > exports/lib/libXft.a -> libXft-2.a > > > > Nice job! > > > > For the libXft-1.dll we'll need a hack somewhere to make that > > libXft.dll for backwards compatibility. > > Well if I might comment on this and take a stance similar to Chuck's > line of reasoning (we were discussing this the other day). First > off, it "Would Be Nice (tm)" to use the prefix that the core > distribution uses "cyg". Alexander says making that happen is > trivial, so why not go with the standard? Secondly, Cygwin's shared > import libraries end in "dll.a" not ".a" [which is the suffix > reserved for static import libraries]. I really think we ought to > differentiate on this. What if I wanted to distribute a shared and > static version of my library? As you know, ld automatically > recognizes dll.a suffix and will use that as the shared import > library. I'm not trying to harp, but this was causing me trouble > earlier this year. There are times when it is handy to link in a > static manner, allowing you to ship as few seperate files as > necessary. Also, I don't understand the need for keeping import > libraries in subdirs. If my original idea doesn't suite you, why not > this (if possible): > > shared: > --- > exports/bin/cygXft-1.dll > exports/bin/cygXft-2.dll > exports/lib/libXft-1.dll.a > exports/lib/libXft-2.dll.a > exports/lib/libXft-2.dll.a -> libXft.dll.a > > static: > --- > exports/lib/libXft-1.a > exports/lib/libXft-2.a > exports/lib/libXft.a -> libXft-2.a > > I'll have a look at Alexander's work to see if I can get it to do > this. Again, I appreciate the hard work both of you put into it. > Call me crazy, but after some previous threads on the main list, I > know how important it is to keep a common naming schema. These changes look reasonable Nicholas. Alexander - can you adjust your patch for this ? Alan.
Re: XFree 4.2.1 + fontconfig-2
On Tue, Sep 24, 2002 at 11:24:43PM +0200, Alexander Gottwald wrote: > Alan Hourihane wrote: > > > Nice job! > > > > For the libXft-1.dll we'll need a hack somewhere to make that > > libXft.dll for backwards compatibility. > > in cygwin.cf is BuildXft1Library still set to no and the for Xft2 is > still build befor Xft1, so Xft.a links to Xft-1.a after make in lib O.k. I'm doing a build later with all your patches you've submitted to the XFree86 patch list and once I've test built I'll commit everything. Thanks again. Alan.
Re: XFree 4.2.1 + fontconfig-2
On Tue, Sep 24, 2002 at 10:56:54PM +0200, Alexander Gottwald wrote: > Nicholas Wourms wrote: > > > final outcome: > > -- > > /usr/X11R6/bin/cygXfoo.0.0.dll > > /usr/X11R6/lib/libXfoo.0.0.dll.a > > /usr/X11R6/lib/libXfoo.0.dll.a > > /usr/X11R6/lib/libXfoo.dll.a > > /usr/X11R6/lib/libXfoo.a > > Attached a patch which tweaks the makefile to build > > lib$(NAME)-$(MAJOR).dll > lib$(NAME)-$(MAJOR).a > lib$(NAME).a -> lib$(NAME)-$(MAJOR).a > > for Xft1 and Xft2 its > exports/bin/libXft-1.dll > exports/bin/libXft-2.dll > exports/lib/libXft-1.a -> ../../lib/Xft1/libXft-1.a > exports/lib/libXft-2.a -> ../../lib/Xft/libXft-2.a > exports/lib/libXft.a -> libXft-2.a Nice job! For the libXft-1.dll we'll need a hack somewhere to make that libXft.dll for backwards compatibility. Alan.
Re: XFree 4.2.1 + fontconfig-2
On Tue, Sep 24, 2002 at 09:32:27 +0200, Alexander Gottwald wrote: > On Mon, 23 Sep 2002, Nicholas Wourms wrote: > > > How about a seperate package call X11-compat for this? Just seems > > like a waste of space for people who don't care. > > Good idea > > > library name used on *nix: libXfoo.0.0.so > > actually libXfoo.so.0.0, everything else will also break the library > versioning. > > > *for Cygwin: > > > > > > runtime name: > > - > > > > "cyg" + + "." + + "." + + "." + "dll" > > [i.e. cygXfoo.0.0.dll] > > Any minor version bump will break older clients. They will request > cygXfoo.0.0.dll but cygXfoo.0.1.dll is installed and is sufficient. > > if we name it only cygXfoo.0.dll, can the cygwin installer make sure > that at least package foo-x.y-1 is installed and not only foo-x.y-0 > for all packages requiring the new version? I think in this instance that windows doesn't help us much. I think it should be fine if we had say libXfoo.0.dll installed (which was really v0.0), but then we released Xfoo-0.1.tar.gz which installed another libXfoo.0.dll (which is now v0.1). I.E We only ever report the major version number and forget about the minor one, as in the case of the minor number we are always backwards compatible. Alan.
Re: XFree 4.2.1 + fontconfig-2
On Mon, Sep 23, 2002 at 03:03:54 -0700, Nicholas Wourms wrote: > > --- Alan Hourihane <[EMAIL PROTECTED]> wrote: > > On Wed, Sep 18, 2002 at 10:25:48 +0200, Alexander Gottwald wrote: > > > That is a windows problem. The XFree libraries are in fact > > versioned. > > > (libXaw.so.6.1 vs libXaw.so.7.0) > > > Alexander, > > > > You've hit a sore spot here. The issue of Xft1 vs Xft2 was only the > > starting of a larger picture. > > > > Your right in the fact that all libraries are versioned, and we > > don't > > respect that for any library. libX11.a should really be > > libX11-6_2.a etc > > or some equivalent of. > > > > We also need to consider backwards compatibility as to not break > > older > > applications. > > > > I've fixed the immediate problem and can re-instate Xft1. But any > > want to pipe up with anything on this topic ? > > Like it or not, if we make the switch we will break binary > compatibility. This is, of course, because runtime libraries cannot > be symlinked on Windows. Still, this is something that will have to > be done sooner or later (again perhaps for the 4.3.0 release?). > However, I think the benefits in the longrun will outweigh the > incovience of a few questions from people caught in this switch. > I'll let Harold voice his mind on this now... We don't have to symlink - we can copy libX11-6_2.dll to libX11.dll etc to maintain compatibility and bug fixes to these kinds of libraries. A small script here will do the trick. But I think we really need to do this for 4.3.0 and just update the FAQ for those caught in the switch - like you say. Alan.
Re: XFree 4.2.1 + fontconfig-2
On Wed, Sep 18, 2002 at 10:25:48 +0200, Alexander Gottwald wrote: > That is a windows problem. The XFree libraries are in fact versioned. > (libXaw.so.6.1 vs libXaw.so.7.0) Alexander, You've hit a sore spot here. The issue of Xft1 vs Xft2 was only the starting of a larger picture. Your right in the fact that all libraries are versioned, and we don't respect that for any library. libX11.a should really be libX11-6_2.a etc or some equivalent of. We also need to consider backwards compatibility as to not break older applications. I've fixed the immediate problem and can re-instate Xft1. But any want to pipe up with anything on this topic ? Alan.
Re: XFree 4.2.1 + fontconfig-2
On Thu, Sep 19, 2002 at 09:40:06AM -0700, Nicholas Wourms wrote: > > For this issue, I would revisit it, if someone claimed that there > > are applications for Cygwin/XFree86 that relied on Xft1. I suspect > > for the number of applications that will become available for > > Cygwin/XFree86 they'll now be using Xft2 anyway. But please speakup > > if this is a problem, I will take another look at fixing it. > > Well this isn't a problem for me. Since you probably have a close > working relationship with Keith, I assume you are more clued-in than > me. I made a hasty assumption and my thinking Xft2 was not source > compatible with Xft1 apps, so it may not be true. Can you confirm > this? I should be releasing QT2 shortly, which uses Xft, but I > haven't investigated if it compiles against Xft2 headers/libraries. > I think some of the gtk-1 stuff uses Xft1, and someone is working on > this. Just to be safe, I'm CC:'ing Steve O. who is working on the > Gnome port. > > I still think, though, that it would be worth the effort to bring > Xfree's runtime libraries into sync with the "generally accepted" > Cygwin standard: > > "cyg" + + "ABI Revision" + ".dll" (i.e. > cygpopt0.dll) > > I'm sure this would not only fix the issues now, but might prevent > further headaches in the future. However, I know the hell that is > Imake, so I'm not going to make a big fuss over this now. Perhaps a > suggestion for Cygwin/XFree-4.3.0? The above is most certainly the right thing to do. Maybe someone can poke at the Imakefiles and send me a patch. > While I have you here, I have a question which Harold said he didn't > know. Why was libXaw built as a static library [it's usually shared > on linux]? I'm running into some runtime issues with my libXaw3d > package [I built it as dll] and I suspect the answer lies in the > reasoning behind that question. I was also wondering how you > generated the foo-def.cpp? Is there a script that does this or do > you just have to go through the entire source? Maybe I'm missing > something because I've been spoiled by libtool/ld autogenerating the > exports... It's more likely a historical thing. Just flip the flag to YES and rebuild. Alexander had a script to generate the foo-def.cpp files. Actually, there's a few other libraries in cygwin.rules that could be flipped to YES too. Anyone want to take stab at it, rebuild and send in a patch. Alan.
Re: XFree 4.2.1 + fontconfig-2
On Wed, Sep 18, 2002 at 11:25:11 -0400, Harold Hunt wrote: > Nicholas, > > I wasn't even aware of XFree86 4.2.1 until you mentioned it. > > I am not sure if I will build a release of it or not... seems like a lot of > trouble for just a few fixes, with non of them Cygwin-specific. 4.2.1 has an important security fix - arguably whether it matters for cygwin based installations though. > As for building versioned DLLs --- I have no idea. I am not knowledgeable > enough about that topic to be able to give you an answer, or even to be able > to discuss it. > > In regards to Xft1 and XFt2, Alan Hourihane and I noticed a problem with > both of them being built and one DLL (version 1) wiping out the other DLL > (version 2), so we said to hell with it and stopped building Xft1 and went > full-on with Xft2. As to whether or not that was a good decision, I can > only say that Alan thought it was okay, so it is okay with me :) For this issue, I would revisit it, if someone claimed that there are applications for Cygwin/XFree86 that relied on Xft1. I suspect for the number of applications that will become available for Cygwin/XFree86 they'll now be using Xft2 anyway. But please speak up if this is a problem, I will take another look at fixing it. > So, in summary, there is not likely to be a release effort applied to > getting 4.2.1 out the door... unless I suddenly come up on a great amount of > time. Also, Alan shipped me the standard X packages last time, which I fed > through the Cygwin packaging script, so if he does that this time I'll > likely make a 4.2.1 release. There's no bandwidth from me at the moment to cover this, I'm swamped underneath lots and lots of work. Alan.
Re: FW: xc/lib/fontconfig/fonts.conf depends on existing fonts installation
O.k. If the problem still exists, contact Keith Packard directly. It's more than likely he missed the post too. But this code is his domain and he's been banging on it a lot lately. I'm sure Keith will respond. Alan. On Fri, Jul 05, 2002 at 10:39:24AM -0400, Harold Hunt wrote: > Alan, > > Hmm... as usual I misspoke... I was bitching about the ``findfonts'' script > which runs on the installed fonts rather than on fonts being built. > > I'll have to look into the font build utility problem. > > I hate it when I get confused. Anyway, here is what I wrote to the XFree86 > devel list. > > Harold > > > -Original Message- > From: Harold Hunt > Sent: Saturday, April 13, 2002 7:44 PM > To: xf-devel > Subject: xc/lib/fontconfig/fonts.conf depends on existing fonts > installation > > > I don't understand why xc/lib/fontconfig/fonts.conf runs the script > xc/lib/fontconfig/findfonts which looks at the *currently installed fonts*. > That doesn't make any sense to me. Shouldn't you be able to build XFree86 > on a machine that doesn't have any fonts installed, or for that matter, any > piece of XFree86 installed? > > The problem that I'm running into on Cygwin is that even if > /usr/X11R6/lib/X11/fonts exits but /usr/share/fonts doesn't exist then the > findfonts script fails because 'find' cannot find that directory. I'm not > certain that this is a Cygwin only problem, but it is the only platform that > I am building on. > > I propose that one of two things be done: > > 1) Do not execute the scripts that do things for *installed* fonts, as this > makes no sense. > > 2) Or, change the findfonts script to silently fail if either of the fonts > directories cannot be found, thus removing a non-error error from build > logs. > > > Please CC me, as I am not currently subscribed to the devel list. > > A snippet of my build log follows. > > > Harold Hunt > > > > > make[1]: Leaving directory > `/home/Administrator/x-devel/build/std/lib/fontconfig > /fc-list' > rm -f fonts.conf > sh ./setfontdirs > find: /usr/share/fonts: No such file or directory > ed: not found > make: *** [fonts.conf] Error 127
Re: Use Tcp.h?
On Fri, Jul 05, 2002 at 03:30:37PM +0100, Alan Hourihane wrote: > On Fri, Jul 05, 2002 at 10:22:00AM -0400, Harold Hunt wrote: > > Oh, I know that the XFree86 folks are doing some stupid things with respect > > to expecting certain XFree86 utilities to already be installed at build > > time. I bitched about this to the devel list at XFree86 and you know what? > > I didn't get a single reply. Not even a ``go away, you are annoying''. > > Apparently no one else on the project things that you should be able to > > bootstrap on a machine that has never had XFree86 installed. Hopefully they > > fix this before the next release. > > Then I missed that. Can you repeat the question here Harold ? Oh, if it's regarding fc-cache, I mentioned it to Keith a while ago, and I believe he's fixed it since. Alan.
Re: Use Tcp.h?
On Fri, Jul 05, 2002 at 10:22:00AM -0400, Harold Hunt wrote: > Oh, I know that the XFree86 folks are doing some stupid things with respect > to expecting certain XFree86 utilities to already be installed at build > time. I bitched about this to the devel list at XFree86 and you know what? > I didn't get a single reply. Not even a ``go away, you are annoying''. > Apparently no one else on the project things that you should be able to > bootstrap on a machine that has never had XFree86 installed. Hopefully they > fix this before the next release. Then I missed that. Can you repeat the question here Harold ? Alan.
Re: test 60 did not fix the kde 3.0 icon problem for me
On Sat, Jun 22, 2002 at 06:37:26 -0400, Harold Hunt wrote: > 1) Do a clean before rebuilding the server to ensure that the RENDER > extension is compiled in and enabled. The RENDER extension is now > reenabled. Unfortunately, the RENDER extension is the cause of the > display problem with KDE 3.0 icons that have alpha channels at a depth > of 32 bits per pixel. It was previously thought that the LAYER and > RANDR extensions were causing the problem because a rebuild of the > server with RENDER enabled did not actually have RENDER enabled, thus > making it seem that RENDER was not causing the problem. (Harold > Hunt) Harold, When this happens, can you tell me what dwBPP and dwDepth are set to ? Alan.
Re: Header X11/Xw32defs.h missing
On Tue, Jun 18, 2002 at 08:21:41AM -0400, Harold Hunt wrote: > > I now see the XFree86 stuff probably was not designed to be using > > WIN32 this > > way. So, perhaps as far as XFree86 is concerned it *is* > > spurious. (But the > > branch on WIN32 *is* in Xos.h.) > > > > BTW *is* it possible to build an X client using the XFree86 and LessTif > > libraries with Visual C++? It's probably possible, but you'd need to undef some things like WIN32, and possibly others. > > I have been doing this using the Hummingbird Exceed X and Motif libraries, > > but I would like to consider changing to XFree86 and LessTif. (Open Motif > > would be even better, but it isn't "open" for Windows.) The same programs > > build with Open Motif or LessTif on Linux. It would be a lot > > easier to use > > stuff that more resembles UNIX as XFree86 does. And it would be nicer to > > use the "same" stuff on all platforms. > > > > An alternative is to use the Cygwin compiler (gcc). This been more > > successful. Then, WIN32 is not defined, but there are some other > > problems. That would be the best approach, but what other problems are you seeing ? Alan.
Re: Workaround, for now
On Fri, Jun 14, 2002 at 09:10:30 -0400, Harold Hunt wrote: > I've found a workaround, for now. > > It turns out that the RENDER extension is working find on Cygwin/XFree86, > but the LAYER and/or RANDR extensions are causing problems when displaying > icons with alpha channels. For now the solution is to just disable LAYER > and RANDR, since we don't even know what they do (lack of documentation from > the creator). LAYER and RANDR are not complete. They both form the basis for Rotate and Resizing. This will allow colour depth switching and rotating of the display. So don't worry about them. Alan.
Re: How to start messing around with creating a rootless mode...
On Thu, Jun 13, 2002 at 10:57:44PM +1000, Robert Collins wrote: > Yes, but the X infrastructure for this is excellent. I had it mostly > working, but looking crap due to the decorations, and not choosing which > windows to show on the taskbar terribly cluefully. Alan has various > patches from me. Unfortunately, my personal time completely dried up > without much warning a couple of months ago, and I haven't gotten back > to that. Unfortunately I didn't get the full set of patches which really did the rootless modes. If you want to create a full diff - I'm sure someone will look at them. Alan.
Re: Texteroids
On Sun, Jun 02, 2002 at 07:13:35AM -0700, Nicholas Wourms wrote: > Alan, > > I realize this point, but in light of recent debate, I wanted to submit an > inquiry to be updated on the status of his project, and any future plans. > This might be relevent to the list, as it was the whole purpose of the > initial question. Which, by the way, has caused you to rethink your > stance. The whole reason I became so impassioned is because you told the > person "It is not open source so we don't have it... Tough". I think you > can be a little more diplomatic or at least do a 10 second google search, > like I did, before replying in such a caustic way. I may have messed up > on a few minor facts and was misled by inaccurate documentation, but at > least we "may" have helped this person find a solution. And for that, all > this discussion was worth it. Then I apologize to Zechy for misleading him into thinking there wasn't a solution. But as for server side extension - I still don't change my stance. Alan.
Re: Texteroids (Minor Retraction)
On Sun, Jun 02, 2002 at 07:03:54AM -0700, Nicholas Wourms wrote: > --- Alan Hourihane <[EMAIL PROTECTED]> wrote: > > Huh ? > > > > libdps in the XFree86 CVS does not depend on "strict motif" at all, > > in fact it has no dependencies on motif, lesstif or anything 'tif. > > It all builds straight from the CVS - all open source. > Yes you are right for the core library, but some additional widgets > included in addon library require motif: > > The source code for libdpstkXm is included with XFree86; however, as it > depends on Motif, this library is not built by default. > > Sorry for the confusion. Right. And that's why I'm saying it doesn't depend on them. If you have them available fine. > > There is no DPS extension in XFree86 CVS either. Like I said the 4.1.0 > > RELNOTES are wrong. Although, yes, http://dps.sourceforge.net provides > > an initial extension for XFree86. But that isn't included in our > > baseline tree. > So the release notes are wrong, I wrote this letter before I received your > clarification on that... > > > What are you ranting about the Open Group for here ??? > > > > You seem to have really gone off at a tangent. > > Why am I ranting? Because it is highly annoying that they have forbidden > using "OpenMotif" on Cygwin/XFree86 when they know full well that > Cygwin/XFree86 is NOT Microsoft Windows, but a platform of its own that > happens to run on top of MS Windows. In any event, if you followed the > list, some other porting projects have been hindered by the lack of > OpenMotif or full Lesstif->Motif compatibility. As I said you can > disagree, but it is relevant to the project. I mean pressure needs to be > put on the so-called "Open Group" to change that policy. Huh again. Where did I say I was disagreeing with you. And why don't you think I follow this list ? I've been on this list for quite some time. If you have some bitching to do about "The Open Group" that bitch at them. We already know the problems we've got here, or help improve LessTif which is certainly more productive. Alan.
Re: Texteroids
Nicholas, There currently exists NO server side support in the current XFree86 CVS. Juliusz may have every intention of moving the code from dps.sourceforge.net into the baseline XFree86 CVS at some point in the future. But currently it ain't there. Probably because, as far as the webpage is concerned, it still claims it's pre-alpha stage. And it even mentions that your better off running dgs if your seriously needing DPS support. Alan. On Sun, Jun 02, 2002 at 06:52:31AM -0700, Nicholas Wourms wrote: > Juliusz, > > Is what Alan saying true? Are there no plans to have a server side DPS > extension officially in the xfree distribution? I noticed from the cvs > activity that the libraries are still being maintained... > > Cheers, > Nicholas > --- Alan Hourihane <[EMAIL PROTECTED]> wrote: > > Ummm, > > > > Excuse me, but you are wrong > > > > The RELNOTES2 is actually incorrect. There is no extension. That > > means server side support. There is however client side support. > > > > What I mean by server extension, is when you do 'xdpyinfo' and > > it lists the extensions. DPS is not one of those extensions. > > > > Having checked if there's an agent. Yes there is. You need to > > get the dgs sources. Just goto http://rpmfind.net and whack in > > 'dgs'. Now this little program provides the dpsnx.agent program > > which does the equivalent to a server side DPS extension, and > > uses our client side libraries. > > > > As for cygwin.cf there's a BuildDPS NO which doesn't mean an > > awful lot as nothing uses 'BuildDPS' it's meaningless and should > > be removed. > > > > Alan. > > > > On Sun, Jun 02, 2002 at 06:10:35AM -0700, Nicholas Wourms wrote: > > > Ummm, > > > > > > Excuse me but you are wrong. If you care to read > > > http://www.xfree86.org/4.1.0/RELNOTES2.html you will notice the line > > that > > > says: > > > -initial DPS extension support > > > If you still doubt me, then check out the xfree cvs repository: > > > http://cvsweb.xfree86.org/cvsweb/xc/lib/dpstk/ or > > > http://cvsweb.xfree86.org/cvsweb/xc/lib/dps/ > > > > > > Now the $40K question is, why isn't this library being built in the > > cygwin > > > distro? Probably no one has attempted to do so, but I'm sure harold > > can > > > tell you what changes to your hosts.dep are necessary to attempt to > > build > > > it, should you decide to embark on the journey to build support in to > > your > > > xfree. > > > > > > In fact this extension has been available for use since 4.0.3, IIRC. > > > > > > Cheers, > > > Nicholas > > > --- Alan Hourihane <[EMAIL PROTECTED]> wrote: > > > > On Sun, Jun 02, 2002 at 04:00:51 +0800, Zechy Wong wrote: > > > > > Hi, something happened when I tried to run texteroids. > > > > > An X window was open, and when I ran texteroids a black box > > > > > appeared briefly before disappearing. These are the messages I > > got: > > > > > > > > > > %% DPS Client Library Warning: > > > > >Auto-launching DPS NX agent. > > > > > %% DPS Client Library Warning: > > > > >FAILED to auto-launch: > > > > > dpsnx.agent > > > > > > > > > > texteroids: DPS is not available. > > > > > You need an X server with the DPS extension, or a DPS NX agent. > > > > > > > > > > Wonder if anyone could help? > > > > > > > > That's the Adobe Display PostScript extension. It's not open source > > > > so the server extension isn't in Cygwin/XFree86. > > > > > > > > Basically. Tough. You can't run that app on this Xserver. > > > > > > > > I know the Solaris Xsun server's have, but we don't. > > > > > > > > Alan. > > > > > > __ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com
Re: Texteroids (Minor Retraction)
Huh ? libdps in the XFree86 CVS does not depend on "strict motif" at all, in fact it has no dependencies on motif, lesstif or anything 'tif. It all builds straight from the CVS - all open source. There is no DPS extension in XFree86 CVS either. Like I said the 4.1.0 RELNOTES are wrong. Although, yes, http://dps.sourceforge.net provides an initial extension for XFree86. But that isn't included in our baseline tree. What are you ranting about the Open Group for here ??? You seem to have really gone off at a tangent. Alan. On Sun, Jun 02, 2002 at 06:42:53AM -0700, Nicholas Wourms wrote: > Ok, > > I forgot the fact that building libdps depends on "strict motif" or gtk > libs, the former not being "open source" (nor legally available for > windows) and the latter still being ported to cygwin by Harold. I > apologize for the minor confusion, as I was still thinking in "linux > mode". For the curious, please check out: > > http://www.xfree86.org/4.2.0/dps.html > http://dps.sourceforge.net/ --> Show actual textroids screenshot in linux > http://www.gyve.org/gtkDPS/ > > > I do have some commentary regarding the so-called "Open Group". There is > nothing that pisses me of more then that oxymoron of a name. Yet another > example of academic innovation being commericialized for corporate greed > and profit (The last time I checked MIT did recieve government subsidies). > Personally I feel like giving the "Open Group" the finger by porting the > motif sources to cygwin and providing to all interested for download. > Lets face it, lesstif is nice, but it is still not there yet in terms of > full compatibility. Frankly, the excuses used to classify cygwin as a > non-open source platform are splitting hairs in my opinion. But, again, > these are my opinions and you are free to disagree. I just felt I needed > to release some steam about this pet peeve of mine. > > > Cheers, > Nicholas > --- Nicholas Wourms <[EMAIL PROTECTED]> wrote: > > Ummm, > > > > Excuse me but you are wrong. If you care to read > > http://www.xfree86.org/4.1.0/RELNOTES2.html you will notice the line > > that > > says: > > -initial DPS extension support > > If you still doubt me, then check out the xfree cvs repository: > > http://cvsweb.xfree86.org/cvsweb/xc/lib/dpstk/ or > > http://cvsweb.xfree86.org/cvsweb/xc/lib/dps/ > > > > Now the $40K question is, why isn't this library being built in the > > cygwin > > distro? Probably no one has attempted to do so, but I'm sure harold can > > tell you what changes to your hosts.dep are necessary to attempt to > > build > > it, should you decide to embark on the journey to build support in to > > your > > xfree. > > > > In fact this extension has been available for use since 4.0.3, IIRC. > > > > Cheers, > > Nicholas > > --- Alan Hourihane <[EMAIL PROTECTED]> wrote: > > > On Sun, Jun 02, 2002 at 04:00:51 +0800, Zechy Wong wrote: > > > > Hi, something happened when I tried to run texteroids. > > > > An X window was open, and when I ran texteroids a black box > > > > appeared briefly before disappearing. These are the messages I got: > > > > > > > > %% DPS Client Library Warning: > > > >Auto-launching DPS NX agent. > > > > %% DPS Client Library Warning: > > > >FAILED to auto-launch: > > > > dpsnx.agent > > > > > > > > texteroids: DPS is not available. > > > > You need an X server with the DPS extension, or a DPS NX agent. > > > > > > > > Wonder if anyone could help? > > > > > > That's the Adobe Display PostScript extension. It's not open source > > > so the server extension isn't in Cygwin/XFree86. > > > > > > Basically. Tough. You can't run that app on this Xserver. > > > > > > I know the Solaris Xsun server's have, but we don't. > > > > > > Alan. > > > > > > __ > > Do You Yahoo!? > > Yahoo! - Official partner of 2002 FIFA World Cup > > http://fifaworldcup.yahoo.com > > > __ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com
Re: Texteroids
Ummm, Excuse me, but you are wrong The RELNOTES2 is actually incorrect. There is no extension. That means server side support. There is however client side support. What I mean by server extension, is when you do 'xdpyinfo' and it lists the extensions. DPS is not one of those extensions. Having checked if there's an agent. Yes there is. You need to get the dgs sources. Just goto http://rpmfind.net and whack in 'dgs'. Now this little program provides the dpsnx.agent program which does the equivalent to a server side DPS extension, and uses our client side libraries. As for cygwin.cf there's a BuildDPS NO which doesn't mean an awful lot as nothing uses 'BuildDPS' it's meaningless and should be removed. Alan. On Sun, Jun 02, 2002 at 06:10:35AM -0700, Nicholas Wourms wrote: > Ummm, > > Excuse me but you are wrong. If you care to read > http://www.xfree86.org/4.1.0/RELNOTES2.html you will notice the line that > says: > -initial DPS extension support > If you still doubt me, then check out the xfree cvs repository: > http://cvsweb.xfree86.org/cvsweb/xc/lib/dpstk/ or > http://cvsweb.xfree86.org/cvsweb/xc/lib/dps/ > > Now the $40K question is, why isn't this library being built in the cygwin > distro? Probably no one has attempted to do so, but I'm sure harold can > tell you what changes to your hosts.dep are necessary to attempt to build > it, should you decide to embark on the journey to build support in to your > xfree. > > In fact this extension has been available for use since 4.0.3, IIRC. > > Cheers, > Nicholas > --- Alan Hourihane <[EMAIL PROTECTED]> wrote: > > On Sun, Jun 02, 2002 at 04:00:51 +0800, Zechy Wong wrote: > > > Hi, something happened when I tried to run texteroids. > > > An X window was open, and when I ran texteroids a black box > > > appeared briefly before disappearing. These are the messages I got: > > > > > > %% DPS Client Library Warning: > > >Auto-launching DPS NX agent. > > > %% DPS Client Library Warning: > > >FAILED to auto-launch: > > > dpsnx.agent > > > > > > texteroids: DPS is not available. > > > You need an X server with the DPS extension, or a DPS NX agent. > > > > > > Wonder if anyone could help? > > > > That's the Adobe Display PostScript extension. It's not open source > > so the server extension isn't in Cygwin/XFree86. > > > > Basically. Tough. You can't run that app on this Xserver. > > > > I know the Solaris Xsun server's have, but we don't. > > > > Alan. > > > __ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com
Re: Texteroids
On Sun, Jun 02, 2002 at 04:00:51 +0800, Zechy Wong wrote: > Hi, something happened when I tried to run texteroids. > An X window was open, and when I ran texteroids a black box > appeared briefly before disappearing. These are the messages I got: > > %% DPS Client Library Warning: >Auto-launching DPS NX agent. > %% DPS Client Library Warning: >FAILED to auto-launch: > dpsnx.agent > > texteroids: DPS is not available. > You need an X server with the DPS extension, or a DPS NX agent. > > Wonder if anyone could help? That's the Adobe Display PostScript extension. It's not open source so the server extension isn't in Cygwin/XFree86. Basically. Tough. You can't run that app on this Xserver. I know the Solaris Xsun server's have, but we don't. Alan.
Re: CVS Update: xc (branch: trunk)
Actually, I had to turn off building of Xft1 because we don't have a concept of shared library versions. We had this on unixes. libXft.so.2.0 libXft.so.1.0 On Windows... libXft.dll (libXft.a) (bang)... We build Xft (v2) first, then Xft1 came along and blew libXft.dll away with v1 of the library.. I suspect the usage of the Xft1 (v1) library is pretty minimal on Windows so we won't be impacted. But it might be worth thinking of a solution here, we may have to call it libXft2.dll for our purposes and hack around with the .cf and Imakefiles. We could use the SOREV stuff here. Takers ? Alan. On Sat, May 25, 2002 at 02:06:31 -0400, Harold Hunt wrote: > Alan, > > I'm not so sure I fixed this correctly... > > A straight through build of the XFree86 tree with this patch still exhibits > the same problem (i.e., x11perf, xlogo, and xclock don't build because > XftDrawPicture and XftDrawSrcPicture are missing). > > However, I can do the following and all three of them build: > cd lib/Xft > rm libXft.a > rm libXft.dll > make > cd ../programs/xlogo > make > cd ../x11perf > make > cd ../xclock > make > > > Any ideas why the straight-through build still fails? > > > Harold > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Alan Hourihane > > Sent: Saturday, May 25, 2002 8:03 AM > > To: [EMAIL PROTECTED] > > Subject: CVS Update: xc (branch: trunk) > > > > > > CVSROOT:/home/x-cvs > > Module name:xc > > Changes by: [EMAIL PROTECTED] 02/05/25 05:03:14 > > > > Log message: > > #5283, Fix Xft-def.cpp for Cygwin/XFree86 > > > > Modified files: > > xc/programs/Xserver/hw/xfree86/: > > CHANGELOG > > xc/lib/Xft/: > > Xft-def.cpp > > > > Revision ChangesPath > > 3.+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG > > 1.3 +3 -1 xc/lib/Xft/Xft-def.cpp > > > > ___ > > Cvs-commit mailing list > > [EMAIL PROTECTED] > > http://XFree86.Org/mailman/listinfo/cvs-commit
Re: CVS Update: xc (branch: trunk)
Fixed. lib/Xft1 was overwriting lib/Xft as the LibName was the same. Alan. On Sat, May 25, 2002 at 02:06:31 -0400, Harold Hunt wrote: > Alan, > > I'm not so sure I fixed this correctly... > > A straight through build of the XFree86 tree with this patch still exhibits > the same problem (i.e., x11perf, xlogo, and xclock don't build because > XftDrawPicture and XftDrawSrcPicture are missing). > > However, I can do the following and all three of them build: > cd lib/Xft > rm libXft.a > rm libXft.dll > make > cd ../programs/xlogo > make > cd ../x11perf > make > cd ../xclock > make > > > Any ideas why the straight-through build still fails? > > > Harold > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Alan Hourihane > > Sent: Saturday, May 25, 2002 8:03 AM > > To: [EMAIL PROTECTED] > > Subject: CVS Update: xc (branch: trunk) > > > > > > CVSROOT:/home/x-cvs > > Module name:xc > > Changes by: [EMAIL PROTECTED] 02/05/25 05:03:14 > > > > Log message: > > #5283, Fix Xft-def.cpp for Cygwin/XFree86 > > > > Modified files: > > xc/programs/Xserver/hw/xfree86/: > > CHANGELOG > > xc/lib/Xft/: > > Xft-def.cpp > > > > Revision ChangesPath > > 3.+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG > > 1.3 +3 -1 xc/lib/Xft/Xft-def.cpp > > > > ___ > > Cvs-commit mailing list > > [EMAIL PROTECTED] > > http://XFree86.Org/mailman/listinfo/cvs-commit
Re: makeNativeRgn
On Wed, Apr 10, 2002 at 11:02:45PM +1000, Robert Collins wrote: > > -Original Message- > > From: Alan Hourihane [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, April 10, 2002 10:37 PM > > > > Will do. > > > > > Actually Rob, don't worry about it. I've already implemented > > what you've suggested. > > Heh, the next version is nearly ready which is what the delay is. I'll > send in the patch anyway once I fix one last bug. You can use or not at > your discretion. > No problem. Your help is appreciated. I certainly don't get mega speedups that you've talked about. And I wouldn't expect them from the span routines, so I don't know what your seeing on your machine. Alan.
Re: makeNativeRgn
On Wed, Apr 10, 2002 at 06:28:11PM +1000, Robert Collins wrote: > > > > -Original Message- > > From: Alan Hourihane [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, April 10, 2002 5:44 PM > > To: [EMAIL PROTECTED] > > Subject: Re: makeNativeRgn > > > > > > On Wed, Apr 10, 2002 at 03:35:06PM +1000, Robert Collins wrote: > > > There's more that can be done, like moving the clipboard selection > > > before the spans iteration, but the biggest improvement > > I've achieved > > > so far is making native Rgn's for the FILLTILED routine. > > I'll make a > > > patch for this once I clean a little other code in > > winfillsp.c up. The > > > background rendering is instantaneous with this for me. > > > > > O.k. > > > > I'll hang off applying that other patch until you've done the above. > > > > Can you send the patch as an attachment. At my end windows > > nicely put in the good old =20 and =3D expansions into the last email. > > Will do. > Actually Rob, don't worry about it. I've already implemented what you've suggested. Alan.
Re: Just a note - nativegdi engine
On Wed, Apr 10, 2002 at 10:18:39AM +1000, Robert Collins wrote: > > -Original Message- > > From: Alan Hourihane [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, April 10, 2002 1:57 AM > > To: [EMAIL PROTECTED] > > Subject: Re: Just a note - nativegdi engine > > > > > > On Wed, Apr 10, 2002 at 01:47:58AM +1000, Robert Collins wrote: > > > 2) I'm working on, I suspect it's a coordinate translation thing. I > > > get lovely background stipple but not (AFAICT solid fills). > > > > > Rob, > > > > Take a look at wingc.c and set miTranslate to 0 (FALSE). > > Already tried that :}. Does that intelligently translate - i.e. will > code for pixmaps be unaffected, and only window drawables get > translated/not translated? > pDrawable->x, y should always be 0 on a pixmap. On a window they're different, but I understand should be 0 too with that set. Alan.
Re: clipping questions
On Wed, Apr 10, 2002 at 04:53:07PM +1000, Robert Collins wrote: > In the span functions, > if pGc->CompositeClip has > (nbox = REGION_NUM_RECTS (pRegion)) == 0, what does that indicate? > > Should we skip rendering the span? Grab 1 rect and hope we can read it? > > Something else? > That would suggest to me no rendering and skip the span. Alan.
Re: makeNativeRgn
On Wed, Apr 10, 2002 at 03:35:06PM +1000, Robert Collins wrote: > There's more that can be done, like moving the clipboard selection > before the spans iteration, but the biggest improvement I've achieved so > far is making native Rgn's for the FILLTILED routine. I'll make a patch > for this once I clean a little other code in winfillsp.c up. The > background rendering is instantaneous with this for me. > O.k. I'll hang off applying that other patch until you've done the above. Can you send the patch as an attachment. At my end windows nicely put in the good old =20 and =3D expansions into the last email. Alan.
Re: makeNativeRgn
On Wed, Apr 10, 2002 at 12:42:23PM +1000, Robert Collins wrote: > Alan, > this may be of use to you: It's the region optimisation I mentioned > before. It seems a little faster to me, which indicates that some > (most?) of the calls have mulitple clip regions. > Robert, Thanks for the patch. I'll apply it. Like I said though, I haven't even started at looking at optimizations until the span functions are working correctly. So your gonna find lots and lots of places that can be optimized. Alan.
