On 2019/05/27, Koenig, Christian wrote:
> Am 27.05.19 um 14:05 schrieb Emil Velikov:
> > On 2019/05/27, Koenig, Christian wrote:
> >> Am 27.05.19 um 10:17 schrieb Emil Velikov:
> >>> From: Emil Velikov
> >>>
> >>> Currently one can
On 2019/05/27, Thomas Hellstrom wrote:
> On 5/27/19 10:17 AM, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > There are cases (in mesa and applications) where one would open the
> > primary node without properly authenticating the client.
> >
&g
On 2019/05/27, Daniel Vetter wrote:
> On Mon, May 27, 2019 at 10:47:39AM +, Koenig, Christian wrote:
> > Am 27.05.19 um 10:17 schrieb Emil Velikov:
> > > From: Emil Velikov
> > >
> > > Currently one can circumvent DRM_AUTH, when the ioctl is exposed vi
On 2019/05/27, Daniel Vetter wrote:
> On Mon, May 27, 2019 at 09:17:29AM +0100, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
> > render node. A seemingly deliberate design decision.
>
On 2019/05/27, Thomas Hellstrom wrote:
> On 5/27/19 2:35 PM, Emil Velikov wrote:
> > Hi Thomas,
> >
> > On 2019/05/27, Thomas Hellstrom wrote:
> >
> > > > I think we might be talking past each other, let's take a step back:
> > > >
> &
On 2019/05/27, Koenig, Christian wrote:
> Am 27.05.19 um 15:26 schrieb Emil Velikov:
> > On 2019/05/27, Daniel Vetter wrote:
> >> On Mon, May 27, 2019 at 10:47:39AM +, Koenig, Christian wrote:
> >>> Am 27.05.19 um 10:17 schrieb Emil Velikov:
> >>>>
On 2019/05/27, Thomas Hellstrom wrote:
> On 5/27/19 5:27 PM, Emil Velikov wrote:
> > On 2019/05/27, Thomas Hellstrom wrote:
> > > On 5/27/19 2:35 PM, Emil Velikov wrote:
> > > > Hi Thomas,
> > > >
> > > > On 2019/05/27, Thomas Hellstrom wrote:
On 2019/05/28, Tomi Valkeinen wrote:
> On 22/05/2019 18:02, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Cc: Tomi Valkeinen
> > Signed-off-by: Emil Velikov
> > ---
> > drivers/gpu/drm/omapdrm/omap_drv.c | 16 +---
> >
On 2019/05/28, Daniel Vetter wrote:
> On Tue, May 28, 2019 at 10:03 AM Koenig, Christian
> wrote:
> >
> > Am 28.05.19 um 09:38 schrieb Daniel Vetter:
> > > [SNIP]
> > >> Might be a good idea looking into reverting it partially, so that at
> > >> least command submission and buffer allocation is st
On 2019/05/28, Koenig, Christian wrote:
> Am 28.05.19 um 18:10 schrieb Emil Velikov:
> > On 2019/05/28, Daniel Vetter wrote:
> >> On Tue, May 28, 2019 at 10:03 AM Koenig, Christian
> >> wrote:
> >>> Am 28.05.19 um 09:38 schrieb Daniel Vetter:
> >&g
On 2019/05/29, Dave Airlie wrote:
> On Wed, 29 May 2019 at 02:47, Emil Velikov wrote:
> >
> > On 2019/05/28, Koenig, Christian wrote:
> > > Am 28.05.19 um 18:10 schrieb Emil Velikov:
> > > > On 2019/05/28, Daniel Vetter wrote:
> > > >>
Hi Tomi,
On Fri, 18 Jan 2019 at 08:29, Tomi Valkeinen wrote:
>
> On 18/01/19 00:04, Rob Herring wrote:
>
> > Mesa/libdrm already has lots of code to open the correct devices and
> > not care about minor numbers. What's the problem here?
>
> Well, maybe the problem is that I don't know how to do t
On Mon, 18 Mar 2019 at 13:32, Tapani Pälli wrote:
> On 3/18/19 3:25 PM, Robert Foss wrote:
> > Hey,
> >
> > On 3/18/19 2:11 PM, Mauro Rossi wrote:
> >> Hi,
> >>
> >> On Mon, Mar 18, 2019 at 10:58 AM Robert Foss
> >> wrote:
> >>>
> >>> Hey Mauro,
> >>>
> >>> On 3/18/19 9:38 AM, Mauro Rossi wrote:
On Wed, 17 Apr 2019 at 12:41, Benjamin Gaignard
wrote:
>
> Le mar. 16 avr. 2019 à 20:48, John Stultz a écrit :
> >
> > On Tue, Apr 16, 2019 at 11:29 AM Sean Paul wrote:
> > > On Tue, Apr 16, 2019 at 09:43:49AM -0700, John Stultz wrote:
> > > > In trying to further align the AOSP libdrm branch wi
; > I discarded the fixes in include/drm/ though, as those should come from
> > > upstream.
> > >
> > > Leaving them here if anyone wants to send those to the kernel:
> >
> > Please submit patch, get it merged? I think one for all of them is fine.
>
> On the li
On Wed, 19 Dec 2018 at 16:23, Eric Engestrom wrote:
>
> Signed-off-by: Eric Engestrom
> ---
> tests/amdgpu/vce_tests.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
Reviewed-by: Emil Velikov
and pushed to mast
return "MOD_BROADCOM_VC4_T_TILED";
> + case DRM_FORMAT_MOD_QCOM_COMPRESSED:
> + return "QCOM_COMPRESSED";
Thanks for the patch Fritz. Sadly the patch ended in my spam hence the delay.
Reviewed and pushed to master.
Reviewed-by: Emil Velikov
-Emil
__
On Mon, 25 Feb 2019 at 19:53, Deucher, Alexander
wrote:
>
> > -Original Message-
> > From: amd-gfx On Behalf Of Emil
> > Velikov
> > Sent: Monday, February 25, 2019 8:09 AM
> > To: Alex Deucher
> > Cc: Deng, Emily ; Maling list - DRI developers
",
> + "armada-drm",
Thanks for the patch Lubomir, reviewed and pushed to master.
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi guys,
On 2019/04/17, Daniel Vetter wrote:
> On Wed, Apr 17, 2019 at 02:46:06PM +0200, Christian König wrote:
> > Am 17.04.19 um 14:35 schrieb Daniel Vetter:
> > > On Wed, Apr 17, 2019 at 12:06:32PM +, Koenig, Christian wrote:
> > > > Am 17.04.19 um 14:00 schrieb Daniel Vetter:
> > > > > On
On 2019/04/17, Christian König wrote:
> This is to work around problems with libva and vainfo.
>
This part reverts a commit from 2013. Something I would wager that will cause
multiple problems across the board.
If we look at the intel libva driver in particular, as-is this will cause all
get para
On 2019/04/17, Emil Velikov wrote:
> On 2019/04/17, Christian König wrote:
> > This is to work around problems with libva and vainfo.
> >
> This part reverts a commit from 2013. Something I would wager that will cause
> multiple problems across the board.
>
> If we loo
On Wed, 17 Apr 2019 at 21:49, Dave Airlie wrote:
>
> On Thu, 18 Apr 2019 at 03:30, Koenig, Christian
> wrote:
> >
> > Am 17.04.19 um 17:51 schrieb Emil Velikov:
> > > Hi guys,
> > >
> > > On 2019/04/17, Daniel Vetter wrote:
> > >> On
memcpy draw test
tests/amdgpu: minor fix for dispatch/draw test
Emil Velikov (4):
xf86drm: fallback to MODALIAS for OF less platform devices
xf85drm: de-duplicate drmParse{Platform.Host1x}{Bus,Device}Info
Revert "libdrm: Fix issue about differrent domainID but sam
everts commit b318e3ff7ca065d6b107e424c85a63d7a6798a69.
>
> Cc: Gerd Hoffmann
> Cc: Dave Airlie
> Signed-off-by: Marc-André Lureau
The DRI3 code extensively uses prime_handle_to_fd and
prime_fd_to_handle for self-import.
Fwiw the patch is:
Reviewed-by: Emil Velikov
-Emil
__
On Sat, 20 Apr 2019 at 05:25, John Stultz wrote:
>
> From: Sean Paul
>
> __mmap2 isn't supported on all platforms, mmap64 is the right way
> to do this in android.
>
> Also folds in a fix from Stéphane Marchesin
> to use an offset in bytes not pages, as that'
call.
>
> Increase this to as many as can fit in a memory PAGE to avoid having to
> reallocate memory too often.
>
> Cc: Emil Velikov
> Cc: Sean Paul
> Cc: Alistair Strachan
> Cc: Marissa Wall
> Signed-off-by: John Stultz
> ---
> xf86drmMode.c | 7
On Sat, 20 Apr 2019 at 05:25, John Stultz wrote:
>
> Clang complains when initializing unions using "= {0}"
> so instead use memset.
>
> Cc: Emil Velikov
> Cc: Sean Paul
> Cc: Alistair Strachan
> Cc: Marissa Wall
> Signed-off-by: John Stult
On Sat, 20 Apr 2019 at 05:25, John Stultz wrote:
>
> From: Hemant Hariyani
>
> Allows mmap on dmabuf fd with MAP_SHARED and PROT_WRITE.
>
> This fixes boot failures caused due to mmap() returning error
>
Commit message is quite meh - xf86-video-omap does not use the API, so
things should work (tm
On Tue, 23 Apr 2019 at 09:05, Gerd Hoffmann wrote:
>
> Hi,
>
> > > The DRI3 code extensively uses prime_handle_to_fd and
> > > prime_fd_to_handle for self-import.
>
> The callbacks are not used for self-import.
>
Userspace converts from it's own handles to a dmabuf fd and vice-versa.
I assumed t
On Tue, 23 Apr 2019 at 15:06, Gerd Hoffmann wrote:
>
> On Tue, Apr 23, 2019 at 12:55:07PM +0100, Emil Velikov wrote:
> > On Tue, 23 Apr 2019 at 09:05, Gerd Hoffmann wrote:
> > >
> > > Hi,
> > >
> > > > > The DRI3 code extensively uses p
Hi Emily,
On Wed, 24 Apr 2019 at 10:19, Deng, Emily wrote:
>
> Hi Emil,
> I don't understand your idea clear about follow, what about the case that
> only has 1 GPU, and don't support pci_domain? For this case, it still need to
> fallback to pci_domain_ok=0.
I'm struggling to understand -
On Wed, 24 Apr 2019 at 06:51, james qian wang (Arm Technology China)
wrote:
>
> Fix the kbuild test rebot reported warnings:
> - symbol was not declared. Should it be static?
> - missing braces around initializer
>
> Depends on:
> - https://patchwork.freedesktop.org/series/58976/
>
> Reported-by:
On Thu, 25 Apr 2019 at 10:49, Seung-Woo Kim wrote:
>
> The pointer p aquired with drmModeGetPlane() is not free in error
> path. Fix possible memory leak by calling drmModeFreePlane() in
> the error path.
>
> Signed-off-by: Seung-Woo Kim
Reviewed-by: Emil Velikov
and pushed
On Wed, 24 Apr 2019 at 18:08, John Stultz wrote:
>
> Recently I've been trying to sync the AOSP libdrm tree with
> the upstream freedesktop branch.
>
> Thanks to input from Sean, Alistair and Marissa, we've managed
> to drop a bunch of stale patches AOSP was carrying, and get
> the AOSP libdrm upd
From: Emil Velikov
In dma_buf_attach() we allocate memory w/o a mutex being held, thus in
the error path we should kfree() it after the mutex_unlock.
The inverse function dma_buf_deattach() gets this right.
Cc: Sumit Semwal
Signed-off-by: Emil Velikov
---
drivers/dma-buf/dma-buf.c | 2 +-
1
From: Emil Velikov
Currently drm_gem_prime_fd_to_handle() consists of illegible amount of
goto labels, for no obvious reason.
Split it in two (as below) making the code far simpler and obvious.
drm_gem_prime_fd_to_handle()
- prime mtx handling
- fd/dmabuf refcounting
- hash table lookup
From: Emil Velikov
Currently drm_gem_prime_handle_to_fd() consists of illegible amount of
goto labels, for no obvious reason.
Split it in two (as below) making the code far simpler and obvious.
drm_gem_prime_handle_to_fd()
- prime mtx handling
- drm_gem_object lookup and refcounting
From: Emil Velikov
The functions are virtually identical, fold them up.
Signed-off-by: Emil Velikov
---
xf86drm.c | 98 +--
1 file changed, 15 insertions(+), 83 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 374734eb..18c9693a 100644
From: Emil Velikov
Some devices can lack OF data or it may not be available in the uevent
file. Fallback to the MODALIAS data in those cases.
We strip any leading "MODALIAS=.*:" thus the resulting information is
compatible with existing code in Mesa.
Signed-off-by: Emil Velikov
---
On Wed, 23 Jan 2019 at 11:04, Eric Engestrom wrote:
>
> On Wednesday, 2019-01-23 10:45:17 +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Some devices can lack OF data or it may not be available in the uevent
> > file. Fallback to the MODALIAS data in tho
On Wed, 23 Jan 2019 at 04:39, Christopher James Halse Rogers
wrote:
>
> We can't use drmSetMaster to query whether or not a drm fd is master
> because it requires CAP_SYS_ADMIN, even if the fd *is* a master fd.
>
> Pick DRM_IOCTL_MODE_ATTACHMODE as a long-deprecated ioctl that is
> DRM_MASTER but
On Wed, 23 Jan 2019 at 11:26, Emil Velikov wrote:
>
> On Wed, 23 Jan 2019 at 11:04, Eric Engestrom wrote:
> >
> > On Wednesday, 2019-01-23 10:45:17 +, Emil Velikov wrote:
> > > From: Emil Velikov
> > >
> > > Some devices can lack OF data or it
On Thu, 24 Jan 2019 at 16:58, Daniel Vetter wrote:
>
> This is only used by drm_irq_install(), which is an optional helper.
> And the right choice is to set it for all pci devices, and not for
> everything else.
>
Can you please add some information (or reference) why it's the right choice?
Thank
On Thu, 24 Jan 2019 at 17:00, Daniel Vetter wrote:
>
> It's 0.
>
I'd add a bit more information here. Feel free to reuse as much/little
of the following:
Both macros evaluate to 0. At the same time flag is already set to
zero since the struct is kzalloc'd in framebuffer_alloc().
As called by drm_
2 +-
> drivers/gpu/drm/vc4/vc4_drv.c| 1 -
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
> drivers/staging/vboxvideo/vbox_drv.c | 2 +-
Local grep shows one more non-legacy entry in
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
With that file addressed and trivial
On 2019/01/25, Daniel Vetter wrote:
> On Fri, Jan 25, 2019 at 02:46:55PM +0000, Emil Velikov wrote:
> > On Thu, 24 Jan 2019 at 16:58, Daniel Vetter wrote:
> > >
> > > This is only used by drm_irq_install(), which is an optional helper.
> > > And the right cho
On Fri, 1 Feb 2019 at 14:15, Lucas Stach wrote:
>
> Hi Emil,
>
> > > For reference with this patch drmdevice and other drmDevice API users
> > > list:
> > > - VGEM, needs "drm/vgem: Fix vgem_init to get drm device available."
> > > - in v5.0 only :'-(
> > > - etnaviv, after "drm/etnaviv: remov
wo or more data types in declaration specifiers
> > Bool bool;
> >^
> >
> > Fix this by making it return a 0/1 integer, with the same semantic as
> > the boolean it was before.
>
> Don't you need to drop the stdbool.h include for this to fix compilation?
From: Emil Velikov
This static inline function doesn't modify any state.
Signed-off-by: Emil Velikov
---
include/drm/drm_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 35af23f5fa0d..eca73330ffaf 100644
From: Emil Velikov
Currently only DRM_ROOT_ONLY is allowed to call the ioctl.
Change that to DRM_MASTER, which means that only a process that is the
current DRM master can drop it. Which makes sense, the process should
be able to opt-out without any specific requirements.
Signed-off-by: Emil
From: Emil Velikov
There are cases (in mesa and applications) where one would open the
primary node without properly authenticating the client.
Sometimes we don't check if the authentication succeeds, but there's
also cases we simply forget to do it. Mesa has been fixed recentl
h the Intel GFX trybot
but I'm not sure how to do that.
Any comments, review or general ack's are appreciated.
Thanks
Emil
Emil Velikov (3):
drm: change DROP_MASTER permissions to allow DRM_MASTER
drm: annotate drm_core_check_feature() dev arg. as const
drm: allow render capable ma
On Wed, 19 Dec 2018 at 20:37, Daniel Vetter wrote:
>
> On Wed, Dec 19, 2018 at 09:30:46PM +0100, Daniel Vetter wrote:
> > On Wed, Dec 19, 2018 at 07:22:44PM +, Emil Velikov wrote:
> > > Hi all,
> > >
> > > This series relaxes some permission handling
On Wed, 19 Dec 2018 at 20:36, Daniel Vetter wrote:
>
> On Wed, Dec 19, 2018 at 07:22:45PM +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Currently only DRM_ROOT_ONLY is allowed to call the ioctl.
> >
> > Change that to DRM_MASTER, which m
On Wed, 19 Dec 2018 at 20:34, Daniel Vetter wrote:
>
> On Wed, Dec 19, 2018 at 07:22:47PM +, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > There are cases (in mesa and applications) where one would open the
> > primary node without properly authenticating
On Thu, 20 Dec 2018 at 14:45, Daniel Vetter wrote:
>
> On Thu, Dec 20, 2018 at 01:50:26PM +, Emil Velikov wrote:
> > On Wed, 19 Dec 2018 at 20:36, Daniel Vetter wrote:
> > >
> > > On Wed, Dec 19, 2018 at 07:22:45PM +, Emil Velikov wro
From: Emil Velikov
Currently only an authenticated master can authenticate another client.
In practise the client can only be master if CAP_SYS_ADMIN is present,
although having the CAP also sets the client as authenticated.
Thus DRM_AUTH in AUTH_MAGIC's "DRM_AUTH | DRM_MASTER"
From: Emil Velikov
Will be used to plug an existing memory leak.
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/drm_file.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index ffa8dc35515f
From: Emil Velikov
Currently we fail to free and detach the drm_file when drm_setup() fails.
Use the drm_close_helper to do address that.
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/drm_file.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm
From: Emil Velikov
This static inline function doesn't modify any state.
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Emil Velikov
Reviewed-by: Daniel Vetter
---
include/drm/drm_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_drv.h b/in
From: Emil Velikov
There are cases (in mesa and applications) where one would open the
primary node without properly authenticating the client.
Sometimes we don't check if the authentication succeeds, but there's
also cases we simply forget to do it.
The former was a case for Mesa wh
On 2019/01/14, Daniel Vetter wrote:
> On Mon, Jan 14, 2019 at 08:44:10AM +0000, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Currently we fail to free and detach the drm_file when drm_setup() fails.
> > Use the drm_close_helper to do address that.
> >
On 2019/01/14, Daniel Vetter wrote:
> On Mon, Jan 14, 2019 at 08:54:08AM +0000, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > There are cases (in mesa and applications) where one would open the
> > primary node without properly authenticating the client.
> >
On Mon, 18 Feb 2019 at 17:10, Eric Engestrom wrote:
>
> On Wednesday, 2018-12-19 17:08:01 +, Eric Engestrom wrote:
> > Adapted from a local patch carried by DragonFlyBSD:
> > https://github.com/DragonFlyBSD/DPorts/blob/bc056f88f7e4d468d8c9751f831a47b5ae1326e3/graphics/libdrm/files/patch-xf86dr
On Mon, 18 Feb 2019 at 17:42, Eric Engestrom wrote:
>
> On Thursday, 2018-12-20 11:53:11 -0800, Dylan Baker wrote:
> > Quoting Eric Engestrom (2018-12-19 08:23:40)
> > > Signed-off-by: Eric Engestrom
> > > ---
> > > RELEASING | 27 ---
> > > 1 file changed, 8 insertions(+
On Tue, 19 Feb 2019 at 10:08, Eric Engestrom wrote:
>
> On Friday, 2019-02-15 15:08:22 +, Emil Velikov via dri-devel wrote:
> > On Fri, 15 Feb 2019 at 15:06, Rob Clark via dri-devel
> > wrote:
> > >
> > > On Fri, Feb 15, 2019 at 8:42 AM Eric Engestrom
&g
On Tue, 19 Feb 2019 at 15:36, Dylan Baker wrote:
>
> Quoting Daniel Vetter (2019-02-19 07:20:12)
> > On Tue, Feb 19, 2019 at 3:02 PM Eric Engestrom
> > wrote:
> > >
> > > On Tuesday, 2019-02-19 13:53:25 +0100, Daniel Vetter wrote:
> > > &g
Hi all,
This patch causes unnecessary round trip by openning the nodes. As
mentioned previously this could be trivially fixed [1].
Even Emily acknowledged that [1], yet the sub-par fix was merged. Can
we revert+fixup this properly?
Thanks
Emil
[1] https://lists.freedesktop.org/archives/amd-gfx/
On 2019/05/29, Koenig, Christian wrote:
> Am 29.05.19 um 15:03 schrieb Emil Velikov:
> > On 2019/05/29, Dave Airlie wrote:
> >> On Wed, 29 May 2019 at 02:47, Emil Velikov
> >> wrote:
> >>> On 2019/05/28, Koenig, Christian wrote:
> >>>> Am 2
On 2019/05/31, Koenig, Christian wrote:
> Am 29.05.19 um 18:29 schrieb Emil Velikov:
> > On 2019/05/29, Koenig, Christian wrote:
> >> Am 29.05.19 um 15:03 schrieb Emil Velikov:
> >>> On 2019/05/29, Dave Airlie wrote:
> >>>> On Wed, 29 May 2019 at 02:47,
On Mon, 27 May 2019 at 09:19, Emil Velikov wrote:
>
> From: Emil Velikov
>
> The authentication can be circumvented, by design, by using the render
> node.
>
> From the driver POV there is no distinction between primary and render
> nodes, thus we can drop the token.
&
On Mon, 27 May 2019 at 09:19, Emil Velikov wrote:
>
> From: Emil Velikov
>
> The authentication can be circumvented, by design, by using the render
> node.
>
> From the driver POV there is no distinction between primary and render
> nodes, thus we can drop the token.
&
On Mon, 27 May 2019 at 09:19, Emil Velikov wrote:
>
> From: Emil Velikov
>
> The authentication can be circumvented, by design, by using the render
> node.
>
> From the driver POV there is no distinction between primary and render
> nodes, thus we can drop the token.
On Mon, 27 May 2019 at 09:19, Emil Velikov wrote:
>
> From: Emil Velikov
>
> The authentication can be circumvented, by design, by using the render
> node.
>
> From the driver POV there is no distinction between primary and render
> nodes, thus we can drop the token.
&
On Mon, 27 May 2019 at 09:19, Emil Velikov wrote:
>
> From: Emil Velikov
>
> The authentication can be circumvented, by design, by using the render
> node.
>
> From the driver POV there is no distinction between primary and render
> nodes, thus we can drop the token.
&
On Mon, 27 May 2019 at 09:19, Emil Velikov wrote:
>
> From: Emil Velikov
>
> The authentication can be circumvented, by design, by using the render
> node.
>
> From the driver POV there is no distinction between primary and render
> nodes, thus we can drop the token.
>
On Mon, 27 May 2019 at 09:19, Emil Velikov wrote:
>
> From: Emil Velikov
>
> The authentication can be circumvented, by design, by using the render
> node.
>
> From the driver POV there is no distinction between primary and render
> nodes, thus we can drop the token.
&g
On Mon, 3 Jun 2019 at 01:40, Ilia Mirkin wrote:
>
> Signed-off-by: Ilia Mirkin
> ---
> tests/modetest/modetest.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index 9c85c07b..a1c81f6c 100644
> --- a/tests/mode
d C8 format, support it with SMPTE pattern
I did not verify the numbers in this patch, but it looks reasonable:
Acked-by: Emil Velikov
> util: fix MAKE_RGBA macro for 10bpp modes
> util: add gradient pattern
> util: add fp16 format support
> util: add cairo drawing for 30bpp for
On Thu, 6 Jun 2019 at 16:54, Emil Velikov wrote:
>
> On Mon, 3 Jun 2019 at 01:40, Ilia Mirkin wrote:
> >
> > This series improves the pattern generation logic to support additional
> > formats, as well as a new "gradient" pattern (see patch com
On Thu, 6 Jun 2019 at 16:58, Ilia Mirkin wrote:
>
> On Thu, Jun 6, 2019 at 11:51 AM Emil Velikov wrote:
> >
> > On Mon, 3 Jun 2019 at 01:40, Ilia Mirkin wrote:
> > >
> > > Signed-off-by: Ilia Mirkin
> > > ---
> > > tests/modetest/modetes
ra
> Cc: Tomeu Vizoso
> Cc: Emil Velikov
> Cc: Benjamin Gaignard
> Cc: Ville Syrjälä
> Signed-off-by: Daniel Vetter
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> To make this perfectly clear, also add a comment to DRM_UNLOCKED.
>
> v2: Don't forget about drm_ioc32.c (Michel). Not a source of copypasta
> mistakes when creating driver ioctl tables, but better to be
> consistent.
>
Personally I would omit the "Not a source of c
On 2019/05/27, Emil Velikov wrote:
> From: Emil Velikov
>
> Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
> render node. A seemingly deliberate design decision.
>
> Hence we can drop the DRM_AUTH all together (details in follow-up patch)
> yet not
Hi all,
Currently, DRM drivers implementing dumb-buffers apply alignment to the
requested width, passing the resulting pitch back to user-space. The
specifics of the alignment can be various - from CPU/GPU architecture
or bus/interconnect, to no alignment at all.
By using dumb-buffers the CPU rea
On 2019/06/14, Koenig, Christian wrote:
> Am 14.06.19 um 14:09 schrieb Emil Velikov:
> > On 2019/05/27, Emil Velikov wrote:
> > [SNIP]
> > Hi Christian,
> >
> >
> > In the following, I would like to summarise and emphasize the need for
> > DRM_AUTH remo
On 2019/06/14, Koenig, Christian wrote:
> Am 14.06.19 um 17:53 schrieb Emil Velikov:
> > On 2019/06/14, Koenig, Christian wrote:
> >> Am 14.06.19 um 14:09 schrieb Emil Velikov:
> >>> On 2019/05/27, Emil Velikov wrote:
> >>> [SNIP]
> >>> Hi
From: Emil Velikov
Currently the AMDGPU_CTX_PRIORITY_* defines are used in both
drm_amdgpu_ctx_in::priority and drm_amdgpu_sched_in::priority.
Extend the comment to mention the CAP_SYS_NICE or DRM_MASTER requirement
is only applicable with the former.
Cc: Bas Nieuwenhuizen
Cc: Christian König
On Mon, 3 Jun 2019 at 08:41, Niclas Zeising wrote:
>
> FreeBSD requires sys/types.h for sys/sysctl.h, add it as part of the
> includes when checking for headers.
> Instead of splitting out the check for sys/sysctl.h from the other
> header checks, just add sys/types.h to all header checks.
>
If he
As tweaked with previous patch - bash is not required. Any shell will do
Signed-off-by: Emil Velikov
---
amdgpu/meson.build| 2 +-
etnaviv/meson.build | 2 +-
exynos/meson.build| 2 +-
freedreno/meson.build | 2 +-
intel/meson.build | 14 +++---
libkms/meson.build
None of the tests are bash specific. Tested with bash, zsh, dash, mksh
and ksh.
Signed-off-by: Emil Velikov
---
amdgpu/amdgpu-symbol-check | 2 +-
etnaviv/etnaviv-symbol-check | 2 +-
exynos/exynos-symbol-check | 2 +-
freedreno/freedreno-symbol-check | 2 +-
intel/intel-symbol
/sh hunk
Signed-off-by: Emil Velikov
---
meson.build | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
index ed407009..14f82b1f 100644
--- a/meson.build
+++ b/meson.build
@@ -179,9 +179,12 @@ else
dep_rt = []
endif
dep_m = cc.find_library(&#
From: Niclas Zeising
Reviewed-by: Emil Velikov
---
meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
index be768afa..64f0d5b1 100644
--- a/meson.build
+++ b/meson.build
@@ -248,7 +248,7 @@ if prog_xslt.found()
endif
with_man_pages
On 2019/06/14, Daniel Vetter wrote:
> Yes this is a bit a big patch, but since it's essentially a complete
> rewrite of all the prime docs I didn't see how to better split it up.
>
> Changes:
> - Consistently point to drm_gem_object_funcs as the preferred hooks,
> where applicable.
>
> - Reorde
On 2019/06/14, Daniel Vetter wrote:
> Drivers must fill out the handle_to_fd and fd_to_handle hooks to
> enable export/import prime functionality already. The additional
> DRIVER_PRIME flag doesn't serve any real purpose, since the overall
> flag doesn't even tell you whether import or export or ma
On 2019/06/14, Daniel Vetter wrote:
> Split out to make the functional changes stick out more.
>
Since this patch flew-by, as standalone one (intentionally or not) I'd
add, anything vaguely like:
"Core users of DRIVER_PRIME were removed from core with prior patches."
HTH
Emil
___
On 2019/06/17, james qian wang (Arm Technology China) wrote:
> On Fri, Jun 14, 2019 at 10:35:23PM +0200, Daniel Vetter wrote:
> > Read the docs, komeda is not an old enough driver for this :-)
> >
> > Signed-off-by: Daniel Vetter
> > Cc: "James (Qian) Wang"
> > Cc: Liviu Dudau
> > ---
> > driv
ioned - might be good idea to split this up a bit and merge it
into a few pieces?
Should make the churn much more manageable.
> drm/prime: Unconditionally set up the prime file private
> drm/prime: Make DRIVER_PRIME a no-op
> drm/prime: Actually remove DRIVER_PRIME everywhere
Patc
On 2019/06/17, Emil Velikov wrote:
> Hi Daniel,
>
> On Fri, 14 Jun 2019 at 21:36, Daniel Vetter wrote:
> >
> > Hi all,
> >
> > So I figured let's get going and polish the docs for the last part of drm
> > core/helpers that hasn't yet seen some
101 - 200 of 2172 matches
Mail list logo
