Version:            (using KDE KDE 3.5.6)
Installed from:    Debian testing/unstable Packages

Reported at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345500

The automatic suspend problem of as soon as klaptopdaemon starts up when
KDE is started, is still there. If I remove the rc file for klaptopdaemon
and start KDE, it works. But then when I again configure klaptopdaemon and
select "Suspend" in the "Button Actions" tab for "LID Close Switch" and
select Apply, the laptop goes into and endless loop of suspend (susped-to-RAM).

Note: I've got another laptop (Dell D600) on which this particular issue isn't
seen, though that laptop doesn't resume at all, instead upon resume it simply
resets the machine. Let's not get into this laptops problem. This was just
for your information that maybe it could help you.

So, since another make laptop isn't having exactly the same problem, I
come up with this question in my mind. Maybe you could answer it.
On Default/Stock Linux Kernels where Suspend1 is the only suspend
mechanism, how does klaptopdaemon handle "suspend-to-RAM" and "suspend-to-DISK".
If it does that with the help of ACPI, then we might narrow it down
hoping that the ACPI support for my actual laptop (against which this defect
was filed) has a broken ACPI implementation.

If klaptopdaemon doesn't use ACPI and uses some other mechanism of its
own to trigger "suspend-to-RAM" and "suspend-to-DISK" events, then definitely
it should be a klaptopdaemon related defect which still isn't fixed in
3.4.2

I can confirm that this is a klaptopdaemon bug because now I've switched to 
kpowersave and I see no such issues.