One thing I’d recommend to focus on before we even consider what hardware or UI/UX we’re targeting for a potential future Haiku port to mobile hardware, is that we surface an API, likely somewhere in AppServer or serving AppKit/InterfaceKit/DeviceKit, which informs apps that a mobile form factor is present.
A simple boolean, enum or struct even, would specify to applications whether they’re running on a desktop, phone, or under other systemwide UI/UX considerations such as text terminal, game-pad, remote keypad, or (accessibility++ !) directional switch control.
Haiku would have that information set by a series of qualifications, from sources such as:
- software: a user/system configuration override
- firmware: DMI, ACPI, UEFI or device tree information directly specifies a handheld, tablet or phone form factor
- hardware capabilities: display size/density/rotation, touch capability (single? multiple? resistive/stylus?)
- hardware presence or absence: cellular radio with telephony? front and rear cameras? no keyboard, no mouse?
- and platform considerations: mobile CPU, GPU? MIPI-DSI display connectivity? LPDDR? eMMC?
Items on that list would be weighted from bottom to top by importance, I’d imagine - since it’s possible for mobile platform hardware to be used in a laptop, or a device with telephony radio/modem or 5" primary display to be a desktop PC; trust more in the firmware’s chassis type registration - and if that’s absent, a configuration override would have final say in the matter.
I don’t anticipate any compatibility issues with existing BeOS or Haiku applications; these are additional data in the API not already present, and this feature does not make or permit any ABI-breaking changes.
Unless I’m missing something, I do notice that Haiku doesn’t seem to be cognizant of SMBIOS DMI structures beyond what is strictly necessary for device discovery and PC platform bringup.
Information about the device ‘chassis’, specific model, devices and other data which can be used for hardware enablement (even outside of the theoretical mobile ports) is largely ignored; whereas in Linux, it is used rather graciously to help set up the kernel to better support target platforms, including informing its render manager, DRM, to rotate the framebuffer.
That capability, both to rotate the display, and to sense whether to do so by default (specifically not IMU auto-rotation), will be crucial in the near future - not just on mobile platforms, but also on portrait desktop monitors, laptops (some have vertically-oriented, sideways-installed displays!), convertible tablets, and other PC-based devices (GPD Win series and Steam Deck comes to mind).