Thanks to everyone who've been testing the 1.7 servers and reporting regressions over 1.6. As of now, there are no known regressions from 1.5 to 1.6 to 1.7 (although there are a few "new" issues common to all of them pertaining to keyboard mapping), so I'm pleased to finally announce our first package release based entirely of upstream-released server bits, 1.7.3 (no -appleXX business here). We've also picked up new xcb-proto and some various other version bumps that are less consequential. http://xquartz.macosforge.org/downloads/SL/XQuartz-2.5.0_beta1.dmg (it should update through sparkle if you're using an earlier alpha/beta). Please let me know if there are any issues. Thanks, Jeremy
Jeremy Huddleston a écrit :
Thanks to everyone who've been testing the 1.7 servers and reporting regressions over 1.6. As of now, there are no known regressions from 1.5 to 1.6 to 1.7 (although there are a few "new" issues common to all of them pertaining to keyboard mapping), so I'm pleased to finally announce our first package release based entirely of upstream-released server bits, 1.7.3 (no -appleXX business here). We've also picked up new xcb-proto and some various other version bumps that are less consequentia
http://xquartz.macosforge.org/downloads/SL/XQuartz-2.5.0_beta1.dmg
(it should update through sparkle if you're using an earlier alpha/beta).
Please let me know if there are any issues.
Thanks, Jeremy
The XQuartz.pkg installer doesn't install (for me at least :-) /Applications/Utilities/XQuartz.app/ but if I get it "manually", every thing is fine. JF Sygnet
Jeremy Huddleston a écrit :
On Dec 3, 2009, at 12:22, Jean-Francois Sygnet wrote:
The XQuartz.pkg installer doesn't install (for me at least :-) /Applications/Utilities/XQuartz.app/ but if I get it "manually", every thing is fine.
I'm not sure what you mean. Why doesn't it install? Does it give an error?
Sorry, my mistake :-( Somewhere on my hard disk was another (old) version of XQuartz.app/ (actually in ~/Downloads/) and it seems that it prevented the XQuartz.pkg installer to copy the XQuartz.app/ (version 1.7.3) to /Applications/Utilities/ I.e.: the installer seemed to work perfectly, finishing with "Installation Successful" and with no errors in the logfile, but eventually no XQuartz.app was found in /Application/Utilities/ Deleting ~/Downloads/XQuartz.app/ and relaunching XQuartz.pkg solved the problem. (And I use a MacBookPro1,1 under 10.6.2) JF Sygnet
Ah, yeah... that's Installer.app trying to be smart. On Dec 3, 2009, at 15:13, Jean-Francois Sygnet wrote:
Jeremy Huddleston a écrit :
On Dec 3, 2009, at 12:22, Jean-Francois Sygnet wrote:
The XQuartz.pkg installer doesn't install (for me at least :-) /Applications/Utilities/XQuartz.app/ but if I get it "manually", every thing is fine. I'm not sure what you mean. Why doesn't it install? Does it give an error?
Sorry, my mistake :-(
Somewhere on my hard disk was another (old) version of XQuartz.app/ (actually in ~/Downloads/) and it seems that it prevented the XQuartz.pkg installer to copy the XQuartz.app/ (version 1.7.3) to /Applications/Utilities/ I.e.: the installer seemed to work perfectly, finishing with "Installation Successful" and with no errors in the logfile, but eventually no XQuartz.app was found in /Application/Utilities/
Deleting ~/Downloads/XQuartz.app/ and relaunching XQuartz.pkg solved the problem.
(And I use a MacBookPro1,1 under 10.6.2)
JF Sygnet _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Jeremy Huddleston <jeremyhu@apple.com> writes:
Please let me know if there are any issues.
Just had a most bizarre semi-freezeup in 2.5.0_beta1, unlike anything I've ever seen before. All of my existing windows stopped responding to mouse clicks --- in some of them a click produced a double beep, in others nothing. I could still open new windows, switch focus via command-digit, and type into the active window. X11's menus still worked too, and I could quit normally. Once before, Jeremy asked for an activity monitor sample of X11 to investigate a freezeup, so I took one before restarting X11. I have a grand total of perhaps an hour's runtime with 2.5.0_beta1 so far, so I'm suspecting this won't be too terribly hard to reproduce. What data should I gather next time? regards, tom lane Sampling process 142 for 3 seconds with 1 millisecond of run time between samples Sampling completed, processing symbols... Analysis of sampling X11.bin (pid 142) every 1 millisecond Call graph: 2342 Thread_875 DispatchQueue_1: com.apple.main-thread (serial) 2342 start 2342 main 2342 mach_msg_server 2342 mach_startup_server 2342 _Xstart_x11_server 2342 do_start_x11_server 2342 server_main 2342 X11ApplicationMain 2342 -[NSApplication run] 2342 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 2342 _DPSNextEvent 2342 BlockUntilNextEventMatchingListInMode 2342 ReceiveNextEventCommon 2342 RunCurrentEventLoopInMode 2342 CFRunLoopRunSpecific 2342 __CFRunLoopRun 2342 mach_msg 2342 mach_msg_trap 2342 Thread_966 DispatchQueue_2: com.apple.libdispatch-manager (serial) 2342 start_wqthread 2342 _pthread_wqthread 2342 _dispatch_worker_thread2 2342 _dispatch_queue_invoke 2342 _dispatch_mgr_invoke 2342 kevent 2342 Thread_975 2342 thread_start 2342 _pthread_start 2342 server_thread 2342 dix_main 2342 Dispatch 2342 WaitForSomething 2342 select$DARWIN_EXTSN 2342 Thread_976 2342 thread_start 2342 _pthread_start 2342 xpbproxy_x_thread 2342 xpbproxy_input_loop 2342 _pthread_cond_wait 2342 __semwait_signal 2342 Thread_987 2342 thread_start 2342 _pthread_start 2342 DarwinProcessFDAdditionQueue_thread 2342 _pthread_cond_wait 2342 __semwait_signal 2342 Thread_995 2342 thread_start 2342 _pthread_start 2342 __CFSocketManager 2342 select$DARWIN_EXTSN 2342 Thread_999 2342 thread_start 2342 _pthread_start 2342 _xp_async_thread 2342 _xp_async_dequeue 2342 _pthread_cond_wait 2342 __semwait_signal Total number in stack (recursive counted multiple, when >=5): 5 _pthread_start 5 thread_start Sort by top of stack, same collapsed (when >= 5): __semwait_signal 7026 select$DARWIN_EXTSN 4684 kevent 2342 mach_msg_trap 2342 Sample analysis of process 142 written to file /dev/stdout
That sample looks like an X11 server sitting idle waiting for events... It sounds like most of the X11 server functionality is working. From your use case, I don't think the server is frozen. My guess is that whatever application you were running is what actually froze, not the server. If this happens again, can you sample your quartz-wm process as well as the application itself? Thanks, Jeremy On Dec 3, 2009, at 22:08, Tom Lane wrote:
Jeremy Huddleston <jeremyhu@apple.com> writes:
Please let me know if there are any issues.
Just had a most bizarre semi-freezeup in 2.5.0_beta1, unlike anything I've ever seen before. All of my existing windows stopped responding to mouse clicks --- in some of them a click produced a double beep, in others nothing. I could still open new windows, switch focus via command-digit, and type into the active window. X11's menus still worked too, and I could quit normally.
Once before, Jeremy asked for an activity monitor sample of X11 to investigate a freezeup, so I took one before restarting X11.
I have a grand total of perhaps an hour's runtime with 2.5.0_beta1 so far, so I'm suspecting this won't be too terribly hard to reproduce. What data should I gather next time?
regards, tom lane
Sampling process 142 for 3 seconds with 1 millisecond of run time between samples Sampling completed, processing symbols... Analysis of sampling X11.bin (pid 142) every 1 millisecond Call graph: 2342 Thread_875 DispatchQueue_1: com.apple.main-thread (serial) 2342 start 2342 main 2342 mach_msg_server 2342 mach_startup_server 2342 _Xstart_x11_server 2342 do_start_x11_server 2342 server_main 2342 X11ApplicationMain 2342 -[NSApplication run] 2342 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 2342 _DPSNextEvent 2342 BlockUntilNextEventMatchingListInMode 2342 ReceiveNextEventCommon 2342 RunCurrentEventLoopInMode 2342 CFRunLoopRunSpecific 2342 __CFRunLoopRun 2342 mach_msg 2342 mach_msg_trap 2342 Thread_966 DispatchQueue_2: com.apple.libdispatch-manager (serial) 2342 start_wqthread 2342 _pthread_wqthread 2342 _dispatch_worker_thread2 2342 _dispatch_queue_invoke 2342 _dispatch_mgr_invoke 2342 kevent 2342 Thread_975 2342 thread_start 2342 _pthread_start 2342 server_thread 2342 dix_main 2342 Dispatch 2342 WaitForSomething 2342 select$DARWIN_EXTSN 2342 Thread_976 2342 thread_start 2342 _pthread_start 2342 xpbproxy_x_thread 2342 xpbproxy_input_loop 2342 _pthread_cond_wait 2342 __semwait_signal 2342 Thread_987 2342 thread_start 2342 _pthread_start 2342 DarwinProcessFDAdditionQueue_thread 2342 _pthread_cond_wait 2342 __semwait_signal 2342 Thread_995 2342 thread_start 2342 _pthread_start 2342 __CFSocketManager 2342 select$DARWIN_EXTSN 2342 Thread_999 2342 thread_start 2342 _pthread_start 2342 _xp_async_thread 2342 _xp_async_dequeue 2342 _pthread_cond_wait 2342 __semwait_signal
Total number in stack (recursive counted multiple, when >=5): 5 _pthread_start 5 thread_start
Sort by top of stack, same collapsed (when >= 5): __semwait_signal 7026 select$DARWIN_EXTSN 4684 kevent 2342 mach_msg_trap 2342 Sample analysis of process 142 written to file /dev/stdout _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
"JH" == Jeremy Huddleston <jeremyhu@apple.com> writes: JH> Please let me know if there are any issues.
I finally got around testing the new beta release. It works fine for me except some keyboard issues... JH> As of now, there are no known regressions from 1.5 to 1.6 to 1.7 JH> (although there are a few "new" issues common to all of them JH> pertaining to keyboard mapping), [...] ... you probably talked about. Key combinations I use all the time (e.g. for switching windows) like Command+Arrows, Command+Alt+Arrows, or Command+Shift+Arrows and the like do not work as expected, instead I see stuff like "[c[d0d0c[C[C" inserted in a XTerm, for example. Does this fit in your "new issues" or do you need more information? Thanks for your great work! -- Marcus
No, this is pretty much what I'm talking about. XKB has a bug whereby it doesn't reset flags on keys when the keymap changes, so we've got our correct keymap, but different keys are being tagged incorrectly because they inherrited those tags from the the default keymap that we clobbered. This is something on the list of "must fix" before 2.5.0 ships. --Jeremy On Dec 17, 2009, at 02:36, Marcus Crestani wrote:
"JH" == Jeremy Huddleston <jeremyhu@apple.com> writes: JH> Please let me know if there are any issues.
I finally got around testing the new beta release. It works fine for me except some keyboard issues...
JH> As of now, there are no known regressions from 1.5 to 1.6 to 1.7 JH> (although there are a few "new" issues common to all of them JH> pertaining to keyboard mapping), [...]
... you probably talked about.
Key combinations I use all the time (e.g. for switching windows) like Command+Arrows, Command+Alt+Arrows, or Command+Shift+Arrows and the like do not work as expected, instead I see stuff like "[c[d0d0c[C[C" inserted in a XTerm, for example. Does this fit in your "new issues" or do you need more information?
Thanks for your great work!
-- Marcus _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
participants (5)
-
Jean-Francois Sygnet
-
Jeremy Huddleston
-
Marcus Crestani
-
Robert Wyatt
-
Tom Lane