The current solution checks for the existing RB mode,
if available in the edid block returns by adding it,
but does not populate the connector with the modes
of same resolution but which are non-rb modes.
As a result the probing and listing of non-rb modes can't
be made, in case the rb mode's pixe
The current solution checks for the existing RB mode,
if available in the edid block returns by adding it,
but does not populate the connector with the modes
of same resolution but which are non-rb modes.
As a result the probing and listing of non-rb modes can't
be made, in case the rb mode's pixe
The current solution checks for the existing RB mode,
if available in the edid block returns by adding it,
but does not populate the connector with the modes
of same resolution but which are non-rb modes.
As a result the probing and listing of non-rb modes can't
be made, in case the rb mode's pixe
Hi,
On Sat, Nov 16, 2013 at 12:29 AM, Adam Jackson wrote:
> On Fri, 2013-11-15 at 10:38 +0530, Shirish S wrote:
>> The current solution checks for the existing RB mode,
>> if available in the edid block returns by adding it,
>> but does not populate the connector with the modes
>> of same resolut
On Fri, 2013-11-15 at 10:38 +0530, Shirish S wrote:
> The current solution checks for the existing RB mode,
> if available in the edid block returns by adding it,
> but does not populate the connector with the modes
> of same resolution but which are non-rb modes.
>
> As a result the probing and l
The current solution checks for the existing RB mode,
if available in the edid block returns by adding it,
but does not populate the connector with the modes
of same resolution but which are non-rb modes.
As a result the probing and listing of non-rb modes can't
be made, in case the rb mode's pixe
