Re: [RFC] OLPC tablet input driver, take two.

["Dmitry Torokhov" <dtor@insightbb.com>]

On 9/11/06, Zephaniah E. Hull <warp@aehallh.com> wrote:
> On Sun, Sep 10, 2006 at 06:19:31PM -0400, Dmitry Torokhov wrote:
> > >
> > > @@ -616,6 +617,15 @@ static int psmouse_extensions(struct psm
> > >   */
> > >                     max_proto = PSMOUSE_IMEX;
> > >             }
> > > +           ps2_command(&psmouse->ps2dev, NULL, PSMOUSE_CMD_RESET_DIS);
> >
> > Do we have to do 2nd reset here? Plus logic seems a bit fuzzy here -
> > if ALPS is detected but initizliztion fails it will start OLPC detection
> > which is probably not what you wanted...
>
> Reset is _probably_ not necessary, I'll verify.
>
> However the logic is the same as for all the others, if init succeeds,
> it returns PSMOUSE_ALPS, if it doesn't then it continues on to the next,
> which happens to be olpc, admittedly it would be more obvious that it's
> doing the same thing if it was in its own if, but.

Not exactly. We have 2 types of protocols - some have only detect,
others have both detect and init. For protocols that have both detect
and init we expect detect to reliably identify whether the device is
of given type or not and once detect succeeds we do not try to probe
for other speciality protocols. For example if alps_detect succeeds
but alps_init fails we won't try Genius detection (we will only try
standard imex, exps and bare) and we should not try OLPC detection
either.

-- 
Dmitry