Checking up on this patch from a few months back that I'd like to get
included.. Acked by Daniel Vetter[1] and Reviewed by Jani Nikula[2].
However ajax has not yet provided comments. Is this SOL without feedback
from ajax?
[1] http://lists.freedesktop.org/archives/dri-devel/2013-March/036457.ht
Checking up on this patch from a few months back that I'd like to get
included.. Acked by Daniel Vetter[1] and Reviewed by Jani Nikula[2].
However ajax has not yet provided comments. Is this SOL without feedback
from ajax?
[1] http://lists.freedesktop.org/archives/dri-devel/2013-March/036457.ht
On Wed, 03 Apr 2013, Dylan Semler wrote:
> Version 3 was Acked by Daniel Vetter[1]. Any chance ajax can give his
> comments?
>
> [1] http://lists.freedesktop.org/archives/dri-devel/2013-March/036457.html
FWIW,
Reviewed-by: Jani Nikula
On Wed, 03 Apr 2013, Dylan Semler wrote:
> Version 3 was Acked by Daniel Vetter[1]. Any chance ajax can give his
> comments?
>
> [1] http://lists.freedesktop.org/archives/dri-devel/2013-March/036457.html
FWIW,
Reviewed-by: Jani Nikula
___
dri-devel m
On Mon, Mar 25, 2013 at 5:58 PM, Dylan Semler
wrote:
>
> Changes in this version
> * rename do_force_quirk_modes() -> do_force_quirk_mode()
> * use list_for_each_entry() instead of list_for_each_entry_safe() in
>do_force_quirk_mode()
> * remove num_modes from do_force_quirk_mode(), just ret
On Mon, Mar 25, 2013 at 5:58 PM, Dylan Semler
wrote:
>
> Changes in this version
> * rename do_force_quirk_modes() -> do_force_quirk_mode()
> * use list_for_each_entry() instead of list_for_each_entry_safe() in
>do_force_quirk_mode()
> * remove num_modes from do_force_quirk_mode(), just ret
Changes in this version
* rename do_force_quirk_modes() -> do_force_quirk_mode()
* use list_for_each_entry() instead of list_for_each_entry_safe() in
do_force_quirk_mode()
* remove num_modes from do_force_quirk_mode(), just return 1 or 0 as
appropriate
* remove unused quirks argument from
Changes in this version
* rename do_force_quirk_modes() -> do_force_quirk_mode()
* use list_for_each_entry() instead of list_for_each_entry_safe() in
do_force_quirk_mode()
* remove num_modes from do_force_quirk_mode(), just return 1 or 0 as
appropriate
* remove unused quirks argument from
On Fri, Mar 22, 2013 at 07:08:05PM -0400, Dylan Semler wrote:
> Changes in this version
> * Uses drm_cvt_mode() instead of drm_gtf_mode() to build modeline
> * Adds bool to specify reduced blanking to edid_quirk_force_mode
> * Removes preferred bit from all other modes
>
> There is at least one
On Fri, Mar 22, 2013 at 09:48:49AM -0400, Dylan Semler wrote:
> Changes in this version
> * Fix missing commit messages in patch emails
Seems to be still missing. Also I kinda liked Alex' idea of adding a
gtf/gtf2/cdt flag for the detailed timing generation algorithm.
-Daniel
>
> These patches
On Fri, Mar 22, 2013 at 07:08:05PM -0400, Dylan Semler wrote:
> Changes in this version
> * Uses drm_cvt_mode() instead of drm_gtf_mode() to build modeline
> * Adds bool to specify reduced blanking to edid_quirk_force_mode
> * Removes preferred bit from all other modes
>
> There is at least one
On Fri, Mar 22, 2013 at 09:48:49AM -0400, Dylan Semler wrote:
> Changes in this version
> * Fix missing commit messages in patch emails
Seems to be still missing. Also I kinda liked Alex' idea of adding a
gtf/gtf2/cdt flag for the detailed timing generation algorithm.
-Daniel
>
> These patches
Changes in this version
* Uses drm_cvt_mode() instead of drm_gtf_mode() to build modeline
* Adds bool to specify reduced blanking to edid_quirk_force_mode
* Removes preferred bit from all other modes
There is at least one monitor that doesn't report its native resolution
in its EDID block. Thi
Changes in this version
* Uses drm_cvt_mode() instead of drm_gtf_mode() to build modeline
* Adds bool to specify reduced blanking to edid_quirk_force_mode
* Removes preferred bit from all other modes
There is at least one monitor that doesn't report its native resolution
in its EDID block. Thi
On Fri, Mar 22, 2013 at 3:02 PM, Dylan Semler wrote:
> On Fri, Mar 22, 2013 at 9:50 AM, Alex Deucher
> wrote:
>>
>> On Thu, Mar 21, 2013 at 5:42 PM, Dylan Semler
>> wrote:
>> > Oops. I neglected to preface this with my motivation: I have a new
>> > monitor that doesn't report its native resol
On Fri, Mar 22, 2013 at 10:41 AM, Daniel Vetter wrote:
>
> On Fri, Mar 22, 2013 at 3:02 PM, Dylan Semler
wrote:
> > On Fri, Mar 22, 2013 at 9:50 AM, Alex Deucher
> > wrote:
> >>
> >> That's odd. Maybe it's actually in an extension block or something
like
> >> that?
> >
> > Yeah, I agree. Accor
On Fri, Mar 22, 2013 at 9:50 AM, Alex Deucher wrote:
>
> On Thu, Mar 21, 2013 at 5:42 PM, Dylan Semler
wrote:
> > Oops. I neglected to preface this with my motivation: I have a new
> > monitor that doesn't report its native resolution in its EDID block. It
> > seemed to me this calls for an ED
On Thu, Mar 21, 2013 at 5:42 PM, Dylan Semler wrote:
> Oops. I neglected to preface this with my motivation: I have a new monitor
> that doesn't report its native resolution in its EDID block. It seemed to
> me
> this calls for an EDID quirk, but the current quirk infrastructure doesn't
> allow
Changes in this version
* Fix missing commit messages in patch emails
These patches offer a fix for a monitor that doesn't report its native
resolution in its EDID. The idea is setup a new quirk list with width, height,
and refresh rates for each monitor that needs this quirk. If a monitor is
a
On Thu, Mar 21, 2013 at 10:42 PM, Dylan Semler
wrote:
> Oops. I neglected to preface this with my motivation: I have a new monitor
> that doesn't report its native resolution in its EDID block. It seemed to
> me
> this calls for an EDID quirk, but the current quirk infrastructure doesn't
> all
On Fri, Mar 22, 2013 at 4:48 AM, Daniel Vetter wrote:
>
> I think it'd be good to shovel these text blocks into the (currently
rather
> empty) commit messages of the patches. Since when reading old commits with
> e.g. git blame that's what people will read.
Yeah, I just noticed that. For some re
On Fri, Mar 22, 2013 at 10:41 AM, Daniel Vetter wrote:
>
> On Fri, Mar 22, 2013 at 3:02 PM, Dylan Semler
wrote:
> > On Fri, Mar 22, 2013 at 9:50 AM, Alex Deucher
> > wrote:
> >>
> >> That's odd. Maybe it's actually in an extension block or something
like
> >> that?
> >
> > Yeah, I agree. Accor
On Fri, Mar 22, 2013 at 3:02 PM, Dylan Semler wrote:
> On Fri, Mar 22, 2013 at 9:50 AM, Alex Deucher wrote:
>>
>> On Thu, Mar 21, 2013 at 5:42 PM, Dylan Semler
>> wrote:
>> > Oops. I neglected to preface this with my motivation: I have a new
>> > monitor that doesn't report its native resoluti
On Fri, Mar 22, 2013 at 9:50 AM, Alex Deucher wrote:
>
> On Thu, Mar 21, 2013 at 5:42 PM, Dylan Semler
wrote:
> > Oops. I neglected to preface this with my motivation: I have a new
> > monitor that doesn't report its native resolution in its EDID block. It
> > seemed to me this calls for an ED
Changes in this version
* Fix missing commit messages in patch emails
These patches offer a fix for a monitor that doesn't report its native
resolution in its EDID. The idea is setup a new quirk list with width, height,
and refresh rates for each monitor that needs this quirk. If a monitor is
a
On Thu, Mar 21, 2013 at 5:42 PM, Dylan Semler wrote:
> Oops. I neglected to preface this with my motivation: I have a new monitor
> that doesn't report its native resolution in its EDID block. It seemed to
> me
> this calls for an EDID quirk, but the current quirk infrastructure doesn't
> allow
On Fri, Mar 22, 2013 at 4:48 AM, Daniel Vetter wrote:
>
> I think it'd be good to shovel these text blocks into the (currently
rather
> empty) commit messages of the patches. Since when reading old commits with
> e.g. git blame that's what people will read.
Yeah, I just noticed that. For some re
On Thu, Mar 21, 2013 at 10:42 PM, Dylan Semler wrote:
> Oops. I neglected to preface this with my motivation: I have a new monitor
> that doesn't report its native resolution in its EDID block. It seemed to
> me
> this calls for an EDID quirk, but the current quirk infrastructure doesn't
> allo
Oops. I neglected to preface this with my motivation: I have a new
monitor
that doesn't report its native resolution in its EDID block. It seemed to
me
this calls for an EDID quirk, but the current quirk infrastructure doesn't
allow explicitly creating new modes. So I set out to make a simple
e
The idea is setup a new quirk list with width, height, and refresh rates for
each monitor that needs this quirk. If a monitor is attached that matches one
in this list, the full modeline is calculated with drm_gtf_mode, the
DRM_MODE_TYPE_PREFERRED bit is set, and the new mode is added to the conne
Oops. I neglected to preface this with my motivation: I have a new
monitor
that doesn't report its native resolution in its EDID block. It seemed to
me
this calls for an EDID quirk, but the current quirk infrastructure doesn't
allow explicitly creating new modes. So I set out to make a simple
e
The idea is setup a new quirk list with width, height, and refresh rates for
each monitor that needs this quirk. If a monitor is attached that matches one
in this list, the full modeline is calculated with drm_gtf_mode, the
DRM_MODE_TYPE_PREFERRED bit is set, and the new mode is added to the conne
32 matches
Mail list logo
