Laptop Dell Latitude D600

From YobiWiki
Revision as of 23:33, 17 November 2006 by <bdi>PhilippeTeuwen</bdi> (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

sites

modprobe i8k force=1

cf http://people.debian.org/~dz/i8k

cat /proc/i8k

Pour activer la sortie TV

atitvout pal
atitvout -f t (pour la sorite S-video, TV)
atitvout -f l (pour remettre le LCD)
atitvout -f c (pour le CRT, à tester)
atitvout -f detect

Il faut avoir booté avec la TV branchée sinon ça ne fonctionne pas.

Suspend-to-RAM

cf http://www.loria.fr/~thome/d600/

Ces notes sont tirées de mon expérience et d'un échange de mails avec Emmanuel Thomé.

J'ai utilisé un kernel 2.6.12-4 Debian et ai donc adapté qqs éléments:
J'ai utilisé le s3_late_bios_new.patch.gz
Si vous essayez s3_late_bios_radeon_new.patch, attention, tel quel il injecte le code dans la fonction radeonfb_pci_suspend au lieu de radeonfb_pci_resume!
Il faut le bootparam acpi_sleep=s3_late_bios
Voilà, le suspend-to-RAM fonctionne.
Et cela fonctionne aussi depuis X (version 4.3.0.1 Debian), en effet depuis la version 4.3.0.dfsg.1 un patch d'Emmanuel Thomé et Ole Rohne a été intégré (Closes: #234575)
Petit bémol: Il faut lors du resume appuyer sur une touche sinon il reste inactif qqpart entre le réveil du PCMCIA (Yenta) et le réveil du mini-PCI

Framebuffer

J'ai tout essayé, en vain, pas moyen d'avoir un fb actif qui ne foire pas au resume après le suspend.
Le symptome est toujours le meme: le PC est gelé, l'écran reste éteint.
Juste pour info j'ai essayé les bootparams video=radeonfb:off video=vesafb; video=vesafb:off video=radeonfb; acpi_sleep=s3_late_bios,s3_late_mode
Rien à faire, dès qu'il y a un vga=791 pour activer le fb, le resume plante.

Radeontool

Le radeontool fonctionne parfaitement (éteint l'écran)
Apparemment le dernier xorg (6.8.2) semble avoir appris à faire power-off sur ces cartes video-là ; en tout cas xset dpms force off éteint la lumière, c'est pas mal. Pour info seulement, car un outil non-x comme radeontool a son intérêt de toute façon.
Sur mon XFree version 4.3.0.dfsg.1-14 (Debian) xset dpms force off fonctionne aussi.

Qqs devices récalcitrants

  • Le module de la carte réseau tg3 est déchargé avant resume et rechargé après.
  • Le touchpad et le petit joystick ne fonctionnaient plus après un resume mais bien une souris externe USB (l'USB se réveille correctement et ses éléments sont redécouverts)
    En compilant psmouse en module et en le déchargeant avant resume et rechargeant après cela fonctionne.
    Apparemment c'est un problème connu dans les versions courantes 2.6.11 et 2.6.12, cf les bugreports Redhat #160733 et #161546
  • Le key-repeat du clavier posait problème après un resume.
    Il semble que cela va mieux en mettant atkbd en module mais il ne fait pas le décharger sinon plus moyen d'aider le resume en pressant une touche!
    Pour pouvoir mettre atkbd en module:
    General setup -> Configure standard kernel features
    Device Drivers -> Input device support -> Keyboards -> AT keyboard
    (rem: i8042 pourrait aussi etre mis en module)

ACPI handler

/etc/acpi/actions/acpi_handler.pl a été fortement adapté suite à ces remarques et aux particularités de la Debian:

  • Debian ignore les fichiers avec un "." dans /etc/acpi/events, j'ai donc renommé trap_all.conf en trap_all
  • reloader les modules tels tg3 et psmouse au resume
  • appeler les scripts /etc/init.d/xxx start/stop car il n'y a pas de /sbin/service sur Debian
  • changer /proc/acpi/wakeup_devices par /proc/acpi/wakeup
    Apparemment le nom a changé et il n'y a plus besoin de patch pour l'avoir.
  • enlever updfstab qui n'existe pas sur Debian.
  • ajouter un test sur la présence du bootparam acpi_sleep=s3_late_bios pour éviter les crashes si on boot sur un autre kernel.

Les logs iront dans /var/log/acpid

Todo

J'ai trouve l'erreur suivante lors de chaque resume dans les logs kernel:

Stopping tasks: ========================================|
Back to C!
Debug: sleeping function called from invalid context at mm/slab.c:2093
in_atomic():0, irqs_disabled():1
 [__might_sleep+166/176] __might_sleep+0xa6/0xb0
 [kmem_cache_alloc+109/112] kmem_cache_alloc+0x6d/0x70
 [acpi_pci_link_set+72/417] acpi_pci_link_set+0x48/0x1a1
 [acpi_pci_link_resume+28/34] acpi_pci_link_resume+0x1c/0x22
 [irqrouter_resume+27/48] irqrouter_resume+0x1b/0x30
 [irqrouter_resume+0/48] irqrouter_resume+0x0/0x30
 [sysdev_resume+259/264] sysdev_resume+0x103/0x108
 [device_power_up+5/10] device_power_up+0x5/0xa
 [suspend_enter+54/96] suspend_enter+0x36/0x60
 [enter_state+70/112] enter_state+0x46/0x70
 [acpi_suspend+42/59] acpi_suspend+0x2a/0x3b
 [copy_from_user+108/176] copy_from_user+0x6c/0xb0
 [acpi_system_write_sleep+105/125] acpi_system_write_sleep+0x69/0x7d
 [vfs_write+229/352] vfs_write+0xe5/0x160
 [sys_write+81/128] sys_write+0x51/0x80
 [syscall_call+7/11] syscall_call+0x7/0xb

Visiblement c'est facile de faire disparaitre le warning mais ce n'est pas de la tarte pour faire ça proprement.
On peut espérer que ce soit résolu après 2.6.13-rc5, cf le thread http://bugzilla.kernel.org/show_bug.cgi?id=3469
Comme dit Emmanuel: Ce qui constituerait une raison pour rester calme et attendre de voir que ça se stabilise un peu ; ça n'a pas toujours été comme ça, c'est pas tous les jours qu'on farfouille dans le code du routeur d'irq, encore heureux.
Si ça va dans la direction d'un assainissement de la situation, j'ose
espérer qu'on pourra en conclure que l'ensemble des manips à faire pour que le S3 marche se restreint ; Patience donc.

En résumé

Pour un kernel 2.6.12-4 Debian:

Modem

  • Installer ALSA pour Intel8x0
  • apt-get install sl-modem-daemon

Multimedia keys

  • apt-get install lineakd lineak-defaultplugin lineak-kdeplugins lineak-xosdplugin
  • (as user) lineakd -c DELL-D600
  • edit ~/.lineak/lineakd.conf
AudioLowerVolume = KMIX_VOLDOWN
AudioMute = KMIX_MUTE
AudioRaiseVolume = KMIX_VOLUP
  • To launch the daemon at each KDE login:
    • Create /home/<user>/.kde/Autostart/lineak.desktop with the following content:
[Desktop Entry]
Name=Start Lineakd
Exec=/usr/bin/lineakd
Type=Application
Terminal=0

But we have extra keys: cdrom eject, wifi, battery. Try while

tail -f /var/log/messages
  • battery:
atkbd.c: Unknown key pressed (translated set 2, code 0x87 on isa0060/serio0).
atkbd.c: Use 'setkeycodes e007 <keycode>' to make it known.
  • wifi:
atkbd.c: Unknown key pressed (translated set 2, code 0x88 on isa0060/serio0).
atkbd.c: Use 'setkeycodes e008 <keycode>' to make it known.
  • eject:
atkbd.c: Unknown key pressed (translated set 2, code 0x89 on isa0060/serio0).
atkbd.c: Use 'setkeycodes e009 <keycode>' to make it known.
evtest
  • battery:
Event: time.270011, type 4 (?), code 4 (?), value 135
  • wifi:
Event: time.930135, type 4 (?), code 4 (?), value 136
  • eject:
Event: time.374029, type 4 (?), code 4 (?), value 137

You should try for keycode ideas, apparently works better if < 127 (but > 83)
Check if keycodes you attend to bind to those scancodes are not yet used:

for ((i=80;i<256;i++));do getkeycodes|grep -q $i || echo -n "$i ";done

Then assign them:

setkeycodes e008 123 e009 122

Then check what is the corresponding code with xev
If xev doesn't react or produces uninterrupted output, try another keycode
Those are working for me
122->209
123->210

I could not get one more free keycode working properly so I reused 125 for e007 which was already used by e05B, so far it seems ok.

I added the bindings to /etc/init.d/bootmisc.sh

# Add some scancode bindings for keys eject,wifi and battery
setkeycodes e007 125 e008 123 e009 122

Create ~/.lineak/lineakkb.def

[DELL-D600]
 brandname = "Dell"
 modelname = "D600"
 [KEYS]
   AudioLowerVolume = 174
   AudioRaiseVolume = 176
   AudioMute        = 160
   Eject            = 209 # keycode 122
   # Battery          = cannot find another free keycode working fine
   Wireless         = 210 # keycode 123
 [END KEYS]
[END DELL-D600]

And now we can augment our ~/.lineak/lineakd.conf

Eject = EAK_OPEN_TRAY
Wireless = sudo ifup eth;sudo kwifimanager
# Battery =

Interesting links: