February 2009 - Xquartz-dev - lists.macosforge.org

2.4.0_beta1
by Jeremy Huddleston 02 Jun '09

02 Jun '09

Hi everyone. I'm proud to announce that 2.4.0_beta1 of XQuartz is ready. With this release, we've jumped to the 1.6 server branch, updated libX11, libxcb, pixman and various others from their rc versions to final release versions, and integrated massive improvements to our GLX support thanks to George's hard work. A list of all changes since 2.3.2.1 can be seen in our ChangeLog: http://xquartz.macosforge.org/trac/wiki/ChangeLog And here's the dmg: http://static.macosforge.org/xquartz/downloads/X11-2.4.0_beta1.dmg For those that are interested, the source code for our libGL is available in svn (see our websvn interface at http://xquartz.macosforge.org/trac/changeset) or from http://xquartz.macosforge.org/downloads/src. The X11 server is seeing massive changes to its input handling to support multiple devices and multitouch. As such, the 1.6 server branch has seen a fair number of changes as a stepping stone toward that end. Unfortunately, all the kinks have not been worked out of input handling, so most of the known regressions are related to input: * capslock doesn't work * a possible race condition can cause xmodmap to ruin your key mappings * workaround: move your ~/.Xmodmap file somewhere else and load it after X has already started * sometimes X may stop responding to your mouse * George has seen this, but I haven't. If someone can help with reproducibility, I'd be grateful George also has some note regarding the GLX improvement (we now support GLX-1.4): AppleSGLX Release Notes o OpenGL Support AppleSGLX supports the same version of OpenGL as Leopard (OpenGL 2.1). Many extensions from the OpenGL framework are now builtin. This adds support for GLSL, and a variety of other features. o Thread Support Thread support has been improved since the libGL in XQuartz 2.3.2.1. o GLX 1.4 Support The GLX 1.3 and 1.4 functions should all work with a few exceptions as outlined in this document. o glXMakeContextCurrent (a GLX 1.3 feature) glXMakeContextCurrent should work with the readable drawable. The OpenGL functions: glReadPixels, glCopyPixels, and glCopyColorTable, should use the readable drawable if it's different than the rendering drawable. o glXGetProcAddress (a GLX 1.4 feature and ARB extension) glXGetProcAddress should work and allow getting the address of any extension functions you may need from the X11 libGL, or OpenGL framework libGL. Previous versions of the X11 libGL didn't allow getting the newer OpenGL framework addresses. o GLXPixmaps New support for GLXPixmaps works well with mixed X11 and OpenGL drawing operations. You can create them using glXCreateGLXPixmap or glXCreatePixmap. o GLXPbuffers Support for GLXPbuffers has been added. These are drawables that are not possible to render to with X11, which is allowed by the spec. A GLXPbuffer will never generate a clobber event, however glXSelectEvent and glXGetSelectedEvent should operate normally. Clobber events are not generated due to low-level architectural differences. The contents of your pbuffers will not be clobbered. o Shared Contexts Due to basic low-level architectural differences the usage of shared contexts requires a similar visual or GLXFBConfig be used in the creation of a shared context. It's best if you specify the same visual. This is due to a CGL design difference, and not something that is easily worked around. o Indirect The X server supports indirect fairly well, so OpenGL applications can be run remotely and displayed by XQuartz. This means you can run applications from a remote host on an XQuartz X server. AppleSGLX does not support indirect rendering. Any indirect context created will appear to glXIsDirect as an indirect context, but it does not actually support indirect rendering to a remote X server. AppleSGLX supports GLXPixmaps and GLXPbuffers with direct and indirect contexts, though they are all direct contexts by definition (see above).

7 13

High CPU load on Mac OS X 10.4
by Simon Ruderich 04 Mar '09

04 Mar '09

Hi, With a new MacPorts installation I also installed X11 through it. After some initial problems which got fixed by Jeremy Huddleston X11 worked fine except for one problem. Shortly after starting X11.app the CPU load climbs up to 110%-160% according to top and Activity Monitor. I described the problem first on the MacPorts development list and Jeremy Huddleston asked me to describe it here. The problem sounds exactly like described in http://lists.macosforge.org/pipermail/xquartz-dev/2009-January/001952.html http://lists.macosforge.org/pipermail/xquartz-dev/2009-January/002042.html http://lists.macosforge.org/pipermail/xquartz-dev/2009-January/002044.html except that I'm running 10.4. I hope you have any ideas what can be done to solve this issue. At the moment I'm back to the default X11 installation :-/ Thanks for your help, Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229

4 13

Re: [Xquartz-dev] 1.4.2-apple34 - no crazy cpu :-)
by Christof Wolf 27 Feb '09

27 Feb '09

On Thursday 26 February 2009, xquartz-dev-request(a)lists.macosforge.org wrote: > Chris, could you check 1.4.2-apple34 ... it doesn't "fix" the problem > the right way. It just comments out the code you bisected to. I want > to *really* confirm that that is the problem. Dear Jeremy, nice to have an up-to-date X11 :-) 1.4.2-apple34 works fine - no crazy cpu!!! thanks chris -- public key www.hfph.mwn.de/~chwolf/chwolf.asc Please respect my privacy and do not make my contact information available to third parties.

1 0

2.3.3-beta1
by Jeremy Huddleston 27 Feb '09

27 Feb '09

So as mentioned yesterday, due to 1.6 not being as stable as I'd like, I've put together another release based on the 1.4 server. I've backported the DRI changes and some other miscellaneous cleanup into our 1.4 branch. Aside from the server change, this release is almost the same as the 2.4.0_beta1 release (meaning all the client side updates are still present). The only change outside the server is for libpng. libpng has been updated to address a security vulnerability (another reason I want to get out another stable release). See the draft release notes for full details: http://xquartz.macosforge.org/trac/wiki/X112.3.3 The dmg for the release is here: http://static.macosforge.org/xquartz/downloads/X11-2.3.3_beta1.dmg Thanks to everyone who was testing the 2.4 alphas and betas. We'll get back to that of that once 2.3.3 ships. Thanks, Jeremy

5 9

Re: [Xquartz-dev] [XQuartz] #241: xquarz uses 100% of CPU when not focused
by Christof Wolf 25 Feb '09

25 Feb '09

Jeremy, I checked my drivers. They are up to date and I tested my macbook pro with the other Intuos 3 (same driver) the same behavior. all my best christof > > I use an USB Wacom Intuos 2 and I have another Intuos 3, but I did > > not test it > > with that so far :-) > > I can separately confirm this behaviour. In my case, I DO have the > latest Wacom drivers. > > Best wishes > > Ralph > -- > Prof Ralph Martin Phone: +44(0)29 2087 5536 > School of Computer Science Fax: +44(0)29 2087 4598 > Cardiff University Email: mailto:ralph@cs.cf.ac.uk > 5 The Parade, Roath WWW: http://ralph.cs.cf.ac.uk/ > Cardiff, CF24 3AA, UK VOIP: sip:17476235487@proxy01.sipphone.com -- public key www.hfph.mwn.de/~chwolf/chwolf.asc Please respect my privacy and do not make my contact information available to third parties.

2 1

2.4.0_beta1 issues ... file bug reports
by Jeremy Huddleston 25 Feb '09

25 Feb '09

Ok, so I've talked this over with George and we both agree that 1.6 is just not "stable enough" right now. I was hoping there would just be a few minor issues I hadn't seen before, but there are just too many random issues to stabilize in the timeframe I'd like (and I'm sure there are others waiting to pop out of the woodwork). I really want to get a stable release out in the next month or so with the new libGL update, the updated libX11 and libxcb, and the various miscellaneous fixes (AFP home directory support, avoid rebuilding fontconfig cache for multiple-archs, the 100% CPU issue [which seems close to a real fix, but at minimum we can revert the patch that caused it], etc). To that end, I think I'm going to table the 1.6 server development for the next few weeks and focus on putting together another release based on the 1.4 server. This will require backporting some of George's GLX fixes. I think it's unfortunate that 1.6 didn't converge as fast as I had hoped, but I've made great strides. I just think it's more important to get a stable, mature release out that will take advantage of George's fixes. So, what that means is I'm going to forget the bugs mentioned with the 1.6 server in 2.4.0_beta1... but they're still going to be there when I resume work on the 1.6 server. PLEASE file a bug report with the info, so it doesn't get lost. http://xquartz.macosforge.org/trac/newticket Thanks, Jeremy

1 0

Re: [Xquartz-dev] [XQuartz] #241: xquarz uses 100% of CPU when not focused
by Christof Wolf 25 Feb '09

25 Feb '09

Jeremy, it's my Wacom tablet :-) I can reproduce it at any time - I just tested the 1.4.2-apple33 same thing, at the moment I plug in my tablet the CPU goes crazy (except if I am focused), if I unplug it it goes to normal. I use an USB Wacom Intuos 2 and I have another Intuos 3, but I did not test it with that so far :-) ciao christof -- public key www.hfph.mwn.de/~chwolf/chwolf.asc Please respect my privacy and do not make my contact information available to third parties.

2 1

Re: [Xquartz-dev] MacPorts XQuartz 2.3.2 (xorg-server 1.4.2-apple32) has problems with $PATH
by Peter Dyballa 21 Feb '09

21 Feb '09

Am 21.02.2009 um 16:04 schrieb xquartz-dev-request(a)lists.macosforge.org: > So then it sounds like everything is correct... what is the issue? The issue is that the correct value of PATH does not exist inside ~/.xinitrc – none of the applications launched by it inherit the correct PATH which existed in /Applications/MacPorts/X11.app/Contents/ MacOS/X11. On my previous eMail I made a mistake. What I invoke in bash is: exec -l /bin/tcsh -c 'echo $path' and I get: /Users/pete/bin /sw/lib/freetype219/bin /sw/lib/fontconfig2/bin /usr/ local/bin /usr/local/ActivePerl-5.8/bin /usr/local/texlive/2008/bin/ universal-darwin /usr/bin /bin /sbin /usr/sbin /usr/local/sbin /sw/ sbin /usr/X11/bin /sw/bin /sw/lib/coreutils/bin /Developer/Tools / Users/pete/bin/FDK/Tools/osx (with PATH instead of path I get: /Users/pete/bin:/sw/lib/freetype219/ bin:/sw/lib/fontconfig2/bin:/usr/local/bin:/usr/local/ActivePerl-5.8/ bin:/usr/local/texlive/2008/bin/universal-darwin:/usr/bin:/bin:/sbin:/ usr/sbin:/usr/local/sbin:/sw/sbin:/usr/X11/bin:/sw/bin:/sw/lib/ coreutils/bin:/Developer/Tools:/Users/pete/bin/FDK/Tools/osx) X clients launched from the programmes menu have: /Users/pete/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/ local/sbin:/usr/local/bin:/sw/bin:/usr/local/bin:/usr/local/texlive/ 2008/bin/universal-darwin:/Users/pete/bin/FDK/Tools/osx:/opt/local/ bin:/usr/X11R6/bin X clients launched by ~/.xinitrc have: /opt/local/bin:/usr/X11/bin:/Users/pete/bin:/usr/bin:/bin:/usr/sbin:/ sbin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin:/sw/bin:/usr/local/ bin:/usr/local/texlive/2008/bin/universal-darwin:/Users/pete/bin/FDK/ Tools/osx:/opt/local/bin:/usr/X11R6/bin Where do these irregular settings come from which cannot come from my own files because none handles strings that have the closest resemblance to these cited above, because they make use of my single spot of failure which is 'defaults read ~/.MacOSX/environment PATH' and which returns: /Users/pete/bin:/sw/lib/freetype219/bin:/sw/lib/fontconfig2/bin:/usr/ local/bin:/usr/local/ActivePerl-5.8/bin:/usr/local/texlive/2008/bin/ universal-darwin:/usr/bin:/bin:/sbin:/usr/sbin:/usr/local/sbin:/sw/ sbin:/usr/X11/bin:/sw/bin:/sw/lib/coreutils/bin:/Developer/Tools Except one: "/Users/pete/bin/FDK/Tools/osx" comes from either ~/.login or ~/.profile. -- Greetings Pete Klingons do not believe in indentation - except perhaps in the skulls of their project managers.

2 1

Re: [Xquartz-dev] MacPorts XQuartz 2.3.2 (xorg-server 1.4.2-apple32) has problems with $PATH
by Peter Dyballa 20 Feb '09

