I reckon this configuration is standard for /etc/X11/xorg.conf.d/50-synaptics.conf
Section "InputClass"
Identifier "touchpad catchall"
Driver "synaptics"
MatchIsTouchpad "on"
# This option is recommend on all Linux systems using evdev, but cannot be
# enabled by default. See the following link for details:
# http://who-t.blogspot.com/2010/11/how-to-ignore-configuration-errors.html
MatchDevicePath "/dev/input/event*"
Option "HorizScrollDelta" "0"
# enable tap-to-click as default (bnc#722457)
Option "TapButton1" "1"
Option "TapButton3" "2"
Option "TapButton2" "3"
EndSection
Section "InputClass"
Identifier "touchpad ignore duplicates"
MatchIsTouchpad "on"
MatchOS "Linux"
MatchDevicePath "/dev/input/mouse*"
Option "Ignore" "on"
EndSection
# This option enables the bottom right corner to be a right button on
# non-synaptics clickpads.
# This option is only interpreted by clickpads.
Section "InputClass"
Identifier "Default clickpad buttons"
MatchDriver "synaptics"
Option "SoftButtonAreas" "50% 0 82% 0 0 0 0 0"
# To disable the bottom edge area so the buttons only work as buttons,
# not for movement, set the AreaBottomEdge
# Option "AreaBottomEdge" "82%"
EndSection
I do additionally have this on my 13.1 system though, but that shouldn’t be relevant for you:
# This option disables software buttons on Apple touchpads.
# This option is only interpreted by clickpads.
Section "InputClass"
Identifier "Disable clickpad buttons on Apple touchpads"
MatchProduct "Apple|bcm5974"
MatchDriver "synaptics"
Option "SoftButtonAreas" "0 0 0 0 0 0 0 0"
EndSection
[/QUOTE]
The rest is 100% identical to what you posted.
I have tried Live USB from Ubuntu, LinuxMint and Fedora, in addition to previous OpenSUSE Factory Live. The ElanTech Touchpad did not work in any of them.
Well, then we can at least say that this is not an openSUSE-specific issue.
So a bug report upstream would probably be better suited. The question is just what upstream. Kernel? Xorg?
Hopefully the openSUSE Xorg maintainers (to whom your bug report is assigned now) will clarify that if they cannot help themselves.
Btw, you as reporter should not change the bug priority yourself. The priority is intended to be used by the developers/maintainers only:
Priority
This field describes the importance and order in which a bug should be fixed. This field is utilized by the programmers/engineers to prioritize their work to be done. The available priorities range from P1 (most important) to P5 (least important).
Yes, I was a little unsure whether to change the priority. I felt it was a bit more urgent than medium as it is impossible to use the laptop without an extra mouse.
After I reported the bug, they(SUSE) changed component from Kernel to X.Org.
device appears in Xorg log, so it might not be a kernel problem
AFAICS (from the “bug activity”), you originally filed the bug against the component “Usability” (not “Kernel”). Somebody from the Maintainance team (who’s neither involved in kernel nor Xorg development AFAIK) then re-assigned it to Xorg, based on the assumption that it’s maybe no kernel bug as Xorg actually sees the device.
That doesn’t necessarily mean that it is indeed an Xorg bug. It could be a bug in the kernel driver nonetheless.
Anyway, I would suggest to wait for a response from the Xorg maintainers before taking further actions.
Maybe they will ask you for further information/ask you to try certain things to find out more, they might re-assign it to “Kernel” if they think that’s where’s the problem is located, or they might tell you to report it upstream.
I have checked a little on Xorg web site. X11R7.6 was released in 2010, while X11R7.7 was released in 2012. I’m not sure how this relates to 1.14.x and 1.16.x versions.
I take the 7.6 from opensuse xorg-x11-server and deduce that it is X11R7.6 (Am I right?). Do we have xorg-x11-server X11R7.7 in any opensuse repository I could try out?
Anyway:
I just checked the source code for x86-input-synaptics 1.7.1 and this fix I mentioned is there.
It looks it is targeted for v3 of Elantech touchpads. I believe I have v4 in my laptop.
That’s the overall version of the whole Xorg distribution release.
See here for an overview which Xorg release contained which versions of the individiual modules: http://www.x.org/wiki/Releases/ModuleVersions/
As openSUSE packages all the modules independently, this is completely irrelevant.
Only the particular package’s version counts.
And most (if not all) of them are even newer in openSUSE than in the X11R7.7 release.
I’m not sure how this relates to 1.14.x and 1.16.x versions.
This is the version of xorg-server.
X11R7.6 had 1.9.3, R7.7 had 1.12.2.
Both are much older than either 1.14.x or 1.16.x, obviously.
I take the 7.6 from opensuse xorg-x11-server and deduce that it is X11R7.6 (Am I right?).
Yes. At least originally I think.
Probably they just didn’t bother or forgot to update the version number, because they don’t package (or track) the Xorg releases as a whole anyway.
In the end, it doesn’t really matter anyway. Each package has its own version number.
I suppose that version number is just a relict from older times when openSUSE did in fact package the Xorg releases, in one/a few large package(s).
Do we have xorg-x11-server X11R7.7 in any opensuse repository I could try out?
Not that I know of, and it wouldn’t make a difference.
I think the following could help. Building a new kernel without
CONFIG_MOUSE_PS2_ELANTECH
and
CONFIG_MOUSE_PS2: as modul
This should avoid the detection of the touchpad and the touch pad fall back to a generic ps2 mouse and you can use it as a mouse.
I will test it on a fujitsu H730 with a recompiled kernel-3.11.10_21_desktop-1
The new kernel is no longer detecting ElanTech Touchpad and x11 maps this device to a PS/2 Logitech Wheel Mouse, which is an acceptable short term solution.
Sure.
Just cd into the source directory (/usr/src/linux-xxx/), run “make cloneconfig” to configure the kernel the same way your running kernel is configured.
Then edit the file .config in a text editor (or use “make menuconfig”/“make xconfig” to edit it) the way de008106 described, run “make all” to build the kernel and then “make install” to install it (should also add an entry to the boot menu).
The workaround works with every new kernel. The general idea is to avoid detection of the elan protocol. If the kernel is no longer detecting the elan touchpad the new touchpad is no longer the issue and X11 takes a surrogate. In this case a PS2 wheel mouse, which is quite good.
To build a kernel is easy.
Unfortunately this is needed because the elan protocol is part of a kernel option and not a loadable module.
rpm -qa | grep kernel
shows you the kernel you have
with zypper or the suse software search tool you have to install