This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 84907 - Backward-incompatible Shift-F* changes
Backward-incompatible Shift-F* changes
Status: CLOSED NOTABUG
Product: Red Hat Raw Hide
Classification: Retired
Component: XFree86 (Show other bugs)
1.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
: MoveUpstream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-02-23 12:31 EST by Enrico Scholz
Modified: 2007-04-18 12:51 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-31 20:58:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Enrico Scholz 2003-02-23 12:31:32 EST
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%
Comment 1 Mike A. Harris 2003-02-24 04:57:09 EST
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.
Comment 2 Enrico Scholz 2003-02-24 05:17:39 EST
Reported as
http://marc.theaimsgroup.com/?l=xfree86&m=104608144732256&w=2
Comment 3 Mike A. Harris 2003-04-08 11:35:01 EDT
Closing bug as UPSTREAM
Comment 4 Mike A. Harris 2003-04-25 06:24:34 EDT
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
Comment 5 Mike A. Harris 2003-05-21 08:42:55 EDT
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.
Comment 6 Enrico Scholz 2003-05-21 18:44:59 EDT
This seems to be an XEamcs issue (see the third comment in
http://list-archive.xemacs.org/xemacs-beta/200305/msg00331.html)
Comment 7 Gennady Feldman 2003-10-31 11:24:34 EST
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?
Comment 8 Mike A. Harris 2003-10-31 23:00:32 EST
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.
Comment 9 Mike A. Harris 2004-08-31 20:58:08 EDT
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)

Note You need to log in before you can comment on or make changes to this bug.