Michael Schmitz wrote:
Do we have a clear picture of the hardware/software combination this bug
is triggered by?
In particular:
- only tibook? What about iBook or later (Al-) PowerBooks?
- running pbbuttonsd (version?), no pmud present?
- running pmud (version?), no pbbuttonsd present?
- running pmud (version?) with pbbuttonsd in pmud-compat mode?
(for this one you'll need to build your own pbbuttonsd, or ask me for
such a beast)
- running neither of them?
- running some version of mouseemu?
- are you using either pbbuttonsd or mouseemu to block the trackpad while
typing?
That would help to narrow it down to either PMU or eventdev communication.
So far, I've not been able to get a clear picture from the reports. ISTR
one user reported that problems went away after using pmud/mouseemu
instead of pbbuttonsd, that's why I suggest testing the above
configurations.
We've been bouncing a few ideas around WRT interaction between events and
PMU but that didn't help much.
If we can get a clearer picture about what usage pattern tends to
interfere with PMU/host communication, or generally locks out interrupts,
we could ask more specific questions on LKML.
Michael
My setup:
Aluminium Powerbook 12" rev. B (2003, powerbook 6,2)
pbbuttonsd 0.7.1
no pmud
mouseemu 0.15
mouseemu blocks the trackpad
pbbuttonsd does not block the trackpad
I've had the power-loss issue happen only three or four times over two
weeks of use, so it's hard to describe behaviour causing it, but it's
always been while I'm actually using the computer (not while running
idle), so it's quite possible that I was sending mouse/keyboard events
at the moment of power loss each time.
I'm going to try telling mouseemu not to block the trackpad.
/james
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
