Several nagging problems in recent Xquartz versions…
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. 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). 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. 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.) 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. 5. Please do not ask me to use a pkg-mgr like Fink or Macports etc. If any src-tarball won't work right "out of the box", then we need to study & fix things in the usual *ix manners, rather than covering-it-up. ;) 6. Personally, I am medically disabled / retired with 38+years work on record. My professional life was mainly in a big IBM mainframe shop doing systems-level work (not the app-level programming). I do open-src projects now as a hobby to keep my brain sharp. ;) All this is on a model iMac6,1 C2D machine with 4GB RAM (maxed-out), running 10.6.8 and all official updates so far. I have no kind of ~/.x* contraptions at all, so nothing should be bothering the Xquartz defaults etc. I try to keep watch on tons of projects via Gmane, a main reason I use Pan (where we're testing several new enhancements to it), and will attempt to follow any help with these problems. Thank you for reading.
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.
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
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.
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).
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. Thanks for the reports, Jeremy
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.
Hi, The new cairo-1.12.0 inside 2.7.2-beta4 seems to fix all the visual anomalies with Pan I reported last year. :) <https://lists.nongnu.org/archive/html/pan-users/2011-05/msg00019.html> <http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/12321> <news://news.gmane.org/453FC7B5-F410-497B-BC0A-7649B45ADF97@hush.ai> This is #3 in my xquartz report from July 12 2011 -- <https://lists.macosforge.org/pipermail/xquartz-dev/2011-July/003386.html> <http://permalink.gmane.org/gmane.os.apple.xquartz.devel/356> <news://news.gmane.org/pan.2011.07.12.17.55.33@scifi.homeip.net> I did not need to recompile anything here -- beta3 still showed the same whacky problems, yet beta4 with the new cairo suddenly showed those problems gone! Exact same Pan code & its other requisites etc. locally (but I did notice Pan takes a while to first start right-after the underlying XQuartz code has been updated, I believe this is due to the dynamic linking related jazz in OSX itself). Even the copy-&-paste highlighting artifacts are now looking as expected (which I could not show in the above posting). At least I presume it was the new cairo that fixed the problems. ;) (My Pan build should show in the User-Agent header line.) As for the other items in my report: 1. I've kept the work-around for the 2nd monitor, by moving the Display Prefs indicator for the Mits to the "other" side. 2. We still have the stuck-'h' key. In fact the bug-report #443 has a few more people who are experiencing this same problem. As for me, a recent Pan build from git.gnome.org can easily change its "hotkey" table, to let us steer-clear of using 'h' for any of its functions. 3. Apparently fixed as per the above. 4. Already fixed as noted further in the original thread. 5. I still cannot use the pkg-mgrs: the latest Pan code seems to need some projects/versions that are not (yet) available except for having to build 'em by hand the old-fashioned way. Sorry. ;) 6. I'm still here and in same condition. I am planning to move to a full open-source system sometime soonish. I find OSX not keeping-up with my favourite hobby for whatever internal reasoning besieging the company. Plus, my particular "iMac6,1" seems to be "officially retired" w/r/t 10.8. Again, sorry, and maybe this could be further discussed via email (BTW the gmane.org email system will de-obfuscate the strange addy for me, yes it will actually work, if you/anyone would like to correspond). Now I am a bit happyier, but still kinda afraid to move onwards. ;) FWIW I would like to pursue an old problem with the NNTP folks: The glitch with Giganews is still bothering us; I've asked the Pan team for some help if possible. Namely, I'd like to see the "hexdump -C" of the actual network packet(s) when we see this in the Pan error log:
Thu Mar 15 17:26:53 2012 - Error reading from news.giganews.com: Received corrupted data
Such glitches have been with GN ever since I first joined them many many years ago, and across several ISPs and news-reader apps etc., no matter if SSL is involved (even thru stunnel) or with just a plain straight connection. This occurs very randomly, a few times or so, day and night. It even occurs when I have Pan set off-line. No other Usenet server/company seems to do this (e.g. AW and Gmane do not do this, AFAICS). I'd like to get a handle on this glitch with GN and hopefully raise a proper support ticket with them. But we probably need to see the "guts" of the related network packet(s). It might be likely causing some other glitches with other F/OSS NNTP projects (such as the 'yencee' script I've mentioned in other earlier posts on the pan-* lists). Thanks for reading. --
On Apr 4, 2012, at 8:30 AM, SciFi <sci-fi@hush.ai> wrote:
Hi,
The new cairo-1.12.0 inside 2.7.2-beta4 seems to fix all the visual anomalies with Pan I reported last year. :)
Great! I knew it fixed some compositing issues, but that's great to hear. I like it when other people fix bugs, and all I need to do is version bump =)
As for the other items in my report:
1. I've kept the work-around for the 2nd monitor, by moving the Display Prefs indicator for the Mits to the "other" side.
Yeah, this one is a tough nut to crack. I'm not sure it's worth the effort, and hopefully it will "just work" with the changes coming in 3.0.
2. We still have the stuck-'h' key. In fact the bug-report #443 has a few more people who are experiencing this same problem. As for me, a recent Pan build from git.gnome.org can easily change its "hotkey" table, to let us steer-clear of using 'h' for any of its functions.
There's really nothing "special" about h other than that it's used higher up in the stack for cmd-h to hide windows. I'm really perplexed by this issue, and unless you can help me reproduce it, there's really no hope of me fixing it.
5. I still cannot use the pkg-mgrs: the latest Pan code seems to need some projects/versions that are not (yet) available except for having to build 'em by hand the old-fashioned way. Sorry. ;)
What versions are missing in MacPorts. I can probably update them for you...
On Wed, 04 Apr 2012 13:28:49 -0700, Jeremy Huddleston wrote:
On Apr 4, 2012, at 8:30 AM, SciFi <sci-fi@hush.ai> wrote: […]
2. We still have the stuck-'h' key. In fact the bug-report #443 has a few more people who are experiencing this same problem. As for me, a recent Pan build from git.gnome.org can easily change its "hotkey" table, to let us steer-clear of using 'h' for any of its functions.
There's really nothing "special" about h other than that it's used higher up in the stack for cmd-h to hide windows. I'm really perplexed by this issue, and unless you can help me reproduce it, there's really no hope of me fixing it.
For the 'h' key problem, some time ago I've asked in the bug-report #443 for precise directions on what to do for testing this problem, please. Assume I know some things, but not "everything" <g>. So I am still awaiting directions. ;)
5. I still cannot use the pkg-mgrs: the latest Pan code seems to need some projects/versions that are not (yet) available except for having to build 'em by hand the old-fashioned way. Sorry. ;)
What versions are missing in MacPorts. I can probably update them for you...
I think the main thing was with the new SSL support in Pan. We wanted to not need stunnel anymore with its more-complex setups etc. We had been testing OpenSSL, but the Pan community was worried about licensing issues, IIUC. (never mind the problems that I myself had with openssl-cvs <heh>) So, they switched to gnutls-2.12.10 or later. For some strange reason I now don't remember, I had to go with gnutls-3.0.9 or later perhaps for extra functions or similar. Of course I had built gnutls-3.0.9 myself (since I can't find it in your "available ports" search page) which now needs nettle and p11-kit as dependencies (instead of needing gcrypt as earlier gnutls required, IIUC). (I still can't find p11-kit in y'all's "available ports" search.) Perhaps if Macports & Fink et al. had a gnutls3 package with deps it could maybe live in the repros together with the current gnutls (but not with each-other on the user's machine of course). They also added crypto support in Pan with the help from the gmime-2.6.x line. Now y'all only have gmime thru 2.4.x which is ok for Pan to use but we won't have crypto support, see. Added problem is that I've been unable to build _working_ libs with the crypto support enabled via ./configure and have asked help from the main gmime author on this: <https://mail.gnome.org/archives/gmime-devel-list/2012-January/msg00002.html> <http://permalink.gmane.org/gmane.mail.mime.gmime.devel/155> <news://news.gmane.org/pan.2012.01.26.08.38.57@scifi.homeip.net> He finally responded: <https://mail.gnome.org/archives/gmime-devel-list/2012-February/msg00003.html> <http://permalink.gmane.org/gmane.mail.mime.gmime.devel/159> <news://news.gmane.org/4F3FCC48.2070206@gnome.org> He admits not having trying to build an OSX flavor. Anyway, I still need to work-up a report for the GPGME team as he requested me to do. And I need to follow-up with the Pan team asking why are they relying on gmime's obvious experimental code for crypto support, and instead why can't we use an already-established project to do crypto in Pan. Now the Pan team wants to do a release this weekend (yes during Easter for some reason). But I'm afraid us OSX users will have some debilitating functionality in this release. :( … BTW since no-one has wanted to further discuss my main pet peeve with the way things are going with OSX, I am only going to be interested in keeping 10.6.x alive here, not anything newer/higher. I know I must spend $$$ to do any kind of upgrade, so I have decided to eventually build my own "dream machine" design, use 100% open-source systems and apps on it, and spend my remaining time on this planet keeping it interesting to tinker with. Instead of having to give more to a company who is trying to close-down my favorite hobby (not to mention TPTB clamping-down our other Rights To Be Human™, but that's for another list). --
participants (2)
-
Jeremy Huddleston
-
SciFi