6.12 will be LTS, so skip 6.11^^
edit,
‘Unable to set DRM atomic cap: Operation not supported’ does this meaning to kernel?
When 6.12 gets out of -rc then it will move to the -mainline kernel and stay there until RPi moves to it as their default kernel. As time goes by before then you will see that they will start paying more attention with the 6.12 kernel getting it prepared.
Exactly where are you seeing this. It could mean it may be looking for different modes available to use or might be some sort of issue. I will ask them if I can confirm it.
sorry, forgot that message came up, most time mess up with ffmpeg/mpv?
btw, forgot how to fix kernel, again & you taught me last time 
Extract the kernel package and copy the /boot and usr/lib/modules/ files over to your system in their respective directories.
Do the same for the raspberrypi-bootloader package with the /boot files.
ok, mess up.
download 0923-sway.img, but calamares did not bring up, again.
ps. checksum ok & flash twice.
Kernel 6.12-rc1 and the latest rpi(4/5)-eeprom, raspberrypi-bootloader packages pushed to unstable when the mirrors sync. 6.12 will most likely be RPi’s new default LTS kernel so give it a good testing as it matures.
1 Like
does 6.12-rc RT enabled?
No it is not. I go with what RPi has for a config as a base. Every time I have researched the RT kernel there appears to be a censuses that there is no advantage for a normal desktop user and some times it can be detrimental. It is only useful if the hardware/software supports it.
In the 5 years I have been with Manjaro I can remember only one person that uses the RT kernel. I maintain 6 rpi kernels each week and due to my health and medicine I have to take I can only focus about 3 or 4 hours at a time. By the time 6.12 makes it to RPi’s default kernel designation that would mean 12 kernels a week and I am not able to do that. One might be able to talk @linux-aarhus in maintaining the RT kernels if there is some dire need for it.
no one asked, because it isn’t exist in mainline.
you should just build 6.6 & 6.12, take a break.
1 Like
v6.11.1 is out.
And BIG thanks for all the releases @Darksky !!
1 Like
v6.11.1 pushed when the mirrors sync.
1 Like
Everything seems fine, thanks a lot.
I have a question regarding mkinitcpio, because I’ve noticed that we do have a microcode block and that ‘aarch64’ is not supported. When did it change ?
(1/5) Arming ConditionNeedsUpdate...
(2/5) Updating module dependencies...
(3/5) Updating linux initcpios...
==> Building image from preset: /etc/mkinitcpio.d/linux-rpi4-mainline.preset: 'default'
==> Using configuration file: '/etc/mkinitcpio.conf'
-> -k 6.11.1-1-MANJARO-RPI4 -c /etc/mkinitcpio.conf -g /boot/initramfs8
==> Starting build: '6.11.1-1-MANJARO-RPI4'
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [autodetect]
-> Running build hook: [microcode]
==> WARNING: architecture 'aarch64' not supported, skipping hook
-> Running build hook: [modconf]
-> Running build hook: [keyboard]
-> Running build hook: [keymap]
-> Running build hook: [consolefont]
==> WARNING: consolefont: no font found in configuration -> Running build hook: [block]
-> Running build hook: [filesystems]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: '/boot/initramfs8'
-> Early uncompressed CPIO image generation successful==> Initcpio image generation successful
(4/5) Updating icon theme caches...
(5/5) Updating the desktop file MIME type cache...
BTW, have you noticed that for v6.12-rc1 they added in the latest commit (dts: Add downstream wrapper bcm2712-ds.dtsi · raspberrypi/linux@aa960f9 · GitHub) this comment for RPI5 (I was not aware but you may be already):
dts: Add downstream wrapper bcm2712-ds.dtsi
The upstream bcm2712.dtsi is a skeleton, lacking many components. Add
bcm2712-ds.dtsi to contain the missing bits, along with any other
required modifications.
It looks like I removed that hook in my mkinitcpio.conf for some reason. It has been a while I guess and do not remember why I did it.
Some minimal support for the pi5 is just now hitting upstream with 6.12. From what I understand one can boot on a sdcard in a serial terminal only. Just guessing but I believe the commit is some type of compatibility thing bridging RPi’s code with upstream. I did not realize that they have added that commit and 7 others since I built the 6.12-rc1 kernels yesterday. I will rebuild the kernels shortly and push them. 
That’s why I told you so. I’ve take a look at it after reading that the minimal RPI5 support was add to the kernel https://www.phoronix.com/news/Linux-6.12-RPi5-More-X1-Laptops
I was a little bit curious about how the RPI team will handle that.
6.12.rc1-2 kernel packages pushed to unstable when the mirrors sync with 8 fixup commits added.
Added 10-03-24:
Just curious with the RT kernel I built it for the pi5 today. I really can not tell much difference with normal desktop workings. It may have a little more zip but at the same time the default governor is set to performance instead of scaling. So one needs to have proper cooling. My temp and fan speed here while running a web video:
Every 2.0s: cat /sys/devices/platform/cooling_fan/hwmon/hwmon2/fan1_input jellyfin: Thu Oct 3 10:46:57 2024
6266
[ray@jellyfin ~]$ cpu-temp-speed
[ 4 cores ] [ cpu ]
[ 2800MHz ] [ 60°C ]
I will try to test a little more and I will share the kernel.
Linux jellyfin 6.12.0-rc1-2-MANJARO-RPI5-RT #1 SMP PREEMPT_RT Thu Oct 3 10:02:49 CDT 2024 aarch64 GNU/Linux
I saw RPi added basic support for the pi-500 today.
1 Like
The latest commit brings some changes also but for everyone:
As of 6.12, cgroups v1 is considered legacy, and must be enabled with
CONFIG_CPUSETS_V1.
Is there any pressing reason to enable it?
Added:
Here is the pi5 RT kernel packages. Be advised installing them should go ok but when going back to one of the regular kernels you need to manually uninstall the RT packages before hand as the other kernels do not know to uninstall the RT packages yet.
I have run out of steam and need to take a break befor building the pi4 RT packages.
https://drive.google.com/file/d/1ES30rU-jQT1F-a9bBCllab-H1vvm-oFe/view?usp=sharing
I don’t think so. But just to inform you that it can be taken into consideration if needed.
and, what about Sched_Ext, what is this?
edit,
AUR had scx-scheds package, but why kernel no CONFIG_SCHED_CLASS_EXT=y config?
I could not readily find it in the config. Something else may have to be enabled to bring it out. Will have to research it when I have time. Building pi4 RT at the moment.