flags.
>
> Until that work lands, add a local workaround.
>
> v2: Use bitwise or (Deepak)
>
> Cc: VMware Graphics
> Cc: Thomas Hellstrom
> Cc: Deepak Singh Rawat
> Signed-off-by: Emil Velikov
> ---
> I'd like to merge this and the next patch hrough the drm-
On Mon, 2019-07-22 at 18:40 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Realistically no drivers, but vmwgfx care about the DRM_AUTH flag
> here.
>
> Follow-up work in this driver will properly isolate primary clients
> from
> different master realms, thus we'll no longer need to parse _
> Hi Deepak,
>
> As far as I can tell Thomas is on holidays for another 2+ weeks.
>
> Is there anyone else in the team who can review the VMWare patches of
> this series? I tested the lot quickly, but additional confirmation
> would
> be appreciated.
>
> You can find the series via the "VMware G
Hi Colin,
Reviewed-by: Deepak Rawat
Thanks,
Deepak
On Mon, 2019-06-24 at 23:44 +0100, Colin King wrote:
> From: Colin Ian King
>
> Variable sub_res is initialized to a value that is never read and it
> is re-assigned later in a for-loop. The initialization is redundant
> and can be removed.
Hi Sam,
Thanks for doing this.
Reviewed-by: Deepak Rawat
I did some compile/basic run test on your patchs. Things look fine.
Will include this for vmwgfx-next so can run more automated test.
On Sun, 2019-06-23 at 12:23 +0200, Sam Ravnborg wrote:
> In two steps drop the use of drmP.h
> First pa
Hi Colin,
Thanks for doing this.
Reviewed-by: Deepak Rawat
Do you want me to include this in vmwgfx-next or will you submit this
via drm-mics?
On Fri, 2019-06-21 at 23:35 +0100, Colin King wrote:
> From: Colin Ian King
>
> Currently when too many retries have occurred there is a memory
> lea
Reviewed-by: Deepak Rawat
On Tue, 2019-05-21 at 00:35 +0200, Daniel Vetter wrote:
> That's purely for the uapi layer to implement the ALLOW_MODESET flag.
>
> Drivers should instead look at the state, e.g. through
> drm_atomic_crtc_needs_modeset(), which vmwgfx already does. Also
> remove
> the c
On Wed, 2019-04-24 at 11:12 +1000, Stephen Rothwell wrote:
> Hi Deepak,
>
> On Wed, 24 Apr 2019 00:36:19 +0000 Deepak Singh Rawat <
> dra...@vmware.com> wrote:
> >
> > On Wed, 2019-04-24 at 10:22 +1000, Stephen Rothwell wrote:
> > >
> > > Commit
&
On Wed, 2019-04-24 at 10:22 +1000, Stephen Rothwell wrote:
> Hi all,
>
> Commit
>
> a9f58c456e9d ("drm/vmwgfx: Be more restrictive when dirtying
> resources")
Hi Stephen,
Actully the Signed-off-by: is not missing see
https://cgit.freedesktop.org/drm/drm/commit/drivers/gpu/drm/vmwgfx?id=a9f5
On Wed, 2019-04-24 at 06:55 +1000, Dave Airlie wrote:
> I'll merge it, but it appears patchwork failed to find this pull
> request.
>
> What version of git was used to generate it?
git version 2.17.1
>
> Dave.
>
> On Sat, 20 Apr 2019 at 03:36, Deepak Singh Rawa
Minor nits below
Reviewed-by: Deepak Rawat
On Fri, 2019-04-12 at 16:04 +, Thomas Hellstrom wrote:
> Add the callbacks necessary to implement emulated coherent memory for
> surfaces. Add a flag to the gb_surface_create ioctl to indicate that
> surface memory should be coherent.
> Also bump th
Minor nits below, otherwise
Reviewed-by: Deepak Rawat
On Fri, 2019-04-12 at 09:04 -0700, Thomas Hellstrom wrote:
> Similar to write-coherent resources, make sure that from the user-
> space
> point of view, GPU rendered contents is automatically available for
> reading by the CPU.
>
> Signed-of
Reviewed-by: Deepak Rawat
On Fri, 2019-04-12 at 09:04 -0700, Thomas Hellstrom wrote:
> With emulated coherent memory we need to be able to quickly look up
> a resource from the MOB offset. Instead of traversing a linked list
> with
> O(n) worst case, use an RBtree with O(log n) worst case complex
Hi Thomas,
With minor comments below
Reviewed-by: Deepak Rawat
On Fri, 2019-04-12 at 09:04 -0700, Thomas Hellstrom wrote:
> This infrastructure will, for coherent resources, make sure that
> from the user-space point of view, data written by the CPU is
> immediately
> automatically available to
It seems this got missed, If no one has any objection I will submit the
patches via drm-mics route.
Deepak
On Tue, 2019-04-09 at 12:49 -0700, Deepak Singh Rawat wrote:
> Hi Daniel/Dave,
>
> The vmwgfx-next changes for 5.2:
> Resource dirtying improvement by Thomas,
> user-spac
> >
> > If you mean ssh on annarchy.freedesktop.org, I already have one
> > with
> > username - drawat
>
> You're added. Please check out the dim toturial and pls ask any
> questions here or on irc or wherever - drm(-misc) maintainers are
> happy to help out.
> -Daniel
>
Hi I followed the inst
On Tue, 2019-04-16 at 20:15 +0200, Daniel Vetter wrote:
> On Tue, Apr 16, 2019 at 6:21 PM Deepak Singh Rawat > wrote:
> >
> > On Tue, 2019-04-16 at 09:42 +0200, Daniel Vetter wrote:
> > > On Mon, Apr 15, 2019 at 05:28:05PM +, Deepak Singh Rawat
> >
On Tue, 2019-04-16 at 09:42 +0200, Daniel Vetter wrote:
> On Mon, Apr 15, 2019 at 05:28:05PM +0000, Deepak Singh Rawat wrote:
> > Plane property "FB_DAMAGE_CLIPS" can only be used by atomic aware
> > user-space, so no point exposing it otherwise.
> >
> > S
Plane property "FB_DAMAGE_CLIPS" can only be used by atomic aware
user-space, so no point exposing it otherwise.
Signed-off-by: Deepak Rawat
Fixes: d3b21767821e ("drm: Add a new plane property to send damage during plane
update")
---
drivers/gpu/drm/drm_mode_config.c | 5 +++--
1 file changed,
Hi Daniel/Dave,
The vmwgfx-next changes for 5.2:
Resource dirtying improvement by Thomas,
user-space error logging improvement and
some other minor fixes.
The following changes since commit 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f:
Merge tag 'drm-misc-next-2019-04-04' of
git://anongit.freedes
No functional change with this change, just fixing formatting and
spaces.
v2: Rebase.
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 687 +++-
1 file changed, 302 insertions(+), 385 deletions(-)
diff --git a/drivers/
Several command verifier function check if context node is present or
not and if not present print an error and return. Use a preprocessor
macro to print the message.
v2: Name-space distinction for preprocessor macro
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm
Whenever command verifier function returns with an error, print a debug
message using VMW_DEBUG_USER. This will make sure failing commands can
be easily tracked for debugging purpose.
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 7 +
Error messages or debugging message reported during user-space command
submission should not be printed to dmesg by default. So add a new
preprocessor define called VMW_DEBUG_USER which translates to
DRM_DEBUG_DRIVER.
v2: Use VMW_DEBUG_USER instead of using DRM_DEBUG_DRIVER directly.
Signed-off-b
Use preprocessor macro for repetitive device command struct format.
v2: Name-space distinction for preprocessor macro.
v3: Struct name as macro parameter and rebase.
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 405 ---
DRM_ERROR overwhelms dmesgi so use VMW_DEBUG_USER instead. Any malformed
command should not really go to device so WARN_ONCE to spot this.
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 18 ++
1 file changed, 10 insertions(
Now that vmw_cmd_check prints debug message whenever a command verifier
fails, some of debug statements are unnecessary. Also rearranged some
debug print-out with this patch.
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 20 -
Whenever FIFO allocation fails an error message is printed to dmesg.
Since this is common operation a lot of similar messages are scattered
everywhere. Use preprocessor macro to remove this cluttering.
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_b
From: YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c: In function 'vmw_cmdbuf_work_func':
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:514:7: warning:
variable 'restart' set but not used [-Wunused-but-set-variable]
It not used any more after commit d
From: Chengguang Xu
unlikely has already included in IS_ERR(), so just
remove redundant unlikely annotation.
Signed-off-by: Chengguang Xu
Reviewed-by: Deepak Rawat
Signed-off-by: Deepak Rawat
---
drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 4 ++--
From: Thomas Hellstrom
Currently we flag resources as dirty (GPU contents not yet read back to
the backing MOB) whenever they have been part of a command stream.
Obviously many resources can't be dirty and others can only be dirty when
written to by the GPU. That is when they are either bound to
Thanks for doing this.
Reviewed-by: Deepak Rawat
On Sat, 2019-03-23 at 02:46 +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/vmwgfx/vmwgfx_fb.c: In function 'vmw_fb_init':
> drivers/gpu/drm/vmwgfx/vmwgfx_fb.c:645:29: warning:
> variable 'fb_offset'
Hi Thomas,
Thanks for doing this and somehow I missed the last patch, sorry about
that. Have some questions below otherwise the patch looks good to me.
Reviewed-by: Deepak Rawat
I will include your changes in vmwgfx-next and run tests.
On Mon, 2019-03-18 at 15:47 +0100, Thomas Zimmermann wrote
Hi Nathan,
Thanks for doing this. I will include this in vmwgfx-next.
Reviewed-by: Deepak Rawat
On Thu, 2019-03-07 at 15:26 -0700, Nathan Chancellor wrote:
> When building with -Wsometimes-uninitialized, Clang warns:
>
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:3964:7: warning: variable
> 'hand
Hi Chengguang,
Thanks for doing this. Will include this for vmwgfx-next
Reviewed-by: Deepak Rawat
On Thu, 2019-02-21 at 10:09 +0800, Chengguang Xu wrote:
> unlikely has already included in IS_ERR(), so just
> remove redundant unlikely annotation.
>
> Signed-off-by: Chengguang Xu
> ---
> driv
Thanks for doing this. Will include this one with next vmwgfx pull
request.
Reviewed-by: Deepak Rawat
On Thu, 2019-02-14 at 02:08 +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c: In function
> 'vmw_cmdbuf_work_func':
> drivers
Reviewed-by: Deepak Rawat
On Thu, 2019-01-31 at 10:52 +0100, Thomas Hellstrom wrote:
> if vmw_execbuf_fence_commands() fails, The handle value will be
> uninitialized and a bogus fence handle might be copied to user-space.
>
> Fixes: 2724b2d54cda: ("drm/vmwgfx: Use new validation interface for
>
Reviewed-by: Deepak Rawat
On Thu, 2019-01-31 at 11:07 +0100, Thomas Hellstrom wrote:
> The function was unconditionally returning 0, and a caller would have
> to
> rely on the returned fence pointer being NULL to detect errors.
> However,
> the function vmw_execbuf_copy_fence_user() would expect
For the series
Reviewed-by: Deepak Rawat
On Tue, 2019-01-29 at 14:35 +0100, Thomas Hellstrom wrote:
> Previously we set only the dma mask and not the coherent mask. Fix
> that.
> Also, for clarity, make sure both are initially set to 64 bits.
>
> Fixes: 0d00c488f3de: ("drm/vmwgfx: Fix the drive
On Wed, 2019-01-09 at 18:49 +0100, Noralf Trønnes wrote:
> Hi,
>
> I was really pleased to see that the damage helper had landed. Now I
> can
> do framebuffer flushing solely through the display pipe functions.
> This
> prepares the ground for the removal of struct tinydrm_device in my
> next
> se
On Tue, 2018-12-25 at 07:01 -0800, Thomas Hellstrom wrote:
> On Mon, 2018-12-24 at 11:49 +0100, Daniel Vetter wrote:
> > On Fri, Dec 21, 2018 at 8:56 PM Thomas Hellstrom <
> > thellst...@vmware.com> wrote:
> > > Reviewed-by: Thomas Hellstrom
> > >
> > > Daniel, Dave, could you help try to get thi
Reviewed-by: Deepak Rawat
On Wed, 2018-12-12 at 10:38 -0800, Thomas Hellstrom wrote:
> Hi, Deepak,
>
> On Wed, 2018-12-12 at 10:00 -0800, Deepak Singh Rawat wrote:
> > On Wed, 2018-12-12 at 15:35 +0100, Thomas Hellstrom wrote:
> > > With the new validation code, a
On Wed, 2018-12-12 at 15:35 +0100, Thomas Hellstrom wrote:
> With the new validation code, a malicious user-space app could
> potentially submit command streams with enough buffer-object and
> resource
> references in them to have the resulting allocated validion nodes and
> relocations make the ke
> Hi Deepak,
>
> Something to consider, with this approach we kind of break the
> following behaviour:
> "Only tests enabled as module parameters are run, if no test is
> explicitly enabled then all of them are run"
>
> What I think we should do is have just one header where we put the
> selftes
> On Tue, Oct 16, 2018 at 01:46:09PM -0700, Deepak Rawat wrote:
> > Selftest for drm damage helper iterator functions.
> >
> > Cc: Daniel Vetter
> > Cc: alexandru-cosmin.gheor...@arm.com
> > Signed-off-by: Deepak Rawat
> > Reviewed-by: Daniel Vetter
> > Reviewed-by: Thomas Hellstrom
>
> I gues
>
> On Tue, Oct 16, 2018 at 02:21:17PM +0200, Daniel Vetter wrote:
> > On Mon, Oct 15, 2018 at 04:11:41PM +0000, Deepak Singh Rawat wrote:
> > > > On Wed, Oct 10, 2018 at 05:16:43PM -0700, Deepak Rawat wrote:
> > > > > Selftest for drm damage helper ite
> > > Obviously needs some adjusting on the igt side too, since we seem to be
> > > missing the igt scaffolding for tests-drm-helper.ko.
> > > -Daniel
> >
> > Hi Daniel,
> >
> > Thanks for the review. I am a little confused here. Should we have single
> > kernel module for drm plane helper selftest
> On Wed, Oct 10, 2018 at 05:16:43PM -0700, Deepak Rawat wrote:
> > Selftest for drm damage helper iterator functions.
> >
> > Cc: ville.syrj...@linux.intel.com
> > Cc: Daniel Vetter
> > Cc: Pekka Paalanen
> > Cc: Daniel Stone
> > Cc: intel-...@lists.freedesktop.org
> > Cc: igt-...@lists.freedes
> drivers/gpu/drm/selftests/drm_damage_helper_selftests.h
> > create mode 100644 drivers/gpu/drm/selftests/test-
> drm_damage_helper.c
> >
> > diff --git a/drivers/gpu/drm/selftests/Makefile
> b/drivers/gpu/drm/selftests/Makefile
> > index 9fc349fa18e9..88ac216f5962 100644
> > --- a/drivers/gpu/dr
> 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 (ie. when we can't
> > rely on pageflips to trigger a flush to the panel).
> >
>
> > > > +#include
> > > > +#include
> > > > +
> > > > +/**
> > > > + * DOC: overview
> > > > + *
> > > > + * FB_DAMAGE_CLIPS is an optional plane property which provides a
> > > means to
> > > > + * specify a list of damage rectangles on a plane in framebuffer
> > > coordinates of
> > > > + * th
>
> On Thu, 6 Sep 2018 21:36:51 +0000
> Deepak Singh Rawat wrote:
>
> > >
> > > - Why no input validation on the damage clips against the framebuffer
> > > size? Ime not validating just leads to funny driver bugs down the road,
> > > so what&
>
> On Wed, Sep 05, 2018 at 04:38:48PM -0700, Deepak Rawat wrote:
> > From: Lukasz Spintzyk
> >
> > FB_DAMAGE_CLIPS is an optional plane property to mark damaged regions
> > on the plane in framebuffer coordinates of the framebuffer attached to
> > the plane.
> >
> > The layout of blob data is si
> > drivers/gpu/drm/drm_atomic_helper.c | 4
> > include/drm/drm_damage_helper.h | 10 ++
> > 2 files changed, 14 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> > index be83e2763c18..e06d2d5d582f 100644
> > --- a/d
> > #include
> >
> > /**
> > @@ -75,6 +76,11 @@
> > * While kernel does not error for overlapped damage clips, it is
> discouraged.
> > */
> >
> > +static int convert_fixed_to_32(int fixed)
> > +{
> > + return ((fixed >> 15) & 1) + (fixed >> 16);
> > +}
> > +
> > /**
> > * drm_plane_en
> >
> > +FB_DAMAGE_CLIPS
> > +~~~
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_damage_helper.c
> > + :doc: overview
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_damage_helper.c
> > + :export:
>
> You forgot to include your nice kerneldoc from the header. Please run
>
> $ make
Hi, thanks for the patch. Perhaps can get rid of vmw_kms_resume
and vmw_kms_suspend, otherwise looks good to me.
>
> convert drm_atomic_helper_suspend/resume() to use
> drm_mode_config_helper_suspend/resume().
>
> suspend_state can be removed from vmw_private as
> it will not be used anymore.
>
Looks good to me based on my limited understanding. Thomas/Sinclair can
could you please review and then we can include this in drm-fixes.
Thanks,
Deepak
>
> arg.version is indirectly controlled by user-space, hence leading to
> a potential exploitation of the Spectre variant 1 vulnerability.
>
Hi Alexandru,
Thanks for the patch, for the vmwgfx part:
Reviewed-by: Deepak Rawat
>
> Signed-off-by: Alexandru Gheorghe cosmin.gheor...@arm.com>
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vm
>
> On Fri, Apr 06, 2018 at 10:35:00PM +0300, Ville Syrjälä wrote:
> > On Fri, Apr 06, 2018 at 07:14:51PM +0000, Deepak Singh Rawat wrote:
> > > This makes sense once we got rid of plane->fb
> > >
> > > Will this go to drm-next?
> >
> > The pl
>Hi,
>
>Many thanks that you have picked it up.
>Unfortunately I didn't had time to work on it for a while.
>
>I am ok with what you have done, ihmo the review is going in good direction.
>I will try not to miss your update of it.
>From my side I can say that damage rects with frame-buffer coordina
> > > > +void drm_plane_enable_damage_clips(struct drm_plane *plane)
> > > > +{
> > > > + struct drm_device *dev = plane->dev;
> > > > + struct drm_mode_config *config = &dev->mode_config;
> > > > +
> > > > + drm_object_attach_property(&plane->base, config-
> > > >prop_damage_clip
This makes sense once we got rid of plane->fb
Will this go to drm-next? Could you please CC
me so that I can do some testing myself. Thanks.
Reviewed-by: Deepak Rawat
>
> From: Ville Syrjälä
>
> We want to get rid of plane->fb on atomic drivers. Stop setting it.
>
> Cc: Thomas Hellstrom
>
>
> From: Ville Syrjälä
>
> Instead of looking at the (soon to be deprecated) plane->fb we'll
> examing plane->state->fb instead. We can do this because
> vmw_du_crtc_atomic_check() prevents us from enabling a crtc
> without the primary plane also being enabled.
>
> Due to that same reason, I'm
Reviewed-by: Deepak Rawat
>
> From: Ville Syrjälä
>
> The only caller of vmw_kms_update_implicit_fb() is the page_flip
> hook which itself gets called with the plane mutex already held.
> Hence we can look at plane->state safely. Toss in a lockdep assert
> to make the situation more clear.
>
> >>> 1) Expose a dirty (or content_age property)
> >>> 2) Attach a clip-rect blob property.
> >>> 3) Fake a page-flip by ping-ponging two frame-buffers pointing to the
> >>> same
> >>> underlying buffer object.
> >>>
> >>> Are you saying that people are already using 3) and we should keep
> using
> plane damage.
>
> On 04/05/2018 09:52 AM, Daniel Vetter wrote:
> >
> > TYPE_PLANE I have no idea who needs that. I suggest we just drop it.
>
> I'm assuming CRTC plane coordinates here. They are used for uploading
> contents of hardware planes. Like, in the simplest case, cursor images.
Yes th
>
> On Wed, Apr 04, 2018 at 04:49:08PM -0700, Deepak Rawat wrote:
> > This patch adds a helper which should be called by driver which enable
> > damage (by calling drm_plane_enable_damage_clips) from atomic_check
> > hook. This helper for now set the damage to NULL for the planes on crtc
> > which
>
> On Wed, Apr 04, 2018 at 04:49:07PM -0700, Deepak Rawat wrote:
> > With damage property in drm_plane_state, this patch adds helper iterator
> > to traverse the damage clips. Iterator will return the damage rectangles
> > in framebuffer, plane or crtc coordinates as need by driver
> > implementa
>
> On Wed, Apr 04, 2018 at 04:49:06PM -0700, Deepak Rawat wrote:
> > From: Lukasz Spintzyk
> >
> > Optional plane property to mark damaged regions on the plane in
> > framebuffer coordinates of the framebuffer attached to the plane.
> >
> > The layout of blob data is simply an array of drm_mode_
>
> On Thu, Apr 05, 2018 at 08:15:05PM +, Deepak Singh Rawat wrote:
> >
> > >
> > > From: Ville Syrjälä
> > >
> > > Instead of looking at plane->fb let's look at the proper new
> > > plane state.
> > >
> > >
>
> From: Ville Syrjälä
>
> Instead of looking at plane->fb let's look at the proper new
> plane state.
>
> Not that the code makes a ton of sense. It's only going through the
> crtcs in the atomic state, so assuming not all of them are included
> we're not even calculating the total bandwidth
>
> On Wed, Apr 04, 2018 at 04:49:05PM -0700, Deepak Rawat wrote:
> > Hi All,
> >
> > This is extension to Lukasz Spintzyk earlier draft of damage interface for
> drm.
> > Bascially a new plane property is added called "DAMAGE_CLIPS" which is
> simply
> > an array of drm_rect (exported to userspac
> -Original Message-
> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> Of Daniel Vetter
> Sent: Thursday, December 21, 2017 5:11 AM
> To: Ville Syrjälä
> Cc: airl...@linux.ie; daniel.vet...@intel.com; dri-
> de...@lists.freedesktop.org; Lukasz Spintzyk
>
> S
work.
Thanks,
Deepak
From: Lukasz Spintzyk [mailto:lukasz.spint...@displaylink.com]
Sent: Thursday, January 4, 2018 5:53 AM
To: Thomas Hellstrom ; dri-devel@lists.freedesktop.org;
daniel.vet...@intel.com; gust...@padovan.org; seanp...@chromium.org;
airl...@linux.ie; Deepak Singh Rawat
Subject
Thanks Rob for finding this one.
Reviewed-by: Deepak Rawat
> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> Of Rob Clark
> Sent: Wednesday, January 17, 2018 7:16 AM
> To: dri-devel@lists.freedesktop.org
> Cc: Thomas Hellstrom ; Rob Clark
> ; David Airlie ; linux-
>
Hi Michal,
Are you currently working on this feature. I started to look into page flip
with damage for VMware drivers.
Thanks,
Deepak
> -Original Message-
> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> Of Michal Lukaszek
> Sent: Tuesday, September 26, 20
Hi All,
I need your help in determining the behavior of drmModeSetCrtc when it is
called with a FB and mode. Should it display the content of FB to physical
screen or not?
I ran the program
https://github.com/dvdhrm/docs/blob/master/drm-howto/modeset.c with Vmware's
vmwgfx drm driver and it w
78 matches
Mail list logo
