This document specifies the industrial HMI reference platform and the workflow used to validate, test, and demonstrate graphical applications built with the Rendering Engine.

System Identity

hostnamectl
cat /etc/os-release
uname -a
dpkg --print-architecture

Hostname: hmi-target
Operating system: Debian GNU/Linux 13.6 (trixie)
Kernel: Linux 6.12.95+deb13-amd64
Architecture: x86-64 / Debian amd64
Hardware vendor reported by firmware: AZW
Hardware model reported by firmware: MINI S
Commercial product: Beelink Mini S
Firmware version: MS2V001
Firmware date: 2025-04-08

Hardware Inventory – CPU

lscpu
grep -m1 'model name' /proc/cpuinfo
nproc

Processor Model: Intel Processor N150 Architecture: x86-64 Physical cores: 4 Logical processors: 4 Operating frequency: 700 MHz – 3.6 GHz Hardware virtualization: Intel VT-x Cache hierarchy: L1: 128 KiB data / 256 KiB instruction L2: 2 MiB L3: 6 MiB

Hardware Inventory – Memory

free -h
grep MemTotal /proc/meminfo
dmidecode -t memory

Installed memory: 16 GB DDR4 Form factor: SODIMM Configured speed: 3200 MT/s Installed memory modules: 1 × 16 GB DDR4 SO-DIMM Maximum supported memory: 32 GB Runtime memory after fresh boot: Used: ~500 MB Available: ~14 GB Swap partition: 16 GB

Hardware Inventory – Storage

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,MODEL

df -h

Installed storage: 512 GB SSD Boot mode: UEFI Partition layout: EFI System Partition: ~1 GB (FAT32) Root filesystem: ~460 GB (ext4) Partition table: GPT Swap: ~16 GB Fresh Debian installation occupies approximately 1.4 GB, leaving approximately 428 GB available for applications, assets and logs.

The platform intentionally uses a simple GPT partition layout without LVM or filesystem encryption to facilitate development and deployment.

Hardware Inventory – Graphics

lspci
lspci | grep -Ei 'vga|display|3d'
lsmod | grep i915

GPU: Integrated Intel Alder Lake-N graphics
PCI address: 00:02.0
Kernel driver: i915
Kernel graphics framework: DRM/KMS
Display output is functional before installation of Xorg, Wayland or Vulkan userspace components.

The minimal Debian installation already includes the kernel-side Intel graphics stack. Xorg, Mesa Vulkan, GLFW and Rendering Engine runtime components have not yet been installed.

Storage Controller

Controller: Intel Alder Lake-N SATA AHCI
Linux storage device: /dev/sda

Ethernet

Two Intel I226-V Ethernet controllers are present.

Hardware Inventory – Network Adapters

ip -br link

lspci -k | grep -A3 -Ei 'network|ethernet'

Wi-Fi: Intel Wi-Fi 6 AX101NGW
- Linux interface: wlo1
- Kernel driver: iwlwifi
- Status during commissioning: active
Ethernet:
- Two Intel I226-V controllers
- Linux interfaces: enp1s0, enp2s0
- Kernel driver: igc
- Status during commissioning: inactive, no cable connected

The minimal Debian installation includes kernel support for all detected network adapters. The iw userspace diagnostic utility is not installed in the baseline system.

Hardware Inventory – Input Devices

lsusb
cat /proc/bus/input/devices
dmesg | grep -i -E "usb|hid|ilitek"

USB Controllers

The Linux xHCI driver exposes four USB root hubs corresponding to the USB controllers integrated into the Intel platform.

Touchscreen

Vendor: 222A Product: 0001 Manufacturer: ILI Technology Corp. Device: Multi-Touch Screen

Detected by the USB subsystem (lsusb). Linux input subsystem creates two logical devices: ILITEK ILITEK-TP and ILITEK ILITEK-TP Mouse This indicates that the touchscreen is recognized as both a native multitouch device a mouse-compatible HID device allowing legacy software to receive mouse events while modern software can consume absolute touch events.

Bluetooth

Intel AX201 Bluetooth

Software Inventory

The complete software inventory of the reference platform was captured immediately after the initial installation of Debian GNU/Linux 13.6 and before installing any additional graphics libraries, development tools or Rendering Engine components.

The attached package list serves as the software baseline for future platform bring-up and deployment.

Attachment:

debian13-baseline-packages.txt

Runtime Services

systemctl --type=service --state=running

Running services after initial Debian installation

Service                     | Purpose
-------------------------------------------------------------
  cron.service              | Scheduled task execution
  dbus.service              | System message bus
  getty@tty1.service        | Local console login
  ssh.service               | Remote administration (OpenSSH)
  systemd-journald.service  | System logging
  systemd-logind.service    | User session management
  systemd-timesyncd.service | Time synchronization
  systemd-udevd.service     | Device discovery and management
  user@1000.service         | User session manager
  wpa_supplicant.service    | Wi-Fi connectivity

Summary

The baseline Debian installation starts only a small set of essential services required for:

system initialization and logging; local and remote user access; automatic hardware detection; wireless networking; scheduled task execution; clock synchronization.

No graphical display manager, desktop environment services, graphics middleware, or Rendering Engine components are active.

Boot Environment

efibootmgr
mount | grep boot
lsblk -f

Boot Configuration Firmware boot mode: UEFI Boot manager: GRUB EFI Default boot entry: Debian EFI executable: \EFI\debian\shimx64.efi Boot chain initiated through shimx64.efi, providing compatibility with UEFI Secure Boot.

Partition Layout

Partition | Filesystem | Purpose
/dev/sda1 | FAT32      | EFI System Partition
/dev/sda2 | ext4       | Root filesystem
/dev/sda3 | swap       | Swap space

Filesystem Mounts EFI System Partition mounted at /boot/efi Root filesystem mounted at /

Summary

The reference platform uses a standard UEFI boot configuration with a GPT partition table. The operating system is installed on a single ext4 root filesystem with a dedicated FAT32 EFI System Partition and a separate swap partition. This simple layout facilitates system maintenance, deployment and recovery.

Network Configuration

The HMI target is configured to obtain its IPv4 address via DHCP.

To provide a stable development environment while retaining DHCP flexibility, the home router contains a static DHCP reservation mapping the wireless MAC address to a fixed IP address.

Property	Value
Hostname	hmi-target
Interface	wlo1
MAC Address	98:FE:3E:08:D5:F9
Reserved IPv4	192.168.1.154
Gateway	192.168.1.1

This approach preserves automatic gateway/DNS configuration while ensuring a stable address for SSH access, deployment scripts and development tooling.

Minimal Xorg and Vulkan Runtime

The reference platform uses a deliberately minimal graphical userspace rather than a conventional desktop environment.

The kernel-side graphics stack is provided by the Linux i915 driver and DRM/KMS. The userspace graphics runtime is installed separately.

Installed Graphics Components

The following packages are installed explicitly:

apt install --no-install-recommends \
    xserver-xorg-core \
    xinit \
    x11-xserver-utils \
    mesa-vulkan-drivers \
    vulkan-tools

Their primary roles are:

Package	Purpose
`xserver-xorg-core`	X.Org display server
`xinit`	Minimal X session startup support
`x11-xserver-utils`	X server utilities including `xrandr` and `xset`
`mesa-vulkan-drivers`	Mesa userspace Vulkan drivers
`vulkan-tools`	Vulkan diagnostic and validation tools including `vulkaninfo` and `vkcube`

The installation uses --no-install-recommends to avoid pulling in a desktop environment, display manager, window manager, terminal emulator, or other desktop-oriented components that are not required by the HMI runtime.

Graphics Device Access

The Intel graphics device is exposed through DRM:

/dev/dri/card0

/dev/dri/renderD128

card0 exposes the primary DRM device used for display/KMS operations, while renderD128 provides a render node for userspace GPU workloads that do not require display-control privileges.

The HMI runtime user belongs to both the video and render groups:

video

render

This allows graphical applications to access the required DRM devices without running the applications as root.

Vulkan Validation

The installed Vulkan runtime was validated with:

vulkaninfo --summary

The physical GPU was successfully enumerated as:

deviceName = Intel(R) Graphics (ADL-N)
deviceType = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
driverName = Intel open-source Mesa driver
driverInfo = Mesa 25.0.7-2+deb13u1

Mesa also exposes the llvmpipe software Vulkan implementation. During the graphical validation, vkcube explicitly selected the physical Intel Alder Lake-N GPU for rendering.

This validation was performed before starting Xorg, confirming that Vulkan device discovery and the Mesa Intel Vulkan driver operate independently of the X display server.

Xorg Validation

For initial commissioning, Xorg was started remotely and attached explicitly to the physical virtual terminal:

