Here Thinkpad A20m - manufactury date 06/2000, Mobile P III Coppermine - would not boot TC at all without the 'acpi=off' boot param.
Unfortunately it is not as simple as just compiling an apm module, as a look at the kernel config would show:
# CONFIG_APM is not set
meaning the kernel would have to be recompiled.
I would fully agree that TC even if not specifically targeted at older PCs, nevertheless due to its low requirements and its structure of ultimate flexibility is de facto an optimal candidate to be used as OS on older hardware, therefore I find the lack of APM rather regretful.
It is often stressed that TC is about choice - and it is overall, as hardly any other OS I have seen; but I have to admit that when I was at the point of considering to switch to TC as my primary OS - weighing pros and cons, the lack of choice of APM was one of the biggest cons.
Older laptops have very frequently issues about wearing out batteries, and there is simply no way to get any battery status, if ACPI is not an option and APM is left out.
Having read a lot about Linux power management and playing around with it with older laptops, I have never heard about any conflicts about both power management subsystems being configured into the same kernel - and most stock kernels I have used since ACPI started to become mainstream featured both.
From kernel docs: "If a working ACPI implementation is found, the ACPI driver will override and disable APM, otherwise the APM driver will be used."
Also there is the config option CONFIG_ACPI_BLACKLIST_YEAR=
Common occurence is that if a blacklist year is set, it is usually 2001.
When I would boot the same OS by default with a box from 2000 APM would be enabled, resp. ACPI
with a box from 2002 (I never happened to lay hand at a box from 2001, so I wouldn't know exactly what would happen in a borderline case).
However, all these are simply defaults, which could most easily be overriden by boot params, e.g. acpi=force, acpi=off apm=on etc.
Therefore, having both pm subsystems configured in same kernel provides a matter of choice, which when not explicitely stated by user is handled by default criterias of one subsystem overriding the other.
A look at /var/log/messages would show that an exclusive choice in favour of one pm subsystem while disabling the other one occurs most early in boot sequence. There is no way to reactivate
the disabled pm subsystem before a reboot occurs and therefore I would rather exclude any possibility of a conflict.
As a 64bit stock kernel has been introduced as a choice addressed at high-end PC's, why not in the same spirit of choice introducing a stock kernel with APM enabled addressed at low-end PCs, when TC as already mentioned has a lot of pros for latter?
Also think about that exactly the same hardware which would run better with APM is very often also not the one most suitable to set up a compile environment, to install the kernel sources and to compile the kernel.
Perhaps an approach could be that a user contributed (if any user would be ready to) kernel based on existing kernel config but with APM enabled could get accepted to be hosted in repo, so the devs which already have to handle many other priorities would not be much burdened with an additional task?
Personally I would favour a kernel including both ACPI and APM - e.g. in the case of netboot where a not uncommon scenario may be that the server would preferably run ACPI, but older clients APM, or in case of having a nomadic OS on some removable storage - but even if ACPI resp. APM would remain exclusive to two different kernels, who would complain about some 2MB of storage usage more, when TC overall in comparison to other Linux systems is an ultimate space saver?
Welcome
FAQ
Downloads
Wiki
