Touchpad problems with latest kernels

Touchpad problems with latest kernels

[Luke Sharkey]

Dear Sir,

I am emailing regarding some problems I have been having with the touchpad 
on my laptop (a hp pavilion dv5046ea  running Fedora Core 5 x86_64).
[ Here are the specifications for my laptop: 
http://h10010.www1.hp.com/wwpc/uk/en/ho/WF06b/21675-38187-38191-38191-38191-12319008-69074479.html]


Support for my touchpad seems to have gotten worse rather than better in 
successive kernels from 2054 onwards.

While on 2054 it generally works fine, On the latest kernels (2154, 2174 
etc.)  I have only to e.g. open a konqueror window for the onscreen pointer 
to start going funny, and jerking about (As happens on computers with v. low 
RAM).  I know its not a RAM problem, as a) everything else works fine, there 
is no slow down of any of the programs I run, only problems with the mouse 
and b) I have just upgraded from 512 MB of RAM to 1 GB.

If I plug in a mouse, the pointer works fine.  Though I would happily use a 
mouse, this is often inconvenient on a laptop.

Do you have any ideas what's wrong?

Thanks
LS

_________________________________________________________________
Windows Live™ Messenger has arrived. Click here to download it for free! 
http://imagine-msn.com/messenger/launch80/?locale=en-gb

Re: Touchpad problems with latest kernels

[Dmitry Torokhov]

On 8/14/06, Luke Sharkey <lukesharkey@hotmail.co.uk> wrote:
> Dear Sir,
>
> I am emailing regarding some problems I have been having with the touchpad
> on my laptop (a hp pavilion dv5046ea  running Fedora Core 5 x86_64).
> [ Here are the specifications for my laptop:
> http://h10010.www1.hp.com/wwpc/uk/en/ho/WF06b/21675-38187-38191-38191-38191-12319008-69074479.html]
>
>
> Support for my touchpad seems to have gotten worse rather than better in
> successive kernels from 2054 onwards.
>
> While on 2054 it generally works fine, On the latest kernels (2154, 2174
> etc.)  I have only to e.g. open a konqueror window for the onscreen pointer
> to start going funny, and jerking about (As happens on computers with v. low
> RAM).  I know its not a RAM problem, as a) everything else works fine, there
> is no slow down of any of the programs I run, only problems with the mouse
> and b) I have just upgraded from 512 MB of RAM to 1 GB.
>
> If I plug in a mouse, the pointer works fine.  Though I would happily use a
> mouse, this is often inconvenient on a laptop.
>

What kind of touchpad is this? Are you using synaptics X driver or
standard mouse driver? Also I am not quire sure what 2054 or 2154 is.
Can you please try vanilla kernels from kernel.org?

Dave, is there a place where one can see contents of a given RH kernel
(without downloadig and unpacking SRPM)?

-- 
Dmitry

Re: Touchpad problems with latest kernels

[Gene Heskett]

On Monday 14 August 2006 09:58, Luke Sharkey wrote:
>Dear Sir,
>
>I am emailing regarding some problems I have been having with the
> touchpad on my laptop (a hp pavilion dv5046ea  running Fedora Core 5
> x86_64). [ Here are the specifications for my laptop:
>http://h10010.www1.hp.com/wwpc/uk/en/ho/WF06b/21675-38187-38191-38191-381
>91-12319008-69074479.html]
>
>
>Support for my touchpad seems to have gotten worse rather than better in
>successive kernels from 2054 onwards.
>
>While on 2054 it generally works fine, On the latest kernels (2154, 2174
>etc.)  I have only to e.g. open a konqueror window for the onscreen
> pointer to start going funny, and jerking about (As happens on computers
> with v. low RAM).  I know its not a RAM problem, as a) everything else
> works fine, there is no slow down of any of the programs I run, only
> problems with the mouse and b) I have just upgraded from 512 MB of RAM
> to 1 GB.
>
>If I plug in a mouse, the pointer works fine.  Though I would happily use
> a mouse, this is often inconvenient on a laptop.
>
>Do you have any ideas what's wrong?
>
>Thanks
>LS

I'm having similar problems with an HP Pavilian dv5220, and with a 
bluetooth mouse dongle plugged into the right side usb port it works just 
fine.  What I'd like to do is totally disable that synaptics pad as its 
way too sensitive, making it impossible to type more than a line or 2 
without the cursor suddenly jumping to someplace else in the message, 
often highliteing several lines of text as it goes, and the next keystroke 
then deletes wholesale quantities of text, thoroughly destroying any 
chance of actually writing a cogent, understandable email response to 
anyone.

Unforch, my questions along those lines have been treated as the ravings of 
a lunatic and ignored.  The bios has no place to disable it, dumbest bios 
I've seen in quite a while, and it has been updated in the last 3 months.

I don't *think* I'm a lunatic, but I'm equally sure that the synaptics is a 
pain in the ass and should be capable of being totally disabled somehow, 
hopefully short of opening the lappy up and unplugging or cutting every 
lead to it until such time as it can be made to behave instead of 
responding to every thumb waved 1/2 to 3/4" above it.  I've gotten hand 
cramps trying to hold my thumbs far enough away from that abomination to 
stop such goings on.

So count this as a vote FOR doing something about the synaptics touchpad 
situation.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

Re: Touchpad problems with latest kernels

[Ian Stirling]

