Thank you for reporting this. To help debugging this issue some more information is necessary.

Please boot into the working 6.9.12 kernel and then from a terminal run:

dmesg > dmesg-good.txt
ls /sys/class/backlight/ > backlight-good.txt

then boot into the non working 6.10.3 kernel and then from a terminal run:

dmesg > dmesg-bad.txt
ls /sys/class/backlight/ > backlight-bad.txt

and then attach all 4 generated .txt files here.

Created attachment 2043880 [details]
Logs

Created attachment 2043881 [details]
Logs2

Created attachment 2043882 [details]
Logs3

Created attachment 2043883 [details]
Logs4

When trying to adjust the display brightness the slider shows up, works and shows a change in brightness, however there is no effect on the display.

Thank you for the logs. I think I know what is going on, but this is quite weird.

Can you boot into the non working 6.10.3 kernel again and then do:

sudo rmmod dell_uart_backlight
sudo modprobe dell_uart_backlight dyndbg
sudo dmesg > dmesg-bad-dyndbg.txt

from a terminal and attach the newly generated dmesg-bad-dyndbg.txt file here ?

Also please run:

grep -r . /sys/class/dmi/id/* 2> /dev/null

from a terminal and copy + paste the output into a comment here.

I believe that you can workaround this problem by running:

sudo grubby --update-kernel=ALL --args="modprobe.blacklist=dell_uart_backlight"

which adds modprobe.blacklist=dell_uart_backlight to the kernel commandline causing the non working /sys/class/backlight/dell_uart_backlight to disappear, which should cause the issue to disappear. After the grubby command reboot into 6.10.3 again, then do "cat /proc/cmdline" to check that the modprobe.blacklist is now on the kernel commandline and then your brightness control should work again.

Needing to manually blacklist dell-uart-backlight is not really a proper fix though, so the purpose of the newly requested logs is to hopefully help find a proper fix.

The weird thing is that the dell_uart_driver should only load if there actually is a UART attached backlight controller board answering the commands it sends over the UART. So the question then becomes why does your Dell AOI have the separate (so extra hw for Dell to add) UART attached backlight controller board if it apparently is not using it ...

Created attachment 2043947 [details]
Log5

grep -r . /sys/class/dmi/id/* 2> /dev/null
/sys/class/dmi/id/bios_date:01/23/2024
/sys/class/dmi/id/bios_release:1.32
/sys/class/dmi/id/bios_vendor:Dell Inc.
/sys/class/dmi/id/bios_version:1.32.0
/sys/class/dmi/id/board_name:085F29
/sys/class/dmi/id/board_vendor:Dell Inc.
/sys/class/dmi/id/board_version:A02
/sys/class/dmi/id/chassis_type:13
/sys/class/dmi/id/chassis_vendor:Dell Inc.
/sys/class/dmi/id/modalias:dmi:bvnDellInc.:bvr1.32.0:bd01/23/2024:br1.32:svnDellInc.:pnOptiPlex7760AIO:pvr:rvnDellInc.:rn085F29:rvrA02:cvnDellInc.:ct13:cvr:sku084A:
/sys/class/dmi/id/power/runtime_active_time:0
/sys/class/dmi/id/power/runtime_status:unsupported
/sys/class/dmi/id/power/runtime_suspended_time:0
/sys/class/dmi/id/power/control:auto
/sys/class/dmi/id/product_family:OptiPlex
/sys/class/dmi/id/product_name:OptiPlex 7760 AIO
/sys/class/dmi/id/product_sku:084A
/sys/class/dmi/id/sys_vendor:Dell Inc.
/sys/class/dmi/id/uevent:MODALIAS=dmi:bvnDellInc.:bvr1.32.0:bd01/23/2024:br1.32:svnDellInc.:pnOptiPlex7760AIO:pvr:rvnDellInc.:rn085F29:rvrA02:cvnDellInc.:ct13:cvr:sku084A:

OK, the workaround brought indeed the solution and the brightness control is working again.
Thanks a lot for the quick help and if there's anything I can do to assist further, just let me know.
I'm quite new to Linux/Fedora but will stay and volunteer to help the community.

Thank you for your help with debugging this so far.

I have written a set of patches which fix this without needing to blacklist the dell-uart-driver:
https://lore.kernel.org/platform-driver-x86/20240814190159.15650-1-hdegoede@redhat.com/

I have started a test Fedora 40 6.10.4 kernel build with these patches added:
https://koji.fedoraproject.org/koji/taskinfo?taskID=121957267

This kernel is still building at the moment (should be done in a couple of hours), please give this kernel a try once it is done building and let us know if this resolves the brightness key-press issue.

Here are instructions for installing a kernel directly from koji (Fedora's buildsystem): https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

Note when testing that:

1. You need to disable secureboot for this unsigned test kernel

2. Please remove the workaround before testing by running:

sudo grubby --update-kernel=ALL --remove-args="modprobe.blacklist=dell_uart_backlight"

before booting into the test kernel and once booted into the test kernel please run "cat /proc/cmdline" and verify the modprobe.blacklist argument is not there.

3. You can re-apply the workaround after testing by running:

sudo grubby --update-kernel=ALL --args="modprobe.blacklist=dell_uart_backlight"

Note the test kernel is done building now.

I followed all the steps above and can now report that with the supplied test kernel the brightness control is working again (without the workaround).
Should I and how can I remove the test kernel again?

(In reply to theneq from comment #12)
> I followed all the steps above and can now report that with the supplied
> test kernel the brightness control is working again (without the workaround).

Great, thank you for testing.

> Should I and how can I remove the test kernel again?

dnf / gnome-software will automatically remove the test kernel when 3 newer kernels have been installed as updates, so there is nothing you need to do.

You should re-enable the workaround for now though, since once you get any kernel updates that will be necessary again. At least until the fixes which you have just tested land in an upstream 6.10.y release.