F22 System Wide Change: Change xorg input stack to use libinput

[Jaroslav Reznik]

= Proposed System Wide Change: Change xorg input stack to use libinput =
https://fedoraproject.org/wiki/Changes/LibinputForXorg

Change owner(s): Hans de Goede <***@redhat.com>

Replace the current (low-level) input xorg drivers with libinput using the
xorg-x11-drv-libinput wrapper.

== Detailed Description ==
Currently xorg uses different input drivers depending on the device type. This
makes it impossible to do things like middle button scrolling on the
trackpoint on laptops where the trackpoint buttons are software-emulated
buttons on the touchpad. Besides this the xf86-input-synaptics driver was
never really designed for multi-touch touchpads and this causes various
issues.

For Wayland we've been working on a new improved input stack, which is to be
shared by all compositors and lives inside libinput. We plan to replace the
current (low-level) input xorg drivers with libinput using the xorg-x11-drv-
libinput wrapper.

== Scope ==
Besides xorg changes, this will also require changes to the control panel
applets for mouse / touchpad configuration in the various desktop environments,
as those all are hardcoded to use the xorg-x11-drv-synaptics specific
interfaces.

* Proposal owners:
Package libinput and xorg-drv-input-libinput (done), make sure that xorg-drv-
input-libinput has the necessary config interfaces for control panel
mouse/touchpad config applets (wip). Write patches for gnome-control-center
mouse/touchpad capplet. Coordinate with other desktop environments.

* Other developers:
GNOME: merge the gnome-control-center patches. KDE: limits itself to standard
X11 mouse config interfaces, no changes needed. Other Desktop Environments:
adjust control-panel code to deal with xorg-x11-drv-libinput, merge these
changes.

* Release engineering: N/A
* Policies and guidelines: N/A
_______________________________________________
devel-announce mailing list
devel-***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

[Kevin Kofler]

Jaroslav Reznik posted (and

KDE: limits itself to standard X11 mouse config interfaces, no changes
needed.

Not true. We ship kcm_touchpad on the KDE spin, which definitely does depend
on synaptics interfaces (search for "synaptics" in:
https://projects.kde.org/projects/playground/utils/kcm-touchpad/repository/revisions/master/entry/src/backends/x11/xlibbackend.cpp ).
Anything that does not use the synaptics driver is not considered a
touchpad. And kcm_touchpad is also in the process of becoming a core part of
upstream Plasma. (It is currently in the git.kde.org playground.)

Therefore, porting kcm_touchpad (the rewritten 1.x series we currently ship,
not the old, obsolete, 0.3.x version, please make sure you look at the
correct version) is an essential requirement before we can move away from
the synaptics driver.


An additional objection I have to this change proposal is that libinput
(deliberately) only implements a small subset of the configurability of the
old drivers, and thus, if we are going to remove the old drivers entirely,
we are taking away flexibility from our users.

Kevin Kofler

[Richard Hughes]

Post by Kevin Kofler
An additional objection I have to this change proposal is that libinput
(deliberately) only implements a small subset of the configurability of the
old drivers, and thus, if we are going to remove the old drivers entirely,
we are taking away flexibility from our users.

Yes, but the old stuff is unmaintainable.

Richard

[drago01]

Post by Kevin Kofler
Jaroslav Reznik posted (and

KDE: limits itself to standard X11 mouse config interfaces, no changes
needed.

Not true. We ship kcm_touchpad on the KDE spin, which definitely does depend
https://projects.kde.org/projects/playground/utils/kcm-touchpad/repository/revisions/master/entry/src/backends/x11/xlibbackend.cpp ).
Anything that does not use the synaptics driver is not considered a
touchpad. And kcm_touchpad is also in the process of becoming a core part of
upstream Plasma. (It is currently in the git.kde.org playground.)
Therefore, porting kcm_touchpad (the rewritten 1.x series we currently ship,
not the old, obsolete, 0.3.x version, please make sure you look at the
correct version) is an essential requirement before we can move away from
the synaptics driver.
An additional objection I have to this change proposal is that libinput
(deliberately) only implements a small subset of the configurability of the
old drivers, and thus, if we are going to remove the old drivers entirely,
we are taking away flexibility from our users.

Longer term we should just use libinput for input and modesetting +
glamor for video (ddx) .. that way its one code base that supports
everything and not a driver for each piece of hardware.

[Tom Hughes]

Post by Kevin Kofler
An additional objection I have to this change proposal is that libinput
(deliberately) only implements a small subset of the configurability of the
old drivers, and thus, if we are going to remove the old drivers entirely,
we are taking away flexibility from our users.

Indeed. Is it, for example, still the case that the libinput developers
are refusing to consider things like definable button areas on clickpads
so you can create a proper middle button?

Tom

[Peter Hutterer]

Post by Kevin Kofler
An additional objection I have to this change proposal is that libinput
(deliberately) only implements a small subset of the configurability of the
old drivers, and thus, if we are going to remove the old drivers entirely,
we are taking away flexibility from our users.

Indeed. Is it, for example, still the case that the libinput developers are
refusing to consider things like definable button areas on clickpads so you
can create a proper middle button?

Have you filed a bug for it?

Cheers,
Peter

[Tom Hughes]

Post by Peter Hutterer

Post by Kevin Kofler
An additional objection I have to this change proposal is that libinput
(deliberately) only implements a small subset of the configurability of the
old drivers, and thus, if we are going to remove the old drivers entirely,
we are taking away flexibility from our users.

Indeed. Is it, for example, still the case that the libinput developers are
refusing to consider things like definable button areas on clickpads so you
can create a proper middle button?

Have you filed a bug for it?

Well based on
http://who-t.blogspot.co.uk/2014/09/libinput-common-input-stack-for-wayland.html
I didn't think there was any point...

What I did do after writing my email above was to go and half implement
it, mostly to see if it would be feasible to maintain a locally patched
libinput.

So if you're interested I have code that (hopefully) allows a middle
button to exist, but I haven't added any way of configuring that button
yet so it's size is just hard coded.

Tom

[Peter Hutterer]

Post by Peter Hutterer

Post by Kevin Kofler
An additional objection I have to this change proposal is that libinput
(deliberately) only implements a small subset of the configurability of the
old drivers, and thus, if we are going to remove the old drivers entirely,
we are taking away flexibility from our users.

Indeed. Is it, for example, still the case that the libinput developers are
refusing to consider things like definable button areas on clickpads so you
can create a proper middle button?

Have you filed a bug for it?

Well based on http://who-t.blogspot.co.uk/2014/09/libinput-common-input-stack-for-wayland.html
I didn't think there was any point...

tbh, I'm not a fan of the feature at all, but then again a discussion may be
worth having. But I'm not going to have this discussion on this list here.

Please file a bug or bring it up on the wayland-devel list, then we can
weigh up the pros and cons there.

What I did do after writing my email above was to go and half implement it,
mostly to see if it would be feasible to maintain a locally patched
libinput.
So if you're interested I have code that (hopefully) allows a middle button
to exist, but I haven't added any way of configuring that button yet so it's
size is just hard coded.

fwiw, hardcoding the size is fine IMO. The detail is in the various corner
cases though, but if you already have it you're welcome to send it to the
wayland list (or attach it to the bug report).

Cheers,
Peter

[Tom Hughes]

Post by Peter Hutterer

Post by Peter Hutterer

Post by Kevin Kofler
An additional objection I have to this change proposal is that libinput
(deliberately) only implements a small subset of the configurability of the
old drivers, and thus, if we are going to remove the old drivers entirely,
we are taking away flexibility from our users.

Indeed. Is it, for example, still the case that the libinput developers are
refusing to consider things like definable button areas on clickpads so you
can create a proper middle button?

Have you filed a bug for it?

Well based on http://who-t.blogspot.co.uk/2014/09/libinput-common-input-stack-for-wayland.html
I didn't think there was any point...

tbh, I'm not a fan of the feature at all, but then again a discussion may be
worth having. But I'm not going to have this discussion on this list here.
Please file a bug or bring it up on the wayland-devel list, then we can
weigh up the pros and cons there.

https://bugs.freedesktop.org/show_bug.cgi?id=87402

Tom

[Peter Hutterer]

Post by Kevin Kofler
Jaroslav Reznik posted (and

KDE: limits itself to standard X11 mouse config interfaces, no changes
needed.

Not true. We ship kcm_touchpad on the KDE spin, which definitely does depend
https://projects.kde.org/projects/playground/utils/kcm-touchpad/repository/revisions/master/entry/src/backends/x11/xlibbackend.cpp ).
Anything that does not use the synaptics driver is not considered a
touchpad. And kcm_touchpad is also in the process of becoming a core part of
upstream Plasma. (It is currently in the git.kde.org playground.)
Therefore, porting kcm_touchpad (the rewritten 1.x series we currently ship,
not the old, obsolete, 0.3.x version, please make sure you look at the
correct version) is an essential requirement before we can move away from
the synaptics driver.
An additional objection I have to this change proposal is that libinput
(deliberately) only implements a small subset of the configurability of the
old drivers, and thus, if we are going to remove the old drivers entirely,
we are taking away flexibility from our users.

You are welcome to file bugs in the freedesktop.org bugzilla
(Wayland/libinput) for the feature requests you have. Some of them may be
closed as wontfix, but I suspect there are others the case isn't clear-cut.

Oh, and if you do so, don't just go through the synaptics/evdev man pages
and file a bug for every option in there. I want clear use-cases that
justify each features you want us to add.

Cheers,
Peter

[Jaroslav Reznik]

----- Original Message -----

Post by Jaroslav Reznik
= Proposed System Wide Change: Change xorg input stack to use libinput =
https://fedoraproject.org/wiki/Changes/LibinputForXorg
Replace the current (low-level) input xorg drivers with libinput using the
xorg-x11-drv-libinput wrapper.

Approved with two caveats: 1) Both GNOME and KDE must be updated by
the contingency date or it goes into effect and 2) the contingency plan
should note that it will may require reverting changes to the control
panels as well.

Hans, could you please update Change page based on FESCo hints?

Thanks
Jaroslav

[Hans de Goede]

Hi,

Post by Jaroslav Reznik
----- Original Message -----

Post by Jaroslav Reznik
= Proposed System Wide Change: Change xorg input stack to use libinput =
https://fedoraproject.org/wiki/Changes/LibinputForXorg
Replace the current (low-level) input xorg drivers with libinput using the
xorg-x11-drv-libinput wrapper.

Approved with two caveats: 1) Both GNOME and KDE must be updated by
the contingency date or it goes into effect and 2) the contingency plan
should note that it will may require reverting changes to the control
panels as well.
Hans, could you please update Change page based on FESCo hints?

As I already replied to the Fesco meeting Summary mail:

WRT to the 2 caveats:

1) As mentioned in the feature page KDE does not need any changes since
its mouse settings panel does not talk directly to low level Xorg drivers.

2) The GNOME control panel changes are already done in such a matter
that things will keep working with the old xorg-x11-drv-evdev +
xorg-x11-drv-synaptics combo, both for other distrosm, as well as some
users want to do a manual fallback to the old combo.

So I think that no changes are necessary to the wiki page.

Regards,

Hans

[Stephen Gallagher]

Post by Hans de Goede
Hi,

Post by Jaroslav Reznik
----- Original Message -----

Post by Jaroslav Reznik
= Proposed System Wide Change: Change xorg input stack to use libinput =
https://fedoraproject.org/wiki/Changes/LibinputForXorg
Replace the current (low-level) input xorg drivers with libinput using the
xorg-x11-drv-libinput wrapper.

Approved with two caveats: 1) Both GNOME and KDE must be updated by
the contingency date or it goes into effect and 2) the contingency plan
should note that it will may require reverting changes to the control
panels as well.
Hans, could you please update Change page based on FESCo hints?

1) As mentioned in the feature page KDE does not need any changes since
its mouse settings panel does not talk directly to low level Xorg drivers.
2) The GNOME control panel changes are already done in such a matter
that things will keep working with the old xorg-x11-drv-evdev +
xorg-x11-drv-synaptics combo, both for other distrosm, as well as some
users want to do a manual fallback to the old combo.
So I think that no changes are necessary to the wiki page.
Regards,
Hans

Thanks, Hans. We wanted to make sure that we didn't have another
instance of the bluetooth fiasco from a couple releases ago, where GNOME
changed the Bluetooth stack and broke things underneath KDE. If this is
already addressed (or at least irrelevant), that's perfect.

[Bastien Nocera]

----- Original Message -----
<snip>

Post by Stephen Gallagher
Thanks, Hans. We wanted to make sure that we didn't have another
instance of the bluetooth fiasco from a couple releases ago, where GNOME
changed the Bluetooth stack and broke things underneath KDE. If this is
already addressed (or at least irrelevant), that's perfect.

BlueZ 5.0, released december 2012.
GNOME with BlueZ 5 support, september 2013.
Fedora 20 with BlueZ 5 included, december 2013.

[Stephen Gallagher]

Post by Jaroslav Reznik
----- Original Message -----
<snip>

Post by Stephen Gallagher
Thanks, Hans. We wanted to make sure that we didn't have another
instance of the bluetooth fiasco from a couple releases ago, where GNOME
changed the Bluetooth stack and broke things underneath KDE. If this is
already addressed (or at least irrelevant), that's perfect.

BlueZ 5.0, released december 2012.
GNOME with BlueZ 5 support, september 2013.
Fedora 20 with BlueZ 5 included, december 2013.

Was it really only F20? Seems older than that. Anyway, it's irrelevant
when BlueZ landed upstream. What went wrong was that GNOME landed the
support which broke backwards compatibility, which forced KDE to
scramble to get it working on their side. This was a communication
issue, and I think everyone would prefer not to repeat it. My apologies
if my original message bringing it up sounded accusatory. It was not my
intent.

The whole point of System Wide Changes is to ensure that all the people
who might be impacted by a Change are notified and involved. So in order
to avoid forcing sudden and unexpected work on a particular group, we
called it out as a contingency issue: if either or both of the
release-blocking desktops don't make the contingency deadlines, it gets
deferred so they can both get it right in the next release.

[Jaroslav Reznik]

----- Original Message -----

Post by Stephen Gallagher

Post by Jaroslav Reznik
----- Original Message -----
<snip>

Post by Stephen Gallagher
Thanks, Hans. We wanted to make sure that we didn't have another
instance of the bluetooth fiasco from a couple releases ago, where GNOME
changed the Bluetooth stack and broke things underneath KDE. If this is
already addressed (or at least irrelevant), that's perfect.

BlueZ 5.0, released december 2012.
GNOME with BlueZ 5 support, september 2013.
Fedora 20 with BlueZ 5 included, december 2013.

Was it really only F20? Seems older than that. Anyway, it's irrelevant
when BlueZ landed upstream. What went wrong was that GNOME landed the
support which broke backwards compatibility, which forced KDE to
scramble to get it working on their side. This was a communication
issue, and I think everyone would prefer not to repeat it. My apologies
if my original message bringing it up sounded accusatory. It was not my
intent.

And sometimes we live in this GNOME vs KDE world and then we forget all
other desktops in Fedora - NM 0.9 fiasco. Where GNOME and KDE were somehow
ready and everything else was released broken. So it's definitely good to
talk and do it in advance.

Jaroslav

[Hans de Goede]

Hi,

Post by Hans de Goede
Hi,

Post by Jaroslav Reznik
----- Original Message -----

Post by Jaroslav Reznik
= Proposed System Wide Change: Change xorg input stack to use libinput =
https://fedoraproject.org/wiki/Changes/LibinputForXorg
Replace the current (low-level) input xorg drivers with libinput using the
xorg-x11-drv-libinput wrapper.

Approved with two caveats: 1) Both GNOME and KDE must be updated by
the contingency date or it goes into effect and 2) the contingency plan
should note that it will may require reverting changes to the control
panels as well.
Hans, could you please update Change page based on FESCo hints?

1) As mentioned in the feature page KDE does not need any changes since
its mouse settings panel does not talk directly to low level Xorg drivers.
2) The GNOME control panel changes are already done in such a matter
that things will keep working with the old xorg-x11-drv-evdev +
xorg-x11-drv-synaptics combo, both for other distrosm, as well as some
users want to do a manual fallback to the old combo.
So I think that no changes are necessary to the wiki page.

Scrap that, Kevin Kofler pointed me to this post:

https://lists.fedoraproject.org/pipermail/devel/2014-December/205490.html

Which I unfortunately missed, so the info I got from KDE upstream is
not correct because the KDE spin adds an extra component which does
directly talk to the low level Xorg drivers, and there are plans to
integrate this into kdebase upstream.

As a result of this Peter Hutterer and I have been rethinking the
plans for switching to xorg-x11-drv-libinput for F-22. So now we plan
to introduce xorg-x11-drv-libinput more carefully / slowly.

The new plan is to only do this for the Desktop product, and thus for
the GNOME desktop.

We've always planned to keep the old drivers around and allow people
to use those instead as a fallback plan, and the GNOME input configuration
changes which are in the works will also keep supporting the old drivers.

I've updated the feature page to reflect this:
https://fedoraproject.org/wiki/Changes/LibinputForXorg

I guess given the changes FESCo may want to re-visit this feature.

I'll also start a discussion on ***@lists.fedoraproject.org about
adding xorg-x11-drv-libinput to the Desktop's product set of default
packages.

Regards,

Hans

[Josh Boyer]

Post by Hans de Goede
Hi,

Post by Hans de Goede
Hi,

Post by Jaroslav Reznik
----- Original Message -----

Post by Jaroslav Reznik
= Proposed System Wide Change: Change xorg input stack to use libinput =
https://fedoraproject.org/wiki/Changes/LibinputForXorg
Replace the current (low-level) input xorg drivers with libinput using the
xorg-x11-drv-libinput wrapper.

Approved with two caveats: 1) Both GNOME and KDE must be updated by
the contingency date or it goes into effect and 2) the contingency plan
should note that it will may require reverting changes to the control
panels as well.
Hans, could you please update Change page based on FESCo hints?

1) As mentioned in the feature page KDE does not need any changes since
its mouse settings panel does not talk directly to low level Xorg drivers.
2) The GNOME control panel changes are already done in such a matter
that things will keep working with the old xorg-x11-drv-evdev +
xorg-x11-drv-synaptics combo, both for other distrosm, as well as some
users want to do a manual fallback to the old combo.
So I think that no changes are necessary to the wiki page.

https://lists.fedoraproject.org/pipermail/devel/2014-December/205490.html
Which I unfortunately missed, so the info I got from KDE upstream is
not correct because the KDE spin adds an extra component which does
directly talk to the low level Xorg drivers, and there are plans to
integrate this into kdebase upstream.
As a result of this Peter Hutterer and I have been rethinking the
plans for switching to xorg-x11-drv-libinput for F-22. So now we plan
to introduce xorg-x11-drv-libinput more carefully / slowly.
The new plan is to only do this for the Desktop product, and thus for
the GNOME desktop.

Erm, except there isn't a Desktop product. There's Workstation, which
is actually looking at including KDE as well.

josh

[Richard Hughes]

There's Workstation, which is actually looking at including KDE as well.

It is? Why?

RIchard

[Reindl Harald]

Post by Richard Hughes

There's Workstation, which is actually looking at including KDE as well.

It is? Why?

why not?

not everybody likes GNOME for several reasons and it would be *so much*
more helpful if a *new user* never worked with Linux before could
install both and chose at login which to use for find out the right DE

and no - you don't need to extend that for any available desktop because
KDE/GNOME are the both major candidates backed by 15 years of history (i
remember KDE 1.0 as example and did not like GNOME that old days as well
as now)

[Josh Boyer]

Post by Richard Hughes

There's Workstation, which is actually looking at including KDE as well.

It is? Why?

Because it was a work item from F21 that didn't make it and we're
continuing off of that. "Including" here doesn't necessarily mean
installed by default, but it's certainly something that impacts what
Workstation needs to plan for.

josh

[Hans de Goede]

Hi,

Post by Josh Boyer

Post by Hans de Goede
Hi,

Post by Hans de Goede
Hi,

Post by Jaroslav Reznik
----- Original Message -----

Post by Jaroslav Reznik
= Proposed System Wide Change: Change xorg input stack to use libinput =
https://fedoraproject.org/wiki/Changes/LibinputForXorg
Replace the current (low-level) input xorg drivers with libinput using the
xorg-x11-drv-libinput wrapper.

Approved with two caveats: 1) Both GNOME and KDE must be updated by
the contingency date or it goes into effect and 2) the contingency plan
should note that it will may require reverting changes to the control
panels as well.
Hans, could you please update Change page based on FESCo hints?

1) As mentioned in the feature page KDE does not need any changes since
its mouse settings panel does not talk directly to low level Xorg drivers.
2) The GNOME control panel changes are already done in such a matter
that things will keep working with the old xorg-x11-drv-evdev +
xorg-x11-drv-synaptics combo, both for other distrosm, as well as some
users want to do a manual fallback to the old combo.
So I think that no changes are necessary to the wiki page.

https://lists.fedoraproject.org/pipermail/devel/2014-December/205490.html
Which I unfortunately missed, so the info I got from KDE upstream is
not correct because the KDE spin adds an extra component which does
directly talk to the low level Xorg drivers, and there are plans to
integrate this into kdebase upstream.
As a result of this Peter Hutterer and I have been rethinking the
plans for switching to xorg-x11-drv-libinput for F-22. So now we plan
to introduce xorg-x11-drv-libinput more carefully / slowly.
The new plan is to only do this for the Desktop product, and thus for
the GNOME desktop.

Erm, except there isn't a Desktop product. There's Workstation, which
is actually looking at including KDE as well.

Ah right, sorry I somehow had Desktop product in my head where it should
be Workstation, you're right. As for the impact of installing
xorg-x11-drv-libinput by default on Workstation, lets discuss that further
on the desktop list, I've just replied to your other mail on this there.

Regards,

Hans

[Miloslav Trmač]

Post by Hans de Goede
https://lists.fedoraproject.org/pipermail/devel/2014-December/205490.html
Which I unfortunately missed, so the info I got from KDE upstream is
not correct because the KDE spin adds an extra component which does
directly talk to the low level Xorg drivers, and there are plans to
integrate this into kdebase upstream.
As a result of this Peter Hutterer and I have been rethinking the
plans for switching to xorg-x11-drv-libinput for F-22. So now we plan
to introduce xorg-x11-drv-libinput more carefully / slowly.
The new plan is to only do this for the Desktop product, and thus for
the GNOME desktop.
We've always planned to keep the old drivers around and allow people
to use those instead as a fallback plan, and the GNOME input configuration
changes which are in the works will also keep supporting the old drivers.
https://fedoraproject.org/wiki/Changes/LibinputForXorg
I guess given the changes FESCo may want to re-visit this feature.

