Re: [PATCH v2] xen/displif: Protocol version 2

["Jürgen Groß" <jgross@suse.com>]

On 02.07.20 09:59, Oleksandr Andrushchenko wrote:
> 
> On 7/2/20 10:20 AM, Jürgen Groß wrote:
>> On 01.07.20 14:07, Oleksandr Andrushchenko wrote:
>>> On 7/1/20 1:46 PM, Jürgen Groß wrote:
>>>> On 01.07.20 09:19, Oleksandr Andrushchenko wrote:
>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>
>>>>> 1. Add protocol version as an integer
>>>>>
>>>>> Version string, which is in fact an integer, is hard to handle in the
>>>>> code that supports different protocol versions. To simplify that
>>>>> also add the version as an integer.
>>>>>
>>>>> 2. Pass buffer offset with XENDISPL_OP_DBUF_CREATE
>>>>>
>>>>> There are cases when display data buffer is created with non-zero
>>>>> offset to the data start. Handle such cases and provide that offset
>>>>> while creating a display buffer.
>>>>>
>>>>> 3. Add XENDISPL_OP_GET_EDID command
>>>>>
>>>>> Add an optional request for reading Extended Display Identification
>>>>> Data (EDID) structure which allows better configuration of the
>>>>> display connectors over the configuration set in XenStore.
>>>>> With this change connectors may have multiple resolutions defined
>>>>> with respect to detailed timing definitions and additional properties
>>>>> normally provided by displays.
>>>>>
>>>>> If this request is not supported by the backend then visible area
>>>>> is defined by the relevant XenStore's "resolution" property.
>>>>>
>>>>> If backend provides extended display identification data (EDID) with
>>>>> XENDISPL_OP_GET_EDID request then EDID values must take precedence
>>>>> over the resolutions defined in XenStore.
>>>>>
>>>>> 4. Bump protocol version to 2.
>>>>>
>>>>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>
>>>> Reviewed-by: Juergen Gross <jgross@suse.com>
>>>
>>> Thank you, do you want me to prepare the same for the kernel so
>>>
>>> you have it at hand when the time comes?
>>
>> It should be added to the kernel only when really needed (i.e. a user of
>> the new functionality is showing up).
> 
> We have a patch for that which adds EDID to the existing PV DRM frontend,
> 
> so while upstreaming those changes I will also include changes to the protocol
> 
> in the kernel series: for that we need the header in Xen tree first, right?

Yes.


Juergen