RE: FYI: ACPI 'sleep 1' resets atkbd keycodes

[Yu, Luming]

> > > 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.

Do you need a event through /proc/acpi/event that can notify userland of
resuming happend,
And let userland app have chance to invoke setkeycode, and other similar
things.

> -	/*
> -	 * Here we probably should check if the keyboard has 
> the same set that
> -         * it had before and bail out if it's different. But 
> this will most likely
> -         * cause new keyboard device be created... and for 
> the user it will look
> -         * like keyboard is lost
> -	 */
> +	if (atkbd->set != old_set) {
> +		/*
> +		 * ok, we woke up with a different keyboard 
> attached. Alhtough we could just
> +		 * signal failure it's not very nice as it will 
> most likely cause new keyboard
> +		 * device be created... and for the user it 
> will look like keyboard is lost.
> +		 */
> +		atkbd_set_name(atkbd);

Is it correct to think if the keyboard has the different set that it
had before , then keyboard has been replaced, without considering
it could be changed by setkeycode.

--Luming
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/