The first link does not mention blacklisting, just resolving a license compatibility issue.

"The patches check for the gxtp7380, ite_8291, ite_8291_lb, ite_8297, ite_829x, stk8321, tuxedo_compatibility_check, tuxedo_io, tuxedo_nb02_nvidia_power_ctrl, tuxedo_nb04_keyboard, tuxedo_nb04_wmi_ab, tuxedo_nb04_wmi_bs, tuxedo_nb04_sensors, tuxedo_nb04_power_profiles, tuxedo_nb04_kbd_backlight, tuxedo_nb05_keyboard, tuxedo_nb05_kbd_backlight, tuxedo_nb05_power_profiles, tuxedo_nb05_ec, tuxedo_nb05_sensors, tuxedo_nb05_fan_control, tuxi_acpi, tuxedo_tuxi_fan_control, clevo_wmi, tuxedo_keyboard, clevo_acpi, and uniwill_wmi kernel modules and will taint if they are present."

That's not what I would describe as "resolving a license compatibility issue"

▲

matheusmoreira 5 days ago | parent | next [-]

> ite_829x

Huh, so Tuxedo developed their own ITE 829x kernel driver.

I have a Clevo based laptop, similar to the ones they sell. Years ago I reverse engineered the keyboard's features and wrote a user space driver.

https://github.com/matheusmoreira/ite-829x

I interacted with Tuxedo quite a few times back then while I was figuring this stuff out. They even sent me source code for a pre-release version of their Electron app. It didn't help much in the end but they proved to be much nicer and more responsive than other manufacturers and even Clevo itself.

Wish they'd emailed me about their driver. I could have helped develop it, especially if they had given me documentation.

I briefly explored the idea of turning it into a kernel module and contributing it to the kernel. While reading Linux driver source code, some comments gave me the impression they'd prefer code remained in user space if possible. Since I already had a working user space driver, I decided not to contribute it.

I wrote the above program because Clevo's app was Windows only and so aggravating to use it defies description. Looks like Tuxedo ran into the same problem with their Electron app, if the complaints in this thread are any indication... Déjà vu.

▲

rhaps0dy 5 days ago | parent | prev | next [-]

I would describe it as exactly "resolving a license compatibility issue". Taint in linux kernel refers to marking this kernel as not supported, which often just means not purely GPLv2 compatible anymore. Proprietary AMD and nVidia drivers also cause taints. https://unix.stackexchange.com/a/118117/251582

	▲	deaddodo 5 days ago \| parent [-]
		Yeah, the person you're responding to is taking "taint" to mean a literal ban situation; versus the very real status that exists in Linux Kernel development. "TAINTing" a driver/code doesn't mean it's blacklisted, it means it can't be upstreamed into the GPL codebase. It means that if you build a Kernel with it, it's no longer considered OSS-friendly. There are plenty of legitimate and viable codebases that use TAINTed kernels. The DoD, various government entities around the world, some commercial interests, etc.

▲

rcxdude 4 days ago | parent | prev [-]

It is, specifically because Tuxedo licensed their modules as GPLv3, instead of GPLv2 (the module license declaration only has 'GPL', to make this confusing), causing a mild license compatibility issue, and since they've had external contributions, it's not so easy for them to fix it. And it's not a ban, just a flag that gets set.