Re: [PATCH] psmouse split

[Dmitry Torokhov]

On 12/13/06, Andres Salomon <dilinger@xxxxxxxxxx> wrote:
> Dmitry Torokhov wrote:
> > Hi Andres,
> [...]
> >
> > Unfortunately I do not think this is going to work well in in default case:
> >
> > 1. PS/2 probing order is important. You need to probe for intellimouse
> >    explorer last otherwise you might miss that mouse supports extended
> >    protocol.
> >
>
> Sorry, I'm not sure I understand; you're saying that the intellimouse
> probe will match other mice?

Yes, for example many Logitech mice supporting PS2++ will respond to
intellimouse and explorer probes. Some versions of synaptics firmware
support intellimouse protocol as well. I am pretty sure ALPS does too.

> I originally had kept the probing order, but dropped it here:
>
> http://dev.laptop.org/git?p=users/dilinger/psmouse-split;a=commit;h=14f352333d057c3a7a05fdab484b339b9bac2959
>
> I can readd it if necessary.
>
>
> > 2. Synaptics hardware has to be probed even if synaptics protocol is not
> >    used, otherwise intellimouse probe will case trackpoint on passthrough
> >    port not working.
> >
>
>
> I'm aware of that, and the synaptics_hardware variable remains in the
> psmouse_extensions() function as a reminder.  I just need to figure out
> a clean way to do the probing; I wanted feedback about whether people
> liked the broken out modules idea, first.

OK.

> > 3. Doing full reset after every protocol probe will cause long delays in
> >    mouse detection.
>
>
> I'm not convinced this will actually take that long, and it should only
> happen during init.  With ordered detection and an additional field in
> the psmouse_protocol struct, each protocol could specify whether it
> should be reset or not.  However, if it's not necessary, I'd rather get
> rid of it all (sounds like the detection ordering might be necessary,
> though).

Resets are needed. We used not to have it but that confused some mice.

> >
> > 4. Maxproto is still needed - psmouse base still contains several protocols
> >    and sometimes users need to force "standard" protocols (Intellimouse/
> >    Explorer), for example when using a KVM switch.
> >
>
> Yes, I intended to split out the protocols into a separate module, as
> mentioned in
>
> http://dev.laptop.org/git?p=users/dilinger/psmouse-split;a=commit;h=2a19dbb884cb05b5e9469bde439ac60ed56bd48d
>
> If a KVM requires a user to force a standard protocol, I would think
> that forcing it via psmouse_attr_set_protocol would be a much nicer way
> than dealing w/ max_proto.  Combine that w/ being able to rmmod specific
> protocol modules (ie, rmmod psmouse-synaptics if it turns out that
> detection is incorrectly seeing something synaptics-like).

That requires changing your init scripts and such. In many instances
specifying psmouse.max_proto on kernel command line is the easiest
way.

> > Also, splitting psmouse into several modules as opposed to having monolitic
> > psmouse with an option to exclude some protocols via Kconfig does not really
> > buy us anything - because protocol autoload is not possible (we do not know
>
> It does; compiling a custom kernel for users is a pain.  However, using
> a distribution kernel and being able to control specifically which
> modules are loaded makes life a lot easier (users get security updates,
> etc).
>
>
> > what protocols port uses until we actually do the probe) distributions will
> > have to compile and load everything anyway. Custom kernel users will just
> > have to compile protocols they need into psmouse.
> >
>
> Yes, distributions will have to compile and load everything anyways.
> However, people who know what hardware they have can then force loading
> of a specific module, rather than having a monolithic module or having
> to recompile a custom kernel.

I would consider this module juggling way over the head for average
user. I want to have the ability to exclude some protocols from
psmouse module via Kconfig option, but I want it to be hidden under
CONFIG_EMBEDDED for everything except very raretic protocols (like
OLPC).

--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/