On Sat, 7 Jan 2006, Luca Bigliardi wrote:
> Hi Peter,
> i'd like to have your opinion on this mail[1] (and the thread).
> Benjamin Herrenschmidt is the maintainer of linux on powerpc;
> he has rejected my patch for synaptics support on adb based trackpad
> (found on ibook and powerbook) because in his opinion the absolute mode
> should be configurable at runtime when synaptics X driver is loaded.
> IMHO his idea could be good, but i'm not aware so i'm going to ask your
> opinion.
>
> [1] http://lists.debian.org/debian-powerpc/2006/01/msg00090.html
I once suggested this a long time ago when the synaptics driver was first
included in the kernel. However, the input subsystem maintainer (Vojtech)
didn't like the idea. (The case with multiple readers reading from the
same event device would be weird if one application could switch mode and
cause another application to receive different events.)
The plan was to have the kernel report raw data to user space using the
event devices and make the X server understand it. The imps/2 emulation
done by mousedev.c (ie /dev/input/mice) would then become obsolete.
The X synaptics driver is a step in that direction, but because of
licensing conflicts the driver has not been included in Xorg. Therefore
the synaptics driver is not always present, in which case the kernel
mousedev emulation is used, which is almost always worse than the built in
emulation in the touchpad hardware that would have been used if the
touchpad was in relative mode.
Fedora handles this situation by always installing the synaptics package
and setting up the X config file automatically if the computer has a
synaptics touchpad. I guess this approach could work for other
distributions too.
--
Peter Osterlund - [email protected]
http://web.telia.com/~u89404340
> Fedora handles this situation by always installing the synaptics package
> and setting up the X config file automatically if the computer has a
> synaptics touchpad. I guess this approach could work for other
> distributions too.
The problem we have is a bit different (or I didn't understand
something). The mac trackpad has it's own kernel driver and is all
relative mode. Luca's patch will make it work in absolute mode instead
for use with X synaptic driver, thus providing more "features" than the
default relative-mode one.
So what we are looking for is a way to have the kernel driver switch
between raw and ps2 modes based on instruction/ioctl from the userland
client (the X synaptic driver). This shouldn't be much of a problem if
the X synaptic driver switches it to raw at X start and on EnterVT and
back to what it was on LeaveVT...
Ben.
On Friday 06 January 2006 19:51, Benjamin Herrenschmidt wrote:
>
> > Fedora handles this situation by always installing the synaptics package
> > and setting up the X config file automatically if the computer has a
> > synaptics touchpad. I guess this approach could work for other
> > distributions too.
>
> The problem we have is a bit different (or I didn't understand
> something). The mac trackpad has it's own kernel driver and is all
> relative mode. Luca's patch will make it work in absolute mode instead
> for use with X synaptic driver, thus providing more "features" than the
> default relative-mode one.
>
> So what we are looking for is a way to have the kernel driver switch
> between raw and ps2 modes based on instruction/ioctl from the userland
> client (the X synaptic driver). This shouldn't be much of a problem if
> the X synaptic driver switches it to raw at X start and on EnterVT and
> back to what it was on LeaveVT...
>
Why would you want to switch to relative mode when leaving X? As far as
I know the only other mouse "user" out there is GPM and there are patches
available for it to use event device:
http://geocities.com/dt_or/gpm/gpm.html
Unfortunately the maintainer can't find time to merge these so they were
sitting there for over 2 years. FWIW Fedora patches their GPM with these.
--
Dmitry
> Why would you want to switch to relative mode when leaving X? As far as
> I know the only other mouse "user" out there is GPM and there are patches
> available for it to use event device:
>
> http://geocities.com/dt_or/gpm/gpm.html
>
> Unfortunately the maintainer can't find time to merge these so they were
> sitting there for over 2 years. FWIW Fedora patches their GPM with these.
gpm among other legacy things ...
Ben.
On Friday 06 January 2006 23:33, Benjamin Herrenschmidt wrote:
>
> > Why would you want to switch to relative mode when leaving X? As far as
> > I know the only other mouse "user" out there is GPM and there are patches
> > available for it to use event device:
> >
> > http://geocities.com/dt_or/gpm/gpm.html
> >
> > Unfortunately the maintainer can't find time to merge these so they were
> > sitting there for over 2 years. FWIW Fedora patches their GPM with these.
>
> gpm among other legacy things ...
>
What other legacy things? And in that case I think manually forcing protocol
back to relative would be an option.
The thing is that Synaptics in absolute and relative mode is 2 completely
different devices with different capabilities. If you want to switch mode
you really need to kill old input device and create a brand new one.
--
Dmitry
On Fri, 2006-01-06 at 23:36 -0500, Dmitry Torokhov wrote:
> On Friday 06 January 2006 23:33, Benjamin Herrenschmidt wrote:
> >
> > > Why would you want to switch to relative mode when leaving X? As far as
> > > I know the only other mouse "user" out there is GPM and there are patches
> > > available for it to use event device:
> > >
> > > http://geocities.com/dt_or/gpm/gpm.html
> > >
> > > Unfortunately the maintainer can't find time to merge these so they were
> > > sitting there for over 2 years. FWIW Fedora patches their GPM with these.
> >
> > gpm among other legacy things ...
> >
>
> What other legacy things? And in that case I think manually forcing protocol
> back to relative would be an option.
>
> The thing is that Synaptics in absolute and relative mode is 2 completely
> different devices with different capabilities. If you want to switch mode
> you really need to kill old input device and create a brand new one.
Ok, so what method should we use to "switch" ? sysfs isn't quite an
option yet as the ADB bus isn't yet represented there (unless we add
attributes to the input object, but that's a bit awkward as it would be
destroyed and re-created if I follow you). A module option would work
but adbhid isn't a module, thus that would basically end up as a static
kernel argument, unless the driver "polls" the module param regulary to
trigger the change.. I don't think there is a way for a driver to get a
callback when /sys/module/<driver>/parameters/* changes is there ?
Ben.
On Friday 06 January 2006 23:44, Benjamin Herrenschmidt wrote:
> On Fri, 2006-01-06 at 23:36 -0500, Dmitry Torokhov wrote:
> > On Friday 06 January 2006 23:33, Benjamin Herrenschmidt wrote:
> > >
> > > > Why would you want to switch to relative mode when leaving X? As far as
> > > > I know the only other mouse "user" out there is GPM and there are patches
> > > > available for it to use event device:
> > > >
> > > > http://geocities.com/dt_or/gpm/gpm.html
> > > >
> > > > Unfortunately the maintainer can't find time to merge these so they were
> > > > sitting there for over 2 years. FWIW Fedora patches their GPM with these.
> > >
> > > gpm among other legacy things ...
> > >
> >
> > What other legacy things? And in that case I think manually forcing protocol
> > back to relative would be an option.
> >
> > The thing is that Synaptics in absolute and relative mode is 2 completely
> > different devices with different capabilities. If you want to switch mode
> > you really need to kill old input device and create a brand new one.
>
> Ok, so what method should we use to "switch" ? sysfs isn't quite an
> option yet as the ADB bus isn't yet represented there (unless we add
> attributes to the input object, but that's a bit awkward as it would be
> destroyed and re-created if I follow you). A module option would work
> but adbhid isn't a module, thus that would basically end up as a static
> kernel argument, unless the driver "polls" the module param regulary to
> trigger the change.. I don't think there is a way for a driver to get a
> callback when /sys/module/<driver>/parameters/* changes is there ?
>
Yes, there is, but I'd imagine static option would be just fine. After
all you either use legacy applications or you don't. And if mousedev
does not provide adequate emulation you switch to relative mothod.
--
Dmitry
On Friday 06 January 2006 23:46, Dmitry Torokhov wrote:
> On Friday 06 January 2006 23:44, Benjamin Herrenschmidt wrote:
> > On Fri, 2006-01-06 at 23:36 -0500, Dmitry Torokhov wrote:
> > > On Friday 06 January 2006 23:33, Benjamin Herrenschmidt wrote:
> > > >
> > > > > Why would you want to switch to relative mode when leaving X? As far as
> > > > > I know the only other mouse "user" out there is GPM and there are patches
> > > > > available for it to use event device:
> > > > >
> > > > > http://geocities.com/dt_or/gpm/gpm.html
> > > > >
> > > > > Unfortunately the maintainer can't find time to merge these so they were
> > > > > sitting there for over 2 years. FWIW Fedora patches their GPM with these.
> > > >
> > > > gpm among other legacy things ...
> > > >
> > >
> > > What other legacy things? And in that case I think manually forcing protocol
> > > back to relative would be an option.
> > >
> > > The thing is that Synaptics in absolute and relative mode is 2 completely
> > > different devices with different capabilities. If you want to switch mode
> > > you really need to kill old input device and create a brand new one.
> >
> > Ok, so what method should we use to "switch" ? sysfs isn't quite an
> > option yet as the ADB bus isn't yet represented there (unless we add
> > attributes to the input object, but that's a bit awkward as it would be
> > destroyed and re-created if I follow you). A module option would work
> > but adbhid isn't a module, thus that would basically end up as a static
> > kernel argument, unless the driver "polls" the module param regulary to
> > trigger the change.. I don't think there is a way for a driver to get a
> > callback when /sys/module/<driver>/parameters/* changes is there ?
> >
>
> Yes, there is, but I'd imagine static option would be just fine. After
> all you either use legacy applications or you don't. And if mousedev
> does not provide adequate emulation you switch to relative mothod.
>
Oh, yes, another option for legacy applications would be to use GPM's
repeater mode.
--
Dmitry
> > Ok, so what method should we use to "switch" ? sysfs isn't quite an
> > option yet as the ADB bus isn't yet represented there (unless we add
> > attributes to the input object, but that's a bit awkward as it would be
> > destroyed and re-created if I follow you). A module option would work
> > but adbhid isn't a module, thus that would basically end up as a static
> > kernel argument, unless the driver "polls" the module param regulary to
> > trigger the change.. I don't think there is a way for a driver to get a
> > callback when /sys/module/<driver>/parameters/* changes is there ?
> >
>
> Yes, there is, but I'd imagine static option would be just fine. After
> all you either use legacy applications or you don't. And if mousedev
> does not provide adequate emulation you switch to relative mothod.
I still don't like static options... it's always wrong to require
rebooting for whatever reason ...
Ben.
On Sat, Jan 07, 2006 at 03:33:15PM +1100, Benjamin Herrenschmidt wrote:
>
> > Why would you want to switch to relative mode when leaving X? As far as
> > I know the only other mouse "user" out there is GPM and there are patches
> > available for it to use event device:
> >
> > http://geocities.com/dt_or/gpm/gpm.html
> >
> > Unfortunately the maintainer can't find time to merge these so they were
> > sitting there for over 2 years. FWIW Fedora patches their GPM with these.
>
> gpm among other legacy things ...
For X there is the synaptics driver, with more features than the pads
PS/2 mode.
For GPM there are the abovementioned patches, with configurable tap
characteristics, etc. They should be at least as good as the pads own
PS/2 mode.
For other legacy applications, there is the gpm repeater mode, exporting
GPM's functionality over the PS/2 protocol.
For legacy applications without GPM on the system, there is mousedev.c,
creating virtualized PS/2 devices for every application that opens it.
Its tap handling is not perfect, and it's not very much configurable,
but it works.
IMO there are enough options to make the device work well in absolute
mode.
If a relative mode is an absolute must, then a kernel option is IMO
sufficient (we have psmouse.proto=imps for the classic PS/2 Synaptics
pads), although a sysfs attribute would likely be better.
In theory, we could use EV_SYN, SYN_CONFIG for notifying applications
that the device has changed its capabilities, but a
disconnect/recreation will work better, since no applications support
the SYN_CONFIG notification ATM.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Saturday 07 January 2006 03:25, Vojtech Pavlik wrote:
>
> If a relative mode is an absolute must, then a kernel option is IMO
> sufficient (we have psmouse.proto=imps for the classic PS/2 Synaptics
> pads), although a sysfs attribute would likely be better.
>
Just FYI, writing into /sys/bus/serio/devices/serioX/protcol allows
swicthing ptorocol dynamically (this involves teardown of old input
device and creation of a new one).
> In theory, we could use EV_SYN, SYN_CONFIG for notifying applications
> that the device has changed its capabilities, but a
> disconnect/recreation will work better, since no applications support
> the SYN_CONFIG notification ATM.
>
I could see SYN_CONFIG being used to signal changes in limits (like min
and max X coordinates) but not to basic device capabilities.
--
Dmitry
On Sat, Jan 07, 2006 at 11:04:52AM -0500, Dmitry Torokhov wrote:
> On Saturday 07 January 2006 03:25, Vojtech Pavlik wrote:
> >
> > If a relative mode is an absolute must, then a kernel option is IMO
> > sufficient (we have psmouse.proto=imps for the classic PS/2 Synaptics
> > pads), although a sysfs attribute would likely be better.
> >
>
> Just FYI, writing into /sys/bus/serio/devices/serioX/protcol allows
> swicthing ptorocol dynamically (this involves teardown of old input
> device and creation of a new one).
I know, but this will not be possible if the Synaptics pad is connected
over ADB, which is the case I believe we are discussing here.
On the other hand, if it's just PS/2 over ADB, a serio driver instead of
an input driver would make more sense.
> > In theory, we could use EV_SYN, SYN_CONFIG for notifying applications
> > that the device has changed its capabilities, but a
> > disconnect/recreation will work better, since no applications support
> > the SYN_CONFIG notification ATM.
>
> I could see SYN_CONFIG being used to signal changes in limits (like min
> and max X coordinates) but not to basic device capabilities.
Yes, that's probably more sensible.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
> I know, but this will not be possible if the Synaptics pad is connected
> over ADB, which is the case I believe we are discussing here.
>
> On the other hand, if it's just PS/2 over ADB, a serio driver instead of
> an input driver would make more sense.
No, it's ADB protocol down to the communication with the PMU.
Ben.