None of the settings in the mouse applet work: mouse speed, left/right handedness, etc. various incantations of xinput seem to indicate none of the props/settings are changed when the widgets in the control center are tweaked.
What input drivers are you using?
evdev. I'm going to try -libinput.
Using xf86-input-libinput gives me my mouse speed back. And g-c-c is able to change its settings. So it's not just synaptics that's unsupported, all !libinput drivers are. For the record (because I had a hard time finding the right place to unmask the libinput USE flag): # cat /etc/portage/profile/use.mask -input_devices_libinput @x11, we should probably unmask INPUT_DEVICES="libinput". What say you? Cheers
Can confirm. I face the same issue unless emerging xf86-input-libinput. Emerging libinput resolves the issue
Unmasking video_cards_libinput right now would break visibility rules. Options are to just emerge xf86-input-libinput without setting that flag, or to mask it in profiles of arches that haven't keyworded it yet, then remove the global mask. Head over to bug 538828 if you wish to discuss.
What is pending to do in gnome-control-center side?
(In reply to Pacho Ramos from comment #6) > What is pending to do in gnome-control-center side? Maybe to RDEPEND on x11-drivers/xf86-input-libinput as it will be used at runtime in wayland and X setups :/
RDEPEND is not enough I guess, the X server must additionally be configured to actually use this driver. Not sure if there is an easy way to check for this from the ebuild.
We could indeed spend a lot of time trying to come up with clever ways to parse xorg.conf.d files, but I don't think it's worth it. Let's just mention it in the upgrade guide. It's a minor issue that's easily fixed.
Yeah, the idea would be to add it to RDEPEND as it is clearly used at runtime... (for X setups, wayland people will rely on libinput directly if I don't misunderstand). For the configuration part a tip in upgrade guide would be enough. My only concern is about what is the default in xorg side when all three drivers are present and NONE of them specified in xorg.conf. I mean, what happens if I don't have any xorg.conf and I have evdev+synaptics+libinput :/ Will it default to libinput over the others? (In Fedora it seems to be the case... but maybe they are patching it downstream)
Maybe an einfo or readme-r*.eclass or whatever thing? Outright RDEPEND doesn't seem that appropriate, maybe behind a X?, but still. Don't need it on wayland probably, also inability to configure it with others inside gnome control center doesn't mean it's a hard runtime requirement - one could configure it through other methods if desired. I don't know about upstream preference order, but our xf86-input-libinput package installs a /usr/share/X11/xorg.conf.d/90-libinput.conf to make use of it. xf86-input-evdev doesn't, and so is a fallback in some unknown order. I don't know what synaptics does, probably also ships a xorg.conf.d snippet, then it matters in what sourcing order they are in there.
/usr/share/X11/xorg.conf.d/10-evdev.conf is installed by >=xf86-input-evdev-2.10 and <x11-base/xorg-server-1.18 I presume 10-evdev.conf will take precedence over 60-libinput.conf but didn't actually verify.
I guess we added 10-evdev.conf in a later version than I've upgraded to? Either way, http://fedoraproject.org/wiki/Input_device_configuration#xorg.conf.d says alphabetically later entries override, so 60-libinput.conf ought to override 10-evdev.conf on what it has common as matching. Ideally I think actually gnome-control-center itself would detect that it isn't running with whatever input driver it needs to modify these settings and would warn as such and maybe disable the controls it can't modify with evdev and whatnot then...
OK, I have confirmed that having evdev, synaptics and libinput ends up still using evdev and synaptics :S As I see in Fedora and upstream page: http://pkgs.fedoraproject.org/cgit/rpms/xorg-x11-drv-libinput.git/tree/xorg-x11-drv-libinput.spec https://fedoraproject.org/wiki/Changes/LibinputForXorg#Upgrade.2Fcompatibility_impact https://www.freedesktop.org/wiki/Software/libinput/ It seems that we should rely on that conf file that we are shipping as "doc" installing it in the location to let Xorg to catch it Regarding the dep... it's clearly an RDEPEND when !wayland USE is unset... gnome-control-center will even drop an error in the terminal when running it telling you that you need to use libinput driver (but, well, the error is invisible if you are not running gnome-control-center from a terminal)
*** Bug 588182 has been marked as a duplicate of this bug. ***
[master 2770283] gnome-base/gnome-control-center: mouse panel needs a concrete set of plugins at runtime, we also need to handle the coexistance of wacom and libinput together (#580474) 1 file changed, 160 insertions(+) create mode 100644 gnome-base/gnome-control-center/gnome-control-center-3.20.1-r1.ebuild
http://who-t.blogspot.com.ee/2016/08/new-xserver-driver-sort-order.html
Yeah, also seeing: http://who-t.blogspot.com.es/2016/09/fedora-cinnamon-mate-and-broken-gnome.html https://lists.debian.org/debian-devel/2016/07/msg00266.html Looks like this is a bit difficult since all upstreams are simply fighting between them :S libinput is properly handled in Gnome, KDE and I think also XFCE and LXDE, while Cinnamon and MATE are completely avoiding it "until Ubuntu/Debian updates to it" I would opt for relying on a default enabled input_devices_libinput USE for this. With that USE we can pull the right drivers with the proper order, while people can still disable it to allow them to shoot them on their foot and, then, decide what desktop they want to break :/ Also this would help us to set defaults that "just work" from upstreams changing the default order every month (for now it is not a problem since they didn't yet released the new X version reordering everything... but sooner or later they will do... and probably they with move again in the next one as they are doing constantly) and we being always late to that changes as we are like 7 months delayed over other major distros.
Created attachment 448468 [details] gnome-control-center-3.20.1-r2.ebuild This was my idea... but it doesn't work as it seems it's not possible to default enable USE flags under "input_devices" (or it's not working on my case for other reason), also we would need to rely on base/package.use.mask for unmasking the USE as bug 538828 is still waiting for sparc to keyword it :S One workaround would be to rely on a "normal" USE flag (gnome?) to allow us to enable by default it (and, hence, gnome users getting the proper defaults), but being able to enable by default input_devices_libinput was looking to me more "elegant" and also more "explicit" :/
This looks like something for readme.eclass, or upgrade/configuration guide for Gnome 3.
(In reply to Pacho Ramos from comment #16) > [master 2770283] gnome-base/gnome-control-center: mouse panel needs a > concrete set of plugins at runtime, we also need to handle the coexistance > of wacom and libinput together (#580474) > 1 file changed, 160 insertions(+) > create mode 100644 > gnome-base/gnome-control-center/gnome-control-center-3.20.1-r1.ebuild I'm not fully happy with this concrete change either. Mainly due to the way USE=wayland is handled. 1) libinput is pulled in either way, no need to USE flag it (xf86-input-libinput will depend on it too) 2) Global USE=wayland does not mean to not support X. Most global USE=wayland users today have it set to play with it, but normally still use X11 sessions mainly. The !wayland ( ... ) construct means that it's broken for most USE=wayland users, or well, nothing improved from before this change.
It seems input_devices_libinput USE was finally unmasked :D Then, we could do this: - dev-libs/libinput is always a RDEPEND as reminded by leio (in the case of wayland it's used directly, in the case of X through x11-drivers/xf86-input-libinput - input_devices_libinput can be used to pull in x11-drivers/xf86-input-libinput as all the other users of that USE are doing - We need to enable that input_devices_libinput by default, I could retry to use +input_devices_libinput... but I think we should rely on a make.defaults file in our gnome profiles for that
(In reply to Pacho Ramos from comment #22) > It seems input_devices_libinput USE was finally unmasked :D > > Then, we could do this: > - dev-libs/libinput is always a RDEPEND as reminded by leio (in the case of > wayland it's used directly, in the case of X through > x11-drivers/xf86-input-libinput > - input_devices_libinput can be used to pull in > x11-drivers/xf86-input-libinput as all the other users of that USE are doing > - We need to enable that input_devices_libinput by default, I could retry to > use +input_devices_libinput... but I think we should rely on a make.defaults > file in our gnome profiles for that We could retake this now that finally input_devices_libinput USE was unmasked and stabilized on all arches and now that the default variable was modified to pull only libinput by default. I also prepared this wiki entry for trying to explain it further for the case we want to refer to that instead of clobbering elog messages: https://wiki.gentoo.org/wiki/Project:GNOME/GNOME3-Troubleshooting#Unable_to_change_mouse_settings_from_control_center In summary: - We all agree that dev-libs/libinput should be an unconditional RDEPEND as it's always used. - We need to be prepared for the latest versions (still in testing) of evdev/libinput/synaptics drivers. The wiki entry is prepared thinking on that. In summary, people must either rely on current default for INPUT_DRIVERS or manually change it in their make.conf to *only* list libinput there. One option is to use input_devices_libinput? to pull in >=x11-drivers/xf86-input-libinput-0.23 (we need that version to ensure all the default config files from upstreams are installed with the order we are predicting... that is now, finally: synaptics and evdev would take more preference that libinput... because upstream thinks that most people should *uninstall* that old drivers if they don't really need them and, then, when installed, they assume they must be used to cover some strange corner case). The other option is to not has this conditional dependency and rely on the right libinput X11 driver being present thanks to our current defaults x11-base/xorg-drivers pulling the needed driver in that case. But I think we should ensure that libinput Xorg driver is pulled anyway :/ Apart of that, we should add two has_version warnings to check if x11-drivers/xf86-input-synaptics and x11-drivers/xf86-input-evdev are present (as maybe they were installed manually or in other way). Those warnings would point people to https://wiki.gentoo.org/wiki/Project:GNOME/GNOME3-Troubleshooting#Unable_to_change_mouse_settings_from_control_center
This is probably obsolete at present time... or is there anything pending to do?
