Linux: Visibilitas rencana pengembangan OS spesifik RPi untuk komunitas?

Melihat ke belakang selama beberapa tahun terakhir, apa yang akan Anda identifikasi sebagai perkembangan di mana masyarakat akan mendapat manfaat dari pemberitahuan sebelumnya?

Sepasti malam mengikuti siang, jumlah versi Linux meningkat. Kami mencoba untuk mendapatkan versi yang berfungsi dari setiap kandidat rilis sesegera mungkin, meskipun tidak semuanya berhasil mencapai kode produksi. Pada saat yang sama, meskipun dengan kecepatan yang jauh lebih lambat, Debian mengeluarkan rilis utama mereka, dan kami kemungkinan akan pindah ke Buster di beberapa titik di masa depan.

Pengembangan perangkat lunak Raspberry Pi sendiri biasanya terkait dengan rilis perangkat keras, dan jika Anda mengharapkan pemberitahuan sebelumnya maka Anda akan kecewa.

Seperti yang dikatakan Phil, banyak hal terkait dengan rilis perangkat keras.

Hampir semua hal yang Eric laporkan adalah hal-hal yang telah berlangsung selama beberapa waktu, tetapi sementara dia di sini, kami memiliki kesempatan untuk mendiskusikan dan mengidentifikasi bagian-bagian yang hilang untuk membawa KMS (palsu) lebih dekat ke arus utama.
Dia memiliki pengalaman codec dan kamera yang sangat terbatas, tetapi banyak pada 3D dan KMS. Saya memiliki pengetahuan yang sangat terbatas tentang V3D, lebih banyak lagi tentang komposisi umum, dan banyak lagi tentang codec dan kamera. Gabungkan keduanya dan berikan beberapa pengetahuan, dan kami mendapatkan beberapa kemajuan :-)

Secara pribadi, saya ingin melihat log perubahan yang lebih detail (misalnya, mereka selalu mengatakan "kernel baru, firmware baru", tetapi tanpa penjelasan apa pun tentang apa yang telah diubah atau telah diperbaiki).

Untuk kernel dan firmware misalnya sangat terbuka di sini di Github, untuk Rilis Raspbian saya tidak melihat semua itu, Rilis Raspbian sepertinya "muncul entah dari mana" ;)

@pelwell tepat di atas kepala saya, penggantian nama VC SONAME. Itu bahkan seharusnya diumumkan sebelumnya, tetapi sejauh yang saya ketahui itu tidak pernah terjadi, dan yang pertama saya pelajari adalah setelah semua bangunan saya rusak. Dan ya saya menyadari itu tidak ada hubungannya dengan kernel. :)

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

@pelwell @6by9 kami akan mendapat manfaat dari pemberitahuan lanjutan tentang spesial RPI seperti VC, firmware, desktop.
HW baru secara eksplisit di luar cakupan.

Contohnya adalah driver VC4 di mana posting blog Eric menunjukkan 'beberapa ujung yang longgar' yang digambarkan sebagai 'Seseorang perlu'.
Mengikat semua aktivitas yang diperlukan bersama-sama melalui tonggak sejarah, berpotensi menarik kontributor untuk mengambilnya dan sebagai hasilnya memungkinkan untuk menggabungkan peningkatan VC4 yang direncanakan ' tidak perlu gpu_mem= lagi ' sedikit lebih cepat.

Mengikat semua aktivitas yang diperlukan bersama-sama melalui tonggak sejarah, berpotensi menarik kontributor untuk mengambilnya dan sebagai hasilnya memungkinkan untuk menggabungkan peningkatan VC4 yang direncanakan 'tidak perlu gpu_mem= lagi' sedikit lebih cepat.

Mengingat hal itu membutuhkan pekerjaan yang signifikan di dalam firmware, dan pekerjaan yang menyertainya pada versi baru vc-sm (semoga dengan kemungkinan kecil untuk upstreaming), itu bukan sesuatu yang bisa dibagikan.

Kemudian ada diskusi besar yang diperlukan tentang bagaimana kami mengelola migrasi dari gpu_mem ke cma. Alokasi jarak jauh baru melalui vc-sm akan membuat firmware lama GLES stack tidak dapat dijalankan karena latensi bolak-balik untuk mengalokasikan memori akan mematikan kinerja (dekode video/kamera melakukan semua alokasi di depan, jadi ini adalah pengaturan yang relatif kecil peningkatan waktu). Beralih antara CMA dan gpu_mem oleh karena itu akan membutuhkan keajaiban dalam firmware yang melihat node pohon perangkat dengan harapan dapat mengetahui mode mana yang dijalankan pengguna, semakin diperumit oleh fakta bahwa hal-hal pohon perangkat saat ini semua dilakukan setelah gpu_mem sudah dialokasikan.
Tak satu pun dari itu dapat dibagikan seperti yang ada di firmware, jadi sekali lagi tidak ada gunanya ditetapkan sebagai tonggak sejarah.

Mungkin ada beberapa manfaat dalam meletakkan beberapa rincian lebih lanjut dari shim DispmanX yang diusulkan untuk KMS, dan mungkin konektor writeback untuk transpose. Yang pertama sebagian besar hingga RPT seperti yang kita ketahui DispmanX, tetapi titik batu sandungan utama adalah harus memiliki solusi yang berbeda antara X11 dan sistem berbasis konsol. Eric yang terakhir memiliki beberapa ide, jadi terserah dia untuk menyempurnakannya.

Terima kasih @6by9.
Saya menantikan untuk melihat lebih banyak tentang rencana 'bagaimana mengelola migrasi dari gpu_mem ke cma' di beberapa titik di masa mendatang.

Ini sebenarnya bukan masalah kernel, jadi tutup. Namun, jangan ragu untuk menambahkan komentar di akhir masalah.