Well, it took me 4 months to find the time, but I finally had a
crack addressing the ideas you mentioned in your last response.
I believe that the patch in the following note does everything
that you wanted, and hopefully it's all straightforward enough
that it doesn't require a lot of explanation
Well, it took me 4 months to find the time, but I finally had a
crack addressing the ideas you mentioned in your last response.
I believe that the patch in the following note does everything
that you wanted, and hopefully it's all straightforward enough
that it doesn't require a lot of explanation
On Mon, 2012-05-07 at 14:50 -0500, Ian Pilcher wrote:
> On 05/03/2012 02:42 PM, Adam Jackson wrote:
> > I'd like to see documentation for the bit values of the quirks as well.
> > And, ideally, this would also have some runtime API for manipulating the
> > quirk list, so that way you can test new q
On 05/03/2012 02:42 PM, Adam Jackson wrote:
> This looks good, thank you for taking it on.
It was either that or give up on my big display, so ... you're welcome.
> I'd like to see documentation for the bit values of the quirks as well.
> And, ideally, this would also have some runtime API for ma
On Mon, 2012-05-07 at 14:50 -0500, Ian Pilcher wrote:
> On 05/03/2012 02:42 PM, Adam Jackson wrote:
> > I'd like to see documentation for the bit values of the quirks as well.
> > And, ideally, this would also have some runtime API for manipulating the
> > quirk list, so that way you can test new q
On 05/03/2012 02:42 PM, Adam Jackson wrote:
> This looks good, thank you for taking it on.
It was either that or give up on my big display, so ... you're welcome.
> I'd like to see documentation for the bit values of the quirks as well.
> And, ideally, this would also have some runtime API for ma
On 5/3/12 2:01 PM, Ian Pilcher wrote:
> The patch does the following:
This looks good, thank you for taking it on.
> * Changes the vendor field of struct edid_quirk to an array, rather
>than a pointer. (This has already been sent to the dri-devel list.)
> * Adds two new quirks EDID_QUIRK_DI
I just attached this patch to
https://bugzilla.redhat.com/show_bug.cgi?id=806091, along with the
following comments:
This is the "first draft" of an EDID quirk-based approach to solving
this problem. I intend to perform a bit of cleanup and break it up
into a series of separate patches, but I'm p
On 5/3/12 2:01 PM, Ian Pilcher wrote:
The patch does the following:
This looks good, thank you for taking it on.
* Changes the vendor field of struct edid_quirk to an array, rather
than a pointer. (This has already been sent to the dri-devel list.)
* Adds two new quirks EDID_QUIRK_DISABL
I just attached this patch to
https://bugzilla.redhat.com/show_bug.cgi?id=806091, along with the
following comments:
This is the "first draft" of an EDID quirk-based approach to solving
this problem. I intend to perform a bit of cleanup and break it up
into a series of separate patches, but I'm p
On 04/24/2012 04:07 AM, Lars-Peter Clausen wrote:
> I just had a similar issue with a different driver and remembered your post
>
> If the S bits in the infoframe are 0 the display may under- or overscan the
> the image (Although the spec says it should behave the same if no infoframe
> is present)
On 04/24/2012 04:07 AM, Lars-Peter Clausen wrote:
I just had a similar issue with a different driver and remembered your post
If the S bits in the infoframe are 0 the display may under- or overscan the
the image (Although the spec says it should behave the same if no infoframe
is present). If it
On 04/19/2012 09:16 PM, Ian Pilcher wrote:
> Greetings all!
>
> I recently discovered that my nice 1900x1200 display is horribly
> confused by the InfoFrame functionality that was added to the nouveau
> driver in Linux 3.3. Additional testing has shown that it has the same
> problem with the i915
On 04/19/2012 09:16 PM, Ian Pilcher wrote:
> Greetings all!
>
> I recently discovered that my nice 1900x1200 display is horribly
> confused by the InfoFrame functionality that was added to the nouveau
> driver in Linux 3.3. Additional testing has shown that it has the same
> problem with the i915
Greetings all!
I recently discovered that my nice 1900x1200 display is horribly
confused by the InfoFrame functionality that was added to the nouveau
driver in Linux 3.3. Additional testing has shown that it has the same
problem with the i915 driver and NVIDIA's proprietary driver.
NVIDIA's Wind
Greetings all!
I recently discovered that my nice 1900x1200 display is horribly
confused by the InfoFrame functionality that was added to the nouveau
driver in Linux 3.3. Additional testing has shown that it has the same
problem with the i915 driver and NVIDIA's proprietary driver.
NVIDIA's Wind
16 matches
Mail list logo
