On 2/29/24 12:33, Paweł Anikiel wrote:
> On Thu, Feb 29, 2024 at 9:02 AM Hans Verkuil wrote:
>>
>> On 28/02/2024 16:34, Paweł Anikiel wrote:
>>> On Wed, Feb 28, 2024 at 12:25 PM Hans Verkuil
>>> wrote:
Hi Paweł,
On 21/02/2024 17:02, Paweł Anikiel wrote:
> Currently, .quer
On Thu, Feb 29, 2024 at 9:02 AM Hans Verkuil wrote:
>
> On 28/02/2024 16:34, Paweł Anikiel wrote:
> > On Wed, Feb 28, 2024 at 12:25 PM Hans Verkuil
> > wrote:
> >>
> >> Hi Paweł,
> >>
> >> On 21/02/2024 17:02, Paweł Anikiel wrote:
> >>> Currently, .query_dv_timings() is defined as a video callba
On 28/02/2024 16:34, Paweł Anikiel wrote:
> On Wed, Feb 28, 2024 at 12:25 PM Hans Verkuil
> wrote:
>>
>> Hi Paweł,
>>
>> On 21/02/2024 17:02, Paweł Anikiel wrote:
>>> Currently, .query_dv_timings() is defined as a video callback without
>>> a pad argument. This is a problem if the subdevice can h
On Wed, Feb 28, 2024 at 12:25 PM Hans Verkuil wrote:
>
> Hi Paweł,
>
> On 21/02/2024 17:02, Paweł Anikiel wrote:
> > Currently, .query_dv_timings() is defined as a video callback without
> > a pad argument. This is a problem if the subdevice can have different
> > dv timings for each pad (e.g. a D
Hi Paweł,
On 21/02/2024 17:02, Paweł Anikiel wrote:
> Currently, .query_dv_timings() is defined as a video callback without
> a pad argument. This is a problem if the subdevice can have different
> dv timings for each pad (e.g. a DisplayPort receiver with multiple
> virtual channels).
>
> To solv
Currently, .query_dv_timings() is defined as a video callback without
a pad argument. This is a problem if the subdevice can have different
dv timings for each pad (e.g. a DisplayPort receiver with multiple
virtual channels).
To solve this, add a pad variant of this callback which includes
the pad
