First of all you need to select the way you want to boot the slackware setup process. You can make a minimal boot cd, boot USB starting from slackware sources, or you can download the minimal boot CD¹⁾ I've prepared for my setup. Boot from the CD, partition the HDD, prepare / and swap partition, etc… you know all that

The kernel supplied with standard Slackware kernel package lacks support for some peripherals, so the first thing you've to do is to recompile a new, well suited kernel for your laptop
Some of the drivers needed to enable peripherals support are experimental and need enabling the support of development code.

Code maturity level options --->
     [*] Prompt for development and/or incomplete code/drivers

First thing I've to select was the processor. Unluckily there are no options linked to Celeron M 430. The most relevant selection is, IMHO, Pentium-4/Celeron(P4-Based)/Pentium-4 M/older Xeon

Processor type and features  --->
    Processor family ()  --->
        (X) Pentium-4/Celeron(P4-Based)/Pentium-4 M/older Xeon
    
    [X] Local APIC support on uniprocessors
    [X]   IO-APIC support on uniprocessors

    <M> /dev/cpu/*/msr - Model-specific register support
    <M> /dev/cpu/*/cpuid < CéU information support

    [*] MTRR (Memory Type Range Register) support        

: Non sono certo che sia corretto…

This laptop embed an Intel SATA Controller:

lspci | grep SATA:

00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02)

SATA controllers (and devices) are, at least in kernel families 2.6.21 & 2.6.22, virtualized to SCSI devices, so 'SCSI Disk support' is also needed in order to enable /dev/sda devices.
To avoid conflict between SATA and “generic/default IDE chipset support” drivers, these cannot be compiled into the kernel, and can at least be included as a module.

Device Drivers  --->
     <*> ATA/ATAPI/MFM/RLL support  --->
             <M>     generic/default IDE chipset support
         SCSI device support  --->
             [*] legacy /proc/scsi/ support
             --- SCSI support type (disk, tape, CD-ROM)
             <*> SCSI disk support
     <*> Serial ATA (prod) and Parallel ATA (experimental) drivers  --->
             <*>   AHCI SATA support
             <*>   Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support
             <M>   Generic ATA support 

Tools used for hardware sensors monitoring are included into lm_sensors package (lm_sensors-2.10.3-i486-1 for Slackware 12).
As any other device, sensor must be enabled from the kernel side before we can start use them successfully…

#: sensors-detect

# sensors-detect revision 4348 (2007-03-18 02:45:21 -0700)

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

We can start with probing for (PCI) I2C or SMBus adapters.
Do you want to probe now? (YES/no): Y

Probing for PCI bus adapters...
Use driver `i2c-i801' for device 0000:00:1f.3: Intel 82801G ICH7

We will now try to load each adapter module in turn.
Module `i2c-i801' already loaded.
If you have undetectable or unsupported adapters, you can have them
scanned by manually loading the modules before running this script.

To continue, we need module `i2c-dev' to be loaded.
Do you want to load `i2c-dev' now? (YES/no): Y

Module loaded successfully.

We are now going to do the I2C/SMBus adapter probings. Some chips may
be double detected; we choose the one with the highest confidence
value in that case.
If you found that the adapter hung after probing a certain address,
you can specify that address to remain unprobed.

Next adapter: SMBus I801 adapter at 5420 (i2c-0)
Do you want to scan it? (YES/no/selectively): Y

Client found at address 0x44
Probing for `Maxim MAX6633/MAX6634/MAX6635'...              No
Client found at address 0x52
Probing for `Analog Devices ADM1033'...                     No
Probing for `Analog Devices ADM1034'...                     No
Probing for `SPD EEPROM'...                                 Success!
    (confidence 8, driver `eeprom')

Some chips are also accessible through the ISA I/O ports. We have to
write to arbitrary I/O ports to probe them. This is usually safe though.
Yes, you do have ISA I/O ports even if you do not have any ISA slots!
Do you want to scan the ISA I/O ports? (YES/no):  Y

Probing for `National Semiconductor LM78' at 0x290...       No
Probing for `National Semiconductor LM78-J' at 0x290...     No
Probing for `National Semiconductor LM79' at 0x290...       No
Probing for `Winbond W83781D' at 0x290...                   No
Probing for `Winbond W83782D' at 0x290...                   No
Probing for `Silicon Integrated Systems SIS5595'...         No
Probing for `VIA VT82C686 Integrated Sensors'...            No
Probing for `VIA VT8231 Integrated Sensors'...              No
Probing for `IPMI BMC KCS' at 0xca0...                      No
Probing for `IPMI BMC SMIC' at 0xca8...                     No

Some Super I/O chips may also contain sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): Y

Probing for Super-I/O at 0x2e/0x2f
Trying family `ITE'...                                      No
Trying family `National Semiconductor'...                   No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Fintek'...                       No
Probing for Super-I/O at 0x4e/0x4f
Trying family `ITE'...                                      No
Trying family `National Semiconductor'...                   No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Fintek'...                       No

Some CPUs or memory controllers may also contain embedded sensors.
Do you want to scan for them? (YES/no): Y

AMD K8 thermal sensors...                                   No
Intel Core family thermal sensor...                         Success!
    (driver `coretemp')
Intel AMB FB-DIMM thermal sensor...                         No

Now follows a summary of the probes I have just done.
Just press ENTER to continue:


Driver `eeprom' (should be inserted):
  Detects correctly:
  * Bus `SMBus I801 adapter at 5420'
    Busdriver `i2c-i801', I2C address 0x52
    Chip `SPD EEPROM' (confidence: 8)

  EEPROMs are *NOT* sensors! They are data storage chips commonly
  found on memory modules (SPD), in monitors (EDID), or in some
  laptops, for example.

Driver `coretemp' (should be inserted):
  Detects correctly:
  * Chip `Intel Core family thermal sensor' (confidence: 9)

I will now generate the commands needed to load the required modules.
Just press ENTER to continue:


To make the sensors modules behave correctly, add these lines to
/etc/modules.conf:

#----cut here----
# I2C module options
alias char-major-89 i2c-dev
#----cut here----

To load everything that is needed, add this to some /etc/rc* file:

#----cut here----
# I2C adapter drivers
modprobe i2c-i801
# Chip drivers
modprobe eeprom
modprobe coretemp
# sleep 2 # optional
/usr/bin/sensors -s # recommended
#----cut here----

If you have some drivers built into your kernel, the list above will
contain too many modules. Skip the appropriate ones! You really
should try these commands right now to make sure everything is  
working properly. Monitoring programs won't work until the needed
modules are loaded.

Do you want to generate /etc/sysconfig/lm_sensors? (yes/NO): N

Unluckily the kernel subsystem for hardware monitoring is not able to detect any motherboard or SuperIo sensor device. There are some rumors saying that there is a : indicare il produttore WinBond ?? PC87951 chip. (Hw Monitor, a monitoring tool for Windows detect PC87951 as main sensor device, but is not able to read any values from it).
: Indicare le fonti di lm_sensors che dicono che non si puo' interrogare perchè è un custom programmable chip.

After drivers compilation we can modify /etc/rc.d/rc.modules to include the modprobe lines stated above. We can safely skip /etc/modules.conf stuff because superseeded by udev script shipped with Slackware 12.
: Verificare che chi si preoccupa di caricare i2c_dev sia realmente udev.

Device Drivers --->
        Character devices --->
            IPMI --->
                <M> IPMI top-level message handler
                [*]   Generate a panic event to all BMCs on a panic
                [*]     Generate OEM events containing the panic string
                <M>   Device interface for IPMI
                <M>   IPMI System Interface handler
                <M>   IPMI Watchdog Timer
                <M>   IPMI Poweroff
    <M> I2C support  --->
         --- I2C support
         <M>   I2C device interface
               I2C Algorithms  --->
                   --- I2C bit-banging interfaces
                   <M> I2C PCF 8584 interfaces
                   <M> I2C PCA 9564 interfaces
               I2C Hardware Bus support  --->
                   <M> Intel 82801 (ICH)
               Miscellaneous I2C Chip support  --->
                   <M> EEPROM reader
    <M> Hardware Monitoring support  --->
         <M>   Intel Core (2) Duo/Solo temperature sensor              

First enable the embedded pci sound card in the kernel:

Device Drivers --->
    Sound --->
        <M> Sound card support
            Advanced Linux Sound Architecture --->
                <M> Advanced Linux Sound Architecture
                <M>   Sequencer support
                <M>   OSS Mixer API
                <M>   OSS PCM (digital audio) API
                [*]     OSS PCM (digital audio) API - Include plugin system
                [*]   OSS Sequencer API
                <M>   RTC Timer support
                [*]     Use RTC as default sequencer timer
                [*]   Support old ALSA API  
                      PCI devices --->
                          <M> Intel HD Audio 

Once built, the needed modules will load automagically during startup.

$ aplay -l

**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC883 Analog [ALC883 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

We also need to setup mixer values via alsamixer utility and save them with alsactl store command to make them persistent.

: Scrivere parte sul framebuffer all'avvio (nel kernel)

Device Drivers
  Graphics Support -->
     [*] Support Frame Buffer Devices
     <*> Intel 830M ... (Experimental)

The release of Slackware installed contains X.Org 7.1 X11 implementation, and is configured to use the framebuffer capabilities of VESA graphic cards.
This laptop is equipped with an Intel 945GM video card, capable to use (share) : 8 to 256 MB of main system RAM. The TFT LCD panel comes into the , so-common-today, form factor of 16:10, with a native resolution of 1280×800 pixel. This specific resolution is not configured into default X Window Slackware configuration, mainly because 1280×800 is not an allowed resolution for VESA standard.
First I'd to make i915 and drm modules from the kernel:

Processor type and features
  [*] MTRR (Memory Type Range Register) support 
Device Drivers
  Character devices  --->
   <M> /dev/agpgart (AGP Support)
   ---   Intel 440LX/BX/GX, I8xx and E7x05 chipset support 
   <M>   Intel 830M, 845G, 852GM, 855GM, 865G                       │ │
      <M>     i915 driver (XFree86 4.1.0 and higher DRI support)

Following there are striped down versions of the Sections I've managed to change into my xorg.conf file: : Verificare come mai mancano ipermessi 0666 su dga

Section "Module"
    Load    "dbe"   # Double buffer extension
    Load    "extmod"
    Load    "record"
    Load    "xtrap"
    Load    "dri"
    Load    "glx"

    SubSection  "extmod"
      Option    "omit xfree86-dga"   # don't initialise the DGA extension
    EndSubSection

    Load        "type1"
    Load        "freetype"
EndSection

Section "Monitor"
    Identifier  "TFT LCD"
    Option      "DPMS"
EndSection

Section "Device"
    Identifier  "SchedaVideo"
    Driver      "i810"

    Option      "XAANoOffscreenPixmaps" "true"
    Option      "RenderAccel" "true"
    Option      "DRI"   "true"
    Option      "NoAccel"   "false"
    Option      "DDC"   "false"
    VendorName  "Intel Corporation"
#    BoardName   "829145GM Integrated Graphics Device"
#    BusID       "PCI:0:2:0"
#    VideoRam    65536
EndSection

: Verificare il comportamento delle altre risoluzioni indicate

Section "Screen"
    Identifier  "Screen 1"
    Device      "SchedaVideo"
    Monitor     "TFT LCD"

    DefaultDepth 24

    Subsection "Display"
        Depth       8
        Modes "1280x800" "1024x768" "800x600" "640x480"
        ViewPort 0 0
    EndSubsection
    Subsection "Display"
        Depth       16
        Modes "1280x800" "1024x768" "800x600" "640x480"
        ViewPort 0 0
    EndSubsection
    Subsection "Display"
        Depth       24
        Modes "1280x800" "1024x768" "800x600" "640x480"
        ViewPort 0 0
    EndSubsection
    Subsection "Display"
        Depth       32
        Modes "1280x800" "1024x768" "800x600" "640x480"
        ViewPort 0 0
    EndSubsection
EndSection

Section "ServerLayout"
    Identifier  "Simple Layout"

    Screen "Screen 1"
    InputDevice "Mouse1" "CorePointer"
    InputDevice "Keyboard1" "CoreKeyboard"

EndSection

No changes are requested for Sections: File :Scrivere l'elenco delle sezioni non modificate : Fare una nuova pagina Other XOrg.conf personalizations in cui raccolgo le altre personalizzazioni (Layout tastiera, repeat rate, etc)

This is the result from lspci:

06:01.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)

So we have to use the b44 kernel module:

Device Drivers --->
     Network device support --->
          [*] Network device support
              Ethernet (10 or 100Mbit) -->
                   [*] EISA, VLB, PCI and on board controllers
                   <M>   Broadcom 4400 ethernet support

First I've tried to find out the wifi card installed:

# lspci
...
05:00.0 Ethernet controller: Atheros Communications, Inc. AR5006EG 802.11 b/g Wireless PCI Express Adapter (rev 01)
...

Hmmm this card is not supported natively by the kernel, altough looking the web I've found a free “quasi-opensource” Linux kernel driver developed to support Atheros-based wireless LAN devices named madwifi (Mulktiband Atheros Driver for WiFi). I called it “quasi-opensource” because this software is composed by some different modules, and one of them is not (cannot) be released as opensouce in order to comply with FCC regulations. Here are there are more details taken directly from madwifi README

The ath_hal module contains the Atheros Hardware Access Layer (HAL).
This code manages much of the chip-specific operation of the driver.
The HAL is provided in a binary-only form in order to comply with FCC
regulations. In particular, a radio transmitter can only be operated at
power levels and on frequency channels for which it is approved. The
FCC requires that a software-defined radio cannot be configured by the
user to operate outside the approved power levels and frequency
channels. This makes it difficult to open-source code that enforces
limits on the power levels, frequency channels and other parameters of
the radio transmitter. See
http://ftp.fcc.gov/Bureaus/Engineering_Technology/Orders/2001/fcc01264.pdf
for the specific FCC regulation. Because the module is provided in a
binary-only form it is marked “Proprietary”; this means when you load it
you will see messages that your system is now “tainted”.

A detailed discussion of the pros and cons of this design can be found
at http://madwifi.org/wiki/HAL

Looking at compatibility page we can see that our chipset is supported by this driver:

So I downloaded (compiled and tried) this: madwifi-0.9.3.2.tar.bz2 then this: madwifi-ng-current.tar.gz (madwifi-ng-r2702-20070903) then this: madwifi-ng-r2598-20070725 and: madwifi-0.9.3.1.tar.bz2, madwifi-dfs-current.tar.gz, madwifi-hal-0.9.30.13-current.tar.gz, madwifi-trunk-current.tar.gz, dadwifi-current.tar.gz (I leaved out madwifi-old-openhal-current.tar.gz beacuse openhal support seems to be pretty old and not very stable…)

All that I've obtained was this (every first attempt to load the driver):

# modprobe ath_pci
# dmesg
ath_hal: module license 'Proprietary' taints kernel.
ath_hal: 0.9.30.13 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133)
wlan: 0.8.4.2 (0.9.3.2)
ath_pci: 0.9.4.5 (0.9.3.2)
ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 19 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:05:00.0 to 64
wifi%d: unable to attach hardware: 'Hardware revision not supported' (HAL status 13)
ACPI: PCI interrupt for device 0000:05:00.0 disabled

and this (every next attempt to load it):

ACPI: PCI interrupt for device 0000:05:00.0 disabled
ath_pci: driver unloaded
ath_pci: 0.9.4.5 (0.9.3.2)
PCI: Enabling device 0000:05:00.0 (0000 -> 0002)
ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 19 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:05:00.0 to 64
wifi%d: unable to attach hardware: 'Hardware didn't respond as expected' (HAL status 3)
ACPI: PCI interrupt for device 0000:05:00.0 disabled

I've tried different revisions of binary HAL (0.9.30.13, 0.9.18.0, …) and then I've decided to leave this driver on his own and try with the “good ol' solution”: ndiswrapper

Googling the web for the correct PCI Vendor, Device, Subvendor, Subdevice sequence (168C:001C:1468:0428) I've found that the chip embedded into this laptop is not the detected AR5006EG but it is AR5BXB63²⁾. This make much more sense to error messages given from madwifi, as stated by the madwifi compatibility details for this chip:

.inf file in windows:
%ATHER.DeviceDesc.3067%  = ATHER_DEV_04281468.ndi, PCI\VEN_168C&DEV_001C&SUBSYS_04281468 //References to this Device, Look ATHER_DEV_04281468.ndi ,an curiosity look DeviceDesc, = 3067
...
[ATHER_DEV_04281468.ndi.NT]  //more parameters referencing this device
Characteristics = 0x84 ; NCF_PHYSICAL | NCF_HAS_UI
BusType         = 5
DelReg          = 5211.DelReg
AddReg          = 5211.reg, ATHER.reg, 5211.reg, 5212.abgmp.reg, customer3a.reg, ATHER_DEV_04281468.ID.REG
CopyFiles       = ATHER.CopyFiles.nt, DEFAULTDESTDIRS
DelFiles        = ATHER.DelIniFiles
//and the end of file we have
ATHER.DeviceDesc.3067  = "Atheros AR5007EG Wireless Network Adapter" // look that DeviceDesc.3067 references to  AR5007EG.!!????

Notes: It's returns Hal status 13, and sometimes hal status 3
Notes: In Openhal the interface ath0 show up there aren't any communication, the commands like iwlist return error.

ndiswrapper is a linux kernel module that loads and runs NDIS (Windows network driver API) drivers supplied by the vendors.

To make things to work you ve to downloaded the latest version of the ndiswrapper sources from :here and extract them with the command

  tar zxvf ndiswrapper-version.tar.gz

This will create ndiswrapper-version directory. Change to that directory and run

  make uninstall
  make

Login as root and run:

  make install

Now you need to install Windows driver for Windows XP (in some cases Windows NT or Windows 2000 may also work). First, get a Windows driver that is known to work. I've used the driver released by Acer at the support page of the ASPIRE 5100³⁾ (mirror). I've not used the driver at the support page of the TM2490 (mirror) because it's an older version.

Wireless_Atheros_V5.3.0.67_XP_XB63_XB62(WHQL) - ASPIRE 5100 driver
Notes.txt:

2007/08/08 Wrote by Kidd Wang.
T60H976.00 XB63 Released for xp-32/64bits:
1.WHQL driver v5.3.0.67.(Negative-Pole LED)
Silent insatllation: c:\Atheros-driver\setup /s or double click this file(SilentInstall.bat).
2.Update to IS12 to fix unclean remove oem*.inf issue.
3.NDIS: Increase WOW keep alive threshold from 16 to 255.
4.NDIS: Fixed BSOD when switching HW radio on\off.

Wireless Lan Driver 802bg Atheros XB63 Ver 5.3.0.35 - Travelmate 2490
Notes.txt:

2007/04/23
T60H976.00 XB63 Released for 2k/xp-32bits:
1.WHQL'd driver v5.3.0.35.(Negative-Pole LED)
Silent insatllation: c:\Atheros-driver\setup /s or double click this file “SilentInstall.bat”
2.NDIS: Driver access register bits beyond its limit for AR2425 only causing a BSOD.
3 NDIS: Driver must support WEP as WPA/2 broadcast key.
4.NDIS: Corrected disable 11a mode for adhoc only in DFS bands.
5.NDIS: Disable super mode for AR2417 and AR2425 which do not support it even if EEPROM has the super mode bits set.
6.Update to IS12 to fix unclean remove oem*.inf issue.

Now we can install the Windows driver with

ndiswrapper -i driver.inf

This installs .inf file and required .sys and .bin files. We can see if installation of Windows driver is “valid” with

ndiswrapper -l

This would report

net5211 : driver installed
        device (168C:001C) present (alternate driver: ath_pci)

IMHO ndiswrapper has a bug in the perl script that is used to parse device Vendor:Device:SubVendor:SubDevice PCI string. In fact I think that the correct result for “ndiswrapper -l” should be:

net5211 : driver installed
        device (168C:001C) present (alternate driver: ath_pci)
        device (168C:001C:1468:0428) present (alternate driver: ath_pci)

In any case it seems that this bug affects only the perl script, not the kernel module.

Now load ndiswrapper module with

modprobe ndiswrapper

If everything worked properly, this should initialize 'wlan0' wireless device, which can be configured with wireless tools, such as 'iwconfig', 'wpa_supplicant' etc.

ndiswrapper version 1.47 loaded (smp=no)
ndiswrapper: driver net5211 (,07/26/2007,5.3.0.67) loaded
ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 19 (level, low) -> IRQ 19
ndiswrapper (ZwClose:2246): closing handle 0xdfd05aa8 not implemented
PCI: Setting latency timer of device 0000:05:00.0 to 64
ndiswrapper: using IRQ 19
wlan0: ethernet device 00:19:7e:09:ae:86 using serialized NDIS driver: net5211, version: 0x50003, NDIS version: 0x501, vendor: 'NDIS Network Adapter', 168C:001C:0428:1468.5.conf
wlan0: encryption modes supported: WEP; TKIP with WPA, WPA2, WPA2PSK; AES/CCMP with WPA, WPA2, WPA2PSK
ADDRCONF(NETDEV_UP): wlan0: link is not ready
usbcore: registered new interface driver ndiswrapper

In order to use advanced controls available through the ACPI interface we have to include ACPI support into the kernel. The package : Nome corretto package acpid must also be installed.

Linux Kernel Configuration: ACPI 
     Power management options (ACPI, APM) --->
       [*] Power Management support
       [*] Software Suspend
       (/dev/sda5) Default resume partition
          ACPI (Advanced Configuration and Power Interface) Support --->
               [*] ACPI Support
               [*]   Sleep States
               [ ]     /proc/acpi/sleep (deprecated)
               [*]   Procfs interface (deprecated)
               <M>   AC Adapter
               <M>   Battery
               <M>   Button
               <M>   Video
               <M>   Fan
               <M>   Processor
               <M>     Thermal Zone
               < >   ASUS/Medion Laptop Extras
               < >   IBM ThinkPad Laptop Extras
               < >   Toshiba Laptop Extras
               (0)   Disable ACPI for systems before Jan 1st this year
               [ ]   Debug Statements

