[Xquartz-dev] Several nagging problems in recent Xquartz versions…

[SciFi]

Hi,

On Tue, 12 Jul 2011 13:46:52 -0700, Jeremy Huddleston wrote:
> 
> On Jul 12, 2011, at 10:55 AM, SciFi wrote:
> 
>> 
>> Hi,
>> 
>> I'm having a few nagging problems with Xquartz, many versions of late,
>> including 2.6.3_rc2 (current as I type/send this note).
>> 
>> 1.  Whenever I hot-plug a 2nd monitor into the mini-DVI port,
>>    all Xquartz windows instantly want to get shoved-over to
>>    that monitor.  I must move my mouse-pointer over to that
>>    monitor and drag-back all those windows to main screen
>>    (the one marked by the desktop bar in Display Prefs).
>>    I do not use, nor have anything configured for, Spaces
>>    and/or Exposé etc., and I've tried various Xquartz Prefs
>>    to no avail.  Display Prefs is configured as an
>>    additional separate 2nd-screen, no 'mirroring' involved.
> 
> This has been an issue with every version of XQuartz that ever supported monitor hotplugging.  The windows don't move within the X11 screen, but the X11 screen now has a new offset (thus moving the windows).
> 
> The fix will be to move every window by the negative of the change in the offset.

Your deeper description of the 1st problem has spurred an idea.  My 2nd monitor is actually the main TV screen for my place [it's a Mitsubishi DLP, with DVI / HDMI (+HDCP) / FireWire (VirtualDVHS) attachments etc., and yes I use 'em all at various times].  The Mits is physically to the left of my iMac.  So naturally that's how I situated the Display Prefs representation for it.

After reading your message, I thought to try re-adjusting Display Prefs by placing the Mits screen to the _right_ of the iMac system screen.  Suddenly the X11 windows became visible on the iMac screen, just as expected / needed.  And this does seem to verify your explanation.  :)

Now, if I can only become accustomed to this arrangement, such as now dragging things past the iMac's right-hand edge instead of the "natural" left-hand edge, it seems this problem can be worked-around for now.  ;)

But I wonder how XQuartz can be made to tell which window(s) needs to be 'frozen' to the iMac display, and which others need to 'move' to the (new) 2nd monitor area, and 'remember' these settings?


>> 2.  I did file a report on my semi-stuck 'h' key, but I am
>>    presently unable to find it to update more tests.
>>    In short, I have tried _several_ keyboards, of various
>>    kinds, even an Apple Wireless (old style), and one
>>    expressly designed for M$-Windows "multimedia" apps
>>    made by Micro-Innovations, model KB565BL.  I've even
>>    tried to adjust the Keyboard Prefs to slow-down
>>    repeated keys etc. to no avail. 
>>    Nevertheless, I *will* eventually get a stuck-'h' key
>>    that self-repeats until I hit it a few more times. 
>>    Remember that it is only the apps running under Xquartz
>>    (including even xterm) that is doing this, none of
>>    the regular OSX apps have this problem.  So this does
>>    not indicate a hardware problem to me -- it indicates
>>    we have a very weird software interplay causing it,
>>    and I'm totally unsure where to ask for more help
>>    other than this list and/or bug-reports.  To wit,
>>    this *does* drive me crazy at times, because 'h' is
>>    a letter that is very-often used, esp'ly for
>>    displaying Headers under Pan (a very famous
>>    gtk+/glib newsreader app).
> 
> Unfortunately, you're the only one to report this issue.  xorg-server-1.11 (which will be in 2.7.0) has improved debug logging support quite a bit, so I'll get something in place that you can use to debug this with an early 2.7.0 alpha.  Please file a ticket for it on xquartz.macosforge.org

I finally found the bug-report I used to initially report this problem:

#443 "semi-stuck H/h key in Leopard XQuartz"
opened 09-Sept.2010

I've re-opened it with new info I've posted on this list, and have added a few more thoughts that might be related ("why me and no-one else").


>> 3.  The massive update included in the 2.6.1 version of
>>    Xquartz, and continuing now with 2.6.3_rc2, has caused
>>    marked visual problems with various text.
> 
> "massive" ? 2.6.1 wasn't that big of an update, and the server stayed on the same server-1.9-branch as 2.6.0.

Just to explain why I said "massive" is that there were many changes to the libs that GUI apps use directly -- cairo, pango, others, and esp'ly libpng-1.5 finally rubbing-out its "private" entries that caused other apps to get re-written.  ;)

I just haven't heard anything about any "requirements" in the glib/gtk+ chain that need recompiling to make things match-up to those changes.

If I ever have more down-time from the other tasks this iMac is doing, I'd much rather spend the time to get Lion installed and re-build all projects properly with latest versions etc.


>>    I've written up a report, and attached a PNG to show
>>    a few of the problems, here:
>>    <https://lists.nongnu.org/archive/html/pan-users/2011-05/msg00019.html>
>>    I was hoping to get some indication on what-all I
>>    should update in the glib/gtk+ train of requisites.
>>    No one has helped there, so I now bring this problem to
>>    this list where the X11 gizmos were bothered-with in
>>    the first place.  ;)  FWIW I do not see this problem
>>    in the xterm window, it seems to be only in the
>>    glib/gtk+ apps.  And yes 2.6.0-and-before I believe
>>    do not cause this problem.  (More is explained in the
>>    linked-to report.)
> 
> Can you try the 2.6.1 RCs to find out exactly when this first occurred?  Can you try installing the 2.6.0 X11.bin on top of 2.6.3_rc2 to see if it's a server issue or client issue?  If it's a client issue, then my hunch would be changes in libpng or cairo as those changed in 2.6.1 as well.  If it's a server issue (the 2.6.0 X11.bin "fixed" the problem), then it would help me to know the version that introduced this issue (or even an exact commit since you seem savvy building from source and might be handy with git-bisect).

I will try to go thru the various testing routines you've listed (with the 2.6.1-RCs etc.).  I don't have any idea how long this will take me.


>> 4.  I did open a newish bug-report to cover a simple fix
>>    when GNU 'mktemp' ends-up being used rather than the
>>    BSD 'mktemp'.  This is bug #490 in the Xquartz tracker.
> 
> That was fixed in April(?) in xinit, and it will land in 2.7.0.  See my comment in that bug report.

I didn't think to search the repo before opening #490.  ;)


> Thanks for the reports,
> Jeremy

Thank you.