企业官网建设流程全解析

原理总结：

kanzi运行在lxc容器上，weston通过wayland协议把kanzi的图像显示到屏幕上。

分层拆解：

┌─────────────────────────────────────────────────┐
│ LXC 容器（Guest） │
│ │
│ Kanzi Engine │
│ ├─ 3D/2D 渲染（OpenGL ES） │
│ ├─ UI 逻辑、动画、状态机 │
│ └─ 渲染结果 → DMA-BUF / 共享内存缓冲区 │
│ │
│ Wayland Client (libwayland-client) │
└──────────────┬──────────────────────────────────┘
│ Wayland 协议（跨容器 socket）
│ /run/user/0/wayland-0 或
│ /var/run/wayland-0
┌──────────────▼──────────────────────────────────┐
│ 宿主机（Host） │
│ │
│ Weston（Wayland Compositor） │
│ ├─ 接收客户端缓冲区 │
│ ├─ 合成（叠加、缩放、图层管理） │
│ ├─ 调用 DRM/KMS 或 GPU 显示驱动 │
│ └─ 输出到物理屏幕 │
│ │
│ DRM/KMS → Display │
└─────────────────────────────────────────────────┘

每一层在干什么：

1. LXC 容器里的 Kanzi

• Kanzi 是应用层 UI 引擎，跑在容器里
• 它不知道自己在一个容器里，它以为自己在正常 Linux 上
• Kanzi 做渲染，产出的是一帧帧图像数据（GPU 渲染到缓冲区）

但容器里没有物理显示设备（DRM 节点通常不暴露给容器），所以 Kanzi 自己没法直接把画面送到屏幕。

2. Wayland 协议 = 跨容器的"显示快递"

Wayland 本质是一个C/S 协议，通过 Unix Domain Socket 通信：

Kanzi（客户端） Weston（服务端）
│ │
│ wl_surface.commit() │
│ ─── 缓冲区句柄（DMA-BUF fd）──→ │
│ │ 合成到屏幕
│ ←── 帧回调（frame done）─────── │

关键点：

• 传递的不是像素拷贝，而是缓冲区句柄（DMA-BUF fd、共享内存 fd）
• 通过 Unix socket 跨容器传递 fd，内核自动处理跨 namespace 的 fd 映射
• 所以图像数据零拷贝从容器传到宿主机

3. Weston 在宿主机上合成

• Weston 持有真正的显示硬件访问权（DRM/KMS）
• 它从 Kanzi 那里拿到缓冲区句柄
• 把 Kanzi 的画面和其他来源（摄像头、状态栏、其他容器）合成
• 最终通过 DRM/KMS 送到屏幕

================================================

背景：

1、Kanzi（由 Rightware/中科创达）是汽车领域非常主流的3D HMI（人机交互界面）引擎，广泛用于仪表盘、中控、抬头显示。

2、两者的关系：应用与底层显示协议

• Kanzi 是“画师”：负责高性能的 3D/2D 图形渲染（UI 内容）。

• Wayland/Weston 是“画布与窗口管理员”：Kanzi 渲染出的画面，需要跑在底层的图形系统上。在现代化的车载 Linux/Android 座舱中，Kanzi 通常作为Wayland 客户端，将其渲染结果提交给 Weston（合成器），由 Weston 最终显示到屏幕上。

• 简单说：Kanzi 做内容，Wayland 管显示。

不同平台的图像显示协议和使用场景比对：

举例：如果把kanzi显示到你电脑屏幕，可能使用的就是x11；显示到按个车机屏幕就用wayland。

查看板端具体采用哪种图像协议(板端的graphics backend)：

1）先在板子执行 ldd 你的应用程序 | grep wayland

如果输出：说明有在使用wayland

2）板子执行如下：说明这个板子支持wayland，并且已经开启协议功能

================================================

这三个问题一个比一个抽象，我从你刚才那个 Kanzi + Weston 的实际场景出发来讲，比教科书定义好懂。

GPU 是什么

GPU（Graphics Processing Unit）= 专门用来画图/算并行任务的硬件芯片。

你车机里大概率有两块"大脑"：

Kanzi 为什么需要 GPU？

Kanzi 画的是 3D 仪表盘、转场动画、光影效果——每个像素的颜色都要算。一个 1920×720 的屏幕有 138 万像素，每秒 60 帧，就是每秒 8300 万次像素计算。CPU 算这个会直接卡死，GPU 专门干这个，轻松搞定。

GPU 渲染完的结果存在显存（或系统内存的 DMA-BUF 区域），然后通过 Wayland 协议把这块内存的"引用"交给 Weston 去显示。

GPU 是什么

GPU（Graphics Processing Unit）= 专门用来画图/算并行任务的硬件芯片。

LXC 容器是什么？

LXC（Linux Containers）= 在 Linux 内核上实现的轻量级"虚拟机"，但比虚拟机轻得多。

虚拟机（VM）：
硬件 → 虚拟机管理程序(Hypervisor) → 跑完整操作系统 → 你的应用
（每个 VM 有自己完整的内核，启动要几十秒，占几 GB 内存）

LXC 容器：
Linux 内核 → 容器 A（只有文件系统+进程隔离）→ Kanzi
→ 容器 B（只有文件系统+进程隔离）→ 其他服务
（共享同一个内核，启动毫秒级，内存开销几十 MB）

容器本质上就是：

• 用 Linux 内核的namespace​ 功能让进程"以为"自己在一个独立系统里（看不到其他进程、有自己的网络、自己的文件系统视图）
• 用cgroup​ 功能限制它能用多少 CPU、多少内存
• 但内核是共享的——所有容器跑在同一个 Linux 内核上

为什么需要容器

TBOX / 座舱场景，为什么要把 Kanzi 塞进容器里：

没有容器：Kanzi 崩溃 → 整个系统崩 → 屏幕黑了 → 司机看不到车速 → 危险
有容器： Kanzi 崩溃 → 容器里的进程死了 → 宿主机 Weston 还在 → 可以重启容器

三者配合 = 安全、独立、高性能的车载 UI 架构：

宿主机 Linux 内核
├─ 管理 GPU 硬件（DRM 驱动）
├─ 运行 Weston（合成器，有 DRM 访问权）
│
└─ LXC 容器（Kanzi 住在里面）
├─ 自己的文件系统（只有 Kanzi 需要的库）
├─ 自己的进程空间（看不到宿主机其他进程）
├─ 通过 wayland socket（跨容器 Unix socket）把渲染结果传给 Weston
└─ 通过 GPU 设备节点（/dev/dri/renderD128）做硬件加速渲染

常见使用场景：

adb -H ip shell -t "lxc-attach -n lv --clear-env"