4:37 a.m.
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
4:47 a.m.
On Mon, Jan 12, 2015 at 11:37 AM, Hans de Goede <hdegoede(a)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:
1) Any objections against these changes ?
Not from me.
2) 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" ;)
4:48 a.m.
On Mon, Jan 12, 2015 at 11:47 AM, drago01 <drago01(a)gmail.com> wrote:
On Mon, Jan 12, 2015 at 11:37 AM, Hans de Goede
<hdegoede(a)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).
4:51 a.m.
Hi,
On 12-01-15 11:48, drago01 wrote:
On Mon, Jan 12, 2015 at 11:47 AM, drago01 <drago01(a)gmail.com>
wrote:
> On Mon, Jan 12, 2015 at 11:37 AM, Hans de Goede <hdegoede(a)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
4:55 a.m.
On Mon, Jan 12, 2015 at 11:51 AM, Hans de Goede <hdegoede(a)redhat.com> wrote:
Hi,
On 12-01-15 11:48, drago01 wrote:
>
> On Mon, Jan 12, 2015 at 11:47 AM, drago01 <drago01(a)gmail.com> wrote:
>>
>> On Mon, Jan 12, 2015 at 11:37 AM, Hans de Goede <hdegoede(a)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.
6:46 a.m.
On Mon, Jan 12, 2015 at 5:55 AM, drago01 <drago01(a)gmail.com> wrote:
On Mon, Jan 12, 2015 at 11:51 AM, Hans de Goede
<hdegoede(a)redhat.com> wrote:
> Hi,
>
>
> On 12-01-15 11:48, drago01 wrote:
>>
>> On Mon, Jan 12, 2015 at 11:47 AM, drago01 <drago01(a)gmail.com> wrote:
>>>
>>> On Mon, Jan 12, 2015 at 11:37 AM, Hans de Goede <hdegoede(a)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
7:28 a.m.
Hi,
On 12-01-15 13:46, Josh Boyer wrote:
On Mon, Jan 12, 2015 at 5:55 AM, drago01 <drago01(a)gmail.com>
wrote:
> On Mon, Jan 12, 2015 at 11:51 AM, Hans de Goede <hdegoede(a)redhat.com> wrote:
>> Hi,
>>
>>
>> On 12-01-15 11:48, drago01 wrote:
>>>
>>> On Mon, Jan 12, 2015 at 11:47 AM, drago01 <drago01(a)gmail.com> wrote:
>>>>
>>>> On Mon, Jan 12, 2015 at 11:37 AM, Hans de Goede
<hdegoede(a)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
8:45 a.m.
On Mon, Jan 12, 2015 at 2:28 PM, Hans de Goede <hdegoede(a)redhat.com> wrote:
Hi,
On 12-01-15 13:46, Josh Boyer wrote:
>
> On Mon, Jan 12, 2015 at 5:55 AM, drago01 <drago01(a)gmail.com> wrote:
>>
>> On Mon, Jan 12, 2015 at 11:51 AM, Hans de Goede <hdegoede(a)redhat.com>
>> wrote:
>>>
>>> Hi,
>>>
>>>
>>> On 12-01-15 11:48, drago01 wrote:
>>>>
>>>>
>>>> On Mon, Jan 12, 2015 at 11:47 AM, drago01 <drago01(a)gmail.com>
wrote:
>>>>>
>>>>>
>>>>> On Mon, Jan 12, 2015 at 11:37 AM, Hans de Goede
<hdegoede(a)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.
9:12 a.m.
Hi,
On 12-01-15 15:45, drago01 wrote:
On Mon, Jan 12, 2015 at 2:28 PM, Hans de Goede
<hdegoede(a)redhat.com> wrote:
> Hi,
>
>
> On 12-01-15 13:46, Josh Boyer wrote:
>>
>> On Mon, Jan 12, 2015 at 5:55 AM, drago01 <drago01(a)gmail.com> wrote:
>>>
>>> On Mon, Jan 12, 2015 at 11:51 AM, Hans de Goede <hdegoede(a)redhat.com>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>> On 12-01-15 11:48, drago01 wrote:
>>>>>
>>>>>
>>>>> On Mon, Jan 12, 2015 at 11:47 AM, drago01 <drago01(a)gmail.com>
wrote:
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 12, 2015 at 11:37 AM, Hans de Goede
<hdegoede(a)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
5:48 p.m.
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
3:21 a.m.
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
9:03 a.m.
----- Original Message -----
From: "Hans de Goede" <hdegoede(a)redhat.com>
To: desktop(a)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
12:15 p.m.
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
8:11 p.m.
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
10:55 a.m.
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
9:24 a.m.
----- Original Message -----
On Mon, Jan 12, 2015 at 2:28 PM, Hans de Goede
<hdegoede(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
9:28 a.m.
On Mon, Jan 12, 2015 at 4:24 PM, Jaroslav Reznik <jreznik(a)redhat.com> wrote:
----- Original Message -----
> On Mon, Jan 12, 2015 at 2:28 PM, Hans de Goede <hdegoede(a)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).
3383
days inactive
3385
days old
desktop@lists.fedoraproject.org
16 comments
7 participants
participants (7)
-
Christian Schaller -
drago01 -
Hans de Goede -
Jaroslav Reznik -
Josh Boyer -
Peter Hutterer -
Rex Dieter