Am Donnerstag, den 24.02.2005, 10:03 +0100 schrieb Vojtech Pavlik: 
> On Mon, Feb 21, 2005 at 09:06:55AM +0100, Kenan Esau wrote:
> 
> > > > I also checked my original standalone-driver: Because of this behaviour
> > > > I always retried the last command 3 times if the responce from the
> > > > device was 0xfe or 0xfc.
> > > 
> > > And did it actually help? Did the touchscreen ever respond with a 0xfa
> > > "ACK, OK" response to these commands?
> > 
> > I played around a little bit last weekend. And obviously the touchscreen
> > always responds 0xfe to the 0xe8 0x07 command. Also repeating the
> > command does not really help. After the firxt 0x07 you get back the 0xfe
> > and the next byte you send to the device is ALWAYS answered by a
> > 0xfc!?!?
> 
> This looks like it either expects some other data (like a second
> parameter to the command?) or just wants the 0x07 again (and not the
> whole command) to make sure you really mean it.
> 
> Could you try sending 0xe8 0x07 0x07?

My old driver did that. But with the same result. It doesn't seem to
matter what the first and the second bytes are -- the answers from the
device are alway the same.

> > At the end of this mail you'll find some traces I did.
> > 
> > I also wonder if it is possible at all to probe this device. I think
> > not. IMHO we should go for a module-parameter which enforces the
> > lifebook-protokoll. Something like "force_lb=1". Any Ideas /
> > suggestions? 
> 
> I'd suggest using psmouse.proto=lifebook

The current patch has implemented it that way. But the meaning is a
little bit different. With proto=lifebook you ENFORCE the lifebook
protocol. As far as I read the meaning of the other ones this does not
really enforce these protocols.

> > How does this work out with a second/external mouse?
> 
> The external mouse has to be in bare PS/2 mode anyway, so we don't need
> to care.

Why that?

I have attached the newest version of the patch.