From: Emil Velikov
Currently as the workaround is applied the screen flickers. As a result
we do not achieve seamless boot experience.
Avoiding the issue in the common use-case might be hard, although we can
resolve it for dual GPU setups - when the "other" GPU is primary and/or
o
On Fri, 4 Jun 2021 at 15:08, Ville Syrjälä
wrote:
>
> On Fri, Jun 04, 2021 at 02:47:16PM +0100, Emil Velikov wrote:
> > On Wed, 26 May 2021 at 17:21, Emil Velikov wrote:
> > >
> > > Hi Ville,
> > >
> > > On Tue, 18 May 2021 at 12:17, Ville Syrj
On Fri, 4 Jun 2021 at 16:49, Emil Velikov wrote:
>
> From: Emil Velikov
>
> Currently as the workaround is applied the screen flickers. As a result
> we do not achieve seamless boot experience.
>
> Avoiding the issue in the common use-case might be hard, although we can
>
On Thu, 10 Jun 2021 at 11:10, Daniel Vetter wrote:
>
> On Wed, Jun 09, 2021 at 05:21:19PM +0800, Desmond Cheong Zhi Xi wrote:
> > This patch eliminates the following smatch warning:
> > drivers/gpu/drm/drm_auth.c:320 drm_master_release() warn: unlocked access
> > 'master' (line 318) expected lock
On Fri, 11 Jun 2021 at 10:47, Daniel Vetter wrote:
>
> On Thu, Jun 10, 2021 at 02:36:59PM -0700, Dongwon Kim wrote:
> > Render clients should be able to create/destroy dumb object to import
> > and use it as render buffer in case the default DRM device is different
> > from the render device (i.e.
we implement
> drm_is_current_master_locked() to be used within drm_auth.c, and
> modify drm_is_current_master() to grab the device's master mutex
> before checking the master status.
>
> Reported-by: Daniel Vetter
> Signed-off-by: Desmond Cheong Zhi Xi
Reviewed-by: Emil Velikov
-Emil
;get lease for %d\n", lessee->lessee_id);
>
> + mutex_lock(&dev->master_mutex);
As-is we're dereferencing an uninitialised pointer in DRM_DEBUG_LEASE.
Move the lock and assignment before the DRM_DEBUG_LEASE, just like
you've done in the list ioctl.
With this fix, the patch is;
Reviewed-by: Emil Velikov
-Emil
On 2023/03/06, Dmitry Osipenko wrote:
> VirtIO-GPU got a new config option for disabling KMS. There were two
> problems left unnoticed during review when the new option was added:
>
> 1. The IS_ENABLED(CONFIG_DRM_VIRTIO_GPU_KMS) check in the code was
> inverted, hence KMS was disabled when it shou
option to disable KMS support")
> > Signed-off-by: Dmitry Osipenko
> > ---
>
> Added r-b from Emil and applied to misc-next
>
For anyone wondering: I've sent that in private, adding here for posterity
Reviewed-by: Emil Velikov
-Emil
t; Daniel Vetter
> Cai Huoqing
> Neil Roberts
> Marek Szyprowski
> Emil Velikov
> Sam Ravnborg
> Boris Brezillon
> Dan Carpenter
>
> Signed-off-by: Robert Swindells
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +-
> include/drm/drm_gem_shmem_helper.h
On Sat, 3 Dec 2022 at 09:45, Cai Huoqing wrote:
>
> Commit 399516ab0fee ("MAINTAINERS: Add a bunch of legacy (UMS) DRM drivers")
> marked these drivers obsolete 7 years ago.
As the author of said patch - calling them obsolete was a bad decision
on my part.
They are effectively orphan with no main
? Consistency across drivers and all that.
>
> Hmm, I guess I could _also_ store the overridden comm/cmdline in
> drm_file. I still need to track it in ctx (msm_file_private) because
> I could need it after the file is closed.
>
> Maybe it could be useful to have a gl extension to let the app set a
> name on the context so that this is useful beyond native-ctx (ie.
> maybe it would be nice to see that "chrome: lwn.net" is using less gpu
> memory than "chrome: phoronix.com", etc)
>
/me awaits for the series to hit the respective websites ;-)
But seriously - the series from Tvrtko (thanks for the link, will
check in a moment) makes sense. Although given the livespan issue
mentioned above, I don't think it's applicable here.
So if it were me, I would consider the two orthogonal for the
short/mid term. Fwiw this and patch 1/3 are:
Reviewed-by: Emil Velikov
HTH
-Emil
ly_
> + * become puregeable until it becomes idle. The status gem object func does
nit: s/puregeable/purgeable/
I think we want a similar note in the drm-usage-stats.rst file.
With the above the whole series is:
Reviewed-by: Emil Velikov
Fwiw: Keeping the i915 patch as part of this ser
On Fri, 21 Apr 2023 at 12:23, Tvrtko Ursulin
wrote:
> On 21/04/2023 11:26, Emil Velikov wrote:
> > On Wed, 12 Apr 2023 at 23:43, Rob Clark wrote:
> >
> >> +/**
> >> + * enum drm_gem_object_status - bitmask of object state for fdinfo
> >> reporting
&g
polish this commit
is:
Reviewed-by: Emil Velikov
I also had a brief look at 01/10, although I cannot find many
references for the pid <> tguid mappings. Be that on the kernel side
or userspace - do you have any links that I can educate myself?
Thanks
Emil
Hey Dmitry,
On 2023/03/24, Dmitry Osipenko wrote:
> Move virtio_gpu_execbuffer_ioctl() into separate virtgpu_submit.c file
> and refactor the code along the way to ease addition of new features to
> the ioctl.
>
At a glance, we have a handful of no-op as well as some functional
changes - let's s
Hi Dmitry,
Have you considered creating a few DRM helpers for this functionality?
AFAICT this is the third driver which supports syncobj timelines and
looking at one of the implementations ... it is not great. Note that
this suggestion is _not_ a blocker.
On 2023/03/24, Dmitry Osipenko wrote:
>
On Sun, 2 Apr 2023 at 18:45, Dmitry Osipenko
wrote:
>
> On 3/30/23 20:24, Emil Velikov wrote:
> > Hi Dmitry,
> >
> > Have you considered creating a few DRM helpers for this functionality?
> >
> > AFAICT this is the third driver which supports syncobj tim
On Mon, 3 Apr 2023 at 14:00, Emil Velikov wrote:
> > > I think we should zero num_(in|out)_syncobjs when the respective parse
> > > fails. Otherwise we get one "cleanup" within the parse function itself
> > > and a second during the cleanup_submit. Haven&#
cked(struct drm_gem_shmem_object *shmem)
> +{
> + struct drm_gem_object *obj = &shmem->base;
> +
> + dma_resv_assert_held(shmem->base.resv);
> +
> + drm_WARN_ON(obj->dev, obj->import_attach);
> +
Ditto.
With that the series is:
Reviewed-by; Emil Velikov
HTH
-Emil
On Mon, 3 Apr 2023 at 11:41, Thomas Zimmermann wrote:
>
> Move code from ad-hoc fbdev callbacks into DRM client functions
> and remove the old callbacks. The functions instruct the client
> to poll for changed output or restore the display. The DRM core
> calls both, the old callbacks and the new
On Mon, 3 Apr 2023 at 15:50, Thomas Zimmermann wrote:
>
> Hi
>
> Am 03.04.23 um 16:27 schrieb Emil Velikov:
> > On Mon, 3 Apr 2023 at 11:41, Thomas Zimmermann wrote:
> >>
> >> Move code from ad-hoc fbdev callbacks into DRM client functions
> >>
Greetings Sui Jingfeng,
I haven't been around drm-land for a while and this is the first
driver I skim through in a few years. So take the following
suggestions with a healthy pinch of salt.
Hope that helps o/
On Mon, 3 Apr 2023 at 18:13, Sui Jingfeng wrote:
> v7 -> v8:
>1) Zero a compil
avoid other branch build fail after merge
> drm-misc-next, just revert the lima patchset on drm-misc-next too.
>
The bug/revert is unfortunate, although we better keep the build clean
or Linus will go bananas ^_^
Fwiw for the series:
Acked-by: Emil Velikov
HTH
-Emil
s &= ~DRM_GEM_OBJECT_PURGEABLE;
Is MSM capable of marking the object as both purgeable and resident or
is this to catch other drivers? Should we add a note to the
documentation above - resident memory cannot be purgeable
> + }
> +
> + if (s & DRM_GEM_OBJECT_ACTIVE) {
> + size.active += obj->size;
> + s &= ~DRM_GEM_OBJECT_PURGEABLE;
Ditto.
With the above nits, the patch is:
Reviewed-by: Emil Velikov
HTH
Emil
DRIVER_RENDER |
> DRIVER_ATOMIC |
> DRIVER_MODESET |
> + DRIVER_SYNCOBJ_TIMELINE |
This line should probably be its own patch. AFAICT it was supported
since ab723b7a992a19b843f798b183f53f7472f598c8, although explicitly
kept disabled until there's userspace/turnip support.
With the above line removed, the patch is:
Reviewed-by: Emil Velikov
HTH
Emil
if (ret) {
> + virtio_gpu_free_post_deps(post_deps, i);
> + return ret;
> + }
> +
> + submit->num_out_syncobjs = num_out_syncobjs;
> + submit->post_deps = post_deps;
> +
> + return 0;
> +}
> +
With the two issues in virtio_gpu_parse_post_deps() addressed, the series is:
Reviewed-by; Emil Velikov
HTH
Emil
Hi Tvrtko
Sorry for the delay, real life and other obligations got in the way.
On Thu, 8 Jun 2023 at 15:26, Tvrtko Ursulin
wrote:
> On 21/04/2023 13:13, Emil Velikov wrote:
> Are you okay if I just paste your very fine explanation verbatim, with
> credits?
>
Yes, feel free to us
Hi Dmitry,
Saw v3 fly by, so I had a quick look. Original RB still stands,
although I noticed a couple of non-blocking nitpicks.
On Sun, 21 May 2023 at 22:00, Dmitry Osipenko
wrote:
> -static int drm_gem_shmem_get_pages_locked(struct drm_gem_shmem_object *shmem)
> +static int drm_gem_shmem_get_
On Mon, 17 Jul 2023 at 14:54, Simon Ser wrote:
>
> On Monday, July 17th, 2023 at 15:24, Emil Velikov
> wrote:
>
> > > > For going forward, here is one way we can shave this yak:
> > > > - update libdrm to max 64 nodes
> > > > - roll libdrm rel
On Fri, 14 Jul 2023 at 11:32, Simon Ser wrote:
>
> (cc Daniel Vetter and Pekka because this change has uAPI repercussions)
>
> On Friday, June 30th, 2023 at 13:56, James Zhu wrote:
>
> > From: Christian König
> >
> > This makes room for up to 128 DRM devices.
> >
> > Signed-off-by: Christian Kön
On Mon, 17 Jul 2023 at 10:45, Simon Ser wrote:
>
> On Monday, July 17th, 2023 at 09:30, Emil Velikov
> wrote:
>
> > > I'm worried what might happen with old user-space, especially old libdrm.
> >
> > I also share the same concern. Although the bigger
On 30 November 2016 at 00:38, Jonathan Gray wrote:
> On Tue, Nov 29, 2016 at 07:55:13PM +0000, Emil Velikov wrote:
>> On 26 November 2016 at 00:40, Jonathan Gray wrote:
>> > Implement drmParsePciDeviceInfo for OpenBSD by using the new
>> > DRM_IOCTL_GET_PCIINFO ioc
On 30 November 2016 at 00:15, Jonathan Gray wrote:
> On Tue, Nov 29, 2016 at 07:22:34PM +0000, Emil Velikov wrote:
>> On 26 November 2016 at 00:40, Jonathan Gray wrote:
>> > Implement drmGetMinorNameForFD for systems without sysfs by
>> > adapting drm_get_device_
On 30 November 2016 at 00:23, Jonathan Gray wrote:
> On Tue, Nov 29, 2016 at 07:46:31PM +0000, Emil Velikov wrote:
>> On 26 November 2016 at 00:40, Jonathan Gray wrote:
>> > Implement drmParseSubsystemType for OpenBSD by always returning
>> > DRM_BUS_PCI. No non
On 30 November 2016 at 00:00, Jonathan Gray wrote:
> On Tue, Nov 29, 2016 at 08:03:58PM +0000, Emil Velikov wrote:
>> On 26 November 2016 at 00:40, Jonathan Gray wrote:
>> > This avoids walking all of /dev and directly maps the fd to a path to a
>> > primary node.
>
From: Emil Velikov
Be consistent with drmParsePciBusInfo() and use solely the device
major/minor pair.
Cc: Jonathan Gray
Signed-off-by: Emil Velikov
---
Jonathan, please respin your patches on top of this series.
---
xf86drm.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions
From: Emil Velikov
Will be used with the drmGetDevice[s]2 API.
Cc: Michel Dänzer
Cc: Nicolai Hähnle
Cc: Mauro Santos
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98502
Signed-off-by: Emil Velikov
---
xf86drm.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions
From: Emil Velikov
... alongside the DRM_DEVICE_IGNORE_PCI_REVISION flag.
Signed-off-by: Emil Velikov
---
tests/drmdevice.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/drmdevice.c b/tests/drmdevice.c
index 72e7066..dcad527 100644
--- a/tests/drmdevice.c
From: Emil Velikov
Up-to recently (patch should land in 4.10) the kernel did not expose the
PCI device revision field as a separate sysfs file.
Thus one needed too parse the config file to retrieve it. This in
itself wakes up the device, which in some cases can be quite slow.
To avoid that
From: Emil Velikov
Relative to the original version, here one can provide a flags bitmask.
Currently only DRM_DEVICE_IGNORE_PCI_REVISION is supported.
Implementation detail:
If it's set, we will only parse the separate sysfs files and we won't
touch the config one. The latter awakes
Library is no longer used.
Signed-off-by: Emil Velikov
---
configure.ac | 7 ---
1 file changed, 7 deletions(-)
diff --git a/configure.ac b/configure.ac
index 9f25a4c..79e600c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -451,13 +451,6 @@ fi
AC_MSG_RESULT([$CAIRO])
AM_CONDITIONAL
Cc: Jakob Bornecrantz
Signed-off-by: Emil Velikov
---
Jakob, seems like libkms did not get the traction one would have
expected. With gbm, mini-gbm around and plans brewing for gbm2/liballoc
should we keep the library around ?
Afaict there hasn't been any distributions building/shipping it
em, but
in all honestly do consider _seriously_ what you're doing ;-)
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
Another small step towards the greater good ;-)
---
tests/Makefile.am| 33 +-
tests/auth.c | 138 -
tests/drist
Purely cosmetic changes.
Signed-off-by: Emil Velikov
---
tests/Makefile.am | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 136ccce..0355a92 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -26,6 +26,10
On 1 October 2016 at 01:22, Shawn Guo wrote:
> Hi Emil,
>
> On Fri, Sep 30, 2016 at 01:34:14PM +0100, Emil Velikov wrote:
>> Hi Shawn,
>>
>> A couple of fly-by suggestions, which I hope you'll find useful :-)
>
> Thanks for the suggestions.
>
>>
On 30 September 2016 at 18:26, Laszlo Ersek wrote:
> On 09/30/16 18:38, Hans de Goede wrote:
>> Hi,
>>
>> On 30-09-16 17:33, Laszlo Ersek wrote:
>>> On 09/30/16 16:59, Hans de Goede wrote:
Hi,
On 30-09-16 16:51, Laszlo Ersek wrote:
> On 09/30/16 12:35, Hans de Goede wrote:
>
On 3 October 2016 at 13:14, Laszlo Ersek wrote:
> On 10/03/16 13:34, Emil Velikov wrote:
>> On 30 September 2016 at 18:26, Laszlo Ersek wrote:
>
>>> This setup (modulo the kernel of course) was known to work, but now the
>>> X server actuall
On 3 October 2016 at 15:27, Laszlo Ersek wrote:
[snip]
> the v3 patch accidentally removed the similarly customized set_busid
> callback for amdgpu -- drm_pci_set_busid(). Emil caught that error in
> review, hence the v4 patch wouldn't contain the same error.
>
You're spot on - virtio-gpu doesn't
ek
Signed-off-by: Emil Velikov
---
Since I'm not 100% sure if we can get into .set_busid() as pci_dev is
NULL (for the virtio-vga 'vs' virgio-gpu-pci case) I've left the local
wrapper.
Note: patch is against mainline (refs/tags/v4.8) but should apply for
drm-next/other
On 3 October 2016 at 18:08, Laszlo Ersek wrote:
> On 10/03/16 18:43, Emil Velikov wrote:
>> Earlier commit was removing all the users of drm_platform_set_busid and
>> removed the virtio hunk (which uses the PCI version of the function) by
>> mistake.
>>
>> This
Hi Bjorn,
On 27 September 2016 at 18:01, Bjorn Andersson
wrote:
> On Wed 21 Sep 05:09 PDT 2016, Emil Velikov wrote:
>
>> On 20 September 2016 at 09:32, Peter Griffin
>> wrote:
>> > Hi Emil,
>> >
>> > On Tue, 20 Sep 2016, Emil Velikov wrote:
&
On 6 October 2016 at 10:37, Peter Griffin wrote:
> In fact the help text for VIRTIO even states this option should be selected
> by any driver which implements virtio.
>
Almost but not quite. It says:
"This option is selected by any driver which implements the virtio _bus_"
REMOTEPROC obviously
- Remove unnecessary snprintf and strlen usage in read callback.
>
> v5:
> - Made the crcs array in drm_crtc_crc_entry fixed-size
> - Lots of other smaller improvements suggested by Emil Velikov
>
> v7:
> - Move definition of drm_debugfs_crtc_crc_add to drm_internal
Hi Peter,
On 6 October 2016 at 11:48, Peter Griffin wrote:
> Hi Emil,
>
> On Wed, 21 Sep 2016, Emil Velikov wrote:
>
>> On 20 September 2016 at 09:32, Peter Griffin
>> wrote:
>> > Hi Emil,
>> >
>> > On Tue, 20 Sep 2016, Emil Velikov wrote:
>
On 6 October 2016 at 12:33, Tomeu Vizoso wrote:
> On 10/06/2016 01:13 PM, Emil Velikov wrote:
>> On 6 October 2016 at 09:56, Tomeu Vizoso
>> wrote:
>>> Adds files and directories to debugfs for controlling and reading frame
>>> CRCs, per CRTC:
>>>
Hi Heiko,
On 3 October 2016 at 18:26, Heiko Becker wrote:
> Helpful if your nm executable has a prefix based on the
> architecture, for example.
>
Thanks for the patch.
Currently one can run the tests as standalone. Personally I don't mind
if we "loose" that functionality or not, but in either c
Hi Dhinakaran,
On 23 September 2016 at 07:33, Dhinakaran Pandiyan
wrote:
> The positions of primary and overlay plane type enums in the kernel were
> updated in
>
> drm/doc: Polish for drm_plane.[hc]
>
> So, making the change here as well.
>
Obviously the issue is/has been fixed elsew
On 28 September 2016 at 15:27, wrote:
> From: Ville Syrjälä
>
> Devices can have multiple planes, so allow the user to choose between
> them.
>
> Signed-off-by: Ville Syrjälä
In the long term I'm wondering if we don't want to nuke/deprecate the
clunky modetest and use a slimmed down atomic
- Remove unnecessary snprintf and strlen usage in read callback.
>
> v5:
> - Made the crcs array in drm_crtc_crc_entry fixed-size
> - Lots of other smaller improvements suggested by Emil Velikov
>
> v7:
> - Move definition of drm_debugfs_crtc_crc_add to drm_internal
On 10 October 2016 at 19:35, Haixia Shi wrote:
> The AUO t215hvn01 is a 21.5" 1920x1080 panel.
>
> v2: fix alphabetical order
>
Thanks for this and dropping the CHOMIUM/Reviewed-on tags.
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1575,6 +1602,
On 11 October 2016 at 10:33, Jani Nikula wrote:
> On Tue, 11 Oct 2016, "Sun, Jing A" wrote:
>> It's needed that DRM Driver module could be removed and reloaded after
>> kernel booting on the projects that I have been working on, and I hope
>> such module type change could be accepted. Looks like
Hi Michel,
On 12 October 2016 at 10:41, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Signed-off-by: Michel Dänzer
> ---
>
> The corresponding kernel changes have landed in Linus' tree.
>
> include/drm/drm.h | 1 +
> include/drm/drm_mode.h | 39 ---
>
> Noticed by Chris Wilson.
>
> Fixes: 95c081c17f28 ("drm: Move master pointer from drm_minor to drm_device")
> Cc: Chris Wilson
> Cc: Chris Wilson
> Cc: Daniel Vetter
> Cc: Emil Velikov
> Cc: Julia Lawall
> Signed-off-by: Daniel Vetter
Oops ;-) Worth updat
there are any non-trivial commits from someone other than myself.
>
Glad to see us (almost) there :-)
Acked-by: Emil Velikov
Emil
: 4ecd1ef010b ("xf86drm: fix null termination of string buffer")
Signed-off-by: Emil Velikov
---
configure.ac | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
index 9ac8929b..18b7e8ba 100644
--- a/configure.ac
+++ b/co
On 30 March 2017 at 07:04, Jani Nikula wrote:
> On Wed, 29 Mar 2017, Marek Olšák wrote:
>> libdrm 2.4.76 has been released.
>>
>> git tag: libdrm-2.4.76
>
> Should the release tags be signed? For a couple of years that has been
> the practise until this release. Admittedly RELEASING doesn't even
when it's
> not in Linus's tree.
>
I'm not Dave, so pardon for dropping in.
AFAICT the idea is that once the feature is within a non-rebase branch
such as drm-next, it's part of the ABI. As such one can use it across
the board - be that in here, Mesa or elsewhere.
That said, the series looks great. Thanks for the updates gents.
Acked-by: Emil Velikov
Thanks
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 20 March 2017 at 00:52, Seung-Woo Kim wrote:
> This patch fixes invalid code of error path including NULL
> deference and leak in g2d test.
>
Thanks for the update. R-b and pushed to master.
For future do add v2 in the subject prefix (git send-email -v2 ...).
It makes it easier to find the cor
On 31 March 2017 at 04:30, Seung-Woo Kim wrote:
> For exynos module for libdrm, there are some build warnings, so this patch
> series remove them.
>
R-b and pushed the series.
Thanks
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https:
On 28 March 2017 at 16:35, Nicolai Hähnle wrote:
> On 27.03.2017 04:09, Seung-Woo Kim wrote:
>>
>> In error path of drmGetBusid() and drmGetReservedContextList(),
>> there are memory leaks for error path. So this removes them.
>>
>> Signed-off-by: Seung-Woo Kim
>
>
> Reviewed-by: Nicolai Hähnle
On 22 March 2017 at 19:05, Rob Herring wrote:
> Disable some more warnings from clang. These don't appear to be warnings
> worth fixing.
>
Maybe we should, but considering nobody has bothered in a long time
let's go with this for now.
R-b and pushed the series.
-Emil
_
Hi Erik,
On 29 March 2017 at 23:24, Erik Faye-Lund wrote:
> This makes the test run under the 'make check'-taget.
>
The test doesn't do anything useful but open/close the tegra device.
Do you see much value in it or we can drop it all together ?
Thierry how do you feel on the topic ?
-Emil
_
On 29 March 2017 at 23:24, Erik Faye-Lund wrote:
> I get a few more symbols in my build tegra-libraries, so let's
> include these in the whitelist as well.
>
> While we're at it, update the comment at the top.
>
> Signed-off-by: Erik Faye-Lund
R-B and pushed to master.
Out of curiosity:
What pla
On 31 March 2017 at 00:17, Eric Engestrom wrote:
> On Thursday, 2017-03-30 18:01:12 +0100, Emil Velikov wrote:
>> Accidentally removed with earlier commit. Although rather than simply
>> adding the check for all platforms, use the same heuristics as we do in
>> mesa.
>&g
On 3 April 2017 at 21:55, Erik Faye-Lund wrote:
> On Mon, Apr 3, 2017 at 6:59 PM, Emil Velikov wrote:
>> On 29 March 2017 at 23:24, Erik Faye-Lund wrote:
>>> I get a few more symbols in my build tegra-libraries, so let's
>>> include these in the whitelist as
Hi Daniel,
Zero objections against the patch, just a couple of small notes.
On 4 April 2017 at 17:52, Daniel Stone wrote:
> From: Ander Conselvan de Oliveira
>
> When using the atomic API, one request can span multiple CRTCs, however
> one event is generated per CRTC. As we cannot disambiguate
From: Emil Velikov
As mentioned on the xcb mailing list, the platform uses the GLIBC
forwarding mechanism.
https://lists.freedesktop.org/archives/xcb/2016-November/010896.html
Cc: Andreas Boll
Reported-by: Andreas Boll
Signed-off-by: Emil Velikov
---
I'm slightly inclined to go a s
> harmful.
Glad to hear, thanks for checking.
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Philipp
On 5 April 2017 at 13:34, Philipp Zabel wrote:
> Import the etnaviv header changes from kernel commits 9ad59fea162c
> ("drm/etnaviv: submit support for in-fences") and 78ec187f64fa
> ("drm/etnaviv: submit support for out-fences") for fence fd support.
>
Looking for 9ad59fea162c in airl
Hi Shashank,
On 7 April 2017 at 17:39, Shashank Sharma wrote:
> + u64 hdmi_420_cap_map = connector->display_info.hdmi.ycbcr420_vcb_map;
>
> for (i = 0; i < len; i++) {
> struct drm_display_mode *mode;
> mode = drm_display_mode_from_vic_index(connecto
Hi Laura,
Couple of trivial nitpicks below.
On 3 April 2017 at 19:57, Laura Abbott wrote:
> --- a/drivers/staging/android/ion/ion.h
> +++ b/drivers/staging/android/ion/ion.h
> @@ -1,5 +1,5 @@
> /*
> - * drivers/staging/android/ion/ion.h
> + * drivers/staging/android/ion/ion_priv.h
Does not mat
On 7 April 2017 at 13:06, Philipp Zabel wrote:
> Add etna_cmd_stream_flush2 with in-fence fd and out-fence fd support for
> explicit fencing.
>
> Signed-off-by: Philipp Zabel
> Reviewed-by: Eric Engestrom
> Reviewed-by: Christian Gmeiner
> ---
> v2: renamed etna_cmd_stream_flush_explicit to etn
On 7 April 2017 at 13:06, Philipp Zabel wrote:
> Import the etnaviv header changes from kernel commits 9ad59fea162c
> ("drm/etnaviv: submit support for in-fences") and 78ec187f64fa
> ("drm/etnaviv: submit support for out-fences") for fence fd support.
>
> The drm_etnaviv_gem_submit structure was e
On 5 April 2017 at 17:23, Tobias Jakobi wrote:
> Hello Eric,
>
>
> Eric Engestrom wrote:
>> On Wednesday, 2017-04-05 16:22:24 +0200, Tobias Jakobi wrote:
>>> Add the usual extern "C" when compiling in C++ mode.
>>
>> Thanks, but why specifically this header? The other exynos/*.h headers
>> also la
Hi Laurent,
Pardon for reviving this old thread. I've noticed a couple of things
which might want some attention.
On 19 November 2016 at 03:28, Laurent Pinchart
wrote:
> +
> +- panel-timing: Most display panels are restricted to a single resolution and
> + require specific display timings. The
Hi Thierry,
I don't mean to stir up anything, just voicing "my 2c" as they say.
On 7 April 2017 at 18:33, Thierry Reding wrote:
> Ever since the simple-panel binding was introduced, which is now about
> 3 1/2 years ago,
Do you have a link to these discussions? Your blog article does not
have a
Hi Gustavo,
Mostly some documentation suggestions below. Hope that I've not lost
the plot and they seem ok :-)
On 10 April 2017 at 01:24, Gustavo Padovan wrote:
> +static bool drm_atomic_async_check(struct drm_atomic_state *state)
> +{
/* FIXME: we support single plane updates for now */
> +
On 10 April 2017 at 10:58, Lucas Stach wrote:
> Am Montag, den 10.04.2017, 09:17 +0200 schrieb Thierry Reding:
>> On Sun, Apr 09, 2017 at 01:31:40PM +0100, Emil Velikov wrote:
>> > Hi Thierry,
>> >
>> > I don't mean to stir up anything, just voicing "
Hi Dave,
On 12 April 2017 at 05:57, Dave Airlie wrote:
> +struct drm_syncobj_handle {
> + __u32 handle;
> + /** Flags.. only applicable for handle->fd */
> + __u32 flags;
> +
> + __s32 fd;
> +};
I think this struct need a __u32 pad as well.
Thanks
Emil
__
On 12 April 2017 at 11:08, Lucas Stach wrote:
> Hi Philipp,
>
> Am Montag, den 10.04.2017, 11:15 +0200 schrieb Philipp Zabel:
>> Import the etnaviv header changes from kernel commits 9ad59fea162c
>> ("drm/etnaviv: submit support for in-fences") and 78ec187f64fa
>> ("drm/etnaviv: submit support for
Christian Gmeiner (1):
configure.ac: bump version for release
Eric Engestrom (1):
intel: remove dead code
Philipp Zabel (2):
etnaviv: sync uapi header
etnaviv: add fence fd support
Tobias Jakobi (1):
exynos: add C++ support to exynos_drmif header
git tag: libdrm-2.
On 17 April 2017 at 21:13, Robert Foss wrote:
> From: Sean Paul
>
> From drm_crtc.h, for use with the plane "rotation" property.
>
Please see the include/drm/README.
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedes
On 18 April 2017 at 11:32, Emil Velikov wrote:
> On 17 April 2017 at 21:13, Robert Foss wrote:
>> From: Sean Paul
>>
>> From drm_crtc.h, for use with the plane "rotation" property.
>>
> Please see the include/drm/README.
>
To elaborate a bit:
The heade
On 18 April 2017 at 16:48, Rob Clark wrote:
> On Fri, Apr 14, 2017 at 1:04 PM, Raghav Jajodia
> wrote:
>> Hi there
>>
>> I am Raghav Jajodia, an Engineering student from India. While going through
>> the X.org foundation, I felt that X.org is a great community for new Open
>> Source developers. I
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 "rotation" property.
>>
>> Signed-off-by: Sean Paul
>> Signed-off-by: Robert Foss
>> Reviewed-by: Sumit Semwal
>> ---
>
On 18 April 2017 at 20:38, Daniel Vetter wrote:
> On Tue, Apr 18, 2017 at 02:27:14PM -0400, Rob Clark wrote:
>> On Tue, Apr 18, 2017 at 1:32 PM, Emil Velikov
>> wrote:
>> > On 18 April 2017 at 16:48, Rob Clark wrote:
>> >> On Fri, Apr 14, 2017 at 1:04 PM, Ra
On 18 April 2017 at 23:16, Daniel Vetter wrote:
> On Tue, Apr 18, 2017 at 8:33 PM, Kristian Høgsberg
> wrote:
As far as I understand the property mechanism, the numeric values
aren't actually ABI. The string names of the enum values are the ABI
and you're supposed to parse the enu
Hi Gerd,
I did not have the change to follow through the discussion.
Pardon if my suggestion have already been discussed.
On 2 May 2017 at 14:34, Gerd Hoffmann wrote:
> It's unused.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Gerd Hoffmann
> ---
> include/uapi/drm/drm_fourcc.h | 2 --
Hi Ben,
On 3 May 2017 at 06:14, Ben Widawsky wrote:
> +struct drm_format_modifier_blob {
> +#define FORMAT_BLOB_CURRENT 1
> + /* Version of this blob format */
> + u32 version;
> +
> + /* Flags */
> + u32 flags;
> +
> + /* Number of fourcc formats supported */
> +
401 - 500 of 2172 matches
Mail list logo
