's all I can think of at the
moment.
munmap appears to work. However if you do it after the close() you
segfault at at exit. That's probably suboptimal.
From an API perspective this is certainly enough for llvmpipe, and I
can work around munmap being quirky
On 2/8/12 6:19 PM, Ben Widawsky wrote:
Similar to i915, it's nice to be able to query this device uniquely and
get some info
Signed-off-by: Ben Widawsky
So, this is actually not especially useful as written. You'd like to be
able to use this to find the vgem device node, but since it's a
de
On 2/15/12 5:42 PM, Jesse Barnes wrote:
+#define DRM_SET_CONFIG_TEST (1<<0) /* don't change the config, just test it
for validity */
+
+struct drm_mode_set_config {
+ __u64 crtcs;
+ __u64 crtc_fbs;
+ __u64 crtc_xpos; /* array of x coords for crtcs */
+ __u64 crtc_ypos; /
On Wed, 2012-02-15 at 22:43 -0600, Matt Sealey wrote:
> Quick question; if I want to validate a mode given to me by a
> connector/encoder as workable or not before I am going through the
> code to actually set that mode, how would I do this?
I think this is an API bug. The crtc really should get
On 2/16/12 6:25 PM, Laurent Pinchart wrote:
*** Common video mode data structure and EDID parser ***
Goal: Sharing an EDID parser between DRM/KMS, FBDEV and V4L2.
The DRM EDID parser is currently the most advanced implementation and will
be taken as a starting point.
Different su
On Mon, 2012-02-20 at 18:10 +0100, Ben Widawsky wrote:
> On Thu, 16 Feb 2012 05:52:12 -0800 (PST)
> Jakob Bornecrantz wrote:
> > Any reason why you are not using the dumb_bo interface? I at least
> > would like to be able to offer vgem on the vmwgfx device when the
> > host has disabled 3D.
>
> I
On Tue, 2012-02-21 at 15:34 +, Dave Airlie wrote:
> Not sure what you mean there, those 3 APIs are just to create dumb
> unaccelerated objects,
> probably are fine for vgem's use. For scanout we create framebuffer
> objects from a dumb object
> then we do shove it back in from above.
>
> So i
On Wed, 2012-02-22 at 16:03 +, James Simmons wrote:
> Fbcon scrolling at be painful at HD or better modes. Fbcon needs 3
> possible accels; copyarea, imageblit, and fillrect. The first two could be
> hooked from the TTM layer. Its something I plan to experiment to see if
> its worth it.
In
On Wed, 2012-02-22 at 19:08 +0300, Andrew Shadura wrote:
> Checking for just two variants of standard timings for
> 1366x768 isn't quite correct, let's check for ranges
> instead.
I... doubt it? Standard timing descriptors are a tuple of
* width in character cells (ie, 8 pixels)
* one of four as
On Wed, 2012-02-22 at 23:56 +0300, Andrew Shadura wrote:
> Well, my fault, I haven't read the code 10 lines above :) Indeed, that's
> not STD, it's DTD. And I'm not sure how to fix it then, but DTD gives
> 1360x768, and that isn't quite correct.
Yeah, that's a different class of bug, that's the m
On Thu, 2012-02-23 at 12:15 -0800, Linus Torvalds wrote:
> Btw, clearly X does *not* cache the EDID results, at least not for
> this case. So the explicit xrandr example is probably pretty close to
> what wine does. Maybe the proper fix is to just make X.org force
> caching when clients do this (b
On Thu, 2012-03-08 at 15:34 +0100, David Herrmann wrote:
>
> xf86drmMode.h is missing a header protection. xf86drm.h has one so
> just copy it
> and adjust the name.
>
> Signed-off-by: David Herrmann
Applied, thanks.
- ajax
signature.asc
Description: This is a digitally signed message part
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
___
dri-devel 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)) {
+
Incorporates some feedback from Rodrigo and Takashi. Major themes of the
series:
- Fix the DMT list to include reduced-blanking modes
- Add modes from DMT for any range descriptor type
- Add an extra modes list for things not in DMT
- For ranges that specify a formula, generate timings from the e
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 ++
mode_in_range() handles what this was warning about.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4f52103..70dcf7a 100644
--- a/drivers/gpu/drm
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 70dcf7a..355e6a0 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b
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
formula.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 355e6a0..7131f38 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/dr
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
Signed-off-by: Adam Jackson
---
include/drm/drm_edid.h | 26 --
1 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index bcb9a66..8cefbbe 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
Some common sizes that don't show up in DMT.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid_modes.h | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index eab60ea..26a1d33 1
We want the same type for extra modes inferred from ranges.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid_modes.h |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index ab3a051..eab60ea
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 73
1 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7131f38..9e3794d 100644
--- a/drivers/gpu/drm/drm_edid.c
data (by the CEA-EXT extension block).
Signed-off-by: Paulo Zanoni
For the series:
Reviewed-by: Adam Jackson
- ajax
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On 4/13/12 4:33 PM, Adam Jackson wrote:
Incorporates some feedback from Rodrigo and Takashi. Major themes of the
series:
- Fix the DMT list to include reduced-blanking modes
- Add modes from DMT for any range descriptor type
- Add an extra modes list for things not in DMT
- For ranges that
the current mode.
>
> Signed-off-by: Lars-Peter Clausen
> Reviewed-by: Jesse Barnes
Reviewed-by: Adam Jackson
- ajax
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists
On Mon, 2012-04-16 at 12:54 +0400, Anton V. Boyarshinov wrote:
> Hi
>
> > Obviously if we have a dead gpu, we need to break out of this loop. But
> > detecting a dead gpu (and returning an appropriate error like EIO) is the
> > kernel's job.
> In my case gpu isn't really dead. It works after some
com/812890
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 10 +-
include/drm/drm_crtc.h |2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5a18b0d..43aecd8 100644
--- a/drivers/gpu/drm/drm_ed
On Tue, 2012-04-17 at 17:25 +0200, Takashi Iwai wrote:
> At Fri, 13 Apr 2012 16:33:37 -0400, Adam Jackson wrote:
> > + u8 flags;
> > + union {
> > + struct {
> > + u8 reserved;
> > + u8 hfreq_st
On Sun, 2012-04-22 at 11:40 -0500, Ian Pilcher wrote:
> EDID vendor IDs are always 3 characters long (4 with the terminating
> 0). It doesn't make any sense to have a (possibly 8-byte) pointer
> to the ID string in the quirk structure.
>
> Signed-off-by: Ian Pilcher
Revie
On 4/16/12 10:40 AM, Adam Jackson wrote:
Requiring the first byte of the EDID base block header to be 0 means we
don't fix up as many transfer errors as we could. Instead have the
callers specify whether it's meant to be block 0 or not, and
conditionally run header fixup bas
On Thu, 2012-04-26 at 14:48 +0100, Dave Airlie wrote:
> +/*
> + * Our emulated hardware has two sets of memory. One is video RAM and can
> + * simply be used as a linear framebuffer - the other provides mmio access
> + * to the display registers. The latter can also be accessed via IO port
> + * a
iewed-by: Adam Jackson
- ajax
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
/911916
Reviewed-by: Adam Jackson
- ajax
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On 5/2/12 3:24 PM, Dave Airlie wrote:
From: Dave Airlie
We should initialise this to 0 really to avoid getting false positives.
Signed-off-by: Dave Airlie
Reviewed-by: Adam Jackson
- ajax
___
dri-devel mailing list
dri-devel
On 5/2/12 4:20 PM, j.gli...@gmail.com wrote:
+ /* there is small chance that we overwritte a bigger last_emited
+* value, but in normal usage this
+*/
Seems unfinished. Also "overwrite".
- ajax
___
dri-devel mailing list
dri-de
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
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
On Sun, 2012-05-13 at 00:07 +0200, Daniel Vetter wrote:
> The problem left is that the CEA spec specifies these modes with
> timings as they get transmitted, but because the double-clocking is
> just to make the HDMI phy happy, the TV actually drops every 2nd
> pixel. So e.g. a 1440x576 mode in ou
DisplayPort has an escape hatch by which sources and sinks can identify
each other. We would prefer not to notice this, but I suspect we're
going to need to.
Signed-off-by: Adam Jackson
---
include/drm/drm_dp_helper.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --
DisplayPort has an escape hatch by which devices can identify each other.
I'm not super thrilled that it does, since that's just a clever way of
getting the spec to explicitly bless interoperability bugs. But it may
be useful information when debugging link training problems, and there's
a cute tr
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/intel_dp.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4b63791..cc8e1ef 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b
Low four bits are downstream port count. High bit indicates peer OUI
support. OUI matching will allow us to do additional per-sink handling
for things like DP->VGA bandwidth limits or (hopefully) the iMac-as-
display hack.
Signed-off-by: Adam Jackson
---
include/drm/drm_dp_helper.h |
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/radeon/atombios_dp.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index c57d856..9282649 100644
--- a/drivers/gpu/drm
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index d996134..bc50c7d 100644
--- a/drivers/gpu/drm
On 5/14/12 3:43 PM, Paulo Zanoni wrote:
Also, I think flag DRM_MODE_FLAG_DBLCLK does not sound correct for
them, so we would need to create flags:
- DRM_MODE_FLAG_PR_1_to_10
- DRM_MODE_FLAG_PR_1_or_2
- DRM_MODE_FLAG_PR_1_or_2_or_4
Or any other more creative names. And then we should cross our f
On Fri, 2012-05-18 at 14:27 +0200, Sascha Hauer wrote:
> + edid = [00 ff ff ff ff ff ff 00 4c 2d 6c 03 36 32 49 4b
> + 0f 13 01 03 80 37 22 a0 2a fe 21 a8 53 37 ae 24
> + 11 50 54
> +
> + /* est
On Mon, 2012-05-14 at 16:05 -0400, Adam Jackson wrote:
> DisplayPort has an escape hatch by which devices can identify each other.
> I'm not super thrilled that it does, since that's just a clever way of
> getting the spec to explicitly bless interoperability bugs. But
On Mon, 2012-05-21 at 15:27 -0400, Alex Deucher wrote:
> I'm pretty sure it's needed for looking up the display topology for
> things like DP 1.2 MST. We probably need to decide on some changes to
> the DRM KMS topology to deal with multiple displays being driven from
> a single connector (sub-co
On Mon, 2012-05-21 at 16:35 -0400, Alex Deucher wrote:
> On Mon, May 21, 2012 at 4:11 PM, Adam Jackson wrote:
> > I had been considering MST to be multiple CRTCs and some quasi-virtual
> > connectors. Does that not match the hardware?
>
> That's the basic idea.
Entirely new class of fail for this one. The detailed timings are for
normal CVT but the monitor really wanted CVT-R.
Bugzilla: http://bugzilla.redhat/com/516471
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 22 ++
1 files changed, 18 insertions(+), 4
On 5/24/12 3:26 PM, Daniel Vetter wrote:
Instead of reusing the polling code for hdp handling, split them up.
This has a few consequences:
- Don't touch HDP capable connectors in the poll loop.
- Only touch HDP capable connectors in drm_helper_hpd_irq_event.
- Run the HDP handling directly instea
On Mon, 2012-05-28 at 08:06 +0100, Chris Wilson wrote:
> No, the i915_error_state had everything I needed to see. It is the old
> ddx bug that was hardcoding a maximum relocation address that never
> corresponded with an actual hw limit. As soon we try to use memory above
> that value, the GPU dec
On Wed, 2012-05-23 at 16:26 -0400, Adam Jackson wrote:
> Entirely new class of fail for this one. The detailed timings are for
> normal CVT but the monitor really wanted CVT-R.
>
> Bugzilla: http://bugzilla.redhat/com/516471
> Signed-off-by: Adam Jackson
Bump.
- ajax
On 5/30/12 8:05 AM, Sean Paul wrote:
Yes, definitely. The reason I can't set it via xrandr (easily) is
because we look for lvds downclock modes (in i915) on the driver init.
Since the driver initializes way before we have a chance to add a new
mode via xrandr, the driver won't have a downclock m
6 bytes seems to be a reasonable default so far, but for the desperate
it's worth exposing this.
Bugzilla: https://bugzilla.redhat.com/582559
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/driver
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |9 +
include/drm/drm_crtc.h |4
2 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c3b5139..c278f2d 100644
--- a/drivers/gpu/drm
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c|2 --
drivers/gpu/drm/gma500/cdv_intel_lvds.c |8
drivers/gpu/drm/gma500/mdfld_dsi_output.c |5 -
drivers/gpu/drm/gma500/psb_intel_lvds.c |9 -
drivers/gpu/drm/i915/intel_lvds.c
% size drivers/gpu/drm/drm.o*
textdata bss dec hex filename
1873718299 336 196006 2fda6 drivers/gpu/drm/drm.o
1912518299 336 199886 30cce drivers/gpu/drm/drm.o.orig
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_crtc.c|3
Either bit 5 or 6 of that byte may be set in a stereo mode.
E-EDID v1.4, Table 3.22
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |5 +++--
include/drm/drm_edid.h |2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers
For readability, since this is about to get more complicated.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 15 +++
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e7547e3..be21040 100644
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_crtc.c|2 +-
drivers/gpu/drm/drm_crtc_helper.c |5 +
drivers/gpu/drm/drm_edid.c| 29 +
include/drm/drm_crtc.h|2 ++
include/drm/drm_edid.h| 15 ++---
On Sat, 2012-06-09 at 00:24 +0100, Chris Wilson wrote:
> A detect() probe may return 'unknown' to indicate that it was not able
> to successfully determine the connector status. However, exposing this
> to userspace just results in lots of confusion as it is uncertain
> whether or not that is a val
On 6/19/12 5:33 AM, Daniel Vetter wrote:
We need to initialize this to false, because the is_rb callback only
ever sets it to true.
Noticed while reading through the code.
Cc: Adam Jackson
Cc: sta...@vger.kernel.org
Signed-Off-by: Daniel Vetter
Reviewed-by: Adam Jackson
- ajax
Only fill it in for pre-1.1 monitors - when GTF hadn't yet been defined
- or for EDID 1.4's explicit "just a range, not a timing formula" case.
Bugzilla: https://bugs.freedesktop.org/51146
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 14 +-
On Tue, 2012-06-19 at 11:33 +0200, Daniel Vetter wrote:
> We need to initialize this to false, because the is_rb callback only
> ever sets it to true.
>
> Noticed while reading through the code.
>
> Cc: Adam Jackson
> Cc: sta...@vger.kernel.org
> Signed-Off-by: Daniel Ve
On Tue, 2012-06-19 at 14:55 -0400, Adam Jackson wrote:
> Only fill it in for pre-1.1 monitors - when GTF hadn't yet been defined
> - or for EDID 1.4's explicit "just a range, not a timing formula" case.
>
> Bugzilla: https://bugs.freedesktop.org/51146
> Signed-
This is a start at pushing down the locking a bit further. Ideally
things like i2c shouldn't affect pageflipping. I've made some attempt
to only take read locks where possible, but there's certainly more work
to be done.
Signed-off-by: Adam Jackson
---
drivers/gpu/dr
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5873e48..4a3e61a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
This fixes the extra_mode walk to be much more conservative. I still think
the whole idea is bogus and that guessing about clone mode sizes is a
userspace policy decision, but apparently xrandr --newmode / --addmode is
unreasonably burdensome.
This should fix a number of reported regressions, ple
Essentially, only do this on digital displays. It's almost certainly
not wise to add them on CRTs, but we can't tell CRT from LCD before EDID
1.4, so just use digital as a proxy for that.
Bugzilla: https://bugs.freedesktop.org/51146
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/
On Mon, 2012-06-25 at 19:14 +0200, Sven Joachim wrote:
> On 2012-06-25 17:25 +0200, Adam Jackson wrote:
>
> > This fixes the extra_mode walk to be much more conservative. I still think
> > the whole idea is bogus and that guessing about clone mode sizes is a
> > usersp
On Mon, 2012-06-25 at 19:40 +0200, Sven Joachim wrote:
> > And, does the patch below help?
>
> Somewhat: at least I get 1280x1024 again, but at 60 rather than 75 Hz.
That is, in fact, what your monitor claims to prefer.
> The xrandr command shows various bogus modes.
Most of which my patch ser
to known issues.
^
Patch says ServerWorks. SE is Emulex, SW is Broadcom.
Seems a little like core PCIE functionality, but apparently we're the
first ones to want it so we can refactor later.
For the series:
Reviewed-by: Adam Jackson
- ajax
signature.asc
Description: This is a digitally
On Wed, 2012-06-27 at 09:48 -0700, Jesse Barnes wrote:
> The other thing I'm worried about with atomic mode setting is handling
> the legacy case properly. We'll still need to handle apps that want to
> change one CRTC at a time without altering the state of other CRTCs.
Fortunately that's not t
ion of
inferred modes by checking not to be greater than other modes.
Also, it checks the duplicated mode entry at the same time.
This is a little aggressive on CRTs, but whatever, better than what's there.
Reviewed-by: Adam Jackson
- ajax
___
dri-de
On 7/19/12 11:54 AM, Carsten Emde wrote:
A description was lacking how to write an EDID firmware file that
corresponds to a given X11 setting.
Signed-off-by: Carsten Emde
Reviewed-by: Adam Jackson
- ajax
___
dri-devel mailing list
dri-devel
On 7/30/12 1:05 PM, James Bottomley wrote:
Lenovo X220i
The display device is
00:02.0 VGA compatible controller: Intel Corporation
82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03)
(prog-if 00 [VGA controller])
Subsystem: Giga-byte Technology Device 2562
F
;Display Range Limits
> & Additional Timing Description Definition (tag #FDh)".
Seems sane.
Reviewed-by: Adam Jackson
- ajax
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
or incorrect hsync/vsync pluse widths, print these
> messages only when KMS debugging is enabled.
Oof, yes, a thousand times yes, how were we still doing this.
Reviewed-by: Adam Jackson
- ajax
signature.asc
Description: This is a digitally sign
At least on an IBM Power 720, this check passes, but several piglit
tests will reliably trigger GPU resets due to the ring buffer pointers
not being updated. There's probably a better way to limit this to just
affected machines though.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/r
On Mon, 2013-06-17 at 11:04 -0400, Alex Deucher wrote:
> On Mon, Jun 17, 2013 at 10:06 AM, Adam Jackson wrote:
> > At least on an IBM Power 720, this check passes, but several piglit
> > tests will reliably trigger GPU resets due to the ring buffer pointers
> > not be
On Tue, 2013-07-23 at 15:46 +1000, Dave Airlie wrote:
> On Wed, Jul 17, 2013 at 11:07 PM, Egbert Eich wrote:
> > Matrox hardware only supports modes whose horizontal parameters are
> > multiples of 8. This rules out a mode like 1366x768 for example.
> >
> > Signed-off-by: Egbert Eich
>
> I'd lik
101 - 200 of 432 matches
Mail list logo
