Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Tue, 15 Feb 2005 18:03:28 +0100, Kenan Esau <kenan.esau@conan.de> wrote:
> Am Dienstag, den 15.02.2005, 09:43 -0500 schrieb Dmitry Torokhov:
> > On Tue, 15 Feb 2005 14:43:08 +0100, Vojtech Pavlik <vojtech@suse.cz> wrote:
> > > On Tue, Feb 15, 2005 at 09:57:59AM +0100, Kenan Esau wrote:
> > > > +static struct dmi_system_id lifebook_dmi_table[] = {
> > > > +     {
> > > > +             .ident = "Fujitsu Siemens Lifebook B-Sereis",
> > > > +             .matches = {
> > > > +                     DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK B Series"),
> > > > +             },
> > > > +     },
> > > > +     { }
> > > > +};
> > >
> > > This might be a bit too much generic. Are you sure there are no B Series
> > > lifebooks without a touchscreen?
> > >
> >
> > And another concern: does this notebook (or others using this
> > touchscreen) have an active MUX? We don't want to force LBTOUCH
> > protocol on an external mouse.
> 
> All B-Series Lifebooks have the same touchscreen-hardware. But Dmitri's
> concern is correct -- at the moment I would enforce the LBTOUCH-protocol
> on external mice...
> 
> I have to fix this. I will additionally to the DMI stuff use "Status
> Request". On a "Request ID"-Command the Device always answers with a
> 0x00 -- could this also be helpfull?
> 
> > > > +static psmouse_ret_t lifebook_process_byte(struct psmouse *psmouse, struct pt_regs *regs)
> > > > +{
> > > > +     unsigned char *packet = psmouse->packet;
> > > > +     struct input_dev *dev = &psmouse->dev;
> > > > +
> > > > +        unsigned long x = 0;
> > > > +        unsigned long y = 0;
> > > > +        static uint8_t pkt_lst_touch = 0;
> > > > +     static uint8_t pkt_cur_touch = 0;
> > > > +     uint8_t pkt_lb = packet[0] & LBTOUCH_LB;
> > > > +     uint8_t pkt_rb = packet[0] & LBTOUCH_RB;
> >
> > We usually don't use userspace types here. unsigned char or u8 for kernel.
> >
> > > > +
> > > > +                psmouse->protocol_handler = lifebook_process_byte;
> > > > +                psmouse->disconnect = lifebook_disconnect;
> > > > +                psmouse->reconnect  = lifebook_initialize;
> > > > +                psmouse->initialize = lifebook_initialize;
> > > > +                psmouse->pktsize = 3;
> > > > +     }
> > > > +
> > > > +     return 0;
> > > > +}
> > >
> > > The change to the psmouse interface I'm leaving to Dmitry to comment on.
> >
> > I don't think that we need a separate initialize handler simply
> > because it is called just once, at initialization time. Here we know
> > exactly what device (protocol) we are dealing with, no need for
> > indirection.
> 
> I introduced the new initialize-handler since psmouse->initialize() is
> also used in psmouse-base.c. This is to prevent putting if-statements on
> each place where the initialization-function for a certain protocol is
> called in psmouse-base.c.

It would be good idea if protocols were initialized in many difefrent
places, but the all are called from one place - psmouse_extensions.
Some protocols that can be detected without changing hardware state
have 2 functions - detect and init and the others have ony detect
which does initialization as well. But they all are called from the
same place.

psmouse_initialize has somewhat confising name, it is not "initialize
protocol", it is "enable streaming and initialize common parameters,
such as rate and resolution". Plus I think it is too late to do
protocol init in psmouse_initialize as this will not allow falling
back to "lesser" protocols if higher prtocol initialization fails.

> I admit since I am also using a different reconnect-function than
> psmouse-base it's not such a huge benefit but think of a new
> protocol/device which uses the same reconnect-function as psmouse-base
> but a different init-function.

I am not sure what difference does it make - if there is no reconnect
hamdler psmosue will end up calling psmouse_extensions which will
re-initialize hardware with proper function for the protocol. It still
does not require a handler in psmouse structure.

> 
> My goal was to have no dependency from psmouse-base to the
> lifebook-handling (none but lifebook_detect()). Thus the indirection is
> IMHO needed.

You can hide all of it right in lifebook_detect or acknowledge that
you have 2 fucntions and call them from psmouse-base, like synaptics
and alps do. I don't think it exposes lbtouch internals too much.

-- 
Dmitry