Linux: Visibility of RPi specific OS development plans for the community?

Looking back over the last few years, what would you identify as developments where the community would have benefited from advance notice?

As sure as night follows day, Linux version numbers increase. We try to get working versions of each release candidate as soon as possible, even though not all of them make it to production code. At the same time, albeit at a much slower pace, Debian is churning out their major releases, and we are likely to move to Buster at some point in the future.

Raspberry Pi's own software development is usually tied to hardware releases, and if you are expecting advance notice of those then you are going to be disappointed.

As Phil says, a lot of stuff is tied to hardware releases.

Almost all of the stuff Eric is reporting on is stuff that has been in progress for a while, but whilst he was here we had a chance to discuss and identify the missing bits to bring (fake) KMS closer to mainline.
He has very limited experience of codecs and cameras, but lots on 3D and KMS. I have very limited knowledge of V3D, some more on general composition, and lots on codecs and cameras. Combine the two and pass some of the knowledge around, and we get some progress :-)

Personally, I'd like to see more detailed changelogs (for example, they always say "new kernel, new firmware", but without any explanation of what has changed or has been fixed).

For the kernel and firmware for example it's very open here on Github, for the Raspbian Releases I don't see any of that, Raspbian Releases just seem to "pop-up out of nowwhere" ;)

@pelwell just off the top of my head, the VC SONAME renaming. It was even supposed to be announced in advance, but as far as I am aware that just never happened, and the first I learned of it was after all my builds broke in stretch. And yes I realise that has nothing to do with the kernel. :)

See: https://github.com/raspberrypi/firmware/issues/625#issuecomment-230356111

@pelwell @6by9 we'd benefit from advanced notification about RPI specials like VC, firmware, desktop.
New HW is explicitly out-of-scope.

An example is VC4 driver where Eric's blog post indicated a 'few loose ends' described as 'Someone needs to'.
Tying all required activities together via a milestone, could potentially attract contributors to pick them up and as result allow for merging the planned VC4 improvement 'not need gpu_mem= any more' a bit sooner.

Tying all required activities together via a milestone, could potentially attract contributors to pick them up and as result allow for merging the planned VC4 improvement 'not need gpu_mem= any more' a bit sooner.

Seeing as that is requiring significant works within the firmware, and accompanying work on a new version of vc-sm (hopefully with a small possibility of upstreaming), it's not something that can be shared around.

There are then major discussions required as to how we manage the migration from gpu_mem to cma. The new remote allocation via vc-sm is going to make the legacy firmware GLES stack unworkable as the round-trip latency to allocate memory is going to kill performance (video decode/camera do all allocations up front, so it is a relatively minor setup time increase). Switching between CMA and gpu_mem is therefore going to require some magic in the firmware looking at device tree nodes in the hope of working out which mode the user is running in, further complicated by the fact that the current device tree stuff is all done after gpu_mem is already allocated.
None of that can be shared out as it is in the firmware, so again it doesn't benefit from being set as a milestone.

There may be some benefit in laying out some more details of the proposed DispmanX shim for KMS, and possibly the writeback connector for transpose. The former of those is mainly up to RPT as we know DispmanX, but the main stumbling point is having to have a different solution between X11 and a console based system. The latter Eric has some ideas, so it would be up to him to flesh out.

Thanks @6by9.
I'm looking forward to see more about the plan for 'how to manage the migration from gpu_mem to cma' at some point in the future.

This isn't really a kernel issue, so closing. However, feel free to add comments to the end of the issue.