On 17.09.2025 16:59, Konrad Dybcio wrote:
On 9/17/25 3:09 AM, Paul Sajna wrote:
Add display dimensions for proper scaling
Signed-off-by: Paul Sajna <sajatt...@postmarketos.org>
---
arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
b/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
index
e84b45ed82fd13850ea7ec1f34ddac5b59fc1434..8c1692f86e6ceea7b718361965e78f95d39373bb
100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
@@ -23,6 +23,13 @@ framebuffer@9d400000 {
format = "a8r8g8b8";
lab-supply = <&lab>;
ibb-supply = <&ibb>;
+
+ panel = <&fb_panel>;
+
+ fb_panel: fb-panel {
+ width-mm = <65>;
+ height-mm = <140>;
It'd be nicer if you moved these properties to the actual panel
node (the DSI one) and referenced that one instead (I think that
should work)
Konrad
Hi!
First of all this code doesn't work well for upstream, because it causes
errors with dtbs checks like:
framebuffer@9d400000 (simple-framebuffer): 'fb-panel' does not match
any of the regexes: '^[a-zA-Z0-9-]+-supply$', '^pinctrl-[0-9]+$'
^^ The subnode is not allowed by bindings.
The whole reasoning for this little hack is that the upstream
recommended approach to solve the "unknown DPI" for framebuffer issue
is to put width-mm, height-mm into real panel node and and reference it
in simple-fb node - sonds very nice in theory, but also doesn't work
well in practice, and explanation why will take a bit longer, please
bear with me for a minute.
If we do as recommended, device tree structure will look like this:
framebuffer@9d400000 {
...
panel = <&display_panel>;
};
soc@0 {
....
mdss {
...
dsi0 {
...
display_panel: panel@0 {
reg = <0>;
compatible = "lg,sw49410";
...
width-mm = <65>;
height-mm = <140>;
};
...
Then, to my understanding, due to how fw-devlink works, the panel=<&..>
link from simplefb node to display_panel node creates a probe-time
dependency, so that the whole display stack probes first: MDSS, DSI
controller, maybe even Adreno GPU, *AND* panel all probe first, thus
making the mere existence of simple-framebuffer pointless.
Additionally, simple-framebuffer probes succesfully after that,
creating "second GPU" entry in as /dev/dri/card1 making it look like
system has 2 GPUS, which confuses almost every window manager in
userspace later. Normally, if simplefb probes first, it gets unloaded
and replaced by MDSS and does not cause any chaos. In the end the whole
situation looks even more silly than the fake panel subnode hack.
Therefore for upstream I'd recommend to just drop any fb-panel hacks and
to not use panel=<&...> with reference to real panel either.
It would all be much much easier if we could just specify width-mm/
height-mm directly in simplefb node, but DT maintainers rejected that idea.
---
Regards,
Alexey Minnekhanov