: Verificare se il supporto ACPI funziona anche in mancanza dell'opzione Procfs interface (ma ne dubito perchè a vedere il manfile di acpid viene usato da quest'ultimo) In order to scale cpu frequency p4clockmod module & cpufreqd package are essential.

: Tutto il discorso Thermal zones e throttling è da verificare… Sembra che il throttling funzioni: via acpi rileva il cambiamento… pero' dimostrare che effettivamente la CPU stia rallentando è diversa cosa… bisognere fare dei test tipo con i tool di stress CPU Thermal Zones are *NOT* working. However the fan does switch off when unused, and does switch on when compilation or other things which demand CPU's power are in progress - I assume this is done by the BIOS, so damage of CPU due to overheating is not likely. Linux just doesn't have the information on thermal zones. Battery indicators are working fine when ACPI is compiled into kernel. You just have to install acpid package.

Now we had to modify /etc/rc.d/rc.modules in order to load ACPI kernel modules at startup:

#### APM support ###
# APM is a BIOS specification for saving power using several different
# techniques.  This is mostly useful for battery powered laptops.
# Note that kernels newer than 2.6 will use ACPI (Advanced Configuration
# and Power Interface) rather than APM, and do not have an APM module.
# If a kernel supports ACPI it will always be built in, not a module.
#if echo $SHORTREL | grep -qw 2.4 ; then
#  /sbin/modprobe apm
#fi
/sbin/modprobe ac
/sbin/modprobe battery
/sbin/modprobe button
/sbin/modprobe fan
/sbin/modprobe processor
/sbin/modprobe thermal
/sbin/modprobe video

Furhter exploring of the ACPI support of this laptop revealed that the DSDT included into BIOS is broken, and is not fully ACPI compliant.
In fact DSDT's disassembly, obtained using iast (:Acronimo e link) cannot be recompiled because there are some errors:

# ./iasl -dc dsdt

Intel ACPI Component Architecture
AML Disassembler version 20061109 [Jul 30 2007]
Copyright (C) 2000 - 2006 Intel Corporation
Supports ACPI Specification Revision 3.0a

