[PATCH v1] Increase framebuffer size to todays standards

[PATCH v1] Increase framebuffer size to todays standards

[Olaf Hering]

My notebook reports a display size of 1920x1080:

(XEN) vesafb: framebuffer at 0xd0000000, mapped to 0xffff82c000201000, using 8128k, total 8128k
(XEN) vesafb: mode is 1920x1080x32, linelength=7680, font 8x16
(XEN) vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0

The hardcoded values feel arbitrary, so just bump them to fix my system.
The filters for notebooks at https://geizhals.eu/ indicate the upper
limit could be even larger, like 3840x2160.

Fixes commit e7cb35e8b1b8f872d906800c72f92f10d701f79c ("xen: introduce a generic framebuffer driver")

Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
 xen/drivers/video/lfb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/drivers/video/lfb.c b/xen/drivers/video/lfb.c
index d0c8c492b0..0d061293d4 100644
--- a/xen/drivers/video/lfb.c
+++ b/xen/drivers/video/lfb.c
@@ -10,7 +10,7 @@
 #include "lfb.h"
 #include "font.h"
 
-#define MAX_XRES 1900
+#define MAX_XRES 1920
 #define MAX_YRES 1200
 #define MAX_BPP 4
 #define MAX_FONT_W 8

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1] Increase framebuffer size to todays standards

[Jan Beulich]

>>> On 25.11.18 at 20:14, <olaf@aepfle.de> wrote:
> My notebook reports a display size of 1920x1080:
> 
> (XEN) vesafb: framebuffer at 0xd0000000, mapped to 0xffff82c000201000, using 8128k, total 8128k
> (XEN) vesafb: mode is 1920x1080x32, linelength=7680, font 8x16
> (XEN) vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> 
> The hardcoded values feel arbitrary, so just bump them to fix my system.
> The filters for notebooks at https://geizhals.eu/ indicate the upper
> limit could be even larger, like 3840x2160.

And I think a change like this should (a) address the more general
case rather than just your laptop (or laptops in general) and (b)
actually add some headroom. Hence at the very least I'd see us
go to 4096x3072. WHUXGA would even call for 7680x4800.

> Fixes commit e7cb35e8b1b8f872d906800c72f92f10d701f79c ("xen: introduce a 
> generic framebuffer driver")

I don't think this is appropriate here. Once further bumping turns
out necessary, would that then be a fix to your change here? A
proper "fix" would imo only be to get rid of the hard coded upper
bounds. Bumping the bounds every once in a while is an expected
action.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1] Increase framebuffer size to todays standards

[Olaf Hering]

[-- Attachment #1.1: Type: text/plain, Size: 564 bytes --]

Am Mon, 26 Nov 2018 03:31:27 -0700
schrieb "Jan Beulich" <JBeulich@suse.com>:

> And I think a change like this should (a) address the more general
> case rather than just your laptop (or laptops in general) and (b)
> actually add some headroom. Hence at the very least I'd see us
> go to 4096x3072. WHUXGA would even call for 7680x4800.

So should I resend this patch with higher values, or should I remove
the bounds check entirely? Not sure what it is trying to achieve, the
framebuffer may fail either way if the BIOS provides bogus values.

Olaf

[-- Attachment #1.2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1] Increase framebuffer size to todays standards

[Jan Beulich]

>>> On 26.11.18 at 17:03, <olaf@aepfle.de> wrote:
> Am Mon, 26 Nov 2018 03:31:27 -0700
> schrieb "Jan Beulich" <JBeulich@suse.com>:
> 
>> And I think a change like this should (a) address the more general
>> case rather than just your laptop (or laptops in general) and (b)
>> actually add some headroom. Hence at the very least I'd see us
>> go to 4096x3072. WHUXGA would even call for 7680x4800.
> 
> So should I resend this patch with higher values, or should I remove
> the bounds check entirely? Not sure what it is trying to achieve, the
> framebuffer may fail either way if the BIOS provides bogus values.

I have to forward this question: Stefano introduced all five MAX_*
values here when splitting out the LFB code in commit e7cb35e8b1
("xen: introduce a generic framebuffer driver"). I apparently didn't
even notice back then that three of them are entirely unused, and
the two dimension ones had no upper bound before.

Stefano: Why were all of these introduced (there's no explanation
in the description) and what were the values derived from? Will
anything break if we remove them?

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1] Increase framebuffer size to todays standards

[Julien Grall]

Hi Jan,

On 11/26/18 4:15 PM, Jan Beulich wrote:
>>>> On 26.11.18 at 17:03, <olaf@aepfle.de> wrote:
>> Am Mon, 26 Nov 2018 03:31:27 -0700
>> schrieb "Jan Beulich" <JBeulich@suse.com>:
>>
>>> And I think a change like this should (a) address the more general
>>> case rather than just your laptop (or laptops in general) and (b)
>>> actually add some headroom. Hence at the very least I'd see us
>>> go to 4096x3072. WHUXGA would even call for 7680x4800.
>>
>> So should I resend this patch with higher values, or should I remove
>> the bounds check entirely? Not sure what it is trying to achieve, the
>> framebuffer may fail either way if the BIOS provides bogus values.
> 
> I have to forward this question: Stefano introduced all five MAX_*
> values here when splitting out the LFB code in commit e7cb35e8b1
> ("xen: introduce a generic framebuffer driver"). I apparently didn't
> even notice back then that three of them are entirely unused, and
> the two dimension ones had no upper bound before.
> 
> Stefano: Why were all of these introduced (there's no explanation
> in the description) and what were the values derived from? Will
> anything break if we remove them?

FWIW, looking at the logs, this was introduced to cater arm framebuffer 
driver. However, we dropped the only driver a few months ago as it was 
not maintained. So x86 is the only user of that code today.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1] Increase framebuffer size to todays standards

[Jan Beulich]

>>> On 27.11.18 at 10:26, <julien.grall@arm.com> wrote:
> Hi Jan,
> 
> On 11/26/18 4:15 PM, Jan Beulich wrote:
>>>>> On 26.11.18 at 17:03, <olaf@aepfle.de> wrote:
>>> Am Mon, 26 Nov 2018 03:31:27 -0700
>>> schrieb "Jan Beulich" <JBeulich@suse.com>:
>>>
>>>> And I think a change like this should (a) address the more general
>>>> case rather than just your laptop (or laptops in general) and (b)
>>>> actually add some headroom. Hence at the very least I'd see us
>>>> go to 4096x3072. WHUXGA would even call for 7680x4800.
>>>
>>> So should I resend this patch with higher values, or should I remove
>>> the bounds check entirely? Not sure what it is trying to achieve, the
>>> framebuffer may fail either way if the BIOS provides bogus values.
>> 
>> I have to forward this question: Stefano introduced all five MAX_*
>> values here when splitting out the LFB code in commit e7cb35e8b1
>> ("xen: introduce a generic framebuffer driver"). I apparently didn't
>> even notice back then that three of them are entirely unused, and
>> the two dimension ones had no upper bound before.
>> 
>> Stefano: Why were all of these introduced (there's no explanation
>> in the description) and what were the values derived from? Will
>> anything break if we remove them?
> 
> FWIW, looking at the logs, this was introduced to cater arm framebuffer 
> driver. However, we dropped the only driver a few months ago as it was 
> not maintained. So x86 is the only user of that code today.

Interesting. I assume you mean arm_hdlcd.c. I've looked at its
4.11.0 version, and I'm afraid I still can't see a connection to
the questionable MAX_* values. Whatever we go with is going
to be a backport candidate (as obviously slightly older versions
of Xen would also better work properly with larger monitors),
and hence I'd still need to understand the correlation, perhaps
unless backporting the removal of that driver is also desired.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1] Increase framebuffer size to todays standards

[Julien Grall]

Hi Jan,

On 11/27/18 9:44 AM, Jan Beulich wrote:
>>>> On 27.11.18 at 10:26, <julien.grall@arm.com> wrote:
>> Hi Jan,
>>
>> On 11/26/18 4:15 PM, Jan Beulich wrote:
>>>>>> On 26.11.18 at 17:03, <olaf@aepfle.de> wrote:
>>>> Am Mon, 26 Nov 2018 03:31:27 -0700
>>>> schrieb "Jan Beulich" <JBeulich@suse.com>:
>>>>
>>>>> And I think a change like this should (a) address the more general
>>>>> case rather than just your laptop (or laptops in general) and (b)
>>>>> actually add some headroom. Hence at the very least I'd see us
>>>>> go to 4096x3072. WHUXGA would even call for 7680x4800.
>>>>
>>>> So should I resend this patch with higher values, or should I remove
>>>> the bounds check entirely? Not sure what it is trying to achieve, the
>>>> framebuffer may fail either way if the BIOS provides bogus values.
>>>
>>> I have to forward this question: Stefano introduced all five MAX_*
>>> values here when splitting out the LFB code in commit e7cb35e8b1
>>> ("xen: introduce a generic framebuffer driver"). I apparently didn't
>>> even notice back then that three of them are entirely unused, and
>>> the two dimension ones had no upper bound before.
>>>
>>> Stefano: Why were all of these introduced (there's no explanation
>>> in the description) and what were the values derived from? Will
>>> anything break if we remove them?
>>
>> FWIW, looking at the logs, this was introduced to cater arm framebuffer
>> driver. However, we dropped the only driver a few months ago as it was
>> not maintained. So x86 is the only user of that code today.
> 
> Interesting. I assume you mean arm_hdlcd.c. I've looked at its
> 4.11.0 version, and I'm afraid I still can't see a connection to
> the questionable MAX_* values. Whatever we go with is going
> to be a backport candidate (as obviously slightly older versions
> of Xen would also better work properly with larger monitors),
> and hence I'd still need to understand the correlation, perhaps
> unless backporting the removal of that driver is also desired.

I would be surprised if someone ever used the HDLCD driver after it was 
merged. I am not even sure if it even works.

Furthermore, this driver only targets development platform (i.g Juno) or 
the models were pretty much everyone tends to use serial console for Xen.

So I would not worry if you break the support when backporting. I am 
also happy to see it completely removed in old Xen version.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1] Increase framebuffer size to todays standards

[Jan Beulich]

>>> On 27.11.18 at 19:17, <julien.grall@arm.com> wrote:
> I would be surprised if someone ever used the HDLCD driver after it was 
> merged. I am not even sure if it even works.
> 
> Furthermore, this driver only targets development platform (i.g Juno) or 
> the models were pretty much everyone tends to use serial console for Xen.
> 
> So I would not worry if you break the support when backporting. I am 
> also happy to see it completely removed in old Xen version.

Thanks - I'll keep this in mind when backporting the eventual final
patch here. I'll probably remove the driver only in case the build
for it would fail with the change discussed here, which I don't
expect to be the case.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel