2.6.0-test5 continues to have APM problems which earlier 2.6.0-test versions
had, which can be solved by booting 2.4.19.
A laptop has the following keys among others:
Fn+F2 = adjust screen brightness (100%->25%->50%->75%->100%)
Fn+F7 = suspend to disk (but see below)
Fn+F8 = adjust CPU speed (200MHz->50MHz->100MHz->200MHz)
Fn+F9 = display battery status on screen for 5 seconds
Fn+F10 = suspend to RAM (but see below)
If no APM driver is active, the BIOS performs all of those operations
itself. Suspend to disk uses a dedicated disk partition and turns off the
power. Suspend to RAM mostly turns off the power, the only way to turn it
back on is to push the power switch, but it does use the battery to refresh
RAM and could drain the battery in a few days if not plugged in.
If an APM driver is active then the BIOS only performs these actions by
itself:
Fn+F2 = adjust screen brightness (100%->25%->50%->75%->100%)
Fn+F8 = adjust CPU speed (200MHz->50MHz->100MHz->200MHz)
Fn+F9 = display battery status on screen for 5 seconds
These actions vary as follows:
Fn+F7 = user suspend, followed by BIOS action (see below)
Fn+F10 = user standby (but see below)
Fn+F7 gives the OS a chance to take some action, after which the BIOS still
saves state to a dedicated disk partition and turns off the power.
Fn+F10 is interpreted by Windows 95, 98, 2000, and XP as suspend to RAM,
even though 98 and 2000 and XP use the word standby for it, and their APM
drivers command the BIOS to do a suspend operation. Only Linux is
different, 2.4.19 commands the BIOS to do a standby operation, which can be
reawakened by actions such as pressing the keyboard's Shift key, but which
could drain the battery in hours if not plugged in (except when I modified
2.4.19 so it commands the BIOS to do a suspend to RAM).
Also if 2.4.19 is running then I can type the command "apm -s" to do a
suspend to RAM (or can type the command "apm -S" to do the power-hungry
version of standby).
If 2.6.0-test[1-5] is running then behavior is as follows:
Fn+F2 = no-op
Fn+F7 = no-op
Fn+F8 = no-op
Fn+F9 = no-op
Fn+F10 = no-op
Fortunately I can still type the command "apm -s" to do a suspend to RAM (or
can type the command "apm -S" to do the power-hungry version of standby).
Running with ACPI=OFF APM=DEBUG, I could confirm the messages that the APM
driver gets from the BIOS.
2.4.19:
Pull the power cord = power status change
Plug in the power cord = power status change
Fn+F2 = none, the BIOS acts by itself
Fn+F7 = user suspend (after which the BIOS acts)
Turn it back on = normal resume (oddly, no power status changes)
Fn+F8 = none, the BIOS acts by itself
Fn+F9 = none, the BIOS acts by itself
Fn+F10 = user standby (though I turned it into a suspend)
Turn it back on = normal resume (followed by two power status changes)
2.6.0-test5:
Pull the power cord = power status change
Plug in the power cord = power status change
Fn+F2 = none, and the BIOS takes no action
Fn+F7 = none, and the BIOS takes no action
Fn+F8 = none, and the BIOS takes no action
Fn+F9 = none, and the BIOS takes no action
Fn+F10 = none, and the BIOS takes no action
As mentioned above, commands "apm -s" and "apm -S" still work, though I
neglected to look at the debug messages. There is no way to force a suspend
to disk though, and no way to adjust the screen brightness etc.
The above complaints all concern either APM or the keyboard driver. I am
not sure if the 2.6.0 keyboard driver could be the reason why the BIOS no
longer even gets signals from the keyboard. I have never seen any other
situation where a keyboard's "Fn" key plus functional meaning of another key
could get broken, so I'm not sure if a broken keyboard driver could really
be this powerful. Otherwise the APM driver itself got b0rked between 2.4.19
and 2.6.0-test[1-5].
(ACPI is not an issue here. It is already known that if I omit ACPI=OFF
then the ACPI drivers will see just enough BIOS hooks so that they will act
as no-ops instead of unloading themselves, they will persuade the APM driver
to unload itself, and then I will have no power management whatsoever. In
2.6.0 I have configured the kernel build to omit ACPI entirely.)
From: "Norman Diamond" <[email protected]>
...
The above complaints all concern either APM or the keyboard driver. I am
not sure if the 2.6.0 keyboard driver could be the reason why the BIOS no
longer even gets signals from the keyboard. I have never seen any other
situation where a keyboard's "Fn" key plus functional meaning of another
key could get broken, so I'm not sure if a broken keyboard driver could
really be this powerful.
Some versions of 2.6 combined with some keyboard versions
will set the keyboard to scancode mode 3. Some (most? all?)
BIOSes expect translated scancode mode 2 and do not work
in any other mode.
So, in case you have scancode mode set 3, change that.
So far we have heard about precisely one keyboard in the world
where scancode mode 3 was useful. It is the Japanese keyboard
of John Bradford. He once wrote
> My keyboard has a distinct ID, and works fine in set 3,
Let me repeat the question:
John: What ID does this keyboard report?
Andries
> So far we have heard about precisely one keyboard in the world
> where scancode mode 3 was useful. It is the Japanese keyboard
> of John Bradford. He once wrote
>
> > My keyboard has a distinct ID, and works fine in set 3,
>
> Let me repeat the question:
> John: What ID does this keyboard report?
Sorry I didn't get back to you earlier about this.
It reports ab90.
Obviously at the moment it defaults to being used in set2, which works
as well in 2.6 as it does in 2.4 - the only problem is that the
language keys are indistinguishable from the space key.
Using set3 in 2.6 works, but not without a few problems.
I loaded a Japanese keyboard map, and most keys, (all the alphanumeric
keys), worked fine. A few symbols didn't, so I started to do some
observations with showkey to see what was going on.
(For anybody new to this discussion - I haven't used the Japanese
keyboard map up until now, because my keyboard emulates a US one when
in set2.)
The Yen key reports keycode 86. This is defined as less/greater in
the Japanese keyboard map I used.
Backslash/underscore reports keycode 43, which the keymap defines as
bracketright/braceright.
The actual bracketright/braceright key reports 84 on my keyboard,
whereas backslash/underscore in the keymap is defined for keycode 89.
Here are two more interesting problems, though:
Pressing any of the language keys reports nothing, but causes the next
keystroke to be lost.
Right alt and right control both generate keycode 100, and are both
interpreted as alt.
All of these problems should be easily fixable. The lost keystoke one
didn't happen last time I actually tested set3 in 2.5, (that was a
long time ago, though, around 2.5.40).
I'll get some more useful debug information later, but my serial
terminal is in need of repair at the moment :-(.
John.
> So far we have heard about precisely one keyboard in the world
> where scancode mode 3 was useful. It is the Japanese keyboard
> of John Bradford.
> John: What ID does this keyboard report?
Sorry I didn't get back to you earlier about this.
It reports ab90.
Thanks!
That is the ID that is said to belong to "old Japanese 'G' keyboards".
Using set3 in 2.6 works, but not without a few problems.
Pressing any of the language keys reports nothing, but causes the next
keystroke to be lost.
Yes, a phenomenon I discovered a few years ago.
Your language keys are muhenkan, zenkoho/henkan, hiragana
with scancodes 85, 86, 87 (untranslated Set 3).
A release produces f0 85, etc.
Now the translation operation turns this f0 into an OR of the first
following scancode byte that does not have the high bit set with 0x80.
That is reasonable in case of e0 escapes like e0 1d that are turned
into e0 9d. But it is unreasonable in a case like this. The effect
is that the following make code is turned into a break code, so that
no keystroke is seen.
Similar things happen with the Windows keys LWin, RWin, Menu.
This means that you do not want to use translated Set 3 - you need
untranslated Set 3. (Not that the kernel should untranslate - the
keyboard must not translate. Try the i8042_direct boot parameter.)
Right alt and right control both generate keycode 100, and are both
interpreted as alt.
RAlt: X(Set 2): e0 38, Set 2: e0 11, keycode2: 100, Set3: 39, keycode3: 100
RCtrl:X(Set 2): e0 1d, Set 2: e0 14, keycode2: 97, Set3: 58, keycode3: 100
This is a bug in the atkbd_set3_keycode[].
Of course one wants the keycodes to be independent of the current
scancode set. So, a diff for atkbd.c (line number might differ):
73c73
< 113,114, 40, 84, 26, 13, 87, 99,100, 54, 28, 27, 43, 84, 88, 70,
---
> 113,114, 40, 84, 26, 13, 87, 99, 97, 54, 28, 27, 43, 84, 88, 70,
The Yen key reports keycode 86. This is defined as less/greater in
the Japanese keyboard map I used.
Yen,| on your keyboard gives Set 3: 13, and that is converted into
keycode 86. Normally keycode 86 is used for Set 2: 61, X(Set 2): 56
a non-US key.
Normally Yen gives X(Set 2): 7d, Set 2: 6a, keycode 183.
Not good, not bad. Adapt the keymap used.
Backslash/underscore reports keycode 43, which the keymap defines as
bracketright/braceright.
Backslash/underscore on your keyboard gives Set 3: 5c, and that is
converted into keycode 43. Normally keycode 43 is used for Set 2: 5d,
X(Set 2): 2b, Set 3: 5c, the \| key.
Not good, not bad. Adapt the keymap used.
The actual bracketright/braceright key reports 84 on my keyboard,
whereas backslash/underscore in the keymap is defined for keycode 89.
Bracketright/braceright on your keyboard gives Set 3: 53, and that is
converted into keycode 84. Normally keycode 84 is returned in Set 2
for Alt+SysRq, while it is returned in Set 3 for both 53 and 5d.
That sounds like another bug in the kernel Set 3 keymap.
Neither 53 nor 5d are standard Set 3 scancodes.
I have no suggestion for correction - we must ask Vojtech why he
put down 84 here. In the meantime, be careful not to activate the
magic sysrq accidentally.
All of these problems should be easily fixable. The lost keystoke one
didn't happen last time I actually tested set3 in 2.5, (that was a
long time ago, though, around 2.5.40).
Yes. That time you used untranslated Set 3, this time translated Set 3.
I'll get some more useful debug information later, but my serial
terminal is in need of repair at the moment :-(.
Well, this was very useful. One ID and two kernel bugs.
Andries