Gene Heskett wrote:
<snip>
> I'm having similar problems with an HP Pavilian dv5220, and with a 
> bluetooth mouse dongle plugged into the right side usb port it works just 
> fine.  What I'd like to do is totally disable that synaptics pad as its 
> way too sensitive, making it impossible to type more than a line or 2 

Enable the proper USB options, point X/GPM to /dev/input/mouse1 - or 
whatever.

It'd be nice if you could do this for keyboards too - but AIUI, you can't.

Re: Touchpad problems with latest kernels

[Dmitry Torokhov]

HI Gene,

On 8/14/06, Gene Heskett <gene.heskett@verizon.net> wrote:
>
> I'm having similar problems with an HP Pavilian dv5220, and with a
> bluetooth mouse dongle plugged into the right side usb port it works just
> fine.  What I'd like to do is totally disable that synaptics pad as its
> way too sensitive,

Are you using synaptics X driver? It can be tweaked to adjust
sensitivity and lots of other things.

> making it impossible to type more than a line or 2
> without the cursor suddenly jumping to someplace else in the message,
> often highliteing several lines of text as it goes, and the next keystroke
> then deletes wholesale quantities of text, thoroughly destroying any
> chance of actually writing a cogent, understandable email response to
> anyone.
>

Have you tried synclient utility? It temporarily disables the touchpad
when you start typing and re-enables it when you done.

> Unforch, my questions along those lines have been treated as the ravings of
> a lunatic and ignored.  The bios has no place to disable it, dumbest bios
> I've seen in quite a while, and it has been updated in the last 3 months.
>
> I don't *think* I'm a lunatic, but I'm equally sure that the synaptics is a
> pain in the ass and should be capable of being totally disabled somehow,
> hopefully short of opening the lappy up and unplugging or cutting every
> lead to it until such time as it can be made to behave instead of
> responding to every thumb waved 1/2 to 3/4" above it.  I've gotten hand
> cramps trying to hold my thumbs far enough away from that abomination to
> stop such goings on.
>
> So count this as a vote FOR doing something about the synaptics touchpad
> situation.
>

There are ways to disable it:

echo -n "manual" > /sys/bus/serio/devices/serioX/bind_mode
echo -n "none" > /sys/bus/serio/devices/serioXdrvctl

This should disable it completely.

-- 
Dmitry

Re: Touchpad problems with latest kernels

[Dave Jones]

On Mon, Aug 14, 2006 at 10:36:14AM -0400, Dmitry Torokhov wrote:
 > On 8/14/06, Luke Sharkey <lukesharkey@hotmail.co.uk> wrote:
 > > Dear Sir,
 > >
 > > I am emailing regarding some problems I have been having with the touchpad
 > > on my laptop (a hp pavilion dv5046ea  running Fedora Core 5 x86_64).
 > > [ Here are the specifications for my laptop:
 > > http://h10010.www1.hp.com/wwpc/uk/en/ho/WF06b/21675-38187-38191-38191-38191-12319008-69074479.html]
 > >
 > >
 > > Support for my touchpad seems to have gotten worse rather than better in
 > > successive kernels from 2054 onwards.
 > >
 > > While on 2054 it generally works fine, On the latest kernels (2154, 2174
 > > etc.)  I have only to e.g. open a konqueror window for the onscreen pointer
 > > to start going funny, and jerking about (As happens on computers with v. low
 > > RAM).  I know its not a RAM problem, as a) everything else works fine, there
 > > is no slow down of any of the programs I run, only problems with the mouse
 > > and b) I have just upgraded from 512 MB of RAM to 1 GB.
 > >
 > > If I plug in a mouse, the pointer works fine.  Though I would happily use a
 > > mouse, this is often inconvenient on a laptop.
 > >
 > 
 > What kind of touchpad is this? Are you using synaptics X driver or
 > standard mouse driver? Also I am not quire sure what 2054 or 2154 is.
 > Can you please try vanilla kernels from kernel.org?
 > 
 > Dave, is there a place where one can see contents of a given RH kernel
 > (without downloadig and unpacking SRPM)?

There are cvs instructions at http://people.redhat.com/davej
A link to cvsweb is also there.

Quick version number mapping, based on cvs annotate kernel-2.6.spec ..

2054 - 2.6.16-rc6-git3
2154 - 2.6.17.3
2174 - 2.6.17.8


		Dave

-- 
http://www.codemonkey.org.uk

Re: Touchpad problems with latest kernels

[Gene Heskett]

On Monday 14 August 2006 11:06, Ian Stirling wrote:
>Gene Heskett wrote:
><snip>
>
>> I'm having similar problems with an HP Pavilian dv5220, and with a
>> bluetooth mouse dongle plugged into the right side usb port it works
>> just fine.  What I'd like to do is totally disable that synaptics pad
>> as its way too sensitive, making it impossible to type more than a line
>> or 2
>
>Enable the proper USB options, point X/GPM to /dev/input/mouse1 - or
>whatever.

Please describe how to do this and it will be done forthwith.

>It'd be nice if you could do this for keyboards too - but AIUI, you
> can't.

That too.  I've had the feeling but cannot nail it to the wall, that some 
of this IS keyboard related as it seems to happen much more frequently for 
some keypress combo's.  Typing a 't' is particularly dangerous, like the 
rollover protection is zip...
-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

Re: Touchpad problems with latest kernels

[Andreas Mohr]

On Mon, Aug 14, 2006 at 10:38:04AM -0400, Gene Heskett wrote:
> I don't *think* I'm a lunatic, but I'm equally sure that the synaptics is a 
> pain in the ass and should be capable of being totally disabled somehow, 
> hopefully short of opening the lappy up and unplugging or cutting every 
> lead to it until such time as it can be made to behave instead of 
> responding to every thumb waved 1/2 to 3/4" above it.  I've gotten hand 
> cramps trying to hold my thumbs far enough away from that abomination to 
> stop such goings on.
> 
> So count this as a vote FOR doing something about the synaptics touchpad 
> situation.

I'm seeing issues as well on my Dell Inspiron 8000 (yes, it has a Synaptics,
NOT ALPS as usual on Inspiron):

(without a mouse plugged in) after random times the pointer exhibits
clear signs of craziness, moving on its own (mild issue) or jumping
uncontrollably (worse) or being completely off-screen most of the time
(worst).

IIRC (I'm quite sure about this) the very first time that I've seen
this phenomenon happen on my notebook was around 2.6.9,
and I attributed this to broken/grown-old hardware on my notebook
(thus from then on mostly running with external mouse attached),
but since several people now report very similar issues
one would think that it's a driver calibration or touchpad setup issue
instead of actually broken touchpad hardware.

Plus, I'm sometimes having issues with pointer movement (cursor won't advance
any more unless I stop touching the touchpad for a few seconds to let it
reset somehow - probably a bytestream hickup issue).

Any clues?

Andreas Mohr

Re: Touchpad problems with latest kernels

[Mattia Dongili]

On Mon, Aug 14, 2006 at 11:13:38AM -0400, Dmitry Torokhov wrote:
> HI Gene,
> 
> On 8/14/06, Gene Heskett <gene.heskett@verizon.net> wrote:
[...]
> >making it impossible to type more than a line or 2
> >without the cursor suddenly jumping to someplace else in the message,
> >often highliteing several lines of text as it goes, and the next keystroke
> >then deletes wholesale quantities of text, thoroughly destroying any
> >chance of actually writing a cogent, understandable email response to
> >anyone.
> >
> 
> Have you tried synclient utility? It temporarily disables the touchpad
> when you start typing and re-enables it when you done.

oh, that should be the syndaemon ;)

-- 
mattia
:wq!

Re: Touchpad problems with latest kernels

[Gene Heskett]

On Monday 14 August 2006 11:13, Dmitry Torokhov wrote:
>HI Gene,
>
>On 8/14/06, Gene Heskett <gene.heskett@verizon.net> wrote:
>> I'm having similar problems with an HP Pavilian dv5220, and with a
>> bluetooth mouse dongle plugged into the right side usb port it works
>> just fine.  What I'd like to do is totally disable that synaptics pad
>> as its way too sensitive,
>
>Are you using synaptics X driver? It can be tweaked to adjust
>sensitivity and lots of other things.

No, I've tried to totally disable any references to it in the xorg.conf.  
Unsuccessfully it would appear, even so far as to say no effect from doing 
so.

>> making it impossible to type more than a line or 2
>> without the cursor suddenly jumping to someplace else in the message,
>> often highliteing several lines of text as it goes, and the next
>> keystroke then deletes wholesale quantities of text, thoroughly
>> destroying any chance of actually writing a cogent, understandable
>> email response to anyone.
>
>Have you tried synclient utility? It temporarily disables the touchpad
>when you start typing and re-enables it when you done.
>
Its not installed that I know of.  Availability?

>> Unforch, my questions along those lines have been treated as the
>> ravings of a lunatic and ignored.  The bios has no place to disable it,
>> dumbest bios I've seen in quite a while, and it has been updated in the
>> last 3 months.
>>
>> I don't *think* I'm a lunatic, but I'm equally sure that the synaptics
>> is a pain in the ass and should be capable of being totally disabled
>> somehow, hopefully short of opening the lappy up and unplugging or
>> cutting every lead to it until such time as it can be made to behave
>> instead of responding to every thumb waved 1/2 to 3/4" above it.  I've
>> gotten hand cramps trying to hold my thumbs far enough away from that
>> abomination to stop such goings on.
>>
>> So count this as a vote FOR doing something about the synaptics
>> touchpad situation.
>
>There are ways to disable it:
>
>echo -n "manual" > /sys/bus/serio/devices/serioX/bind_mode
bash: /sys/bus/serio/devices/serioX/bind_mode:  No such file or directory
>echo -n "none" > /sys/bus/serio/devices/serioXdrvctl
bash: /sys/bus/serio/devices/serioXdvrctl: Permission denied

The above is from a root bash shell while X is running the KDE desktop.
>
>This should disable it completely.

next step? :)

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

Re: Touchpad problems with latest kernels

[Dmitry Torokhov]