Loading Acpi table from file dsdt
Acpi table [DSDT] successfully installed and loaded
Pass 1 parse of [DSDT]
Pass 2 parse of [DSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
..............................................................................................................................................................................................................................................................................................................................................................................................
Parsing completed
Disassembly completed, written to "dsdt.dsl"

Compiling "dsdt.dsl"
dsdt.dsl  1084:                 Name (_T_0, Zero)
Error    4081 -     Use of reserved word ^  (_T_0)

dsdt.dsl  1088:                     Name (_T_1, Zero)
Error    4081 -         Use of reserved word ^  (_T_1)

dsdt.dsl  1122:                     Name (_T_2, Zero)
Error    4081 -         Use of reserved word ^  (_T_2)

dsdt.dsl  1161:                     Name (_T_3, Zero)
Error    4081 -         Use of reserved word ^  (_T_3)

dsdt.dsl  1184:             Method (Z002, 0, NotSerialized)
Warning  1086 -                        ^ Not all control paths return a value (Z002)

dsdt.dsl  1205:                 Name (_T_0, Zero)
Error    4081 -     Use of reserved word ^  (_T_0)

dsdt.dsl  1344:                 Name (_T_0, Zero)
Error    4081 -     Use of reserved word ^  (_T_0)

dsdt.dsl  1356:                         Name (_T_1, Zero)
Error    4081 -             Use of reserved word ^  (_T_1)

dsdt.dsl  1487:                     Name (_T_2, Zero)
Error    4081 -         Use of reserved word ^  (_T_2)

dsdt.dsl  1700:             Method (_WED, 1, NotSerialized)
Warning  1086 -                        ^ Not all control paths return a value (_WED)

dsdt.dsl  1700:             Method (_WED, 1, NotSerialized)
Warning  1079 -                        ^ Reserved method must return a value (_WED)

dsdt.dsl  1706:                         Return (Z002 ())
Warning  1091 -                                    ^ Called method may not always return a value

dsdt.dsl  1744:             Method (WMBD, 3, NotSerialized)
Warning  1086 -                        ^ Not all control paths return a value (WMBD)

ASL Input:  dsdt.dsl - 6682 lines, 239966 bytes, 2608 keywords
Compilation complete. 8 Errors, 5 Warnings, 0 Remarks, 40 Optimizations

Errors 1-4 are simply fixed. The use of the prefix _T_ is not allowed from the compiler as it is reserved for internal compiler use.
Warnings are also simply fixable putting a return value at the end of the methods listed above. In practice the last instruction of each of: Z002, _WED, _WMBD has to be the following: Return(Package(0x02){0x00, 0x00}).

Embedded touchpad is correctly recognised and handled by the kernel interface:

  Device Drivers  --->
   Input device support  --->
      --- Mouse interface

      <M> Event interface

      [*] Mouse  --->
         --- Mouse
         <M>   PS/2 mouse  

You'll obtain two modules named psmouse and evdev on the next kernel recompile
Now check that the touchpad is correctly detected by the kernel (quoted from trouble-shooting.txt file present into the source tree of the synaptic xorg driver):

If you are using a 2.6 linux kernel, check the /proc/bus/input/devices file.
The touchpad must be identified a “SynPS/2 Synaptics TouchPad” or an “AlpsPS/2 ALPS TouchPad”.
If it is identified as a “PS/2 Generic Mouse” or “PS/2 Synaptics TouchPad”, something is wrong.

As you can see the touchpad is not correctly detected and is identified by the kernel as a “PS/2 Synaptics TouchPad”. This appens because the module psmouse is loaded by Slackware using the option proto=imps (This option has to be removed):
/etc/rc.d/rc.modules-`uname -r`

### Mouse support:
# PS/2 mouse support:
# The default in Slackware is to use proto=imps because that works with the
# most types of mice out of the box.  For example, using proto=any will
# completely break the mouse if you change consoles with several models of KVM
# switches.
if echo $SHORTREL | grep -qvw 2.4 ; then
#  /sbin/modprobe psmouse proto=imps
  /sbin/modprobe psmouse
fi

: Aggiungere una piccola spiegazione delle opzioni disponibili da interfaccia prelevandolo dal sito di sviluppo del driver synaptic

Altough gpm claim to support Synaptic (and Synaptic PS/2) tablets, the version shipped with slackware 12.0 is not able to handle the touchpad correctly⁴⁾. A limited support is available configuring it to use the standard ps/2 mode.
You must verify that /etc/rc.d/rc.gpm start rule is so configured:

  echo "Starting gpm:  /usr/sbin/gpm -m /dev/mouse -t ps2"
  /usr/sbin/gpm -m /dev/mouse -t ps2

/dev/mouse is automagically generated by udev, following the rule that matches “mice:“

To use all the features of the touchpad in xorg-x11, you've to download and compile synaptic xorg driver from: :URL (Eventually if you don't want to compile the driver, you can try the latest synaptic packaged driver from linuxpackages.org :Specificare meglio)

Now that the driver is correctly installed (you can find it into :verificare directory), you can proceed editing xorg.conf file:

Section "Module"
   Load "synaptics"
EndSection

Section "InputDevice"
   Identifier "Touchpad"
   Driver "synaptics"
   Option "SendCoreEvents"
#   Option "Device" "/dev/input/event2" # eventX number may vary depending on the laptop model.
#   Option "Protocol" "event"
   Option "Protocol" "auto-dev"
   # Next line enable Shared Memory Access. Used to change configuration options without restarting X Server:
   Option "SHMConfig" "on"
   # The rest of the options are NOT required, just a default similar to the Windows drivers with none of the extra features.
   Option "LeftEdge" "1900"
   Option "RightEdge" "5400"
   Option "TopEdge" "1400"
   Option "BottomEdge" "4500"
   Option "FingerLow" "25"
   Option "FingerHigh" "30"
   Option "MaxTapTime" "180"
   Option "MaxTapMove" "220"
   Option "VertScrollDelta" "100"
   Option "MinSpeed" "0.02"
   Option "MaxSpeed" "0.18"
   Option "AccelFactor" "0.0010"
EndSection

Section "ServerLayout"
    InputDevice "Touchpad" "CorePointer"
    InputDevice "Mouse1" "SendCoreEvents"
EndSection

The “Protocol” option can be changed from “auto-dev” to “event”, but in that case you've to specify the correct kernel event interface for the touchpad (I've /dev/input/event2, you can find yours looking the voice Handlers of “SynPS/2 Synaptics TouchPad” into /proc/bus/input/devices).

: verificare: The settings in the serverlayout section will make the touchpad your primary input device instead of your external mouse. If you want to start the X-server without an external mouse then there will be no problem. If you’re using hotplug you will notice that you can plug in a mouse while the X-server is running and it can be used immediately.
: For more information on the synaptic driver read URL driver xorg Synaptic
: Aggiungere info da documentazione presente nel tar.gz del driver xorg

