Why is the Powerbook Fn-Key handled differently?

Why is the Powerbook Fn-Key handled differently?

[Matthias Grimm]

Hello,

I own an Powerbook G3 which has a Fn-Key for his special functions.
During my kernel source studies I learned that there are two keyboard
drivers: 1. The old machintosh keyboard driver and
          2. The new event driven Human Input Device from Vojtech Pavlik

The old driver map the scancode for the Fn-Key to a different value and
passes it to the Kernel keyboard driver. The new HID filters the Fn-Key
completely out, as the attached code fragments below show.

Is there any reason to cut out the Fn-Key in the new input driver?
Nevertheless the Fn-Key is hard wired with the special keys and the
number block, it would helpful to have an additional qualifier key on
this small keyboard.

For now this is to check if it makes sense for me to work further in
this direction.

  Thanks for your help in advance
    Matthias Grimm


Sourcefile: driver/machintosh/mac_keyb.c, old-style keyboard driver

static void
input_keycode(int keycode, int repeat)
{
	[...]

	/* remap the "Fn" key of the PowerBook G3 Series to 0x48
	   to avoid conflict with button emulation */
    >>>     if (keycode == 0x3f)
    >>>		keycode = 0x48;

	[...]
}

Sourcefile: driver/machintosh/adbhid.c, new-style keyboard event driver

static void
adbhid_input_keycode(int id, int keycode, int repeat)
{
	[...]

	switch (keycode) {
	[...]
   >>>	case 0x3f: /* ignore Powerbook Fn key */
   >>>		return;
	}

	[...]
}


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Why is the Powerbook Fn-Key handled differently?

[Michel Dänzer]

On Mon, 2002-02-04 at 19:20, Matthias Grimm wrote:

> I own an Powerbook G3 which has a Fn-Key for his special functions.
> During my kernel source studies I learned that there are two keyboard
> drivers: 1. The old machintosh keyboard driver and
>           2. The new event driven Human Input Device from Vojtech Pavlik
>
> The old driver map the scancode for the Fn-Key to a different value and
> passes it to the Kernel keyboard driver. The new HID filters the Fn-Key
> completely out, as the attached code fragments below show.
>
> Is there any reason to cut out the Fn-Key in the new input driver?
> Nevertheless the Fn-Key is hard wired with the special keys and the
> number block, it would helpful to have an additional qualifier key on
> this small keyboard.

If the fn key generates a keycode, existing shortcuts involving it won't
work anymore, will they? I'm specifically thinking of stuff like
ctrl-alt-{+,-} to switch resolutions in X.


--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Why is the Powerbook Fn-Key handled differently?

[Michael Schmitz]

On 5 Feb 2002, Michel Dänzer wrote:
> If the fn key generates a keycode, existing shortcuts involving it won't
> work anymore, will they? I'm specifically thinking of stuff like
> ctrl-alt-{+,-} to switch resolutions in X.

Not if that keycode is interpreted as modifier keycode in handle_scancode
(assuming XFree doesn't set the console to VC_RAW; if it does it needs
to be taught to handle Fn as modifier anyway)

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Why is the Powerbook Fn-Key handled differently?

[Michael Schmitz]

> The old driver map the scancode for the Fn-Key to a different value and
> passes it to the Kernel keyboard driver. The new HID filters the Fn-Key
> completely out, as the attached code fragments below show.
>
> Is there any reason to cut out the Fn-Key in the new input driver?
> Nevertheless the Fn-Key is hard wired with the special keys and the
> number block, it would helpful to have an additional qualifier key on
> this small keyboard.

AFAIR with the Fn key pressed, those keys that do have a Fn key mapping
will generate separate key codes anyway (leaving the key in would generate
a 'modifier' key event followed by a different keycode so you wouldn't see
fn-u but fn followed by kp-4). The rest of the modifier keys behaves
different (the keycode of a key pressed together with ctrl won't change).
That will be the reason why the HID code drops the fn key event. In order
to leave it in as additional modifier you'd need to add another translation
table (identity, as far as the keypad codes are concerned). Other than
that, I can see no reason to drop that key event.

BTW the old driver never shows up the Fn key events either. That 'special
value' seems to be dropped by handle_scancode now. The comment there
indicates the original keycode (assuming it goes through) would confuse
the mouse button emulation. Here's why:

  /*
    The X server for MkLinux DR2.1 uses the following unused keycodes to
    read the mouse:

    0x7e  This indicates that the next two keycodes should be interpreted
          as mouse information.  The first following byte's high bit
          represents the state of the left button.  The lower seven bits
          represent the x-axis acceleration.  The lower seven bits of the
          second byte represent y-axis acceleration.

    0x3f  The x server interprets this keycode as a middle button
          release.

    0xbf  The x server interprets this keycode as a middle button
          depress.

    0x40  The x server interprets this keycode as a right button
          release.

    0xc0  The x server interprets this keycode as a right button
          depress.

    NOTES: There should be a better way of handling mice in the X server.
    The MOUSE_ESCAPE code (0x7e) should be followed by three bytes instead
    of two.  The three mouse buttons should then, in the X server, be read
    as the high-bits of all three bytes.  The x and y motions can still be
    in the first two bytes.  Maybe I'll do this...
  */

IOW, the ancient Xpmac mouse data input hack (rerouting mouse data to the
keyboard input stream, yuck). Do we need to support this any further?? If
not, the remapping in the old driver can go, as can the 'if (kbd->kbdmode
== VC_RAW)' section of mouse_input.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/