Add Wayland-compatible AppStore runtime

[vicliu624]

Summary

• add a wrapper that selects Wayland/SDL or framebuffer runtime based on the current display environment
• add Wayland build output alongside the existing framebuffer runtime
• add Zero desktop metadata for Wayland task matching
• keep the framebuffer path available for the legacy launcher
• improve install/uninstall behavior in the Zero runtime without changing the AppStore UI contract

Validation

• deployed and exercised on pi@192.168.50.35
• verified the AppStore can run in the Zero labwc session without OS-specific window rules
• verified package install/uninstall flow shows the system authorization prompt and updates APPLaunch desktop entries

[dianjixz]

The current implementation has changed since this PR was opened. Please rebase this PR on the latest target branch and adapt the changes to the current implementation, while preserving the intended Wayland support and compatibility with the existing runtime paths. Thank you.

[vicliu624]

The current implementation has changed since this PR was opened. Please rebase this PR on the latest target branch and adapt the changes to the current implementation, while preserving the intended Wayland support and compatibility with the existing runtime paths. Thank you.

Thanks for the review. I’ve rebased this PR on the current target branch and reworked it to fit the current runtime structure.

The main idea is that fbdev/evdev is still the default and primary runtime path for CardputerZero. A normal CardputerZero=y build, as well as the existing upstream setup.ini deployment flow, stays unchanged: it still builds and deploys the original single M5CardputerZero-AppStore executable and uses the existing fbdev/evdev configuration. The standard deployment does not need a Wayland launcher, extra environment variables, or additional runtime files.

Wayland support is now an explicit optional dual-runtime setup, rather than something that replaces fbdev. When this optional package is assembled, it contains:

• M5CardputerZero-AppStore at the original path, acting as a small launcher;
• M5CardputerZero-AppStore-fbdev for the existing fbdev runtime;
• M5CardputerZero-AppStore-wayland for the optional Wayland runtime.

The launcher respects an explicitly set SDL_VIDEODRIVER first. If it is not set, it only chooses Wayland when WAYLAND_DISPLAY is available; otherwise it uses fbdev. So a normal CardputerZero environment continues to use the existing fbdev path, while a Wayland-capable environment can opt into the SDL/Wayland binary.

The launcher uses exec to start the selected native executable. Both runtime binaries remain in the same application directory, so the existing executable-relative resource and backend lookup logic continues to work as expected.

I also added checks for the launcher’s selection and fallback behavior, and confirmed that the default deployment manifest still only contains the original fbdev deployment.

One thing to note for transparency: I no longer have access to a CardputerZero device, as the one I had was returned, so I could not do final validation on the real hardware after this rebase. I did test the Wayland runtime and launcher-selection behavior on a Raspberry Pi running Wayland. The final hardware verification on CardputerZero will still need to be done by a maintainer or contributor with access to a device. Because of that, I kept the default fbdev deployment path aligned with the current upstream behavior and made Wayland strictly an optional, non-disruptive addition.