Page 2 of 2 FirstFirst 12
Results 11 to 17 of 17

Thread: Trackpoint sensitivity returns to default when resuming from suspend

  1. #11
    Join Date
    Jan 2008
    Location
    Chicago, IL, USA
    Beans
    122

    Re: Trackpoint sensitivity returns to default when resuming from suspend


  2. #12
    Join Date
    Sep 2007
    Location
    Alnilam
    Beans
    311
    Distro
    Kubuntu

    Re: Trackpoint sensitivity returns to default when resuming from suspend

    I have tried every single method that is available online to fix this in Kubuntu Lucid with ThinkPad T410s so that the sensitivity is customized, but nothing works. I have tried udev, sysfsutils, rc.local and the script posted by vukasin0. Forget about suspend, it doesn't even work after reboot. This is crazy.

    Is there any way to get Ubuntu Lucid to stop resetting trackpoint sensitivity after every reboot?
    Last edited by undoIT; May 22nd, 2010 at 12:19 AM.

  3. #13
    Join Date
    May 2010
    Beans
    3

    Re: Trackpoint sensitivity returns to default when resuming from suspend

    You should be able to set speed and sensitivity by adding a rule in /etc/udev/rules.d. However due to a kernel bug (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549379), the rule gets triggered before the speed or sensitivity attributes exist. As a work around, you can add a WAIT_FOR condition. I set the speed and sensitivity using /etc/udev/rules.d/trackpoint.rules with a single line:

    SUBSYSTEM=="serio", DRIVERS=="psmouse", ATTR{description}=="Synaptics pass-through", WAIT_FOR="/sys/devices/platform/i8042/serio1/serio2/sensitivity" ATTR{sensitivity}="220", ATTR{speed}="160"

    You might also add a WAIT_FOR the speed attribute, but waiting on one works fine for me.

  4. #14
    Join Date
    Nov 2009
    Beans
    2

    Re: Trackpoint sensitivity returns to default when resuming from suspend

    Kubuntu 10.04 LTS all updates on a Thinkpad T42p 2373-KYG, with UltraNav

    I've tried it as described:
    If you don't look out carefully for the correct device path, and test as advertised with
    Code:
    sudo udevadm test /sys/devices/platform/i8042/serio1
    you are getting an error,
    with my configuration, it should be
    Code:
    hal@T42pUXGA:~$ sudo udevadm test /sys/devices/platform/i8042/serio1/serio2
    (note the serio2 at the end)


    Trivial but still a pitfall.
    HTH

  5. #15
    Join Date
    Feb 2008
    Beans
    18

    Re: Trackpoint sensitivity returns to default when resuming from suspend

    I'm having a problem on a T410i running Ubuntu 10.10. The WAIT_FOR code is working on startup, setting the speed and sensitivity according to the values in trackpoint.rules. However it is not applied after suspend.

    I tried adding another WAIT_FOR for speed by writing:

    SUBSYSTEM=="serio", DRIVERS=="psmouse", ATTR{description}=="Synaptics pass-through", WAIT_FOR="/sys/devices/platform/i8042/serio1/serio2/sensitivity", WAIT_FOR="/sys/devices/platform/i8042/serio1/serio2/speed" ATTR{sensitivity}="220", ATTR{speed}="160"

    Did not work.

    So i tried to replace sensitivity with speed:

    SUBSYSTEM=="serio", DRIVERS=="psmouse", ATTR{description}=="Synaptics pass-through", WAIT_FOR="/sys/devices/platform/i8042/serio1/serio2/speed" ATTR{sensitivity}="220", ATTR{speed}="160"

    Did not work.

    Am I doing something wrong here or is this fix not working in 10.10?

  6. #16
    Join Date
    Feb 2008
    Beans
    18

    Re: Trackpoint sensitivity returns to default when resuming from suspend

    Sorry, double post.
    Last edited by McBraid; January 20th, 2011 at 09:35 PM. Reason: Double post.

  7. #17
    Join Date
    May 2010
    Beans
    3

    Re: Trackpoint sensitivity returns to default when resuming from suspend

    Check whether udevadm test /sys/devices/platform/i8042/serio1 (substituting your appropriate path) corrects the problem after suspend. WAIT_FOR has a 10s timeout period which might not be enough. (http://www.kernel.org/pub/linux/util...udev/udev.html) I have occasionally seen the setting fail to hold, possibly due to a timeout. However, I have not tried this on 10.10.

Page 2 of 2 FirstFirst 12

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •