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

Right click in Xmgrace
by Mengjuei Hsieh 05 Jan '10

05 Jan '10

Hi, I am not sure if this has been discussed, but it seems that I lost my click control every time I right click to show the contextual menu inside Xmgrace. The mouse cursor still moves around okay, but the cursor icon becomes an arrow point to upper right and I can't click anything. I can only cmd-q to close the X. The version of my Xquartz is 2.4.1_beta1 (xorg-server 1.7.1.901) and the results are the same either on linux or snowleopard (macports) xmgrace. The OS version is 10.6.2. Please let me know if I should provide more information. -- Mengjuei

2 5

Middle click broken during fast user switching
by Martin Otte 31 Dec '09

31 Dec '09

Hi, On 2 different machines (both OSX 10.6.2) with recent X servers (1.7.3), I find that that the middle mouse click is broken when I login using fast user switching when another user is already logged in. "Fake" middle clicks work correctly. The steps to reproduce this are: 1) Make sure that you are not logged in and that another user is. 2) Use fast user switching to log into your account while the previous user is still logged in. 3) Start the X server. Try copying and then pasting with the middle mouse button; it doesn't work for me. After some debugging in darwinEvents.c, it looks like the reported x and y positions of the middle click are wrong and are different than for the left and right clicks. I can get the middle click to work in an xterm window if I first maximize the window to fit most of the screen. If I then middle click to paste with the mouse pointer near the middle of the xterm, the paste works because the erroneous x and y points are then probably still within the xterm window. Further debugging shows that the problem occurs in X11Application.m, in the routine sendX11NSEvent, near line 1027: } else { location.x = lastpt.x + [e deltaX]; location.y = lastpt.y - [e deltaY]; lastpt = [e locationInWindow]; } After I login using fast user switching, the deltaX and deltaY values for middle clicks are erroneous. As a temporary fix, I noticed that in the block of code just above this, you added an exception for tablets where the reported deltas are bad; so I just added middle clicks to the exceptions: diff -up hw/xquartz/X11Application.m.baddeltas hw/xquartz/X11Application.m --- hw/xquartz/X11Application.m.baddeltas 2009-12-30 15:05:54.000000000 -0500 +++ hw/xquartz/X11Application.m 2009-12-30 15:08:38.000000000 -0500 @@ -1015,12 +1015,13 @@ static inline int ensure_flag(int flags, location.x += frame.origin.x; location.y += frame.origin.y; lastpt = location; - } else if(isTabletEvent) { + } else if(isTabletEvent || [e type] == NSOtherMouseDown || [e type] == NSOtherMouseUp) { // NSEvents for tablets are not consistent wrt deltaXY between events, so we cannot rely on that // Thus tablets will be subject to the warp-pointer bug worked around by the delta, but tablets // are not normally used in cases where that bug would present itself, so this is a fair tradeoff // <rdar://problem/7111003> deltaX and deltaY are incorrect for NSMouseMoved, NSTabletPointEventSubtype // http://xquartz.macosforge.org/trac/ticket/288 + // The deltaXY for middle click events also appear erroneous during fast user switching location = [e locationInWindow]; lastpt = location; } else { I'll assume that there shouldn't be a problem with the warp-pointer bug for just mouse click events. Please see if you can reproduce this bug and if this patch may be worthwhile for fixing it. Martin

2 2

X11 freezeup seen again
by Tom Lane 27 Dec '09

27 Dec '09

Currently running 2.5.0_beta1 with server 1.7.3; up-to-date 10.6.2. I noted this time that X11 was *not* shown as "(not responding)" in the Force Quit list. I'm not sure if I saw that before. Other symptoms the same as before: X11 menus can be pulled down but it's otherwise totally nonresponsive to keyboard and mouse events. Attached are Activity Monitor samples of X11 and quartz-wm, as Jeremy suggested grabbing last time. It's possibly relevant that at the time it froze, I had just quit out of iTunes. Also, a Time Machine backup started at more or less the same time. regards, tom lane Sampling process 5667 for 3 seconds with 1 millisecond of run time between samples Sampling completed, processing symbols... Analysis of sampling X11.bin (pid 5667) every 1 millisecond Call graph: 2382 Thread_256279 DispatchQueue_1: com.apple.main-thread (serial) 2382 start 2382 main 2382 mach_msg_server 2382 mach_startup_server 2382 _Xstart_x11_server 2382 do_start_x11_server 2382 server_main 2382 X11ApplicationMain 2382 -[NSApplication run] 2382 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 2382 _DPSNextEvent 2382 BlockUntilNextEventMatchingListInMode 2382 ReceiveNextEventCommon 2382 RunCurrentEventLoopInMode 2382 CFRunLoopRunSpecific 2382 __CFRunLoopRun 2382 mach_msg 2382 mach_msg_trap 2382 Thread_256364 DispatchQueue_2: com.apple.libdispatch-manager (serial) 2382 start_wqthread 2382 _pthread_wqthread 2382 _dispatch_worker_thread2 2382 _dispatch_queue_invoke 2382 _dispatch_mgr_invoke 2382 kevent 2382 Thread_256367 2382 thread_start 2382 _pthread_start 2382 server_thread 2382 dix_main 2382 Dispatch 2382 WaitForSomething 2382 select$DARWIN_EXTSN 2382 Thread_256368 2382 thread_start 2382 _pthread_start 2382 xpbproxy_x_thread 2382 xpbproxy_input_loop 2382 _pthread_cond_wait 2382 __semwait_signal 2382 Thread_256381 2382 thread_start 2382 _pthread_start 2382 DarwinProcessFDAdditionQueue_thread 2382 _pthread_cond_wait 2382 __semwait_signal 2382 Thread_256387 2382 thread_start 2382 _pthread_start 2382 __CFSocketManager 2382 select$DARWIN_EXTSN 2382 Thread_256391 2382 thread_start 2382 _pthread_start 2382 _xp_async_thread 2382 _xp_async_dequeue 2382 _pthread_cond_wait 2382 __semwait_signal 2382 Thread_342775 2382 thread_start 2382 _pthread_start 2382 __NSThread__main__ 2382 +[NSURLConnection(NSURLConnectionReallyInternal) _resourceLoadLoop:] 2382 CFRunLoopRunSpecific 2382 __CFRunLoopRun 2382 mach_msg 2382 mach_msg_trap 2382 Thread_342784: JavaScriptCore: FastMalloc scavenger 2382 thread_start 2382 _pthread_start 2382 WTF::TCMalloc_PageHeap::runScavengerThread(void*) 2382 WTF::TCMalloc_PageHeap::scavengerThread() 2382 _pthread_cond_wait 2382 __semwait_signal 2382 Thread_746520 2382 start_wqthread 2382 _pthread_wqthread 2382 __workq_kernreturn Total number in stack (recursive counted multiple, when >=5): 7 _pthread_start 7 thread_start Sort by top of stack, same collapsed (when >= 5): __semwait_signal 9528 mach_msg_trap 4764 select$DARWIN_EXTSN 4764 __workq_kernreturn 2382 kevent 2382 Sample analysis of process 5667 written to file /dev/stdout Sampling process 5729 for 3 seconds with 1 millisecond of run time between samples Sampling completed, processing symbols... Analysis of sampling quartz-wm (pid 5729) every 1 millisecond Call graph: 2499 Thread_256382 DispatchQueue_1: com.apple.main-thread (serial) 2499 start 2499 main 2499 CFRunLoopRun 2499 CFRunLoopRunSpecific 2499 __CFRunLoopRun 2499 mach_msg 2499 mach_msg_trap 2499 Thread_256385 DispatchQueue_2: com.apple.libdispatch-manager (serial) 2499 start_wqthread 2499 _pthread_wqthread 2499 _dispatch_worker_thread2 2499 _dispatch_queue_invoke 2499 _dispatch_mgr_invoke 2499 kevent 2499 Thread_256386 2499 thread_start 2499 _pthread_start 2499 __CFSocketManager 2499 select$DARWIN_EXTSN Total number in stack (recursive counted multiple, when >=5): Sort by top of stack, same collapsed (when >= 5): kevent 2499 mach_msg_trap 2499 select$DARWIN_EXTSN 2499 Sample analysis of process 5729 written to file /dev/stdout

2 3

MacPorts' xorg-server-devel @1.7.99.2 with 10.5.8 and GNU Emacs 23.1.90
by Peter Dyballa 27 Dec '09

27 Dec '09

Hello Jeremy! An "ancient" version of GNU Emacs 23.1.50 showed this effect, and the freshly compiled GNU Emacs 23.1.90 shows it even in more extreme: just a few mm of text are shown (the remainder cut off to the right at some pixels). Before it could have been the same amount in cm, see attached screenshot. The lower window in the 23.1.90 (tool) frame shows text that was previously selected to copy it to GNU Emacs 22.3 (which works fine). Then the selection high-lighting was removed and a bit more text, as in 23.1.50, was shown. With the previously used xorg-server-devel @1.7.99.1 all worked fine... (which I am now going make active again) Bug report to MacPorts will follow! -- Greetings Pete "A TRUE Klingon warrior does not comment his code."

2 1

2.5.0_beta1
by Jeremy Huddleston 17 Dec '09

17 Dec '09

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

5 9

OSX 10.6.2 breaks X11 auth forwarding?
by Tom Lane 17 Dec '09

17 Dec '09

Since updating to 10.6.2 last night, I notice that every single outbound ssh -Y connection reports Warning: No xauth data; using fake authentication data for X11 forwarding. This happens with both 2.4.1_beta1 and the stock Snow Leopard X11. I've seen this message before but only occasionally; now it seems 100% reproducible. Anyone else see it? Any suggestions about investigating the cause? regards, tom lane

4 4

border drawing problem in xorg-server-1.7.3
by Martin Otte 03 Dec '09

03 Dec '09

Jeremy, I'm going to describe the last remaining problem the I see with border drawing in the recent 1.7.3 server, using the simple border.c example code that I sent a few months ago. I'll attach the simple code again so that you can easily have the code. When I compile and run the code, it just creates a window with an internal window that has a border. Previously, the internal border was not shown, but you have fixed this in the recent servers. I have attached initial.png that shows the initial correct appearance when I first run the program: now when I drag the handle to make the window smaller to obscure the border (minimized.png): and then drag the handle to make the window larger again, exposing the internal border again, the internal border becomes corrupted (reexposed.png): The only instance I can find when the internal border is always shown correctly is when the window is all the way in the upper-left corner of my display. The further the window is from the upper-left corner, the more corruption there is of the internal border. With a larger program that I have which displays many buttons of various sizes, even the initial appearance of the borders can be slightly corrupted if the window is away from the upper-left corner. In case this is system/graphic card dependent, I'm running this on a MacBook Pro. Can you verify the same behavior with my simple test case? Thanks, Martin

4 3