Tuxedo Pulse 15, Tuxedo Control Center wont show CPU Temp and no control with CPU clock/Fan

Support Software & Applications
1

Since i have bought my Tuxedo Pulse 15 Laptop, i have issues with this software, i used the newest client from official manjaro repo but as i said in Topic, CPU Temp showed N/A and also the CPU Fan is N/A, i also cant control the CPU Frequency… the Software showed me access but nothing happend, after im adjusting the clock.

journalctl -p 3 -xb:

Jul 27 17:06:46 koboldx-tuxedopulse15 systemd-modules-load[346]: Failed to find module 'tuxedo_io'
Jul 27 17:06:46 koboldx-tuxedopulse15 systemd-modules-load[346]: Failed to find module 'tuxedo_keyboard'

inxi --admin --verbosity=7 --filter --no-host --width:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "",
        LC_ALL = (unset),
        LC_MONETARY = "de_DE.UTF-8",
        LC_MEASUREMENT = "de_DE.UTF-8",
        LC_TIME = "de_DE.UTF-8",
        LC_NUMERIC = "de_DE.UTF-8",
        LANG = "en_DE.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
System:
  Kernel: 5.15.55-1-MANJARO arch: x86_64 bits: 64 compiler: gcc v: 12.1.0
    parameters: BOOT_IMAGE=/vmlinuz-5.15-x86_64
    root=UUID=117a5f35-5599-4992-850a-7d04cb4bca27 rw quiet apparmor=1
    security=apparmor udev.log_priority=3
  Desktop: KDE Plasma v: 5.24.6 tk: Qt v: 5.15.5 wm: kwin_x11 vt: 1 dm: SDDM
    Distro: Manjaro Linux base: Arch Linux
Machine:
  Type: Laptop System: TUXEDO product: TUXEDO Pulse 15 Gen1 v: Standard
    serial: <superuser required>
  Mobo: NB02 model: PULSE1501 v: Standard serial: <superuser required>
    BIOS: American Megatrends v: N.1.07.A03 date: 05/11/2021
Battery:
  ID-1: BAT0 charge: 91.6 Wh (100.0%) condition: 91.6/91.6 Wh (100.0%)
    volts: 12.9 min: 11.6 model: standard type: Li-ion serial: <filter>
    status: full
Memory:
  RAM: total: 15.05 GiB used: 2.2 GiB (14.6%)
  RAM Report:
    permissions: Unable to run dmidecode. Root privileges required.
CPU:
  Info: model: AMD Ryzen 7 4800H with Radeon Graphics bits: 64 type: MT MCP
    arch: Zen 2 gen: 3 built: 2020-22 process: TSMC n7 (7nm) family: 0x17 (23)
    model-id: 0x60 (96) stepping: 1 microcode: 0x8600103
  Topology: cpus: 1x cores: 8 tpc: 2 threads: 16 smt: enabled cache:
    L1: 512 KiB desc: d-8x32 KiB; i-8x32 KiB L2: 4 MiB desc: 8x512 KiB L3: 8 MiB
    desc: 2x4 MiB
  Speed (MHz): avg: 1593 high: 2732 min/max: 1400/2900 boost: enabled
    scaling: driver: acpi-cpufreq governor: ondemand cores: 1: 2634 2: 1398
    3: 2053 4: 2732 5: 1393 6: 1395 7: 1401 8: 1397 9: 1397 10: 1397 11: 1397
    12: 1317 13: 1397 14: 1397 15: 1395 16: 1397 bogomips: 92657
  Flags: 3dnowprefetch abm adx aes aperfmperf apic arat avic avx avx2 bmi1
    bmi2 bpext cat_l3 cdp_l3 clflush clflushopt clwb clzero cmov cmp_legacy
    constant_tsc cpb cpuid cqm cqm_llc cqm_mbm_local cqm_mbm_total
    cqm_occup_llc cr8_legacy cx16 cx8 de decodeassists extapic extd_apicid
    f16c flushbyasid fma fpu fsgsbase fxsr fxsr_opt ht hw_pstate ibpb ibrs ibs
    irperf lahf_lm lbrv lm mba mca mce misalignsse mmx mmxext monitor movbe
    msr mtrr mwaitx nonstop_tsc nopl npt nrip_save nx osvw overflow_recov pae
    pat pausefilter pclmulqdq pdpe1gb perfctr_core perfctr_llc perfctr_nb
    pfthreshold pge pni popcnt pse pse36 rapl rdpid rdpru rdrand rdseed rdt_a
    rdtscp rep_good sep sha_ni skinit smap smca smep ssbd sse sse2 sse4_1
    sse4_2 sse4a ssse3 stibp succor svm svm_lock syscall tce topoext tsc
    tsc_scale umip v_spec_ctrl v_vmsave_vmload vgif vmcb_clean vme vmmcall
    wbnoinvd wdt xgetbv1 xsave xsavec xsaveerptr xsaveopt xsaves
  Vulnerabilities:
  Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: mmio_stale_data status: Not affected
  Type: spec_store_bypass
    mitigation: Speculative Store Bypass disabled via prctl and seccomp
  Type: spectre_v1
    mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Retpolines, IBPB: conditional, IBRS_FW,
    STIBP: conditional, RSB filling
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: AMD Renoir vendor: Tongfang Hongkong driver: amdgpu v: kernel
    arch: GCN 5.1 process: TSMC n7 (7nm) built: 2018-21 pcie: gen: 4
    speed: 16 GT/s lanes: 16 ports: active: eDP-1 empty: HDMI-A-1
    bus-ID: 03:00.0 chip-ID: 1002:1636 class-ID: 0300
  Display: x11 server: X.Org v: 21.1.4 compositor: kwin_x11 driver: X:
    loaded: amdgpu unloaded: modesetting alternate: fbdev,vesa gpu: amdgpu
    display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22")
    s-diag: 582mm (22.93")
  Monitor-1: eDP-1 mapped: eDP model: BOE Display 0x0900 built: 2019
    res: 1920x1080 hz: 60 dpi: 142 gamma: 1.2 size: 344x194mm (13.54x7.64")
    diag: 395mm (15.5") ratio: 16:9 modes: max: 1920x1080 min: 640x480
  OpenGL: renderer: AMD RENOIR (LLVM 14.0.6 DRM 3.42 5.15.55-1-MANJARO)
    v: 4.6 Mesa 22.1.3 direct render: Yes
Audio:
  Device-1: AMD Renoir Radeon High Definition Audio vendor: Tongfang Hongkong
    driver: snd_hda_intel v: kernel pcie: gen: 4 speed: 16 GT/s lanes: 16
    bus-ID: 03:00.1 chip-ID: 1002:1637 class-ID: 0403
  Device-2: AMD ACP/ACP3X/ACP6x Audio Coprocessor vendor: Tongfang Hongkong
    driver: N/A alternate: snd_pci_acp3x, snd_rn_pci_acp3x, snd_pci_acp5x pcie:
    gen: 4 speed: 16 GT/s lanes: 16 bus-ID: 03:00.5 chip-ID: 1022:15e2
    class-ID: 0480
  Device-3: AMD Family 17h/19h HD Audio vendor: Tongfang Hongkong
    driver: snd_hda_intel v: kernel pcie: gen: 4 speed: 16 GT/s lanes: 16
    bus-ID: 03:00.6 chip-ID: 1022:15e3 class-ID: 0403
  Sound Server-1: ALSA v: k5.15.55-1-MANJARO running: yes
  Sound Server-2: JACK v: 1.9.21 running: no
  Sound Server-3: PulseAudio v: 16.1 running: yes
  Sound Server-4: PipeWire v: 0.3.56 running: yes
Network:
  Device-1: Intel Wi-Fi 6 AX200 driver: iwlwifi v: kernel pcie: gen: 2
    speed: 5 GT/s lanes: 1 bus-ID: 01:00.0 chip-ID: 8086:2723 class-ID: 0280
  IF: wlp1s0 state: down mac: <filter>
  Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
    vendor: Tongfang Hongkong driver: r8169 v: kernel pcie: gen: 1
    speed: 2.5 GT/s lanes: 1 port: f000 bus-ID: 02:00.0 chip-ID: 10ec:8168
    class-ID: 0200
  IF: eno1 state: up speed: 100 Mbps duplex: full mac: <filter>
  IP v4: <filter> type: dynamic noprefixroute scope: global
    broadcast: <filter>
  IP v6: <filter> type: noprefixroute scope: link
  WAN IP: <filter>
Bluetooth:
  Device-1: Intel AX200 Bluetooth type: USB driver: btusb v: 0.8
    bus-ID: 1-4.4:4 chip-ID: 8087:0029 class-ID: e001
  Report: rfkill ID: hci0 rfk-id: 0 state: up address: see --recommends
Logical:
  Message: No logical block device data found.
RAID:
  Message: No RAID data found.
Drives:
  Local Storage: total: 465.76 GiB used: 22.34 GiB (4.8%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/sda maj-min: 8:0 vendor: Samsung model: SSD 860 EVO M.2 500GB
    size: 465.76 GiB block-size: physical: 512 B logical: 512 B speed: 6.0 Gb/s
    type: SSD serial: <filter> rev: 4B6Q scheme: MBR
  Message: No optical or floppy data found.
Partition:
  ID-1: / raw-size: 240.66 GiB size: 235.82 GiB (97.99%)
    used: 17.71 GiB (7.5%) fs: ext4 dev: /dev/sda2 maj-min: 8:2 label: N/A
    uuid: 117a5f35-5599-4992-850a-7d04cb4bca27
  ID-2: /boot raw-size: 500 MiB size: 458.3 MiB (91.67%)
    used: 62.7 MiB (13.7%) fs: ext3 dev: /dev/sda1 maj-min: 8:1 label: Boot
    uuid: be5baa10-5f66-4e30-b9c6-a1788e510c69
  ID-3: /home raw-size: 175.78 GiB size: 171.96 GiB (97.83%)
    used: 4.57 GiB (2.7%) fs: ext4 dev: /dev/sda3 maj-min: 8:3 label: Home
    uuid: 71a27b4e-f3fb-43e1-8e9d-8f5eec561bdd
Swap:
  Alert: No swap data was found.
Unmounted:
  ID-1: /dev/sda4 maj-min: 8:4 size: 2.93 GiB fs: swap label: N/A
    uuid: a5d2ba7c-3b01-46f0-8f71-ebab43cf0582
USB:
  Hub-1: 1-0:1 info: Hi-speed hub with single TT ports: 4 rev: 2.0
    speed: 480 Mb/s chip-ID: 1d6b:0002 class-ID: 0900
  Hub-2: 1-4:2 info: Genesys Logic Hub ports: 4 rev: 2.0 speed: 480 Mb/s
    power: 100mA chip-ID: 05e3:0608 class-ID: 0900
  Device-1: 1-4.3:3 info: Realtek RTS5129 Card Reader Controller
    type: <vendor specific> driver: rtsx_usb,rtsx_usb_ms,rtsx_usb_sdmmc
    interfaces: 1 rev: 2.0 speed: 480 Mb/s power: 500mA chip-ID: 0bda:0129
    class-ID: ff00 serial: <filter>
  Device-2: 1-4.4:4 info: Intel AX200 Bluetooth type: Bluetooth
    driver: btusb interfaces: 2 rev: 2.0 speed: 12 Mb/s power: 100mA
    chip-ID: 8087:0029 class-ID: e001
  Hub-3: 2-0:1 info: Super-speed hub ports: 2 rev: 3.1 speed: 10 Gb/s
    chip-ID: 1d6b:0003 class-ID: 0900
  Hub-4: 3-0:1 info: Hi-speed hub with single TT ports: 4 rev: 2.0
    speed: 480 Mb/s chip-ID: 1d6b:0002 class-ID: 0900
  Hub-5: 4-0:1 info: Super-speed hub ports: 2 rev: 3.1 speed: 10 Gb/s
    chip-ID: 1d6b:0003 class-ID: 0900
Sensors:
  System Temperatures: cpu: N/A mobo: N/A gpu: amdgpu temp: 40.0 C
  Fan Speeds (RPM): N/A
Info:
  Processes: 328 Uptime: 30m wakeups: 1 Init: systemd v: 251
  default: graphical tool: systemctl Compilers: gcc: 12.1.0 clang: 14.0.6
  Packages: pacman: 1313 lib: 346 flatpak: 0 Shell: Bash v: 5.1.16
  running-in: konsole inxi: 3.3.19
2

it’s sad to read that another tuxedo-customer is in trouble due to lack of support. that should not happen and is a bad reputation for this company which sells a linux-related package and doesn’t care to keep the support up to date. you could enable the aur-repositories and check if there is anything that could help in your case.
i feel really sorry, thought this company wanted to get a well honored supplier for linux-equipped hardware but the reputation is sinking from day to day.

1 Like
4

The sensors isn’t actually a problem with the laptop vendor, it’s something that the kernel changed for reasons unclear to me, they switched AMD ryzen from showing and using TDIE sensor data, which is the cpu temp, to using TCTL:

sensors
  ...
k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +52.0°C

https://www.kernel.org/doc/html/v5.12/hwmon/k10temp.html

Tctl is the processor temperature control value, used by the platform to
control cooling systems. Tctl is a non-physical temperature on an arbitrary
scale measured in degrees. It does not represent an actual physical
temperature like die or case temperature.

I don’t remember exactly when this regression happened, I want to say around kernel 5.14-15, but I could be off. AMD Zen with TDIE data worked fine since Zen was introduced, then it just vanished from sensors output, and from /sys and anywhere else sensor data is to be found.

Despite what that kernel documentation says, I have yet to see a single AMD Zen instance that shows both TDIE and TCTL sensor output, only the strange and hard to explain Tctl, which is allegedly not the actual cpu temp at all, though to me it looks like it is. But I haven’t added that as a fallback source in inxi unfortunately because the kernel docs are so clear about saying it is a synthetic value that has very little to do with your actual cpu temp.

I’ve been aware of this issue for a while, and probably should decide on some fix for it because it does not look like the original TDIE, the actual cpu die temperature, is getting restored. I don’t know if this was a kernel regresssion or if this was done on purpose.

AMD Zen cpus have never shown fan speed data, which surprises me, I expected that to not show for the first year or so until it got reverse engineered, but kernel after kernel the fan speed data remained blank.

This is NOT a laptop vendors issue, it’s a kernel issue, which they cannot do anything to control. I also run Ryzen and have found it frustrating that despite the much vaunted AMD GPU open source driver, the actual sensors on the boards and cpus are still not released as far as I can tell.

Sensors failure to open not under NDA is mainly an ongoing long term issue with board vendors, not operating system or hardware assemblers, so you want to assign blame where it belongs. And credit, because the kernel sensors guys have been battling this sensor issue for about 20 years now, give or take. I am amazed they haven’t given up in frustration because it just doesn’t get better for most of the board vendors.

The Cause and the Solution
I finally found the cause of the vanishing Tdie, someone confused a regression with a fix, and removed Tdie when Tdie == Tctl, which is really a strange idea.

That recent hire, Mario Limonciello, also added k10temp support for other missing AMD Zen 2/3 CPU entries plus also fixed up the driver to no longer display Tdie temperatures if there is no difference from the Tctl temperature.

I just managed to squeeze this fix into the about to be released 3.3.20 inxi.

inxi -sC
CPU:
  Info: 6-core model: AMD Ryzen 5 2600 bits: 64 type: MT MCP cache: L2: 3 MiB
  Speed (MHz): avg: 3137 min/max: 1550/3400 cores: 1: 3627 2: 3723 3: 3522
    4: 2839 5: 3326 6: 3679 7: 2045 8: 3187 9: 2243 10: 2883 11: 3891 12: 2690
Sensors:
  System Temperatures: cpu: 52.5 C mobo: N/A gpu: radeon temp: 56.0 C
  Fan Speeds (RPM): N/A

This just went live a few minutes ago.

Glad I took another look, I had been unable to find any solution. I’m genuinely confused as to why someone would think removing a key name that is the officially designated amd zen cpu temperature key, where tctl is the synthetic key / value pair, was a good idea, or worse, a ‘fix’, but that’s how it goes sometimes.

3 Likes
5

I downloaded the new inxi version, but nothing changed… i have the same problems with the Tuxedo Control Center, i also have the same error messages in journal.

I disagree, the support told me that Ubuntu/Devian should work but they dont care much about Manjaro…

They not even Maintain/Provide a AUR Packages, but they told me they could support me to create my own AUR TCC Package… which normal costumer want this?

I would never recommend anyone Tuxedo Linux Hardware, the Manjaro Branded Hardware from Tuxedo is just expensive fake.

6

to be fair, the actual kernel 5.10 or newer do trouble a lot. maybe it’s worth a try to use kernel 5.4 or even 4.19. they are lts and still active.

7

Just to be clear, inxi doesn’t ‘fix’ your system, so nothing should change externally to inxi. The fix was making cpu temp show again given the new information about Tctl vs Tdie sensors.

In general, it’s not realistic to expect a rolling release distro with current kernels to be supported by any business, which is probably why Tuxedo supports Ubuntu/Debian. I used to do a lot of rolling release support work, and that’s not a viable thing to do long term at any level, it wasn’t viable for our project despite the significant success we saw, and it definitely is not viable for commercial entities.

There’s always costs as well as benefits to running rolling release GNU/Linux operating systems, that’s just how it is I also run a rolling release, Debian Testing, on most of my systems, and it’s definitely not as stable as a frozen pool release, though of course, totally fine if you know how to fix things now and then.

But it’s also worth noting that I have many times not updated to current kernels for months at a time due to certain things, drivers, features, etc, not working due to regressions and bugs, which is a good example of why you can’t actually support on an ongoing basis rolling release stuff if you have any hooks into core components that can and do change, that’s APIs, ABIs, and so on. That’s in particular relevant for kernels and desktops/desktop toolkits.

This doesn’t diminish the value of running rolling release distributions, it is just worth being aware that you can’t have your cake and eat it too, as the expression goes. I go with the occasional forced freezes, breaks, glitches, to have reasonably current desktops, but that’s because I am willing to fix the glitches when they happen. Businesses in general don’t have that luxury.

Making packages means you have to support them, and that means you have to devote developer manhours, which are expensive and certainly not free, to always making sure the package works. That’s just not a good use of resources as a rule, which is why it’s quite rare to see commercial enterprises supporting officially anything but stable releases like RHEL, SLED, Ubuntu LTS, Debian stable, and so on.

I don’t have any experience with Tuxedo, but from what you wrote, it sounds like they are really trying to help you, but aren’t willing to take economically non-viable steps, which makes sense for a business.

8

That’s your point of view, okay. But if your not able to deliver the product that you’re promoting than it’s a bitter lemon ! If you can’t deliver the work than don’t announce it !!!

9

Oh, that’s absolutely true. If they said they were going to support a rolling release distro, that was a mistake. My guess is they just didn’t have enough experience to realize that over time that is not a viable policy, and really intended to and wanted to do what they said, then reality sank in. That probably didn’t take very long is my guess. But definitely a mistake to claim to be able to do something that isn’t practical to do. I can kind of see it, some of them were Arch/Manjaro users, and really liked it, and didn’t realize the gap between liking something yourself as a user and having to actually support that commercially. That’s something you unfortunately only learn from experience.

From my own experience supporting significantly unstable Debian Sid/unstable (that’s more unstable than Arch/Manjaro rolling release by a significant margin since it is not intended for mainstream supported use, just bug catching and bleeding edge development), I saw over and over people claim Sid was stable and fine (since they didn’t have enough experience or time in it to be aware of when things break, they break, and you never know when that will happen), then you’d never hear from them after their systems failed. I put this down more to being naive than malicious or misleading.

Note that any time a kernel feature is required for support to work, in general the best policy is to run multiple kernels, always keeping a known good one as backup, then if a new one fails or breaks a feature you want, just remove it, and wait until that regression is fixed. I find that cycle is 3 to 6 months usually, give or take, except for non free drivers, then it can vary widely, and always ends in support being removed at some kernel or xorg level, in the case of nvidia non free. I always run at least 2 kernels, usually 3, so I can roll back if I suddenly realize something isn’t working as expected.

10

Thats why i am using only LTS Kernel and as far i know, no one forced Tuxedo to brand their laptops with a Manjaro logo on it, but at the end not giving the customer reliable support.

11

That was a mistake for sure. But I understand how they made that mistake, it really I think comes down to inexperience long term, it’s completely understandable. It is however also useful as the end user to be aware that certain things can’t actually be done in the real world, so even if someone claims they can do x or y, that doesn’t mean x or y can actually be done.

If I got for example a Frameworks or System76 laptop, I would not really care what they said about supporting anything, and just look at the hardware it came with, making sure it’s got free drivers available, then after that, I’d consider that I’m the maintainer of the operating system I install, not the hardware vendor. That’s why I only run Thinkpads, for example. Though Dell is doing good stuff, system76, the key to me is the hardware, not the operating system that may have come with the hardware, which I’m not going to use anyway, I’d always do a fresh install no matter what.

I think what matters most when it comes down to hardware, and in particular laptops, is if the vendor is making sure that they are contributing driver code directly to the kernel project, or using hardware already supported by the kernel natively. I believe Dell and Lenova are now both doing something like that on their supported laptops, which is a really good bit of progress.

But if the kernel has a regression, which happens all the time, just like improvements happen all the time, there’s zero the hardware vendor can do about that beyond contributing developer manhours to fixing the regression if they are in a position to do that.

12

For what it’s worth, I have never over some 15 years seen even the very well supported Thinkpad hardware always work on every new kernel released, I’ve always had to stop for a while to wait for some broken feature to be fixed, usually involving suspend/wake/hibernate. That’s not so much a question of long term support kernels as it is of a specific kernel working and a specific kernel or kernel series not working, any one of those could be a long term support kernel.

I usually run Liquorix/zen kernels by the way, unless they are broken in some way, so generally I’m not far from the bleeding edge, though I don’t install new kernels all the time, just every few months usually.

13

So at the end… there is no real solution and i better just uninstall this TCC. I regret buying Tuxedo Hardware. People better just buy Laptop’s without Linux Branded advertising (because its fake) and they can safe houndred’s of dollars when they buy a normal Laptop.

14

that’s the sad final ending. people paid a huge extra to get a all-in-one package and trusted that they get a running system because they are new to linux and finally are frustrated because the company doesn’t fullfill the expectations that they promoted. that is more than annoying,

1 Like
15

As someone who has a Tuxedo on order, I can’t help myself from weighing in. I am aware it would take the thread off topic, but if we keep it civilized the Gods of Manjaro may let it live.

Any business proposing to do things differently (breaking ground) will meet challenges. It is understandable that you are annoyed when your Manjaro-branded hardware doesn’t live up to all its promises. But, you have options, for instance live without TCC, go with Ubuntu or wait until TCC works again. The world does not come to an end.

Criticism need to be fair and balanced, and I think yours isn’t. A company of Tuxedo’s size will always have shortcomings that come at a cost of being strong in other areas.
Want an ultrabook with 2TB of storage? Tuxedo got you covered, and for a (very) reasonable price too. I guess most of the sales are within Europe and Tuxedo promises to supply any keyboard layout. That’s quite a commercial feat, given that EU alone has 24 official languages.

I can envisage that in a not too distant future, custom-ordered hardware will become the norm among the large vendors. They are waiting for smaller operators like Tuxedo to figure out how it’s done, only to either buy them out or put out of business. And until then Tuxedo will have to travel a rocky road.

I hope anyone seeing @Kobold and @Olli’s comments on here also takes time to read @h2-1’s good explanations of the core issue .

1 Like
16

Sorry for waking this thread.
The solution for me was to install the corresponding linux-headers package, so for me running Kernel 6.6 I run:

pacman -S linux66-headers

After a reboot Tuxedo Control Center shows me CPU -Temp and CPU - Fan

1 Like
17

Nah don’t be sorry, i let this Topic open if something changed or someone has a solution,
maybe your option helps someone, but for me as a LTS Kernel user, im not so sure.

Does this works with LTS 6.1 or other LTS Kernels?

It only shows you CPU clock and Fan speed? But the real questions is, can you control it now?

18

you must install dkms to generate the modules

19

I used 6.1 in the past with no issues, also worked OK on 6.5.
Kernel 6.6 is also a Longterm release: The Linux Kernel Archives - Releases
It shows the current profile selected and acts accordingly:

image
image918×396 22 KB

On the profile tab you can configure and select a profile:

image
image1001×657 55 KB

I updated from 6.5 to Kernel 6.6 recently, because 6.5 is marked EOL.
With 6.6 I have a problem when I use my external monitor connected to the ‘official’ Tuxedo vouched docking station: monitor cant be used after computer wakes from sleep: Tuxedo Pulse 15 Gen2 + USB-C dock - no network + external monitor won't wake after sleep

Tuxedo packages installed on my machine:

# pacman -Qs tuxedo
local/tuxedo-control-center 2.0.11-3
    A tool to help you control performance, energy, fan and comfort settings on TUXEDO laptops.
local/tuxedo-drivers-dkms 3.2.14-1
    TUXEDO Computers kernel module drivers for keyboard, keyboard backlight & general hardware I/O using the SysFS interface
local/tuxedo-keyboard-ite-dkms 0.4.4-3
    Per-key keyboard backlight driver for TUXEDO ITE devices.
local/tuxedo-touchpad-switch 1.0.7-1
    A Linux userspace driver to enable and disable the touchpads on TongFang/Uniwill laptops using a HID command
1 Like
20

And most importantly - the relevant kernel headers …

And I can say that my Tuxedo Infinitybook Pro 14 gen.8 is a marvel …

And you have of course read the relevant documention on tuxedo web?