On 8/14/06, Andreas Mohr <andi@rhlx01.fht-esslingen.de> wrote:
> On Mon, Aug 14, 2006 at 10:38:04AM -0400, Gene Heskett wrote:
> > I don't *think* I'm a lunatic, but I'm equally sure that the synaptics is a
> > pain in the ass and should be capable of being totally disabled somehow,
> > hopefully short of opening the lappy up and unplugging or cutting every
> > lead to it until such time as it can be made to behave instead of
> > responding to every thumb waved 1/2 to 3/4" above it.  I've gotten hand
> > cramps trying to hold my thumbs far enough away from that abomination to
> > stop such goings on.
> >
> > So count this as a vote FOR doing something about the synaptics touchpad
> > situation.
>
> I'm seeing issues as well on my Dell Inspiron 8000 (yes, it has a Synaptics,
> NOT ALPS as usual on Inspiron):
>
> (without a mouse plugged in) after random times the pointer exhibits
> clear signs of craziness, moving on its own (mild issue) or jumping
> uncontrollably (worse) or being completely off-screen most of the time
> (worst).
>
> IIRC (I'm quite sure about this) the very first time that I've seen
> this phenomenon happen on my notebook was around 2.6.9,
> and I attributed this to broken/grown-old hardware on my notebook
> (thus from then on mostly running with external mouse attached),
> but since several people now report very similar issues
> one would think that it's a driver calibration or touchpad setup issue
> instead of actually broken touchpad hardware.
>
> Plus, I'm sometimes having issues with pointer movement (cursor won't advance
> any more unless I stop touching the touchpad for a few seconds to let it
> reset somehow - probably a bytestream hickup issue).
>
> Any clues?
>

Yes, you might want to reseat your touchpad connector and vacuum the
case a bit. Inspiron 8000 is almost the same as 8100 and I am using it
constantly ;) Well, I thought my keyboard broke because PgUp stopped
working but it recovered after I got a hairball from under the key.
Just make sure you do not pull ACPI battery info to often.

-- 
Dmitry

Re: Touchpad problems with latest kernels

[Ian Stirling]

Gene Heskett wrote:
> On Monday 14 August 2006 11:06, Ian Stirling wrote:
>> Gene Heskett wrote:
>> <snip>
>>
>>> I'm having similar problems with an HP Pavilian dv5220, and with a
>>> bluetooth mouse dongle plugged into the right side usb port it works
>>> just fine.  What I'd like to do is totally disable that synaptics pad
>>> as its way too sensitive, making it impossible to type more than a line
>>> or 2
>> Enable the proper USB options, point X/GPM to /dev/input/mouse1 - or
>> whatever.
> 
> Please describe how to do this and it will be done forthwith.

Actually - I think it should be stock.
Try cat /dev/input/mouse0 - and moving the mouse/trackpad. if this 
generates random text, then you're done.
/dev/input/mice is a fake device that globs all the mice in the system 
together.
/dev/input/mouse[n] is the nth mouse on the system.
Also - you can just go to device drivers/input - and disable the ps/2 
mouse driver.
Set up X and GPM to use /dev/input/mouse1 - if this is your USB mouse, 
and it just works.

Re: Touchpad problems with latest kernels

[Dmitry Torokhov]

On 8/14/06, Gene Heskett <gene.heskett@verizon.net> wrote:
> On Monday 14 August 2006 11:13, Dmitry Torokhov wrote:
> >HI Gene,
> >
> >On 8/14/06, Gene Heskett <gene.heskett@verizon.net> wrote:
> >> I'm having similar problems with an HP Pavilian dv5220, and with a
> >> bluetooth mouse dongle plugged into the right side usb port it works
> >> just fine.  What I'd like to do is totally disable that synaptics pad
> >> as its way too sensitive,
> >
> >Are you using synaptics X driver? It can be tweaked to adjust
> >sensitivity and lots of other things.
>
> No, I've tried to totally disable any references to it in the xorg.conf.
> Unsuccessfully it would appear, even so far as to say no effect from doing
> so.

Ok, so you are most likely using mousedev emulation mode. Not the best
choice with ALPS/Synaptics. I recommend usig specialized driver for X
(see below).

>
> >> making it impossible to type more than a line or 2
> >> without the cursor suddenly jumping to someplace else in the message,
> >> often highliteing several lines of text as it goes, and the next
> >> keystroke then deletes wholesale quantities of text, thoroughly
> >> destroying any chance of actually writing a cogent, understandable
> >> email response to anyone.
> >
> >Have you tried synclient utility? It temporarily disables the touchpad
> >when you start typing and re-enables it when you done.
> >
> Its not installed that I know of.  Availability?
>

http://web.telia.com/~u89404340/touchpad/
It is a part of Synaptics X driver. And I apologize, it is called
syndaemon, not synclient.

> >> Unforch, my questions along those lines have been treated as the
> >> ravings of a lunatic and ignored.  The bios has no place to disable it,
> >> dumbest bios I've seen in quite a while, and it has been updated in the
> >> last 3 months.
> >>
> >> I don't *think* I'm a lunatic, but I'm equally sure that the synaptics
> >> is a pain in the ass and should be capable of being totally disabled
> >> somehow, hopefully short of opening the lappy up and unplugging or
> >> cutting every lead to it until such time as it can be made to behave
> >> instead of responding to every thumb waved 1/2 to 3/4" above it.  I've
> >> gotten hand cramps trying to hold my thumbs far enough away from that
> >> abomination to stop such goings on.
> >>
> >> So count this as a vote FOR doing something about the synaptics
> >> touchpad situation.
> >
> >There are ways to disable it:
> >
> >echo -n "manual" > /sys/bus/serio/devices/serioX/bind_mode
> bash: /sys/bus/serio/devices/serioX/bind_mode:  No such file or directory
> >echo -n "none" > /sys/bus/serio/devices/serioXdrvctl
> bash: /sys/bus/serio/devices/serioXdvrctl: Permission denied
>
> The above is from a root bash shell while X is running the KDE desktop.
> >
> >This should disable it completely.
>
> next step? :)
>

serioX is the name of serio port your touchpad is connected to
(serio0, serio1, etc) You will have to look which port is bound to
psmouse driver.

-- 
Dmitry

Re: Touchpad problems with latest kernels

[Andreas Mohr]

On Mon, Aug 14, 2006 at 11:41:29AM -0400, Dmitry Torokhov wrote:
> On 8/14/06, Andreas Mohr <andi@rhlx01.fht-esslingen.de> wrote:
> >Plus, I'm sometimes having issues with pointer movement (cursor won't 
> >advance
> >any more unless I stop touching the touchpad for a few seconds to let it
> >reset somehow - probably a bytestream hickup issue).
> >
> >Any clues?
> >
> 
> Yes, you might want to reseat your touchpad connector and vacuum the
> case a bit. Inspiron 8000 is almost the same as 8100 and I am using it
> constantly ;) Well, I thought my keyboard broke because PgUp stopped
> working but it recovered after I got a hairball from under the key.

Hmm, might need to verify that, but I've been cleaning it from time to time
(Murphy tells me that it was the regular cleaning which broke it ;).

> Just make sure you do not pull ACPI battery info to often.

Uh... why!?

Andreas Mohr

-- 
No programming skills!? Why not help translate many Linux applications! 
https://launchpad.ubuntu.com/rosetta
(or alternatively buy nicely packaged Linux distros/OSS software to help
support Linux developers creating shiny new things for you?)

Re: Touchpad problems with latest kernels

[Dmitry Torokhov]

On 8/14/06, Andreas Mohr <andi@rhlx01.fht-esslingen.de> wrote:
> On Mon, Aug 14, 2006 at 11:41:29AM -0400, Dmitry Torokhov wrote:
> > On 8/14/06, Andreas Mohr <andi@rhlx01.fht-esslingen.de> wrote:
> > >Plus, I'm sometimes having issues with pointer movement (cursor won't
> > >advance
> > >any more unless I stop touching the touchpad for a few seconds to let it
> > >reset somehow - probably a bytestream hickup issue).
> > >
> > >Any clues?
> > >
> >
> > Yes, you might want to reseat your touchpad connector and vacuum the
> > case a bit. Inspiron 8000 is almost the same as 8100 and I am using it
> > constantly ;) Well, I thought my keyboard broke because PgUp stopped
> > working but it recovered after I got a hairball from under the key.
>
> Hmm, might need to verify that, but I've been cleaning it from time to time
> (Murphy tells me that it was the regular cleaning which broke it ;).
>

That could be too ;)

> > Just make sure you do not pull ACPI battery info to often.
>
> Uh... why!?
>

On many laptops (including mine) polling battery takes a loooong time
and is done in SMI mode in BIOS causing lost keypresses, jerky mouse
etc. It is pretty common problem. I think I have my ACPI client
refreshing every 3 minutes.

-- 
Dmitry

Re: Touchpad problems with latest kernels

[Gene Heskett]

On Monday 14 August 2006 11:53, Dmitry Torokhov wrote:
>On 8/14/06, Gene Heskett <gene.heskett@verizon.net> wrote:
>> On Monday 14 August 2006 11:13, Dmitry Torokhov wrote:
>> >HI Gene,
>> >
>> >On 8/14/06, Gene Heskett <gene.heskett@verizon.net> wrote:
>> >> I'm having similar problems with an HP Pavilian dv5220, and with a
>> >> bluetooth mouse dongle plugged into the right side usb port it works
>> >> just fine.  What I'd like to do is totally disable that synaptics
>> >> pad as its way too sensitive,
>> >
>> >Are you using synaptics X driver? It can be tweaked to adjust
>> >sensitivity and lots of other things.
>>
>> No, I've tried to totally disable any references to it in the
>> xorg.conf. Unsuccessfully it would appear, even so far as to say no
>> effect from doing so.
>
>Ok, so you are most likely using mousedev emulation mode. Not the best
>choice with ALPS/Synaptics. I recommend usig specialized driver for X
>(see below).
>
>> >> making it impossible to type more than a line or 2
>> >> without the cursor suddenly jumping to someplace else in the
>> >> message, often highliteing several lines of text as it goes, and the
>> >> next keystroke then deletes wholesale quantities of text, thoroughly
>> >> destroying any chance of actually writing a cogent, understandable
>> >> email response to anyone.
>> >
>> >Have you tried synclient utility? It temporarily disables the touchpad
>> >when you start typing and re-enables it when you done.
>>
>> Its not installed that I know of.  Availability?
>
>http://web.telia.com/~u89404340/touchpad/
>It is a part of Synaptics X driver. And I apologize, it is called
>syndaemon, not synclient.
>
>> >> Unforch, my questions along those lines have been treated as the
>> >> ravings of a lunatic and ignored.  The bios has no place to disable
>> >> it, dumbest bios I've seen in quite a while, and it has been updated
>> >> in the last 3 months.
>> >>
>> >> I don't *think* I'm a lunatic, but I'm equally sure that the
>> >> synaptics is a pain in the ass and should be capable of being
>> >> totally disabled somehow, hopefully short of opening the lappy up
>> >> and unplugging or cutting every lead to it until such time as it can
>> >> be made to behave instead of responding to every thumb waved 1/2 to
>> >> 3/4" above it.  I've gotten hand cramps trying to hold my thumbs far
>> >> enough away from that abomination to stop such goings on.
>> >>
>> >> So count this as a vote FOR doing something about the synaptics
>> >> touchpad situation.
>> >
>> >There are ways to disable it:
>> >
>> >echo -n "manual" > /sys/bus/serio/devices/serioX/bind_mode
>>
>> bash: /sys/bus/serio/devices/serioX/bind_mode:  No such file or
>> directory
>>
>> >echo -n "none" > /sys/bus/serio/devices/serioXdrvctl
>>
>> bash: /sys/bus/serio/devices/serioXdvrctl: Permission denied
>>
>> The above is from a root bash shell while X is running the KDE desktop.
>>
>> >This should disable it completely.
>>
>> next step? :)
>
>serioX is the name of serio port your touchpad is connected to
>(serio0, serio1, etc) You will have to look which port is bound to
>psmouse driver.

