Hi,
On 13-01-15 00:48, Peter Hutterer wrote:
On Mon, Jan 12, 2015 at 04:12:01PM +0100, Hans de Goede wrote:
[...]
Running KDE apps on top of the GNOME desktop will not be affected,
actually even with xorg-x11-drv-libinput installed KDE itself will
still work fine, the only thing which will not work is KDE's configuration
applet for configuring touchpad settings like tap-to-click.
If KDE users have xorg-x11-drv-libinput installed (somehow) and they
want something else then the default touchpad behaviour they can still
get it but the will need to use xinput from the commandline to change
the settings; or they can simply do "rpm -e xorg-x11-drv-libinput",
restart X and have everything as it was in F-21, even if they started
with the desktop product.
We are planning a gradual transition here, where both the old and new
xorg drivers will be supported, independent of the DE really, but we
would like to slowly move towards the new driver, so for F-22 the plan
is to have GNOME's input configuration bits know how to talk to either
driver, and have the new driver installed by default on the desktop
product.
Can't we just make whatever the package that contains the KDE control
panel to carry a /etc/X11/xorg.conf.d/ snippet that enables the
synaptics driver?
That way you get libinput by default and synaptics if you install KDE
... as GNOME handles both it won't break GNOME.
In F23 once KDE is ported we can stop shipping that file.
Hmm, interesting suggestion, I've been unable to find clear documentation
on the ordering of parsing xorg.conf.d snippets in general, and the
ordering of parsing stuff under /usr/share/X11 vs under /etc .
Peter, can you shed some light on the parsing ordering (we should really
add something about this to "man xorg.conf".
Peter, what do you think about Draco's suggestion ?
The lookup order is (in lowest priority first):
/usr/share/X11/xorg.conf.d
/etc/X11/xorg.conf.d/
/etc/X11/xorg.conf
with the directories being read in sorted order (but /etc always overrides
/usr). we only ship snippets in /usr/share and leave /etc up to the user, so
that's what KDE would have to do as well.
There are two drawbacks to this approach:
First, we can't remove synaptics/evdev because many people have a
copy-pasted InputClass snippet that includes the Driver "synaptics" or
"evdev" line. That'll override any system config so if we don't have the
drivers installed those users get dead devices. Fixable in the server by
setting libinput if the module isn't present but that needs to be done
upstream first.
Second, config files can only add up and override, not remove options. But
we can match on already-assigned driver, so this should work:
Section "InputClass"
Identifier "restore synaptics"
MatchDriver "libinput"
MatchIsTouchpad "on"
Driver "synaptics"
EndSection
Ah yes, that should work, and kcm_touchpad could install that with a high
priority. That might be a good solution, I say might because I'm not 100% sold
on this, this means that a user installing KDE once, just to give it a try,
will then be moved back to synaptics and things will stay that way.
It may be better to just tell people to do "rpm -e xorg-x11-drv-libinput" if
they started with the Workstation product and want to use kcm_touchpad, AFAIK
kcm_touchpad will register itself with the KDE control-panel if the synaptics
driver is loaded, so if we end up using libinput kcm_touchpad will simple not
show, rather then break.
So opinions on this anyone ?
Note ideally someone would step up to make kcm_touchpad work with libinput,
that likely needs to happen eventually anyways, see e.g. also :
https://bugs.freedesktop.org/show_bug.cgi?id=88215
that then needs to have a higher sort-order than whatever assigns libinput.
I think that's the sanest plan. It's still nasty because _installing_ a
package will change your config rather than running it. But the only way out
of that would be to have the DM write out a config on-the-fly if a KDE is
started. Doable, but more room for error and given it's meant to be
temporary not worth the effort.
Regards,
Hans
--
desktop mailing list
desktop@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/desktop
