summaryrefslogtreecommitdiffstats
path: root/gnu/usr.bin/gdb
diff options
context:
space:
mode:
authoryokota <yokota@FreeBSD.org>1997-06-30 12:52:57 +0000
committeryokota <yokota@FreeBSD.org>1997-06-30 12:52:57 +0000
commit4590227899e89f0079d5d0a7d3aadcd23953fbb8 (patch)
tree800132d5c2b13b2fa2094c0edb242aca06240429 /gnu/usr.bin/gdb
parentf3aa4e706ec9df10aba0a7e026f660eee66f5b29 (diff)
downloadFreeBSD-src-4590227899e89f0079d5d0a7d3aadcd23953fbb8.zip
FreeBSD-src-4590227899e89f0079d5d0a7d3aadcd23953fbb8.tar.gz
Add experimental APM support for some laptops.
If the configuration option PSM_HOOKAPM is defined and the APM device is available, the psm driver will issue the ENABLE command to the pointing device at the resume APM event if the device was open when the system went into suspended mode. If the option PSM_RESETAFTERSUSPEND is specified in addition to PSM_HOOKAPM, the driver will try to reset the pointing device before sending the ENABLE command. Built-in PS/2-type pointing devices in some laptops (all the reports I heard were about Toshiba models) sometimes don't work immediately after the system is resumed. The device MAY become available after a while. The system may exhibit the same symptom in other OS's too (no, FreeBSD is not the only OS that is suffering :-). I don't know the correct way of solving this yet, but it's been reported that issuing the ENABLE command after resumption wakes up the pointing device. Without PSM_HOOKAPM, the psm driver behaves in the same way as before. Problem reported in the bsd-nomads mailing list in Japan.
Diffstat (limited to 'gnu/usr.bin/gdb')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud