| original_url | created_at | updated_at | closed_at | status | type | resolution | reporter | owner | priority | milestone | component | version | keywords | cc | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
2010-09-08 06:57:38 -0700 |
2015-10-23 17:33:29 -0700 |
2015-10-23 17:33:29 -0700 |
closed |
usability |
Duplicate |
sci-fi@… |
jeremyhu@… |
Important |
later |
xserver |
2.5.3 (xserver-1.8.2) |
semi-stuck H/h key |
|
[I first thought this was related to ticket #305, but a response there seems to indicate this is a different problem, so I will refile it as a separate bug, with additional info.]
Hi,
I am still using 10.5.8 on a 2006 iMac C2D 24". I have been using the latest Leopard XQuartz dmg for a couple years; now I use 2.5.3.
I have had a semi-stuck 'H'/'h' key for almost all this time, what I can remember, and still right now. It takes a few 'slaps' of that key to get it to stop repeating so fast. AFAICT no other key acts this way here, and it acts *only* under the XQuartz subsystem (not on any native OSX itself). We can definitely throw-out any idea of hardware problem.
The main problem is that H/h tells Pan to show/hide the Usenet article headers, either the message being viewed, or upon the next article if none selected. If H/h is hit during viewing an article, the text will bounch up-&-down extremely fast, in relation to how-much-header is needing to be printed.
Also, depending on where the text cursor is directed/located (for ex inside the Subject-Search box), hitting the H/h will likely cause a string of H/h's to be repeated inside that box.
The repeat rate seems to coincide with the System Prefs setting, I know of no other way to control it (X11-wise, GTK/glib-wise, etc).
I never use Fink/Macports to build most apps (they all kill my env-vars I want/need to use). Instead I will painstakingly build all sorts of open-src apps by hand with the XCode-provided make/gcc/etc system (and I do mean a huge amount of projects, mainly: most all libs for ffmpeg/mplayer support, the GTK/glib stuff for Pan newsreader and the HDHomeRun SiliconDust apps, etc).
I do not build the full/entire GNOME system, either; we just need the components for Pan & other apps etc.
I also never have any use for Expose/Spaces, so I can say this bug is for 'plain' use [and thus different than ticket #305 AFATIC].
The keyboard in use here is the one I ordered separately, the 2007 metal USB hard-wired Apple chicklet keyboard with so-called 10-keypad on the right-hand side. Small printing on its underneath side says Model A1243.
I do not have *any* files named ~/.X* nor ~/.x* --- yes I do mean including the leading 'dot'. ;) I have no need to do that kind of fancy X11-isms here. ;)
I cannot see any of the rdar articles here either, because the MobileSafari app needed (being forcibly invoked) is broken under Leopard.
I read the mailing lists via the websites carrying them. I thought someone had mentioned this precise problem there quite some time ago, but the symptoms & remedies do not apply to my environments IIRC, ergo I have been living with the stuck H/h for quite some time. At any rate, the ticket system only produced #305 when I tried to search for (several) revelant keywords etc. I now strongly feel whatever "remedy" is required for this stuck H/h problem, that we record it here in the ticket system so it can be more-easily found for perpetuity.
[FWIW I am still worried so much about building FOSS for SL that I am staying with 10.5.x probably 'til the cows come home (sorry).]
[Also FWIW I follow a ton of FOSS apps thru the GMane maillist/Usenet system there, which is perhaps why you-all might not have heard of me. ;) I hope have your list-mgrs join GMane if not already.]
[Lastly FWIW I am medically disabled / retired. Do this as a hobby to keep braincells sharp. My former regular job was deeply Computer Spechuslist {purposely misspelled to get around your trac spam filtering} / SystemS Programming, in everything from Mainframes down to FreeBSD/Linux, for nearly 30-years. I do feel I know my way around "problem reports" etc, so that's why I type so darn much here, and why I feel we need to *properly* archive the kinds of info they can save for perpetuity.]
Please advise?
Thank you.
jeremyhu@… commented on Oct 16, 2010
- Status changed from new to closed
- Resolution changed from to worksforme
This sounds like a hardware issue. There is nothing "special" about the H key as far as X11 is concerned.
sci-fi@… commented on Nov 7, 2010
- Status changed from closed to reopened
- Resolution worksforme deleted
Replying to jeremyhu@…:
This sounds like a hardware issue. There is nothing "special" about the H key as far as X11 is concerned.
I'm talking about XQUARTZ, not X11 per se.
If you'll re-re-read my lengthy explanation above, this is *not* a hardware problem, since H/h works *fine* on all ALL (EVERY OTHER) OSX app. *EXCEPT* for XQUARTZ, across many releases. But any-other key seems fine EVEN UNDER XQUARTZ. As I have said.
The semi-stuck H/h key is still occurring even right now. Only on XQUARTZ apps. Even on the xterm that is started by Xquartz.app. But NOT occurring under regular plain OSX apps.
Do you "Mr.worksforme" have the indicated precise Apple-manufactured keyboard "Model A1243"? With the official firmware that was released for it a while back? If not, then how can you say it _really_ does "worksforme" yourself?
[Yes I am quite angry with this "resolution" -- getting this kind of response from the Apple employees: "The user is dumb, don't help him/her." If this isn't true, then I *need* help in this regard, not just a blanket droll explanation. With everything else Apple is currently doing to us little customers, I am feeling entirely alienated with this entire platform/system. You-all need to stop treating us as plain "dumb".]
So how do we figure out what this problem is, please? Exactly who are we to address this problem, if Apple has a hardware problem with this particular keyboard MODEL under the XQUARTZ app strictly? This is the direction I am requiring, to further this problem along, please.
Thank you.
jeremyhu@… commented on Nov 7, 2010
- Status changed from reopened to closed
- Resolution set to worksforme
Replying to sci-fi@…:
Replying to jeremyhu@…:
This sounds like a hardware issue. There is nothing "special" about the H key as far as X11 is concerned.
I'm talking about XQUARTZ, not X11 per se.
Correct. XQuartz is the X11 server that we run on Mac OS X. XQuartz does nothing special with the h key.
If you'll re-re-read my lengthy explanation above, this is *not* a hardware problem, since H/h works *fine* on all ALL (EVERY OTHER) OSX app. *EXCEPT* for XQUARTZ, across many releases. But any-other key seems fine EVEN UNDER XQUARTZ. As I have said.
I read your message. I understand your frustration, but there is no other user experiencing this problem, and there is nothing in our code that does anything with the h key. Please examine it yourself if you don't believe me.
The semi-stuck H/h key is still occurring even right now. Only on XQUARTZ apps. Even on the xterm that is started by Xquartz.app. But NOT occurring under regular plain OSX apps.
If you can figure out a reproduction case, that may help, but there is nothing I can do.
Do you "Mr.worksforme" have the indicated precise Apple-manufactured keyboard "Model A1243"? With the official firmware that was released for it a while back? If not, then how can you say it _really_ does "worksforme" yourself?
Yes. I have 3, and I have never seen this problem. It is also common hardware and I'd suspect that if it was the problem, others would have reported similar issues.
[Yes I am quite angry with this "resolution" -- getting this kind of response from the Apple employees: "The user is dumb, don't help him/her."
Please point to where you have been seen a response such as, "The user is dump, don't help him/her" ... that is certainly not Apple policy!
If this isn't true, then I *need* help in this regard, not just a blanket droll explanation. With everything else Apple is currently doing to us little customers, I am feeling entirely alienated with this entire platform/system. You-all need to stop treating us as plain "dumb".]
I don't think you are treated as dumb, but as I mentioned, there is *NOTHING* that we do with the h key other than pass it through just like we do with almost every other key.
So how do we figure out what this problem is, please?
Standard debugging principles: Have you tried creating a fresh user account? Have you tried this keyboard on another machine? Have you tried another keyboard? Have you tried it without other software running in the background? ...
Exactly who are we to address this problem, if Apple has a hardware problem with this particular keyboard MODEL under the XQUARTZ app strictly?
You are the only report of this issue, that's why I think it is likely an issue with your specific configuration.
This is the direction I am requiring, to further this problem along, please.
If you can provide concrete reproducibility or some indication that this is really a bug in XQuartz, please reopen with that information... otherwise, I advise you do direct questions to the x11-users mailing list where you will get help from the community at large rather than just me. Perhaps someone on the list might have other ideas to help you.
sci-fi@… commented on Jul 16, 2011
- Status changed from closed to reopened
- Resolution worksforme deleted
[I'm re-opening this, after re-discovering where I had originally filed this bug-report, and with new discussion on the xquartz-devel mail-list suggested I do have such a report on-file here. Along with several other problems with recent XQuartz (v2.6.1 thru 2.6.3 on SL/10.6.8 as I re-open this), I posted the text below:]
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 the provided 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).
[I was then told by Jeremy Huddleston that work on 2.7.0 should have "improved debug logging" and he will "get something in place that [I] can use to debug this".]
[I want to say further that the model I'm using is iMac6,1 late-2006 C2D but still has 32-bit EFI and thus needs the 32-bit kernels. It does boot the Lion previews fine, but I've not purused Lion much further than that (yes I am a paid ADC member).]
[Also another thing that might be related: I have been noticing that this iMac won't fully boot-up several of the 'live CD' kits being shared around the net, these CDs usually get stuck at a user-intervention type screen that needs input from a keyboard/mouse. I am only needing a barebones m$ system so I can run the Pioneer firmware update tools to upgrade the BDR-203 bluray drive I bought from OWC (who does not have such tools, shame on Mac vendors who won't support what they sell). So I've been asking for help at the rpc1.org site, hopefully to port their latest DVRFlash tool to OSX which should do this.]
doh123@… commented on Jul 16, 2011
Just for the record... I've seen this same exact problem with the H key in several games running under Wine... I've always worked around it by remapping the keys in game to not use the H key. I've never seen it happen with any key except the H key. Happened in 10.5 and 10.6 with built in keyboards on 3 different Models of Macbook Pros.
doh123@… commented on Jul 21, 2011
- Cc doh123@… added
randrew@… commented on Sep 20, 2011
I can confirm that this is real. It happens to me across several different Macs on different versions of OS X with different keyboards. It only happens in XQuartz, no other application. It happens with keyboards in different languages, and it's always the H key. In addition to getting semi-stuck, it will sometimes drop H keystrokes, causing a typo.
jeremyhu@… commented on Sep 20, 2011
Well I've never seen it, and I have no way to reproduce it. Without either of those, there's nothing I can do. "h" is not treated special in any way by the server, so I don't see how this is possible (at least at the XQuartz layer).
randrew@… commented on Sep 20, 2011
It doesn't seem to happen when 'Enable key equivalents under X11' is unchecked. Maybe the problem is being caused by something that looks for Cmd-H?
sci-fi@… commented on Sep 21, 2011
Hi,
I'm still here. ;)
I send 'thank you's to other people having this problem and coming by this ticket to jot a quick log.
To update this ticket further, I'm (now/still) on OS-10.6.8 with all possible updates. I'm also running "XQuartz 2.7.0_beta1 (xorg-server 1.10.99.901)" (quoted from its About box). I'm still having this problem.
I tried turning 'off' the 'Enable key equivalents under X11' checkbox as randrew suggested just above. Mine was checked, but unchecking it did not help the problem -- immediately I went to Pan to fetch a message from Gmane, and hit 'h' to see its headers, and voila it went into the loop. BTW I do need this box enabled: with it off, XQuartz does not follow the Cmd+<number> keys to flip-around the various X11 tasks I have running.
To ping jeremyhu: since I have the 2.7.0b1 installed & running now, please detail the 'debug' steps you mentioned in the mail-list, which will help us figure out this problem. If you'd rather/wish, post to the mail-list for others to see. Thank you.
jeremyhu@… commented on Jun 2, 2012
I still have never seen this issue, and I have 'Enable key equivalents under X11' checked. Regarding debug logging, check out the "LOGGING" section of the Xquartz man page.
jpd@… commented on Jul 16, 2012
Replying to jeremyhu@…:
I still have never seen this issue, and I have 'Enable key equivalents under X11' checked. Regarding debug logging, check out the "LOGGING" section of the Xquartz man page.
Here's a procedure that reliably induces the problem for me (with 'Enable key equivalents under X11' checked):
Close all X11 windows, but leave XQuartz running.
command-N (open terminal)
command-H (hide XQuartz)
Click XQuartz icon to unhide
Click terminal window to focus
shift-H
I see something like HHHhhhhhhhhhhh.... every time.
jeremyhu@… commented on Jul 16, 2012
Ok, so it's almost certainly fallout from the CMD-H ... interesting... I've reproduced that case.
I still haven't seen it happen randomly though.
jeremyhu@… commented on Jul 16, 2012
- Milestone set to 2.7.4
jpd@… commented on Jul 17, 2012
Replying to jeremyhu@…:
Ok, so it's almost certainly fallout from the CMD-H ... interesting... I've reproduced that case.
I still haven't seen it happen randomly though.
It seems to happen on the first 'h' or 'H' after CMD-H. That might, of course, be long after, thus appearing to be random.
jeremyhu@… commented on Aug 28, 2012
- Milestone changed from 2.7.5 to 2.7.4
jeremyhu@… commented on Sep 20, 2012
- Milestone changed from 2.7.4 to 2.7.5
I need to get 2.7.4 out to address a critical issue seen in OS X 10.8.2 and 10.7.5, so deferring everything that is not a regression.
jeremyhu@… commented on Oct 16, 2012
More info in #672
jeremyhu@… commented on Nov 15, 2013
- Milestone changed from 2.7.5 to 2.7.6
jeremyhu@… commented on Apr 6, 2014
- Milestone changed from 2.7.6 to 2.7.7
jeremyhu@… commented on Apr 6, 2014
- Status changed from reopened to new
jeremyhu@… commented on Apr 6, 2014
- Status changed from new to assigned
jeremyhu@… commented on Jul 23, 2014
- Milestone changed from 2.7.7 to later
dlanini@… commented on Dec 15, 2014
Replying to jeremyhu@…:
Just saw this thread. I've experienced the semi-stuck 'h' key behavior for at least the last 5 years. I hadn't yet realized that it happens after using CMD-H to hide X11, but sure enough, I can reproduce the repeating behavior every time in Xterm if/when I do just that. I use "xv" (and old, (antique?) image viewer and regularly end up with images flipping horizontally endlessly and have been hoping (read assuming) someone would find and fix this problem especially since it has been identified and is reproducible, so I'm just adding my 2 cents worth of frustration here.
If it makes any difference, I'm using XQuartz XQuartz 2.7.7 (xorg-server 1.15.2) on a Mac Pro (A1289) with 24GB running Mavericks (OSX 10.9.5 - soon to be 10.10). But as I said, I've had this issue since I was using Snow Leopard, (or maybe even Leopard on my old Power Mac G4).
At least I now know when to expect it this mis-behavior, but its still frustrating nonetheless.
bencoh@… commented on Jul 16, 2015
I've also been experiencing this behavior for years (four or five), but I had always thought it was due to my window manager (wmii). It occurs on different machines with different Darwin/Xquartz versions (all running fullscreen wmii):
- MacBookPro (~2008/2009) with 10.5
- MacBookPro 2011 with 10.7.3 (stock X11)
- MacBookPro 2011 with 10.7.4 (stock X11)
- MacBookPro Retina 2014 with 10.10.4 (Xquartz 2.7.7)
I had never noticed it always happens with the first 'h' after Cmd-H (it seemed quite random to me thus far and I suspected it was some race condition with one of the wmii shortcuts), but I can reproduce it at will following this procedure (as mentioned in the previous comments): Cmd-H in X11 (fullscreen), switch back to X11, press 'h' with or without any modifier (immediatly or with others keystrokes in-between), release key, enjoy the repeating behavior.
I don't know whether it's related or not (it might be a completely separate bug), but I also often need to press 'h' to get any keyboard input to X11 windows (I probably need to file a proper detailed report for this one).
jeremyhu@… commented on Oct 23, 2015
Mass Edit
As you may have noticed, we have had issues with spam in trac for the past couple years. We've decided to migrate to using freedesktop.org's bugzilla for our bug tracker (more details will be coming on the mailing lists in the next couple weeks).
I don't want us to loose valuable bug reports in the transition, so I want to make sure that any relevant open issues in this MacOSForge trac are migrated over to the new system. If you are interested in this issue, please take a few minutes to file a new bug for this issue in bugzilla. Please make sure to do the following:
- Copy over all relevant information into that report, just in case we loose this one.
- Set the URL field of the bugzilla report to this trac ticket's URL.
- Paste the URL of the new bugzilla report as a comment in this ticket, and I'll close it out.
jpd@… commented on Oct 23, 2015
Migrated to https://bugs.freedesktop.org/show_bug.cgi?id=92648
jeremyhu@… commented on Oct 23, 2015
- Status changed from assigned to closed
- Resolution set to Duplicate
Thanks.