Arch Linux User Repository

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.

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.

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).

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…

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:

1. Download the package manually
2. Run makepkg -o
3. Edit the file in the source code src/tuxedo-something/src/tuxedo_keyboard.c
4. 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"

1. Install the package by running makepkg -se in the root dir where you cloned it

Since commit #254e167 (https://github.com/tuxedocomputers/tuxedo-keyboard/commit/254e16714f91a6041f29b36ee547be98572643e5), Tuxedo has added a TUXEDO DMI string check.

Noobie here. Just a reminder to fellow noobs, if you are using linux-lts, then make sure you have linux-lts-headers installed. Otherwise dkms will complain with something like this:

(2/2) Install DKMS modules ==> ERROR: Missing opt kernel headers for module tuxedo-keyboard/3.2.3. ==> ERROR: Missing etc kernel headers for module tuxedo-keyboard/3.2.3.

Since version 3.2.0, tuxedo-keyboard uses the SysFS Interface. https://github.com/tuxedocomputers/tuxedo-keyboard/blob/4749901db2dcc3430bf6497086bb9fefbac7eeff/src_pkg/rpm_pkg.spec#L144-L148