[xkb] map Apple->AltGr on Macintoshes?

I need to know exactly when this broke down. The fact you had something in
.bashrc it makes
very difficult to track down the problem.

Fabio

Downgrading xlibs to various versions (ubuntu18, 22, 23) does not make any
difference. However, the xmodmap call works with xserver-xfree up to
4.3.0.dfsg.1-6ubuntu23, and even works if I _upgrade_ from -23 to -24, but it
does not work if I install -24 from scratch (as done with the release candidate
candidate cd, or after purging the old package).

Of course it would be cool to have this working out of the box, but the xmodmap
call is at least an easy workaround, which should work in any case.

The real cause is the changing of macintosh to pc105 XkbModel. The keycode for
the Option key is the same in both models (0x73), but the xmodmap call does work
with 'macintosh', but not with 'pc105'.

Can I debug this any further?

I found a solution to transform the ugly xmodmap call to a proper configuration
option: setting

  Option "XkbOptions" "grp:lwin_switch"

will assign the Mode_switch key (i. e. for entering @ [] {} etc.) to the Super_L
key (Windows key on i386, Apple key on ppc).

The only remaining problem is that this does not work on pc105, only on
macintosh layout. If we found a solution how to make it work with pc105, then we
won't need to ask questions or create FAQs...

I just found out that the option 'lv3:lwin_switch' works fine for pc105.

Hmm, this is all highly handwavey stuff. How does OS X do it? Since that's the
OS most people will be using -- and the default, vendor-supplied OS -- we should
really be following its conventions as far as possible in this respect.

(In reply to comment #6)

> How does OS X do it? Since that's the
> OS most people will be using -- and the default, vendor-supplied OS -- we should
> really be following its conventions as far as possible in this respect.

I already wrote about this on u-devel: OS X uses simply "Alt" as the third level
key. However, since there are many Linux applications which use Alt for
different purposes (menu hotkeys and other stuff), we should not break Alt on
powerpc.

The plot thickens. The question is: what is the most predictable thing to do
here? If someone installs from OS X, how will they expect it to work?

(In reply to comment #8)
> The plot thickens. The question is: what is the most predictable thing to do
> here? If someone installs from OS X, how will they expect it to work?

I would rather compare it to Linux on other platforms. When I used the iBook the
first time, I intuitively used the Apple key, since apart from Alt there simply
was no other key available. So if it isn't Apple, there is no obvious choice.

So far my favourite solution is

  http://lists.ubuntu.com/archives/ubuntu-devel/2004-November/001092.html

("put this kind of thing into the XKB definitions for the keyboard layouts that
need them"). This is exactly what is done at the text consoles where Apple is
used for emulating AltGr in the German mac usb layout. Text consoles and X
should behave consistently, anyway.

I'd rather be consistent with the way the Mac keryboards are laid out under
MacOS / OS X.

I.e., AltGr => Option key (the one that's also labeled "alt" :-/ )
      Alt => Command key (the one with the Apple)

That may be confusing to people who get told to type Alt-Foobar (hit
Command-Foobar if using a Mac keyboard), but if you ever used a Mac before, or
(worse) if you need to switch between MacOS and Linux, there's no way you'll get
used to working differently. I know, I've been there.

Plus, people with some European keyboards need to use AltGr rather often, and
the Option key is on both sides of the space bar. Command usually isn't.

(In reply to comment #10)
> I'd rather be consistent with the way the Mac keryboards are laid out under
> MacOS / OS X.
>
> I.e., AltGr => Option key (the one that's also labeled "alt" :-/ )
> Alt => Command key (the one with the Apple)
>
> That may be confusing to people who get told to type Alt-Foobar (hit
> Command-Foobar if using a Mac keyboard), but if you ever used a Mac before, or
> (worse) if you need to switch between MacOS and Linux, there's no way you'll get
> used to working differently. I know, I've been there.

For me it's just the other way round. I never use MacOS, but very often switch
between my laptop and my desktop. Having the keys swapped on the laptop is very
confusing.

We should not redefine what is printed on the keys. Alt should stay Alt. MacOS
does _not_ swap the meaning of these keys, if you are told to press Alt there,
you have to.

> Plus, people with some European keyboards need to use AltGr rather often, and
> the Option key is on both sides of the space bar. Command usually isn't.

No, it's the other way round. There is only one Alt (Command) key, but two
Option (Apple) keys.

Let me think about it for a bit.

*** Bug 11168 has been marked as a duplicate of this bug. ***

My current feelings are to map one of the Apple keys to AltGr (both?). AltGr on
PC keyboards seems to typically be on the right-hand side, but given the
position of AltGr under OS X ... hmmm. Yeah, I think both Apples.

And then where do you put Meta ?

On my PowerBook, I only have 1 Apple key, on the left. I'm not sure you can get
the right one with a different key code, unlike for Option (aka Alt). I have 2
of these on my PowerBook.

I would like lv3:lwin_switch to be the default, and will look at how to do this
within XKB today, but it will not hold up the release of -1ubuntu9; if I figure
it out while it's building across all the machines, great. If not, another
release. :)

I don't see any real clean way to do this within the XKB definition for
keyboards that need it, and I don't want to mess too deeply with this sort of
thing (the modifiers in particular are spasmodically fragile), so if we're on
powerpc and the model is pc105, we add lv3:lwin_switch to the default set of
options. Mac people -- is this all I need? It all just works on my X40, y'see
... ;)

(In reply to comment #17)
> I don't see any real clean way to do this within the XKB definition for
> keyboards that need it, and I don't want to mess too deeply with this sort of
> thing (the modifiers in particular are spasmodically fragile), so if we're on
> powerpc and the model is pc105, we add lv3:lwin_switch to the default set of
> options. Mac people -- is this all I need? It all just works on my X40, y'see
> ... ;)

Nice to see some progress here; although the Enlish folks will certainly regret
losing their Meta key. Is it possible to restrict this further to add this
option only to non-English keyboards?

Otherwise adding this option is all that should be required. This makes console
and X keyboard perfectly consistent.

Er, surely Alt/Option is Meta?

Apple key is currently "Meta" but does not work properly as assigning shortcut
is GNOME does not recognize it as such, which prevent switching workspace or
process (meta-tab). Emacs do however recognize it as Meta.
Left and right Apple keys can NOT be address separately as they have the same
keycode, and PowerBooks only have one of these.

Option-Alt is currently used a "Alt" and allow to obtain | } ] and so on on
French layout, and should allow to get accent and other things, like it does on
MacOS X.

(In reply to comment #20)
> Option-Alt is currently used a "Alt" and allow to obtain | } ] and so on on
> French layout, and should allow to get accent and other things, like it does on
> MacOS X.

As we already discussed, this does not work because e. g. Fn+Alt+8 (on a German
layout) is not interpreted as (Fn+Alt)+8 = AltGr + 8, but as Alt+(Fn+8) which
selects "8" on the numeric keypad (on laptops) and results in Alt+8. Since Fn is
hardwired, we cannot change this interpretation in software.

(In reply to comment #21)
> As we already discussed, this does not work because e. g. Fn+Alt+8 (on a German
> layout) is not interpreted as (Fn+Alt)+8 = AltGr + 8, but as Alt+(Fn+8) which
> selects "8" on the numeric keypad (on laptops) and results in Alt+8. Since Fn is
> hardwired, we cannot change this interpretation in software.

I don't see where the Fn key comes in what I said.

I was just saying the expected behaviour, that has a solution as before
upgrading my PowerBook to ubuntu/X.org, the Apple key was bound as Meta and
recognized by GNOME to allow switching Metacity workspace, while Alt (aka
Option) is used to get | } ]. For me there is clearly a regression.

One should note, that I was using a slightly modified keymap to have that
behaviour, see http://seb.france.free.fr/linux/ibookG4/iBookG4-howto-5.html. The
keymap itself is at http://seb.france.free.fr/linux/ibookG4/fr_new

In the past, when the "Windows" key did not exist on PC keyboard, we had Ctrl,
Alt, AltGr (right Alt key). AltGr was use to get symbols like \ | on french
layout. The Apple keyboard is better because we also have the Apple key as an extra.

 xorg (6.8.1-1ubuntu10) hoary; urgency=low
 .
   * Change Option "HorizSync" "xx-yy" and Option "VertRefresh" "yy-zz" to
     HorizSync xx-yy and VertRefresh yy-zz in dexconf; thanks Marius Gedminas
     for the catch.
   * Disable horizontal scrolling by default on Synaptics touchpads (closes:
     Ubuntu#5014).
   * Pull i8xx/i915 driver back from HEAD, as it contains numerous improvements
     from Tungsten -- i915GM support, PanelID support, and support for custom
     video modes in the video BIOS, eliminating the need for
     855wrap/855resolution/865patch, et al (closes: Ubuntu#2827).
     + Mesa 6.2.x branch, which will allow DRI around suspend/resume (also
       fixing random video bustage after suspend/resume) on i8xx, is pending,
       and will be in the next revision.
   * Map right Apple -> Level 3 shift (AltGr) on Macintosh European layouts per
     default (closes: Ubuntu#2327).
   * dexconf: use dpkg --print-installation-architecture instead of
     dpkg-architecture, so we can do clean installs on hoary (and
     reconfigurations on the live CD) without dpkg-dev installed.
   * Add original iMacs to the list of desktop hardware which needs sync ranges
     written out, and via to the list of LVDS-driving chipsets which need sync
     ranges also (closes: Ubuntu#5085).
   * Add #099p, which changes the second level of tilde from backslash to
\303\251 on
     Turkish keyboards (closes: Ubuntu#5318).
   * Backport the entire via driver from the Unichrome project.
   * Rename XORGFORCEPROBE to XORG_FORCE_PROBE; make .config.in reset all
     values to defaults if this environment variable is set (semantics note:
     change most $RECONFIGURE tests to assume first install if -z $RECONFIGURE
     || -n $XORG_FORCE_PROBE, so you get the equivalent of the first install).
   * Rename DEBUG_XFREE86_PACKAGE to DEBUG_XORG_PACKAGE, and
     DEBUG_XFREE86_DEBCONF to DEBUG_XORG_DEBCONF, but still respect old
     variables.

I think this fix is about as good as I can get it, given you still need AltGr on
a UK-layout keyboard. Please reopen if you have any better suggestions. :)

(In reply to comment #23)
> * Map right Apple -> Level 3 shift (AltGr) on Macintosh European layouts per
> default (closes: Ubuntu#2327).

I don't have a Right Apple key on my PowerBook as I tolder in Comment 20

I'll download that package and see.

Why don't you include the fr_new keymap referenced in comment 22 ?

Two reasons -- first, I didn't really notice as it went past. Second, I don't
see the value in changing the keymap for no reason; it would change for everyone
using it, which would suck. And adding fr vs fr_new would just cause confusion.
 So I don't really want to include it, unless there's a very compelling case.
As for the Apple key thing, it should work for any Apple key.

(In reply to comment #25)
> Second, I don't
> see the value in changing the keymap for no reason; it would change for everyone
> using it, which would suck. And adding fr vs fr_new would just cause confusion.

In fact it should replace the fr keymap for Mac keyboards as it provide the same
layout as we have on MacOS X..... It has been designed this way, and even if not
perfect, it is far far away from what the default is.

And in fact, my problems seems to be that the X.org migration was so well done
that I still use it... :-/