What if there appear to be two functional mice running the same curser?  
One being the M$ accessory mouse, the other the touchpad.  So I would have 
a serio0 and a serio1.  How do I determine which to feed those commands 
to?  Is the device identified in those info trees?

I've printed this for reference the next time I fire it up, as I'd just now 
shut it off after installing the synaptics driver and a few other updates.

Thanks.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

Re: Touchpad problems with latest kernels

[Dmitry Torokhov]

On 8/14/06, Gene Heskett <gene.heskett@verizon.net> wrote:
> >
> >serioX is the name of serio port your touchpad is connected to
> >(serio0, serio1, etc) You will have to look which port is bound to
> >psmouse driver.
>
> What if there appear to be two functional mice running the same curser?
> One being the M$ accessory mouse, the other the touchpad.  So I would have
> a serio0 and a serio1.  How do I determine which to feed those commands
> to?  Is the device identified in those info trees?
>

It depends... One serio is your keyboard port, another one is aux
(mouse). The external mouse - is it also PS/2 or is is USB? If it is
USB then it won't be listed under serio bus but rather in USB bus...
Look at /sys/bus/serio/devices/serioX/inputX/name attribute in sysfs -
it should give you a clue what device is connjected to a serio port.


-- 
Dmitry

Re: Touchpad problems with latest kernels

[Dmitry Torokhov]

On 8/14/06, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> On 8/14/06, Andreas Mohr <andi@rhlx01.fht-esslingen.de> wrote:
> >
> > (without a mouse plugged in) after random times the pointer exhibits
> > clear signs of craziness, moving on its own (mild issue) or jumping
> > uncontrollably (worse) or being completely off-screen most of the time
> > (worst).
> >

BTW, next time it gets stuck could you please do:

echo 1 > /sys/modules/i8042/parameters/debug

and if cursor is still stuck (or otherwise misbehaving) after that
send me your dmesg or /valog/log/kernel.

Thanks!

-- 
Dmitry

Polling for battery stauts and lost keypresses (was: Touchpad problems with latest kernels)

[Giuseppe Bilotta]

On Mon, 14 Aug 2006 12:06:06 -0400, Dmitry Torokhov wrote:

> On many laptops (including mine) polling battery takes a loooong time
> and is done in SMI mode in BIOS causing lost keypresses, jerky mouse
> etc. It is pretty common problem. I think I have my ACPI client
> refreshing every 3 minutes.

BTW, polling battery status takes a lot on a Dell Inspiron 8200 too,
and all keypresses and mouse movements (and I think even network
IRQs?) are totally *dead* while polling.

However, The Other OS(tm) *seems* to do it right enough to have no
noticeable keypress losses, even when updating the battery status. Is
it using different system calls, or what?

-- 
Giuseppe "Oblomov" Bilotta

[W]hat country can preserve its liberties, if its rulers are not
warned from time to time that [the] people preserve the spirit of
resistance? Let them take arms...The tree of liberty must be
refreshed from time to time, with the blood of patriots and
tyrants.
	-- Thomas Jefferson, letter to Col. William S. Smith, 1787

Re: Polling for battery stauts and lost keypresses (was: Touchpad problems with latest kernels)

[Dmitry Torokhov]

On 8/14/06, Giuseppe Bilotta <bilotta78@hotpop.com> wrote:
> On Mon, 14 Aug 2006 12:06:06 -0400, Dmitry Torokhov wrote:
>
> > On many laptops (including mine) polling battery takes a loooong time
> > and is done in SMI mode in BIOS causing lost keypresses, jerky mouse
> > etc. It is pretty common problem. I think I have my ACPI client
> > refreshing every 3 minutes.
>
> BTW, polling battery status takes a lot on a Dell Inspiron 8200 too,
> and all keypresses and mouse movements (and I think even network
> IRQs?) are totally *dead* while polling.
>
> However, The Other OS(tm) *seems* to do it right enough to have no
> noticeable keypress losses, even when updating the battery status. Is
> it using different system calls, or what?
>

I am not sure, but there are many things that may affect it:

