New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
xinput issues #323
Comments
I dont know what version of Debian you are running, but this should cover it: https://packages.debian.org/search?keywords=xinput We have talked internally about different pages for different systems based on what is bundled, but that's something we wont be able to get to immediately. |
I might be able to check/disable that page in lumina-config if the utility is not found. Let me look into that.... |
Fixed! I added a quick runtime check for the "xinput" utility, and if it is not available then the input devices page in lumina-config will not be available. |
I should have been more clear. I'm not talking about the xinput executable, but the xinput header file. Lumina fails to build on my system because of a missing compile-time dependency which is not provided by the xinput package. My problem is that the xcb/xinput.h header file is not available. Having a run-time check for the xinput program is a good run-time work around, but first I need to get Lumina to compile. So far as I can tell, using apt-file, there is no xinput.h header file in Debian. |
Ok, that makes more sense now. |
Yep - part of the base XCB library on FreeBSD: |
It is not even in a separate library bundle. The main "libxcb" dist file looks like it includes it. |
|
Now that I think about this, there are several distros that split dev files into other packages. So this will probably end up being an issue that others face as well. |
Not only that, but the header is in another location. On my system (with libxi-dev installed, thanks for tracking down the package), the XInput.h file is stored in the PREFIX/include/X11/extensions/ directory. Where it looks like Lumina's build process is looking in PREFIX/include/xcb/ for the file. We should probably have this in the search/includ path and mention the libxi-dev package dependency in the documentation. |
The X11/extensions directory should be for the XLib libraries, not the XCB libraries (same effect - different libraries though) |
Slicer69, can you let me know if other than xinput and libxi-dev that the list that appears in the DEPENDENCY file are correct for Debian? Did you find that you needed anything else, if so I want to get that added to the list. |
I think those were the only two dependency issues. |
Same error here on Debian Jessie, "xcb/xinput.h" does not exist in the distro. |
That would explain all the xinput/xcb errors I run into when xinput.h has been added to the system. Thanks for confirming it's not just me messing up the build process. |
Ok - Try this now: dc8e7ac The new "NO_XINPUT" compile-time flag will disable the use of the xcb/xinput.h class (and disable the input device properties page in lumina-config) if your OS does not have that include file for some reason. |
New release archive created for 1.2.0 which includes this change: |
I compiled the new Lumina patch and confirmed "qmake CONFIG+=NO_XINPUT LINUX_DISTRO=Debian" works on my Debian Stable system. |
Can you also update description of build process on https://lumina-desktop.org/get-lumina/#source-debian page? |
I just disabled that xinput usage permanently. |
I tried to build the new Lumina snapshot (from Dec 12th) on Debian Linux and ran into a few problems, all with the new xinput code. The problems basically seem to boil down into two things:
xinput isn't available in Debian, causing an dependency issue.
The xinput website (as it is listed in the FreeBSD port) does not exist, so I cannot learn about xinput and download/build it.
I checked and it looks like other BSDs do not have xinput either, making Lumina more or less tied to FreeBSD-based systems until we can patch around the dependency. Maybe we can add platform checks to the code which basically makes xinput a FreeBSD exclusive feature for now?
The text was updated successfully, but these errors were encountered: