Has seamless handoff been tested on the bring your own kernel patch list, or is it only verified on the L4T 5.15 kernel? The question could be extended to other users as well. Has anyone else tried this and if so, did it work or fail?
My specific usecase involves working with LTS kernel forks, of which I am currently working with 6.6 and 6.12, with more focus on the latter. I have working display if I disable seamless handoff. I’ve tried a few cases with seamless enabled.
Loading simplefb before tegra-dce and nvidia-drm: I see a handful of mmu faults and the display goes ‘out of range’.
Don’t load simplefb, then load tegra-dce and nvidia-drm: I see endless cbb faults and the display turns off.
I also note that openrm requires num_registered_fb to be exported from the main kernel to facilitate handoff, and this is no longer exported as of kernel 6.1. I’ve reverted that back in for my builds, and conftest does detect this correctly. If I don’t, the cbb faults happen as in the second bullet.
I have one question here. Are you talking about that you don’t even have any display able to run even after you follow our instructions to add patch to upstream kernel?
No, like I said in the first post: “I have working display if I disable seamless handoff.” So, if I build uefi with the default seamless option of ‘never’, display works as expected. The problem only occurs when trying to enable seamless display.
I am building uefi tag uefi-202412.0 with a few shallow modifications. Like reverting t194 support back in, changing the boot logo, disabling some on-screen prints, and modifying partition names in AndroidBootDxe. There’s no changes to the display code.
Ok. So if you didn’t modify anything in UEFI and just let it use the default one provided by BSP, then your display would never work. Is my understanding correct?
I believe that would be correct, yes. However, I cannot easily verify that as my partition layout does not match what’s supported by the BSP prebuilt uefi.
With seamless enabled, and kernel configured how I had previously, including num_registered_fb support restored. This is with CONFIG_FB=m as the defconfig I base off disables fb and vt. This shows the boot logo, then the monitor reports ‘out of range’. dmesg_with_fb_module.txt (67.3 KB)
With seamless enabled and CONFIG_FB=y and efifb enabled. Also boots to the monitor reporting ‘out of range’. dmesg_with_efifb.txt (67.2 KB)
With seamless enabled, CONFIG_FB=y, CONFIG_VT=y, and fbcon enabled. This shows the boot logo, then earlycon on screen, then back to the monitor reporting ‘out of range’. dmesg_with_fbcon.txt (67.3 KB)
I have done some further work on the kernel build setup I’m using. And now I no longer see mmu faults. I was trying to grab a log with those included, but am no longer able to do so. But the display is still not working.
Something else I note: if I mount debugfs and look at the dri debug info, I see in /sys/kernel/debug/dri/13800000.display/state that plane-0’s pitch is 7680. However, simplefb is given a linelength of 8192. This is a pretty standard 1920x1080 monitor. 1920x(32/8) is 7680, so I would expect that to be correct. However, uefi passes 8192 to L4T on 5.15 and L4T makes it work properly. So I don’t know why it’s failing here.
This thread does answer the question of ‘does it work on bring your own kernel’, though. And the answer is apparently ‘yes’, at least as of 6.8. So… am I missing another kernel module or defconfig entry? Or is this a problem with the driver being built with clang? I’m already having to disable cfi because openrm has c++ code, which breaks cfi. I will have to experiment further. Maybe look at the conftest output and see if anything else suspicious isn’t being detected.
Actually what I don’t understand is other users seems able to make display work by revert patch to make num_registered_fb back. But that seems not happened to you.
It is indeed that default setting of k6.8 won’t work with seamless display. I’ve confirmed with internal team. But not sure why other users’ workaround not able to work on your side.
See the right side of the selected entree. You can’t see it on a still image, but those lines are moving like scanlines on an old crt. Very possibly an out of range issue, but this display is willing to at least try. Whereas my other display is better at detecting broken modes and refusing to damage itself. To reiterate, this does not happen with seamless disabled, the display does not have the broken scanlines in that case.
This makes me wonder if other the user(s) on kernel 6.8 have a correct image or if the mode is slightly broken like here.
