Newest X server and libinput, libwacom have left system without keyboard or mouse input
 

Running on current and ran the updates from Saturday. This added packages libinput, libwacom and the rebuilt X-19 server. The is causing all X sessions, regardless of DE/WM to have no keyboard or mouse input. The only means to close X is to reboot! Anyone else having this bug?

have you installed the new 'xf86-input-libinput' package

x/xf86-input-libinput-0.23.0-x86_64-1.txz: Added.
This is the new generic X.Org input driver which replaces evdev for most
purposes. It does not (for now) replace xf86-input-synaptics or
xf86-input-vmmouse. If this driver package is missing then X will fall
back to using xf86-input-evdev as before.
Thanks to Robby Workman.

I can confirm the same issue here. As soon as i startx, regradless of window manage/DE i have to hard reboot because i have no input whatsoever.

I just updated earlier today, and rebooted a few minutes ago. I've checked all packages on the command line using
and there are only 2 packages listed, one for fbdev and the other for noveaua.

Also checked that i've done;
Still no input from mouse/keyboard, having to boot into a small xubuntu partition to type this.

Hi , im not have that problem in my machines.

If "reinstall" is NOT a problem , then try to download current iso and install.

http://bear.alienbase.nl/mirrors/sla...e-current-iso/

Yes, I accepted all the package new installs and updates using slackpkg. I'm using the nouveau driver. Because I accept all changes at one time, I'm not sure if the error is X-server rebuild or the libinput/libwacom. If libinput/libwacom, hopefully they can be removed and this will resolve.

Posting right now using Live Slak DVD, although I tried using lnyx to post to forum it was really hard to use since it wasn't displaying easily on my default tty screen. Another reason to have a handy-dandy Live Slak, thank you Alien Bob!

I had the same issue with my laptop and resorted to doing a removepkg xf86-input-libinput.

Thanks for suggesting that!

I just booted back into my slackware and did;
X is working fine again now! and seems to have resolved the problem for me. Cheers!

and why no try to remove evdev ? ... probably input and evdev conflict to manage hardware.

well.. slackpkg clean-system didn't present any packages to remove. Just to be clear, the changelog for xf86-libinput and latest updates actually would suggest that you DO NOT want to remove evdev, because it is a fallback position.

That's what i thought when removing the other two packages. Surely the fallback would continue to work as it would before.

@coralfang - did you remove both packages at the same time or test in-between each removal?
I'm curious because my version of xf86-input-wacom is from Nov 19, 2016 but xf86-input-libinput was properly updated yesterday.

Yesterday the log shows installation of new libwacom-0.22-x86_64-1 from slackware64 repository, as a dependency for new libinput-1.5.4, as spelled out in the change-log. Already installed was libinput-1.3.3-x86_64-1alien. libinput-1.5.4 was selected for upgrade, and in slackpkg+ I don't have alien's packages blacklisted or greylisted, but Alienbob's repositories are priority in slackpkg+. So I'm wondering if the slackware64 package was deprecated during the upgrade as a result? Remembering that slackpkg doesn't care about release level and only alpha package name.

Probably the bug is that libinput-1.5.4 wasn't installed due to the slackpkg+ priorities and libwacom or xf86-input-libinput and the old libinput-1.3.3 aren't in sync to collaborate. This would be the second time in five months on current that upgrades have failed because I wasn't aware or anticipate a potential conflict with packages between slackware64 and alienbob Plasma 5 packages.

I might have to reconsider if the pure slackpkg and 14.2 would be more stable for me, based on my Linux skills and analysis of potential conflicts. I'd also eliminate multilib, restricted (bye vlc codecs), ktown, and alienbob generally (bye WINE). I just don't know how to replace one program that needs real .Net and WINE 32bit services at this point though.

This would not be a problem at all if you didn't use slackpkg+. If you just managed Eric's extra packages manually, then things should just work. The only exception would be for new packages added to Slackware that Eric had available, because you probably had his packages blacklisted (so slackpkg wouldn't accidentally "upgrade" them with any stock packages), so at that point, you'd need to check the changelog for newly added items and verify you don't have an "alien" version installed.

But, even if you stuck with slackpkg+ and had his repos added with priority, if you stayed with 14.2 instead of -current, you wouldn't run into this either. Because 14.2 should never see new packages added, only updates to existing packages. So there shouldn't be any update that would require you to replace alien packages with stock packages (except for maybe gcc or glibc updates, if Eric doesn't refresh his multilib packages right away).

People, this has already been issued here: http://www.linuxquestions.org/questi...re-4175597804/

There is a "Search" button here at LQ, try use it.

@ Bindestrck: This issue has two different titles for each thread. Searching did NOT show the libinput thread BEFORE I posted the original question, because the cause of my issue was unclear at the time of my posting and I wanted to be as broad as possible. There are many times posts about the same issue, but discovered and analyzed through different thinking processes and aids from members. No one else seems to care that there are more than one thread.

@bassmadrigal: Actually alien's repositories are not blacklisted or greylisted. They are prioritized. The slackpkg+ process which caught me, which I added to the Libinput-Beware thread, is that slackpkg+ may not be aware of the version and only acted on the package name or followed the package priorities setup in slackpkg+. What is also interesting is that slackware64 repository updates are regularly presented when issuing slackpkg install-new and upgrade-all (even for minor version updates), even if an alienbob version has the same package in his repositories. Specifically, it seems that slackpkg+ is prioritizing slackware64 first since alien and SBo are not black/greylisted. This bug with Libinput maybe an anomoly with libinput and may need further research by others who better understand the intricacy of slackpkg+ processes and prioritizing. However the fix is to be aware of the issue with libinput package when using slackpkg+. Oh even if running 14.2, the same issue will occur if a user forgets to run all four steps of slackpkg ie. read change-log, install-new, upgrade-all, clean-system. Maybe a fifth step is that one MUST verify that all packages actually installed, because in my case, and others on that other thread, the Libinput file was NOT installed even though selected until they turnedoff slackpkg+!

The blacklist I was referring to was if you were NOT using slackpkg+. You would need to blacklist those packages, especially multilib and ktown, to ensure that they aren't overwritten by the stock install packages. Any updates from Eric would need to be manually downloaded and installed, but any new packages by Pat would show up properly using either install-new (if it isn't installed) or upgrade-all (if you had an alternate version from another source like Eric installed).

I then went on to say that if you were to use slackpkg+ on a stable system (eg, not -current), then it would be unlikely to run into this issue as packages are never added to Slackware stable (at least, not that I can remember). There'll only be updates to existing packages (you shouldn't ever need to run install-new on a stable system). So, libinput would never be added to 14.2 and you Eric's package would still remain. So, slackpkg+ would work fine, and it would follow the priorities you have set in your slackpkgplus.conf file. The only issue I could see is if Pat were to upgrade one of the multilib packages (gcc or glibc) and if you were to run slackpkg before Eric refreshes his versions, you could lose multilib functionality until updated multilib packages are available.

But, ultimately, it is best to read the changelog, whether you're running -current or stable, slackpkg or slackpkg+, other tools, or manually doing everything. Reading the changelog helps make you aware of what changes these tools might be making.