On Tue, May 7, 2019 at 11:02 AM Jordan Crouse wrote:
>
> When we move to 64 bit addressing for a5xx and a6xx targets we will start
> seeing pagefaults at larger addresses so format them appropriately in the
> log message for easier debugging.
Yes please, this has confused me more than once.
Revi
On Tue, May 7, 2019 at 12:18 PM Jordan Crouse wrote:
>
> In the failure path for dpu_kms_init() it is possible to get to the MMU
> destroy function with uninitialized MMU structs. Check for NULl and skip
s/NULl/NULL
> if needed.
>
> Signed-off-by: Jordan Crouse
Reviewed-by: Kristian H. Kristen
On Thu, Feb 27, 2020 at 7:38 PM Dave Airlie wrote:
>
> On Fri, 28 Feb 2020 at 07:27, Daniel Vetter wrote:
> >
> > Hi all,
> >
> > You might have read the short take in the X.org board meeting minutes
> > already, here's the long version.
> >
> > The good news: gitlab.fd.o has become very popular
On Mon, Jan 13, 2020 at 3:17 PM Rob Clark wrote:
>
> On Mon, Jan 13, 2020 at 2:55 PM Brian Ho wrote:
> >
> > On Mon, Jan 13, 2020 at 09:57:43AM -0800, Kristian Kristensen wrote:
> > > On Mon, Jan 13, 2020 at 8:25 AM Rob Clark wrote:
> > >
> > > > On Mon, Jan 13, 2020 at 7:37 AM Brian Ho wrote:
On Tue, Jan 14, 2020 at 8:41 AM Rob Clark wrote:
>
> On Tue, Jan 14, 2020 at 7:58 AM Jordan Crouse wrote:
> >
> > On Tue, Jan 14, 2020 at 01:40:11AM +0100, Bas Nieuwenhuizen wrote:
> > > On Tue, Jan 14, 2020 at 12:41 AM Jordan Crouse
> > > wrote:
> > > >
> > > > On Mon, Jan 13, 2020 at 09:25:57
On Mon, Apr 17, 2017 at 1:13 PM, Robert Foss wrote:
> From: Sean Paul
>
> From drm_crtc.h, for use with the plane "rotation" property.
>
> Signed-off-by: Sean Paul
> Signed-off-by: Robert Foss
> Reviewed-by: Sumit Semwal
> ---
> Changes since v1:
> - Added r-b
>
> include/drm/drm.h | 8 +
On Tue, Apr 18, 2017 at 11:03 AM, Emil Velikov wrote:
> On 18 April 2017 at 18:38, Kristian Høgsberg wrote:
>> On Mon, Apr 17, 2017 at 1:13 PM, Robert Foss
>> wrote:
>>> From: Sean Paul
>>>
>>> From drm_crtc.h, for use with the plane "rotat
On Thu, Nov 3, 2016 at 8:47 AM Sean Paul wrote:
> On Tue, Nov 1, 2016 at 3:41 PM, Kristian H. Kristensen
> wrote:
> > We used to call drm_of_encoder_active_endpoint_id() from
> > rockchip_dp_drm_encoder_atomic_check() to determine the endpoint for the
> > active encoder. However, the encoder isn
On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca wrote:
> On 23/03/17 01:38, Rob Clark wrote:
>>
>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray wrote:
>>>
>>> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher
wrote:
>
>
On Fri, Mar 24, 2017 at 12:44 PM, Jose Fonseca wrote:
> On 24/03/17 19:10, Kristian Høgsberg wrote:
>>
>> On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca wrote:
>>>
>>> On 23/03/17 01:38, Rob Clark wrote:
>>>>
>>>>
>>>> On Wed
On Tue, Sep 13, 2016 at 3:59 PM, Rob Clark wrote:
> On Tue, Sep 13, 2016 at 6:07 PM, Kristian H. Kristensen
> wrote:
>> The only current user of this open codes the ioctl. Let's add an entry
>> point for this to libdrm.
>>
>> Signed-off-by: Kristian H. Kristensen
>> ---
>> xf86drmMode.c | 21 ++
On Mon, Oct 19, 2020 at 10:45 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Move grabbing the bo lock into shrinker, with a msm_gem_trylock() to
> skip over bo's that are already locked. This gets rid of the nested
> lock classes.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gem.
On Mon, Oct 19, 2020 at 10:45 PM Rob Clark wrote:
>
> From: Rob Clark
>
> We cannot switch to using obj->resv for locking without first moving all
> the copy_from_user() ahead of submit_lock_objects(). Otherwise in the
> mm fault path we aquire mm->mmap_sem before obj lock, but in the submit
> p
On Mon, Oct 19, 2020 at 10:45 PM Rob Clark wrote:
>
> From: Rob Clark
>
> This doesn't remove *all* the struct_mutex, but it covers the worst
> of it, ie. shrinker/madvise/free/retire. The submit path still uses
> struct_mutex, but it still needs *something* serialize a portion of
> the submit p
On Mon, Oct 5, 2020 at 4:02 PM Daniel Vetter wrote:
>
> On Mon, Oct 05, 2020 at 05:24:19PM +0800, Hillf Danton wrote:
> >
> > On Sun, 4 Oct 2020 12:21:45
> > > From: Rob Clark
> > >
> > > Now that the inactive_list is protected by mm_lock, and everything
> > > else on per-obj basis is protected
On Sun, Oct 4, 2020 at 9:21 PM Rob Clark wrote:
>
> From: Rob Clark
>
> This doesn't remove *all* the struct_mutex, but it covers the worst
> of it, ie. shrinker/madvise/free/retire. The submit path still uses
> struct_mutex, but it still needs *something* serialize a portion of
> the submit pat
On Tue, Sep 1, 2020 at 8:41 AM Rob Clark wrote:
>
> From: Rob Clark
>
> This reduces the spam in dmesg when we start hitting the shrinker, and
> replaces it with something we can put on a timeline while profiling or
> debugging system issues.
That is a good solution,
Reviewed-by: Kristian H. Kr
Why is this useful if only root can use it?
Kristian
On Wed, Jul 20, 2016 at 12:39 PM, Chris Wilson
wrote:
> When performing driver testing, one factor we want to test is how we
> handle a foreign fence that is never signaled. We can wait on that fence
> indefinitely, in which case the driver a
On Fri, Aug 23, 2013 at 4:29 AM, Chris Wilson wrote:
> On Fri, Aug 23, 2013 at 01:13:27PM +0200, David Herrmann wrote:
>> From: Kristian Høgsberg
>>
>> Enable support for drm render nodes for i915 by flagging the ioctls that
>> are safe and just needed for renderi
Did we forget about this one? I guess I could commit it myself, but I'm not
sure which branch to push it too...
Kristian
On Wed, Nov 9, 2016 at 4:10 PM Kristian Kristensen
wrote:
> On Wed, Nov 9, 2016 at 4:36 AM, Daniel Vetter
> wrote:
>
> Not setting the fb modifiers flag is something differe
On Wed, Dec 21, 2016 at 7:42 AM Rob Clark wrote:
> On Wed, Dec 21, 2016 at 4:19 AM, Ville Syrjälä
> wrote:
> > On Wed, Dec 21, 2016 at 10:15:15AM +0100, Daniel Vetter wrote:
> >> On Tue, Dec 20, 2016 at 07:46:12PM -0500, Rob Clark wrote:
> >> > On Tue, Dec 20, 2016 at 7:12 PM, Kristian H. Kris
On Mon, Oct 15, 2018 at 10:33 AM Rob Clark wrote:
>
> Userspace hasn't used submit cmds with submit_offset != 0 for a while,
> but this starts cropping up again with cmdstream sub-buffer-allocation
> in libdrm_freedreno.
>
> Doesn't do much good to increment the buf ptr before assigning it.
Revie
On Mon, Jun 11, 2018 at 11:26 AM Jordan Crouse wrote:
>
> Now that the IOMMU is the master of it's own power we don't need to bring
> up the GPU to do IOMMU operations. This is good because bringing up a6xx
> requires the GMU so calling pm_runtime_get_sync() too early in the process
> gets us into
On Thu, Aug 23, 2018 at 10:44 PM Laurent Carlier wrote:
>
> Le vendredi 24 août 2018, 00:37:51 CEST Kristian H. Kristensen a écrit :
> > https://dri.freedesktop.org/libdrm/libdrm-2.4.94.tar.bz2
>
> -> Forbidden
>
> You don't have permission to access /libdrm/libdrm-2.4.94.tar.bz2 on this
> server.
On Fri, Aug 24, 2018 at 1:13 AM Michel Dänzer wrote:
>
> On 2018-08-24 12:37 a.m., Kristian H. Kristensen wrote:
> > Benjamin Gaignard (2):
> > tests/modetest: Add atomic support
> > tests/util: Add support for stm module
> >
> > Christian König (7):
> > amdgpu: stop using the ha
On Fri, Aug 23, 2013 at 4:29 AM, Chris Wilson
wrote:
> On Fri, Aug 23, 2013 at 01:13:27PM +0200, David Herrmann wrote:
>> From: Kristian H?gsberg
>>
>> Enable support for drm render nodes for i915 by flagging the ioctls that
>> are safe and just needed for rendering.
>>
>> Cc: Daniel Vetter
>>
There's no reason to keep a reference to objects in the name idr. Each
handle to an object has a reference to the object and just before we
destroy the last handle we take the object out of the name idr. Thus,
if an object is in the name idr, there's at least one reference to the
object.
Or to p
On Tue, Dec 3, 2013 at 7:26 AM, Daniel Vetter wrote:
> On Mon, Dec 02, 2013 at 05:36:17PM -0800, Kristian H?gsberg wrote:
>> There's no reason to keep a reference to objects in the name idr. Each
>> handle to an object has a reference to the object and just before we
>> destroy the last handle we
On Mon, Apr 16, 2018 at 2:59 PM Eric Anholt wrote:
> "Kristian H. Kristensen" writes:
> > Rockchip doesn't support per-pixel alpha blending for the lowest
> > window in the stack. While the hw supports restacking the windows, we
> > don't expose that in KMS, so just filter out alpha formats for
On Thu, Sep 28, 2017 at 4:44 PM, Kristian H. Kristensen
wrote:
> This teaches modetest about the new IN_FORMATS blob and decodes the
> blob to show supported formats and modifiers.
>
> Signed-off-by: Kristian H. Kristensen
I went ahead and pushed this.
Kristian
> ---
> tests/modetest/modetest
On Wed, Oct 18, 2017 at 5:49 PM, Mark yao wrote:
> On 2017年10月19日 01:52, Brian Norris wrote:
>>
>> Hi Kristian,
>>
>> On Thu, Nov 03, 2016 at 12:46:48PM -0700, Kristian Högsberg wrote:
>>>
>>> We used to call drm_of_encoder_active_endpoint_id() from
>>> rockchip_dp_drm_encoder_atomic_check() to de
On Mon, Oct 23, 2017 at 9:47 AM, Noralf Trønnes wrote:
> Add debugfs file that dumps info about the framebuffers and its planes.
> Also dump info about any connected gem object(s).
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_debugfs.c | 6 +
> drivers/gpu/drm/drm_frame
On Tue, Oct 24, 2017 at 9:39 AM, Noralf Trønnes wrote:
>
> Den 23.10.2017 23.32, skrev Kristian Høgsberg:
>>
>> On Mon, Oct 23, 2017 at 9:47 AM, Noralf Trønnes
>> wrote:
>>>
>>> Add debugfs file that dumps info about the framebuffers and its planes.
c 20, 2017 at 12:41 PM, Miguel Angel Vico <
mvicom...@nvidia.com> wrote:
> >>>> On Wed, 20 Dec 2017 11:54:10 -0800 Kristian Høgsberg <
hoegsb...@gmail.com> wrote:
> >>>>> I'd like to see concrete examples of actual display controllers
> >&
On Thu, Feb 1, 2018 at 9:53 AM Chris Wilson
wrote:
> Quoting Andy Lutomirski (2018-02-01 17:40:22)
> > *However*, I do see one unfortunate side effect of turning on PSR. It
> > seems that, when I move my cursor a little bit after a few seconds of
> > doing nothing, there seems to be a little bit
On Wed, Dec 20, 2017 at 11:51 AM, Daniel Vetter wrote:
> Since this also involves the kernel let's add dri-devel ...
>
> On Wed, Dec 20, 2017 at 5:51 PM, Miguel Angel Vico
> wrote:
>> Hi all,
>>
>> As many of you already know, I've been working with James Jones on the
>> Generic Device Allocator
On Thu, Dec 21, 2017 at 6:21 AM, Ville Syrjälä
wrote:
> Here's a quick proof of concept implementation of HDR support
> for Wayland/Weston/Mesa.
>
> I'm not posting this as patches right now because I'm not sure
> that would do much good given how rough this is. But here are
> all the repos/branch
On Fri, Oct 5, 2012 at 9:36 AM, Imre Deak wrote:
> Needed by the upcoming DRM raw monotonic timestamp support.
I just had a quick look at driver/input/evdev.c, since evdev devices
did a similar change recently to allow evdev timestamp from the
monotonic clock. They're using a different time API:
It's the same situation as flink and we need take the same pre-cautions.
---
intel/intel_bufmgr_gem.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 3bcc849..92c0444 100644
--- a/intel/intel_bufmgr_gem.c
+++ b
On Fri, Sep 14, 2012 at 4:40 PM, Chris Wilson wrote:
> On Fri, 14 Sep 2012 16:37:53 -0400, Kristian Høgsberg
> wrote:
>> It's the same situation as flink and we need take the same pre-cautions.
>> ---
>> intel/intel_bufmgr_gem.c |8 +++-
>> 1 file c
On Fri, Sep 14, 2012 at 5:03 PM, Chris Wilson wrote:
> On Fri, 14 Sep 2012 17:01:18 -0400, Kristian Høgsberg
> wrote:
>> On Fri, Sep 14, 2012 at 4:40 PM, Chris Wilson
>> wrote:
>> > On Fri, 14 Sep 2012 16:37:53 -0400, Kristian Høgsberg
>> > wrote:
>&g
On Wed, Sep 12, 2012 at 06:47:56PM +0100, Damien Lespiau wrote:
> From: Damien Lespiau
>
> Signed-off-by: Damien Lespiau
> ---
> include/drm/drm_mode.h | 35 +--
> xf86drmMode.h | 35 +--
> 2 files changed, 42 insertions(+
On Wed, Sep 12, 2012 at 06:48:19PM +0100, Damien Lespiau wrote:
> From: Damien Lespiau
>
> Now that modes have flags to describe which 3d formats the sink
> supports, it's time to test them.
>
> The new test cycles through the supported 3D formats and paint 3D
> stereoscopic images taken from pu
On Fri, Sep 14, 2012 at 5:14 PM, Jesse Barnes wrote:
> On Wed, 12 Sep 2012 21:58:31 +0300
> Ville Syrjälä wrote:
>
>> On Wed, Sep 12, 2012 at 01:00:19PM -0500, Clark, Rob wrote:
>> > On Wed, Sep 12, 2012 at 12:27 PM, Ville Syrjälä
>> > wrote:
>> > > On Wed, Sep 12, 2012 at 10:48:16AM -0500, Rob
Here's the patch to implement render nodes as discussed in the "DRM2"
talk at XDC:
http://wiki.x.org/wiki/Events/XDC2012/Proceedings#DRM2
The core problem is that DRM security is compromised in the face of
VT switching and multiple DRM masters. Any local user can access all
shared buffers from
We got the minor number base right, but limit is too big and causes the
minor numer ranges for the control and render nodes to overlap.
Signed-off-by: Kristian Høgsberg
---
drivers/gpu/drm/drm_stub.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm
without
a master, potentially in headless setups such as video-transcoding or
GPGPU work.
Signed-off-by: Kristian Høgsberg
---
drivers/gpu/drm/drm_drv.c | 13 +++--
drivers/gpu/drm/drm_fops.c |9 ++---
drivers/gpu/drm/drm_pci.c |9 +
include/drm/drmP.h
Enable support for drm render nodes for i915 by flagging the ioctls that
are safe and just needed for rendering.
Signed-off-by: Kristian Høgsberg
---
drivers/gpu/drm/i915/i915_dma.c | 36 ++--
drivers/gpu/drm/i915/i915_drv.c |3 ++-
2 files changed, 20
On Fri, Oct 5, 2012 at 9:36 AM, Imre Deak wrote:
> Needed by the upcoming DRM raw monotonic timestamp support.
I just had a quick look at driver/input/evdev.c, since evdev devices
did a similar change recently to allow evdev timestamp from the
monotonic clock. They're using a different time API:
On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes wrote:
> On Mon, 14 Nov 2011 21:47:09 +0100
> David Herrmann wrote:
>> > I had to modify the resolution the test was searching for
>> > to 1920x1200 instead of 1024x600 since I tested on a DP attached
>> > monitor, and fix the connector id, but other
2011/11/15 David Herrmann :
> 2011/11/15 Kristian Høgsberg :
>> On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes
>> wrote:
>>> On Mon, 14 Nov 2011 21:47:09 +0100
>>> David Herrmann wrote:
>>>> > I had to modify the resolution the test was searching f
On Wed, Feb 22, 2012 at 2:29 PM, Ben Widawsky wrote:
> From: Dave Airlie
>
> ---
> drivers/gpu/drm/Makefile | 2 +-
> drivers/gpu/drm/drm_drv.c | 3 +
> drivers/gpu/drm/drm_gem.c | 3 +-
> drivers/gpu/drm/drm_prime.c | 126
> +++
> includ
On Wed, Apr 18, 2012 at 10:36 AM, Daniel Vetter wrote:
> On Wed, Apr 18, 2012 at 05:26:07PM +0300, Ville Syrjälä wrote:
>> On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
>> > On 04/18/2012 02:25 PM, Rob Clark wrote:
>> > > On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim
>> > >
On Fri, Apr 20, 2012 at 6:20 AM, Dave Airlie wrote:
> On Thu, Apr 12, 2012 at 7:19 PM, Ilija Hadzic
> wrote:
>> The following set of patches is the reword of the series
>> sent two weeks ago [2] that will revive the drm-render-nodes [1]
>> branch. Details of the original series are described in [
Kristian
> CC: Kristian Høgsberg
> Signed-off-by: Chad Versace
> ---
> dri2proto.txt | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/dri2proto.txt b/dri2proto.txt
> index df763c7..7bde067 100644
> --- a/dri2proto.txt
>
On Tue, Nov 9, 2010 at 7:35 PM, Joe Perches wrote:
> Using %pV reduces the number of printk calls and
> eliminates any possible message interleaving from
> other printk calls.
>
> Signed-off-by: Joe Perches
> ---
> drivers/gpu/drm/drm_stub.c | 14 +++---
> 1 files changed, 11 insertion
On Wed, Dec 1, 2010 at 11:54 AM, Julien Cristau wrote:
> On Wed, Dec 1, 2010 at 17:10:42 +0200, Alexander Shishkin wrote:
>
>> For headers that get exported to userland and make use of u32 style
>> type names, it is advised to include linux/types.h.
>>
>> This fixes 5 headers_check warnings.
>>
>
On Sun, Feb 20, 2011 at 8:17 PM, Ben Skeggs wrote:
> From: Ben Skeggs
>
> We're coming to see a need to have a set of generic capability checks in
> the core DRM, in addition to the driver-specific ioctls that already
> exist.
Looks good to me, just one comment: I don't think we need the driver
matter). The only difference is that if we
return zero, hw/xfree86/dri/dri.c will keep trying to create a drm
drawable (look for drmCreateDrawable) every time somebody creates a
dri drawable, but since that's a noop, who cares.
Reviewed-by: Kristian Høgsberg
> Signed-off-by: Daniel Vette
clients
should be able to access the window buffers, which avoids leaking buffer
access to other X servers or unpriviledged X clients.
Signed-off-by: Kristian Høgsberg
---
We've discussed how the current drm security model is broken in
different ways before. This is my proposal for fixi
On Thu, Jul 8, 2010 at 11:59 AM, Keith Packard wrote:
> On Thu, 8 Jul 2010 11:23:25 -0400, Kristian Høgsberg
> wrote:
>
>> - a mechanism to attach a binary blob to an flink_to buffer name.
>> open_with_data returns the data. Userspace (typically libdrm)
>>
On Thu, Jul 8, 2010 at 12:49 PM, Jesse Barnes wrote:
> On Thu, 08 Jul 2010 17:37:20 +0100
> Chris Wilson wrote:
>
>> On Thu, 8 Jul 2010 12:14:28 -0400, Kristian Høgsberg
>> wrote:
>> > On Thu, Jul 8, 2010 at 11:59 AM, Keith Packard wrote:
>> > > On
2010/7/8 Kristian Høgsberg :
...
> In the work on the EGL extension, the other Khronos members have
> indicated that sharing buffers by passing an integer could work for
> their implementations too, and that's what the draft standard
> currently requires. I could try to get
Ok, so the flink_to discussion rat-holed a bit on the binary blob
attachment issue. But before we even get to that, there are a lot of
issues that I'd some feedback on as well. There were a few bugs in
the patch that I've fixed, but I don't see the point in sending it out
again just yet, as I'd l
[ Let's try this again... ]
Ok, so the flink_to discussion rat-holed a bit on the binary blob
attachment issue. But before we even get to that, there are a lot of
issues that I'd some feedback on as well. There were a few bugs in
the patch that I've fixed, but I don't see the point in sending it
2010/7/12 Dave Airlie :
> On Mon, 2010-07-12 at 11:55 -0400, Kristian Høgsberg wrote:
>> [ Let's try this again... ]
>>
>> Ok, so the flink_to discussion rat-holed a bit on the binary blob
>> attachment issue. But before we even get to that, there are a lot of
>
On Wed, Aug 11, 2010 at 3:58 PM, Davidlohr Bueso wrote:
> On Wed, 2010-08-11 at 07:35 -0700, Joe Perches wrote:
>> On Wed, 2010-08-11 at 09:18 -0400, Davidlohr Bueso wrote:
>> > memory allocation in drm_bufs.c is followed by initializing the memory
>> > with 0.
>> >
>> > Replace the use of kmallo
On Mon, Aug 23, 2010 at 4:53 PM, Daniel Vetter wrote:
> There's no point in jumping through two indirections. So kill one
> and call the kernels agp functions directly.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_agpsupport.c | 40 +++--
> drive
On Wed, Apr 18, 2012 at 10:36 AM, Daniel Vetter wrote:
> On Wed, Apr 18, 2012 at 05:26:07PM +0300, Ville Syrj?l? wrote:
>> On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
>> > On 04/18/2012 02:25 PM, Rob Clark wrote:
>> > > On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim> > > sam
On Fri, Apr 20, 2012 at 6:20 AM, Dave Airlie wrote:
> On Thu, Apr 12, 2012 at 7:19 PM, Ilija Hadzic
> wrote:
>> The following set of patches is the reword of the series
>> sent two weeks ago [2] that will revive the drm-render-nodes [1]
>> branch. Details of the original series are described in [
On Wed, Feb 22, 2012 at 2:29 PM, Ben Widawsky wrote:
> From: Dave Airlie
>
> ---
> ?drivers/gpu/drm/Makefile ? ?| ? ?2 +-
> ?drivers/gpu/drm/drm_drv.c ? | ? ?3 +
> ?drivers/gpu/drm/drm_gem.c ? | ? ?3 +-
> ?drivers/gpu/drm/drm_prime.c | ?126
> +++
> ?includ
On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes
wrote:
> On Mon, 14 Nov 2011 21:47:09 +0100
> David Herrmann wrote:
>> > I had to modify the resolution the test was searching for
>> > to 1920x1200 instead of 1024x600 since I tested on a DP attached
>> > monitor, and fix the connector id, but other
2011/11/15 David Herrmann :
> 2011/11/15 Kristian H?gsberg :
>> On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes
>> wrote:
>>> On Mon, 14 Nov 2011 21:47:09 +0100
>>> David Herrmann wrote:
> I had to modify the resolution the test was searching for
> to 1920x1200 instead of 1024x600 since
flink_to is similar to flink, but the global name is only made available to
one other drm fd, identified by the existing drm_magic_t cookie mechanism.
flink_to names are transient. Once the receiving fd opens a name, it
goes away. flink_to lets application attach a binary blob of data to the
nam
On Thu, Jul 8, 2010 at 11:59 AM, Keith Packard wrote:
> On Thu, ?8 Jul 2010 11:23:25 -0400, Kristian H?gsberg
> wrote:
>
>> ?- a mechanism to attach a binary blob to an flink_to buffer name.
>> ? ?open_with_data returns the data. ?Userspace (typically libdrm)
>> ? ?decides the layout and version
On Thu, Jul 8, 2010 at 12:49 PM, Jesse Barnes
wrote:
> On Thu, 08 Jul 2010 17:37:20 +0100
> Chris Wilson wrote:
>
>> On Thu, 8 Jul 2010 12:14:28 -0400, Kristian H?gsberg
>> wrote:
>> > On Thu, Jul 8, 2010 at 11:59 AM, Keith Packard
>> > wrote:
>> > > On Thu, ?8 Jul 2010 11:23:25 -0400, Krist
2010/7/8 Kristian H?gsberg :
...
> In the work on the EGL extension, the other Khronos members have
> indicated that sharing buffers by passing an integer could work for
> their implementations too, and that's what the draft standard
> currently requires. ?I could try to get that changed to a
> siz
Ok, so the flink_to discussion rat-holed a bit on the binary blob
attachment issue. But before we even get to that, there are a lot of
issues that I'd some feedback on as well. There were a few bugs in
the patch that I've fixed, but I don't see the point in sending it out
again just yet, as I'd l
[ Let's try this again... ]
Ok, so the flink_to discussion rat-holed a bit on the binary blob
attachment issue. But before we even get to that, there are a lot of
issues that I'd some feedback on as well. There were a few bugs in
the patch that I've fixed, but I don't see the point in sending it
2010/7/12 Dave Airlie :
> On Mon, 2010-07-12 at 11:55 -0400, Kristian H?gsberg wrote:
>> [ Let's try this again... ]
>>
>> Ok, so the flink_to discussion rat-holed a bit on the binary blob
>> attachment issue. ?But before we even get to that, there are a lot of
>> issues that I'd some feedback on a
On Tue, Nov 9, 2010 at 7:35 PM, Joe Perches wrote:
> Using %pV reduces the number of printk calls and
> eliminates any possible message interleaving from
> other printk calls.
>
> Signed-off-by: Joe Perches
> ---
> ?drivers/gpu/drm/drm_stub.c | ? 14 +++---
> ?1 files changed, 11 insertion
et an error and fall back to the user provided size.
Signed-off-by: Kristian Høgsberg
---
intel/intel_bufmgr_gem.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index f98f7a7..278f5c8 100644
--- a/
On Thu, Apr 29, 2010 at 5:14 AM, Daniel Vetter
wrote:
> The information supplied by userspace through these ioctls is only
> accessible by dev->drw_idr. But there's no in-tree user of that.
> Information might also leak via the RM_DRAW ioctl (in the form of
> a negative return code in case the dr
On Wed, Aug 11, 2010 at 3:58 PM, Davidlohr Bueso wrote:
> On Wed, 2010-08-11 at 07:35 -0700, Joe Perches wrote:
>> On Wed, 2010-08-11 at 09:18 -0400, Davidlohr Bueso wrote:
>> > memory allocation in drm_bufs.c is followed by initializing the memory
>> > with 0.
>> >
>> > Replace the use of kmallo
On Mon, Aug 23, 2010 at 4:53 PM, Daniel Vetter
wrote:
> There's no point in jumping through two indirections. So kill one
> and call the kernels agp functions directly.
>
> Signed-off-by: Daniel Vetter
> ---
> ?drivers/gpu/drm/drm_agpsupport.c | ? 40 +++--
> ?driv
On Wed, Dec 1, 2010 at 11:54 AM, Julien Cristau wrote:
> On Wed, Dec ?1, 2010 at 17:10:42 +0200, Alexander Shishkin wrote:
>
>> For headers that get exported to userland and make use of u32 style
>> type names, it is advised to include linux/types.h.
>>
>> This fixes 5 headers_check warnings.
>>
>
On Sun, Feb 20, 2011 at 8:17 PM, Ben Skeggs wrote:
> From: Ben Skeggs
>
> We're coming to see a need to have a set of generic capability checks in
> the core DRM, in addition to the driver-specific ioctls that already
> exist.
Looks good to me, just one comment: I don't think we need the driver
It's the same situation as flink and we need take the same pre-cautions.
---
intel/intel_bufmgr_gem.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 3bcc849..92c0444 100644
--- a/intel/intel_bufmgr_gem.c
+++ b
On Fri, Sep 14, 2012 at 4:40 PM, Chris Wilson
wrote:
> On Fri, 14 Sep 2012 16:37:53 -0400, Kristian H?gsberg
> wrote:
>> It's the same situation as flink and we need take the same pre-cautions.
>> ---
>> intel/intel_bufmgr_gem.c |8 +++-
>> 1 file changed, 7 insertions(+), 1 deletion(-
On Fri, Sep 14, 2012 at 5:03 PM, Chris Wilson
wrote:
> On Fri, 14 Sep 2012 17:01:18 -0400, Kristian H?gsberg
> wrote:
>> On Fri, Sep 14, 2012 at 4:40 PM, Chris Wilson
>> wrote:
>> > On Fri, 14 Sep 2012 16:37:53 -0400, Kristian H?gsberg > > bitplanet.net> wrote:
>> >> It's the same situation a
On Wed, Sep 12, 2012 at 06:47:56PM +0100, Damien Lespiau wrote:
> From: Damien Lespiau
>
> Signed-off-by: Damien Lespiau
> ---
> include/drm/drm_mode.h | 35 +--
> xf86drmMode.h | 35 +--
> 2 files changed, 42 insertions(+
On Wed, Sep 12, 2012 at 06:48:19PM +0100, Damien Lespiau wrote:
> From: Damien Lespiau
>
> Now that modes have flags to describe which 3d formats the sink
> supports, it's time to test them.
>
> The new test cycles through the supported 3D formats and paint 3D
> stereoscopic images taken from pu
On Fri, Sep 14, 2012 at 5:14 PM, Jesse Barnes
wrote:
> On Wed, 12 Sep 2012 21:58:31 +0300
> Ville Syrj?l? wrote:
>
>> On Wed, Sep 12, 2012 at 01:00:19PM -0500, Clark, Rob wrote:
>> > On Wed, Sep 12, 2012 at 12:27 PM, Ville Syrj?l?
>> > wrote:
>> > > On Wed, Sep 12, 2012 at 10:48:16AM -0500, Rob
Here's the patch to implement render nodes as discussed in the "DRM2"
talk at XDC:
http://wiki.x.org/wiki/Events/XDC2012/Proceedings#DRM2
The core problem is that DRM security is compromised in the face of
VT switching and multiple DRM masters. Any local user can access all
shared buffers from
We got the minor number base right, but limit is too big and causes the
minor numer ranges for the control and render nodes to overlap.
Signed-off-by: Kristian H?gsberg
---
drivers/gpu/drm/drm_stub.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_s
This patch introduces a new kind of drm device node: the render node.
A render node exposes a safe subset of the legacy drm device ioctls and can
only be used for rendering. The legacy node supports modesetting, DRI1
and global buffer sharing, while the render node only supports rendering
and limi
Enable support for drm render nodes for i915 by flagging the ioctls that
are safe and just needed for rendering.
Signed-off-by: Kristian H?gsberg
---
drivers/gpu/drm/i915/i915_dma.c | 36 ++--
drivers/gpu/drm/i915/i915_drv.c |3 ++-
2 files changed, 20 inser
On Fri, Feb 14, 2014 at 09:31:45AM +0200, Pekka Paalanen wrote:
> On Thu, 13 Feb 2014 18:18:23 +
> "Yeh, Sinclair" wrote:
>
> > > The below seems fine, but I wonder if we could make this one cause an
> > > error to be returned later where we can, rather than silently ignoring.
> > > I'm not s
On Wed, May 2, 2012 at 3:03 PM, Chad Versace
wrote:
> Fix the documented opcodes in dri2proto.txt to be consistent with the
> actual opcode values in dri2proto.h and in xcb/proto:src/dri2.xml. (It
> looks like the opcodes were incorrect due to copy-paste errors).
Looks correct to me.
Kristian
>
On Thu, Oct 31, 2013 at 04:13:14PM -0700, Keith Packard wrote:
> Returns a prime file descriptor for the specified region.
>
> Signed-off-by: Keith Packard
> ---
> src/mesa/drivers/dri/i915/intel_regions.c | 13 +
> src/mesa/drivers/dri/i915/intel_regions.h | 4
> src/mesa/driv
1 - 100 of 124 matches
Mail list logo
