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

From: "Jan Beulich" <JBeulich@suse.com>
To: Julien Grall <julien.grall@arm.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Cc: Olaf Hering <olaf@aepfle.de>, Wei Liu <wei.liu2@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v1] Increase framebuffer size to todays standards
Date: Tue, 27 Nov 2018 02:44:34 -0700	[thread overview]
Message-ID: <5BFD12020200007800200418@prv1-mh.provo.novell.com> (raw)
In-Reply-To: <ce1163a4-35fb-c0a2-4deb-97fa2f348692@arm.com>

>>> 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