Hi,
On 10/5/26 05:09, Dmitry Baryshkov wrote:
Hi,
During your presentation at the XDC this year you mentoned that the
kernel needs to describe the attached panel to the userspace and that it
should also describe optical characteristics of the system.
Having played with the Google Cardboard and other kits implementing the
same idea, I'd have a controversial proposal as a reponse. What if let
the kernel describe only the actual panel(s) being used in the device
and let userspace describe the optics (in a way similar to libinput
determining and applying device-specific quirks in userspace).
As I wrote, this comes from the Carboard-like devices. Users can use
them to transform the phone into the poor man's xR headset. The kernel
knows nothing about the attached kit, so it won't be able to export any
information (only the phone's panel). Similarly, I think, using
prescription lenses with the actual xR headsets would affect optical
characteristics. Finally, devices like Snap Specs will have some, but
not all properties (e.g. there will be FoV, distance to the screen and
inter-display distance, but, I guess, nothing else).
Having all of that in mind, I think, the params of the device should go
to the userspace.
I mean, yes they are for userspace, kernel would have no use of those
properties (until there's some hardware able to do the rendering), but
we need a common way to share those properties.
You're using an edge use case (Google cardboard) which has barely nothing
to do with devices crafted for XR which has per-device calibration tables.
Some will come from DT, some would come from tables in filesystem, the idea
is to perhaps standardize a well-define blob format which could hold all
those parameters you could gather from the DRM interface. So any
system (DT, ACPI, ...) could define those in an unified way.
At the same time, if the kernel grows up support for the response
measures (e.g. performing CAC or waveguide demura), we would need to
describe necessary properties _to_ the kernel, which mean userspace
descibing optical characteristics to the kernel driver rather than the
other way around.
For CAC, the parameters would need to be set from user-space, no doubt on this.
Our questioning is how to handle the variety of ways to handle CAC in HW.
Neil