Xorg :0 vt1 -keeptty

This command is a commissioning/validation procedure and is not intended to be the final HMI startup mechanism.

The Xorg log confirmed:

modeset(0): using drv /dev/dri/card0
modeset(0): glamor X acceleration enabled on Mesa Intel(R) Graphics (ADL-N)
modeset(0): glamor initialized
modeset(0): [DRI2] DRI driver: iris

No GNOME, KDE, display manager, or window manager was installed or required for this validation session.

Display Detection

The physical display configuration was inspected with:

DISPLAY=:0 xrandr --query

The GreenTouch display is detected as:

HDMI-1 connected primary

1920x1080 @ 60 Hz

Standalone Vulkan Rendering Test

Hardware-accelerated graphical rendering was validated with:

DISPLAY=:0 vkcube

vkcube reported:

Selected WSI platform: xcb

Selected GPU 0: Intel(R) Graphics (ADL-N), type: IntegratedGpu

The rotating Vulkan cube rendered successfully on the physical GreenTouch display.

This validates the graphics path from the Vulkan application through the Mesa Intel driver and Xorg to the physical Intel GPU and display.

Display Configuration

The GreenTouch display is connected through HDMI-1 and uses the native 1920 × 1080 mode at 60 Hz.

For the HMI reference platform, the physical display is mounted in portrait orientation. The Linux virtual console and Xorg display environment are configured independently.

Linux Virtual Console

Persistent framebuffer-console rotation is configured through the Linux kernel command line in /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="quiet fbcon=rotate:3"

After modifying the configuration:

update-grub

reboot

Xorg Portrait Configuration

Xorg portrait orientation is configured in:

/etc/X11/xorg.conf.d/10-monitor.conf

with:

Section "Monitor"
    Identifier "HDMI-1"
    Option "Rotate" "left"
EndSection
 
Section "ServerFlags"
    Option "BlankTime" "0"
    Option "StandbyTime" "0"
    Option "SuspendTime" "0"
    Option "OffTime" "0"
EndSection

The monitor configuration causes Xorg to expose the display as a logical 1080 × 1920 portrait display.

The ServerFlags configuration disables Xorg screen blanking and DPMS timeouts so that the HMI display remains active during operation.

System-level suspend configuration remains unchanged.

Application Deployment Workflow

The HMI reference platform uses a deliberately simple remote deployment workflow. Applications are built and packaged on the development machine, transferred to the target over SSH, and launched remotely for validation on the physical HMI display.

1. Build the Application

Build the application for the target architecture:

Operating system: Linux

Architecture: x86-64 / amd64

For performance-sensitive validation, use a Release build. Release Unix application binaries should be stripped.

2. Package Rendering Engine Applications

For applications based on the Rendering Engine, use the project packaging workflow where possible:

Project Packaging Guide

A packaged Rendering Engine application contains the executable, the Rendering Engine runtime library, configuration, content, and application manifest in a relocatable directory structure.

3. Copy the Application to the Transfer Directory

The Ubuntu development environment shares a transfer directory with the Windows host.

Example:

mkdir -p /media/sf_HMITransfer/Applications

cp -r <Path/To/ApplicationPackage> /media/sf_HMITransfer/Applications/

4. Transfer the Application to the HMI Target

From Windows PowerShell:

scp -r .\Applications\* alexander@hmi-target:~/Applications/

The transferred applications are stored under:

/home/alexander/Applications/

If the executable permission is lost during the Windows-mediated transfer, restore it on the target:

chmod +x ~/Applications/<Application>/Binaries/<Executable>

5. Execute a Linux Console Application

Console applications can write directly to the physical Linux virtual console.

Writing directly to /dev/tty1 may require elevated privileges. Example:

su -

/home/alexander/Applications/HelloHMI > /dev/tty1 2>&1

This allows the application output to be observed directly on the portrait HMI display without installing a desktop environment or terminal emulator.

6. Execute a Graphical Application

Start the minimal Xorg environment in the first SSH terminal:

Xorg :0 vt1 -keeptty

Then launch the graphical application from a second SSH terminal:

cd ~/Applications/<ApplicationPackage>

DISPLAY=:0 ./Binaries/<ApplicationExecutable>

Example:

cd ~/Applications/ActorDrawableAttach-v0.1.1-Linux

DISPLAY=:0 ./Binaries/ActorDrawableAttach

The application renders directly through the minimal Xorg/Vulkan environment on the physical HMI display.