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

[Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>]

Hi, Paul!

On 7/2/20 11:42 AM, Jürgen Groß wrote:
> 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@xxxxxxxx>
>>>>>>
>>>>>> 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@xxxxxxxx>
>>>>>
>>>>> Reviewed-by: Juergen Gross <jgross@xxxxxxxx>
>>>>
>>>> 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.
>
Is it possible that we have this change in the release please?

This is not used by any piece of code in Xen, so it won't hurt anything.

But I need this change in so I can proceed with the Linux kernel part:

we would like to upstream the relevant EDID change to the display

frontend driver and without the header in Xen tree we are stuck

Thank you in advance,

Oleksandr

>
> Juergen