So much broken hardware, so few bullets.
Signed-off-by: Adam Jackson a...@redhat.com
---
Documentation/kernel-parameters.txt |3 +++
drivers/gpu/drm/drm_edid.c | 12 ++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b
On Tue, 2010-04-27 at 15:01 +1000, Dave Airlie wrote:
On Tue, Apr 27, 2010 at 5:03 AM, Adam Jackson a...@redhat.com wrote:
Signed-off-by: Adam Jackson a...@redhat.com
not sure about the kernel-parameters additions, since the option would
be drm.edid_threshhold= and its a module option
On Tue, 2010-04-27 at 10:47 -0400, Alex Deucher wrote:
On Tue, Apr 27, 2010 at 10:30 AM, Adam Jackson a...@redhat.com wrote:
That's a valid point though: we currently don't distinguish between
connected but with broken EDID and disconnected. I think it sounds
reasonable to treat the former
Switches will try to update the topology address and not correctly fix
up the checksum, so just let it slide.
https://bugs.freedesktop.org/28229
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git
On Wed, 2010-06-16 at 07:39 -0400, Andrew Lutomirski wrote:
[resend to correct dri-devel address]
Hi all-
Just a friendly regression reminder: a recent patch intended to fix
the long-standing hotplug storm bugs in i915 instead made it a good
deal worse -- I now get hotplug interrupts
We're adjusting horizontal timings only here, moving vsync was just a
slavish translation of a typo in the X server.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b
Some cosmetic cleanups, and then some changes to add more modes than we
were before. 6 and 7 are the particularly touchy bits; I'd like a bit of
volunteer testing before landing it on drm-core-next, particularly on
HDMI monitors. Note that this is mostly about doing more with things
other than
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 15 ---
include/drm/drm_crtc.h | 35 +--
2 files changed, 1 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 38 +-
include/drm/drm_edid.h |6 ++
2 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e668084
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1bc15a8..9299dd6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers
Also fix up mode generation to only add RB modes from DMT if it looks
like an RB-capable monitor.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 43 +
drivers/gpu/drm/drm_edid_modes.h | 98 --
drivers/gpu
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 188 +++-
drivers/gpu/drm/drm_edid_modes.h | 260 ++
2 files changed, 389 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b
On Thu, 2010-08-05 at 12:16 -0400, Matt Turner wrote:
Hi,
I've hit a snag and I'm not really sure how to debug it.
Both xf86-video-glint/src/pm3_dac.c:Permedia3Init and
kernel/drivers/video/pm3fb.c:pm3fb_write_mode set the mode in
virtually identical ways. I'm trying to do the same, but I
On Wed, 2010-08-11 at 01:16 +0200, Andrei Paskevich wrote:
Currently, the LVDS connector on i915-equipped laptops
is always reported as connected, regardless of the lid
state and presence of external monitors. This was done
because of too many BIOSes reporting lid status in
an unreliable
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16651
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_modes.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index f1f473e..949326d
On Mon, 2010-08-23 at 10:19 -0400, Adam Jackson wrote:
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16651
Signed-off-by: Adam Jackson a...@redhat.com
Tested-by: Adam Serbinski a...@serbinksi.com
- ajax
signature.asc
Description: This is a digitally signed message part
Wang zhen...@linux.intel.com
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
.
This fixed incorrect probe for DP monitor's audio. Fengguang helped
to test this set. We got correct DP sound on Eizo EV2333W, and HDMI
audio also worked with no regression found.
Patch is against Chris's drm-intel-next branch.
Ignore my previous r-b.
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
On Tue, 2010-09-21 at 23:02 +0100, Sam Tygier wrote:
Currently an invalid EDID extension will cause the whole EDID to be
considered invalid. Instead just drop the extension, and return the
valid base block. The base block is modified to not claim to have
extensions, and update the checksum.
absolutely disclaim any
responsibility for any security bugs that result from someone shooting
themselves in the foot with this. But, that said:
Regretted-by: Adam Jackson a...@redhat.com
- ajax
signature.asc
Description: This is a digitally signed message part
.
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
, to allow for it.
Signed-off-by: Jesse Barnesjbar...@virtuousgeek.org
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
--
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing
On 4/15/11 2:40 PM, Jesse Barnes wrote:
@@ -1461,6 +1462,15 @@ static void drm_add_display_info(struct edid *edid,
info-bpp = 0;
break;
}
+
+ if (edid-features DRM_EDID_FEATURE_RGB)
+ info-color_formats = DRM_COLOR_FORMAT_RGB444;
+
On 4/15/11 3:19 PM, Jesse Barnes wrote:
Or is there a CEA block extension that allows for more granularity?
CEA has bits for the two YCbCr formats too, which we should also parse
since there's plenty of 1.3+CEA blocks in the world thanks to HDMI. For
CEA blocks version 2 and up (version
places where the
DPCD block was read from the device. Now everyone shares the same
function, and that function retries the reads.
Reviewed-by: Adam Jackson a...@redhat.com
[PATCH 4/5] drm/i915: Delay 250ms before running the hotplug code
I was experimenting with DP hotplugging -- moving
This was just confusing. -polled just means which directions you want
to poll for changes, regardless of whether you can get HPD interrupts
for them.
Signed-off-by: Adam Jackson a...@redhat.com
---
Kind of an RFC patch, and I've not tested it yet, but it certainly makes
more sense to read
behind
DRM_DEBUG_KMS, they're too chatty for normal dmesg.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7425e5c..a15f10b 100644
On Wed, 2011-09-21 at 11:29 -0400, Alex Deucher wrote:
On Wed, Sep 21, 2011 at 10:12 AM, Adam Jackson a...@redhat.com wrote:
If hardware does require composite sync for a mode, it's out of luck
with current drivers, since none support that. Just skip the mode
instead, there'll be others
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_crtc_helper.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index f88a9b2..f236644 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
On 11/2/11 2:20 AM, Keith Packard wrote:
+ if (intel_dp-link_configuration [1]
DP_LANE_COUNT_ENHANCED_FRAME_EN)
+ intel_dp-DP |= DP_ENHANCED_FRAMING;
+
+ /*
+* Check for DPCD version 1.1 and enhanced framing support
+
On 11/2/11 12:20 PM, Jesse Barnes wrote:
@@ -766,10 +766,10 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct
drm_display_mode *mode,
continue;
intel_dp = enc_to_intel_dp(encoder);
- if (intel_dp-base.type == INTEL_OUTPUT_DISPLAYPORT) {
+
On 11/2/11 1:31 PM, Keith Packard wrote:
On Wed, 02 Nov 2011 13:13:52 -0400, Adam Jacksona...@redhat.com wrote:
Given the choice of trusting DPCD or the VBT, I'd definitely prefer
DPCD.
Except that the DPCD is coded into the monitor while the VBT is done by
the platform. And, it's the
.
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
.
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
. The mode list was indeed mechanically
generated (pdf2text on the spec and then some python to bash it all
together). It's probably worth noting in the comment that it's from
CEA-861-D, as I suspect subsequent revisions have added more timings (I
haven't bought it yet to check).
Reviewed-by: Adam
. For the series:
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On 11/17/11 9:13 PM, Keith Packard wrote:
On Thu, 17 Nov 2011 17:45:40 -0500, Adam Jacksona...@redhat.com wrote:
Your silicon people worry me.
In any case, the changes are mostly to move bits around so that there
are two bits for pipe select
Yeah, the patch looks like it could be correct,
On Sat, 2011-12-03 at 19:35 +0200, Kirill A. Shutemov wrote:
Hi,
Commit dc22ee6 introduces regression on my laptop HP EliteBook 8440p. I see
nothing on the panel after mode setting. Reverting the commit fixes the issue.
Try this patch (might need rediffing):
On 12/5/11 3:39 PM, Alexander Beregalov wrote:
At boot time:
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 206
Raw EDID:
27 0f 01 03 80 26 1e 78 2a de 95 a3 54 4c 99 26
0f 50 54 bf ef 80 81 80 81 40 71 4f 01 01 01 01
01 01 01 01 01 01 30
There's no reason to force the first byte to be correct if we're already
scoring how correct the header is.
See also: https://bugzilla.redhat.com/show_bug.cgi?id=722909
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 18 --
1 files changed, 8
On Fri, 2011-12-09 at 11:46 +, Kavuri, Sateesh wrote:
+ if ((multi_val == STRUCTURE_PRESENT) ||
+ (multi_val == STRUCTURE_MASK_PRESENT) ) {
+ if ((edid_ext[i+15+hdmi_vic_len] 0x01) ==
0x01)
+
On Wed, 2011-12-14 at 13:04 +, Kavuri, Sateesh wrote:
+ /* Data block offset in CEA extension block */
+ start_offset = 4;
+ end_offset = edid_ext[2];
+
+ /* 3D vars */
+ int multi_present = 0;
Pretty sure kernel style frowns upon mixed decls and code.
+ /*
+
drm_helper_connector_dpms helper directly), that this happens
at bootup. This solves an issue with connectors not getting
enabled from fbcon_init() when the driver is loaded.
Signed-off-by: Rob Clark r...@ti.com
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
signature.asc
Description: This is a digitally signed
On Mon, 2011-12-19 at 18:19 +0100, Boszormenyi Zoltan wrote:
Thanks.
Is this setting permanent after reboot and applies to GDM, too?
It's stored in the session, so if there's not a Make system default
button in the UI, then no it won't affect gdm.
- ajax
signature.asc
Description: This is a
On Mon, 2011-12-19 at 18:56 +0100, Boszormenyi Zoltan wrote:
Thanks. As I am logged in as my user, there's no such button.
How can I set it as the system default? It was a long time ago
when GNOME allowed a root login.
Ideally, gnome would implement that button.
Failing that you can set
On 12/7/11 6:26 PM, Adam Jackson wrote:
There's no reason to force the first byte to be correct if we're already
scoring how correct the header is.
Don't use this. The 00 check is needed to make sure we only attempt the
header fixup on the zeroth block (not extensions).
- ajax
On 12/20/11 1:38 PM, Harald Judt wrote:
Hi,
When using more than one monitor, the card uses higher clocks than in
single-monitor mode and low-power profile. As a subjectively negative
side-effect, the fan on the card starts making more noise. Other cards I
used before had no problem with
(DMI_SYS_VENDOR, ASUSTeK Computer INC.),
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman
On Wed, 2012-01-04 at 14:08 -0500, Marc Gariépy wrote:
Hello,
I've been directed here by Stephane Graber. I need to blacklist the
LVDS port on some hp t5745 thin client.
Here is the bug link:
https://bugs.launchpad.net/bugs/911916
Does this actually work? The bug above doesn't include
or
any glaring bugs. Eventually I'd like to see solutions for sharing gem
objects between drm devices and/or the dma_buf API, but that's a ways
down the road.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/Kconfig |8 ++
drivers/gpu/drm/Makefile|1 +
drivers
On Wed, 2012-01-11 at 12:16 -0800, Eric Anholt wrote:
I remember at one point you had a plan along the lines of passing shmem
fds across the protocol. I'm curious what happened to that -- too hard
to get the passing to work, or something else? I'm just thinking of
kernel developer grumbling
On Tue, 2012-01-17 at 17:31 +0100, Daniel Vetter wrote:
On Wed, Jan 04, 2012 at 05:50:36PM -0500, Marc Gariépy wrote:
Sorry for the mistake, i made a typo when correcting the indentation issue
i had.
here is the correct patch and also the dmidecode from the thin client.
Signed-Off-by is
On 1/30/12 9:24 AM, Elvis L. wrote:
Hello
first of all, please excuse my possibly bad english. Im German.
I wanted to install DRI-supported drivers for my Savage4 graphic-chip
(Acer Aspire 1310XC Laptop). I found some in
http://dri.freedesktop.org/snapshots/ and read, that I have to
./install
On 2/3/12 4:37 AM, Dave Airlie wrote:
On Fri, Jan 27, 2012 at 9:40 PM, Daniel Vetterdaniel.vet...@ffwll.ch wrote:
CEA actually specifies an interlaced mode with even vtotal and
supplies a diagram showing how this is supposed to work.
Note that interlaced modes with an even vtotal seem to be a
On 2/7/12 6:28 PM, Ben Widawsky wrote:
On Wed, Jan 11, 2012 at 04:04:20PM -0500, Adam Jackson wrote:
If you can, I recommend using the intel gtt mapping type of mmap ioctl,
where it gives you back an offset that you use the mmap syscall on, and
implement the vgem_gem_fault to map its pages
If a CRT doesn't deign to provide a preferred mode, we should try to
pick a mode with a vaguely reasonable DPI instead of whatever happens to
be biggest.
Bugzilla: https://bugzilla.redhat.com/522155
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 52
.
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 for now.
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
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 Widawskyb...@bwidawsk.net
So, this is actually not especially useful as written. You'd like to be
able to use this to find the vgem device node,
On 2/15/12 5:42 PM, Jesse Barnes wrote:
+#define DRM_SET_CONFIG_TEST (10) /* 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 a
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
On Mon, 2012-02-20 at 18:10 +0100, Ben Widawsky wrote:
On Thu, 16 Feb 2012 05:52:12 -0800 (PST)
Jakob Bornecrantz ja...@vmware.com 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
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 if the
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 my
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
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
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
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 dh.herrm...@googlemail.com
Applied, thanks.
- ajax
signature.asc
Description: This is a digitally
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 Jackson a...@redhat.com
- ajax
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...
list regrows the r-b modes, but practically speaking EST3
codes don't exist in the wild.
Signed-off-by: Adam Jackson a...@redhat.com
---
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 a...@redhat.com
---
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
Require that the monitor support rb for rb modes to be added.
Signed-off-by: Adam Jackson a...@redhat.com
---
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
Copied from the list in xserver.
Signed-off-by: Adam Jackson a...@redhat.com
---
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
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
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
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 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
Signed-off-by: Adam Jackson a...@redhat.com
---
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
No functional change, but will make an upcoming change clearer.
Signed-off-by: Adam Jackson a...@redhat.com
---
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
list regrows the r-b modes, but practically speaking EST3
codes don't exist in the wild.
Signed-off-by: Adam Jackson a...@redhat.com
---
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 a...@redhat.com
---
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
Slightly more honest naming.
Signed-off-by: Adam Jackson a...@redhat.com
---
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
Copied from the list in xserver.
Signed-off-by: Adam Jackson a...@redhat.com
---
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
-by: Adam Jackson a...@redhat.com
---
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/drm_edid.c
Signed-off-by: Adam Jackson a...@redhat.com
---
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
Signed-off-by: Adam Jackson a...@redhat.com
---
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
Some common sizes that don't show up in DMT.
Signed-off-by: Adam Jackson a...@redhat.com
---
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
We want the same type for extra modes inferred from ranges.
Signed-off-by: Adam Jackson a...@redhat.com
---
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
Signed-off-by: Adam Jackson a...@redhat.com
---
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
are also
used in the EDID data (by the CEA-EXT extension block).
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
For the series:
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
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
.
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
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 ioctl
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_start_khz; /* need to multiply by 2 */
+ u8 c
-by: Adam Jackson a...@redhat.com
- ajax
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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 based
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
+ *
=d350d97d196a632b6c7493acf07a061017fc6f7d
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
1 - 100 of 405 matches
Mail list logo
