Bug 141187

Kernel problem?

I'll need more info about the setup - at least the output of `dmesg` and the contents of '/proc/bus/input/devices' and '/var/log/Xorg.0.log'.

A month in NEEDINFO -> closing. If you can supply the data, please reopen.
Using 'psmouse.rate=40' on the kernel command line might help. If it does,
please reopen the bug and state so.

only a minor improvement was noted.

Please supply the data mentioned above. Also - you changed the version to
"Preview 3". Why? Does "attempting to move the cursor" mean using the arrow
keys or the touchpad itself?

"Preview 3" is a mistake, a change that was not intended.

Attemtping to move the cursor refers to using the touchpad itself.  (not the arrow keys).

"Preview 3" is a mistake, a change that was not intended.

Attemtping to move the cursor refers to using the touchpad itself.  (not the arrow keys).

OK, why only "after positioning the cursor"? I'd expect to give trouble all the time, but from your description it seems that only after the first use, which itself is fine?

English usage!  What I meant is:

When using the touchpad to move the cursor across the screen you may need to lift your finger and touch the pad in a different place to continue to move the cursor.  For example to move down a long list of applications.  On touching the touchpad, the second or third time, the cursor will jump randomly around the screen, usually in the direction from which you were moving.

The bug happens repeatedly both on the desktop and within an application.

Thanks for the explanation, I think I see where the problem is coming from then
(bad detection of touched/untouched state, causing the touchpad react to your finger before being fully touched). I'll still need the files mentioned earlier.

Created attachment 70058 [details]
Xorg Log

hopefully the requested files are attached.  dmesg cannot be found on my system!

It's almost impossible you don't have dmesg. Check thay the util-linux package
is installed.

Reloaded SUSE V10 in its entirity.

From a terminal window and logged in as root ran 

ls -laR dm* 

no file was found.  In looking through various files the only file vaguely similar was kmesg.

In which directory should dmesg reside?




 

/bin/dmesg

Created attachment 70550 [details]
output from dmesg

Thanks.  The output from dmesg is given in the attached file.  Do you now have the required infomation?

Yes, I believe I do.

No, I still miss the contents of the 

/proc/bus/input/devices

file. And I need it. So far it seems you're the first user of an _USB_ Synaptics touchpad I've met. We don't support those (only the PS/2) version at this time.
I can add that support for you, but I'll need quite a bit of cooperation, and
it will include recompiling the kernel modules.

Created attachment 71026 [details]
Devices

Thanks for the information provided.

The pad is detected as a standard USB mouse without any extra capabilities (like
absolute position or tap reporting). All the processing (including the jumping)
is done in hardware/firmware. There isn't anything I can do to fix it.

There is a last chance: The device may have an absolute mode that's switched
on by some magic HID report sent to the device. To confirm or eliminate that
possibility, I'll need the descriptor dump for the device. That can be obtained
either using 'lsusb -vv', or by #defining DEBUG in hid-core.c and hid-input.c
in the drivers/usb/input subdirectory of the kernel sources, recompiling, and
installing the new resulting HID module. For that, you of course need the
kernel development tools (C compiler, linker, etc), and the kernel sources
installed. All are available for install via yast.

Please provide the above information or close the bug as INVALID, because
that's the right option for hardware problems.

Created attachment 71151 [details]
lsusb output file

Thanks. Please re-run it as root, this way it misses the important bits - the report descriptors.

Created attachment 71243 [details]
lsusb file output when run as root

Please change the status back from NEEDINFO when you provide the requested
information - otherwise the bug stays hanging there without me looking at it.

Still the report information is missing even in the latest attachment.

Created attachment 79046 [details]
lsusb -vv listing

Requested info

Any further progress.  I note there has been no change with version 10.01

The report descriptors are still missing in your 'lsusb' listing. You
may need to unload the 'usbhid' module to be able to access them.

Could you please advise how to unload the 'usbhid' module

'rmmod usbhid' should do the trick. Your touchpad won't work after that operation
until you type 'modprobe usbhid' again, of course.

Created attachment 83931 [details]
lsusb listing 

Thank you for the instructions.  As the touchpad didnt't work (as warned) I assume the listing is correct.

Indeed, the listing is complete now. Thanks!

The listing confirms that there indeed isn't anything Linux can do about
the touchpad: All the touch processing is done inside it and Linux only
gets relative mouse movements.