Hi Noralf,
On Fri, Sep 08, 2017 at 05:07:19PM +0200, Noralf Trønnes wrote:
> This adds device unplug support to drm_fb_helper, drm_fb_cma_helper
> (fbdev) and tinydrm.
>
> There are several changes in this version:
>
> I've used Daniel's idea of protecting drm_device.unplugged with srcu to
> pro
https://bugs.freedesktop.org/show_bug.cgi?id=100387
--- Comment #12 from aceman ---
Try looking for DRI driver name or VDPAU driver name in Xorg.log.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
d
On Fri, Sep 8, 2017 at 10:32 AM, Sean Paul wrote:
> Now that we have the DRM_DEV_* variants, we should use them.
>
> Signed-off-by: Sean Paul
Applied to -misc-next with danvet's R-b.
Sean
> ---
> Documentation/gpu/todo.rst | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a
Linus Walleij writes:
> This makes use of the drm_simple_display_pipe_attach_bridge()
> call and removes the two calls removing the bridge, which were
> erroneous: they unregister the bridge which is not what
> we want, we just want to unreference it and that is already
> handled by the core.
>
>
Linus Walleij writes:
> The header file contains prototypes for two nonexisting
> functions. Get rid of them.
It seems like these are ready to push, to me.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedeskto
Colin King writes:
> From: Colin Ian King
>
> The current error handling on devm_kzalloc failures performs a non-null
> check on connector. Thss check is redundant because connector is null
> at that failure point. With this check removed, we may as well make
> the failure path into a trivial -
https://bugs.freedesktop.org/show_bug.cgi?id=100387
--- Comment #13 from Peter ---
Created attachment 134095
--> https://bugs.freedesktop.org/attachment.cgi?id=134095&action=edit
X.org log file
please, see attachment...
--
You are receiving this mail because:
You are the assignee for the bug
https://bugs.freedesktop.org/show_bug.cgi?id=102581
--- Comment #2 from Felix Potthast ---
Created attachment 134096
--> https://bugs.freedesktop.org/attachment.cgi?id=134096&action=edit
Glxinfo output
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=102581
Felix Potthast changed:
What|Removed |Added
Version|17.1|17.2
--
You are receiving this mail b
https://bugs.freedesktop.org/show_bug.cgi?id=102581
--- Comment #3 from Felix Potthast ---
Added glxinfo attachment.
Also upgraded to Mesa 17.2, but the problem still exists, glxinfo log is from
new version.
--
You are receiving this mail because:
You are the assignee for the bug.__
From: Gustavo Padovan
Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
intel_legacy_cursor_update() did but through atomic.
v4:
- call drm_atomic_helper_async_check() from the check hook
v3:
- set corr
From: Gustavo Padovan
Add support for async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
vc4_update_plane() did but through atomic.
v5: add missing call to vc4_plane_atomic_check() (Eric Anholt)
v4: add drm_atomic_helper_async() commi
From: Gustavo Padovan
After converting legacy cursor updates to atomic async commits
mdp5_cursor_plane_funcs just duplicates mdp5_plane_funcs now.
Cc: Rob Clark
Cc: Archit Taneja
Signed-off-by: Gustavo Padovan
Tested-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 26 -
From: Gustavo Padovan
Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
mdp5_update_cursor_plane_legacy() did but through atomic.
v5: call drm_atomic_helper_async_check() from the check hook
v4: add missing atomic asyn
From: Gustavo Padovan
After converting legacy cursor updates to atomic async commits
intel_cursor_plane_funcs just duplicates intel_plane_funcs now.
Cc: Daniel Vetter
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 12 +---
sun4i-drm is maintained in drm-misc as a small driver.
Signed-off-by: Maxime Ripard
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1c3feffb1c1c..a6e1d9fa84d5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4431,7 +4431,7 @@ L:
Changes since v7 [1]:
* rebase on the mid-merge-window state of the tree to pick up new mmap
implementations.
* expand the mmap operation handler conversion beyond 'struct
file_operations' to include, 'struct etnaviv_gem_ops', 'struct
dma_buf_ops', 'struct drm_driver', 'struct fb_ops', and '
On Fri, Sep 08, 2017 at 09:40:39PM +0200, Maxime Ripard wrote:
> sun4i-drm is maintained in drm-misc as a small driver.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Daniel Vetter
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINT
Quoting Gustavo Padovan (2017-09-08 20:24:15)
> @@ -13167,6 +13170,26 @@ static int intel_atomic_commit(struct drm_device
> *dev,
> struct drm_i915_private *dev_priv = to_i915(dev);
> int ret = 0;
>
> + /*
> +* The atomic async update fast path takes care
> +
On 9 Sep. 2017 2:30 am, "Marek Olšák" wrote:
What's the difference between HandleToFD and ExportSyncFile?
One just gives you an FD for sharing the syncobj itself, the other exports
the syncobj state into a sync file and you get to do sync file stuff with
it.
A) is for process sharing
B) for in
https://bugs.freedesktop.org/show_bug.cgi?id=100387
--- Comment #14 from aceman ---
The attached log seems to imply R600 driver is used.
It also lists the GPU as:
Chipset: "AMD Radeon HD 6800 Series" (ChipID = 0x6739)
Is this really from the A8-7600 machine?
--
You are receiving this mail beca
2017-09-08 Chris Wilson :
> Quoting Gustavo Padovan (2017-09-08 20:24:15)
> > @@ -13167,6 +13170,26 @@ static int intel_atomic_commit(struct drm_device
> > *dev,
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > int ret = 0;
> >
> > + /*
> > +* The atomic a
https://bugs.freedesktop.org/show_bug.cgi?id=101229
--- Comment #13 from katof...@protonmail.com ---
I've also had this problem, I'm using the AMDGPU-experimental option that i've
enabled in the kernels because I'm on a R9 390x. I'm in Mesa 17.1 on Kernel
4.12.11 in KDE Manjaro Linux. I am using a
https://bugs.freedesktop.org/show_bug.cgi?id=101229
katof...@protonmail.com changed:
What|Removed |Added
Severity|normal |major
--
You are receiving th
https://bugs.freedesktop.org/show_bug.cgi?id=102625
--- Comment #4 from Philipp Überbacher ---
Created attachment 134101
--> https://bugs.freedesktop.org/attachment.cgi?id=134101&action=edit
Output with R600_DEBUG="ps,vs,tcs,tes,cs,gs"
Radeon RX 560
Arch Linux, mesa 17.1.8, xf86-video-amdgpu 1
On Fri, Sep 8, 2017 at 10:08 PM, Dave Airlie wrote:
>
>
> On 9 Sep. 2017 2:30 am, "Marek Olšák" wrote:
>
> What's the difference between HandleToFD and ExportSyncFile?
>
>
> One just gives you an FD for sharing the syncobj itself, the other exports
> the syncobj state into a sync file and you get
https://bugs.freedesktop.org/show_bug.cgi?id=102500
--- Comment #17 from Dieter Nützel ---
(In reply to Christian König from comment #15)
> Created attachment 134082 [details] [review]
> Possible fix
>
> Please try the attached kernel patch.
Hello Christian,
you've made your 'homework'...;-)
On 9 Sep. 2017 10:17 am, "Marek Olšák" wrote:
On Fri, Sep 8, 2017 at 10:08 PM, Dave Airlie wrote:
>
>
> On 9 Sep. 2017 2:30 am, "Marek Olšák" wrote:
>
> What's the difference between HandleToFD and ExportSyncFile?
>
>
> One just gives you an FD for sharing the syncobj itself, the other exports
https://bugs.freedesktop.org/show_bug.cgi?id=100387
--- Comment #15 from Peter ---
No, the log is from LTSP thin/fat client. Terefore CPU is of LTSP server.
GPU is correct though.
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=101229
--- Comment #14 from Michel Dänzer ---
(In reply to Justin Mitzel from comment #13)
> I've also had this problem,
How do you know it's the same problem? I still don't have a good idea what the
problem reported here looks like (and my last ques
101 - 130 of 130 matches
Mail list logo
