With the latest update to 4.0.0 the keyboard backlight isn't working properly anymore in the Tuxedo Control Center, stating that it requires tuxedo-keyboard 3.2 at least
Search Criteria
Package Details: tuxedo-drivers-dkms 4.4.3-1
Package Actions
| Git Clone URL: | https://aur.archlinux.org/tuxedo-drivers-dkms.git (read-only, click to copy) |
|---|---|
| Package Base: | tuxedo-drivers-dkms |
| Description: | TUXEDO Computers kernel module drivers for keyboard, keyboard backlight & general hardware I/O using the SysFS interface |
| Upstream URL: | https://github.com/tuxedocomputers/tuxedo-drivers |
| Keywords: | tuxedo tuxedo-drivers |
| Licenses: | GPL3 |
| Conflicts: | tuxedo-keyboard-dkms, tuxedo-keyboard-ite-dkms |
| Provides: | clevo-acpi, clevo-wmi, ite_8291, ite_8291_lb, ite_8297, ite_829x, tuxedo-io, tuxedo-keyboard, tuxedo-keyboard-ite, uniwill-wmi |
| Submitter: | StevenSeifried |
| Maintainer: | StevenSeifried |
| Last Packager: | StevenSeifried |
| Votes: | 31 |
| Popularity: | 1.46 |
| First Submitted: | 2023-12-11 18:55 (UTC) |
| Last Updated: | 2024-05-08 15:51 (UTC) |
Dependencies (5)
- dkms
- linux-hardened-headers (linux-hardened-headers-gitAUR) (optional) – build modules against the HARDENED kernel
- linux-headers (linux-headers-binAUR) (optional) – build modules against Arch kernel
- linux-lts-headers (optional) – build modules against LTS kernel
- linux-zen-headers (optional) – build modules against ZEN kernel
Required by (6)
- tailor-hwcaps (requires tuxedo-io)
- tailor-hwcaps (requires tuxedo-keyboard)
- tailord (requires tuxedo-io)
- tailord (requires tuxedo-keyboard)
- tuxedo-backlight-control-git (requires tuxedo-keyboard)
- tuxedo-control-center-bin
Sources (3)
FuzzyAtish commented on 2023-12-12 16:20 (UTC)
holwes commented on 2023-12-12 08:38 (UTC)
The repository (tuxedo-keyboard) will no longer get any updates as the code is now part of tuxedo-drivers. I had to remove "tuxedo-control-center-bin" first, afterwards "tuxedo-keyboard-dkms" and last not least reinstall "tuxedo-control-center-bin". Otherwise you are caught in a dependency loop.
gilbus commented on 2023-12-12 08:12 (UTC)
I'd like to make the same request as in 'tuxedo-keyboard-dkms' (https://aur.archlinux.org/packages/tuxedo-keyboard-dkms#comment-947474) namely, moving the installed files out of /etc/ to their respective directories.
gilbus commented on 2023-12-12 08:04 (UTC)
Thanks a lot for packaging! Would you consider moving the installed files out of /etc and to their respective directories /usr/lib/modules-load.d/ and /lib/modprobe.d/? This way /etc/ only contains modifications/overrides.
sekret commented on 2023-12-11 19:45 (UTC)
Thanks for this package!
I replaced tuxedo-keyboard with it. Looks like you should also put "tuxedo-io" into provides=(), because tailord requires it.
Also, the package itself includes no binaries, so arch=('any') should be the right choice.
Camponotus commented on 2023-11-27 14:18 (UTC)
Hi StevenSeifried!
Thank you for integrating a run of mkinitcpio to post install hooks with the last update! Until now I had to perform this manually. Did you change something in addition in version 3.2.14-1 ? At the moment everything works as it should – no problem with the keyboard while entering the password on boot! (see my last comment for details).
Camponotus commented on 2023-10-24 19:45 (UTC) (edited on 2023-10-24 19:46 (UTC) by Camponotus)
Hi!
I use tuxedo-keyboard/tuxedo-keybord-dkms since about two years. Without any trouble at the first year. But one year ago a strange behavior occurred… and I am still not sure where the problem is located because it occur most of the time but not every time. So I sometimes already thought it is fixed, but it was not…
I have an encrypted system and I directly start my system with a Unified kernel image signed for Secure Boot directly with a UEFI boot entry. The Hooks in my mkinitcpio therefor are:
base systemd plymouth keyboard autodetect modconf kms block sd-vconsole sd-encrypt lvm2 filesystems fsck
Since one year, on most reboots the keyboard hangs after some pressed buttons when it comes to enter the password in the early boot process. The keyboard is dead after this. Even if I plug a external keyboard to complete the password and boot successfully, the built in keyboard keeps unusable. The only thing I can do – do not touch the keyboard of my laptop while booting up the system and only use the external keyboard for booting. After the system is up I can unplug the external keyboard and use the built in keyboard without any troubles.
What could be the reason for this behavior? Anyone an idea how tuxedo-keyboard could mess up the usability of the keyboard in early boot process? Or is there a possibility to only integrate the stock driver for the keyboard into the initramfs without the backlight? – I do not really need this feature at the password prompt…
evorster commented on 2023-08-24 08:54 (UTC) (edited on 2023-08-24 11:44 (UTC) by evorster)
Hi there!
If you have a Sager laptop which is basically a rebranded Tuxedo laptop, you can still get this driver to work. You just have to get around that DMI string check mentioned below.
Using modified instructions from a comment in the clevo-xms-wmi:
- Download the package manually
- Run makepkg -o
- Edit the file in the source code src/tuxedo-something/src/tuxedo_keyboard.c
- Search for "DMI_MATCH" and set the DMI strings to what matches your system.
How to find what matches your system?
sudo dmidecode | grep Manufacturer
Use the first three hits, on my system it was "Notebook", "Notebook" and "No Enclosure"
- Install the package by running makepkg -se in the root dir where you cloned it
Pinned Comments
StevenSeifried commented on 2024-01-07 11:02 (UTC)
Please don't abuse the "Flag package out-of-date" function to report bugs, please use the comment function as intended.
When the "Flag package out-of-date" will be abused to report a bug, I will unflag it and wait, that the bug will be reported as comment. If you don't want to report a bug as comment, please feel free to contact me directly via e-mail. Unflagging doesn't mean that I'm "implied refusal to correct".
Also, filling out an "Orphan Request" more or less directly after I unflagged it, isn't fair. I don't always have the time to take care of it straight away. So, please give me time.