[Pkg-xfce-devel] Bug#523517: Bug#523517: xfce4-settings: <Alt> and <Meta> keyboard settings swapped
dawitbro at sbcglobal.net
Sat Apr 11 02:37:12 UTC 2009
Yves-Alexis Perez wrote:
> On ven, 2009-04-10 at 15:33 -0400, Dave Witbrodt wrote:
>> Today I discovered that my XFCE keyboard configuration has become
>> confused, with the <Alt> key being swapped with the <Meta> key in many
>> cases. I have been using keyboard Application Shortcuts bound to
>> <Ctrl><Alt>-t and <Ctrl><Alt>-b for a long time, and just discovered
>> they were no longer working.
>> I recently upgraded from XFCE 4.4 to XFCE 4.6 in Sid, and today upgraded
>> xorg from 7.3 to 7.4. I cannot say with confidence which upgrade
>> introduced the problem -- I had other, more visible problems with the
>> XFCE upgrade, which I was able to solve by manually changing the icon
>> theme -- so I was not checking keyboard behavior. The xorg upgrade
>> _did_ have the effect of disabling the old X keyboard driver and
>> switching me to evdev, so that may well be the cause.
> Yes, the concurrent upgrades means that it's a bit difficult to track
> down the problems. Especially since xorg use hal now, so some people now
> have it installed while they didn't before.
> Basically, to track down problems it might be worth trying with a fresh
> config, so see if it's related to soft or config.
I'm afraid I didn't need to do that! :)
Problems seem to be solved.... [see below]
>> The last 2 entries shown here are my Application Shortcuts. Under XFCE
>> v4.4 I had defined these using <Ctrl><Alt>, and they somehow had changed
>> to <Ctrl><Meta> today. What you see above is the result of deleting the
>> shortcuts and manually resetting them to use <Ctrl><Alt> instead.
> It would have been nice to know if this was the result of the migration
> script, or the result of the X changes. Basically I think that alt/meta
> can just be the same (physical) key (the “Alt” one) but which can be
> differently mapped to alt or meta. And it may depend on the selected
> keyboard and/or layout.
There is another possibility I didn't consider: that <Meta> actually
means <Shift><Alt> on my system, and that the contents of that file were
not changed, but had always mapped both <Alt>-F2 and <Meta>-F2 to the
I should not have claimed this was a bug without being able to show the
original file as well as the (allegedly) changed version. Since these
changes, if any, never caused any problem for me at all, I no longer
believe that a bug report was warranted. Sorry about this noise.
The only problem I had was that my two Application Shortcuts, bound to
<Ctrl><Alt>-t and <Ctrl><Alt>-b, were somehow altered to
<Ctrl><Meta>-t/b -- which caused them to stop working. Simply removing
them and adding them back was the solution.
>> I am still trying to solve other keyboard-related issues:
>> 1) In DOSBox the numeric keypad <Enter> is not recognized the
>> same as the main <Enter> key, but it works fine in apps such as
>> 'mousepad', 'xfce4-terminal', and 'xfce4-notes-plugin'. This
>> key used to work fine in DOSBox. Numlock status has no effect.
> I don't know DOSBox. I'd say it's not an Xfce issue, but…
Well, I spent a few hours pondering this, reading documentation, and
experimenting. Clearly, something changed -- and the possibilities are
only my Xfce update or my xorg update. Neither the version of DOSBox,
nor my DOSBox configuration, nor the old DOS game I run on it changed at
Just before I began experimenting with 'xmodmap', I decided to look into
the DOSBox configuration and see if there was a way to remap the numeric
keypad <Enter> and the right <Ctrl> key. What I discovered, by
accident, was that DOSBox (which uses the SDL library) provides a
configuration setting called "usescancodes". My original setting was
"usescancodes=true," which is preserved from my original experimenting
with DOSBox running on a 32-bit Pentium 4 machine years ago. I doubt
that the setting ever made much difference, but I never thought about it
again... until now.
Simply setting "usescancodes=false" made everything work perfectly.
So, something changed with one of those upgrades that only bothered
DOSBox -- since no other software was affected. (The shortcut problem
mentioned earlier seems unrelated, unless the scan codes for <Alt> and
<Shift><Alt> were swapped when switching to evdev.)
I wish I could get back all of the numerous hours I've lost fighting
with Linux over issues just like this, which have 2-second fixes! :)
>> 3) In 'xfce4-terminal', the key combinations <Alt>-left and
>> <Ctrl>-left cause 'D' to be printed, and <Alt>-right and
>> <Ctrl>-right cause 'C' to be printed. (Other combinations also
>> produce strange, wrong results... so these are merely specific
>> examples.) This behavior was not seen before.
> If it should run a shortcut, then just (re)bind it at the correct place
> (I guess xfce4-terminal shortcuts settings). If it shouldn't, than
> there's not much to do about it. (for the record, here alt+left
> produces ;3D). And I'd say it's vte related :)
In other words, these observations also were not problems. I guess I
was assuming something was really broken with my keyboard support --
either because of X or Xfce, or both -- and just made mountains out of
>> I would like to be able to resize windows with <Alt><Shift>-arrow, and
>> move windows with <Ctrl><Alt><Shift>-arrow, again because I became so
>> conditioned to these key combinations. I have started retraining myself
>> to use <Alt>-F8 and <Alt>-F7 in the meantime, though.
> Yeah, you'll really have to do that, because the resize is gone
> completely. I'm not sure what Alt-F7 and Alt-F8 are bound to by default,
> but you can bind a key to “resize“ (and then use the arrow keys). One
> really nice feature of Xfce 4.6 is the “fill” resize. Really nice
> (you'll find the three shortcuts on the WM Shortcut settings)
That's a bummer... I really liked moving and resizing with those
modifier key combinations.
The default Xfce binding for <Alt>-F7 is "move", and <Alt>-F8 is
"resize". These are the features I want, but they seem less convenient
to me than the old way. Once I stop complaining, and just get over it,
I'll probably just get used to the new way. ;)
The net result here is that either there is no bug at all, or the Xfce
upgrade from 4.4 to 4.6 can mess up Application Shortcut bindings.
Allow me to thank and congratulate the Debian Xfce Maintainers on a job
well done -- I put Xfce 4.6 on hold for many days until I knew I would
have a lot of hours to troubleshoot, and then I upgraded Xfce and xorg
less than 24 hours apart with almost no problems at all.
More information about the Pkg-xfce-devel