only UMS driver using this is i810, which needs it
even with DRI disabled. I have difficulty caring though.
In related news, since i810 is only ever attached to 32-bit x86 we
could disable the frontend unconditionally on amd64 (and everything
else tbh).
Acked-by:
On Wed, 2019-01-16 at 20:35 +0200, Pekka Paalanen wrote:
> I would agree with an effort to establish a userspace EDID parsing
> library in any case. As mentioned above, there will probably be too
> much to expose via kernel UABI, or it will become just another
> encoded format that again should ha
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 Mon, 2019-03-04 at 17:47 +0200, Jani Nikula wrote:
> On Mon, 04 Mar 2019, Maxime Ripard wrote:
> > In some cases, in order to accomodate with displays with poor EDIDs, we
> > need to ignore that the monitor alledgedly supports audio output and
> > disable the audio output.
>
> *sad trombone*
>
On Tue, 2019-03-05 at 09:08 +0100, Maxime Ripard wrote:
> Chances are that they would stop at 1, call the device trash and never
> submit any quirk, therefore making the quirk approach useless in the
> process.
But the device _is_ trash. It's not like writing an accurate EDID is
difficult, if you
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
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, 2019-03-26 at 10:17 +0100, Thomas Zimmermann wrote:
> +static bool is_generic_driver(const struct fb_info *fb_info)
> +{
> + /* DRM porting note: We don't want to bind to vga16fb, vesafb, or any
> + * other generic fbdev driver. Usually, these drivers have limited
> + * capab
On Wed, 2019-04-03 at 09:23 +0200, Gerd Hoffmann wrote:
> - Only DRM_FORMAT_RGB565 (depth 16) is supported. The old driver does
>that too by default. There was a module parameter which enables 24/32
>bpp support and disables higher resolutions (due to cirrus hardware
>constrains).
On Wed, 2019-04-03 at 16:15 +0100, Daniel Stone wrote:
> There's already a list of supported formats for each DRM plane, which
> you can get via drmModeGetPlane (being careful to enable universal
> planes so you can discover the primary plane). The same information is
> present in the 'IN_FORMATS'
On Thu, 2019-07-18 at 14:41 -0700, Matthias Kaehlcke wrote:
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 045b1b13fd0e..e49402ebd56f 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw
On Tue, 2019-07-23 at 15:37 +0200, Linus Walleij wrote:
> Migrating the TI nspire calculators to use the PL111 driver for
> framebuffer requires grayscale support for the elder panel
> which uses 8bit grayscale only.
>
> DRM does not support 8bit grayscale framebuffers in memory,
> but by defining
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
1<<31 is undefined because it's a signed int and C is terrible.
Reviewed-by: Eric Engestrom
---
include/uapi/drm/drm_fourcc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 3feeaa3f987a..c06d34559fab 100644
1<<31 is undefined because it's a signed int and C is terrible.
Reviewed-by: Eric Engestrom
Signed-off-by: Adam Jackson
---
include/uapi/drm/drm_fourcc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fou
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
__
On Wed, 2020-03-11 at 12:31 -0500, Jason Ekstrand wrote:
> - X11: With present, it has these "explicit" fence objects but
> they're always a shmfence which lets the X server and client do a
> userspace CPU-side hand-off without going over the socket (and
> round-tripping through the kernel). How
care about
the generated errno value beyond feeding it into strerror() so that
should also be safe.
Looks good otherwise, and these are definitely more reasonable
semantics. Thanks for taking this on!
Reviewed-by: Adam Jackson
- ajax
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, 2020-03-17 at 10:12 -0700, Jacob Lifshay wrote:
> One related issue with explicit sync using sync_file is that combined
> CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
> rendering in userspace (like llvmpipe but for Vulkan and with extra
> instructions for GPU tasks) but nee
gt; gtk/mutter/gnomeshell
> efl/enlightment
>
> Cc: Adam Jackson
> Suggested-by: Adam Jackson
> Signed-off-by: Emil Velikov
Delightful! Series is:
Reviewed-by: Adam Jackson
- ajax
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, 2019-09-13 at 04:21 +, zhangn1...@outlook.com wrote:
> Dear developers
>
> I have a Samsung 40’ HDMI TV, which has wrong EDID.
>
> The actaul size of this TV is 40’ (88cm*49cm), but in EDID the size
> is 49’ (106*63cm)
>
> Thus makes image size is larger than screen, both in conso
ore I don't think this changes
> anything for us, we've already peer-enforced respectful and
> constructive interactions since a long time. But it's good to document
> things properly.
>
> v2: Drop confusing note from commit message and clarify the grammer
> (Ch
sible sort order for bus types, so let's at least make it less of a
trap for the caller.
Invert its boolean sense to be 'true if equal', rename it to describe
the type it actually operates on, and export.
Signed-off-by: Adam Jackson
---
xf86drm.c | 18 +-
xf8
AC_HEADER_MAJOR only defines MAJOR_IN_SYSMACROS if major() is _not_
defined by alone. It is, but it warns, and that's ugly.
To fix this, push -Werror into CFLAGS when invoking AC_HEADER_MAJOR so
the warning makes the compilation test fail.
Signed-off-by: Adam Jackson
---
configure.a
On Fri, 2020-04-03 at 15:24 +0300, Pekka Paalanen wrote:
> On Fri, 03 Apr 2020 10:15:21 + Simon Ser wrote:
>
> > Additionally, I've heard Pekka saying that it would be nice to have
> > constants
> > for property names in the UAPI headers. Indeed, this would prevent
> > hard-to-debug typo iss
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
t;
> Or as ajax put it on irc:
> "< ajax> the point of the "pick a timing formula" heuristic was to
> generate something the sink could _likely_ sink. if it tells us
> timings it can sink explicitly then second-guessing seems dumb."
>
> Cc: Adam Jackson
> Signed-off-by: Ville Syrjälä
Reviewed-by: Adam Jackson
- ajax
1.0 device, but the changes make
sense. 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 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
On Fri, 2018-07-06 at 11:12 +0200, Gerd Hoffmann wrote:
> cirrus can handle 1024x768 (and slightly higher) with 24bpp depth.
> cirrus can handle up to 800x600 with 32bpp.
16bpp is maybe a better choice? Nobody's using cirrus because they care
about color fidelity and it'll use less CPU to update.
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 {
> +
ith 16bpp.
>
> Also use the default depth for the framebuffer console and
> mode_info->preferred_depth.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Adam Jackson
- ajax
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Sep 6, 2023 at 5:57 AM Sarah Walker wrote:
>
> + *:BYPASS_CACHE: There are very few situations where this flag is
> useful.
> + * By default, the device flushes its memory caches after every job.
>
Presumably BYPASS_CACHE does something other than "after every job". Is
that "ne
"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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
the moment.
The series as is is clearly better than what we've got. I still think
there's something fundamentally amiss with a display that doesn't want
to accept InfoFrames, but without having it in hand to mess with - and
without wanting to play telephone to figure it out - I'm fine with this.
Reviewed-by: Adam Jackson
- ajax
On 10/19/12 1:43 PM, Lucas Kannebley Tavares wrote:
> The radeon driver does speed cap detection on the root PCI device for
> the maximum speed with which the adapter can communicate. On ppc64
> systems, however, the root device belongs to the Hypervisor, so the
> current code would case a null poi
On 10/27/12 9:52 AM, Daniel Vetter wrote:
> Userspace seems to like this, see
>
> commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
> Author: Adam Jackson
> Date: Fri Jul 16 14:46:29 2010 -0400
>
> drm/i915: Initialize LVDS and eDP outputs before anything else
>
>
On 10/27/12 9:52 AM, Daniel Vetter wrote:
> This essentially reverts
>
> commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
> Author: Adam Jackson
> Date: Fri Jul 16 14:46:29 2010 -0400
>
> drm/i915: Initialize LVDS and eDP outputs before anything else
>
> simply b
On 9/3/12 11:54 AM, Shirish S wrote:
> Hello Dave,
>
> My patch-set for adding support for 4 block EDID is now reviewed and ready.
> Please let me know if you want any further clarification
I assume you have actual displays with that many EDID extensions. Can
you send a sample of the complete ED
On Thu, 2012-09-06 at 17:41 +0300, Meelis Roos wrote:
> [drm] radeon defaulting to kernel modesetting.
> [drm] radeon kernel modesetting enabled.
> PCI: Enabling device: (:02:02.0), cmd 82
> [drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1002:0x0908).
> [drm] register mmio base:
On 9/8/12 6:35 AM, Dave Airlie wrote:
> On Sat, Sep 8, 2012 at 3:30 AM, Shirish S wrote:
>> Hi Dave,
>> Gentle Reminder!
>> This patch is required for passing the very first test case of HDMI
>> Compliance test suite.
>> Regards,
>> Shirish S
>
> Can you provide ajax with the sample he asked for p
.
Signed-off-by: Jerome Glisse
I guess. I don't see why we don't just move it into DRM_DEBUG_KMS if
we're going to suppress it, but this does what it says on the box.
Reviewed-by: Adam Jackson
- ajax
___
dri-devel mailing
wrong here. If
DISABLE_AUDIO is sufficient for one driver it should be sufficient for all.
For the rest (though I have some complaints that aren't enough to
justify saying no):
Reviewed-by: Adam Jackson
Paul's FORCE_REDUCED_BLANKING series makes me nervous about what those
On 8/27/12 4:34 PM, Alex Deucher wrote:
On Mon, Aug 27, 2012 at 4:24 PM, Adam Jackson wrote:
Paul's FORCE_REDUCED_BLANKING series makes me nervous about what those
monitors will do over VGA, since from a conversation we had on IRC he hasn't
been able to test that.
I asked the clo
On 8/28/12 7:33 PM, Ian Pilcher wrote:
On 08/27/2012 03:24 PM, Adam Jackson wrote:
https://patchwork.kernel.org/patch/1310091/ - nak, the commit message
itself gives away that we're doing else something wrong here. If
DISABLE_AUDIO is sufficient for one driver it should be sufficient fo
On 8/29/12 3:53 PM, Ian Pilcher wrote:
Thinking a bit more about this, I'm starting to rethink my assertion
that the Intel driver is at fault here. On one hand, it doesn't make
any sense to send audio InfoFrames to a non-HDMI display. (BTW, I'm
assuming that a display with a DisplayPort port w
On 8/30/12 3:44 AM, Daniel Vetter wrote:
Some monitors totally don't like to receive infoframes, and naturally
don't claim to support hdmi.
But for some odd reason they've added a CEA block to their edid,
which automatically gives you basic audio. Still, we may not send
out hdmi infoframes to th
On 6/6/12 3:07 PM, Adam Jackson wrote:
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
Anyone want to give this series some love?
- ajax
___
dri-devel mailing list
dri-devel
On 9/3/12 11:54 AM, Shirish S wrote:
Hello Dave,
My patch-set for adding support for 4 block EDID is now reviewed and ready.
Please let me know if you want any further clarification
I assume you have actual displays with that many EDID extensions. Can
you send a sample of the complete EDID b
On Thu, 2012-09-06 at 17:41 +0300, Meelis Roos wrote:
> [drm] radeon defaulting to kernel modesetting.
> [drm] radeon kernel modesetting enabled.
> PCI: Enabling device: (:02:02.0), cmd 82
> [drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1002:0x0908).
> [drm] register mmio base:
On 9/8/12 6:35 AM, Dave Airlie wrote:
On Sat, Sep 8, 2012 at 3:30 AM, Shirish S wrote:
Hi Dave,
Gentle Reminder!
This patch is required for passing the very first test case of HDMI
Compliance test suite.
Regards,
Shirish S
Can you provide ajax with the sample he asked for previously?
He did
Tested-by: Takashi Iwai
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c |3 ++-
include/drm/drm_crtc.h |1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b7ee230..a1895ba 100644
--- a/drivers
Sources: DP, eDP, and DP interop specs, and a VESA slideshow about DP
1.2 for the MST bits.
Tested-by: Takashi Iwai
Signed-off-by: Adam Jackson
---
include/drm/drm_dp_helper.h | 60 ---
1 files changed, 56 insertions(+), 4 deletions(-)
diff --git a
v2: Fix parenthesis mismatch, spotted by Jani Nikula
Tested-by: Takashi Iwai
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/intel_dp.c | 25 -
1 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915
ad of something unrelated to sink status.
Tested-by: Takashi Iwai
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/intel_dp.c | 35 ++-
1 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/i
On Tue, 2012-09-18 at 10:58 -0400, Adam Jackson wrote:
> If there's no downstream device, DPCD success is good enough. If
> there's a hotplug-capable downstream device, count the number of
> connected sinks in DP_SINK_STATUS and return success if it's non-zero.
> Othe
On 9/20/12 10:10 AM, Paulo Zanoni wrote:
2012/9/18 Adam Jackson :
Sources: DP, eDP, and DP interop specs, and a VESA slideshow about DP
1.2 for the MST bits.
All I needed to review every bit was DP spec version 1.2.
Lucky you! I don't have a copy.
+#define DP_SINK_
Note with a comment anything newer than DP 1.1a.
Obviously this needs some work still...
Signed-off-by: Adam Jackson
---
include/drm/drm_dp_helper.h | 52 ++
1 files changed, 32 insertions(+), 20 deletions(-)
diff --git a/include/drm/drm_dp_helper.h b
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/intel_dp.c |9 -
include/drm/drm_dp_helper.h |3 ++-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 813b771..00f99e5 100644
--- a
On Sat, 2012-09-22 at 23:34 -0500, Ian Pilcher wrote:
> On 09/12/2012 08:44 PM, Dave Airlie wrote:
> > Ajax, I think Ian still has an open request on how to proceed with the
> > infoframes quirk nightmare.
>
> Indeed.
I'm sorry, I thought I was clearer. Daniel posted a patch to fix the
Intel dri
On Tue, 2012-09-25 at 13:47 -0500, Ian Pilcher wrote:
> In the meantime, I would like to move the ball forward on this issue.
> As I see it, there 3 issues that have become conflated:
>
> 1. The display (LG L246WP) is confused by *any* InfoFrames.
If this is still the case after applying:
comm
still think
there's something fundamentally amiss with a display that doesn't want
to accept InfoFrames, but without having it in hand to mess with - and
without wanting to play telephone to figure it out - I'm fine with this.
Reviewed-by: Adam Jackson
- ajax
__
On 10/19/12 1:43 PM, Lucas Kannebley Tavares wrote:
The radeon driver does speed cap detection on the root PCI device for
the maximum speed with which the adapter can communicate. On ppc64
systems, however, the root device belongs to the Hypervisor, so the
current code would case a null pointer d
On 10/27/12 9:52 AM, Daniel Vetter wrote:
Userspace seems to like this, see
commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
Author: Adam Jackson
Date: Fri Jul 16 14:46:29 2010 -0400
drm/i915: Initialize LVDS and eDP outputs before anything else
This makes them sort to the front
On 10/27/12 9:52 AM, Daniel Vetter wrote:
This essentially reverts
commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
Author: Adam Jackson
Date: Fri Jul 16 14:46:29 2010 -0400
drm/i915: Initialize LVDS and eDP outputs before anything else
simply because it doesn't scale: It misses
Signed-off-by: Adam Jackson
---
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
+++ b/drivers
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 Jackson 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 platform
On 11/2/11 4:05 PM, Keith Packard wrote:
On Wed, 02 Nov 2011 15:36:20 -0400, Adam Jackson wrote:
The VBT is going to be crap.
The only question then is what to do with hardware that doesn't have the
DPCD value -- that's "new" in revision 0x11, after all.
It is? The D
On 11/2/11 5:13 PM, Keith Packard wrote:
On Wed, 02 Nov 2011 16:35:51 -0400, Adam Jackson wrote:
It is? The DP 1.1a text for lane count is "For Rev.1.1, only the
following three values are supported. All other values are reserved."
Yeah, if you look at the MAX_LINK_RATE field,
to determine n, and the existing code
> will filter non-timing 18byte descriptors anyway.
Good catch, thanks.
Reviewed-by: Adam Jackson
- 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
ishing this up. 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
I'll test this on some other intel kit I've got
handy. For the series:
Reviewed-by: Adam Jackson
- 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 Wed, 2011-11-16 at 16:29 -0800, Keith Packard wrote:
> The Ivybridge eDP control register looks like a cross between a
> Cougarpoint PCH DP control register and a Sandybridge eDP control
> register.
Your silicon people worry me.
> +/* IVB */
> +#define EDP_LINK_TRAIN_400MV_0DB_IVB (0x2
On 11/17/11 9:13 PM, Keith Packard wrote:
On Thu, 17 Nov 2011 17:45:40 -0500, Adam Jackson 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, just shaking
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):
http://www.mail-archive.com/
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 2
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
---
drivers/gpu/drm/drm_edid.c | 18 --
1 files changed, 8 inserti
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
Reviewed-by: Adam Jackson
- ajax
signature.asc
Description:
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 i
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 Op
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 extens
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 staying
back,
> .ident = "Asus EeeBox PC EB1007",
> .matches = {
> DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer INC."),
Reviewed-by: Adam Jackson
- ajax
signature.asc
Description: This is a digitally signed message part
__
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 inc
feedback on the approach 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
---
drivers/gpu/drm/Kconfig |8 ++
drivers/gpu/drm/Makefile
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 grumbl
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-Of
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"
7;s supposed to work. Furthermore intel Bspec
explicitly mentions that both odd and even interlaced vtotal are
supported (VTOTAL register in the south display engine of PCH split
chips).
Cc: Adam Jackson
Signed-Off-by: Daniel Vetter
---
Ajax? I'd like your ack/review on this.
That |=
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
---
drivers/gpu/drm/drm_edid.c |
1 - 100 of 432 matches
Mail list logo
