We only ever use xserver's AGP support from the i810 driver.
Signed-off-by: Adam Jackson
---
src/uxa/intel_driver.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/uxa/intel_driver.c b/src/uxa/intel_driver.c
index 73d7f4f..62abdd2 100644
--- a/src/uxa/intel_driver.c
+++ b/sr
adding support to
> userspace, but we can't land any patches until drm_fourcc.h has been updated
> here.
Series is:
Reviewed-by: Adam Jackson
- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, 2019-02-27 at 19:14 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Some monitors apparently forget to mark any mode as preferred in the
> EDID. In this particular case we have a very generic looking ID
> "PNP Model 0 Serial Number 4" / "LVDS 800x600" so a specific quirk
> doesn't s
On Wed, 2019-02-27 at 23:03 +0200, Ville Syrjälä wrote:
> So instead of putting this logic into the EDID parser I guess we
> could just put it into the i915 fixed mode code. But then I suppose
> we should also fix EDID_QUIRK_FIRST_DETAILED_PREFERRED (assuming it
> exists for a good reason).
I don
On Thu, 2019-03-07 at 10:48 +0100, Maarten Lankhorst wrote:
> Hi Sean and Joonas,
>
> Here's a pull request for HDR format enabling in i915. Can this be pulled to
> drm-misc-next and dinq?
Could you also add Kevin Strasser's patch for FP16 formats? For that
matter I'd like to see FP32 added too,
On Mon, 2019-03-11 at 12:19 +0100, Maarten Lankhorst wrote:
> Hey,
>
> Op 07-03-2019 om 18:12 schreef Adam Jackson:
> > On Thu, 2019-03-07 at 10:48 +0100, Maarten Lankhorst wrote:
> > > Hi Sean and Joonas,
> > >
> > > Here's a pull request for
On Tue, 2019-03-19 at 13:17 +0100, Maarten Lankhorst wrote:
> There has unfortunately been a conflict with the following 3 commits:
>
> commit e9961ab95af81b8d29054361cd5f0c575102cf87
> Author: Ayan Kumar Halder
> Date: Fri Nov 9 17:21:12 2018 +
> drm: Added a new format DRM_FORMAT_XVYU
s was only about panels on i915, and not
any monitor/connector with no preferred modes. Looks sane to me though.
Reviewed-by: Adam Jackson
- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
ernel.
>
> The concensus seems to be that this quirk is a bit misguided
> anyway so let's nuke the leftovers.
Reviewed-by: Adam Jackson
- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Sat, 2019-10-05 at 05:58 +0800, Lee Shawn C wrote:
> This panel (manufacturer is SDC, product ID is 0x4141)
> used manufacturer defined DPCD register to control brightness
> that not defined in eDP spec so far. This change follow panel
> vendor's instruction to support brightness adjustment.
I'
On Mon, 2019-10-07 at 12:08 +0300, Jani Nikula wrote:
> The problem with the EDID quirks is that exposing the quirks sticks out
> like a sore thumb. Thus far all of it has been contained in drm_edid.c
> and they affect how the EDID gets parsed, for all drivers. Obviously
> this could be changed, b
On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote:
> On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
> > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> > > pre-merge CI.
> >
> > Thanks for the suggestion! I implem
On Tue, 2020-02-11 at 13:33 -0500, Lyude Paul wrote:
> - if (!intel_dp_aux_display_control_capable(intel_connector))
> + /*
> + * There are a lot of machines that don't advertise the backlight
> + * control interface to use properly in their VBIOS, :\
> + */
> + if (dev_
ce the ability to apply DP quirks based on EDID
> identification. We reuse the same quirk bits for OUI-based quirks, so
> that callers can simply check all possible quirks using
> drm_dp_has_quirk().
With the bug URL fixed in 2/3, series is:
Reviewed-by: Adam Jackson
- ajax
__
Signed-off-by: Adam Jackson
---
tools/intel_vbt_decode.c | 4 ++--
tools/intel_vbt_defs.h | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/intel_vbt_decode.c b/tools/intel_vbt_decode.c
index 9d90c69d..ce7da2c0 100644
--- a/tools/intel_vbt_decode.c
+++ b/tools
The gen2+ code has been unreachable since:
commit ebb7c78d358b2ea45c7d997423e6feb42e5ce4ef
Author: Daniel Vetter
Date: Wed Jan 27 14:38:00 2016 +0100
agp/intel-gtt: Only register fake agp driver for gen1
Signed-off-by: Adam Jackson
---
drivers/char/agp/intel-gtt.c | 631
The i810 was attached to Pentium III motherboards, no 64-bit CPU is ever
going to have one.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index
On Fri, 2018-04-20 at 20:20 +, Patchwork wrote:
> Possible regressions
>
> igt@drv_module_reload@basic-no-display:
> fi-elk-e7500: PASS -> DMESG-FAIL +2
>
> igt@drv_module_reload@basic-reload:
> fi-gdg-551: PASS -> DMESG-FAIL +2
> fi-blb-
On Tue, 2018-05-15 at 12:51 +0200, Thomas Klausner wrote:
> > Those specific fixes could probably be cherry-picked to the version
> > you're trying to build, but it may be worthwhile to update to git
> > master anyway.
>
> I'm packaging for NetBSD, and we prefer to package tarballs, not git
> mas
Hey, if you haven't been following xorg-devel@, we're planning to move
our repository hosting to freedesktop's gitlab instance. This is
basically transparent from the client side, your git urls won't change,
but you get continuous integration hooks for free if you want them.
Longer term, we'd like
On Tue, 2018-07-24 at 21:15 +0530, Uma Shankar wrote:
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -209,6 +209,17 @@
> #define DRM_MODE_CONTENT_PROTECTION_DESIRED 1
> #define DRM_MODE_CONTENT_PROTECTION_ENABLED 2
>
> +enum extended_colorimetry {
> +
On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote:
> - Sticking to fdo bugzilla and disabling gitlab issues for at least
> drm-intel for the time being. Doing that migration in the same go is a
> bit much I think. Reassignment across bugzilla and gitlab will be an
> issue.
Can you elabor
get with the 1 kHz resolution we use).
>
> This should help code that's looking for an exact clock match (eg. i915
> audio N/CTS setup).
Looks like a sane set of changes. Series is:
Reviewed-by: Adam Jackson
- ajax
___
Intel-gf
"supplied by the
driver" as with EDID-derived modes.
With or without that, patches 2 3 4 and 8 are:
Reviewed-by: Adam Jackson
- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, 2018-03-07 at 07:46 -0800, Rodrigo Vivi wrote:
> Copied from Mesa with no modifications.
>
> Gives us Geminilake and Kaby Lake platform names updates and
> sync on Coffee Lake PCI IDs.
>
> Cc: Timo Aaltonen
> Signed-off-by: Rodrigo Vivi
Merged, thanks:
remote: I: patch #208689 updated
t page flipping on master
> outputs while there are active slave outputs.
>
> Define HAS_DIRTYTRACKING_DRAWABLE_SRC for drivers to check, but leave
> HAS_DIRTYTRACKING_ROTATION defined as well to make things slightly
> easier for drivers.
>
> Signed-off-by: Mich
On Thu, 2018-01-18 at 17:06 +0200, Jani Nikula wrote:
> No more sing-a-ling.
>
> Reported-by: Adam Jackson
Why'd you omit the typos I reported in tools/intel_vbt_decode.c ?
- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedes
On Fri, 2018-01-19 at 10:17 +0200, Jani Nikula wrote:
> On Thu, 18 Jan 2018, Adam Jackson wrote:
> > On Thu, 2018-01-18 at 17:06 +0200, Jani Nikula wrote:
> > > No more sing-a-ling.
> > >
> > > Reported-by: Adam Jackson
> >
> > Why'd you
On Mon, 2010-04-12 at 17:09 +0800, Zhenyu Wang wrote:
> Update the self-refresh watermark for display plane/cursor and enable
> the memory self-refresh on Ironlake. The watermark is also updated for
> the active display plane.
>
> More than 1W idle power is saved on one Ironlake laptop after enabl
On Mon, 2010-04-12 at 17:03 +0800, Zhenyu Wang wrote:
> On 2010.04.09 17:55:10 -0400, Adam Jackson wrote:
> > This should be a small power savings, but the Watts-Up I used to test is
> > only precise to within 100mW. Tested on Lenovo T410 (Ironlake), LVDS
> > VGA and DisplayP
This should be a small power savings. Tested on Lenovo T410 (Ironlake), LVDS
VGA and DisplayPort, up to 1920x1200R.
v2: Add Sandybridge support, fix obvious math error.
Acked-by: Zhenyu Wang
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/intel_display.c | 26
pci.ids and the datasheet both say it's 358e, not 35e8.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/i915_drv.c |5 +++--
drivers/gpu/drm/i915/i915_drv.h |3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm
IS_MOBILE() catches 85x, so we'd always try to use the 9xx FIFO sizing;
since there's an explicit 85x version, this seems wrong.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/intel_display.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drive
On Fri, 2010-04-16 at 10:24 +0800, ykzhao wrote:
> On Fri, 2010-04-16 at 02:03 +0800, Adam Jackson wrote:
> > IS_MOBILE() catches 85x, so we'd always try to use the 9xx FIFO sizing;
> > since there's an explicit 85x version, this seems wrong.
>
> Right. It seems t
IS_MOBILE() catches 85x, so we'd always try to use the 9xx FIFO sizing;
since there's an explicit 85x version, this seems wrong.
v2: Handle 830m correctly too.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/intel_display.c | 11 ++-
1 files changed, 6 insertions(+), 5
Spatial dither is better than nothing, but ST is even better.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/i915_reg.h |5 -
drivers/gpu/drm/i915/intel_display.c | 10 ++
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915
On Wed, 2010-04-21 at 16:46 +0800, ykzhao wrote:
> On Sat, 2010-04-10 at 05:14 +0800, Eric Anholt wrote:
> > As far as I can tell from reading the specs, this patch just completely
> > breaks TV detect on GM45. And the logic of "set all the bits for the
> > register setting we're going to do and t
Disclaimer: I haven't tested this extensively, it just seems logical, and I
really hate to see us lose FBC on gen3 since that's the family being used in
low-wattage devices. Wider testing would be greatly appreciated.
The only thing I really don't like about this is how we hit every CRTC on
resum
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/i915_debugfs.c | 13 +--
drivers/gpu/drm/i915/i915_dma.c |3 +-
drivers/gpu/drm/i915/i915_drv.h |5 ++-
drivers/gpu/drm/i915/intel_display.c | 66 ++---
4 files changed, 51 insertions
Restore it on the way back up if we disabled it on the way down.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/i915_drv.c | 13 +
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_suspend.c |2 --
3 files changed, 14 insertions(+), 2 deletions
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/i915_drv.h |2 --
drivers/gpu/drm/i915/intel_display.c |4 ++--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e9e8c4a..a43a4f5 100644
--- a
Disabling it across suspend cycles should be equivalent, without losing
the power savings.
This reverts commit 8d06a1e1e9c69244f08beb7d17146483f9dcd120.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/i915_drv.c |4 ++--
drivers/gpu/drm/i915/intel_display.c |2 +-
2 files
illa.redhat.com/584229
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_bios.c |1 +
drivers/gpu/drm/i915/intel_sdvo.c | 41
3 files changed, 11 insertions(+), 32 deletions(-)
diff --git a/drive
On Sat, 2010-04-24 at 17:25 +0100, Peter Clifton wrote:
> I noticed an anomaly in the register settings on my GM45, according to
> PIPEBCONF, it is set in 10-bit palette mode, yet the KMS code programs
> the palette registers as if it is in 8-bit mode, and doesn't touch the
> PIPEBGCMAX{RED,GREEN,
On Fri, 2010-04-23 at 16:16 -0400, Adam Jackson wrote:
> So, instead of that, let's just use the DDC bus the child device table
> tells us to use. I'm guessing at the bitmask and shifting from VBIOS
> dumps, but it can't possibly be worse.
Except,
&
On Mon, 2010-04-26 at 22:19 +0100, Peter Clifton wrote:
> @@ -3439,11 +3442,16 @@ void intel_crtc_load_lut(struct drm_crtc *crtc)
>
> /* use legacy palette for Ironlake */
> if (IS_IRONLAKE(dev))
> - palreg = (intel_crtc->pipe == 0) ? LGC_PALETTE_A :
> -
On Mon, 2010-04-26 at 23:24 +0100, Peter Clifton wrote:
> ---
> drivers/gpu/drm/i915/intel_display.c | 38 ++---
> drivers/gpu/drm/i915/intel_drv.h |2 +-
> 2 files changed, 17 insertions(+), 23 deletions(-)
Nak.
This will break DirectColor visuals in X. Di
On Tue, 2010-04-27 at 12:53 -0500, Gabriel M. Beddingfield wrote:
> Any idea why it won't load the correct resolution?
Because you're using the vesa driver, and you should be using the intel
driver.
- ajax
signature.asc
Description: This is a digitally signed message part
_
On Tue, 2010-04-27 at 14:16 -0500, Gabriel M. Beddingfield wrote:
> On Tue, 27 Apr 2010, Adam Jackson wrote:
> > On Tue, 2010-04-27 at 12:53 -0500, Gabriel M. Beddingfield wrote:
> >> Any idea why it won't load the correct resolution?
> >
> > Because you're
On Tue, 2010-04-27 at 14:58 -0500, Gabriel M. Beddingfield wrote:
> First: I _really_ appreciate your help!
>
> I added 8086A010, 8086A011, and 8086A012 to a file
> /usr/share/xserver-xorg/pci/intel.icv, and then I get:
>
> (EE) Failed to load module "i810" (module does not exist, 0)
>
On Wed, 2010-04-28 at 08:30 +0200, Tino Keitel wrote:
> Your X server uses the VESA driver. This list is about the intel
> driver. As 1024x600 is not a resolution defined by VESA, it won't be
> used by the VESA driver. If you switch to the intel driver, it should
> work (and also give reasonable a
On Wed, 2010-04-28 at 10:15 +0800, Zhenyu Wang wrote:
> On 2010.04.23 16:16:12 -0400, Adam Jackson wrote:
> > Multifunction SDVO cards stopped working after 14571b4, and would report
> > something that looked remarkably like an ADD2 SPD ROM instead of EDID.
> > This appears
On Thu, 2010-04-29 at 15:45 -0700, Eric Anholt wrote:
> On Fri, 23 Apr 2010 11:17:40 -0400, Adam Jackson wrote:
> > Restore it on the way back up if we disabled it on the way down.
>
> I don't think we need to restore it on the way back up. The
> force_mode_set will DPMS
On Fri, 2010-04-30 at 12:25 -0700, SD wrote:
> But, why not to split intel driver between old cards and new ones?
> Every one knows that it is impossible to provide full support for:
> 810, i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
> E7221 (i915), 915GM, 945G, 945GM, 945GME,
On Fri, 2010-04-30 at 22:56 +0200, Clemens Eisserer wrote:
> > Oh, I get it. You don't understand software.
>
> Well although the whole discussion isn't really focussed, he has one point.
That's as may be true. But the leap from "it's worse" to "because it
supports so many devices" is just nons
On Fri, 2010-04-23 at 16:16 -0400, Adam Jackson wrote:
> Multifunction SDVO cards stopped working after 14571b4, and would report
> something that looked remarkably like an ADD2 SPD ROM instead of EDID.
> This appears to be because DDC bus selection was utterly horked by that
On Wed, 2010-05-05 at 10:52 -0700, Carl Worth wrote:
> I'm going through the past couple weeks of traffic on the list looking
> for patches that haven't gotten picked up yet.
>
> So I'd love to review one like this, but it would be easier if the
> commit message pointed me to something specific I
On Wed, 2010-05-05 at 15:38 +0800, ykzhao wrote:
> Hi, Ajax
>
> Using the BIOS-defined value in VBT can fix the bug you mentioned.
> but the problem is that it is static and would still have problem if
> user does outputs swap on a multiple function SDVO device at run
> time(E.g. The exte
On Fri, 2010-05-07 at 14:41 -0700, Eric Anholt wrote:
> Applied those two.
>
> The fact that we're exposing 2 connectors for this situation is bogus in
> how the KMS architecture is supposed to work, right? I mean, we've got
> 2 "outputs" in this encoder going to one physical connector. The use
I got a report of KMS setup failing on an eDP panel. dmesg shows us
trying to set 1.62GHz for the link rate, which would be perfectly legal
for the requested mode, but the VBT appears to claim that the panel
only supports 2.7GHz.
This patch attempts to scrape the eDP setup parameters out of the V
eDP panels are often fixed-rate. Grab the link speed and lane count
from the VBT and use those instead of trying to compute them.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/intel_bios.c | 18 ++
drivers/gpu/drm/i915
On Thu, 2010-05-13 at 10:46 +0800, Zhenyu Wang wrote:
> On 2010.05.12 11:29:53 -0400, Adam Jackson wrote:
> > eDP panels are often fixed-rate. Grab the link speed and lane count
> > from the VBT and use those instead of trying to compute them.
> >
> >
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/intel_dp.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 78a75e8..a1a6785 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm
DisplayPort spec v1.1a, Table 2-52.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/intel_dp.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 77e40cf..78a75e8 100644
--- a/drivers/gpu/drm
On Mon, 2010-05-17 at 12:13 +0100, Simon Farnsworth wrote:
> The first bit of misbehaviour I'm seeing is caching of EDID across hotplug
> events. If I boot my system with no display attached, I correctly see no EDID
> property. When I connect a monitor via VGA, using cabling that supports DDC, I
>
On Tue, 2010-05-18 at 18:07 +0100, Simon Farnsworth wrote:
> On Tuesday 18 May 2010, Adam Jackson wrote:
> > On Mon, 2010-05-17 at 12:13 +0100, Simon Farnsworth wrote:
> > > The first bit of misbehaviour I'm seeing is caching of EDID across
> > > hotplug eve
Disable the CRT plug interrupt while doing the force cycle, explicitly
clear any CRT interrupt we may have generated, and restore when done.
Should mitigate interrupt storms from hotplug detection.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/i915_reg.h |1 -
drivers/gpu/drm/i915
On Mon, 2010-05-24 at 21:46 -0400, Andrew Lutomirski wrote:
> On Mon, May 24, 2010 at 4:46 PM, Adam Jackson wrote:
> > Disable the CRT plug interrupt while doing the force cycle, explicitly
> > clear any CRT interrupt we may have generated, and restore when done.
> > Shou
that.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/i915_irq.c | 50 ++-
1 files changed, 23 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a7e4b1f..f9d2cc0 100644
--- a/drivers/gp
I'm actually kind of shocked that it works at all otherwise.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/intel_bios.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 4c
On Thu, 2010-05-27 at 17:26 -0400, Adam Jackson wrote:
> Unmask, then enable interrupts, then enable interrupt sources; matches
> PCH ordering. The old way (sources, enable, unmask) gives a window
> during which interrupt conditions would appear in ISR but would never
> reach IIR an
On Fri, 2010-06-04 at 10:40 -0500, Sander Jansen wrote:
> When will the GMA HD reference docs become available?
If you mean Core i3/i5 (Ironlake), then:
http://www.x.org/docs/intel/HD/
- ajax
signature.asc
Description: This is a digitally signed message part
___
On Mon, 2010-06-07 at 16:41 +, bob schulman wrote:
> Use of this function seems central for server-space use of DRI (as
> this function sets up the DRIScreenPrivKey for use by dixLookupPrivate
> by way of dixSetPrivate()). Yet this func is only called by
> I810DRIScreenInit() which is only call
On Tue, 2010-06-08 at 04:12 -0400, Andrew Lutomirski wrote:
> On my trusty X200s (GM45), I still have such frequent i915 hotplug
> storms that any standard kernel is essentially unusable.
You're not running master, it looks like. I'd be interested to know if
this patch helps:
commit 6e0032f0ae44
On Sat, 2010-06-12 at 23:38 +0800, Li Peng wrote:
> Enable self-refresh on 945 when just one CRTC is activated.
> Otherwise user would get display flicker with dual display.
>
> This fixes https://bugs.freedesktop.org/show_bug.cgi?id=27667
>
> Signed-off-by: Li Peng
Reviewe
On Sat, 2010-06-12 at 09:28 +0100, Chris Wilson wrote:
> On Sat, 12 Jun 2010 14:32:21 +0800, Zhenyu Wang
> wrote:
> > static void
> > -intel_dp_compute_m_n(int bytes_per_pixel,
> > +intel_dp_compute_m_n(int bpp,
> > int nlanes,
> > int pixel_clock,
> >
Unmask the bits for link training reporting before starting link
training. If stage 1 training finished before we unmask them, then we'd
spin around in a loop a few times until smashing on through. Which is
harmless, since training _did_ succeed, it just looks ugly in dmesg.
Signed-off-by:
x27;t define dri1 protocol in any case.
Signed-off-by: Adam Jackson
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 353f942..30bed3e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -330,7 +330,7 @@ fi
# Store the list of s
wngrade this to DRM_DEBUG_KMS so we can still see it
if we want it.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d78d33f.
1.0 device, but the changes make
sense. For the series:
Reviewed-by: Adam Jackson
- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
;Display Range Limits
> & Additional Timing Description Definition (tag #FDh)".
Seems sane.
Reviewed-by: Adam Jackson
- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
since otherwise it's awkward
to look up.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/intel_crt.c | 40 +---
1 file changed, 17 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
ind
On Mon, 2012-03-26 at 21:33 +0200, Daniel Vetter wrote:
> As a first step refuse to load without kms on chips where userspace
> never supported ums. Now upstream hasn't supported ums on ilk, ever.
> But RHEL had the great idea to backport the kms support to their ums
> driver.
In RHEL5, yes. Per
at driver is based on xf86-video-intel version 2.2,
> which is pre-gem.
Reviewed-by: Adam Jackson
- ajax
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.
On 4/10/12 4:35 AM, Chris Wilson wrote:
As part of the PCH split, the ability to control CRT standby/suspend
states was defeatured; the bits are now marked reserved and apparently
have no effect.
Are the intermediate states even tested? I have vague memories of them
not working. I'd be just
ng in mode_fixup failures and
ultimately black screens.
Chris Wilson pointed out that we still get things wrong for bpp > 24,
but that should be fixed in another patch (and it'll be easier because
this patch consolidates the logic).
Certainly an improvement.
Reviewed-by: Adam Jac
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... o
These should have been there since day one.
This series cleans up the few places that touch the DMT list to handle rb
modes correctly, and then imports the modes from xserver's list, along with
a few cosmetic changes.
- ajax
___
Intel-gfx mailing list
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5a18b0d..79a3637 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
No functional change, but will make an upcoming change clearer.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 79a3637..0a23ee5
mode list regrows the r-b modes, but practically speaking EST3
codes don't exist in the wild.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 37 -
drivers/gpu/drm/drm_fb_helper.c |2 +-
include/drm/drm_crtc.h |3 ++
Slightly more honest naming.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4f52103..83c51d6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b
Require that the monitor support rb for rb modes to be added.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 83c51d6..0fc63ca 100644
--- a
Copied from the list in xserver.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid_modes.h | 94 +-
1 files changed, 93 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index a91ffb1
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid_modes.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index 4be9c1a..ab3a051 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b
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, that's a
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/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 a
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 on
On 4/12/12 5:35 PM, Adam Jackson wrote:
@@ -1030,6 +1026,10 @@ drm_dmt_modes_for_range(struct drm_connector *connector,
struct edid *edid,
for (i = 0; i< drm_num_dmt_modes; i++) {
if (mode_in_range(drm_dmt_modes + i, edid, timing)) {
+
1 - 100 of 323 matches
Mail list logo
