Page Comparison

Attendee

原木、黒川、日下部、田口、駒形、山口、谷川、丸山、光成、Damian(敬称略)

...

• DRM lease 資料（multi-container-drm-lease-v3.pptx）
  • Q. Displayの名前にエイリアスはつけれる? （Page14）
    
    • 既存のアプリケーションの実装を変えたくないので、設定依存のことはしないほうがいい
    • Host側のマネージャでDisplayを分配する。
    • Containerの役割としては、マネージャから渡されたファイルに書かれていることをスキャンしてDisplay nameなどを取得できるようにしたい。コンテナのWesonなどはDRMをスキャンしないようにしてほしい
  • udevの問題もなくせる?
    • 表示に関わる課題はなくなるはず。 
    • Inputのやり取りに関する課題は残る。これはHostにinput managerのようなものがないといけない
  • CESデモでは、remotingのためにvirtual displayを扱っていた。Lease Managerは仮想デバイスも扱うか?
    
    • DRM Lease managerが扱うのは物理デバイスのみ。仮想デバイスはContainer側
    • Westonでしか動かないシステムにはしたくない
      • Westonはいろんなパッケージに依存している。QM汚染になってしまう。
    • SoCに依存せずに、DRMのリソースの引き渡しなどができるとありがたい。
      • マルチカードなどの技術はSoCに依存してしまう。
  • ホストにDBUSをもつことは致し方ないかもしれない。
    • よく使われている仕組み
    • DBUSをホストに使うことについては、QMと関わりがないから、コード検証しない、という選択をすることができる。
  • libdrmはコンテナに置かないといけない?
    • Yes
  • lease managerはlibdrmを使う?
    • lease managerが使う(実装依存)
    • そんなにコード量は多くない
  • コンテナが落ちたときに、Lease Managerは画面状態をキープできるか?コンテナが落ちても保持してほしい。
    • できなくはない。
      • 基本的には画面は消えるが、実装によって保持機能を付ける
      • CESではホストのwestonがキープしてくれていた。
    • 落ちてもブラックアウトしないことがRequirementにある。
    • 復活するときには、クライアント側が工夫しないといけないこともある。
    • 固まってはダメなものもある。カメラ映像が最たる例
      • カメラ映像は別経路にするべき
      • クラスタ
        • 固まっていいものとないもの(Telltaleなど?)があると思うがどうか
        • 分別しないといけない。
      • コンテナを早く起動しなおすことが肝要
      • 本当にまずいものはコンテナではなく、ホストに置くことも考えないといけない
        • それでも満たせない場合は、カーネルレベルで解決など。それは商品のRequirementによる
      • DRMで実現できないことは別の手段を考えたほうがいい
    • AGL側は使えるユースケースやスペックの提示が必要
      • Requirementをまとめる
        • Requirementを分析し、どういう品質レベルが必要か精査し、マッピングしたい
        • メータ側の人たちでまとめる
        • ちなみにRear Viewは同じIVIのSoCにいるだけでシステムは別
        • ガイド線は、だれが書くか、という問題はあるが。
    • 違うQMのコンテナの内容を一つのディスプレイに表示したいときはどうすればよいか。
      
      • コンポジット機能が外にないといけない
      • 一番厳しい要件に引っ張られる。Requirementによって適切な実装を選択する必要がある。
      • 提供できる選択肢を増やす方がいい。 = Product Ready
  • スケジュールについては、11月のCESをターゲットにしてほしい。マージは不要。
    • Kernelのバージョンの問題もある。現状は4.14を使っているので、バックポートをしている
    • Kernelのバージョンアップは間に合わない

Clusterアーキ

前回からのアップデート

　実装モデル

　コンテナ

　service部：共通部、OEM固有部

　IFとAPIを使い分けて書きた方がいい。

　なにを使って実装するのか？フレームワークを提供する？

　AGLはbinderを提供している

　アーキテクチャの中でAPIという表現は構わない

    AbstractionLayerでcommon IF

    Dbusでも

　表示のフローとデータ生成のフローは分けて記載したほうがよい

　出力系はいろんなソリューションがあるよ、これ使えそう、または無いから作らないといけない

　→メータfunction軸と要素軸で分けて、なにを共通化するのか

OSSだとライセンスの課題もあるので、変にプロセスを分ける分けないを規定しないほうが良い。買い入れを採用するケースもある。

AMMの発表スライドのときはタイトルを細かく変えること

実装はサプライヤ次第。

Safetyとの間はCAN以外にあるのか？

①コマンド転送/②映像転送(H.264など)/③ダイレクトレンダリングを使えば、IVIが描画した内容をメータに重畳可能。

①は製品固有、③はBSP依存、②はオープンソースソリューションもある。

AGLとしてはどのソリューションでもできるように提供することが重要。

①と③がAGLでは現状、実装持ってない。

チャレンジするなら③。チップ依存が大きいのが課題。実装レベルでの議論をしないと意味がないレベル。

ボタン系の入力をどう制御する？InputManager

→OEMとしては入力を制御するECUを同じものにしたい

キーイベントを待っているアプリに対してInputManagerがメッセージを

振り分ける必要がある。

→UI仕様に依存する部分が大きい。かっちりは決められない？？

Tier1としても毎回作り直している部分。

ダメだった事例ならたくさん出せる。

システム側で固めすぎると、変なUIが出てきてしまうのもこまる。

Test spec

テストコードのイメージは？

→C0C1カバレッジを想定できるようなもの

対象は、アーキ上のClusterServiceの部分。

→リンクするライブラリが課題。

案としては、使っていいライブラリを用意もしくは限定して、一緒にコントリビュートする、など。

目的は均一なテストを実施できるようにすること。ライブラリの組み合わせでばらついたり、動かないなどは避けたい。

※全てのライブラリに対してMISRA-C運用やテスト適用は不可能。

テストプログラムの配布方法どうする？テスト実行環境も。

　→リファレンスバーチャル環境みたいなものも必要かも。

異常系のテストケースは項目を抽出することが難しい。

LTS

先週のSCでLTSの話が出た。

UserLandに対するLTS。

Pokyのトラブルとして、昔あったフォルダがまるっと消えているケースなど。

MetadebianはLTSが現状無い。

昔のスナップショットが消えている課題あり。

MetadebianのモチベーションがLTSに無い。

お試し環境はコンフルエンスにある。

　URL: 

Redhatのほうがプロダクト観点でも良い。パッチレベルの指定可能、トレースしやすい。課題はベースがないこと。

Redhat8のメンテフェーズが27年まで。23年24年のLO製品はちょうどいいタイミング。

=== Appendix 2020/1/22～23の議事 ====

...

...

...