Bug 1199825 - kcm_touchpad: No touchpad found
Summary: kcm_touchpad: No touchpad found
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: plasma-desktop
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: KDE SIG
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1229304 (view as bug list)
Depends On:
Blocks: F22Target-kde 1181565
TreeView+ depends on / blocked
 
Reported: 2015-03-08 18:42 UTC by Rex Dieter
Modified: 2015-11-15 14:58 UTC (History)
12 users (show)

Fixed In Version: muon-5.3.2-1.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-07-03 18:35:07 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
check for 'synaptics Tap Action' atom first (985 bytes, patch)
2015-06-23 19:45 UTC, Rex Dieter
no flags Details | Diff
Fix touchpad backend initialization (1.83 KB, patch)
2015-06-24 13:31 UTC, Rajeesh
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 751471 0 None None None Never
GNOME Bugzilla 751472 0 None None None Never
KDE Software Compilation 344958 0 None None None Never

Description Rex Dieter 2015-03-08 18:42:31 UTC
Testing F22 (alpha) and installed kcm_touchpad-5.1.95 (which includes all subsequent commits up to 
e267c5fd548198b4cbc064168191c13777ea54d0 add missing libinputproperties.c

before it was migrated to plasma-desktop repo (but I didn't notice any significant commits since then).

Anyway, trying to configure my touchpad, the kcm reports:  No touchpad found

I suspect this may be some problem with the libinput support recently added.

See also upstream report,
https://bugs.kde.org/show_bug.cgi?id=344958

Comment 1 Rex Dieter 2015-03-08 21:22:11 UTC
After installing xorg-x11-drv-libinput, it works.  (I had xorg-x11-drv-synaptics installed previously).

It's supposed to be able to work both ways.

I'll do more testing, but in the meantime, I figure we probably ought to install libinput support.

Comment 2 Rex Dieter 2015-03-08 21:40:56 UTC
Weird, installed updates which included ,
https://admin.fedoraproject.org/updates/FEDORA-2015-3300/xorg-x11-server-1.17.1-6.fc22

then, uninstalled xorg-x11-drv-libinput (keeping -synaptics), and things still worked (no "No touchpad found" error).

For completeness, tried also removing libinput... same.

so it seems I cannot reproduce this anymore. :-/

Comment 3 Rex Dieter 2015-04-10 16:00:38 UTC
and, now I can reproduce the problem again, I have xorg-x11-server-1.17.1-7.fc22 installed now.

Comment 4 Dan Mossor [danofsatx] 2015-04-10 16:09:26 UTC
Fedup from F21 with Plasma5 from dvratil-copr to F22 on 09APR2015 (after Beta freeze), and my touchpad went the way of yum.

On initial boot with libinput still installed, I had no capability to customize the buttons of the touchpad, and both buttons registered as a right click, as well as the right button.

Removing libinput restored the middle button click with both buttons, but kcm_touchpad is now reporting "No touchpad found". I do have xorg-x11-drv-synaptics installed.

The touchpad is an Elantech in an Asus ROG G55VW laptop. Not sure this is kcm_touchpad - it looks more like an X11 error. Here is the snippet from /var/log/Xorg.0.log that finds the touchpad, then bails on setting it up:

[    18.804] (II) config/udev: Adding input device ETPS/2 Elantech Touchpad (/dev/input/event5)
[    18.804] (**) ETPS/2 Elantech Touchpad: Applying InputClass "evdev touchpad catchall"
[    18.804] (**) ETPS/2 Elantech Touchpad: Applying InputClass "touchpad catchall"
[    18.804] (**) ETPS/2 Elantech Touchpad: Applying InputClass "Default clickpad buttons"
[    18.804] (II) LoadModule: "synaptics"
[    18.805] (II) Loading /usr/lib64/xorg/modules/input/synaptics_drv.so
[    18.805] (II) Module synaptics: vendor="X.Org Foundation"
[    18.805]    compiled for 1.17.1, module version = 1.8.2
[    18.805]    Module class: X.Org XInput Driver
[    18.805]    ABI class: X.Org XInput driver, version 21.0
[    18.805] (II) Using input driver 'synaptics' for 'ETPS/2 Elantech Touchpad'
[    18.805] (**) ETPS/2 Elantech Touchpad: always reports core events
[    18.805] (**) Option "Device" "/dev/input/event5"
[    18.868] (--) synaptics: ETPS/2 Elantech Touchpad: x-axis range 0 - 2940 (res 0)
[    18.868] (--) synaptics: ETPS/2 Elantech Touchpad: y-axis range 0 - 1260 (res 0)
[    18.868] (--) synaptics: ETPS/2 Elantech Touchpad: pressure range 0 - 255
[    18.868] (--) synaptics: ETPS/2 Elantech Touchpad: finger width range 0 - 15
[    18.868] (--) synaptics: ETPS/2 Elantech Touchpad: buttons: left right double triple
[    18.868] (--) synaptics: ETPS/2 Elantech Touchpad: Vendor 0x2 Product 0xe
[    18.868] (--) synaptics: ETPS/2 Elantech Touchpad: touchpad found
[    18.868] (**) ETPS/2 Elantech Touchpad: always reports core events
[    18.904] (**) Option "config_info" "udev:/sys/devices/platform/i8042/serio4/input/input11/event5"
[    18.904] (II) XINPUT: Adding extended input device "ETPS/2 Elantech Touchpad" (type: TOUCHPAD, id 12)
[    18.904] (**) synaptics: ETPS/2 Elantech Touchpad: (accel) MinSpeed is now constant deceleration 2.5
[    18.904] (**) synaptics: ETPS/2 Elantech Touchpad: (accel) MaxSpeed is now 1.75
[    18.904] (**) synaptics: ETPS/2 Elantech Touchpad: (accel) AccelFactor is now 0.063
[    18.904] (**) ETPS/2 Elantech Touchpad: (accel) keeping acceleration scheme 1
[    18.904] (**) ETPS/2 Elantech Touchpad: (accel) acceleration profile 1
[    18.904] (**) ETPS/2 Elantech Touchpad: (accel) acceleration factor: 2.000
[    18.904] (**) ETPS/2 Elantech Touchpad: (accel) acceleration threshold: 4
[    18.904] (--) synaptics: ETPS/2 Elantech Touchpad: touchpad found
[    18.904] (II) config/udev: Adding input device ETPS/2 Elantech Touchpad (/dev/input/mouse0)
[    18.904] (II) No input driver specified, ignoring this device.
[    18.904] (II) This device may have been added with another device file.

Comment 5 Fedora Admin XMLRPC Client 2015-05-04 23:46:11 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 6 Kevin Kofler 2015-05-05 08:16:15 UTC
kcm_touchpad is now part of the plasma-desktop package, reassigning.

Comment 7 Rex Dieter 2015-05-27 17:57:59 UTC
*** Bug 1225579 has been marked as a duplicate of this bug. ***

Comment 8 Rajeesh 2015-06-20 19:19:27 UTC
I tried to debug this and found the following:
XlibBackend::initialize() checks if libinput is installed/active by checking the X atom "libinput Tapping Enabled" and if yes, it instantiates XlibLibinputBackend, otherwise instantiates XlibSynapticsBackend.
When xorg-x11-drv-libinput is *not* installed, one would expect the X atom check fails and falls back to synaptics driver.

On the contrary, even when xorg-x11-drv-libinput is not installed, the libinput_prop_tapping.atom() check succeeds. And I can verify this by:

[rajeesh@athena: ~]$ xlsatoms | grep -i tapping
560     libinput Tapping Enabled

This confuses XlibBackend::initialize() which tries to load the non-existent libinput backend.

Adding Peter Hutterer if he has ideas what/why this happens.

Comment 9 Peter Hutterer 2015-06-23 04:52:07 UTC
weird. is there another device handled by libinput? if not, does the code somehow create this atom?
try to fire up a server without KDE running and then check if the property is initialized.


fwiw, there's a somewhat unrelated bug in the code anyway: if the property exists but the touchpad itself isn't handled by libinput, the code won't work correctly either, it'll still create a libinput backend.

Comment 10 Rajeesh 2015-06-23 19:12:14 UTC
So, I have downloaded the F22 Workstation (GNOME) and checked default, libinput and synaptics drivers installed situation:

$ xlsatoms | grep -i tap
324    libinput Tapping Enabled

Removed xorg-x11-drv-libinput, restarted and:

$ xlsatoms | grep -i tap
313    libinput Tapping Enabled
342    synaptics Tap Action

Clearly shows that property remains active.

Also, KCM touchpad has the below code:

325     libinput_prop_tapping.intern(connection, "libinput Tapping Enabled");
326     if (libinput_prop_tapping.atom())
327         return new XlibLibinputBackend(parent);
328     else
329         return new XlibSynapticsBackend(parent);
    

What would be a better check at line 325? Rather, try to instantiate XlibLibinputBackend and if it fails, try to create new XlibSynapticsBackend ?

Comment 11 Rex Dieter 2015-06-23 19:23:46 UTC
Offhand, given those findings, perhaps something like:

if
synaptics Tap Action
is present, use synaptics backend

else if
libinput Tapping Enabled
is present, is libinput backend

else ... some error condition

Comment 12 Rex Dieter 2015-06-23 19:24:54 UTC
I'll prepare a patch and test that theory...

Comment 13 Rex Dieter 2015-06-23 19:45:56 UTC
Created attachment 1042490 [details]
check for  'synaptics Tap Action' atom first

Quick-n-dirty proof-of-concept patch to check for 'synaptics Tap Action' atom first for existence of synaptics.

Comment 14 Rex Dieter 2015-06-23 19:55:44 UTC
Confirmed patch seems to work as advertised, will submit a build for testing purposes.

Comment 15 Rex Dieter 2015-06-23 22:27:34 UTC
If anyone's willing to test, try this f22 build:
https://koji.fedoraproject.org/koji/buildinfo?buildID=664677

Comment 16 Peter Hutterer 2015-06-23 22:50:36 UTC
(In reply to Rajeesh from comment #10)
> $ xlsatoms | grep -i tap
> 313    libinput Tapping Enabled
> 342    synaptics Tap Action
> 
> Clearly shows that property remains active.

do you have an Xorg.log for this? it doesn't make sense, the libinput driver is the only thing that creates this property intentionally, everything else should only check for it.


> Also, KCM touchpad has the below code:
> 
> 325     libinput_prop_tapping.intern(connection, "libinput Tapping Enabled");
> 326     if (libinput_prop_tapping.atom())
> 327         return new XlibLibinputBackend(parent);
> 328     else
> 329         return new XlibSynapticsBackend(parent);
>     
> 
> What would be a better check at line 325? Rather, try to instantiate
> XlibLibinputBackend and if it fails, try to create new XlibSynapticsBackend ?

yep, I don't know how to fail from within a C++ constructor though (exception I guess).

Rex' patch will work too for now, but it just reverses the problem. If something creates that property when it shouldn't you'll run into the same issue. Also won't work correctly if there are two touchpads with two different drivers, but that's a niche case and probably won't work anyway. Still I guess something like this should be best:

try {
    return new XlibLibinputBackend(parent);
} catch (XlibBackendFailedException) {
    try
        return new XLibSynapticsBackend(parent);
    catch (...) {
        return "no touchpad present";
}

Comment 17 Rajeesh 2015-06-24 09:37:27 UTC
(In reply to Peter Hutterer from comment #16)
> (In reply to Rajeesh from comment #10)
> > $ xlsatoms | grep -i tap
> > 313    libinput Tapping Enabled
> > 342    synaptics Tap Action
> > 
> > Clearly shows that property remains active.
> 
> do you have an Xorg.log for this? it doesn't make sense, the libinput driver
> is the only thing that creates this property intentionally, everything else
> should only check for it.


No, this is reproducible in vanilla F22 Workstation and KDE spin. You can easily check this in a VM.

> 
> 

> > What would be a better check at line 325? Rather, try to instantiate
> > XlibLibinputBackend and if it fails, try to create new XlibSynapticsBackend ?
> 
> yep, I don't know how to fail from within a C++ constructor though
> (exception I guess).
> 
> Rex' patch will work too for now, but it just reverses the problem. If
> something creates that property when it shouldn't you'll run into the same
> issue. Also won't work correctly if there are two touchpads with two
> different drivers, but that's a niche case and probably won't work anyway.
> Still I guess something like this should be best:
> 
> try {
>     return new XlibLibinputBackend(parent);
> } catch (XlibBackendFailedException) {
>     try
>         return new XLibSynapticsBackend(parent);
>     catch (...) {
>         return "no touchpad present";
> }

I have another idea:

    XlibBackend* backend;
    libinput_prop_tapping.intern(connection, "libinput Tapping Enabled");
    if (libinput_prop_tapping.atom())
        backend = new XlibLibinputBackend(parent);
    if (!backend->errorString().isNULL())
        backend = new XlibSynapticsBackend(parent);
    return backend;

Both XlibLibinputBackend and XlibSynapticsBackend constructors need to be slightly updated with m_errorString populated in all error cases. There's already an upstream bug for one of these.
Thoughts?

Comment 18 Peter Hutterer 2015-06-24 11:42:34 UTC
(In reply to Rajeesh from comment #17)
> No, this is reproducible in vanilla F22 Workstation and KDE spin. You can
> easily check this in a VM.

if I start a plain X server (xinit) after uninstalling libinput, the property doesn't exist. once I run startkde the property shows up. so the bug is in kcm_touchpad, the property that should be only be checked is somehow created.

question now is whether that's an xcb bug, the kcm_touchpad code looks ok on a glance?

> 
> I have another idea:
> 
>     XlibBackend* backend;
>     libinput_prop_tapping.intern(connection, "libinput Tapping Enabled");
>     if (libinput_prop_tapping.atom())
>         backend = new XlibLibinputBackend(parent);
>     if (!backend->errorString().isNULL())
>         backend = new XlibSynapticsBackend(parent);
>     return backend;
> 
> Both XlibLibinputBackend and XlibSynapticsBackend constructors need to be
> slightly updated with m_errorString populated in all error cases. There's
> already an upstream bug for one of these.
> Thoughts?

yeah, it'll work. doesn't seem to be very C++-ish with RAII and so on. then again, I'm a C programmer and don't know the style KDE requires :)

Comment 19 Kevin Kofler 2015-06-24 12:03:01 UTC
That won't do the right thing if the atom is NOT present, will it?

I think you want:
    XlibBackend* backend;
    libinput_prop_tapping.intern(connection, "libinput Tapping Enabled");
    if (libinput_prop_tapping.atom()) {
        backend = new XlibLibinputBackend(parent);
        if (!backend->errorString().isNULL())
            backend = new XlibSynapticsBackend(parent);
    } else
        backend = new XlibSynapticsBackend(parent);
    return backend;

Comment 20 Rajeesh 2015-06-24 13:31:42 UTC
Created attachment 1042761 [details]
Fix touchpad backend initialization

Indeed, I found out while testing. How about the attached patch? And a scratch build is at http://koji.fedoraproject.org/koji/taskinfo?taskID=10197551

Comment 21 Rajeesh 2015-06-24 13:40:20 UTC
(In reply to Peter Hutterer from comment #18)
> (In reply to Rajeesh from comment #17)
> > No, this is reproducible in vanilla F22 Workstation and KDE spin. You can
> > easily check this in a VM.
> 
> if I start a plain X server (xinit) after uninstalling libinput, the
> property doesn't exist. once I run startkde the property shows up. so the
> bug is in kcm_touchpad, the property that should be only be checked is
> somehow created.
> 
> question now is whether that's an xcb bug, the kcm_touchpad code looks ok on
> a glance?

The issue is reproducible with GNOME (workstation) where kcm_touchpad is *not* installed.

> 

Interestingly, now that I removed xorg-x11-drv-libinput more than once, the atom is *not present*. I remember similar instance in F21 also...

Comment 22 Peter Hutterer 2015-06-25 00:01:23 UTC
bug in clutter, mutter, and GTK+. I suspect something using GTK is started in the desktop and causes the property to be created. Upstream GNOME bugs are here:
https://bugzilla.gnome.org/show_bug.cgi?id=751472
https://bugzilla.gnome.org/show_bug.cgi?id=751471

Comment 23 Peter Hutterer 2015-06-25 00:27:46 UTC
Comment on attachment 1042761 [details]
Fix touchpad backend initialization

I'd skip the first check completely, it doesn't really add anything. Make the code:

backend = new XlibLibinputBackend(parent);
if (! backend->errorString().isNull()) {
   delete backend;
   backend = new XlibSynapticsBackend(parent);
}

Comment 24 Rajeesh 2015-06-25 08:31:51 UTC
Thanks for solving the puzzle!
I will revise the patch accordingly, and see if it actually fixes issue for other reporters.

Comment 25 Peter Hutterer 2015-06-26 04:42:47 UTC
*** Bug 1229304 has been marked as a duplicate of this bug. ***

Comment 26 Fedora Update System 2015-06-28 22:58:28 UTC
muon-5.3.2-1.fc22, plasma-workspace-wallpapers-5.3.2-1.fc22, powerdevil-5.3.2-1.fc22, plasma-breeze-5.3.2-1.fc22, bluedevil-5.3.2-1.fc22, kscreen-5.3.2-1.fc22, kdeplasma-addons-5.3.2-1.fc22, libksysguard-5.3.2-1.fc22, kio-extras-5.3.2-1.fc22, plasma-systemsettings-5.3.2-1.fc22, oxygen-fonts-5.3.2-1.fc22, sddm-kcm-5.3.2-1.fc22, plasma-oxygen-5.3.2-1.fc22, kf5-baloo-5.9.2-1.fc22, plasma-milou-5.3.2-1.fc22, polkit-kde-5.3.2-1.fc22, kmenuedit-5.3.2-1.fc22, khelpcenter-5.3.2-1.fc22, kde-gtk-config-5.3.2-1.fc22, kdecoration-5.3.2-1.fc22, ksshaskpass-5.3.2-1.fc22, libkscreen-qt5-5.3.2-1.fc22, kf5-kfilemetadata-5.9.2-1.fc22, khotkeys-5.3.2-1.fc22, plasma-sdk-5.3.2-1.fc22, kinfocenter-5.3.2-1.fc22, kwin-5.3.2-1.fc22, kf5-kwayland-5.3.2-1.fc22, plasma-desktop-5.3.2-2.fc22, ksysguard-5.3.2-1.fc22, plasma-workspace-5.3.2-2.fc22, kde-cli-tools-5.3.2-1.fc22, kwrited-5.3.2-1.fc22, plasma-nm-5.3.2-1.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/muon-5.3.2-1.fc22,plasma-workspace-wallpapers-5.3.2-1.fc22,powerdevil-5.3.2-1.fc22,plasma-breeze-5.3.2-1.fc22,bluedevil-5.3.2-1.fc22,kscreen-5.3.2-1.fc22,kdeplasma-addons-5.3.2-1.fc22,libksysguard-5.3.2-1.fc22,kio-extras-5.3.2-1.fc22,plasma-systemsettings-5.3.2-1.fc22,oxygen-fonts-5.3.2-1.fc22,sddm-kcm-5.3.2-1.fc22,plasma-oxygen-5.3.2-1.fc22,kf5-baloo-5.9.2-1.fc22,plasma-milou-5.3.2-1.fc22,polkit-kde-5.3.2-1.fc22,kmenuedit-5.3.2-1.fc22,khelpcenter-5.3.2-1.fc22,kde-gtk-config-5.3.2-1.fc22,kdecoration-5.3.2-1.fc22,ksshaskpass-5.3.2-1.fc22,libkscreen-qt5-5.3.2-1.fc22,kf5-kfilemetadata-5.9.2-1.fc22,khotkeys-5.3.2-1.fc22,plasma-sdk-5.3.2-1.fc22,kinfocenter-5.3.2-1.fc22,kwin-5.3.2-1.fc22,kf5-kwayland-5.3.2-1.fc22,plasma-desktop-5.3.2-2.fc22,ksysguard-5.3.2-1.fc22,plasma-workspace-5.3.2-2.fc22,kde-cli-tools-5.3.2-1.fc22,kwrited-5.3.2-1.fc22,plasma-nm-5.3.2-1.fc22

Comment 27 Fedora Update System 2015-06-30 00:04:32 UTC
Package muon-5.3.2-1.fc22, plasma-workspace-wallpapers-5.3.2-1.fc22, powerdevil-5.3.2-1.fc22, plasma-breeze-5.3.2-1.fc22, bluedevil-5.3.2-1.fc22, kscreen-5.3.2-1.fc22, kdeplasma-addons-5.3.2-1.fc22, libksysguard-5.3.2-1.fc22, kio-extras-5.3.2-1.fc22, plasma-systemsettings-5.3.2-1.fc22, oxygen-fonts-5.3.2-1.fc22, sddm-kcm-5.3.2-1.fc22, plasma-oxygen-5.3.2-1.fc22, kf5-baloo-5.9.2-1.fc22, plasma-milou-5.3.2-1.fc22, polkit-kde-5.3.2-1.fc22, kmenuedit-5.3.2-1.fc22, khelpcenter-5.3.2-1.fc22, kde-gtk-config-5.3.2-1.fc22, kdecoration-5.3.2-1.fc22, ksshaskpass-5.3.2-1.fc22, libkscreen-qt5-5.3.2-1.fc22, kf5-kfilemetadata-5.9.2-1.fc22, khotkeys-5.3.2-1.fc22, plasma-sdk-5.3.2-1.fc22, kinfocenter-5.3.2-1.fc22, kwin-5.3.2-1.fc22, kf5-kwayland-5.3.2-1.fc22, plasma-desktop-5.3.2-2.fc22, ksysguard-5.3.2-1.fc22, plasma-workspace-5.3.2-2.fc22, kde-cli-tools-5.3.2-1.fc22, kwrited-5.3.2-1.fc22, plasma-nm-5.3.2-1.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing muon-5.3.2-1.fc22 plasma-workspace-wallpapers-5.3.2-1.fc22 powerdevil-5.3.2-1.fc22 plasma-breeze-5.3.2-1.fc22 bluedevil-5.3.2-1.fc22 kscreen-5.3.2-1.fc22 kdeplasma-addons-5.3.2-1.fc22 libksysguard-5.3.2-1.fc22 kio-extras-5.3.2-1.fc22 plasma-systemsettings-5.3.2-1.fc22 oxygen-fonts-5.3.2-1.fc22 sddm-kcm-5.3.2-1.fc22 plasma-oxygen-5.3.2-1.fc22 kf5-baloo-5.9.2-1.fc22 plasma-milou-5.3.2-1.fc22 polkit-kde-5.3.2-1.fc22 kmenuedit-5.3.2-1.fc22 khelpcenter-5.3.2-1.fc22 kde-gtk-config-5.3.2-1.fc22 kdecoration-5.3.2-1.fc22 ksshaskpass-5.3.2-1.fc22 libkscreen-qt5-5.3.2-1.fc22 kf5-kfilemetadata-5.9.2-1.fc22 khotkeys-5.3.2-1.fc22 plasma-sdk-5.3.2-1.fc22 kinfocenter-5.3.2-1.fc22 kwin-5.3.2-1.fc22 kf5-kwayland-5.3.2-1.fc22 plasma-desktop-5.3.2-2.fc22 ksysguard-5.3.2-1.fc22 plasma-workspace-5.3.2-2.fc22 kde-cli-tools-5.3.2-1.fc22 kwrited-5.3.2-1.fc22 plasma-nm-5.3.2-1.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-10880/muon-5.3.2-1.fc22,plasma-workspace-wallpapers-5.3.2-1.fc22,powerdevil-5.3.2-1.fc22,plasma-breeze-5.3.2-1.fc22,bluedevil-5.3.2-1.fc22,kscreen-5.3.2-1.fc22,kdeplasma-addons-5.3.2-1.fc22,libksysguard-5.3.2-1.fc22,kio-extras-5.3.2-1.fc22,plasma-systemsettings-5.3.2-1.fc22,oxygen-fonts-5.3.2-1.fc22,sddm-kcm-5.3.2-1.fc22,plasma-oxygen-5.3.2-1.fc22,kf5-baloo-5.9.2-1.fc22,plasma-milou-5.3.2-1.fc22,polkit-kde-5.3.2-1.fc22,kmenuedit-5.3.2-1.fc22,khelpcenter-5.3.2-1.fc22,kde-gtk-config-5.3.2-1.fc22,kdecoration-5.3.2-1.fc22,ksshaskpass-5.3.2-1.fc22,libkscreen-qt5-5.3.2-1.fc22,kf5-kfilemetadata-5.9.2-1.fc22,khotkeys-5.3.2-1.fc22,plasma-sdk-5.3.2-1.fc22,kinfocenter-5.3.2-1.fc22,kwin-5.3.2-1.fc22,kf5-kwayland-5.3.2-1.fc22,plasma-desktop-5.3.2-2.fc22,ksysguard-5.3.2-1.fc22,plasma-workspace-5.3.2-2.fc22,kde-cli-tools-5.3.2-1.fc22,kwrited-5.3.2-1.fc22,plasma-nm-5.3.2-1.fc22
then log in and leave karma (feedback).

Comment 28 Fedora Update System 2015-07-03 18:35:07 UTC
muon-5.3.2-1.fc22, plasma-workspace-wallpapers-5.3.2-1.fc22, powerdevil-5.3.2-1.fc22, plasma-breeze-5.3.2-1.fc22, bluedevil-5.3.2-1.fc22, kscreen-5.3.2-1.fc22, kdeplasma-addons-5.3.2-1.fc22, libksysguard-5.3.2-1.fc22, kio-extras-5.3.2-1.fc22, plasma-systemsettings-5.3.2-1.fc22, oxygen-fonts-5.3.2-1.fc22, sddm-kcm-5.3.2-1.fc22, plasma-oxygen-5.3.2-1.fc22, kf5-baloo-5.9.2-1.fc22, plasma-milou-5.3.2-1.fc22, polkit-kde-5.3.2-1.fc22, kmenuedit-5.3.2-1.fc22, khelpcenter-5.3.2-1.fc22, kde-gtk-config-5.3.2-1.fc22, kdecoration-5.3.2-1.fc22, ksshaskpass-5.3.2-1.fc22, libkscreen-qt5-5.3.2-1.fc22, kf5-kfilemetadata-5.9.2-1.fc22, khotkeys-5.3.2-1.fc22, plasma-sdk-5.3.2-1.fc22, kinfocenter-5.3.2-1.fc22, kwin-5.3.2-1.fc22, kf5-kwayland-5.3.2-1.fc22, plasma-desktop-5.3.2-2.fc22, ksysguard-5.3.2-1.fc22, plasma-workspace-5.3.2-2.fc22, kde-cli-tools-5.3.2-1.fc22, kwrited-5.3.2-1.fc22, plasma-nm-5.3.2-1.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 29 Murilo Opsfelder Araujo 2015-11-14 01:50:04 UTC
This is still happening to me with Fedora 23 KDE spin.

Any change the fix did not land F23?

plasma-desktop-5.4.3-1.fc23.x86_64

Comment 30 Rex Dieter 2015-11-14 14:14:01 UTC
You might be hitting a different case.  Can you please file a new bug, ideally with the debugging output similar to comment #10 ?

Comment 31 Murilo Opsfelder Araujo 2015-11-14 23:13:00 UTC
Hello, Rex.

I removed xorg-x11-drv-libinput, rebooted, and issue still persists.

Do you think the below information is enough to file a bug against F23?

[muriloo@localhost ~]$ xlsatoms | grep -i tap
[muriloo@localhost ~]$ sudo xlsatoms | grep -i tap
[muriloo@localhost ~]$

[muriloo@localhost ~]$ rpm -q xorg-x11-drv-libinput
xorg-x11-drv-libinput-0.14.0-2.fc23.x86_64

[muriloo@localhost ~]$ sudo dnf remove xorg-x11-drv-libinput 
...
Removed:
  xorg-x11-drv-libinput.x86_64 0.14.0-2.fc23

Complete!
[muriloo@localhost ~]$ sudo reboot

After the reboot:

[muriloo@localhost ~]$ xlsatoms | grep -i tap
[muriloo@localhost ~]$ sudo xlsatoms | grep -i tap
[muriloo@localhost ~]$

Comment 32 Rajeesh 2015-11-15 05:19:30 UTC
(In reply to Murilo Opsfelder Araujo from comment #31)

This indeed looks like a different problem. Please, could you file a new bug report?

Comment 33 Murilo Opsfelder Araujo 2015-11-15 14:58:46 UTC
I have just submitted https://bugzilla.redhat.com/show_bug.cgi?id=1282210.

Thanks, Rex and Rajeesh.


Note You need to log in before you can comment on or make changes to this bug.