[tlinux-users:08167] Re: New release of omnibook module soon: testing welcome

>> Mathieu... the problem still exists with this patch too.
>> After 5-6 minutes, laptop turn-on automatically.
>>
>>     
Sorry, I am seriously out of ideas. 
You can load the drivers with hotkeys=0 to see
if it's the reason of this behavior.
If not then it's quite strange as this is one of the
few features that do something upon module unloading.
>> Sep 15 17:15:04 mandachuva shutdown[3827]: shutting down for system halt
>> Sep 15 17:15:05 mandachuva gconfd (yamane-3701): SIGHUP received,
>> reloading all data bases.
>> Sep 15 17:15:05 mandachuva gconfd (yamane-3701): Address
>> "xml:readonly:/etc/opt/gnome/gconf/gconf.xml.mandatory" resolved for a
>> config supply with read-only permissions in position 0
>> Sep 15 17:15:05 mandachuva gconfd (yamane-3701): The address
>> "xml:readwrite:/home/yamane/.gconf" resolved for a config supply with
>> write permissions in position 1
>> Sep 15 17:15:05 mandachuva gconfd (yamane-3701): Address
>> "xml:readonly:/etc/opt/gnome/gconf/gconf.xml.defaults" resolved for a
>> config supply with read-only permissions in position 2
>> Sep 15 17:15:05 mandachuva gconfd (yamane-3701): GConf server is not in
>> use, shutdown.
>> Sep 15 17:15:05 mandachuva gconfd (yamane-3701): Finishing
>> Sep 15 17:15:05 mandachuva init: Switching to runlevel: 0
>>     
>
> I thing that the problem exists in this lines above (gconf), because
> when I unload omnibook before shutdown my laptop, this lines don't
> exists and log files show me this:
>
> Sep 15 15:59:46 mandachuva shutdown[5577]: shutting down for system halt
> Sep 15 15:59:47 mandachuva gconfd (yamane-3700): Received signal 15,
> shutdown correcty
> Sep 15 15:59:47 mandachuva gconfd (yamane-3700): Finishing
> Sep 15 15:59:47 mandachuva init: Switching to runlevel: 0
>
> See the diferences between first line ("shutting down for system halt")
> and the last line ("Switching to runlevel: 0") in this two log files above.
>   
I am 100% sure that gconf a nothing to do with that. I would
be more than surprised if you can reproduce this output.
" Address foo resolved for a config supply with read-only
permissions in position bar" is a known harmless gconf message.

Sorry to bother you again with this hotkeys issue but could you
try that hotkey.patch and do the usual kernel logs / xev test.

--
Mathieu Bérard

--- trunk/nbsmi.c	2006-09-17 00:41:08.451479899 +0200
+++ exp/nbsmi.c	2006-09-17 01:13:29.082418015 +0200
@@ -539,6 +539,9 @@
 	data |= (state & HKEY_STICK) ? SMI_STICK_KEYS_MASK : 0;
 	data |= (state & HKEY_TWICE_LOCK) ? SMI_FN_TWICE_LOCK_MASK : 0;
 	data |= (state & HKEY_DOCK) ? SMI_FN_DOCK_MASK : 0;
+	/* ugly quirk */
+	if(!state)
+		data = 0x19;
 
 	retval = nbsmi_smi_write_command(&hotkeys_op, data);
 	if (retval < 0)