The IN_FORMATS blob allows the kernel to advertise to userspace which
format/modifier combinations are supported, per plane. Use this to
advertise that we support both T_TILED and linear.
Signed-off-by: Daniel Stone
---
drivers/gpu/drm/vc4/vc4_plane.c | 22 +-
1 file changed
Hi,
On 1 August 2017 at 17:58, Ben Widawsky wrote:
> @@ -1240,6 +1253,19 @@ intel_sprite_plane_create(struct drm_i915_private
> *dev_priv,
> plane_formats = skl_plane_formats;
> num_plane_formats = ARRAY_SIZE(skl_plane_formats);
> modifiers = skl_p
Hi,
On 26 July 2017 at 19:07, Ben Widawsky wrote:
> Due to hardware limitations we require that the main surface and
> the AUX surface (CCS) be part of the same bo. The hardware also
> makes life hard by not allowing you to provide separate x/y offsets
> for the main and AUX surfaces (excpet with
Hi Ben,
On 26 July 2017 at 19:07, Ben Widawsky wrote:
> v2: Drop the 'dev' argument from the hook
> v3: Include the description of the CCS surface layout
This went missing. Vidya's patch has it though.
> +static const struct drm_format_info ccs_formats[] = {
> + { .format = DRM_FO
Hi Ben,
On 26 July 2017 at 19:08, Ben Widawsky wrote:
> +static bool intel_primary_plane_format_mod_supported(struct drm_plane *plane,
> +uint32_t format,
> +uint64_t modifier)
> +{
> + s
Hi,
On 26 July 2017 at 19:08, Ben Widawsky wrote:
> +static const uint64_t skl_plane_format_modifiers_noccs[] = {
> + I915_FORMAT_MOD_Yf_TILED,
> + I915_FORMAT_MOD_Y_TILED,
> + I915_FORMAT_MOD_X_TILED,
> + DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID
> +};
> +
>
Hi Ben,
On 26 July 2017 at 19:08, Ben Widawsky wrote:
> + } else if (INTEL_GEN(dev_priv) >= 9) {
> intel_primary_formats = skl_primary_formats;
> num_formats = ARRAY_SIZE(skl_primary_formats);
> - modifiers = skl_format_modifiers;
> +
Hi Matt,
On 17 July 2017 at 20:39, Matt Hoosier wrote:
> Also beware that the DRM backend of Weston will aggressively set the mode
> before you have any chance to paint user-defined content of your own in a
> Wayland client program. So there will still be some window of time during
> which your e
On 21 June 2017 at 18:23, Eric Anholt wrote:
> Taken from make headers_install of drm-misc-next
> (34c8ea400ff6383b028f63df2453914163afc07c)
Oh! I'd somehow totally missed the kernel modifier support. Pushed with review.
Cheers,
Daniel
___
dri-devel ma
On 13 June 2017 at 16:49, Eric Anholt wrote:
> Daniel Stone writes:
>> I posted a DRI3 v1.1 patch series which can advertise and also transit
>> modifiers directly under X11, and have also typed up the support for
>> Wayland which is working just fine with Weston from git
Hi Eric,
On 8 June 2017 at 01:13, Eric Anholt wrote:
> This allows mesa to set the tiling format for a BO and have that
> tiling format be respected by mesa on the other side of an
> import/export (and by vc4 scanout in the kernel), without defining a
> protocol to pass the tiling through userspa
Hi Ben,
On 16 May 2017 at 22:31, Ben Widawsky wrote:
> Updated blob layout (Rob, Daniel, Kristian, xerpi)
If you take the attached fixup, this is:
Reviewed-by: Daniel Stone
The rest of the series looks fine to me, so you can take my Acked-by,
but I'm currently off work sick and am a
n't accept the FB modifiers. So this gets my:
Acked-by: Daniel Stone
And a future revision with the fixups found here would get my R-b.
Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi,
On 4 May 2017 at 09:59, Lucas Stach wrote:
> Am Mittwoch, den 03.05.2017, 18:15 +0100 schrieb Daniel Stone:
>> What about planes which aren't present in this commit, but are still
>> taking up a PRE unit? Will they have their PRE stolen, or am I missing
>> somethin
Hi Lucas,
On 3 May 2017 at 17:28, Lucas Stach wrote:
> int available_pres = ipu_prg_max_active_channels();
> int i;
>
> + /*
> +* We are going over the planes in 2 passes: first we assign PREs to
> +* planes with a tiling modifier, which need the PREs to reso
On 3 May 2017 at 15:07, Liviu Dudau wrote:
> On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel Stone wrote:
>> On 3 May 2017 at 11:34, Liviu Dudau wrote:
>> > You are *really* pushing your luck by not Cc-ing *any* of the maintainers
>> > of
>> > the drivers y
Hi Brian,
On 3 May 2017 at 15:03, Brian Starkey wrote:
> On Wed, May 03, 2017 at 02:51:18PM +0100, Daniel Stone wrote:
>> formats_offset is the end of the fixed-size element, which is
>> currently aligned to 32 bytes, and practically speaking would always
>> have to be anyw
Hi Brian,
On 3 May 2017 at 13:51, Brian Starkey wrote:
> On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
>> + modifiers_size =
>> + sizeof(struct drm_format_modifier) *
>> format_modifier_count;
>> +
>> + blob_size = ALIGN(sizeof(struct drm_format_modifier_
Hi Liviu,
On 3 May 2017 at 11:34, Liviu Dudau wrote:
> On Tue, May 02, 2017 at 10:14:26PM -0700, Ben Widawsky wrote:
>> v2: A minor addition from Daniel
>
> You are *really* pushing your luck by not Cc-ing *any* of the maintainers of
> the drivers you touch. You do want reviews, don't you?
Ouch.
Hi Brian,
On 3 May 2017 at 12:00, Brian Starkey wrote:
> Having just caught up on IRC I'm sure I'm far too late for this party,
> but...
>
> Wouldn't this whole thing be a whole lot simpler if "IN_FORMATS"
> stored "pointers" to separate blobs for the format and modifier lists?
>
> I've used/writ
Hi,
On 2 May 2017 at 09:10, Daniel Vetter wrote:
> On Fri, Apr 21, 2017 at 03:41:10PM -0300, Gustavo Padovan wrote:
>> Do you know which hw would that be? I don't know. Maybe we should just
>> don't care for now and see how drivers will solve this to then extract
>> helpers like we did for atomic
Hi Eric,
On 25 April 2017 at 20:33, Eric Anholt wrote:
> Signed-off-by: Eric Anholt
Both are:
Reviewed-by: Daniel Stone
Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/
Hi,
On 24 April 2017 at 15:26, Ville Syrjälä wrote:
> On Mon, Apr 24, 2017 at 04:54:25PM +0900, Michel Dänzer wrote:
>> On 24/04/17 04:36 PM, Gerd Hoffmann wrote:
>> > When running in opengl mode there will be a hardware-specific mesa
>> > driver in userspace, which will either know what the gpu
Hi,
On 11 April 2017 at 07:48, Daniel Vetter wrote:
> Note: As Daniel Stone mentioned in the announcement fd.o admins
> started chatting with the communities their hosting, which includs the
> X.org foundation board, to figure out how to fan out enforcement and
> allow projects to r
Reviewed-by: Daniel Stone
[mobile email formatting apology here]
On Fri, 7 Apr 2017 at 5:48 pm, Daniel Vetter wrote:
> I thought I've fixed this, but maybe not. Anyway, clearly broken, and
> easy fix.
>
> Cc: Tony Lindgren
> Reported-by: Tony Lindgren
> Fixes: b95
.
Cheers,
Daniel
Ander Conselvan de Oliveira (1):
Add CRTC ID to vblank event
Daniel Stone (2):
Headers: Sync drm{,_mode}.h with the kernel
configure.ac: bump version for release
Emil Velikov (1):
configure.ac: pthread-stubs is not a thing on GNU/kFreeBSD
Eric Engestrom (4
]
v2: Split into separate commit.
Signed-off-by: Ander Conselvan de Oliveira
Signed-off-by: Daniel Stone
Cc: Maarten Lankhorst
---
xf86drm.h | 9 -
xf86drmMode.c | 24
2 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/xf86drm.h b/xf86drm.h
the 'reserved'
field from vblank events to include the CRTC ID.
v2: Split into separate patch, pull in full kernel changes.
v3: Undo revert of connector-type enums, since it is not actually
harmful.
Signed-off-by: Daniel Stone
---
include/drm/drm.h | 3 ++-
include/drm/drm_m
Hi,
On 4 April 2017 at 18:58, Sean Paul wrote:
> On Tue, Apr 04, 2017 at 05:52:21PM +0100, Daniel Stone wrote:
>> With the atomic API, it is possible that a single commit affects
>> multiple crtcs. If the user requests an event with that commit, one
>> event will be sent for
the 'reserved'
field from vblank events to include the CRTC ID.
The define -> enum conversion from
dee7a4fee730ca8908f335b6b66174cba4598ecd was manually reverted from this
sync, to avoid any potential ABI issues.
Signed-off-by: Daniel Stone
---
include/drm/drm.h | 3 ++-
ssage.]
Signed-off-by: Ander Conselvan de Oliveira
Signed-off-by: Daniel Stone
Cc: Maarten Lankhorst
---
xf86drm.h | 9 -
xf86drmMode.c | 24
2 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/xf86drm.h b/xf86drm.h
index 0d927018..d75ca8ce 100644
Hi Emil,
On Tue, 2017-04-04 at 18:12 +0100, Emil Velikov wrote:
> On 4 April 2017 at 17:52, Daniel Stone wrote:
> > @@ -846,7 +847,7 @@ struct drm_event_vblank {
> > __u32 tv_sec;
> > __u32 tv_usec;
> > __u32 sequence;
> > - __u32 re
ssage.]
Signed-off-by: Ander Conselvan de Oliveira
Signed-off-by: Daniel Stone
Cc: Maarten Lankhorst
---
include/drm/drm.h | 3 ++-
xf86drm.h | 9 -
xf86drmMode.c | 24
3 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/include/drm/dr
elvan de Oliveira
Signed-off-by: Daniel Stone
Cc: Maarten Lankhorst
---
drivers/gpu/drm/drm_ioctl.c | 3 +++
drivers/gpu/drm/drm_irq.c | 2 ++
include/uapi/drm/drm.h | 3 ++-
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gp
Hi,
Following the annual tradition, I've rebased Ander/Maarten's patches
to include the CRTC ID in vblank events. Specifically, this makes it
possible to know which CRTC an atomic request-completion event refers
to.
I'm using this in Weston, for which I can ack it as good API, and a
second opinion
Hi,
On 4 April 2017 at 12:15, Christian König wrote:
> Am 04.04.2017 um 12:43 schrieb Daniel Stone:
>> Yeah, the ABI is that AddFB2 should fail hard on something which can
>> never be used as a framebuffer. The fact it didn't is a bug rather
>> than a behavioural change
Hi,
On 4 April 2017 at 11:27, Christopher James Halse Rogers
wrote:
> On 4 April 2017 6:31:12 pm AEST, Daniel Vetter wrote:
>>This seems like an awful specific special case. Why can't you do the
>>entire dance upfront, i.e. import buffer, addfb2? None of that has any
>>visible effect, and it wil
Hi,
On 4 April 2017 at 09:31, Daniel Vetter wrote:
> On Tue, Apr 04, 2017 at 06:13:20PM +1000, r...@ubuntu.com wrote:
>> Until recently, on (at least) nouveau, radeon, and amdgpu attempting to
>> scanout of an
>> imported dma-buf would silently result in the dma-buf sharing being broken.
>>
>> W
Hi,
On 1 April 2017 at 19:47, Rob Clark wrote:
> On Tue, Dec 20, 2016 at 7:12 PM, Kristian H. Kristensen
> wrote:
>> This new ioctl exctends DRM_IOCTL_MODE_GETPLANE, by returning
>> information about the modifiers that will work with each format.
>
> So, just to toss out a completely different i
Hi,
On 24 March 2017 at 17:51, Eric Anholt wrote:
> Dylan Baker writes:
>> I also think it's worth talking to Eric (who said he's porting X to meson),
>> Daniel Stone (who has patches to port weston to meson), and Peter Hutterer
>> (who
>> has patches t
Hi Jose,
On 24 March 2017 at 14:03, Jose Fonseca wrote:
> On 22/03/17 20:57, Dylan Baker wrote:
>> Cross compiling for mingw is supported, and it provides a way to
>> differentiate
>> the build, host, and target machines [1], I've cross compiled for
>> aarch64-linux-gnu, and it was trivial (I've
;t something they are interested in doing.
With a rebase of Ben's GBM branch[0], and my last Weston atomic
series, for Y_CCS this series is:
Tested-by: Daniel Stone
I had to disable Yf_CCS due to complaints about the kernel's idea of
the tiling mode not matching the modifier. Not sure
date the DRM_DEBUG output to be slightly more accurate, this
> doesn't only affect requests from userspace.
This test looks much more sensible, and also fixes VT switching for me.
Reviewed-by: Daniel Stone
Cheers,
Daniel
___
dri-de
Hi,
On 16 March 2017 at 09:55, Michel Dänzer wrote:
> Otherwise this can also prevent modesets e.g. for switching VTs.
>
> FB_MISC_USER_EVENT is set when the request originates from userspace,
> which is what we're interested in here according to the DRM_DEBUG
> output.
>
> Bugzilla: https://bugs
in the remote URL, you can modify ~/.ssh/config:
$ printf '\nHost git.freedesktop.org\n\tUser ' >> ~/.ssh/config
with that, it's:
Reviewed-by: Daniel Stone
Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi,
On 17 February 2017 at 14:56, Ville Syrjälä
wrote:
> On Fri, Feb 17, 2017 at 02:42:26PM +, Lionel Landwerlin wrote:
>> If we're talking fixed point reprsentation, ChromeOS is using this :
>>
>> https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc?q=DrmDevice&l=209
Hi,
On 15 February 2017 at 11:39, Ville Syrjälä
wrote:
> On Tue, Jan 31, 2017 at 06:46:39PM +0100, Daniel Vetter wrote:
>> On Tue, Jan 31, 2017 at 6:22 PM, Ville Syrjälä
>> wrote:
>> > Hmm. Two's complement is what I was thinking it is. Which shows that
>> > I never managed to read the code in a
Hi John,
On 14 February 2017 at 19:25, John Stultz wrote:
> +static enum drm_mode_status
> +drm_connector_check_crtc_modes(struct drm_connector *connector,
> + struct drm_display_mode *mode)
> +{
> + struct drm_device *dev = connector->dev;
> + const struc
Hi Maxime,
On 13 February 2017 at 10:54, Maxime Ripard
wrote:
> On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote:
>> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote:
>> > This patch add a config to support to create multi buffer for cma fbdev.
>> > Such as double buffer and t
Hi,
On 9 February 2017 at 17:01, Daniel Vetter wrote:
> On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote:
>> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned
>> long arg)
>> +{
>> + struct drm_fb_helper *fb_helper = info->par;
>> + struct drm_device
Hi,
On 6 February 2017 at 17:59, Daniel Vetter wrote:
> On Mon, Feb 06, 2017 at 10:39:28AM -0700, Jordan Crouse wrote:
>> This initial series implements 4 ringbuffers to give sufficient coverage for
>> the
>> range of priority levels requested by the GLES and compute extensions. The
>> targeted
Hi Satendra,
On 20 January 2017 at 08:12, Satendra Singh Thakur
wrote:
> -Added a new ioctl in Linux DRM KMS driver.
> This ioctl allows user to set the values of an object’s multiple
> properties in one go.
> -In the absence of such ioctl, User would be calling one ioctl to set each
> propert
Hi Dan,
On 13 January 2017 at 12:56, Dan Carpenter wrote:
> drivers/gpu/drm/drm_crtc.c:392 drm_mode_getcrtc()
> error: we previously assumed 'crtc->primary->state' could be null
> (see line 384)
>
> drivers/gpu/drm/drm_crtc.c
>383
>384 if (crtc->primary->state && crtc->
Hey,
On 13 January 2017 at 09:37, Ville Syrjälä
wrote:
> On Thu, Jan 12, 2017 at 07:27:03PM +0000, Daniel Stone wrote:
>> It would make sense, but then gbm_surface_create_with_modifiers takes
>> a fixed pixel format and a list of acceptable modifiers (which to me
>> see
Hi,
On 12 January 2017 at 18:11, Ville Syrjälä
wrote:
> On Thu, Jan 12, 2017 at 05:50:15PM +0000, Daniel Stone wrote:
>> struct drm_plane {
>> struct {
>> uint32_t format;
>> uint64_t modifiers[];
>> } formats[];
>> }
>
> Flipp
Hi,
On 12 January 2017 at 17:45, Ville Syrjälä
wrote:
> On Thu, Jan 12, 2017 at 05:04:46PM +0000, Daniel Stone wrote:
>> Implicit is clever but horrible. AFAICT, the only way to do it
>> properly would be to have a nested forwards loop walk when you first
>> hit a modifier,
Hi,
On 12 January 2017 at 14:56, Rob Clark wrote:
> On Thu, Jan 12, 2017 at 4:38 AM, Ville Syrjälä
> wrote:
>> Isn't an implicit offset enough? As in first mask for a specific
>> modifier is for format indexes 0-63, second mask for the same modifier
>> is for 64-127, and so on.
>
> hmm, hadn't t
Hi,
On 5 January 2017 at 08:52, Daniel Vetter wrote:
> On Thu, Jan 05, 2017 at 10:41:07AM +0200, Jani Nikula wrote:
>> No matter what we do here, the question remains what to do with
>> Chamelium. Changing the color range is really a workaround for
>> Chamelium, not a fix. Using CEA range is perf
Hi Randy,
On 4 January 2017 at 16:29, Randy Li wrote:
> index 90d2cc8..23c8e99 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_UYVY,
Hi Christian,
On 4 January 2017 at 16:02, Christian König wrote:
> Am 04.01.2017 um 16:47 schrieb Rob Clark:
>> If the position of the different parts of the buffer are somewhere
>> required to be a function of w/h/bpp/etc then I'm not sure if there is
>> a strong advantage to treating them as s
Hi Marek,
On 3 January 2017 at 23:38, Marek Olšák wrote:
> I've been thinking about it, and it looks like we're gonna continue
> using immutable per-BO metadata (buffer layout, tiling description,
> compression flags). The reasons are that everything else is less
> economical, and the current "
Hi Randy,
On 2 January 2017 at 09:50, Randy Li wrote:
> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
> per channel video format. Rockchip's vop support this
> video format(little endian only) as the input video format.
>
> Signed-off-by: Randy Li
> ---
> include/uapi/drm/drm_fo
Hi all,
On 2 January 2017 at 13:03, ayaka wrote:
> On 01/02/2017 07:07 PM, Sakari Ailus wrote:
>> On Mon, Jan 02, 2017 at 06:53:16PM +0800, ayaka wrote:
>>> On 01/02/2017 05:10 PM, Sakari Ailus wrote:
If the format resembles the existing formats but on a different bit
depth,
it sho
loc() and
> drm_dev_register() explicitly.
>
> For consistency inline the .unload() handler in the remove function as
> well.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Sean Paul
> Reviewed-by: Daniel Vetter
> Reviewed-by: Daniel Stone
> ---
> Changes sin
hought about cleaning this up, but my XU3's eMMC is dead, so testing
on Exynos for me has a 5+ minute RTT through LAVA ... so this is:
Reviewed-by: Daniel Stone
Cheers,
Daniel
On 13 December 2016 at 23:08, Daniel Vetter wrote:
> This is single-threaded setup code, no need for locks. And anyway,
> all properties need to be set up before the driver is registered
> anyway, they can't be hot-added.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Daniel Stone
Hi,
> On 13 Dec 2016, at 6:48 pm, Ville Syrjälä linux.intel.com> wrote:
>
>> On Tue, Dec 13, 2016 at 06:19:12PM +0000, Daniel Stone wrote:
>> @@ -357,7 +357,10 @@ int drm_mode_getcrtc(struct drm_device *dev,
>>
>>drm_modeset_lock_crtc(crtc, crtc->p
If atomic state is available, use this to read the current plane in
GetCrtc/GetPlane, rather than the legacy points.
Signed-off-by: Daniel Stone
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 5 -
drivers/gpu/drm/drm_plane.c | 8 ++--
2 files changed, 10 insertions(+), 3 deletions
Hi Harry,
I've been loathe to jump in here, not least because both cop roles
seem to be taken, but ...
On 13 December 2016 at 01:49, Harry Wentland wrote:
> On 2016-12-11 09:57 PM, Dave Airlie wrote:
>> On 8 December 2016 at 12:02, Harry Wentland
>> wrote:
>> Sharing code is a laudable goal and
Hi Stephen,
On 1 December 2016 at 20:45, Stephen Rothwell wrote:
> On Thu, 01 Dec 2016 11:02:26 +0000 Daniel Stone
> wrote:
>> Sorry about this, it is quite bad. I think having mirrors for the key DRM
>> trees on GitHub is a good idea though, and I can get to setting that u
Hi guys,
On Nov 30 2016, at 10:49 pm, Rob Clark wrote:
> yeah, {cgit,anongit}.fd.o have been having problems all day.. (the ssh
git urls for folks who have push access work fine).. although it has
worked for me a couple times today, given enough time.
>
> (not sure if we have github/
iewed-by: Eric Anholt
Reviewed-by: Daniel Stone
ifier too isn't any increase in complexity. It does
affect advertisement and negotiation though. I'll prepare some
clarifying wording for the EGL spec, to clarify that the modifier must
be equal for all planes.
Acked-by: Daniel Stone
Cheers,
Daniel
On 30 September 2016 at 11:55, Daniel Stone wrote:
> Hi,
>
> [...]
... and with that, Reviewed-by: Daniel Stone
Cheers,
Daniel, off to find more coffee
Hi,
On 29 September 2016 at 16:20, Daniel Vetter wrote:
> + * 1. Driver commits new hardware state into vblank-synchronized registes.
> + * 2. A vblank happes, committing the hardware state. Also the corresponding
> + *vblank interrupt is fired off and fully processed by the interrupt
> + *
Hi,
On 22 August 2016 at 16:23, Rob Clark wrote:
> I guess a lot comes down to 'how long before hw designers bolt a CP to
> the thing'.. at that point, I think you especially don't want a
> per-blit kernel interface.
Regardless of whether or not we want it, we already _have_ it, in the
form of
On 17 August 2016 at 11:17, Daniel Vetter wrote:
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index d5ad60d3cf06..6544c74d250a 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -389,6 +389,15 @@ connector and plane objects by
Hi Tomeu,
On 22 July 2016 at 15:10, Tomeu Vizoso wrote:
> +/**
> + * DOC: CRC ABI
> + *
> + * DRM device drivers can provide to userspace CRC information of each frame
> as
> + * it reached a given hardware component (a "source").
> + *
> + * Userspace can control generation of CRCs in a given C
On 4 August 2016 at 11:01, Michel Dänzer wrote:
> On 04.08.2016 18:51, Daniel Stone wrote:
>> On 4 August 2016 at 04:39, Michel Dänzer wrote:
>>> Patch 6 extends the ioctl with new flags, which allow userspace to
>>> explicitly specify the target vblank seqno. T
Hi,
On 4 August 2016 at 08:50, Daniel Vetter wrote:
> One problem with 2d blitters is that there's no common userspace
> interface, but many: Xrender, hwc, old X drawing api, various attempts by
> khronos to standardize something, cairo, ... It's probably worse than
> video decoding even, and def
Hi,
On 4 August 2016 at 04:39, Michel Dänzer wrote:
> Patch 6 extends the ioctl with new flags, which allow userspace to
> explicitly specify the target vblank seqno. This can also avoid delaying
> flips in some cases where we are already in the target vertical blank
> period when the ioctl is c
Hi Rainer,
On 24 June 2016 at 05:54, Rainer Hochecker wrote:
> I spent some time reading and investigating on this. Bear with me, I am
> doing Kodi development in my spare time and may not be up-to-date on all
> platforms. Seems Wayland is much better suited to serve as reference
> platform as X1
Hi,
On 21 June 2016 at 14:57, Rainer Hochecker wrote:
> Are you saying that this is outdated:
> https://wayland.freedesktop.org/faq.html#heading_toc_j_12
>
> A more subtle point is that libGL.so includes the GLX symbols, so linking to
> that library will pull in all the X dependencies. This means
Hi,
On 21 June 2016 at 04:24, Rainer Hochecker wrote:
> Thanks a lot.
> Would you know if/when Wayland will support OpenGL?
Er, it always has ... ?
It will never support GLX (as the name implies, that's X-specific),
but EGL is perfectly capable of creating OpenGL contexts. It works
fine.
Cheer
Hi Rainer,
On 17 June 2016 at 22:00, Rainer Hochecker wrote:
> I agree. GLX_OML_sync_control fulfils all our requirements apart from being
> available for EGL. It would be great to have it available for EGL. In regard
> to Wayland this is really important. For the time being Kodi stopped
> suppor
k_busy returns outdated information.
>
> v4: Hold dev->event_lock while checking the VOP's event field as
> suggested by Daniel Stone.
>
> v5: Only block if there's outstanding work if it's a blocking call.
>
> Signed-off-by: Tomeu Vizoso
Reviewed-by: Daniel Stone
Cheers,
Daniel
Hi Tomeu,
On 5 April 2016 at 16:07, Tomeu Vizoso wrote:
> On 4 April 2016 at 17:44, Daniel Stone wrote:
>> On 4 April 2016 at 14:55, Tomeu Vizoso wrote:
>>> + if (async) {
>>> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
>>> +
Hi Andrzej,
On 24 March 2016 at 10:52, Andrzej Hajda wrote:
> @@ -229,24 +229,12 @@ void exynos_drm_crtc_cancel_page_flip(struct drm_crtc
> *crtc,
> struct drm_file *file)
> {
> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> -
et's share the embarrassment. What could possibly go wrong?
Reviewed-by: Daniel Stone
Cheers,
Daniel
nything obviously wrong, for patches 1-5:
Reviewed-by: Daniel Stone
Cheers,
Daniel
Hi,
On 28 April 2016 at 23:28, Rob Clark wrote:
> On Wed, Apr 27, 2016 at 2:39 AM, Daniel Vetter wrote:
>> On Tue, Apr 26, 2016 at 01:48:02PM -0700, Greg Hackmann wrote:
>>> A (per-CRTC?) array of fences would be more flexible. And even in the cases
>>> where you could make a 1-to-1 mapping bet
Hi,
On 26 April 2016 at 00:33, Gustavo Padovan wrote:
> +static inline struct drm_crtc *fence_to_crtc(struct fence *fence)
> +{
> + if (fence->ops != &drm_crtc_fence_ops)
> + return NULL;
Since this is (currently) only used before unconditional dereferences,
maybe turn this i
Hi,
On 27 April 2016 at 03:03, Dave Airlie wrote:
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 9d5e3c8..d899dac 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1179,6 +1179,15 @@ drm_atomic_set_crtc_for_connector(struct
Hi,
On 27 April 2016 at 03:03, Dave Airlie wrote:
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 9d5e3c8..d899dac 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1179,6 +1179,15 @@ drm_atomic_set_crtc_for_connector(struct
Hi,
On 27 April 2016 at 03:03, Dave Airlie wrote:
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> b/drivers/gpu/drm/drm_crtc_helper.c
> index 66ca313..29b7835 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -456,6 +456,9 @@ drm_crtc_helper_disab
Hi,
On 26 April 2016 at 21:48, Greg Hackmann wrote:
> On 04/26/2016 01:05 PM, Daniel Vetter wrote:
>> On Tue, Apr 26, 2016 at 09:55:06PM +0300, Ville Syrjälä wrote:
>>> What are they doing that can't stuff the fences into an array
>>> instead of props?
>>
>> The hw composer interface is one in-
Hi,
On 5 April 2016 at 15:04, Rob Clark wrote:
> On Tue, Apr 5, 2016 at 8:57 AM, Daniel Stone wrote:
>> I've been assuming that it would have to be write-only; I don't
>> believe there would be any meaningful usecases for read. Do you have
>> any in mind, or is
Hi,
On 5 April 2016 at 13:36, Rob Clark wrote:
> ok, so I've been slacking on writing up the reasons that I don't like
> the idea of using a property for fd's (including fence fd's).. I did
> at one point assume we'd use properties for fence fd's, but that idea
> falls apart pretty quickly when y
Hi Tomeu,
On 4 April 2016 at 14:55, Tomeu Vizoso wrote:
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index 3b8f652698f8..8305bbd2a4d7 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_
Hi Inki,
On 31 March 2016 at 12:26, Inki Dae wrote:
> 2016-03-31 19:56 GMT+09:00 Daniel Stone :
>> On 31 March 2016 at 11:05, Inki Dae wrote:
>>> Then, existing drivers would need additional works for explicit fencing
>>> support. This wouldn't be really what t
401 - 500 of 753 matches
Mail list logo
