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
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.
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. :-/
and, now I can reproduce the problem again, I have xorg-x11-server-1.17.1-7.fc22 installed now.
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.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
kcm_touchpad is now part of the plasma-desktop package, reassigning.
*** Bug 1225579 has been marked as a duplicate of this bug. ***
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.
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.
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 ?
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
I'll prepare a patch and test that theory...
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.
Confirmed patch seems to work as advertised, will submit a build for testing purposes.
If anyone's willing to test, try this f22 build: https://koji.fedoraproject.org/koji/buildinfo?buildID=664677
(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"; }
(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?
(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 :)
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;
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
(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...
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 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); }
Thanks for solving the puzzle! I will revise the patch accordingly, and see if it actually fixes issue for other reporters.
*** Bug 1229304 has been marked as a duplicate of this bug. ***
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
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).
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.
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
You might be hitting a different case. Can you please file a new bug, ideally with the debugging output similar to comment #10 ?
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 ~]$
(In reply to Murilo Opsfelder Araujo from comment #31) This indeed looks like a different problem. Please, could you file a new bug report?
I have just submitted https://bugzilla.redhat.com/show_bug.cgi?id=1282210. Thanks, Rex and Rajeesh.