If I understand correctly, this would amount to the inability to install both GNOME and KDE side-by-side, with both desktops’ touchpad configuration dialog working without manual involvement (because the driver change is done by installing/uninstalling packages or perhaps xorg.conf changes).

That’s not the end of the world but also not ideal. Is there anyone interested in porting the kcm module in time for F22?
Mirek

[drago01]

Post by Miloslav Trmač

Post by Hans de Goede
https://lists.fedoraproject.org/pipermail/devel/2014-December/205490.html
Which I unfortunately missed, so the info I got from KDE upstream is
not correct because the KDE spin adds an extra component which does
directly talk to the low level Xorg drivers, and there are plans to
integrate this into kdebase upstream.
As a result of this Peter Hutterer and I have been rethinking the
plans for switching to xorg-x11-drv-libinput for F-22. So now we plan
to introduce xorg-x11-drv-libinput more carefully / slowly.
The new plan is to only do this for the Desktop product, and thus for
the GNOME desktop.
We've always planned to keep the old drivers around and allow people
to use those instead as a fallback plan, and the GNOME input configuration
changes which are in the works will also keep supporting the old drivers.
https://fedoraproject.org/wiki/Changes/LibinputForXorg
I guess given the changes FESCo may want to re-visit this feature.

If I understand correctly, this would amount to the inability to install both GNOME and KDE side-by-side, with both desktops’ touchpad configuration dialog working without manual involvement (because the driver change is done by installing/uninstalling packages or perhaps xorg.conf changes).

Well that might be solvable see
https://lists.fedoraproject.org/pipermail/desktop/2015-January/011415.html

Post by Miloslav Trmač
That’s not the end of the world but also not ideal. Is there anyone interested in porting the kcm module in time for F22?

That's the best solution yes (also see thread on -desktop).

[Vít Ondruch]

Just wanted to thank for this feature. I installed xorg-x11-drv-libinput
two days ago and middle button track point scrolling works like a charm.
My life is much better now ;)


Vít

Post by Jaroslav Reznik
= Proposed System Wide Change: Change xorg input stack to use libinput =
https://fedoraproject.org/wiki/Changes/LibinputForXorg
Replace the current (low-level) input xorg drivers with libinput using the
xorg-x11-drv-libinput wrapper.
== Detailed Description ==
Currently xorg uses different input drivers depending on the device type. This
makes it impossible to do things like middle button scrolling on the
trackpoint on laptops where the trackpoint buttons are software-emulated
buttons on the touchpad. Besides this the xf86-input-synaptics driver was
never really designed for multi-touch touchpads and this causes various
issues.
For Wayland we've been working on a new improved input stack, which is to be
shared by all compositors and lives inside libinput. We plan to replace the
current (low-level) input xorg drivers with libinput using the xorg-x11-drv-
libinput wrapper.
== Scope ==
Besides xorg changes, this will also require changes to the control panel
applets for mouse / touchpad configuration in the various desktop environments,
as those all are hardcoded to use the xorg-x11-drv-synaptics specific
interfaces.
Package libinput and xorg-drv-input-libinput (done), make sure that xorg-drv-
input-libinput has the necessary config interfaces for control panel
mouse/touchpad config applets (wip). Write patches for gnome-control-center
mouse/touchpad capplet. Coordinate with other desktop environments.
GNOME: merge the gnome-control-center patches. KDE: limits itself to standard
adjust control-panel code to deal with xorg-x11-drv-libinput, merge these
changes.
* Release engineering: N/A
* Policies and guidelines: N/A
_______________________________________________
devel-announce mailing list
https://admin.fedoraproject.org/mailman/listinfo/devel-announce