Shift keycodes on the iBook

Hi,
I have come across this issue several times in the past, and it has
never been a show-stopper for me ... but now it is more painful.

The Linux kernel does not seem to differentiate between several of
the keys on the iBook (iceBook in this case) keyboard that are
differentiable on most platforms...  For instance (my current
problem), the left and right shift keys both return a left shift
keycode.  (Ditto for the command key, same keycode for both.)
Unfortunately I am in the situation of needing to set up an iBook for
a Russian user who is used to using a shift+shift chord to change
character sets (apparently this is quite common) ... since the iBook
produces the same keycode for both keys, there is no way to produce
this chord.  I can use a different method (for instance I currently
have her using the caps lock key to change mappings), but it isn't
what she is used to.

Is this a hardware limitation, or just a limitation of the current
maps?  If it is the latter, can it be easily fixed?  I'm willing to
provide whatever information is necessary if the problem is just that
the appropriate developer needs information about the iBook keyboard.

Thanks for your time,
Ethan
--
Now if I wasn't such a weenie do ya think you'd still love me,
Pretendin' I'm an airplane on the living room floor?
                -- The Offspring, "I Choose"

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

Is this a hardware limitation, or just a limitation of the current
maps?  If it is the latter, can it be easily fixed?  I'm willing to
provide whatever information is necessary if the problem is just that
the appropriate developer needs information about the iBook keyboard.

AFAIK, it's a HW limitation (or at least a limitation of the PMU's
firmware), there is no workaround I know about.

Ben.


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

"Benjamin Herrenschmidt" [off-list ref] writes:

quoted

Is this a hardware limitation, or just a limitation of the current
maps?  If it is the latter, can it be easily fixed?  I'm willing to
provide whatever information is necessary if the problem is just that
the appropriate developer needs information about the iBook keyboard.

AFAIK, it's a HW limitation (or at least a limitation of the PMU's
firmware), there is no workaround I know about.

The interesting thing is that was what was believed for years about
the locking capslock key as well...

jas.

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

On   3 Sep, this message from Jason E. Stewart echoed through cyberspace:

quoted

quoted

Is this a hardware limitation, or just a limitation of the current
maps?  If it is the latter, can it be easily fixed?  I'm willing to
provide whatever information is necessary if the problem is just that
the appropriate developer needs information about the iBook keyboard.

AFAIK, it's a HW limitation (or at least a limitation of the PMU's
firmware), there is no workaround I know about.

The interesting thing is that was what was believed for years about
the locking capslock key as well...

Ah, but that depends on the specific model of keyboard. At least some of
Apple's ADB keyboards _do_ indead have a mechanical capslock.

I don't know for USB keyboards, but obviously the PowerBook keyboards
have a regular (non-locking) key as capslock. Whether the lock is done
in the ADB driver or in the keyboard controller, I don't know...

Cheers

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


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

quoted

quoted

Is this a hardware limitation, or just a limitation of the current
maps?  If it is the latter, can it be easily fixed?  I'm willing to
provide whatever information is necessary if the problem is just that
the appropriate developer needs information about the iBook keyboard.

AFAIK, it's a HW limitation (or at least a limitation of the PMU's
firmware), there is no workaround I know about.

The interesting thing is that was what was believed for years about
the locking capslock key as well...

The locking capslock is in HW as well, there is a hack to turn capslock
into some different key, but it's really a hack.

Ben.


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

quoted

The interesting thing is that was what was believed for years about
the locking capslock key as well...

Ah, but that depends on the specific model of keyboard. At least some of
Apple's ADB keyboards _do_ indead have a mechanical capslock.

I don't know for USB keyboards, but obviously the PowerBook keyboards
have a regular (non-locking) key as capslock. Whether the lock is done
in the ADB driver or in the keyboard controller, I don't know...

Actually, the lock itself isn't, but the keycode sent by the PMU behave
like a HW lock (and the LED is driven that way too).

In both cases, there may be ways to instruct the PMU to behave differently
but I don't know about them.

Ben.


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

On   3 Sep, this message from Benjamin Herrenschmidt echoed through cyberspace:

quoted

quoted

The interesting thing is that was what was believed for years about
the locking capslock key as well...

Ah, but that depends on the specific model of keyboard. At least some of
Apple's ADB keyboards _do_ indead have a mechanical capslock.

I don't know for USB keyboards, but obviously the PowerBook keyboards
have a regular (non-locking) key as capslock. Whether the lock is done
in the ADB driver or in the keyboard controller, I don't know...

Actually, the lock itself isn't, but the keycode sent by the PMU behave
like a HW lock (and the LED is driven that way too).

In both cases, there may be ways to instruct the PMU to behave differently
but I don't know about them.

Anybody up for sucking the PMU firmware out of the little beast and
reverse-engineering it? Might be a fun project :-))

Cheers

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


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

Anybody up for sucking the PMU firmware out of the little beast and
reverse-engineering it? Might be a fun project :-))

Already beeing done, though I'll let the culprit tell about it
himself if he wants to ;)

Ben.


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

Michel Lanners wrote:

On   3 Sep, this message from Benjamin Herrenschmidt echoed through cyberspace:

quoted

quoted

quoted

The interesting thing is that was what was believed for years about
the locking capslock key as well...

Ah, but that depends on the specific model of keyboard. At least some of
Apple's ADB keyboards _do_ indead have a mechanical capslock.

I don't know for USB keyboards, but obviously the PowerBook keyboards
have a regular (non-locking) key as capslock. Whether the lock is done
in the ADB driver or in the keyboard controller, I don't know...

Actually, the lock itself isn't, but the keycode sent by the PMU behave
like a HW lock (and the LED is driven that way too).

In both cases, there may be ways to instruct the PMU to behave differently
but I don't know about them.

Anybody up for sucking the PMU firmware out of the little beast and
reverse-engineering it? Might be a fun project :-))

There's a little program for doing the "sucking" part of this available on
my page at penguinppc.org;  Apple was nice enough to include some commands
in the CPU<->PMU interface language for reading any part of the PMU memory.

The PMU is a Mitsubishi MCU; afaik, it's a M30624FGMGP, which is a member of the
M16C/62 family.  Mitsubishi's documentation pages have been much improved
lately; you can actually find the pdf's you need now :)

Reverse engineering something as big as this is quite a bit of work, though;
especially if you don't know which of the 88 i/o lines on the chip are
connected where ;)


Cheers,

Segher

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