[ltp] Setting up the trackpoint

[Noah Dain]

On 1/3/06, Richard Neill <rn214@hermes.cam.ac.uk> wrote:
>
>
> Torsten Wolf wrote:
> > Hi!
> >
> > When trying to follow the instructions in
> > http://thinkwiki.org/wiki/How_to_configure_the_TrackPoint I noticed,
> > that the the configuration files are located in
> > /sys/devices/platform/i8042/serio0/serio2 only after a fresh boot of th=
e
> > system. After a suspend to disk (with a reboot), the last directory
> > changes to serio3, i.e. the number increases with each std-cycle.
> > Suspending to ram does not affect the location (as there is no reboot?)=
.
> > Does anybody else experience this behaviour? I just saw that 2.6.15 has
> > finally been released, so I'll check whether this is 2.6.15-rc5 related=
.
>
> No idea - but do tell us if you get it fixed.
>
> > The reason why I'm bothered is that I'd finally like to set up the
> > trackpoint correctly. At the moment I have a simple script that searche=
s
> > for the configuration files in /sys/devices/platform/i8042/serio0 and
> > then modifies the values e.g. via "echo -n 1 >/sys/.../press_to_select"=
.
> > So here comes my first dumb question. Do the configuration files appear
> > when the xserver is starting? I ask this because once I failed setting
> > the values via an init-script during bootup.
>
> I think that they are from by the kernel device driver, and independent
> of X. You might need to modprobe the correct module.
>
> >
> > My next attempt was to invoke the script when starting the windowmanage=
r
> > (.xsession or fluxbox/startup). In this scenario the script is executed
> > by the user owning  the X session. But an ordinary user seems to lack
> > the proper permissions; every "echo -n..." returns "Permission denied".
> > Altering the suid bit had no success.
>
> Use sudo?
> If, like me, you are the only user of the laptop, you could set up sudo
> to allow certain commands to be executed without the password.
> [You might even allow "sudo su"]
>
> >
> > Now, my last idea is to write an udev-rule, giving me an
> > /dev/input/trackpoint, no matter where the serio resides  and setup the
> > trackpoint in the xorg.conf file. But can all settings be accessed from
> > the X configuration?
>
> iirc, *none* of the trackpoint-specific settings
> (sensitivity,press-to-select) can be configured in X.
>
> /dev/input/trackpoint is a good idea but for a different reason. It
> allows you to have multiple mice (if desired), or perhaps a graphics
> tablet - and then you don't have to care about weirdness from
> /dev/input/mice.
>
> >
> > Hmm, these questions seem a bit dumb to me, but I'm stuck at this point=
,
> > so every hint is greatly appreciated.
>
> It's rather a shame that the old tp4d  doesn't work with kernel 2.6.
> That was, in my view, nicer.  Good luck.
>
> Richard
> --
> The linux-thinkpad mailing list home page is at:
> http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
>

currently running 2.6.14.5 here.

i've seen similar behaviour when removing the psmouse kernel module
and then re-inserting it.  I'd speculate a shortcoming of the current
design of kernel-udev communication, or maybe just in the trackpoint
code itself.  It seems when removing the module, udev is not notified
and therefore leaves device node(s) in the vfs (ie: /dev/input/eventX
or /dev/input/mouseX).  For each iteration of removal and insertion,
another devnode is created, the lattermost being the only one with
works.

so, I would hazard to guess the somewhere in the suspend and resume
process the psmouse module is being removed or becoming
stale/non-operative, and when resuming the module is re-inserted
yielding the behaviour outlined above.

perhaps if the psmouse module were statically compiled into the kernel
this would not be a problem?  or, perhaps you just would be inable to
get the trackpoint back up at all after a resume (???)


--
Noah Dain
"Single failures can occur for a variety of reasons that have nothing
to do with a hardware defect, such as cosmic radiation ..." - IBM
Thinkpad R40 maintenance manual, page 25