Issues with tuxedo-drivers-dkms

[michaldybczak]

All works fine for me, but the package tuxedo-drivers-dkms needs to be recompiled with kernel 6.8 and 6.9, because with those, it doesn’t show temperature or fan data:

I had to switch to clevo-drivers-dkms-git from AUR, which has then no issue with kernel 6.8+. Previously I was using 6.7 which worked fine with tuxedo-drivers, but now that it became EOL and I had to switch to 6.8, but I also need Tuxedo Control Center to be usable. Luckily, clevo package fixes that, but it would nicer if Manjaro package would work as well.

[freggel.doe]

@michaldybczak

but the package tuxedo-drivers-dkms needs to be recompiled with kernel 6.8 and 6.9

Ahem, that is a dkms package - it already recompiles modules for your installed kernels.

[michaldybczak]

@freggel.doe

Ahem, that is a dkms package - it already recompiles modules for your installed kernels.

It is nodepmod package - whatever that means. During updates, it looks as if it was skipping recompilation phase.
Anyway, Manjaro version of that package doesn’t work with newest manjaro kernels, while AUR version does. So something needs to be fixed with tuxedo-drivers-dkms. I’m just reporting the issue and trust that Manjaro devs will know what to do with it.

[cscs]

https://wiki.archlinux.org/title/Dynamic_Kernel_Module_Support

[Yochanan]

@michaldybczak

doesn’t work

Oh c’mon… you know better that that. Don’t make me link to the wiki & tutorials…

@michaldybczak

Manjaro version … doesn’t work …, while AUR version does.

Please examine your transaction history and tell me what the difference is between the two installations–because there shouldn’t be any since it’s a DKMS module.

@linux-aarhus also has a Tuxedo laptop and he hasn’t complained.

[michaldybczak]

@Yochanan

@linux-aarhus also has a Tuxedo laptop and he hasn’t complained.

He certainly has a different model. Mine is experimental (first gen full AMD laptop) with different components that other Tuxedo laptops and some TCC options don’t work for it at all (like fan curves).

@Yochanan

Please examine your transaction history and tell me what the difference is between the two installations–because there shouldn’t be any since it’s a DKMS module.

And yet there is a difference. However, you are right, I could install Manjaro version again and see if there is a difference now. Maybe all I needed was a reinstallation of the package. I will do that and let you know if it fixed it.

EDIT: After the reinstallation, it works correctly! Or maybe it wasn’t the reinstallation but installation of clevo package and swaping to tuxedo one? Maybe some files were missing and the clevo package added it and when tuxedo version was installed, the file remained? Ah, I’m just speculating. Anyway, it works now. Oh, I probably got it: it needs to be reinstalled with every new kernel install. I recall, that with 6.7 it also lacked the data on the beginning, and then it showed up, probably because there was a driver’s update.

I am used to rebuilding AUR packages if they stop working once in a while, but never the repo package. I guess, there is always a first time…

[cscs]

@freggel.doe

that is a dkms package

@cscs

Dynamic Kernel Module Support - ArchWiki

Though the rebuild of the DKMS modules is usually seamless during a kernel upgrade, it may still happen that the rebuild fails. You should pay extra attention to the pacman output. This applies in particular if the system relies on the DKMS module to boot successfully and/or if you use DKMS with a custom kernel not in the official repositories.

To deal with changes in the kernel, fix bugs, or add necessary features consider upgrading the DKMS package before rebooting.

Rebuild modules

Rebuild all modules for the currently running kernel:

# dkms autoinstall

or for a specific kernel:

# dkms autoinstall -k 3.16.4-1-ARCH

To build a specific module for the currently running kernel:

# dkms install -m nvidia -v 334.21

or simply:

# dkms install nvidia/334.21

To build a module for all kernels:

# dkms install nvidia/334.21 --all

[Yochanan]

@michaldybczak

I probably got it: it needs to be reinstalled with every new kernel install.

Indeed. There’s a hook for that.