Embedded card reader does not work with stock kernel. It seems the problem is that into the embedded ENE CB712 controller there are two MMC/SD controllers bind to device 0x0550 and 0x0551 respectively. The default sdhci driver detects only the interface at 0x0550, that's a dummy one (or more probably is implemented to the chip but is not connected to any phisical device) that does nothing.

06:04.2 Generic system peripheral [0805]: ENE Technology Inc ENE PCI Secure Digital Card Reader Controller (rev 01)

Also the mysterious 0x0551 device, exposed by the controller is actually SDHCI-compatible.

06:04.4 FLASH memory: ENE Technology Inc SD/MMC Card Reader Controller (rev 01)

Unluckily, as stated above, this device is not supported by current, stock, vanilla kernels⁵⁾… but you can successfully enable it using this patch originally released here: [Sdhci-devel] A patch that maybe fixes ENE CB712/4 card readers, that I've only updated to fit with 2.6.22.2 kernel line. The patch add to sdhci driver the knowledge that 0x0551 is a SDHCI device… simple ad effective :P

diff -Bbur linux-2.6.20-suspend2-r4-orig/drivers/mmc/sdhci.c linux-2.6.20-suspend2-r4/drivers/mmc/sdhci.c
--- linux-2.6.20-suspend2-r4-orig/drivers/mmc/host/sdhci.c	2007-05-11 01:43:16.000000000 +0300
+++ linux-2.6.20-suspend2-r4/drivers/mmc/host/sdhci.c	2007-05-11 01:51:00.000000000 +0300
@@ -74,6 +74,14 @@
 		.driver_data	= SDHCI_QUIRK_SINGLE_POWER_WRITE,
 	},
 
+	{
+		.vendor		= PCI_VENDOR_ID_ENE,
+		.device		= PCI_DEVICE_ID_ENE_CB712_SD_2,
+		.subvendor	= PCI_ANY_ID,
+		.subdevice	= PCI_ANY_ID,
+		.driver_data	= SDHCI_QUIRK_SINGLE_POWER_WRITE,
+	},
+
 	{	/* Generic SD host controller */
 		PCI_DEVICE_CLASS((PCI_CLASS_SYSTEM_SDHCI << 8), 0xFFFF00)
 	},
diff -Bbur linux-2.6.20-suspend2-r4-orig/include/linux/pci_ids.h linux-2.6.20-suspend2-r4/include/linux/pci_ids.h
--- linux-2.6.20-suspend2-r4-orig/include/linux/pci_ids.h	2007-05-11 01:40:24.000000000 +0300
+++ linux-2.6.20-suspend2-r4/include/linux/pci_ids.h	2007-05-11 01:50:11.000000000 +0300
@@ -1972,6 +1972,7 @@
 
 #define PCI_VENDOR_ID_ENE		0x1524
 #define PCI_DEVICE_ID_ENE_CB712_SD	0x0550
+#define PCI_DEVICE_ID_ENE_CB712_SD_2	0x0551
 #define PCI_DEVICE_ID_ENE_1211		0x1211
 #define PCI_DEVICE_ID_ENE_1225		0x1225
 #define PCI_DEVICE_ID_ENE_1410		0x1410

Now you can copy the path to your kernel source directory (Here I suppose it's /usr/src/linux) and apply it:

cd /usr/src/linux

patch -p1 < ENE_SD.patch

Aggiungere la patch per lspci

: Completare e testare
The cardBus bridge is a ENE Technology Inc CB-712/4 Cardbus Controller (rev 10) (as stated by lcpci) and is detected and can be used as soon as you enable yenta card support into your kernel.

      Bus options (PCI, PCMCIA, EISA, MCA, ISA)  --->
           PCCARD (PCMCIA/CardBus) support  --->   
   <M> PCCard (PCMCIA/CardBus) support                              │ │
         [ ]   Enable PCCARD debugging                                    │ │
         <M>   16-bit PCMCIA support                                      │ │
         [*]     Load CIS updates from userspace (EXPERIMENTAL)           │ │
         [*]     PCMCIA control ioctl (obsolete)                          │ │
         ---   32-bit CardBus support                                     │ │
         ---   PC-card bridges                                            │ │
         <M>   CardBus yenta-compatible bridge support                    │ │
         < >   Cirrus PD6729 compatible bridge support                    │ │
         < >   i82092 compatible bridge support 
         < >   i82365 compatible bridge support                           │ │
         < >   Databook TCIC host bridge support   

Output of lspcmcia:

Socket 0 Bridge:        [yenta_cardbus]         (bus ID: 0000:06:04.0)