1. Battry attributes are divided into 2 groups - static (i think they
go into /proc/acpi/battery/<name>/info and dynamic
(/proc/acpi/batetry/state). Static attributes take really long time to
pull and they do not change so it may wery well be they are polled one
at startup. Dynamic attributes are cheaper to poll and even then OS
may cache access or limit rate.

2. Quite often there are OEM drivers that are tweaked to a specific
hardware and involve hardware-specific hacks.

-- 
Dmitry

Re: Polling for battery stauts and lost keypresses

[Giuseppe Bilotta]

On Mon, 14 Aug 2006 16:17:01 -0400, Dmitry Torokhov wrote:

> On 8/14/06, Giuseppe Bilotta <bilotta78@hotpop.com> wrote:
>> On Mon, 14 Aug 2006 12:06:06 -0400, Dmitry Torokhov wrote:
>>
>>> On many laptops (including mine) polling battery takes a loooong time
>>> and is done in SMI mode in BIOS causing lost keypresses, jerky mouse
>>> etc. It is pretty common problem. I think I have my ACPI client
>>> refreshing every 3 minutes.
>>
>> BTW, polling battery status takes a lot on a Dell Inspiron 8200 too,
>> and all keypresses and mouse movements (and I think even network
>> IRQs?) are totally *dead* while polling.
>>
>> However, The Other OS(tm) *seems* to do it right enough to have no
>> noticeable keypress losses, even when updating the battery status. Is
>> it using different system calls, or what?
>>
> 
> I am not sure, but there are many things that may affect it:
> 
> 1. Battry attributes are divided into 2 groups - static (i think they
> go into /proc/acpi/battery/<name>/info and dynamic
> (/proc/acpi/batetry/state). Static attributes take really long time to
> pull and they do not change so it may wery well be they are polled one
> at startup. Dynamic attributes are cheaper to poll and even then OS
> may cache access or limit rate.

Well, this would explain why Linux freezes while polling only if Linux
polls for the slow, static ones just as much as it does for the
dynamic ones ...

> 2. Quite often there are OEM drivers that are tweaked to a specific
> hardware and involve hardware-specific hacks.

If I remember correctly (damn, I can't find a way to do a search on
the LKML archives ...) there was someone working on Dell stuff, at
least as far as fans and thermal sensors were concerned (based on the
code from Massimo Dal Zotto) to integrate them with the kernel sensors
framework. However, some of those patches where NACKed by someone from
Dell because they were sort of "guessy" about the addresses to poke
around to get the information, instead of using the data provided by
the BIOS on where to look for them ... however, there hasn't been any
news about that that stuff since ...

-- 
Giuseppe "Oblomov" Bilotta

"Da grande lotterò per la pace"
"A me me la compra il mio babbo"
(Altan)
("When I grow up, I will fight for peace"
 "I'll have my daddy buy it for me")

Re: Polling for battery stauts and lost keypresses

[Dmitry Torokhov]

On Wednesday 16 August 2006 03:31, Giuseppe Bilotta wrote:
> On Mon, 14 Aug 2006 16:17:01 -0400, Dmitry Torokhov wrote:
> 
> > 2. Quite often there are OEM drivers that are tweaked to a specific
> > hardware and involve hardware-specific hacks.
> 
> If I remember correctly (damn, I can't find a way to do a search on
> the LKML archives ...) there was someone working on Dell stuff, at
> least as far as fans and thermal sensors were concerned (based on the
> code from Massimo Dal Zotto) to integrate them with the kernel sensors
> framework. However, some of those patches where NACKed by someone from
> Dell because they were sort of "guessy" about the addresses to poke
> around to get the information, instead of using the data provided by
> the BIOS on where to look for them ... however, there hasn't been any
> news about that that stuff since ...
> 

As far as I remember that person from Dell was not ready to disclose
details of their SMBIOS :( so it naturally went nowhere.
 
-- 
Dmitry

Re: Polling for battery stauts and lost keypresses

[Arjan van de Ven]

On Sat, 2006-08-19 at 11:50 -0400, Dmitry Torokhov wrote:
> On Wednesday 16 August 2006 03:31, Giuseppe Bilotta wrote:
> > On Mon, 14 Aug 2006 16:17:01 -0400, Dmitry Torokhov wrote:
> > 
> > > 2. Quite often there are OEM drivers that are tweaked to a specific
> > > hardware and involve hardware-specific hacks.
> > 
> > If I remember correctly (damn, I can't find a way to do a search on
> > the LKML archives ...) there was someone working on Dell stuff, at
> > least as far as fans and thermal sensors were concerned (based on the
> > code from Massimo Dal Zotto) to integrate them with the kernel sensors
> > framework. However, some of those patches where NACKed by someone from
> > Dell because they were sort of "guessy" about the addresses to poke
> > around to get the information, instead of using the data provided by
> > the BIOS on where to look for them ... however, there hasn't been any
> > news about that that stuff since ...
> > 
> 
> As far as I remember that person from Dell was not ready to disclose
> details of their SMBIOS :( so it naturally went nowhere.

actually Dell did document their smbios ...

http://linux.dell.com/libsmbios/main/index.html

there was also a posting from Dell with details, but I assume that's
included in their libsmbios...

>  
-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com

Re: Polling for battery stauts and lost keypresses

[Giuseppe Bilotta]

On Sat, 19 Aug 2006 18:02:18 +0200, Arjan van de Ven wrote:

> actually Dell did document their smbios ...
> 
> http://linux.dell.com/libsmbios/main/index.html
> 
> there was also a posting from Dell with details, but I assume that's
> included in their libsmbios...

This is very good news. What is the best place to follow integration
of this with the sensor stuff currently used by Linux?

-- 
Giuseppe "Oblomov" Bilotta

Hic manebimus optime

Re: Polling for battery stauts and lost keypresses

[Dmitry Torokhov]

On 8/19/06, Arjan van de Ven <arjan@infradead.org> wrote:
> On Sat, 2006-08-19 at 11:50 -0400, Dmitry Torokhov wrote:
> > On Wednesday 16 August 2006 03:31, Giuseppe Bilotta wrote:
> > > On Mon, 14 Aug 2006 16:17:01 -0400, Dmitry Torokhov wrote:
> > >
> > > > 2. Quite often there are OEM drivers that are tweaked to a specific
> > > > hardware and involve hardware-specific hacks.
> > >
> > > If I remember correctly (damn, I can't find a way to do a search on
> > > the LKML archives ...) there was someone working on Dell stuff, at
> > > least as far as fans and thermal sensors were concerned (based on the
> > > code from Massimo Dal Zotto) to integrate them with the kernel sensors
> > > framework. However, some of those patches where NACKed by someone from
> > > Dell because they were sort of "guessy" about the addresses to poke
> > > around to get the information, instead of using the data provided by
> > > the BIOS on where to look for them ... however, there hasn't been any
> > > news about that that stuff since ...
> > >
> >
> > As far as I remember that person from Dell was not ready to disclose
> > details of their SMBIOS :( so it naturally went nowhere.
>
> actually Dell did document their smbios ...
>
> http://linux.dell.com/libsmbios/main/index.html
>
> there was also a posting from Dell with details, but I assume that's
> included in their libsmbios...
>

I could not find any fan control or temperature monitoring references
there. Maybe I missed them.

-- 
Dmitry

Re: Polling for battery stauts and lost keypresses

[Arjan van de Ven]

On Mon, 2006-08-21 at 08:34 -0400, Dmitry Torokhov wrote:
> On 8/19/06, Arjan van de Ven <arjan@infradead.org> wrote:
> > On Sat, 2006-08-19 at 11:50 -0400, Dmitry Torokhov wrote:
> > > On Wednesday 16 August 2006 03:31, Giuseppe Bilotta wrote:
> > > > On Mon, 14 Aug 2006 16:17:01 -0400, Dmitry Torokhov wrote:
> > > >
> > > > > 2. Quite often there are OEM drivers that are tweaked to a specific
> > > > > hardware and involve hardware-specific hacks.
> > > >
> > > > If I remember correctly (damn, I can't find a way to do a search on
> > > > the LKML archives ...) there was someone working on Dell stuff, at
> > > > least as far as fans and thermal sensors were concerned (based on the
> > > > code from Massimo Dal Zotto) to integrate them with the kernel sensors
> > > > framework. However, some of those patches where NACKed by someone from
> > > > Dell because they were sort of "guessy" about the addresses to poke
> > > > around to get the information, instead of using the data provided by
> > > > the BIOS on where to look for them ... however, there hasn't been any
> > > > news about that that stuff since ...
> > > >
> > >
> > > As far as I remember that person from Dell was not ready to disclose
> > > details of their SMBIOS :( so it naturally went nowhere.
> >
> > actually Dell did document their smbios ...
> >
> > http://linux.dell.com/libsmbios/main/index.html
> >
> > there was also a posting from Dell with details, but I assume that's
> > included in their libsmbios...
> >
> 
> I could not find any fan control or temperature monitoring references
> there. Maybe I missed them.
there was an lkml posting from a Dell guy with a full table, just that
my google skills seem to be not successful at locating it right now.

Re: Polling for battery stauts and lost keypresses

[Pavel Machek]

On Wed 16-08-06 09:31:48, Giuseppe Bilotta wrote:
> On Mon, 14 Aug 2006 16:17:01 -0400, Dmitry Torokhov wrote:
> 
> > On 8/14/06, Giuseppe Bilotta <bilotta78@hotpop.com> wrote:
> >> On Mon, 14 Aug 2006 12:06:06 -0400, Dmitry Torokhov wrote:
> >>
> >>> On many laptops (including mine) polling battery takes a loooong time
> >>> and is done in SMI mode in BIOS causing lost keypresses, jerky mouse
> >>> etc. It is pretty common problem. I think I have my ACPI client
> >>> refreshing every 3 minutes.
> >>
> >> BTW, polling battery status takes a lot on a Dell Inspiron 8200 too,
> >> and all keypresses and mouse movements (and I think even network
> >> IRQs?) are totally *dead* while polling.
> >>
> >> However, The Other OS(tm) *seems* to do it right enough to have no
> >> noticeable keypress losses, even when updating the battery status. Is
> >> it using different system calls, or what?
> >>
> > 
> > I am not sure, but there are many things that may affect it:
> > 
> > 1. Battry attributes are divided into 2 groups - static (i think they
> > go into /proc/acpi/battery/<name>/info and dynamic
> > (/proc/acpi/batetry/state). Static attributes take really long time to
> > pull and they do not change so it may wery well be they are polled one
> > at startup. Dynamic attributes are cheaper to poll and even then OS
> > may cache access or limit rate.
> 
> Well, this would explain why Linux freezes while polling only if Linux
> polls for the slow, static ones just as much as it does for the
> dynamic ones ...

I guess patch caching battery/*/state would be welcome.
-- 
Thanks for all the (sleeping) penguins.