https://bugs.freedesktop.org/show_bug.cgi?id=97909
--- Comment #12 from Christian Inci ---
Unfortunately I'm not able to test this till three weeks. I'll let you know the
result of the test after that, if nothing unexpected happens.
What do you think about closing this bug as WONTFIX? Working ar
https://bugs.freedesktop.org/show_bug.cgi?id=100166
Timothy Arceri changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #2 from Timothy A
https://bugs.freedesktop.org/show_bug.cgi?id=95659
Timothy Arceri changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #10 from Timothy A
On Wed, Apr 11, 2018 at 01:03:59PM +0100, Robin Murphy wrote:
> On 10/04/18 21:59, Sinan Kaya wrote:
>> Code is expecing to observe the same number of buffers returned from
>> dma_map_sg() function compared to sg_alloc_table_from_pages(). This
>> doesn't hold true universally especially for systems
https://bugs.freedesktop.org/show_bug.cgi?id=97909
Timothy Arceri changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #11 from Timothy A
From: Fengguang Wu
Use drm_*_get() and drm_*_put() helpers instead of drm_*_reference() and
drm_*_unreference() helpers.
Generated by: scripts/coccinelle/api/drm-get-put.cocci
Fixes: 6784ac15bc68 ("drm: Add ASPEED GFX driver")
Signed-off-by: Fengguang Wu
Signed-off-by: Julia Lawall
---
tre
https://bugs.freedesktop.org/show_bug.cgi?id=104190
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=103972
Timothy Arceri changed:
What|Removed |Added
CC||t_arc...@yahoo.com.au
--- Comment #1 f
https://bugs.freedesktop.org/show_bug.cgi?id=105018
--- Comment #29 from L.S.S. ---
EDIT: Maybe not really fixed in 4.17 (regression again?!)... just now after the
screen went blank, I got another panic and had to reboot... :-(
When the panic occurred, it spawned two errors.
Apr 12 11:32:03 lin
*Resend the whole actual series*
This patch implements a simple function for matching DRM device FDs against
the desired properties of a device that you are looking for.
The properties that are possible to look for are the elements of DrmVersion
and DrmDevice.
The discussion that led to this ser
drmHandleMatch is intended to allow for userspace to filter out
devices that it does not want to open.
Opening specific devices using paths alone is not a reliable due to
probing order. This function intends to provide a mechanism
for filtering out devices that don't fit what you need using the
al
https://bugs.freedesktop.org/show_bug.cgi?id=98977
Timothy Arceri changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #1 from Timothy Ar
https://bugs.freedesktop.org/show_bug.cgi?id=98492
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=97909
Timothy Arceri changed:
What|Removed |Added
CC||amarildo-ge...@autistici.or
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #9 from David Henningsson ---
Could add that my graphics card is an RX460:
23:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Device [1002:67ef] (rev cf) (prog-if 00 [VGA controller])
Subsystem:
https://bugs.freedesktop.org/show_bug.cgi?id=105880
David Henningsson changed:
What|Removed |Added
CC||di...@ubuntu.com
--- Comment #8 fro
https://bugs.freedesktop.org/show_bug.cgi?id=105018
--- Comment #28 from L.S.S. ---
Just updated to the 4.17-rc0 kernel and it seems the problem has been mostly
fixed there. The patches are no longer needed (already in there) and trying to
reproduce the issue only resulted in a couple of "Failed
For a while we actually haven't had any way of retraining MST links with
fallback link parameters like we do with SST. While uncommon, certain
setups such as my Caldigit TS3 + EVGA MST hub require this since
otherwise, they end up getting stuck in an infinite MST retraining loop.
MST retraining is
Unlike SST, MST can have far more then a single display hooked up on a
single port. What this also means however, is that if the DisplayPort
link to the top-level MST branch device becomes unstable then every
single branch device also has an unstable link. Additionally, MST has a
few more steps tha
This is useful for drivers (which will probably be all of them soon)
which need to track state that is exclusive to the topology, and not a
specific connector on said topology. This includes things such as the
link rate and lane count that are shared by all of the connectors on the
topology.
Signe
This gives drivers subclassing drm_dp_mst_topology_state the ability to
prepare their topology states for a new hub to be connected whenever
it's detected that the currently connected topology has been
disconnected from the system. We'll need this in order to correctly
track RX capabilities in i915
There's no reason to track the atomic state three times. Unfortunately,
this is currently what we're doing, and even worse is that there is only
one actually correct state pointer: the one in mst_state->base.state.
mgr->state never seems to be used, along with the one in
mst_state->state.
This con
When a DP MST link needs retraining, sometimes the hub will detect that
the current link bw config is impossible and will update it's RX caps in
the DPCD to reflect the new maximum link rate. Currently, we make the
assumption that the RX caps in the dpcd will never change like this.
This means if t
Does what it says on the label, it's a little confusing debugging atomic
check failures otherwise.
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_atomic.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c
The current way of handling changing VCPI allocations doesn't make a
whole ton of sense. Since drm_atomic_helper_check_modeset() can be
called multiple times which means that intel_dp_mst_atomic_check() can
also be called multiple times. However, since we make the silly mistake
of trying to free VC
Next version of https://patchwork.freedesktop.org/series/41576/
Only changes are removing duplicate SoBs that git send-email annoyingly
added. Sorry about that :(
Lyude Paul (10):
drm/atomic: Print debug message on atomic check failure
drm/i915: Move DP modeset retry work into intel_dp
drm/
While having the modeset_retry_work in intel_connector makes sense with
SST, this paradigm doesn't make a whole ton of sense when it comes to
MST since we have to deal with multiple connectors. In most cases, it's
more useful to just use the intel_dp struct since it indicates whether
or not we're d
Since these functions are dealing with an atomic state that needs to be
modified during atomic check and commit, change the naming on this
function to drm_atomic_dp_mst_get_topology_state() since we're the only
one using the function, and it's more consistent with the naming
scheme used in drm_atom
On Wed, Apr 11, 2018 at 2:55 PM, Jordan Crouse wrote:
> I've been struggling with a problem for a while and I haven't been able to
> come
> up with a clean solution. Rob convinced me to stop complaining and do
> _something_ and hopefully this can spur a good discussion.
>
> The scenario is basica
> From: Michel Dänzer [mailto:mic...@daenzer.net]
> Sent: Wednesday, April 11, 2018 05:50
> On 2018-04-11 08:57 AM, Nicolai Hähnle wrote:
> > On 10.04.2018 23:45, Cyr, Aric wrote:
> >> How does it work fine today given that all kernel seems to know is
> >> 'current' or 'current+1' vsyncs.
> >> Pres
Hi,
Il 12/04/2018 01:09, Paul Kocialkowski ha scritto:
Hi,
Le jeudi 12 avril 2018 à 00:22 +0200, Giulio Benetti a écrit :
Hi,
Il 10/04/2018 23:31, Paul Kocialkowski ha scritto:
This adds the pins definition for RGB666 LCD panels on the A20. It
was
imported from the A33 definition, that conce
Hi,
Le mercredi 11 avril 2018 à 08:28 +0200, Maxime Ripard a écrit :
> On Tue, Apr 10, 2018 at 11:31:27PM +0200, Paul Kocialkowski wrote:
> > This adds timings for the RGB666 variant of the Innolux AT070TN92
> > panel,
> > as found on the Ainol AW1 tablet.
> >
> > Signed-off-by: Paul Kocialkowski
Hi,
Le jeudi 12 avril 2018 à 00:22 +0200, Giulio Benetti a écrit :
> Hi,
>
> Il 10/04/2018 23:31, Paul Kocialkowski ha scritto:
> > This adds the pins definition for RGB666 LCD panels on the A20. It
> > was
> > imported from the A33 definition, that concernes the same set of
> > pins.
> >
> > Si
Hi and thanks for the review !
Le mercredi 11 avril 2018 à 09:06 +0200, Maxime Ripard a écrit :
> Hi,
>
> On Tue, Apr 10, 2018 at 11:31:29PM +0200, Paul Kocialkowski wrote:
> > This adds support for the Ainol AW1, an A20-based 7" tablet from
> > Ainol.
> >
> > The following board-specific featur
The current way of handling changing VCPI allocations doesn't make a
whole ton of sense. Since drm_atomic_helper_check_modeset() can be
called multiple times which means that intel_dp_mst_atomic_check() can
also be called multiple times. However, since we make the silly mistake
of trying to free VC
For a while we actually haven't had any way of retraining MST links with
fallback link parameters like we do with SST. While uncommon, certain
setups such as my Caldigit TS3 + EVGA MST hub require this since
otherwise, they end up getting stuck in an infinite MST retraining loop.
MST retraining is
This is useful for drivers (which will probably be all of them soon)
which need to track state that is exclusive to the topology, and not a
specific connector on said topology. This includes things such as the
link rate and lane count that are shared by all of the connectors on the
topology.
Signe
Unlike SST, MST can have far more then a single display hooked up on a
single port. What this also means however, is that if the DisplayPort
link to the top-level MST branch device becomes unstable then every
single branch device also has an unstable link. Additionally, MST has a
few more steps tha
When a DP MST link needs retraining, sometimes the hub will detect that
the current link bw config is impossible and will update it's RX caps in
the DPCD to reflect the new maximum link rate. Currently, we make the
assumption that the RX caps in the dpcd will never change like this.
This means if t
This gives drivers subclassing drm_dp_mst_topology_state the ability to
prepare their topology states for a new hub to be connected whenever
it's detected that the currently connected topology has been
disconnected from the system. We'll need this in order to correctly
track RX capabilities in i915
There's no reason to track the atomic state three times. Unfortunately,
this is currently what we're doing, and even worse is that there is only
one actually correct state pointer: the one in mst_state->base.state.
mgr->state never seems to be used, along with the one in
mst_state->state.
This con
Does what it says on the label, it's a little confusing debugging atomic
check failures otherwise.
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_atomic.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c
Since these functions are dealing with an atomic state that needs to be
modified during atomic check and commit, change the naming on this
function to drm_atomic_dp_mst_get_topology_state() since we're the only
one using the function, and it's more consistent with the naming
scheme used in drm_atom
Next version of https://patchwork.freedesktop.org/series/41576/
All changes in this patch series are just to make checkpatch a little
happier, no functional changes.
Lyude Paul (10):
drm/atomic: Print debug message on atomic check failure
drm/i915: Move DP modeset retry work into intel_dp
d
While having the modeset_retry_work in intel_connector makes sense with
SST, this paradigm doesn't make a whole ton of sense when it comes to
MST since we have to deal with multiple connectors. In most cases, it's
more useful to just use the intel_dp struct since it indicates whether
or not we're d
Hi,
Il 10/04/2018 23:31, Paul Kocialkowski ha scritto:
This adds the pins definition for RGB666 LCD panels on the A20. It was
imported from the A33 definition, that concernes the same set of pins.
Signed-off-by: Paul Kocialkowski
---
arch/arm/boot/dts/sun7i-a20.dtsi | 8
1 file cha
https://bugs.freedesktop.org/show_bug.cgi?id=105990
--- Comment #5 from Chris Wilson ---
We do for set_master, but not drop as I didn't think it failed for !master!!
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-deve
https://bugs.freedesktop.org/show_bug.cgi?id=105990
--- Comment #4 from Martin Peres ---
I agree. Maybe we could print the list of the clients when this fails? Bonus
points for showing which one is actually master?
--
You are receiving this mail because:
You are the assignee for the bug.___
We are an atomic driver so the gamma LUT should also be exposed as a
CRTC property through the DRM atomic color management. This will also
take care of the legacy path for us.
Signed-off-by: Stefan Schake
---
v2: Use drm_color_lut_size for LUT length
v3: Disable gamma lut when gamma_lut is NULL (
This series adds support for the gamma and CTM properties to VC4.
The CTM support is somewhat limited in that we can only enable it for one
CRTC at a time and coefficients are S0.9 in hardware. The latter seems
good enough for the various color corrections Android offers.
The CTM support in v3 is
We need to access the channel for configuring our CTM hardware.
Signed-off-by: Stefan Schake
---
v3: New in the series
drivers/gpu/drm/vc4/vc4_crtc.c | 33 -
drivers/gpu/drm/vc4/vc4_drv.h | 33 +
2 files changed, 33 insertions(+),
From: Eric Anholt
At least the RGBA expand field we should have been setting, because we
aren't expanding correctly for 565 -> . Other registers are ones
that may be interesting for various projects that have been discussed.
Signed-off-by: Eric Anholt
Cc: Stefan Schake
Acked-by: Stefan Sc
The hardware has a single block for applying a CTM prior to gamma lut.
It can be fed with pixels from one of our CRTC at a time and uses a
matrix with S0.9 scalars. Use private atomic state to reject attempts
from userland to apply CTM for more than one CRTC at a time and reject
matrices with scala
https://bugzilla.kernel.org/show_bug.cgi?id=199357
--- Comment #5 from Harry Wentland (harry.wentl...@amd.com) ---
I've no idea why this causes "flip_done timed out" and locks the system right
now, but we're currently also dealing with some more fallout from that change,
in particular blinking/fli
https://bugs.freedesktop.org/show_bug.cgi?id=105990
Chris Wilson changed:
What|Removed |Added
Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
This is useful for drivers (which will probably be all of them soon)
which need to track state that is exclusive to the topology, and not a
specific connector on said topology. This includes things such as the
link rate and lane count that are shared by all of the connectors on the
topology.
Signe
For a while we actually haven't had any way of retraining MST links with
fallback link parameters like we do with SST. While uncommon, certain
setups such as my Caldigit TS3 + EVGA MST hub require this since
otherwise, they end up getting stuck in an infinite MST retraining loop.
MST retraining is
The current way of handling changing VCPI allocations doesn't make a
whole ton of sense. Since drm_atomic_helper_check_modeset() can be
called multiple times which means that intel_dp_mst_atomic_check() can
also be called multiple times. However, since we make the silly mistake
of trying to free VC
When a DP MST link needs retraining, sometimes the hub will detect that
the current link bw config is impossible and will update it's RX caps in
the DPCD to reflect the new maximum link rate. Currently, we make the
assumption that the RX caps in the dpcd will never change like this.
This means if t
This gives drivers subclassing drm_dp_mst_topology_state the ability to
prepare their topology states for a new hub to be connected whenever
it's detected that the currently connected topology has been
disconnected from the system. We'll need this in order to correctly
track RX capabilities in i915
Since these functions are dealing with an atomic state that needs to be
modified during atomic check and commit, change the naming on this
function to drm_atomic_dp_mst_get_topology_state() since we're the only
one using the function, and it's more consistent with the naming
scheme used in drm_atom
Unlike SST, MST can have far more then a single display hooked up on a
single port. What this also means however, is that if the DisplayPort
link to the top-level MST branch device becomes unstable then every
single branch device also has an unstable link. Additionally, MST has a
few more steps tha
While having the modeset_retry_work in intel_connector makes sense with
SST, this paradigm doesn't make a whole ton of sense when it comes to
MST since we have to deal with multiple connectors. In most cases, it's
more useful to just use the intel_dp struct since it indicates whether
or not we're d
Does what it says on the label, it's a little confusing debugging atomic
check failures otherwise.
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_atomic.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c
There's no reason to track the atomic state three times. Unfortunately,
this is currently what we're doing, and even worse is that there is only
one actually correct state pointer: the one in mst_state->base.state.
mgr->state never seems to be used, along with the one in
mst_state->state.
This con
Latest version of PW series 39642, hopefully this should also actually
come up on intel-gfx and go through CI.
No changes other than rebasing to the current drm-intel-next-queued
Lyude Paul (10):
drm/atomic: Print debug message on atomic check failure
drm/i915: Move DP modeset retry work into
I've been struggling with a problem for a while and I haven't been able to come
up with a clean solution. Rob convinced me to stop complaining and do
_something_ and hopefully this can spur a good discussion.
The scenario is basically this: The MSM GPU wants to manage its own IOMMU
virtual address
Add a list of compatible strings for devices that wish to opt out
of attaching to a DMA domain. This is for devices that prefer to
manage their own IOMMU space for any number of reasons. Returning
ENOTSUPP for attach device will filter down and force
arch_setup_dma_ops() to not set up the iommu DM
Provide individual device drivers the chance to gracefully refuse
to attach a device to the default domain. If the attach_device
op returns -ENOTSUPP don't print a error message and don't set
group->domain but still return success from iommu_group_add_dev().
This allows all the usual APIs to work
https://bugzilla.kernel.org/show_bug.cgi?id=199357
--- Comment #4 from Christian König (christian.koe...@amd.com) ---
Thanks, yeah that is clearly DC (display core).
Harry can you take a look?
--
You are receiving this mail because:
You are watching the assignee of the bug.
Am 11.04.2018 um 19:11 schrieb Robin Murphy:
Now that drm_prime_sg_to_page_addr_arrays() understands the case where
dma_map_sg() has coalesced segments and returns 0 < count < nents, we
can relax the check to only consider genuine failure.
That pattern is repeated in pretty much all drivers usi
Am 11.04.2018 um 19:11 schrieb Robin Murphy:
For dma_map_sg(), DMA API implementations are free to merge consecutive
segments into a single DMA mapping if conditions are suitable, thus the
resulting DMA addresses may be packed into fewer entries than
ttm->sg->nents implies.
drm_prime_sg_to_page_
https://bugs.freedesktop.org/show_bug.cgi?id=103246
--- Comment #2 from i...@yahoo.com ---
I just sow that there is already issue opened for the same/similar issue:
https://github.com/iXit/Mesa-3D/issues/296
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=103246
i...@yahoo.com changed:
What|Removed |Added
Keywords||regression
--- Comment #1 from i...@yah
On 11/04/18 18:11, Robin Murphy wrote:
For dma_map_sg(), DMA API implementations are free to merge consecutive
segments into a single DMA mapping if conditions are suitable, thus the
resulting DMA addresses may be packed into fewer entries than
ttm->sg->nents implies.
drm_prime_sg_to_page_addr_a
https://bugzilla.kernel.org/show_bug.cgi?id=199357
--- Comment #3 from Mathias Tillman (master.ho...@gmail.com) ---
I've just finished running a bisect now, and I have concluded that commit
36cc549d59864b7161f0e23d710c1c4d1b9cf022 (drm/amd/display: disable CRTCs with
NULL FB on their primary plane
https://bugs.freedesktop.org/show_bug.cgi?id=105680
--- Comment #8 from Jose Roberto de Souza ---
Hi Marta did it ran? Should I ask someone else to review and merge?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-deve
For dma_map_sg(), DMA API implementations are free to merge consecutive
segments into a single DMA mapping if conditions are suitable, thus the
resulting DMA addresses may be packed into fewer entries than
ttm->sg->nents implies.
drm_prime_sg_to_page_addr_arrays() does not account for this, meanin
Now that drm_prime_sg_to_page_addr_arrays() understands the case where
dma_map_sg() has coalesced segments and returns 0 < count < nents, we
can relax the check to only consider genuine failure.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
1 file changed, 1 ins
Maxime Ripard writes:
> Hi,
>
> This serie aims at enhancing the support for plane-wide alpha in the
> drivers that are implementing it at the moment, by turning it into a
> generic property and converting the drivers (rcar-du and atmel-hclcdc). It
> also introduces support for it in the sun4i dr
https://bugs.freedesktop.org/show_bug.cgi?id=104216
--- Comment #24 from Germano Massullo ---
Just got a burst of very interesting comments in Firefox bugreport
from
https://bugzilla.mozilla.org/show_bug.cgi?id=1421353#c19
to comment number 21
--
You are receiving this mail because:
You are the
On 2018-04-10 06:26 PM, Cyr, Aric wrote:> > My guess is they prefer to
“do nothing” and let driver/HW manage it,
> otherwise you exempt all existing games from supporting adaptive sync
> without a rewrite or update.
Nobody is saying adaptive sync should only work with explicit target
presentation t
On 11/04/18 15:33, Sinan Kaya wrote:
On 4/11/2018 8:03 AM, Robin Murphy wrote:
On 10/04/18 21:59, Sinan Kaya wrote:
Code is expecing to observe the same number of buffers returned
from dma_map_sg() function compared to
sg_alloc_table_from_pages(). This doesn't hold true universally
especially f
The LVDS signal integrity is only guaranteed when the correct enable
sequence (first IPU DI, then LDB) is used. If the LDB display output was
active before the imx-drm driver is loaded (like when a bootsplash was
active) the DI will be disabled by the full IPU reset we do when loading
the driver. T
If the second LVDS channel has been disabled in the DT when using dual-channel
mode we should not print a warning.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/imx/imx-ldb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/dr
On 2018-04-10 09:02 PM, Laura Abbott wrote:
> There's an ongoing effort to remove VLAs[1] from the kernel to eventually
> turn on -Wvla. Switch to a constant value that covers all hardware.
>
> [1] https://lkml.org/lkml/2018/3/7/621
>
> Signed-off-by: Laura Abbott
> ---
> v2: Switch to a larger si
The patch adding support for the AUO P320HVN03 panel was written against a
preliminary datasheet, which specified JEIDA data ordering. Testing with
real hardware has shown that the actually used data ordering is SPWG.
Fixes: 70c0d5b783f5 (drm/panel: simple: add support for AUO P320HVN03)
Signed-of
The steps for flattening a scene on a dedicated crtc are:
1. Find an available and unused crtc(the display connector is
disconnected).
2. Copy layers from active composition.
3. Plan layers of copy on the unused crtc. This is realized by using a
newly created DrmDisplayCompositor object.
4. Commit
Add logic for finding a suitable writeback connector, there are two
possibilities for finding an usable writeback connector:
1) Attached to the same CRTC as the display and can function
concurrently with the display connector.
2) On a different CRTC and the display connector is not used (state
Flatten scene on the same CRTC as the one driving the display.
The active composition is played back to the display with a buffer
attached to the writeback connector.
Then we build a composition that has only one plane enabled and that
uses the result of the writeback as the input.
Signed-off-by:
Add a vsync worker that calls back into the DrmDisplayCompositor,
for now at every 60 vsyncs if the scene does not change we trigger
the flattening of the scene using the writeback connector.
Other, more complex and proper heuristics could be implemented later
on.
Signed-off-by: Alexandru Gheorghe
There is a lot of boilerplate for creating an initialized
drmdisplaycomposition. This patch gathers that in a separate method.
Signed-off-by: Alexandru Gheorghe
---
drmdisplaycompositor.cpp | 23 +++
drmdisplaycompositor.h | 2 ++
2 files changed, 25 insertions(+)
diff --
ApplyFrame holds the lock just when it swaps the value of
active_composition_, in a multithread context we could end up in a
situation where something is shown on the screen, but something else
is set in active_composition_. Fix it by holding the lock during
CommitFrame.
Signed-off-by: Alexandru G
Add utility functions to copy the DrmHwcLayer and DrmCompositionPlanes
from another DrmDisplayComposition.
Signed-off-by: Alexandru Gheorghe
---
drmdisplaycomposition.cpp | 29 +
drmdisplaycomposition.h | 3 +++
2 files changed, 32 insertions(+)
diff --git a/drmdi
Currently Prepareframebuffer uses the mode of the connected connector
to decide how big the buffer should be, however when using the
drmdisplaycompositor just for flattening, the mode had not been set
yet, so we need a way to pass the desired buffer sizes.
Signed-off-by: Alexandru Gheorghe
---
d
In the current implementation TryEncoderForDisplay just looks
at the crtc linked to the display, if that's not assigned to
a display it means the encoder could be used, otherwise iterate
to the list of possible_crtcs and find one which is not used.
This logic works fine when you have just one enco
When writeback connectors are available assign them to displays, in
order to be able to use them for flattening of the current displayed
scene. The pipeline for each display will look like this:
CRTC encoder display connector.
|--- writeback enc -- writeback connector.
Writeback connector is a special case of connector, which can be
linked to a CRTC in order to get the result of the composition back to
a memory buffer. This had not been merged to the mainline kernel yet,
latest version of the kernel patches could be found here [1].
[1] https://lists.freedesktop.
When doing flattening of a composition on a different CRTC we need to be
able to clone a layer in order to import it and then pass it to another CRTC.
Signed-off-by: Alexandru Gheorghe
---
drmhwcomposer.h | 1 +
hwcutils.cpp| 11 +++
2 files changed, 12 insertions(+)
diff --git a/d
drmModeEncoder has a field called possible_clones. It's a bit mask
which tells if the encoder could be simultaneously connected, to the
same CRTC, with the encoders specified in the possible_clones mask.
Signed-off-by: Alexandru Gheorghe
---
drmencoder.cpp | 8
drmencoder.h | 4 ++
1 - 100 of 166 matches
Mail list logo
