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
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: Adam Jack
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
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
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 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
d 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 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).
ty 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 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
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_fourcc.h
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
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,
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.
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
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
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
> +++
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
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 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
> + *
into the kernel.
>
> 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-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
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 HDR f
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
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
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 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
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
ding 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
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
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
> 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 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 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.
;supplied by the
driver" as with EDID-derived modes.
With or without that, patches 2 3 4 and 8 are:
Reviewed-by: Adam Jackson <a...@redhat.com>
- ajax
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 <a...@redhat.
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 <a...@redhat.com>
---
xf86drm.c | 18 +-
xf86drm.h | 2 ++
2
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
> (Chris, Alex and others).
Acked-by: Ad
lows a different
> > proportion of error depending on the clock. I believe VESA CVT
> > allows a maximum deviation of .5%, so using that for normal mode
> > matching might be a good idea?
>
> Ping. Any thoughts from anyone?
Reviewed-by: Adam Jackson
- ajax
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
Turns out 1366x768 does not in fact work on this hardware.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 6e84df9..ad4b901
gt; 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
On Wed, 2014-12-17 at 18:30 +0100, Daniel Vetter wrote:
> All pulled into my drm misc branch.
Ugh, wish I'd caught this earlier. I'm not entirely thrilled with
requiring non-zero clock, it's not a concept that makes sense on virtual
hardware.
- ajax
On Thu, 2014-11-20 at 16:26 -0800, Zach Reizner wrote:
> This patch implements the virtual GEM driver with PRIME sharing which
> allows vgem to import a gem object from other drivers for the purpose
> of mmap-ing them to userspace.
The reason I initially wanted this was to get zero-copy llvmpipe,
On Mon, 2014-10-27 at 16:30 +0100, Gerd Hoffmann wrote:
> How about stop using cirrus and go for 'qemu -vga std' instead?
>
> Linux kernel 3.14+ comes with a modesetting driver for the qemu standard
> vga (CONFIG_DRM_BOCHS). Just switch over, and all your cirrus pain is
> gone.
>
> That is
On Fri, 2014-10-24 at 18:31 -0700, Stéphane Marchesin wrote:
> Dave, Adam: are you ok with this patch?
Seems like it doesn't go far enough? You'd already need an "aware"
guest to have this work, since the chip actually being emulated didn't
have 32bpp. The pitch check would prevent
On Fri, 2013-11-15 at 10:38 +0530, Shirish S wrote:
> The current solution checks for the existing RB mode,
> if available in the edid block returns by adding it,
> but does not populate the connector with the modes
> of same resolution but which are non-rb modes.
>
> As a result the probing and
, but the changes make
sense. For the series:
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
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
On Tue, 2013-07-23 at 15:46 +1000, Dave Airlie wrote:
On Wed, Jul 17, 2013 at 11:07 PM, Egbert Eich e...@suse.com 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
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
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/radeon
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 a...@redhat.com
---
drivers/gpu
On Mon, 2013-06-17 at 11:04 -0400, Alex Deucher wrote:
On Mon, Jun 17, 2013 at 10:06 AM, Adam Jackson a...@redhat.com 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 being updated. There's
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
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Ty
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 a...@redhat.com
- ajax
signature.asc
Description: This is a digitally signed message part
;Display Range Limits
> & Additional Timing Description Definition (tag #FDh)".
Seems sane.
Reviewed-by: Adam Jackson
- ajax
Description Definition (tag #FDh).
Seems sane.
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
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
>
> simp
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:
Userspace seems to like this, see
commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
Author: Adam Jackson a...@redhat.com
Date: Fri Jul 16 14:46:29 2010 -0400
drm/i915: Initialize LVDS and eDP outputs before anything else
This makes them sort
On 10/27/12 9:52 AM, Daniel Vetter wrote:
This essentially reverts
commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
Author: Adam Jackson a...@redhat.com
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
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
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
he 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
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 a...@redhat.com
- ajax
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:
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:
commit
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
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 driver
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
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
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.
>
On 9/20/12 10:10 AM, Paulo Zanoni wrote:
2012/9/18 Adam Jackson a...@redhat.com:
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_COUNT
Note with a comment anything newer than DP 1.1a.
Obviously this needs some work still...
Signed-off-by: Adam Jackson a...@redhat.com
---
include/drm/drm_dp_helper.h | 52 ++
1 files changed, 32 insertions(+), 20 deletions(-)
diff --git a/include/drm
Signed-off-by: Adam Jackson a...@redhat.com
---
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
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.
> Otherwise, probe DD
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/intel_dp.c
index
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
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
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
Tested-by: Takashi Iwai ti...@suse.de
Signed-off-by: Adam Jackson a...@redhat.com
---
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
Sources: DP, eDP, and DP interop specs, and a VESA slideshow about DP
1.2 for the MST bits.
Tested-by: Takashi Iwai ti...@suse.de
Signed-off-by: Adam Jackson a...@redhat.com
---
include/drm/drm_dp_helper.h | 60 ---
1 files changed, 56 insertions(+), 4
v2: Fix parenthesis mismatch, spotted by Jani Nikula
Tested-by: Takashi Iwai ti...@suse.de
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c | 25 -
1 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915
unrelated to sink status.
Tested-by: Takashi Iwai ti...@suse.de
Signed-off-by: Adam Jackson a...@redhat.com
---
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
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.
Otherwise, probe DDC and report
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
On 9/8/12 6:35 AM, Dave Airlie wrote:
On Sat, Sep 8, 2012 at 3:30 AM, Shirish S shirish@gmail.com 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
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 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/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
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
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
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
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
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
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
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
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 t
se something 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
monitor
1 - 100 of 405 matches
Mail list logo
