>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville Syrjälä
>Sent: Tuesday, February 5, 2019 11:43 PM
>To: Shankar, Uma
>Cc: intel-...@lists.freedesktop.org; Syrjala, Ville ;
>Lankhorst, Maarten ; dri-
>de...@lists.freedesktop.org
On Mon, Jan 28, 2019 at 12:43 PM Sean Paul wrote:
>
> From: Sean Paul
>
> There exists a bunch of confusion as to what the actual units of
> frame_done is:
>
> - The definition states it's in # of frames
> - CRTC treats it like it's ms
> - frame_done_timeout comment thinks it's Hz, but it stores
On Mon, Jan 28, 2019 at 12:23 PM Daniel Vetter wrote:
>
> Compared to the RFC[1] no changes to the patch itself, but igt moved
> forward a lot:
>
> - gitlab CI builds with: reduced configs/libraries, arm cross build
> and a sysroot build (should address all the build/cross platform
> concerns
On Wed, Jan 30, 2019 at 8:32 AM Sean Paul wrote:
>
> From: Sean Paul
>
> The frame_busy mask is used in frame_done event handling, which is not
> invoked for async commits. So an async commit will leave the
> frame_busy mask populated after it completes and future commits will start
> with the
On Mon, Jan 28, 2019 at 12:43 PM Sean Paul wrote:
>
> From: Sean Paul
>
> In the case of an async/cursor update, we don't wait for the frame_done
> event, which means handle_frame_done is never called, and the frame_done
> watchdog isn't canceled. Currently, this results in a frame_done timeout
On Mon, Feb 04, 2019 at 03:40:22PM -0800, Manasi Navare wrote:
> This patch adds appropiate kernel documentation for DRM DP helpers
> used for enabling Display Stream compression functionality in
> drm_dp_helper.h and drm_dp_helper.c as well as for the DSC spec
> related structure definitions and
This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.
Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with
This patch series creates a new connector property to program
colorspace to sink devices. Modern sink devices support more
than 1 type of colorspace like 601, 709, BT2020 etc. This helps
to switch based on content type which is to be displayed. The
decision lies with compositors as to in which
This patch adds a DP colorspace property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
Create a new connector property to program colorspace to sink
devices. Modern sink devices support more than 1 type of
colorspace like 601, 709, BT2020 etc. This helps to switch
based on content type which is to be displayed. The decision
lies with compositors as to in which scenarios, a
This adds colorspace information to HDMI AVI infoframe.
A helper function is added to program the same.
v2: Moved this to drm core instead of i915 driver.
v3: Exported the helper function.
v4: Added separate HDMI specific macro as per CTA spec.
This is separate from user exposed enum values.
https://bugs.freedesktop.org/show_bug.cgi?id=109499
--- Comment #5 from Nadal Gonzalo García Zavala
---
Created attachment 143308
--> https://bugs.freedesktop.org/attachment.cgi?id=143308=edit
working_edid.bin
--
You are receiving this mail because:
You are the assignee for the
Hi Dave, Daniel,
Fixes for 5.0:
- Fix missing freesync properties on eDP
- Fix locking in pasid mgr
- Fix clang warning in kfd
- DC/powerplay fix
- Fix reported rev ids on raven
- Doorbell fix for vega20
The following changes since commit 6e11ea9de9576a644045ffdc2067c09bc2012eda:
drm/amdgpu:
https://bugs.freedesktop.org/show_bug.cgi?id=109561
Bug ID: 109561
Summary: [regression, bisected] code re-factor causing games to
stutter or lock-up system
Product: Mesa
Version: git
Hardware: Other
OS:
https://bugs.freedesktop.org/show_bug.cgi?id=109499
--- Comment #4 from Nadal Gonzalo García Zavala
---
I'm not sure, but is possible the issue were fixed between revisions 43 and 45
of ubuntu kernel 4.15.
Before upgrading the kernel, we reached a solution:
- Using EDID emulators, getting
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_pci.c
between commit:
fcd70cd36b9b ("drm: Split out drm_probe_helper.h")
from the drm tree and commit:
5f5c139d6900 ("drm/i915: Allocate active tracking nodes from a slabcache")
from
https://bugzilla.kernel.org/show_bug.cgi?id=202511
--- Comment #1 from Michael A. Leonetti (mikealeone...@gmail.com) ---
Created attachment 281011
--> https://bugzilla.kernel.org/attachment.cgi?id=281011=edit
4.17.19 working amdgpu dmesg
For reference here is my dmesg from the 4.17.19 which
https://bugzilla.kernel.org/show_bug.cgi?id=202511
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
64 bpp half float formats are supported on hdr planes only and are subject
to the following restrictions:
* 90/270 rotation not supported
* Yf Tiling not supported
* Frame Buffer Compression not supported
* Color Keying not supported
v2:
- Drop handling pixel normalize register
- Don't
This series defines new formats and adds implementation to the i915 driver.
Since posting v1 I have removed the pixel normalize property, as it's not needed
for basic functionality. Also, I have been working on adding support to
userspace, but we can't land any patches until drm_fourcc.h has been
Change the api in order to enable callers that can't supply a valid
intel_plane pointer, as would be the case prior to calling
drm_universal_plane_init.
Cc: Uma Shankar
Cc: Shashank Sharma
Cc: Ville Syrjälä
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by:
Add 64 bpp 16:16:16:16 half float pixel formats. Each 16 bit component is
formatted in IEEE-754 half-precision float (binary16) 1:5:10
MSb-sign:exponent:fraction form.
This patch attempts to address the feedback provided when 2 of these
formats were previosly proposed:
This patch adds appropiate kernel documentation for DRM DP helpers
used for enabling Display Stream compression functionality in
drm_dp_helper.h and drm_dp_helper.c as well as for the DSC spec
related structure definitions and helpers in drm_dsc.c and drm_dsc.h
Also add links between the functions
On Tue, Feb 5, 2019 at 7:42 AM Maxime Ripard wrote:
>
> On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote:
> > On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng wrote:
> > > >> IIRC, from the previous discussion, HDMI had a tolerancy requirement
> > > >> in the standard. Do you know
First thing that struck me is that the chip's reset is actually low active
reset-gpios = < 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
(please correct this in patches 11 and 12)
Consequently, you're using inverted values here in the driver:
> +static void
* Tomi Valkeinen [190205 11:07]:
> Yep... So there's the DSI internal code which needs to deal with ulps
> and disconnect_lanes, and then the external interface to the DSI PLL (so
> that DPI can use DSI PLL) without ulps/disconnect.
>
> I think your patch breaks this latter one, as
On Mon, 28 Jan 2019 18:22:58 +0100
Daniel Vetter wrote:
> Compared to the RFC[1] no changes to the patch itself, but igt moved
> forward a lot:
>
> - gitlab CI builds with: reduced configs/libraries, arm cross build
> and a sysroot build (should address all the build/cross platform
>
On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote:
> On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote:
> > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote:
> > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote:
> > > > On Mon, Feb 04, 2019 at
On Tue, Feb 05, 2019 at 06:06:50AM +0800, Tom Li wrote:
> > Since you care about this driver, considered converting it to a drm
> > display driver? You can still have all the acceleration and stuff, the
> > fbdev compat mode in drm is rather flexible.
> > -Daniel
>
> Yes, I know fbdev is now in
On Mon, Feb 04, 2019 at 06:35:28PM +0100, Noralf Trønnes wrote:
>
>
> Den 04.02.2019 16.41, skrev Daniel Vetter:
> > On Sun, Feb 03, 2019 at 04:41:56PM +0100, Noralf Trønnes wrote:
> >> The only thing now that makes drm_dev_unplug() special is that it sets
> >> drm_device->unplugged. Move this
On Mon, Feb 4, 2019 at 6:20 AM Maxime Ripard wrote:
>
> Hi,
>
> On Sun, Feb 03, 2019 at 10:54:55AM -0800, Vasily Khoruzhick wrote:
> > Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i: rgb:
> > Validate the clock rate") prevents some panel and bridges from working with
> > sun4i
On 2/3/19 5:41 PM, Noralf Trønnes wrote:
> drm_dev_unplug() has been stripped down and is going away. Open code its
> 2 remaining function calls.
>
> Also remove the drm_dev_is_unplugged() check since this can't be true
> before drm_dev_unregister() is called which happens after the check.
>
> Cc:
Hi,
* Tomi Valkeinen [190204 09:57]:
> On 31/01/2019 05:32, Tony Lindgren wrote:
> > Currently dsi_display_init_dsi() calls dss_pll_enable() but it is not
> > paired with dss_pll_disable() in dsi_display_uninit_dsi(). This leaves
>
> But it is paired with dsi_pll_uninit().
But we need to also
On Thu, Oct 18, 2018 at 03:33:18PM +0800, Icenowy Zheng wrote:
> This patchset brings the support for Analogix ANX6345 RGB-(e)DP bridge,
> which is used by some Allwinner A64 laptops, such as Pinebook and Olimex
> TERES-I.
>
So what's the status here? I'm working on the Teres-I and I find myself
On 2/3/19 5:42 PM, Noralf Trønnes wrote:
> There are no users left.
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/drm_drv.c | 17 -
> include/drm/drm_drv.h | 1 -
> 2 files changed, 18 deletions(-)
>
> diff --git
On Mon, Feb 4, 2019 at 4:22 AM Torsten Duwe wrote:
>
> On Thu, Oct 18, 2018 at 03:33:18PM +0800, Icenowy Zheng wrote:
> > This patchset brings the support for Analogix ANX6345 RGB-(e)DP bridge,
> > which is used by some Allwinner A64 laptops, such as Pinebook and Olimex
> > TERES-I.
> >
>
> So
This panel has a backlight, so add a property describing that and
add the code to use that.
This makes things like xset dpms force off
also turn off the backlight, so we do not need to rely on additional
userspace programs to do that.
Andreas Kemnade (2):
drm/omap: panel-tpo-td028ttec1: add
On 2/3/19 5:41 PM, Noralf Trønnes wrote:
> The only thing now that makes drm_dev_unplug() special is that it sets
> drm_device->unplugged. Move this code to drm_dev_unregister() so that we
> can remove drm_dev_unplug().
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Oleksandr Andrushchenko
> ---
This panel has a backlight, so fetch it from devicetree using the
corresponding property as documented in panel-common.txt. It is
implemented the same way as in panel-dpi.c
This ensures the backlight is also disabled when the display is
turned off like when doing xset dpms force off.
> Since you care about this driver, considered converting it to a drm
> display driver? You can still have all the acceleration and stuff, the
> fbdev compat mode in drm is rather flexible.
> -Daniel
Yes, I know fbdev is now in maintenance-only mode, reimplementing it
on top of DRM is on my
On 21/01/19 9:15 PM, Maxime Ripard wrote:
> Hi,
>
> Here is a set of patches to allow the phy framework consumers to test and
> apply runtime configurations.
>
> This is needed to support more phy classes that require tuning based on
> parameters depending on the current use case of the
This adds an additional backlight property as described
in panel-common.txt
Signed-off-by: Andreas Kemnade
---
Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git
On Mon, Feb 4, 2019 at 12:23 PM Rob Herring wrote:
> > simple-panel would probably work if you stuck in some mostly compatible
> > string and provided a ddc-i2c-bus property in the device tree node. The
> > generic-ish fallback case could be implemented by providing a fallback
> > compatible
Hi,
On Mon, 4 Feb 2019 10:13:46 +0200
Tomi Valkeinen wrote:
> Hi,
>
> On 19/01/2019 20:21, Andreas Kemnade wrote:
> > This panel has a backlight, so fetch it from devicetree using the
> > as documented in panel-common.txt. It is implemented the same way as in
>
> Extra words above, or maybe
On Mon, Feb 4, 2019 at 8:56 AM Thierry Reding wrote:
> > I think it is perfectly fine to have a generic-ish fallback as long as
> > it is just that, a fallback. If the panel has quirks, then you'd
> > better make sure the firmware is stuffing in the right compatibles or
> > that you can update
On Mon, Feb 4, 2019 at 12:24 AM Thierry Reding wrote:
> >
> > Pinebook used several 768p panels that have slightly different timings
> > and recent batch uses 1080p panel.
> >
> > What panel descriptor should I use as fallback?
>
> You don't use panel descriptors as fallback. The simple-panel
On Mon, Feb 04, 2019 at 10:13:25AM -0800, Rodrigo Vivi wrote:
> On Thu, Jan 31, 2019 at 07:17:02PM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Jan 31, 2019 at 09:59:26AM -0800, Rodrigo Vivi wrote:
> > > On Thu, Jan 31, 2019 at 02:15:07PM +0100, Greg Kroah-Hartman wrote:
> > > > When calling
On Mon, Feb 04, 2019 at 12:01:31PM +0100, Gerd Hoffmann wrote:
> Commit "f4bd542bca drm/fb-helper: Scale back depth to supported maximum"
> uncovered a bug in the cirrus driver. It must create its own primary
> plane, using the correct format list, depending on the bpp module
> parameter, so it
https://bugs.freedesktop.org/show_bug.cgi?id=109548
Michel Dänzer changed:
What|Removed |Added
Product|DRI |Mesa
Component|DRM/AMDgpu
于 2019年2月5日 GMT+08:00 上午12:26:43, Vasily Khoruzhick 写到:
>On Mon, Feb 4, 2019 at 6:20 AM Maxime Ripard
> wrote:
>>
>> Hi,
>>
>> On Sun, Feb 03, 2019 at 10:54:55AM -0800, Vasily Khoruzhick wrote:
>> > Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i:
>rgb:
>> > Validate the
On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng wrote:
> >> IIRC, from the previous discussion, HDMI had a tolerancy requirement
> >> in the standard. Do you know if there's such a thing for eDP? That
> >> would solve the issue for all the eDP displays at once.
> >
> >I don't have access to eDP
On Mon, Feb 4, 2019 at 8:39 AM Rob Herring wrote:
>
> On Mon, Feb 4, 2019 at 10:11 AM Vasily Khoruzhick wrote:
> >
> > On Mon, Feb 4, 2019 at 12:24 AM Thierry Reding
> > wrote:
> > > >
> > > > Pinebook used several 768p panels that have slightly different timings
> > > > and recent batch uses
On 2/3/19 5:41 PM, Noralf Trønnes wrote:
> If userspace has open fd(s) when drm_dev_unplug() is run, it will result
> in drm_dev_unregister() being called twice. First in drm_dev_unplug() and
> then later in drm_release() through the call to drm_put_dev().
>
> Since userspace already holds a ref
On Mon, Feb 04, 2019 at 09:02:35PM +0530, C, Ramalingam wrote:
> daniel,
>
> Could you please review this patch too.? Already Updated this as per your
> previous review comment.
Oops, missed this one somehow. Looks much cleaner now imo.
Reviewed-by: Daniel Vetter
>
> --Ram
>
> On 1/31/2019
On Mon, Feb 04, 2019 at 07:38:58PM +0100, Gerd Hoffmann wrote:
> ttm_fbdev_mmap() just doesn't work. It appears to work fine, mmap()
> returns success, but any attempt to actually access the mapping causes a
> SIGBUS.
>
> We can just use drm_gem_prime_mmap() instead. Almost. We have to copy
>
On Mon, 04 Feb 2019, Daniel Vetter wrote:
> On Mon, Feb 04, 2019 at 10:47:36AM +0200, Joonas Lahtinen wrote:
>> Quoting Dave Airlie (2019-02-04 07:02:07)
>> > On Sat, 2 Feb 2019 at 18:29, Rodrigo Vivi wrote:
>> > >
>> > > Hi Dave and Daniel,
>> > >
>> > > Here goes another pull request for 5.1.
On Mon, Feb 04, 2019 at 03:33:31PM +0530, Kishon Vijay Abraham I wrote:
>
>
> On 21/01/19 9:15 PM, Maxime Ripard wrote:
> > Hi,
> >
> > Here is a set of patches to allow the phy framework consumers to test and
> > apply runtime configurations.
> >
> > This is needed to support more phy classes
The etnaviv_gem_prime_get_sg_table() is supposed to return error
pointers. Otherwise it can lead to a NULL dereference when it's called
from drm_gem_map_dma_buf().
Fixes: 5f4a4a73f437 ("drm/etnaviv: fix gem_prime_get_sg_table to return new SG
table")
Signed-off-by: Dan Carpenter
---
On Mon, Feb 04, 2019 at 03:40:22PM -0800, Manasi Navare wrote:
> This patch adds appropiate kernel documentation for DRM DP helpers
> used for enabling Display Stream compression functionality in
> drm_dp_helper.h and drm_dp_helper.c as well as for the DSC spec
> related structure definitions and
Quoting Stéphane Marchesin (2019-02-05 06:16:48)
> On Mon, Feb 4, 2019 at 1:07 AM Daniel Vetter wrote:
> >
> > On Mon, Feb 04, 2019 at 10:57:24AM +0200, Joonas Lahtinen wrote:
> > > Quoting Joonas Lahtinen (2019-01-15 16:47:27)
> > > > Hi all,
> > > >
> > > > I would like to have some Acked-by's
Den 05.02.2019 10.11, skrev Daniel Vetter:
> On Mon, Feb 04, 2019 at 06:35:28PM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 04.02.2019 16.41, skrev Daniel Vetter:
>>> On Sun, Feb 03, 2019 at 04:41:56PM +0100, Noralf Trønnes wrote:
The only thing now that makes drm_dev_unplug() special is that
https://bugs.freedesktop.org/show_bug.cgi?id=109550
Sylvain BERTRAND changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote:
> On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote:
> > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote:
> > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote:
> > > > On Mon, Feb 04, 2019 at
w/compOn Thu, Jan 31, 2019 at 3:46 PM Daniel Vetter
wrote:
>
> Someone owes me a beer ...
>
> While typing these I think doing an s/component_master/aggregate/
> would be useful:
> - it's shorter :-)
> - I think component/aggregate is much more meaningful naming than
> component/puppetmaster
On 04/02/2019 17:42, Tony Lindgren wrote:
> Hi,
>
> * Tomi Valkeinen [190204 09:57]:
>> On 31/01/2019 05:32, Tony Lindgren wrote:
>>> Currently dsi_display_init_dsi() calls dss_pll_enable() but it is not
>>> paired with dss_pll_disable() in dsi_display_uninit_dsi(). This leaves
>>
>> But it is
>
> ME FW is contributes a vital role in HDCP2.2 authentication.
> HDCP2.2 driver needs to communicate to ME FW for each step of the
> HDCP2.2 authentication.
>
> ME FW prepare and HDCP2.2 authentication parameters and encrypt them as
> per spec. With such parameter Driver prepares HDCP2.2 auth
On Fri, Jan 25, 2019 at 02:11:42PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> If an I2C adapter doesn't match the provided device tree node, also try
> matching the parent's device tree node. This allows finding an adapter
> based on the device node of the parent device that was
https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #70 from jake.hed...@yahoo.com ---
Ok, that seems to have stabilized my system. It at least withstood constant
use for 4+ hours. I went idle, stressed it, idle again, and no crashes.
My current setup is Buster and idle=nomwait.
>
> >-Original Message-
> >From: C, Ramalingam
> >Sent: Thursday, January 31, 2019 12:30 PM
> >To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> >daniel.vet...@ffwll.ch; Winkler, Tomas ;
> >Shankar, Uma
> >Cc: C, Ramalingam
> >Subject: [PATCH v10 24/40]
https://bugs.freedesktop.org/show_bug.cgi?id=109557
Martin Peres changed:
What|Removed |Added
Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=109557
Martin Peres changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |maxime.ripard@free-electron
> >Request ME FW to start the HDCP2.2 session for an intel port.
> >Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sends
> to
> >ME FW.
> >
> >On Success, ME FW will start a HDCP2.2 session for the port and
> >provides the content for HDCP2.2 AKE_Init message.
> >
> >v2: Rebased.
Thanks Tomas.
On 2/5/2019 6:39 PM, Winkler, Tomas wrote:
Request ME FW to start the HDCP2.2 session for an intel port.
Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sends
to
ME FW.
On Success, ME FW will start a HDCP2.2 session for the port and
provides the content for
>-Original Message-
>From: Shankar, Uma
>Sent: Monday, February 4, 2019 10:49 PM
>To: Ville Syrjälä
>Cc: intel-...@lists.freedesktop.org; Syrjala, Ville ;
>Lankhorst, Maarten ; dri-
>de...@lists.freedesktop.org
>Subject: RE: [Intel-gfx] [v10 3/3] drm/i915: Attach colorspace property and
Hi Sam,
On Tue, Jan 29, 2019 at 04:48:33PM +0100, Sam Ravnborg wrote:
> > > > + }
> > > > +
> > > > + drm_mode_set_name(mode);
> > > > +
> > > > + mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
> > > > + drm_mode_probed_add(connector, mode);
> > > > +
> > > >
Create a new connector property to program colorspace to sink
devices. Modern sink devices support more than 1 type of
colorspace like 601, 709, BT2020 etc. This helps to switch
based on content type which is to be displayed. The decision
lies with compositors as to in which scenarios, a
This patch adds a DP colorspace property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
This adds colorspace information to HDMI AVI infoframe.
A helper function is added to program the same.
v2: Moved this to drm core instead of i915 driver.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_connector.c | 2 +-
drivers/gpu/drm/drm_edid.c | 28
This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.
Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with
This patch series creates a new connector property to program
colorspace to sink devices. Modern sink devices support more
than 1 type of colorspace like 601, 709, BT2020 etc. This helps
to switch based on content type which is to be displayed. The
decision lies with compositors as to in which
On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote:
> On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng wrote:
> > >> IIRC, from the previous discussion, HDMI had a tolerancy requirement
> > >> in the standard. Do you know if there's such a thing for eDP? That
> > >> would solve the
Someone owes me a beer ...
While typing these I think doing an s/component_master/aggregate/
would be useful:
- it's shorter :-)
- I think component/aggregate is much more meaningful naming than
component/puppetmaster or something like that. At least to my
English ear "aggregate" emphasizes
https://bugs.freedesktop.org/show_bug.cgi?id=109539
--- Comment #6 from Nicholas Kazlauskas ---
Do you still see the issue occur when amdgpu.dc=1 if you disable DP1.2 support
in your monitor's OSD?
--
You are receiving this mail because:
You are the assignee for the
On Tue, Feb 05, 2019 at 10:55:12AM +0100, Daniel Vetter wrote:
> On Mon, Feb 04, 2019 at 03:40:22PM -0800, Manasi Navare wrote:
> > This patch adds appropiate kernel documentation for DRM DP helpers
> > used for enabling Display Stream compression functionality in
> > drm_dp_helper.h and
On Tue, Feb 05, 2019 at 05:32:16PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Tuesday, February 5, 2019 10:02 PM
> >To: Shankar, Uma
> >Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
On Tue, Feb 05, 2019 at 04:49:02PM +, Russell King - ARM Linux admin wrote:
> On Tue, Feb 05, 2019 at 05:21:07PM +0100, Daniel Vetter wrote:
> > Someone owes me a beer ...
>
> I find that deeply offensive - it is clearly directed at me personally
> as author of the component helper.
>
>
Create a new connector property to program colorspace to sink
devices. Modern sink devices support more than 1 type of
colorspace like 601, 709, BT2020 etc. This helps to switch
based on content type which is to be displayed. The decision
lies with compositors as to in which scenarios, a
This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.
Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with
This patch series creates a new connector property to program
colorspace to sink devices. Modern sink devices support more
than 1 type of colorspace like 601, 709, BT2020 etc. This helps
to switch based on content type which is to be displayed. The
decision lies with compositors as to in which
This patch adds a DP colorspace property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
This adds colorspace information to HDMI AVI infoframe.
A helper function is added to program the same.
v2: Moved this to drm core instead of i915 driver.
v3: Exported the helper function.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_connector.c | 2 +-
drivers/gpu/drm/drm_edid.c
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, February 5, 2019 10:03 PM
>To: Shankar, Uma
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Syrjala,
>Ville
>; Lankhorst, Maarten
>Subject: Re: [Intel-gfx] [v11 3/4]
Den 05.02.2019 17.31, skrev Daniel Vetter:
> On Tue, Feb 05, 2019 at 11:20:55AM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 05.02.2019 10.11, skrev Daniel Vetter:
>>> On Mon, Feb 04, 2019 at 06:35:28PM +0100, Noralf Trønnes wrote:
Den 04.02.2019 16.41, skrev Daniel Vetter:
> On
On Tue, Feb 05, 2019 at 11:24:19AM +0100, Thierry Reding wrote:
> On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote:
> > On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote:
> > > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote:
> > > > On Mon, Feb 04, 2019 at
On Mon, Feb 04, 2019 at 08:37:01PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Feb 04, 2019 at 10:13:25AM -0800, Rodrigo Vivi wrote:
> > On Thu, Jan 31, 2019 at 07:17:02PM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Jan 31, 2019 at 09:59:26AM -0800, Rodrigo Vivi wrote:
> > > > On Thu, Jan 31,
On Tue, Feb 05, 2019 at 11:47:58AM +0100, Rafael J. Wysocki wrote:
> w/compOn Thu, Jan 31, 2019 at 3:46 PM Daniel Vetter
> wrote:
> >
> > Someone owes me a beer ...
> >
> > While typing these I think doing an s/component_master/aggregate/
> > would be useful:
> > - it's shorter :-)
> > - I think
On Tue, Feb 05, 2019 at 11:20:55AM +0100, Noralf Trønnes wrote:
>
>
> Den 05.02.2019 10.11, skrev Daniel Vetter:
> > On Mon, Feb 04, 2019 at 06:35:28PM +0100, Noralf Trønnes wrote:
> >>
> >>
> >> Den 04.02.2019 16.41, skrev Daniel Vetter:
> >>> On Sun, Feb 03, 2019 at 04:41:56PM +0100, Noralf
On Tue, Feb 05, 2019 at 09:33:34PM +0530, Uma Shankar wrote:
> Create a new connector property to program colorspace to sink
> devices. Modern sink devices support more than 1 type of
> colorspace like 601, 709, BT2020 etc. This helps to switch
> based on content type which is to be displayed. The
What I want to know is what is calling your machine ‘localhorst’?
Sent from my iPhone
> On Nov 20, 2018, at 9:15 AM, bugzilla-dae...@freedesktop.org wrote:
>
> Comment # 47 on bug 105733 from Allan
> I have really bad news.
>
> I'm delaying a lot to answer because I literally sent for
https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #71 from Garry Hurley Jr ---
What I want to know is what is calling your machine ‘localhorst’?
Sent from my iPhone
> On Nov 20, 2018, at 9:15 AM, bugzilla-dae...@freedesktop.org wrote:
>
> Comment # 47 on bug 105733 from Allan
>
1 - 100 of 106 matches
Mail list logo
