The TongFang GKxNRxx, GMxNGxx, GMxZGxx, and GMxRGxx / TUXEDO Stellaris/Polaris Gen 1-4, have the same problem as the Clevo NL5xRU and NL5xNU / TUXEDO Aura 15 Gen1 and Gen2: They have a working native and video interface for screen backlight. However the default detection mechanism first registers the video interface before unregistering it again and switching to the native interface during boot. This results in a dangling SBIOS request for backlight change for some reason, causing the backlight to switch to ~2% once per boot on the first power cord connect or disconnect event. Setting the native interface explicitly circumvents this buggy behaviour by avoiding the unregistering process.
The upstream commit "ACPI: video: Make backlight class device registration a separate step (v2)" changes the logic in a way that these quirks are not required anymore, but kernel <= 6.0 still need these.
Signed-off-by: Werner Sembach wse@tuxedocomputers.com --- drivers/acpi/video_detect.c | 64 +++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 3b972ca53689..e5518b88f710 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -463,6 +463,70 @@ static const struct dmi_system_id video_detect_dmi_table[] = { DMI_MATCH(DMI_BOARD_NAME, "PF5LUXG"), }, }, + /* + * More Tongfang devices with the same issue as the Clevo NL5xRU and + * NL5xNU/TUXEDO Aura 15 Gen1 and Gen2. See the description above. + */ + { + .callback = video_detect_force_native, + .ident = "TongFang GKxNRxx", + .matches = { + DMI_MATCH(DMI_BOARD_NAME, "GKxNRxx"), + }, + }, + { + .callback = video_detect_force_native, + .ident = "TongFang GKxNRxx", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"), + DMI_MATCH(DMI_BOARD_NAME, "POLARIS1501A1650TI"), + }, + }, + { + .callback = video_detect_force_native, + .ident = "TongFang GKxNRxx", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"), + DMI_MATCH(DMI_BOARD_NAME, "POLARIS1501A2060"), + }, + }, + { + .callback = video_detect_force_native, + .ident = "TongFang GKxNRxx", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"), + DMI_MATCH(DMI_BOARD_NAME, "POLARIS1701A1650TI"), + }, + }, + { + .callback = video_detect_force_native, + .ident = "TongFang GKxNRxx", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"), + DMI_MATCH(DMI_BOARD_NAME, "POLARIS1701A2060"), + }, + }, + { + .callback = video_detect_force_native, + .ident = "TongFang GMxNGxx", + .matches = { + DMI_MATCH(DMI_BOARD_NAME, "GMxNGxx"), + }, + }, + { + .callback = video_detect_force_native, + .ident = "TongFang GMxZGxx", + .matches = { + DMI_MATCH(DMI_BOARD_NAME, "GMxZGxx"), + }, + }, + { + .callback = video_detect_force_native, + .ident = "TongFang GMxRGxx", + .matches = { + DMI_MATCH(DMI_BOARD_NAME, "GMxRGxx"), + }, + }, /* * Desktops which falsely report a backlight and which our heuristics * for this do not catch.
Adding Hans de Goede to the CC
Thanks for offering to review this.
Am 19.10.22 um 17:30 schrieb Werner Sembach:
The TongFang GKxNRxx, GMxNGxx, GMxZGxx, and GMxRGxx / TUXEDO Stellaris/Polaris Gen 1-4, have the same problem as the Clevo NL5xRU and NL5xNU / TUXEDO Aura 15 Gen1 and Gen2: They have a working native and video interface for screen backlight. However the default detection mechanism first registers the video interface before unregistering it again and switching to the native interface during boot. This results in a dangling SBIOS request for backlight change for some reason, causing the backlight to switch to ~2% once per boot on the first power cord connect or disconnect event. Setting the native interface explicitly circumvents this buggy behaviour by avoiding the unregistering process.
The upstream commit "ACPI: video: Make backlight class device registration a separate step (v2)" changes the logic in a way that these quirks are not required anymore, but kernel <= 6.0 still need these.
Signed-off-by: Werner Sembachwse@tuxedocomputers.com
drivers/acpi/video_detect.c | 64 +++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 3b972ca53689..e5518b88f710 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -463,6 +463,70 @@ static const struct dmi_system_id video_detect_dmi_table[] = { DMI_MATCH(DMI_BOARD_NAME, "PF5LUXG"), }, },
- /*
* More Tongfang devices with the same issue as the Clevo NL5xRU and
* NL5xNU/TUXEDO Aura 15 Gen1 and Gen2. See the description above.
*/
- {
- .callback = video_detect_force_native,
- .ident = "TongFang GKxNRxx",
- .matches = {
DMI_MATCH(DMI_BOARD_NAME, "GKxNRxx"),
},
- },
- {
- .callback = video_detect_force_native,
- .ident = "TongFang GKxNRxx",
- .matches = {
DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
DMI_MATCH(DMI_BOARD_NAME, "POLARIS1501A1650TI"),
},
- },
- {
- .callback = video_detect_force_native,
- .ident = "TongFang GKxNRxx",
- .matches = {
DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
DMI_MATCH(DMI_BOARD_NAME, "POLARIS1501A2060"),
},
- },
- {
- .callback = video_detect_force_native,
- .ident = "TongFang GKxNRxx",
- .matches = {
DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
DMI_MATCH(DMI_BOARD_NAME, "POLARIS1701A1650TI"),
},
- },
- {
- .callback = video_detect_force_native,
- .ident = "TongFang GKxNRxx",
- .matches = {
DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
DMI_MATCH(DMI_BOARD_NAME, "POLARIS1701A2060"),
},
- },
- {
- .callback = video_detect_force_native,
- .ident = "TongFang GMxNGxx",
- .matches = {
DMI_MATCH(DMI_BOARD_NAME, "GMxNGxx"),
},
- },
- {
- .callback = video_detect_force_native,
- .ident = "TongFang GMxZGxx",
- .matches = {
DMI_MATCH(DMI_BOARD_NAME, "GMxZGxx"),
},
- },
- {
- .callback = video_detect_force_native,
- .ident = "TongFang GMxRGxx",
- .matches = {
DMI_MATCH(DMI_BOARD_NAME, "GMxRGxx"),
},
- }, /*
- Desktops which falsely report a backlight and which our heuristics
- for this do not catch.
On Wed, Oct 19, 2022 at 05:30:59PM +0200, Werner Sembach wrote:
The TongFang GKxNRxx, GMxNGxx, GMxZGxx, and GMxRGxx / TUXEDO Stellaris/Polaris Gen 1-4, have the same problem as the Clevo NL5xRU and NL5xNU / TUXEDO Aura 15 Gen1 and Gen2: They have a working native and video interface for screen backlight. However the default detection mechanism first registers the video interface before unregistering it again and switching to the native interface during boot. This results in a dangling SBIOS request for backlight change for some reason, causing the backlight to switch to ~2% once per boot on the first power cord connect or disconnect event. Setting the native interface explicitly circumvents this buggy behaviour by avoiding the unregistering process.
The upstream commit "ACPI: video: Make backlight class device registration a separate step (v2)" changes the logic in a way that these quirks are not required anymore, but kernel <= 6.0 still need these.
Please properly reference an upstream commit the way the documentation asks you to (you forgot the sha1 number), and also you need to really really really document why the upstream commit does not work here.
And you need to cc: all of the developers and maintainers on the original commit and get them to agree that this is the acceptable change to take, as it is not upstream and it needs their approval.
Please fix up and resend it letting everyone know what is happening here.
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org