Description of problem: I have a Dell XPS13 system with a Synaptics trackpad that works either in PS2 mode or in I2C mode. The I2C mode is much more powerful, but in Mageia it is forced into PS2 mode because the psmouse is compiled into the kernel instead of a module which would allow me to not load it on the XPS13. I cannot see any problems with it being a module and it causes trouble by not being a module. How reproducible: always. Reproducible: Steps to Reproduce:
On entering KDE I get a notice that I have two trackpads and the system cannot handle that. It obviously picks the PS2 instead of the I2C version. This disables for example the ability to switch off the trackpad while typing, scroll areas, etc.
Source RPM: kernel => kernel 3.19.3
Assignee: bugsquad => tmbSource RPM: kernel 3.19.3 => kernel-3.19.3
This is still a problem (Mageia 5 rc1) It is impossible to disable psmouse module if it is not a module, but compiled in. It needs to be compiled as a module not in the kernel. This makes the trackpad not very useable. And again, I cannot see what problems having this as a module would cause. (in .config need CONFIG_MOUSE_PS2=m instead of =y)
Hardware: i586 => x86_64Source RPM: kernel-3.19.3 => kernel-desktop-3.19.6
Note that in case there is a worry that things depend on psmouse being compliled in, Ubuntu has psmouse as a module. Ie, it seems to be OK to make this a module instead of the default compiled-in. (It is still compiled in in kernel 3.19.8-2)
Target Milestone: --- => Mageia 6
CC: (none) => lohmaier+mageia
for xps, using the following kernel parameters avoid the touchpad problems, at least I didn't get a "stuck in scrolling mode" with those so far. Not sure whether *all* parameters are needed, but they don't hurt - esp. the proto and the smartscroll one seem to be the ones that make the difference: psmouse.resetafter=0 psmouse.rate=1 psmouse.smartscroll=0 psmouse.proto=bare my reasoning: resetafter=0 don't try to reset the device if the psmouse one thinks something i s wrong â it is none of the psmouse business anyway (maybe the reason for completely frozen pointer, where click still works, but you cannot move anymore - again no idea whether this is really the cause, as I didn't bother testing individually) rate=1 no need to poll for updates more than 1 per second (not sure wehther 0 would completely disable or is invalid value) - again it is not the psmouse driver's job to move the pointer, so let it alone as much as possible. smartscroll=0 that what I assume is related to the touchpad-stuck-in-scroll effect, that most likely occurs in windows where both horizontal and vertical scroll is used - that alone might not do the trick without also setting the proto one proto=bare - if psmouse is loaded, then it should handle the least features to lessen the risk of messing around. I think this is the cause for two-finger-right-click and three-finger-middle-click behaving inpredictably. In addition to the kernel parameters, also make sure to have the pad set to clickpad: # cat /etc/X11/xorg.conf.d/99-xps-touchpad.conf # force the toucpad to clickpad Section "InputClass" Identifier "xps-touchpad" MatchProduct "DLL0665:01 06CB:76AD UNKNOWN" Driver "synaptics" Option "Clickpad" "on" EndSection with that configuration, you get the rightclick area at the bottom right of the pad (i.e. single-click is right-click in that area, while you need to use two-finger-click in the rest of the pad), and the two-finger-drag, or multi-finger-click register properly. (using Mga 5) If you don't want the right-kick area, set the RightClickArea values accordingly
But it is so so much simpler if psmouse is just no loaded at all. Then it is not there to fight with the I2S driver as to who controls the mouse. Of course if it is compiled into the kernel, as Mageia ( but not Fedora or Ubuntu) does it, then there is no option, and one has to go through contortions to stop it from making a mess while it fights with I2S. I cannot see any downside to having psmouse a module rather than compiled into the kernel. (Yes, initrd may have to have it loaded, but that it true of loads of modules anyway-- and it is pretty rare to have to use the mouse in the ram loader anyway.) Please please, make psmouse a module rather than compiled into the kernel, as both Ubuntu and Fedora have already done. (I also have no idea why the kernel has it compiled in in the default config but that is another issue.)
Still not a module in Cauldron for kernel 4.1.6
Still not a module in MGA5 update kernel 4.1.8 Please please can we not make this a module? It will not hurt anything AFAI can see, and it would make it usable for the Dell XPS13. The PS2 mouse messes up the trackpad on that machine.
tmb, what do you think of this proposal?
Arch Linux also has psmouse as a module.
I note that 4.2.6 in Cauldron still has psmouse compiled in rather than as a module. CONFIG_MOUSE_PS2=y
Let me repeat my request that psmouse be made a module rather than compiled in. It really is a pain on the Dell XPS13 to constantly have to recompile the kernel every time on an upgrade just to change the CONFIG_MOUSE_PS2=y to CONFIG_MOUSE_PS2=m in the config file. (I have tested again in Mga5 4.1.13) Please?
We usually dont change things like this in the middle of a stable release. just because "I cannot see any problems with it being a module" does not mean it wont introduce regressions... like for installer and so on... Having said that... any changes are always "cauldron first"... So... I will flip it to module in cauldron and watch the fallout... If it works out somewhat, I might consider doing it for mga5 too ...
First side effect seems to be bug#17470
CC: (none) => thierry.vignaud
Tnanks for making this a module. Apparently that bug 17470 was not due to this being a module.
fixed with 4.4.13 kernel - now it is a module and can be blacklisted - unfortunately 4.4.13 broke vaapi for me, see bug#18713
Status: NEW => RESOLVEDSee Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=18688Resolution: (none) => FIXED