This may be just a minor issue:
I had to use the setkeycodes utility to enable some extra keys (that weren't
mapped by kernel's atkbd tables).
After waking from sleep 1, those keys were reset. That is, I had to use
'setkeycodes' again to customize the tables again.
IMHO the way kernel works now is correct. It should *not* have extra code just
to handle that. Just make sure anybody that alters his kbd tables puts some
extra script to recover the tables after an ACPI wake.
This should be more like a note to Linux distributors.
Have a nice day.
On Sun, Jan 25, 2004 at 11:37:19AM +0200, P. Christeas wrote:
> This may be just a minor issue:
> I had to use the setkeycodes utility to enable some extra keys (that weren't
> mapped by kernel's atkbd tables).
> After waking from sleep 1, those keys were reset. That is, I had to use
> 'setkeycodes' again to customize the tables again.
>
> IMHO the way kernel works now is correct. It should *not* have extra code just
> to handle that. Just make sure anybody that alters his kbd tables puts some
> extra script to recover the tables after an ACPI wake.
> This should be more like a note to Linux distributors.
Hmm, I, on the other hand don't think it's correct. Because the kernel
has extra code to delete the tables on wake, which is wrong. Thanks for
noticing.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Sun, Jan 25, 2004 at 11:37:19AM +0200, P. Christeas wrote:
> This may be just a minor issue:
> I had to use the setkeycodes utility to enable some extra keys (that weren't
> mapped by kernel's atkbd tables).
> After waking from sleep 1, those keys were reset. That is, I had to use
> 'setkeycodes' again to customize the tables again.
>
> IMHO the way kernel works now is correct. It should *not* have extra code just
> to handle that. Just make sure anybody that alters his kbd tables puts some
> extra script to recover the tables after an ACPI wake.
> This should be more like a note to Linux distributors.
>
> Have a nice day.
Patch attached, please test. It'll make it into 2.6.3, with some luck
even 2.6.2.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
> Patch attached, please test. It'll make it into 2.6.3, with some luck
> even 2.6.2.
Your patch works fine for me. (shame that I had to reboot, though)
Many thanks for your time.
In article <[email protected]>,
P. Christeas <[email protected]> wrote:
| This may be just a minor issue:
| I had to use the setkeycodes utility to enable some extra keys (that weren't
| mapped by kernel's atkbd tables).
| After waking from sleep 1, those keys were reset. That is, I had to use
| 'setkeycodes' again to customize the tables again.
|
| IMHO the way kernel works now is correct. It should *not* have extra code just
| to handle that. Just make sure anybody that alters his kbd tables puts some
| extra script to recover the tables after an ACPI wake.
| This should be more like a note to Linux distributors.
I'm not totally sure I agree that the kernel should save this
information. With all the things the kernel does save, keyboard might be
a good thing. Consider someone with a REALLY hacked layout, like
modified dvorak or some of the keyboards for the access challenged. Now
think "can't use the keyboard enough to type in the ...ing commands to
do the load."
If we can carry the code for two competing disfunctional ACPI
implementations and a used-to-work but we broke it for some machines
APM, we can surely add a pair om memcpy lines to eliminate at least one
"oh-shit moment."
Obviously my opinion only, some breakage due to BIOS misfeatures,
contents may settle in shipping, etc.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.