Hi All,
As explained here: https://fedoraproject.org/wiki/Changes/LibinputForXorg
We want to move the input stack for xorg over to libinput, the plan is to do this move gradually, starting with moving GNOME / the desktop product over.
Upstream GNOME is already working on adding support for xf86-input-libinput's configuration API, once that lands xorg-x11-drv-libinput should be added to the Desktop's set of default packages, hence this mail.
So 2 questions:
1) Any objections against these changes ? 2) Who will add the package to the default package set when the time comes ?
Regards,
Hans
On Mon, Jan 12, 2015 at 11:37 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi All,
As explained here: https://fedoraproject.org/wiki/Changes/LibinputForXorg
We want to move the input stack for xorg over to libinput, the plan is to do this move gradually, starting with moving GNOME / the desktop product over.
Upstream GNOME is already working on adding support for xf86-input-libinput's configuration API, once that lands xorg-x11-drv-libinput should be added to the Desktop's set of default packages, hence this mail.
So 2 questions:
- Any objections against these changes ?
Not from me.
- Who will add the package to the default package set when the time
comes ?
Anyone with commit access can do that ... just ping that thread "when the time comes" ;)
On Mon, Jan 12, 2015 at 11:47 AM, drago01 drago01@gmail.com wrote:
On Mon, Jan 12, 2015 at 11:37 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi All,
As explained here: https://fedoraproject.org/wiki/Changes/LibinputForXorg
We want to move the input stack for xorg over to libinput, the plan is to do this move gradually, starting with moving GNOME / the desktop product over.
Upstream GNOME is already working on adding support for xf86-input-libinput's configuration API, once that lands xorg-x11-drv-libinput should be added to the Desktop's set of default packages, hence this mail.
One question though ... if both libinput and synapics are installed which one will X pick? (asking because of upgrades).
Hi,
On 12-01-15 11:48, drago01 wrote:
On Mon, Jan 12, 2015 at 11:47 AM, drago01 drago01@gmail.com wrote:
On Mon, Jan 12, 2015 at 11:37 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi All,
As explained here: https://fedoraproject.org/wiki/Changes/LibinputForXorg
We want to move the input stack for xorg over to libinput, the plan is to do this move gradually, starting with moving GNOME / the desktop product over.
Upstream GNOME is already working on adding support for xf86-input-libinput's configuration API, once that lands xorg-x11-drv-libinput should be added to the Desktop's set of default packages, hence this mail.
One question though ... if both libinput and synapics are installed which one will X pick? (asking because of upgrades).
xorg-x11-drv-libinput will be preferred over the old evdev / synaptics drivers if both are installed.
Regards,
Hans
On Mon, Jan 12, 2015 at 11:51 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 12-01-15 11:48, drago01 wrote:
On Mon, Jan 12, 2015 at 11:47 AM, drago01 drago01@gmail.com wrote:
On Mon, Jan 12, 2015 at 11:37 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi All,
As explained here: https://fedoraproject.org/wiki/Changes/LibinputForXorg
We want to move the input stack for xorg over to libinput, the plan is to do this move gradually, starting with moving GNOME / the desktop product over.
Upstream GNOME is already working on adding support for xf86-input-libinput's configuration API, once that lands xorg-x11-drv-libinput should be added to the Desktop's set of default packages, hence this mail.
One question though ... if both libinput and synapics are installed which one will X pick? (asking because of upgrades).
xorg-x11-drv-libinput will be preferred over the old evdev / synaptics drivers if both are installed.
OK.
On Mon, Jan 12, 2015 at 5:55 AM, drago01 drago01@gmail.com wrote:
On Mon, Jan 12, 2015 at 11:51 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 12-01-15 11:48, drago01 wrote:
On Mon, Jan 12, 2015 at 11:47 AM, drago01 drago01@gmail.com wrote:
On Mon, Jan 12, 2015 at 11:37 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi All,
As explained here: https://fedoraproject.org/wiki/Changes/LibinputForXorg
We want to move the input stack for xorg over to libinput, the plan is to do this move gradually, starting with moving GNOME / the desktop product over.
Upstream GNOME is already working on adding support for xf86-input-libinput's configuration API, once that lands xorg-x11-drv-libinput should be added to the Desktop's set of default packages, hence this mail.
One question though ... if both libinput and synapics are installed which one will X pick? (asking because of upgrades).
xorg-x11-drv-libinput will be preferred over the old evdev / synaptics drivers if both are installed.
OK.
So from the thread on devel@, it seems KDE is going to have issues with libinput in the F22 timeframe. While GNOME is the base DE for Workstation, KDE was supposed to be a focus area for Workstation with this release. We have the qt theme under review already, etc.
How does this all play out? Aren't we going to face the same problems here that the KDE spin does?
josh
Hi,
On 12-01-15 13:46, Josh Boyer wrote:
On Mon, Jan 12, 2015 at 5:55 AM, drago01 drago01@gmail.com wrote:
On Mon, Jan 12, 2015 at 11:51 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 12-01-15 11:48, drago01 wrote:
On Mon, Jan 12, 2015 at 11:47 AM, drago01 drago01@gmail.com wrote:
On Mon, Jan 12, 2015 at 11:37 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi All,
As explained here: https://fedoraproject.org/wiki/Changes/LibinputForXorg
We want to move the input stack for xorg over to libinput, the plan is to do this move gradually, starting with moving GNOME / the desktop product over.
Upstream GNOME is already working on adding support for xf86-input-libinput's configuration API, once that lands xorg-x11-drv-libinput should be added to the Desktop's set of default packages, hence this mail.
One question though ... if both libinput and synapics are installed which one will X pick? (asking because of upgrades).
xorg-x11-drv-libinput will be preferred over the old evdev / synaptics drivers if both are installed.
OK.
So from the thread on devel@, it seems KDE is going to have issues with libinput in the F22 timeframe. While GNOME is the base DE for Workstation, KDE was supposed to be a focus area for Workstation with this release. We have the qt theme under review already, etc.
How does this all play out? Aren't we going to face the same problems here that the KDE spin does?
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.
Regards,
Hans
On Mon, Jan 12, 2015 at 2:28 PM, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 12-01-15 13:46, Josh Boyer wrote:
On Mon, Jan 12, 2015 at 5:55 AM, drago01 drago01@gmail.com wrote:
On Mon, Jan 12, 2015 at 11:51 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 12-01-15 11:48, drago01 wrote:
On Mon, Jan 12, 2015 at 11:47 AM, drago01 drago01@gmail.com wrote:
On Mon, Jan 12, 2015 at 11:37 AM, Hans de Goede hdegoede@redhat.com wrote: > > > Hi All, > > As explained here: > https://fedoraproject.org/wiki/Changes/LibinputForXorg > > We want to move the input stack for xorg over to libinput, the plan > is to do this move gradually, starting with moving GNOME / the > desktop product over. > > Upstream GNOME is already working on adding support for > xf86-input-libinput's configuration API, once that lands > xorg-x11-drv-libinput should be added to the Desktop's set of default > packages, hence this mail. >
One question though ... if both libinput and synapics are installed which one will X pick? (asking because of upgrades).
xorg-x11-drv-libinput will be preferred over the old evdev / synaptics drivers if both are installed.
OK.
So from the thread on devel@, it seems KDE is going to have issues with libinput in the F22 timeframe. While GNOME is the base DE for Workstation, KDE was supposed to be a focus area for Workstation with this release. We have the qt theme under review already, etc.
How does this all play out? Aren't we going to face the same problems here that the KDE spin does?
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.
Hi,
On 12-01-15 15:45, drago01 wrote:
On Mon, Jan 12, 2015 at 2:28 PM, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 12-01-15 13:46, Josh Boyer wrote:
On Mon, Jan 12, 2015 at 5:55 AM, drago01 drago01@gmail.com wrote:
On Mon, Jan 12, 2015 at 11:51 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 12-01-15 11:48, drago01 wrote:
On Mon, Jan 12, 2015 at 11:47 AM, drago01 drago01@gmail.com wrote: > > > On Mon, Jan 12, 2015 at 11:37 AM, Hans de Goede hdegoede@redhat.com > wrote: >> >> >> Hi All, >> >> As explained here: >> https://fedoraproject.org/wiki/Changes/LibinputForXorg >> >> We want to move the input stack for xorg over to libinput, the plan >> is to do this move gradually, starting with moving GNOME / the >> desktop product over. >> >> Upstream GNOME is already working on adding support for >> xf86-input-libinput's configuration API, once that lands >> xorg-x11-drv-libinput should be added to the Desktop's set of default >> packages, hence this mail. >>
One question though ... if both libinput and synapics are installed which one will X pick? (asking because of upgrades).
xorg-x11-drv-libinput will be preferred over the old evdev / synaptics drivers if both are installed.
OK.
So from the thread on devel@, it seems KDE is going to have issues with libinput in the F22 timeframe. While GNOME is the base DE for Workstation, KDE was supposed to be a focus area for Workstation with this release. We have the qt theme under review already, etc.
How does this all play out? Aren't we going to face the same problems here that the KDE spin does?
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 ?
Regards,
Hans
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
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.
Cheers, Peter
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
----- Original Message -----
From: "Hans de Goede" hdegoede@redhat.com To: desktop@lists.fedoraproject.org Sent: Tuesday, January 13, 2015 4:21:52 AM Subject: Re: Adding xorg-x11-drv-libinput to the Desktop's set of default packages
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.
This does not sound good to me and it sounds like it would be in breach of one of the defined principles of the Fedora Workstation: "The Workstation working group will define a set of packages that are considered required be installed in order for the system to qualify as a Fedora Workstation. Through policy users will be strongly advised against uninstalling any of these packages and there will also be no option in the graphical software installer to uninstall them. Any optional packages for the Fedora Workstation can not obsolete or in any other way try to remove or disable these packages."
This seems to fall foul with the last sentence since it disables one of the standard packages of the Workstation.
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 ?
I prefer this one, as per the policy mentioned above this way at least people make an active choice to 'mess up' their system as opposed to packages being installed doing it 'silently'.
Christian
Christian Schaller wrote:
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 ?
I prefer this one, as per the policy mentioned above this way at least people make an active choice to 'mess up' their system as opposed to packages being installed doing it 'silently'.
That option still kinda sucks. kcm_touchpad would essentially be broken, until some other package is removed (if I'm understanding this right).
I suppose adding a Conflicts: xorg-x11-drv-libinput to kcm-touchpad isn't a viable option either.
On the other hand, if this cannot be toggled at install/runtime somehow, the original suggestion may be the least bad option.
-- rex
On Tue, Jan 13, 2015 at 12:15:34PM -0600, Rex Dieter wrote:
Christian Schaller wrote:
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 ?
I prefer this one, as per the policy mentioned above this way at least people make an active choice to 'mess up' their system as opposed to packages being installed doing it 'silently'.
That option still kinda sucks. kcm_touchpad would essentially be broken, until some other package is removed (if I'm understanding this right).
I suppose adding a Conflicts: xorg-x11-drv-libinput to kcm-touchpad isn't a viable option either.
On the other hand, if this cannot be toggled at install/runtime somehow, the original suggestion may be the least bad option.
I had a look at the kcm_touchpad code and it's not that complicated to make it support both drivers. Current tree with a couple of things converted is here https://github.com/whot/kcm_touchpad/tree/wip/libinput-support
So making something that provides the basic config toggles to enable tapping, scrolling and natural scrolling isn't that hard. The main problem with kcm_touchpad is that it's essentially a graphical mirror to almost all synaptics config options. With libinput there are a lot less toggles, so most of that UI is now greyed out (or not, which is buggy).
I contacted the maintainers, but I think fixing this in time may be viable, so we don't have to worry about hacks to partially disable it.
Question becomes: are we willing to ship this as a Fedora patch if need be?
Cheers, Peter
Peter Hutterer wrote:
I contacted the maintainers, but I think fixing this in time may be viable, so we don't have to worry about hacks to partially disable it.
Question becomes: are we willing to ship this as a Fedora patch if need
Yes, that would be preferable to other options I've seen so far.
-- Rex
----- Original Message -----
On Mon, Jan 12, 2015 at 2:28 PM, Hans de Goede hdegoede@redhat.com wrote: 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.
As far as I understand, KDE upstream is now porting configuration module to KDE Frameworks 5 - so it means they already have quite a lot of work ahead but on the other hand, it wouldn't be a bad idea to start new port with libinput, as it seems to be preferred way in the future. So maybe worth talking to them and in a best case, we could get both in F22 timeframe...
Jaroslav
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Mon, Jan 12, 2015 at 4:24 PM, Jaroslav Reznik jreznik@redhat.com wrote:
----- Original Message -----
On Mon, Jan 12, 2015 at 2:28 PM, Hans de Goede hdegoede@redhat.com wrote: 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.
As far as I understand, KDE upstream is now porting configuration module to KDE Frameworks 5 - so it means they already have quite a lot of work ahead [...]
Also note https://bugs.freedesktop.org/show_bug.cgi?id=88215 ... unlikely to end up in F22 but at some point "just not installing synaptics" wouldn't be enough (unless the xserver gets changes to prefer it but that would cause issues with upgrades).
desktop@lists.fedoraproject.org
-
Christian Schaller -
drago01 -
Hans de Goede -
Jaroslav Reznik -
Josh Boyer -
Peter Hutterer -
Rex Dieter