20 Feb '09

Am 20.02.2009 um 16:01 schrieb Jeremy Huddleston: > I'd put in some debugging stuff into your ~/.tcshrc or whatever that > saves the $PATH to a file before and after setting, so you can see > what's going on... This file is OK since some years, $path is the same as $PATH. When I create a new instance of Terminal it echoes what it has read before. Xterm in MacPorts' X11 has the same echo output as Terminal. After I have launched X11, a different value is echoed into Console. > > similarly, maybe put something in /Applications/MacPorts/X11.app/ > Contents/MacOS/X11 that does the same thing... then you can maybe > start narrowing down what's happening. Before the case block is entered, bash's PATH is the one as read with defaults from ~/.MacOSX/environment.plist. So the change happens around: csh|tcsh) exec -l "${SHELL}" -c 'exec $argv:q' "${@}" ;; When I invoke in bash (invoked by 'bash <RET>' which reads ~/.bashrc) inside Terminal exec -l /bin/tcsh -c 'exec $argv:q' "${@}" the correct path and PATH settings are echoed from ~/.cshrc (because I don't have a ~/.tcshrc file). -- Greetings Pete "Debugging? Klingons do not debug! Our software does not coddle the weak."

2 1

Re: [Xquartz-dev] MacPorts XQuartz 2.3.2 (xorg-server 1.4.2-apple32) has problems with $PATH
by Peter Dyballa 19 Feb '09

19 Feb '09

Am 18.02.2009 um 16:00 schrieb Jeremy Huddleston: > Here's how X11.app starts on Tiger (or on Leopard if you aren't using > the launchd start): > > X11.app inherits its environment from environment.plist just like any > other app launched by ApplicationServices. > X11.app runs a shell script on startup that gets an environment > from your login shell before launching the X11 binary. > The X11 binary fork/execs startx > startx fork/execs xinit > xinit fork execs xinitrc and X > X tells X11.app how to star the server (command line > arguments passed over mach IPC) > xinitrc runs your initial clients (like quartz-wm) > > Thus xinitrc inherits your environment.plist on Tiger. > With pstree I see: -+= 00001 root /sbin/launchd -v \-+= 00481 windowse /System/Library/Frameworks/ ApplicationServices.framework/Frameworks/CoreGraphics.framework/ Resources/WindowServer -daemon \-+- 06548 pete /Applications/MacPorts/X11.app/Contents/MacOS/ X11.bin -psn_0_36306945 \-+- 06569 pete /bin/sh /opt/local/bin/startx \-+- 06606 pete xinit /Users/pete/.xinitrc -- /opt/local/bin/ X :0 -nolisten tcp -dpi 100 -auth /Users/pete/.serverauth.6569 \-+= 06609 pete /bin/sh /Users/pete/.xinitrc \-+- 06630 pete /usr/local/bin/emacs-23.0.90 -geometry 100x57+696+145 -T 23.0.90 --debug-init So it seems that theory and practise meet. Examining with ps the processes' environments I get these PATH values: • 00001 root /sbin/launchd -v does not seem to have any • 00481 WindowServer has PATH=/usr/bin:/bin:/usr/sbin:/sbin • 06548 X11.bin has PATH=/Users/pete/bin:/usr/bin:/bin:/usr/sbin:/ sbin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin:/sw/bin:/usr/local/ bin:/usr/texbin:/Users/pete/bin/FDK/Tools/osx • all other programmes in the chain ínherit this (no quartz-wm running) This is a path that is not derived from any of my supported shells (sh, bash, csh, tcsh). And it isn't root's path, not even when I (root) copy my ~/.MacOSX directory to /var/root. When I change /etc/csh.login to contain /usr/local/texlive/2008/bin/ universal-darwin instead of Mac TeX's silly /usr/texbin, the latter is substituted with /usr/local/texlive/2008/bin/universal-darwin. Nevertheless elements from my shell's path value, coming directly from ~/.MacOSX/environment.plist, are not part of X11.bin's environment. They're included in all other Aqua clients, for example Carbon Emacs or Emacs.app or ... -- Greetings Pete They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania.

2 1