❯ cat /etc/pacman.d/hooks/90-mkinitcpio-dkms-linux.hook
# https://wiki.archlinux.org/title/NVIDIA#pacman_hook
[Trigger]
Operation=Install
Operation=Upgrade
Operation=Remove
Type=Package
Target=*dkms
Target=linux
# Change the linux part above if a different kernel is used

[Action]
Description=Update DKMS modules in initcpio
Depends=mkinitcpio
When=PostTransaction
NeedsTargets
Exec=/bin/sh -c 'while read -r trg; do case $trg in linux*) exit 0; esac; done; /usr/bin/mkinitcpio -P'

[michaldybczak]

@cscs

Though the rebuild of the DKMS modules is usually seamless during a kernel upgrade, it may still happen that the rebuild fails

This package behaves differently than any of the kernel-modules. During update, it shows no-depmod info as if it was uninstalled and then installed anew to any new kernel. There is no info about any error:

Remove upgraded DKMS modules
==> dkms remove --no-depmod tuxedo-drivers/4.4.0 -k 6.6.26-1-MANJARO
==> dkms remove --no-depmod tuxedo-drivers/4.4.0 -k 6.8.5-1-MANJARO
[...]
Install DKMS modules
==> dkms install --no-depmod tuxedo-drivers/4.4.0 -k 6.6.26-1-MANJARO
==> dkms install --no-depmod tuxedo-drivers/4.4.0 -k 6.8.5-1-MANJARO
==> depmod 6.6.26-1-MANJARO
==> depmod 6.8.5-1-MANJARO

Then I get usual:

Updating linux initcpios...
==> Building image from preset: /etc/mkinitcpio.d/linux66.preset: 'default'
==> Using default configuration file: '/etc/mkinitcpio.conf'
  -> -k /boot/vmlinuz-6.6-x86_64 -g /boot/initramfs-6.6-x86_64.img
==> Starting build: '6.6.26-1-MANJARO'
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [autodetect]
  -> Running build hook: [microcode]
  -> Running build hook: [modconf]
  -> Running build hook: [kms]
  -> Running build hook: [keyboard]
==> WARNING: Possibly missing firmware for module: 'xhci_pci'

and so on.

This is the only module package that does that, and I have no idea what it means, but probably it isn’t behaving as you believe it should behave.

As to the other info about dkms - thanks, but it’s too much. I’m no IT guy, just a regular user, so it’s hard to understand all of that output. All I see is that it is doing something different from other packages, and it seems as it was skipping the rebuild, hence the issue of needing to be reinstalled after the new kernel install.

From the link you gave me:

Note: dkms install is making sure depmod is called at the end of its process. dkms install depends on dkms build (to build the source against the current kernel), which itself depends on dkms add (to add a symlink from /var/lib/dkms/PACKAGE_NAME/PACKAGE_VERSION/source to /usr/src/PACKAGE_NAME-PACKAGE_VERSION).

That looks it isn’t happening with this package. I assumed that this is normal and intended to behave that way from some reason. If not, maybe this is an issue to solve?

I think I can ask TUXEDO support about it. They should know.

EDIT: I found in Arch manuals:

–no-depmod
This option prevents DKMS from running the depmod command during install and uninstall which will avoid (re)calculating module dependencies and thereby save time.

Hmm… From what I can understand, this is a “static” package, meaning that when usually any kernel changes are done, modules are compiled again to that newer version, while the tuxedo-drivers package is just a module that attaches to any kernel version. So, instead having versions per kernel version, it has versions independent of the kernel. Because of that, it must be uninstalled and installed anew each time. Normally, kernel would expect a different module version to be updated, but it isn’t available, this uninstall and install later method tricks it to use the same version over and over. Option --no-depmod is used, because dependencies hasn’t changed. Somehow, this process is broken while installing a new kernel, where the module is not registered properly, hence the need to reinstall the package. At least this is what I could figure it out, but I may be wrong,

[linux-aarhus]

@michaldybczak

meaning that when usually any kernel changes are done, modules are compiled again to that newer version

Assuming you have the headers installed for the kernel in question.

Depending whether you use mhwd-kernel or pacman to install a new kernel - only the former will also install headers if present for the running kernel.

On the Tuxedo I use - everything is supported with Manjaro OOB - no need for tuxedo control panel - everything just works.

In fact when I install the tuxedo-drivers-dkms the touchpad on/off stops working.

If I were you I would test how Manjaro kernel works without Tuxedo drivers - then consider what needs to be done.

@michaldybczak

first gen full AMD laptop

Is that the Pulse model or did they build models with all AMD before the Pulse?

Just checked their web - Sirius model perhaps?

[michaldybczak]

@linux-aarhus

Just checked their web - Sirius model perhaps?

Yes, Sirius.

Given the fact that with not fully registered to the kernel drivers make the TCC not show temperature and fan, suggests that they are needed. However, I can do an experiment and see if it is really so.

@linux-aarhus

On the Tuxedo I use - everything is supported with Manjaro OOB - no need for tuxedo control panel - everything just works.

TCC is needed for control of CPU power and overall work culture. By default, CPU is powerful and there are constant frequency spikes, which makes the system use more energy, and it heats up frequently, making fans to work intensely and loud. Once I applied frequency caps on CPU, temperatures keep to the certain limits and fans are quiet. So TCC is not only showing up CPU/GPU stats, temperatures and fans, but also can control how laptop behaves. Limiting CPUs power doesn’t influence visibly on performance during work and daily tasks, but laptop stays quiet and more energy efficient. I only switch to full power mode for gaming, which I do sporadically. So Tuxedo Control Center is very, very useful.

When I first got the laptop, fans were so loud and were driving me crazy. Once I applied profiles, all went to the state I was used to, quiet work.

On other models, there is a possibility to control fans, which doesn’t work on Sirius. However, seeing how well I can influence fans by limiting CPU, makes it not essential, because I got what I wanted - a quiet and efficient laptop.

@linux-aarhus

In fact when I install the tuxedo-drivers-dkms the touchpad on/off stops working.

I don’t know what that is. Is there such an option? Why would I turn off the touchpad? Plasma makes a good job of turning it off automatically when writing, so I never experienced accidental touch gestures while writing. Or maybe I just don’t touch it while writing, so this is a non issue for me? Either way, I don’t see a reason to turn off the touchpad.

However, I would gladly make NUM permanent, in a way, that it couldn’t be turned off by accident hits. Also, I hate context-menu key that lies between right-Alt and right-Ctrl. I would gladly rip it off the keyboard! Maybe there is a way to deactivate it permanently. Other than that, keyboard is awesome and touchpad is also great, although it lacks the separate buttons. A stupid trend. Now only the highest-class and most expensive laptops have it - for a reason. Clicks are way more convenient and you avoid wrong touch registers. Now it too often detects my finger laying on the lower edge and when I do a gesture with another finger, it registers it incorrectly. All my life I had click buttons on touchpad, so I can’t get use to not keeping some fingers on the bottom edge constantly.
Uh, uh… I strayed out of the topic.

@linux-aarhus

Depending whether you use mhwd-kernel or pacman to install a new kernel - only the former will also install headers if present for the running kernel.

I use only mhwd to change kernels. I don’t have expertise to use different ones, so I am sticking with what Manjaro offers. However, I would do an exception, if there were tuxedo-kernels in AUR, because they have a fix to make suspension work. Regular kernels don’t have it, as the fix didn’t make upstream so far.

There are also some smaller quirks. Hardware is not so well Linux compatible IMO. My old, Alienware laptop with Nvidia was way more Linux compatible (the only issue was with sound, but that was a race condition on a driver that was showing only once a month, so not a big deal). In Sirus there is a bunch of issues thou, with Plasma gestures in Wayland, or with Jabra not being able to work as a microphone and speaker at the same time, etc.