Appreciate the feedback. For 12th and 13th gen, this is what we have that works. Now, this may change in the future. At this time for this generation of Intel, this is the workaround we have available.
What we have presented is an actionable workaround for Intel 12th and 13th gen boards.
Since this on course to devolve into something non-constructive, I would ask that we wrap this up here. Thank you
Due to new details in a ticket, I will be replicating this tomorrow with the following, to see if something new has taken place.
Ubuntu 22.4.3 which installing the OEM C kernel via the guide should have users on 6.1.0-1019-oem.
Fedora 38 with the latest updates and kernels.
If something has changed, and the needed tweaks are required after confirming duplication.
Thank you
Closing the loop on this. @Loell_Framework and myself have confirmed this is absolutely working on 12th gen and we have not been able to replicate the cold boot experience where it does not. Personally did 3 separate clean installs and updated it to test this.
sudo grubby --update-kernel=ALL --args="module_blacklist=hid_sensor_hub"
Reboot
This is on a single OS installed nvme drive, Fedora 38.
This leads me to believe something else is at play for those affected by this on Fedora 38, latest updates installed.
Not taking away from anyone’s experiences - I understand this happened to some folks. But we need to be able to replicate this and folks, even internally, this method remains working.
For the record, I have exactly the same issue as devkev reports. His solution of binding to i2c_hid_api is the only solution, only blacklisting the ALS by blacklisting hid_sensor_hub is not enough.
I’ve provided support with video proof, I’ve reinstalled many times upon support request, swapped out SSDs, memory, flash drives and distro’s (not only on Fedora, also Ubuntu) and have been consistently been reproducing the issue. Only this command works:
echo i2c-FRMW0001:00 | sudo tee /sys/bus/i2c/drivers/i2c_hid_acpi/bind
I understand that on your system and theirs. However, something must be different - which is what we’re trying to determine. 
This is a matter of us being completely unable to duplicate this failure.
We have not, at all, but able to get the boot parameter not to work.
For some reason, something, somewhere is different - we need to identify what that is.
We also use this internally for our software devs (they use this parameter on Ubuntu for their laptops).
Now, for you all, you have a workaround that is working and that’s solid.
However, it is critical that folks who happen upon this thread do not believe that this is a hard requirement - it is not unless we can spot what you two have different than what we have on our own systems, and those systems used by our own software team.
We vet and retest to keep our workflows current and as of yesterday, we have found that the grub parameter stands on the 12th gen mainboards tested.
Now, obviously this is an issue…but it’s maddening that we don’t see it here. At all, whatsoever. 
I’d love to get to the bottom of this.
Those affected, can you let me know
what is connected to your Framework when you tried sudo grubby --update-kernel=ALL --args="module_blacklist=hid_sensor_hub" and then reboot.
Which BIOS release you’re using?
Which distribution and kernel you’re using?
Confirm this affecting your 12th gen board?
While connected to AC power (if so, which charger?)
Some of this will sound absurd, however, we cannot seem to replicate this issue on our end whatsoever - it just works for us - Fedora 38 and Ubuntu 22.04.3.
Appreciate this folks. I will test again, one more time today myself. My tests are detached from everything except AC power.
My next test will be with current release of 22.04.3 - although this also worked when tested on 22.04.2 as well. This will be with current linux-oem-22.04c which is currently 6.1.0.1019.19
Stay tuned, updating shortly.
Re-test one:
Framework 13, 12th gen i5-1240
BIOS 3.04
Ubuntu 22.04.3
Kernel 6.1.0-1019-oem
No external anything attached, just AC power to USB-C.
Only these parameters used: quiet splash module_blacklist=hid_sensor_hub
/etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash module_blacklist=hid_sensor_hub"
sudo update-grub
Reboot
Brightness keys worked in this test.
Will repeat the process on Fedora 38, using grubby later this afternoon.
Next re-test will be on 3.06 BIOS, 12th gen i7-1280p
Hey Matt, the issue does not trigger on reboot. It needs a full power off and a fresh power on.
Appreciate this, my 3.04 BIOS machine is off (Ubuntu). Going to power on and test.
Powering on cold with Ubuntu. Tested, keys worked. Hmmm This is tough. Tested on battery and attached to power.
Spoke to @DHowett and they brought up an interesting point. What if for some reason, it’s not propagated to the ramdisk. This would be why none of us could duplicate it.
I’m setting up the 3.06 machine now.
Since it flip flops, the way to 100% reproduce it in my case is:
Then on the 2nd one, it 100% triggers for me. It’s tedious I’m sorry.
Edited my thoughts above, DHowett has a possible reason why it’s happening and this would also address why it’s not reproducible on our end. It may be unloading on your configuration where it is not having this issue on ours. Which is why we cannot seem to replicate it successfully.
No, you’re fine - my OCD is screaming right now because it’s not a thing on my machine, Loell’s machines or anyone else at work. lol
What does your grub parameters look like? Wondering if something is “pushing off” the blacklisting from boot.
Looking back through devkev’s notes for some additional clues.
May a moot point. Most folks can use the parameters fine (looking at past tickets, etc).
But there may be something triggered where it’s not working for some folks.
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.4.11-200.fc38.x86_64 root=UUID=476d5716-fa96-44a4-82f4-9d92994ff54d ro rootflags=subvol=root rd.luks.uuid=luks-234b5ccd-8326-4baa-951d-f128a8f473f1 rhgb quiet nvme.noacpi=1 module_blacklist=hid_sensor_hub
This is unlikely though, because devkev and I can verify that the module is not loaded, even in situations where the issue triggers.
Yeah, that looks fine to me.
That is so odd. Okay, well this is going to have to have a pin put into it. Grub for most, devkev’s approach for anyone experiencing this.
Going to pin this and mark as a potential workaround guide in case anyone else is seeing this. Man, I just want repro this one time. Would help me to have something to dig into. But this is solid workaround in case it crops up again in later BIOS releases.
Thanks everyone for letting me sort through this. It was rough, but I’ve determined:
Should the standard GRUB_CMDLINE_LINUX_DEFAULT="quiet splash module_blacklist=hid_sensor_hub" fail for anyone, please use kevdev’s method linked below.
In multiple tests, we were not able to reproduce cold boot, warm boot, Fedora and Ubuntu. But if find that you’re not able to get the brightness keys working, the method below has been confirmed to help.
Big props to @devkev for the solution that is working for them and will help others if it fails to operate correctly.
You can also enable it temporally by running sudo rmmod hid_sensor_trigger hid_sensor_iio_common hid_sensor_als hid-sensor-hub to unload the module and dependends.
Do any of the solutions here apply for the 11th gen?
I just updated bios (Fedora 38) from 3.03 to 3.17 and the function keys to control screen brightness are not doing anything, but they were working before the update. I also could not find anything in settings for screen brightness. All other function keys are working.
Did not see the file /etc/modprobe.d/framework-als-blacklist.conf.
If your have a standard, untouched grub configuration on 11th Gen, it’s not needed. You have no other odd blacklisting or tweaks made? Does this also happen on a live usb of 38?
No blacklisting. Some minor tweaks that I always do when reinstalling OS. Fn keys were workinf with live usb.
I got it working again after a reinstall of OS. Thanks for the help