Add display dimensions for proper scaling
Signed-off-by: Paul Sajna <sajattack@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>;
+ };
};
};
--
2.51.0
On 9/17/25 3:09 AM, Paul Sajna wrote:
> Add display dimensions for proper scaling
>
> Signed-off-by: Paul Sajna <sajattack@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
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 <sajattack@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
On 9/17/25 4:54 PM, Alexey Minnekhanov wrote:
> 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 <sajattack@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.
Would adding post-init-providers = <&real_panel> help?
Konrad
On 07.10.2025 16:55, Konrad Dybcio wrote: > Would adding post-init-providers = <&real_panel> help? > > Konrad I suppose it should, as means to break devlink dependency, but I personally haven't tried it yet. It's easier to just have "msm" and "panel-*" modules in initramfs and leave simpledrm node be with invalid scaling, because it doesn't live long enough to display anything (maybe a fraction of a second) due to being quickly replaced by msm drm framebuffer emulation. Framebuffer-only display with proper scaling is only needed for devices without display/panel drivers, perhaps temporarily during early porting stage, so this all is minor issue. Still would be nice to have a proper solution for this of course. -- Regards, Alexey Minnekhanov
© 2016 - 2026 Red Hat, Inc.