At Fri, 13 Apr 2012 12:31:25 -0400,
Adam Jackson wrote:
>
> On 4/13/12 11:41 AM, Takashi Iwai wrote:
> > At Fri, 13 Apr 2012 11:30:01 -0400, Alex Deucher wrote:
> >> One thing to be careful of is that some monitors (especially LCD
> >> panels) don't like modes that are not in their EDIDs. As
At Fri, 13 Apr 2012 11:30:01 -0400,
Alex Deucher wrote:
>
> On Fri, Apr 13, 2012 at 11:13 AM, Takashi Iwai wrote:
> > At Fri, 13 Apr 2012 15:35:04 +0100,
> > Dave Airlie wrote:
> >>
> >> > I don't think we need to support all wild modes, too. ?But the _very_
> >> > common modes like 1366x768 and
At Fri, 13 Apr 2012 10:55:16 -0400,
Adam Jackson wrote:
>
> On 4/13/12 10:29 AM, Takashi Iwai wrote:
> > At Fri, 13 Apr 2012 10:14:46 -0400,
> > Adam Jackson wrote:
> >> Yeah, that's a bug. That's why I said it should be renamed
> >> drm_dmt_modes_for_range and run unconditionally if we find a
At Fri, 13 Apr 2012 15:35:04 +0100,
Dave Airlie wrote:
>
> > I don't think we need to support all wild modes, too. ?But the _very_
> > common modes like 1366x768 and 1600x900 should be really supported as
> > default.
>
> You guys still haven't answered the basic question, what HW is this
At Fri, 13 Apr 2012 10:14:46 -0400,
Adam Jackson wrote:
>
> On 4/12/12 7:09 PM, Rodrigo Vivi wrote:
>
> >> CVT monitors _must_ accept GTF as well, EDID says so. So functionally
> >> there's nothing wrong with the existing code.
> >
> > Actually the current code just check for gtf flag... so if
So, the modes that I added in that list was half got from windows on
my monitor and half requested by HP.
So let forget about other modes and focus on the one required by HP.
HP has requested the same list for everybody 3 years ago and it was
added by Windows and AMD at that time but our open
> I don't think we need to support all wild modes, too. ?But the _very_
> common modes like 1366x768 and 1600x900 should be really supported as
> default.
You guys still haven't answered the basic question, what HW is this broken?
Can you provide some EDIDs?
Dave.
On 4/13/12 11:25 AM, David Airlie wrote:
> I'm still intrigued about what hardware exists with a panel with a native
> mode it doesn't describe.
>
> How are we to know what the panel preferred mode is in this case?
>
> Or is this for larger panels wanting to use smaller modes?
AFAICT, yes, this
On 4/13/12 11:41 AM, Takashi Iwai wrote:
> At Fri, 13 Apr 2012 11:30:01 -0400, Alex Deucher wrote:
>> One thing to be careful of is that some monitors (especially LCD
>> panels) don't like modes that are not in their EDIDs. As such when
>> you try and set them you often get a wonky display or
On Fri, Apr 13, 2012 at 11:41 AM, Takashi Iwai wrote:
> At Fri, 13 Apr 2012 11:30:01 -0400,
> Alex Deucher wrote:
>>
>> On Fri, Apr 13, 2012 at 11:13 AM, Takashi Iwai wrote:
>> > At Fri, 13 Apr 2012 15:35:04 +0100,
>> > Dave Airlie wrote:
>> >>
>> >> > I don't think we need to support all wild
On Fri, Apr 13, 2012 at 11:13 AM, Takashi Iwai wrote:
> At Fri, 13 Apr 2012 15:35:04 +0100,
> Dave Airlie wrote:
>>
>> > I don't think we need to support all wild modes, too. ?But the _very_
>> > common modes like 1366x768 and 1600x900 should be really supported as
>> > default.
>>
>> You guys
>
> I agree with your point, too. When I worked on supporting these
> modes
> in X server side, I didn't pick up all such modes but only really de
> facto standard ones. It should suffice for most demands, indeed.
>
> Also, we don't have to add always 1600x900 or 1366x768. Such a mode
> is
On 4/13/12 10:29 AM, Takashi Iwai wrote:
> At Fri, 13 Apr 2012 10:14:46 -0400,
> Adam Jackson wrote:
>> Yeah, that's a bug. That's why I said it should be renamed
>> drm_dmt_modes_for_range and run unconditionally if we find a range
>> descriptor.
>
> Yeah, I saw your patches. Should the further
On 4/12/12 7:09 PM, Rodrigo Vivi wrote:
>> CVT monitors _must_ accept GTF as well, EDID says so. So functionally
>> there's nothing wrong with the existing code.
>
> Actually the current code just check for gtf flag... so if a monitor
> is gtf2 or cvt this dmt modes are not being added.
Yeah,
At Fri, 13 Apr 2012 10:14:46 -0400,
Adam Jackson wrote:
On 4/12/12 7:09 PM, Rodrigo Vivi wrote:
CVT monitors _must_ accept GTF as well, EDID says so. So functionally
there's nothing wrong with the existing code.
Actually the current code just check for gtf flag... so if a monitor
On 4/13/12 10:29 AM, Takashi Iwai wrote:
At Fri, 13 Apr 2012 10:14:46 -0400,
Adam Jackson wrote:
Yeah, that's a bug. That's why I said it should be renamed
drm_dmt_modes_for_range and run unconditionally if we find a range
descriptor.
Yeah, I saw your patches. Should the further work base
At Fri, 13 Apr 2012 15:35:04 +0100,
Dave Airlie wrote:
I don't think we need to support all wild modes, too. But the _very_
common modes like 1366x768 and 1600x900 should be really supported as
default.
You guys still haven't answered the basic question, what HW is this broken?
The
At Fri, 13 Apr 2012 10:55:16 -0400,
Adam Jackson wrote:
On 4/13/12 10:29 AM, Takashi Iwai wrote:
At Fri, 13 Apr 2012 10:14:46 -0400,
Adam Jackson wrote:
Yeah, that's a bug. That's why I said it should be renamed
drm_dmt_modes_for_range and run unconditionally if we find a range
On Fri, Apr 13, 2012 at 11:13 AM, Takashi Iwai ti...@suse.de wrote:
At Fri, 13 Apr 2012 15:35:04 +0100,
Dave Airlie wrote:
I don't think we need to support all wild modes, too. But the _very_
common modes like 1366x768 and 1600x900 should be really supported as
default.
You guys still
At Fri, 13 Apr 2012 11:30:01 -0400,
Alex Deucher wrote:
On Fri, Apr 13, 2012 at 11:13 AM, Takashi Iwai ti...@suse.de wrote:
At Fri, 13 Apr 2012 15:35:04 +0100,
Dave Airlie wrote:
I don't think we need to support all wild modes, too. But the _very_
common modes like 1366x768 and
On Fri, Apr 13, 2012 at 11:41 AM, Takashi Iwai ti...@suse.de wrote:
At Fri, 13 Apr 2012 11:30:01 -0400,
Alex Deucher wrote:
On Fri, Apr 13, 2012 at 11:13 AM, Takashi Iwai ti...@suse.de wrote:
At Fri, 13 Apr 2012 15:35:04 +0100,
Dave Airlie wrote:
I don't think we need to support all
On 4/13/12 11:41 AM, Takashi Iwai wrote:
At Fri, 13 Apr 2012 11:30:01 -0400, Alex Deucher wrote:
One thing to be careful of is that some monitors (especially LCD
panels) don't like modes that are not in their EDIDs. As such when
you try and set them you often get a wonky display or more often
At Fri, 13 Apr 2012 12:31:25 -0400,
Adam Jackson wrote:
On 4/13/12 11:41 AM, Takashi Iwai wrote:
At Fri, 13 Apr 2012 11:30:01 -0400, Alex Deucher wrote:
One thing to be careful of is that some monitors (especially LCD
panels) don't like modes that are not in their EDIDs. As such when
On 4/13/12 11:25 AM, David Airlie wrote:
I'm still intrigued about what hardware exists with a panel with a native mode
it doesn't describe.
How are we to know what the panel preferred mode is in this case?
Or is this for larger panels wanting to use smaller modes?
AFAICT, yes, this last
So, the modes that I added in that list was half got from windows on
my monitor and half requested by HP.
So let forget about other modes and focus on the one required by HP.
HP has requested the same list for everybody 3 years ago and it was
added by Windows and AMD at that time but our open
Hi Ajax and Takashi,
Thanks for your comments.
> The intent here is great, but I don't like the way this is phrased, or
> the implementation.
To be honest I don't like this implementation as well. I just tried to
follow the way it wasa already there.
> CVT monitors _must_ accept GTF as well,
At Wed, 11 Apr 2012 21:59:28 -0300,
Rodrigo Vivi wrote:
>
> There are many bugs open on fd.o regarding missing modes that are supported
> on Windows and other closed source drivers.
> >From EDID spec we can (might?) infer modes using GTF and CVT when monitor
> >allows it trough range limited
On Wed, 2012-04-11 at 21:59 -0300, Rodrigo Vivi wrote:
> There are many bugs open on fd.o regarding missing modes that are supported
> on Windows and other closed source drivers.
> From EDID spec we can (might?) infer modes using GTF and CVT when monitor
> allows it trough range limited flag...
On Wed, 2012-04-11 at 21:59 -0300, Rodrigo Vivi wrote:
There are many bugs open on fd.o regarding missing modes that are supported
on Windows and other closed source drivers.
From EDID spec we can (might?) infer modes using GTF and CVT when monitor
allows it trough range limited flag...
At Wed, 11 Apr 2012 21:59:28 -0300,
Rodrigo Vivi wrote:
There are many bugs open on fd.o regarding missing modes that are supported
on Windows and other closed source drivers.
From EDID spec we can (might?) infer modes using GTF and CVT when monitor
allows it trough range limited flag...
Hi Ajax and Takashi,
Thanks for your comments.
The intent here is great, but I don't like the way this is phrased, or
the implementation.
To be honest I don't like this implementation as well. I just tried to
follow the way it wasa already there.
CVT monitors _must_ accept GTF as well, EDID
31 matches
Mail list logo
