https://bugs.freedesktop.org/show_bug.cgi?id=106671
--- Comment #23 from Alan W. Irwin ---
Created attachment 141872
--> https://bugs.freedesktop.org/attachment.cgi?id=141872=edit
tarball containing daemon.log, messages, kern.log, syslog, and dmesg output
The previously described uptime test
https://bugs.freedesktop.org/show_bug.cgi?id=108194
Bug ID: 108194
Summary: Civilization VI - Animated leader characters small
black squares artifacts
Product: Mesa
Version: 18.2
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=101739
Marek Olšák changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Hi Greg,
Nothing too much happening at this point,
3 i915 fixes:
compressed error handling zlib fix
compiler warning cleanup
and a minor code cleanup
2 tda9950:
Two fixes for the HDMI CEC
1 exynos:
A fix required for IOMMU interaction.
Thanks,
Dave.
drm-fixes-2018-10-04:
drm exynos, tda9950
https://bugs.freedesktop.org/show_bug.cgi?id=99923
Marek Olšák changed:
What|Removed |Added
CC||mar...@gmail.com
--- Comment #36 from
Hi, Dave:
This include hdmi output support for mt2701 and mt7623.
Regards,
CK
The following changes since commit
87c2ee740c07f1edae9eec8bc45cb9b32a68f323:
Merge branch 'drm-next-4.20' of
git://people.freedesktop.org/~agd5f/linux into drm-next (2018-09-28
09:48:40 +1000)
are available in
On Mon, Oct 01, 2018 at 09:23:38AM +0200, Daniel Vetter wrote:
> On Mon, Sep 24, 2018 at 02:08:14PM -0700, Radhakrishna Sripada wrote:
> > At times 12bpc HDMI cannot be driven due to faulty cables, dongles
> > level shifters etc. To workaround them we may need to drive the output
> > at a lower
On Wed, Oct 03, 2018 at 01:00:03PM -0700, Matthew Wilcox wrote:
> On Thu, Oct 04, 2018 at 12:28:54AM +0530, Souptick Joarder wrote:
> > These are the approaches which could have been taken to handle
> > this scenario -
> >
> > * Replace vm_insert_page with vmf_insert_page and then write few
> >
https://bugs.freedesktop.org/show_bug.cgi?id=108110
Chris Wilson changed:
What|Removed |Added
Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
Daniel Vetter writes:
> drm_plane_helper_disable is a non-atomic drivers only function, and
> will blow up (since no one passes the locking context it needs).
>
> Atomic drivers which want to quiescent their hw on unload should
> use drm_atomic_helper_shutdown() instead.
>
> v2: Rebase.
I've
Hi Dave,
Here goes drm-intel-fixes-2018-10-03:
There's one fix for our zlib incomlete Z_FINISH on our error state handling,
plus a compilation warning fix and a tiny code clean up.
Thanks,
Rodrigo.
The following changes since commit 17b57b1883c1285f3d0dc2266e8f79286a7bef38:
Linux 4.19-rc6
On Thu, Sep 27, 2018 at 10:10:07AM +0800, Bin Meng wrote:
> On Thu, Sep 27, 2018 at 12:57 AM Bjorn Helgaas wrote:
> > On Wed, Sep 26, 2018 at 08:14:01AM -0700, Bin Meng wrote:
> > > Add more PCI IDs to the Intel GPU "spurious interrupt" quirk table,
> > > which are known to break.
> >
> > Do you
Hi Dave,
We've cut over to misc-next-fixes for 4.20, so just one patch this week. It's
Neil's fix for mali binary driver.
drm-misc-next-fixes-2018-10-03:
- Add EXPERT config option to allow phys mem leak from fbdev for blob drivers
(Neil)
Cc: Neil Armstrong
Cheers, Sean
The following
On Wed, Oct 3, 2018 at 6:13 PM Daniel Vetter wrote:
>
> On Wed, Oct 03, 2018 at 05:49:32PM +0200, Noralf Trønnes wrote:
> >
> >
> > Den 02.10.2018 22.58, skrev Arnd Bergmann:
> > > The variable is now referenced unconditionally, but still
> > > declared in an #ifdef:
> > >
> > >
On Tue, Oct 02, 2018 at 02:50:55PM -0700, Manasi Navare wrote:
> This patch explains the DRM_MODE_PROP_IMMUTABLE flag a bit better
> by telling which function to call if kernel wants to update
> drm object's immutable properties.
>
> Suggested-by: Daniel Vetter
> Cc: Daniel Vetter
>
Hi Noralf,
Le 08/09/2018 15:46, Noralf Trønnes a écrit :
> The CMA helper is already using the drm_fb_helper_generic_probe part of
> the generic fbdev emulation. This patch makes full use of the generic
> fbdev emulation by using its drm_client callbacks. This means that
>
Le 28/09/2018 14:05, Neil Armstrong a écrit :
> Since "drm/fb: Stop leaking physical address", the default behaviour of
> the DRM fbdev emulation is to set the smem_base to 0 and pass the new
> FBINFO_HIDE_SMEM_START flag.
>
> The main reason is to avoid leaking physical addresse to user-space,
Alexandru-Cosmin Gheorghe kirjoitti 3.10.2018 klo 20.18:
On Wed, Oct 03, 2018 at 02:31:08PM +0300, Juha-Pekka Heikkila wrote:
Hi Alex,
For my patches there seems limited interest to get them merged before IGT
support these modes..I'm not holding my breath for this.
I'm interested if that
On Wed, Oct 03, 2018 at 11:42:14AM -0700, Radhakrishna Sripada wrote:
> On Mon, Oct 01, 2018 at 04:48:01PM +0300, Ville Syrjälä wrote:
> > On Mon, Sep 24, 2018 at 02:08:15PM -0700, Radhakrishna Sripada wrote:
> > > Use the newly added "max bpc" connector property to limit pipe bpp.
> > >
> > >
On Mon, Oct 01, 2018 at 04:48:01PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 24, 2018 at 02:08:15PM -0700, Radhakrishna Sripada wrote:
> > Use the newly added "max bpc" connector property to limit pipe bpp.
> >
> > V3: Use drm_connector_state to access the "max bpc" property
> > V4: Initialize
On Wed, Oct 03, 2018 at 10:41:20AM +0200, Daniel Vetter wrote:
> On Tue, Oct 02, 2018 at 10:49:17AM -0400, Harry Wentland wrote:
> >
> >
> > On 2018-10-01 03:15 AM, Daniel Vetter wrote:
> > > On Mon, Sep 24, 2018 at 02:15:34PM -0400, Nicholas Kazlauskas wrote:
> > >> These patches are part of a
Yes, Andrey has commit rights.
Marek
On Wed, Oct 3, 2018 at 10:34 AM Christian König
wrote:
>
> Thanks for keeping working on this.
>
> Series is Reviewed-by: Christian König as well.
>
> Do you now have commit rights?
>
> Christian.
>
> Am 02.10.2018 um 22:47 schrieb Marek Olšák:
> > For the
On Wed, Oct 03, 2018 at 02:31:08PM +0300, Juha-Pekka Heikkila wrote:
> Hi Alex,
>
> For my patches there seems limited interest to get them merged before IGT
> support these modes..I'm not holding my breath for this.
I'm interested if that counts.
I asked the same question on the
drm fbdev emulation doesn't support changing the pixel format at all,
so reject all pixel format changing requests.
Cc: sta...@vger.kernel.org
Signed-off-by: Eugeniy Paltsev
---
Changes v1->v2:
* Reject all pixel format changing request, not just the invalid ones.
On Wed, Oct 03, 2018 at 10:35:18AM -0300, Rodrigo Siqueira wrote:
> On 10/03, Daniel Vetter wrote:
> > Typed up all the items Rodrigo capture at the vkms workshop at
> > xdc2018:
> >
> > https://etherpad.net/p/vkms_todo
> >
> > v2: Review from Rodrigo.
> > - Add eBPF for atomic check, I forgot
https://bugzilla.kernel.org/show_bug.cgi?id=201015
--- Comment #10 from Aleksandr Mezin (mezin.alexan...@gmail.com) ---
After recent updates, the issue went away. But I'm not sure what exactly has
changed. I tried reverting the kernel (to 4.19-rc3) and libdrm, but still can't
trigger it anymore.
On Wed, Oct 03, 2018 at 05:50:52PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Print the plane hw state readout results in the common format
> we already use for pipes and encoders. Also print some clearer
> debug messages when we disable planes during the early phases
> of state
On Wed, Oct 03, 2018 at 05:49:32PM +0200, Noralf Trønnes wrote:
>
>
> Den 02.10.2018 22.58, skrev Arnd Bergmann:
> > The variable is now referenced unconditionally, but still
> > declared in an #ifdef:
> >
> > drivers/gpu/drm/imx/imx-drm-core.c: In function 'imx_drm_bind':
> >
On Wed, Oct 03, 2018 at 05:50:17PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> When we decide that a plane is attached to the wrong pipe we try
> to turn off said plane. However we are passing around the crtc we
> think that the plane is supposed to be using rather than the crtc
> it
https://bugzilla.kernel.org/show_bug.cgi?id=201163
Ricardo Ribalda (ricardo.riba...@gmail.com) changed:
What|Removed |Added
Hardware|All |x86-64
--
On Wed, Oct 03, 2018 at 05:29:34PM +0200, Daniel Vetter wrote:
> On Wed, Oct 3, 2018 at 4:30 PM Eugeniy Paltsev
> wrote:
> >
> > On Wed, 2018-10-03 at 15:30 +0300, Ville Syrjälä wrote:
> > > On Wed, Oct 03, 2018 at 01:36:00PM +0200, Daniel Vetter wrote:
> > > > On Wed, Oct 3, 2018 at 1:05 PM
Den 02.10.2018 22.58, skrev Arnd Bergmann:
The variable is now referenced unconditionally, but still
declared in an #ifdef:
drivers/gpu/drm/imx/imx-drm-core.c: In function 'imx_drm_bind':
drivers/gpu/drm/imx/imx-drm-core.c:264:6: error: 'legacyfb_depth' undeclared
(first use in this
https://bugs.freedesktop.org/show_bug.cgi?id=107213
--- Comment #21 from Shmerl ---
I tested it with Intel GPU recently, and it doesn't crash. So it's amdgpu
specific.
--
You are receiving this mail because:
You are the assignee for the bug.___
On Wed, Oct 3, 2018 at 4:30 PM Eugeniy Paltsev
wrote:
>
> On Wed, 2018-10-03 at 15:30 +0300, Ville Syrjälä wrote:
> > On Wed, Oct 03, 2018 at 01:36:00PM +0200, Daniel Vetter wrote:
> > > On Wed, Oct 3, 2018 at 1:05 PM Eugeniy Paltsev
> > > wrote:
> > > >
> > > > Validate requested pixel format
From: Ville Syrjälä
Print the plane hw state readout results in the common format
we already use for pipes and encoders. Also print some clearer
debug messages when we disable planes during the early phases
of state readout/sanitization.
v2: Rebase
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
When we decide that a plane is attached to the wrong pipe we try
to turn off said plane. However we are passing around the crtc we
think that the plane is supposed to be using rather than the crtc
it is currently using. That doesn't work all that well because
we may have to
From: Ville Syrjälä
Plane sanitation needs vblank interrupts (on account of CxSR disable).
So let's restore vblank interrupts earlier.
v2: Make it actually build
v3: Add comment to explain why we need this (Daniel)
Cc: sta...@vger.kernel.org
Cc: Dennis
Tested-by: Dennis
Bugzilla:
Thanks for keeping working on this.
Series is Reviewed-by: Christian König as well.
Do you now have commit rights?
Christian.
Am 02.10.2018 um 22:47 schrieb Marek Olšák:
For the series:
Reviewed-by: Marek Olšák
Marek
On Fri, Sep 28, 2018 at 10:46 AM Andrey Grodzovsky
wrote:
Seems like
On Wed, Oct 03, 2018 at 10:53:11AM +0200, Daniel Vetter wrote:
> On Tue, Oct 02, 2018 at 05:21:36PM +0300, Ville Syrjälä wrote:
> > On Tue, Oct 02, 2018 at 02:11:34PM +0200, Daniel Vetter wrote:
> > > On Mon, Oct 01, 2018 at 05:31:20PM +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > >
On Wed, 2018-10-03 at 15:30 +0300, Ville Syrjälä wrote:
> On Wed, Oct 03, 2018 at 01:36:00PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 3, 2018 at 1:05 PM Eugeniy Paltsev
> > wrote:
> > >
> > > Validate requested pixel format against bits_per_pixel to reject
> > > invalid formats with
At the moment, the check of tcon->panel to be valid is wrong. IS_ERR()
has been used, but that macro doesn't check if tcon->panel pointer is
null or not, but check if tcon->panel is between -1 and -4095(MAX_ERRNO).
Remove IS_ERR() from tcon->panel checking and let "if (tcon->panel)" as
condition
If using tcon with VGA, tcon->panel will be null(0), this will cause
segmentation fault when trying to dereference tcon->panel->connector.
Add tcon->panel null check before calling
sun4i_tcon0_mode_set_dithering().
Signed-off-by: Giulio Benetti
Fixes: f11adcecbd5f ("drm/sun4i: tcon: Add
Am 03.10.2018 um 11:06 schrieb Daniel Vetter:
On Wed, Oct 03, 2018 at 08:54:44AM +, Koenig, Christian wrote:
Am 03.10.2018 um 09:14 schrieb Daniel Vetter:
On Sat, Sep 29, 2018 at 9:27 AM Koenig, Christian
wrote:
This is work in progress.
I published patches to enable DMA_buf P2P a few
On 10/03, Daniel Vetter wrote:
> Typed up all the items Rodrigo capture at the vkms workshop at
> xdc2018:
>
> https://etherpad.net/p/vkms_todo
>
> v2: Review from Rodrigo.
> - Add eBPF for atomic check, I forgot it.
> - Improve spelling.
>
> Signed-off-by: Daniel Vetter
> Cc: Gustavo Padovan
On Wed, Oct 03, 2018 at 09:57:15AM -0300, Rodrigo Siqueira wrote:
> Hi,
>
> I just added some minor reviews below.
>
> Also, did you give up to add the eBPF task?
I forgot to add that. Will fix.
>
> Best Regards
>
> Allow Berkeley Packet Filter (BPF), use cases for atomic check:
>
> On
Typed up all the items Rodrigo capture at the vkms workshop at
xdc2018:
https://etherpad.net/p/vkms_todo
v2: Review from Rodrigo.
- Add eBPF for atomic check, I forgot it.
- Improve spelling.
Signed-off-by: Daniel Vetter
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc: Haneen
On Wed, Oct 03, 2018 at 11:18:27AM +0200, Daniel Vetter wrote:
> Well except the destroy helper, which isn't really a primary helper
> but generally useful, if mislabelled.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_plane_helper.c | 85 --
>
On Wed, Oct 03, 2018 at 11:18:25AM +0200, Daniel Vetter wrote:
> From: Thomas Hellstrom
>
> Use the correct helper and also return early on helper
> success rather than on helper failure.
>
> Also explicitly return 0 in the case of no fb.
>
> v2: Check for !fb after updating state->visible
On Wed, Oct 03, 2018 at 11:18:24AM +0200, Daniel Vetter wrote:
> With armada the last bigger driver that realistically needed these to
> convert from legacy kms to atomic is converted. These helpers have
> been broken more often than not the past 2 years, and as this little
> patch series shows,
On Wed, Oct 03, 2018 at 11:18:23AM +0200, Daniel Vetter wrote:
> drm_plane_helper_disable is a non-atomic drivers only function, and
> will blow up (since no one passes the locking context it needs).
>
> Atomic drivers which want to quiescent their hw on unload should
> use
On Wed, Oct 03, 2018 at 11:18:22AM +0200, Daniel Vetter wrote:
> drm_plane_helper_disable is a non-atomic drivers only function, and
> will blow up (since no one passes the locking context it needs).
>
> Atomic drivers which want to quiescent their hw on unload should
> use
On Wed, Oct 03, 2018 at 11:17:26AM +0200, Daniel Vetter wrote:
> drm_plane_helper_disable is a non-atomic drivers only function, and
> will blow up (since no one passes the locking context it needs).
>
> Atomic drivers which want to quiescent their hw on unload should
> use
On Wed, Oct 03, 2018 at 11:16:44AM +0200, Daniel Vetter wrote:
> drm_plane_helper_disable is a non-atomic drivers only function, and
> will blow up (since no one passes the locking context it needs).
>
> Atomic drivers which want to quiescent their hw on unload should
> use
Hi,
I just added some minor reviews below.
Also, did you give up to add the eBPF task?
Best Regards
Allow Berkeley Packet Filter (BPF), use cases for atomic check:
On 10/03, Daniel Vetter wrote:
> Typed up all the items Rodrigo capture at the vkms workshop at
> xdc2018:
>
>
On Wed, Oct 03, 2018 at 01:36:00PM +0200, Daniel Vetter wrote:
> On Wed, Oct 3, 2018 at 1:05 PM Eugeniy Paltsev
> wrote:
> >
> > Validate requested pixel format against bits_per_pixel to reject
> > invalid formats with subcomponents length sum is greater than requested
> > bits_per_pixel.
> >
> >
Typed up all the items Rodrigo capture at the vkms workshop at
xdc2018:
https://etherpad.net/p/vkms_todo
Signed-off-by: Daniel Vetter
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc: Haneen Mohammed
Cc: Rodrigo Siqueira
---
Documentation/gpu/vkms.rst | 87
Il 03/10/2018 11:43, Chen-Yu Tsai ha scritto:
On Wed, Oct 3, 2018 at 5:59 AM Giulio Benetti
wrote:
At the moment, the check of tcon->panel to be valid is wrong. IS_ERR()
has been used, but that macro doesn't check if tcon->panel pointer is
null or not, but check if tcon->panel is between -1
On Wed, Oct 3, 2018 at 1:05 PM Eugeniy Paltsev
wrote:
>
> Validate requested pixel format against bits_per_pixel to reject
> invalid formats with subcomponents length sum is greater than requested
> bits_per_pixel.
>
> weston 5.0.0 with fbdev backend tries to set up an ARGB x8r8g8b8 pixel
>
Hi Alex,
For my patches there seems limited interest to get them merged before
IGT support these modes..I'm not holding my breath for this.
https://lists.freedesktop.org/archives/intel-gfx/2018-September/174877.html
/Juha-Pekka
On 02.10.2018 18:00, Alexandru-Cosmin Gheorghe wrote:
Hi,
How
Hi,
> Andreas Färber hat am 2. Oktober 2018 um 16:33 geschrieben:
>
>
> Hi Stefan and Daniel,
>
> Am 02.10.18 um 11:48 schrieb Stefan Wahren:
> > Hi Daniel,
> SNIP
> > personally i didn't know this option before this issue, but i cannot
> > speak for all the distributions. I checked Raspbian
Validate requested pixel format against bits_per_pixel to reject
invalid formats with subcomponents length sum is greater than requested
bits_per_pixel.
weston 5.0.0 with fbdev backend tries to set up an ARGB x8r8g8b8 pixel
format without bits_per_pixel updating. So it can request
x8r8g8b8 with
On 10/1/2018 11:43 PM, Jordan Crouse wrote:
On Mon, Oct 01, 2018 at 06:01:38PM +0530, Sharat Masetty wrote:
This patch changes to kzalloc and avoids setting individual submit
struct fields to zero manually.
I don't think this one is worth it. There are so many members in submit and so
few
Hi Dave,
These are the latest changes I have for Mali DP. Please
note that due to drm-next lagging behind drm-fixes at this
moment, the first two patches ("drm: mali-dp: Call
drm_crtc_vblank_reset on device init" and "drm/malidp: Fix
writeback in NV12") will be skipped if you backport v4.19-rc6
Thanks for the review comments Jordan. I tried to answer a few queries..
please check.
On 10/2/2018 12:32 AM, Jordan Crouse wrote:
On Mon, Oct 01, 2018 at 06:01:41PM +0530, Sharat Masetty wrote:
This patch hooks up the DRM gpu scheduler to the msm DRM driver. The
most noticeable changes to
On Wed, Oct 3, 2018 at 5:59 AM Giulio Benetti
wrote:
>
> At the moment, the check of tcon->panel to be valid is wrong. IS_ERR()
> has been used, but that macro doesn't check if tcon->panel pointer is
> null or not, but check if tcon->panel is between -1 and -4095(MAX_ERRNO).
>
> Remove IS_ERR()
On Wed, Oct 03, 2018 at 02:57:47PM +0800, Y.C. Chen wrote:
> From: "Y.C. Chen"
>
> The value of pitches is not correct while calling mode_set.
> The issue we found so far on following system:
> - Debian8 with XFCE Desktop
> - Ubuntu with KDE Desktop
> - SUSE15 with KDE Desktop
>
>
On Tue, Oct 02, 2018 at 06:34:39PM +0300, Ville Syrjälä wrote:
> On Tue, Oct 02, 2018 at 03:35:16PM +0200, Daniel Vetter wrote:
> > These do absolutely nothing for atomic drivers.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Alexey Brodkin
> > ---
> > drivers/gpu/drm/arc/arcpgu_crtc.c | 2 --
>
From: Thomas Hellstrom
Use the correct helper and also return early on helper
success rather than on helper failure.
Also explicitly return 0 in the case of no fb.
v2: Check for !fb after updating state->visible (Ville).
Signed-off-by: Thomas Hellstrom (v1)
Reported-by: Dan Carpenter
With armada the last bigger driver that realistically needed these to
convert from legacy kms to atomic is converted. These helpers have
been broken more often than not the past 2 years, and as this little
patch series shows, tricked a bunch of people into using the wrong
helpers for their
drm_plane_helper_disable is a non-atomic drivers only function, and
will blow up (since no one passes the locking context it needs).
Atomic drivers which want to quiescent their hw on unload should
use drm_atomic_helper_shutdown() instead.
v2: Rebase.
Signed-off-by: Daniel Vetter
Cc: Eric
drm_plane_helper_disable is a non-atomic drivers only function, and
will blow up (since no one passes the locking context it needs).
Atomic drivers which want to quiescent their hw on unload should
use drm_atomic_helper_shutdown() instead.
Signed-off-by: Daniel Vetter
Cc: Shawn Guo
---
Well except the destroy helper, which isn't really a primary helper
but generally useful, if mislabelled.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_plane_helper.c | 85 --
include/drm/drm_plane_helper.h | 10
2 files changed, 11 insertions(+), 84
It's for legacy drivers only (atomic ones should use
drm_atomic_helper_check_plane_state() instead), and there's no users
left except the one in the primary plane helpers.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_plane_helper.c | 49 +++---
drm_plane_helper_disable is a non-atomic drivers only function, and
will blow up (since no one passes the locking context it needs).
Atomic drivers which want to quiescent their hw on unload should
use drm_atomic_helper_shutdown() instead.
The sti cleanup code seems supremely confused:
- In the
drm_plane_helper_disable is a non-atomic drivers only function, and
will blow up (since no one passes the locking context it needs).
Atomic drivers which want to quiescent their hw on unload should
use drm_atomic_helper_shutdown() instead.
Signed-off-by: Daniel Vetter
Cc: Rob Clark
Cc: Rajesh
On Tue, Oct 02, 2018 at 11:29:11PM +0800, Kai-Heng Feng wrote:
> There's another panel that reports "DFP 1.x compliant TMDS" but it
> supports 6bpc instead of 8 bpc.
>
> Apply 6 bpc quirk for the panel to fix it.
>
> BugLink: https://bugs.launchpad.net/bugs/1794387
> Cc: # v4.8+
>
On Tue, Oct 02, 2018 at 04:49:30PM +, Thomas Hellstrom wrote:
> Hi, Daniel,
>
> On 10/02/2018 03:35 PM, Daniel Vetter wrote:
> > The idea behind allowing drivers to override legacy ioctls (instead of
> > using the generic implementations unconditionally) is to handle bugs
> > in old
On Tue, Oct 02, 2018 at 06:40:52PM +0300, Ville Syrjälä wrote:
> On Tue, Oct 02, 2018 at 03:35:11PM +0200, Daniel Vetter wrote:
> > We already have a separate overview doc for this, makes sense to
> > untangle it from the overall atomic helpers.
> >
> > v2: Rebase
> >
> > v3: Rebase more.
>
>
On Tue, Oct 02, 2018 at 04:53:12PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Tuesday, 2 October 2018 16:35:10 EEST Daniel Vetter wrote:
> > It's the default. The exported version was kinda a transition state,
> > before we made this the default.
> >
> > To
On Wed, Oct 03, 2018 at 08:54:44AM +, Koenig, Christian wrote:
> Am 03.10.2018 um 09:14 schrieb Daniel Vetter:
> > On Sat, Sep 29, 2018 at 9:27 AM Koenig, Christian
> > wrote:
> >> This is work in progress.
> >>
> >> I published patches to enable DMA_buf P2P a few months ago, but now I'm
>
On Tue, Oct 02, 2018 at 12:27:02PM +0200, Horst Balthasar wrote:
> Hallo,
>
> as a software developer at the company "imed medical" in Neu-Ulm" I am
> working with the intel graphics driver
>
> under Debian.
>
> The aim is to output continuous 2D images with the "libdrm" graphic library
> on
Am 03.10.2018 um 09:14 schrieb Daniel Vetter:
> On Sat, Sep 29, 2018 at 9:27 AM Koenig, Christian
> wrote:
>> This is work in progress.
>>
>> I published patches to enable DMA_buf P2P a few months ago, but now I'm
>> waiting for the PCI subsystem to pick up core support for this.
>>
>> I can
On Tue, Oct 02, 2018 at 05:21:36PM +0300, Ville Syrjälä wrote:
> On Tue, Oct 02, 2018 at 02:11:34PM +0200, Daniel Vetter wrote:
> > On Mon, Oct 01, 2018 at 05:31:20PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > When we decide that a plane is attached to the wrong pipe we
On Tue, Oct 02, 2018 at 04:30:30PM +, Deepak Singh Rawat wrote:
> > On Thu, Sep 27, 2018 at 05:30:07PM -0700, Deepak Rawat wrote:
> > > From: Rob Clark
> > >
> > > Add an atomic helper to implement dirtyfb support. This is needed to
> > > support DSI command-mode panels with x11 userspace
On Tue, Oct 02, 2018 at 10:49:17AM -0400, Harry Wentland wrote:
>
>
> On 2018-10-01 03:15 AM, Daniel Vetter wrote:
> > On Mon, Sep 24, 2018 at 02:15:34PM -0400, Nicholas Kazlauskas wrote:
> >> These patches are part of a proposed new interface for supporting variable
> >> refresh rate via DRM
Hi
I'm curious to know whether this will/could work over PRIME
If the discrete card is rendering slower than the display's frequency could
the frequency be dropped on integrated display? I think there are laptops
that have freesync now
Cheers
Mike
On Mon, 1 Oct 2018 at 08:15 Daniel Vetter
On Wed, Oct 03, 2018 at 06:39:00AM +, Lisovskiy, Stanislav wrote:
> On Tue, 2018-10-02 at 15:28 +, Alexandru-Cosmin Gheorghe wrote:
> > Hi,
> >
> > On Tue, Oct 02, 2018 at 02:15:42PM +0300, Stanislav Lisovskiy wrote:
> > > v5: This is YUV444 packed format same as AYUV, but without alpha,
On Wed, Oct 3, 2018 at 5:59 AM Giulio Benetti
wrote:
>
> If using tcon with VGA, tcon->panel will be null(0), this will cause
> segmentation fault when trying to dereference tcon->panel->connector.
>
> Add tcon->panel null check before calling
> sun4i_tcon0_mode_set_dithering().
>
>
At the moment, the check of tcon->panel to be valid is wrong. IS_ERR()
has been used, but that macro doesn't check if tcon->panel pointer is
null or not, but check if tcon->panel is between -1 and -4095(MAX_ERRNO).
Remove IS_ERR() from tcon->panel checking and let "if (tcon->panel)" as
condition
Hi Stefan,
> [add Peter and Andreas]
>
>
> Am 02.10.2018 um 10:44 schrieb Daniel Vetter:
> > On Mon, Oct 01, 2018 at 06:21:23PM +0200, Stefan Wahren wrote:
> >> Hi,
> >>
> >>> Sergey Suloev hat am 1. Oktober 2018 um 12:17
> >>> geschrieben:
> >>>
> >>>
> >>> Hi, Stefan,
> >>>
> >>>
> >>> On
On Tuesday 02 October 2018 06:50 PM, Maxime Ripard wrote:
On Thu, Sep 27, 2018 at 11:15:50PM +0530, Jagan Teki wrote:
On Thu, Sep 27, 2018 at 10:28 PM Maxime Ripard
wrote:
On Thu, Sep 27, 2018 at 05:18:45PM +0530, Jagan Teki wrote:
TCON DRQ set bits for non-burst DSI mode can computed via
Il 01/10/2018 11:36, Dan Carpenter ha scritto:
Hello Giulio Benetti,
The patch 490cda5a3c82: "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE
checking if panel is used." from Jul 18, 2018, leads to the following
static checker warning:
drivers/gpu/drm/sun4i/sun4i_tcon.c:558
From: "Y.C. Chen"
The value of pitches is not correct while calling mode_set.
The issue we found so far on following system:
- Debian8 with XFCE Desktop
- Ubuntu with KDE Desktop
- SUSE15 with KDE Desktop
Signed-off-by: Y.C. Chen
---
drivers/gpu/drm/ast/ast_mode.c | 1 +
1 file changed, 1
On Tue, Oct 02, 2018 at 09:52:51AM +0200, Patrik Jakobsson wrote:
> Hi Phillip,
> This is executed while holding a spinlock so we cannot sleep here.
> This is true for send_pkg_done() as well.
>
> - Patrik
Dear Patrik,
Oops, sorry. I'll try and be more observant in future. Just picked up on
On Tue, Oct 02, 2018 at 01:43:28PM +0200, Gerd Hoffmann wrote:
> On Wed, Sep 26, 2018 at 09:04:55AM -0700, Matthew Wilcox wrote:
> > On Wed, Sep 26, 2018 at 09:00:31AM -0700, Matthew Wilcox wrote:
> > > @@ -59,6 +59,7 @@ static int virtio_gpu_context_create(struct
> > > virtio_gpu_device *vgdev,
There's another panel that reports "DFP 1.x compliant TMDS" but it
supports 6bpc instead of 8 bpc.
Apply 6 bpc quirk for the panel to fix it.
BugLink: https://bugs.launchpad.net/bugs/1794387
Cc: # v4.8+
Signed-off-by: Kai-Heng Feng
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3
Hallo,
as a software developer at the company "imed medical" in Neu-Ulm" I am
working with the intel graphics driver
under Debian.
The aim is to output continuous 2D images with the "libdrm" graphic
library on the screen. We use the Intel i915 driver.
Since I'm not so familiar with the
On Sat, Sep 29, 2018 at 9:27 AM Koenig, Christian
wrote:
>
> This is work in progress.
>
> I published patches to enable DMA_buf P2P a few months ago, but now I'm
> waiting for the PCI subsystem to pick up core support for this.
>
> I can prepare you a branch based on current upstream kernel
Hi Stefan and Daniel,
Am 02.10.18 um 11:48 schrieb Stefan Wahren:
> Hi Daniel,
>
> [add Peter and Andreas]
>
> Am 02.10.2018 um 10:44 schrieb Daniel Vetter:
>> On Mon, Oct 01, 2018 at 06:21:23PM +0200, Stefan Wahren wrote:
Sergey Suloev hat am 1. Oktober 2018 um 12:17
geschrieben:
Il 02/10/2018 15:26, Giulio Benetti ha scritto:
Il 01/10/2018 11:36, Dan Carpenter ha scritto:
Hello Giulio Benetti,
The patch 490cda5a3c82: "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE
checking if panel is used." from Jul 18, 2018, leads to the following
static checker warning:
1 - 100 of 103 matches
Mail list logo
