On Fri, Aug 17, 2012 at 3:01 AM, Jani Nikula
wrote:
> On Thu, 16 Aug 2012, Jerome Glisse wrote:
>> On Thu, Aug 16, 2012 at 11:13 AM, Jani Nikula
>> wrote:
>>>
>>> There's a bug [1] where the faster GMBUS transmissions fail with some
>>> CRTs, and the fix [2] is to fallback to GPIO bit-banging
On Thu, 16 Aug 2012, Jerome Glisse wrote:
> On Thu, Aug 16, 2012 at 11:13 AM, Jani Nikula
> wrote:
>>
>> There's a bug [1] where the faster GMBUS transmissions fail with some
>> CRTs, and the fix [2] is to fallback to GPIO bit-banging upon errors. As
>> noted in the bug, the fix still leaves
On Thu, 16 Aug 2012, Jerome Glisse j.gli...@gmail.com wrote:
On Thu, Aug 16, 2012 at 11:13 AM, Jani Nikula
jani.nik...@linux.intel.com wrote:
There's a bug [1] where the faster GMBUS transmissions fail with some
CRTs, and the fix [2] is to fallback to GPIO bit-banging upon errors. As
noted
On Fri, Aug 17, 2012 at 3:01 AM, Jani Nikula
jani.nik...@linux.intel.com wrote:
On Thu, 16 Aug 2012, Jerome Glisse j.gli...@gmail.com wrote:
On Thu, Aug 16, 2012 at 11:13 AM, Jani Nikula
jani.nik...@linux.intel.com wrote:
There's a bug [1] where the faster GMBUS transmissions fail with some
There's a bug [1] where the faster GMBUS transmissions fail with some
CRTs, and the fix [2] is to fallback to GPIO bit-banging upon errors. As
noted in the bug, the fix still leaves plenty of EDID dumps in dmesg, so
some measures to reduce the EDID error messages would be most welcome.
[1]
On Thu, Aug 16, 2012 at 11:13 AM, Jani Nikula
wrote:
>
> There's a bug [1] where the faster GMBUS transmissions fail with some
> CRTs, and the fix [2] is to fallback to GPIO bit-banging upon errors. As
> noted in the bug, the fix still leaves plenty of EDID dumps in dmesg, so
> some measures to
On Thu, Aug 16, 2012 at 11:13 AM, Jani Nikula
jani.nik...@linux.intel.com wrote:
There's a bug [1] where the faster GMBUS transmissions fail with some
CRTs, and the fix [2] is to fallback to GPIO bit-banging upon errors. As
noted in the bug, the fix still leaves plenty of EDID dumps in dmesg,
On Tue, Aug 14, 2012 at 10:54 AM, Adam Jackson wrote:
> On 8/9/12 11:25 AM, j.glisse at gmail.com wrote:
>>
>> From: Jerome Glisse
>>
>> Limit printing bad edid information at one time per connector.
>> Connector that are connected to a bad monitor/kvm will likely
>> stay connected to the same
On 8/9/12 11:25 AM, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> Limit printing bad edid information at one time per connector.
> Connector that are connected to a bad monitor/kvm will likely
> stay connected to the same bad monitor/kvm and it makes no
> sense to keep printing the bad
On 8/9/12 11:25 AM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
Limit printing bad edid information at one time per connector.
Connector that are connected to a bad monitor/kvm will likely
stay connected to the same bad monitor/kvm and it makes no
sense to keep printing the
On Tue, Aug 14, 2012 at 10:54 AM, Adam Jackson a...@redhat.com wrote:
On 8/9/12 11:25 AM, j.gli...@gmail.com wrote:
From: Jerome Glisse jgli...@redhat.com
Limit printing bad edid information at one time per connector.
Connector that are connected to a bad monitor/kvm will likely
stay
From: Jerome Glisse
Limit printing bad edid information at one time per connector.
Connector that are connected to a bad monitor/kvm will likely
stay connected to the same bad monitor/kvm and it makes no
sense to keep printing the bad edid message.
Signed-off-by: Jerome
From: Jerome Glisse jgli...@redhat.com
Limit printing bad edid information at one time per connector.
Connector that are connected to a bad monitor/kvm will likely
stay connected to the same bad monitor/kvm and it makes no
sense to keep printing the bad edid message.
Signed-off-by: Jerome Glisse
13 matches
Mail list logo