Dear Alex,
see
http://lists.freedesktop.org/archives/dri-devel/2011-November/016934.html for a
proposal.
I went back to the DVI detect function in radeon_connectors.c. The
reason for this is that during initial configuration of the framebuffer,
where we would like to put the log message output,
Dear Alex,
see
http://lists.freedesktop.org/archives/dri-devel/2011-November/016934.html for a
proposal.
I went back to the DVI detect function in radeon_connectors.c. The
reason for this is that during initial configuration of the framebuffer,
where we would like to put the log message output,
Dear Alex,
sounds reasonable: it really should be sufficient to have the EDID dumps
of to be removed function radeon_ddc_dump() if at all as debug
information during fb initialisation.
Let's see if there will be a nice solution.
Best regards
Thomas
Am Dienstag, den 01.11.2011, 10:01 -0400 sch
Dear Alex,
I think we've got the point. The users with improperly terminated i2c
busses suffered a long time from flooded logs and terminals. We solved
the problem by introducing the extended DDC probe check, which will be
according to your other patch the default for all implementations. We
reduc
On Tue, Nov 1, 2011 at 7:23 AM, Thomas Reim wrote:
> Dear Alex,
>
> I think we've got the point. The users with improperly terminated i2c
> busses suffered a long time from flooded logs and terminals. We solved
> the problem by introducing the extended DDC probe check, which will be
> according to
Dear Alex,
sounds reasonable: it really should be sufficient to have the EDID dumps
of to be removed function radeon_ddc_dump() if at all as debug
information during fb initialisation.
Let's see if there will be a nice solution.
Best regards
Thomas
Am Dienstag, den 01.11.2011, 10:01 -0400 sch
On Tue, Nov 1, 2011 at 7:23 AM, Thomas Reim wrote:
> Dear Alex,
>
> I think we've got the point. The users with improperly terminated i2c
> busses suffered a long time from flooded logs and terminals. We solved
> the problem by introducing the extended DDC probe check, which will be
> according to
Dear Alex,
I think we've got the point. The users with improperly terminated i2c
busses suffered a long time from flooded logs and terminals. We solved
the problem by introducing the extended DDC probe check, which will be
according to your other patch the default for all implementations. We
reduc
Dear Alex,
your reply confuses me:
> On Sat, Oct 29, 2011 at 8:55 AM, Thomas Reim wrote:
> > Dear Alex,
> >
> > but we use DDC probing e. g. to identify connectors with improperly
> > terminated i2c bus. Instead of flooding logs and terminals with EDID dumps,
> > we decided some months ago to u
On Mon, Oct 31, 2011 at 11:15 AM, Thomas Reim wrote:
> Dear Alex,
>
> your reply confuses me:
>
>> On Sat, Oct 29, 2011 at 8:55 AM, Thomas Reim
>> wrote:
>> > Dear Alex,
>> >
>> > but we use DDC probing e. g. to identify connectors with improperly
>> > terminated i2c bus. Instead of flooding log
On Mon, Oct 31, 2011 at 11:15 AM, Thomas Reim wrote:
> Dear Alex,
>
> your reply confuses me:
>
>> On Sat, Oct 29, 2011 at 8:55 AM, Thomas Reim wrote:
>> > Dear Alex,
>> >
>> > but we use DDC probing e. g. to identify connectors with improperly
>> > terminated i2c bus. Instead of flooding logs an
Dear Alex,
your reply confuses me:
> On Sat, Oct 29, 2011 at 8:55 AM, Thomas Reim wrote:
> > Dear Alex,
> >
> > but we use DDC probing e. g. to identify connectors with improperly
> > terminated i2c bus. Instead of flooding logs and terminals with EDID dumps,
> > we decided some months ago to u
On Sat, Oct 29, 2011 at 8:55 AM, Thomas Reim wrote:
> Dear Alex,
>
> but we use DDC probing e. g. to identify connectors with improperly
> terminated i2c bus. Instead of flooding logs and terminals with EDID dumps,
> we decided some months ago to use this function during module loading to
> inform
On Sat, Oct 29, 2011 at 8:55 AM, Thomas Reim wrote:
> Dear Alex,
>
> but we use DDC probing e. g. to identify connectors with improperly
> terminated i2c bus. Instead of flooding logs and terminals with EDID dumps,
> we decided some months ago to use this function during module loading to
> inform
Dear Alex,
but we use DDC probing e. g. to identify connectors with improperly
terminated i2c bus. Instead of flooding logs and terminals with EDID
dumps, we decided some months ago to use this function during module
loading to inform the user once (and only once!), which connector has a
monitor
Dear Alex,
but we use DDC probing e. g. to identify connectors with improperly
terminated i2c bus. Instead of flooding logs and terminals with EDID
dumps, we decided some months ago to use this function during module
loading to inform the user once (and only once!), which connector has a
monitor
From: Alex Deucher
The function didn't work with DP, eDP, or DP bridge
connectors and thus confused users as it lead them to
believe nothing was connected or the EDID was invalid
when in fact is was, just on the aux bus rather an i2c.
It should also speed up module loading as it avoids a
bunch o
From: Alex Deucher
The function didn't work with DP, eDP, or DP bridge
connectors and thus confused users as it lead them to
believe nothing was connected or the EDID was invalid
when in fact is was, just on the aux bus rather an i2c.
It should also speed up module loading as it avoids a
bunch o
18 matches
Mail list logo
