Red Hat Bugzilla – Bug 84907
Backward-incompatible Shift-F* changes
Last modified: 2007-04-18 12:51:33 EDT
Description of problem: The recent XFree86 version adds XF86_Switch_VT_* keyboard-bindings to Shift-F*: | $ xmodmap -pke | ... | keycode 67 = F1 XF86_Switch_VT_1 This breaks e.g. XEmacs which fails to interpret Shift-F* now: | $ xemacs | ... | C-h k Sh-f1 | f1 is undefined When executing "xmodmap -e 'keycode 67 = F1'" or running a previous XFree86, the message would be 'Sh-f1 is undefined'. Version-Release number of selected component (if applicable): XFree86-4.2.99.902-20030218.0 How reproducible: 100%
Please report this problem to the xfree86@xfree86.org mailing list as well, to ensure that the xkb maintainers can hopefully fix this alleged problem prior to the planned XFree86 4.3.0 gold release on Feb 27th. Once the fixes are in CVS, I can update our snapshot to the latest, or to 4.3.0, etc. and provide a package update. Please update this report when the issue has been reported upstream, so I can track it. Thanks.
Reported as http://marc.theaimsgroup.com/?l=xfree86&m=104608144732256&w=2
Closing bug as UPSTREAM
Is this alleged problem still present in Red Hat Linux 9? If so can you re-report it upstream in the new bugzilla so it can be tracked, and then provide the upstream bug URL here: http://bugs.xfree86.org
I presume that the problem was just a configuration problem for you, and that you have worked things out. If this is not the case and the problem still persists, please follow my instructions above of filing the bug upstream and pasting the upstream bug URL here, and reopening this report, and I will track it upstream as mentioned above Closing as NOTABUG.
This seems to be an XEamcs issue (see the third comment in http://list-archive.xemacs.org/xemacs-beta/200305/msg00331.html)
I have managed to hit this problem with RH9. There is an open bugzilla bug in xfree86. Referencing it here. I posted all the details there including some possible patches. http://bugs.xfree86.org/show_bug.cgi?id=643 Can this bug be re-opened?
Not sure why someone didn't report this upstream months ago as was requested, as it is possible Ivan Pascal or someone could have possibly come up with a solution by now if it had been reported to them. Now that it is reported upstream however, I will reopen this, and change the resolution to UPSTREAM. If Ivan or someone else develops a solution for this issue for 4.3.0 which gets accepted into the official XFree86 CVS repository in the xf-4_3-branch stable branch, I will apply it to some test builds for a while and see if anything breaks. If these (hypothetical) upstream xf-4_3-branch fixes turn out to be stable and not regress anything, I'll keep them in our official builds for future erratum, etc. Note that we will be tracking XFree86.org's official resolution to this however, and if XFree86.org rejects the bug, then we will reject it as well. This issue _must_ be fixed in XFree86's stable 4.3.0 branch before I will consider including it in any of our future 4.3.0 releases, as Ivan is the expert in this area, and if he rejects something, I consider his rejection as authoritative. If the problem is fixed in some way in the head of CVS, but not in the 4.3.0 branch, then it'll appear in our builds once 4.4.0 is released and we update to that. I wont backport fixes from CVS or 4.4.0 for this to 4.3.0 however unless Ivan considers them safe enough to personally commit them to the xf-4_3-branch upstream first. Ok, reopening this to set the status to UPSTREAM to track this in the upstream bug report. Thanks for the update.
The upstream bug report was closed by XFree86.org with resolution "NOTOURBUG", which indicates the issue is either a misconfiguration, or a bug in emacs or somewhere else. If this problem persists in a recent version of the OS distribution, please file a bug report against emacs. If you truely believe the issue is within the X code, be sure to upgrade to Fedora Core 2 first, and upgrade to the latest rawhide X.Org packages. If the problem persists, you can then file a bug report in X.Org bugzilla for a secondary opinion from our new upstream X11 project. If the experts in this area upstream believe this is not an X11 issue however, I have to defer to them as I am not an expert in this area. Closing bug as "NOTABUG" (we don't have a "NOTOURBUG" resolution)