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
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
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 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 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 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 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 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 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
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 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
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
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 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,
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 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 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,
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,
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
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
iewed-by: Eric Anholt
Reviewed-by: Daniel Stone
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
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
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
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 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
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
;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
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
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 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
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
> + *
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 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
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 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 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 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,
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 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 Inki,
On 31 March 2016 at 08:45, Inki Dae wrote:
> 2016ë
03ì 29ì¼ 22:23ì Rob Clark ì´(ê°) ì´ ê¸:
>> On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae wrote:
>>> In addition, I wonder how explicit and implicit fences could coexist
>>> together.
>>> Rob said,
>>> "Implicit sync ofc remains
Hi Inki,
On 31 March 2016 at 11:05, Inki Dae wrote:
> 2016ë
03ì 31ì¼ 18:35ì Daniel Stone ì´(ê°) ì´ ê¸:
>> On 31 March 2016 at 08:45, Inki Dae wrote:
>>> As of now, it seems that this wouldn't be optional but mandatory if
>>> explicit fence suppo
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
nything obviously wrong, for patches 1-5:
Reviewed-by: Daniel Stone
Cheers,
Daniel
et's share the embarrassment. What could possibly go wrong?
Reviewed-by: Daniel Stone
Cheers,
Daniel
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);
> -
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) {
>>> +
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,
On 24 February 2016 at 16:01, Emil Velikov wrote:
> On 23 February 2016 at 23:56, Rob Clark wrote:
>> On Tue, Feb 23, 2016 at 6:29 PM, Emil Velikov
>> wrote:
>>> On 2 February 2016 at 23:37, Zach Reizner wrote:
The prime fd to handle ioctl was not used with rockchip before. Support
>
Hi,
On 30 December 2015 at 07:37, Meng Yi wrote:
> I have tested your patch, It seems good to me.
> But I think state->fb check is still necessary, because fb is related to crtc
> , and panel is related to connector,. When fsl,panel is not valid, it
> indicate that connector is not available, b
Hi Inki,
On 4 January 2016 at 12:57, Inki Dae wrote:
> 2015ë
12ì 24ì¼ 22:32ì Daniel Stone ì´(ê°) ì´ ê¸:
>> On 24 December 2015 at 09:10, Inki Dae wrote:
>>> +void exynos_drm_crtc_cancel_page_flip(struct drm_crtc *crtc)
>>> +{
>>> +
struct drm_device *dev, struct drm_pending_event
>> *e) {
>> assert_spin_locked(&dev->event_lock);
>>
>> + if (!e->file_priv) {
>
> I don't think this could happen before this patch as e->file_priv is
> dereferenced below, and I don't see anything in this patch that makes the
> condition possible.
>
>> + e->destroy(e);
>> + return;
>> + }
... and now here.
This looks good to me, and a good sight better than doing it in every
driver. Still drowning in stuff after three weeks off though, so the
best I can offer for the series right now is:
Acked-by: Daniel Stone
Cheers,
Daniel
Hi Inki,
On 8 January 2016 at 08:46, Inki Dae wrote:
> Changelog v3:
> - initialize only device specific things. Each page flip event object
> is created by DRM core so DRM core should release the object including
> incrementing event space.
I'm a bit confused here; we no longer call event->
Hi Inki,
On 12 January 2016 at 06:25, Inki Dae wrote:
> 2016ë
01ì 12ì¼ 04:00ì Daniel Stone ì´(ê°) ì´ ê¸:
>> On 8 January 2016 at 08:46, Inki Dae wrote:
>>> Changelog v3:
>>> - initialize only device specific things. Each page flip event object
>>>
Hi,
Jumping in after a couple of weeks where I've paged most everything
out of my brain ...
On Fri, 19 Jun 2020 at 10:43, Daniel Vetter wrote:
> On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote:
> > > The proposed patches might very well encode the wrong contract, that's
> > > all up
Hi,
On Wed, 8 Jul 2020 at 16:13, Daniel Vetter wrote:
> On Wed, Jul 8, 2020 at 4:57 PM Christian König
> wrote:
> > Could we merge this controlled by a separate config option?
> >
> > This way we could have the checks upstream without having to fix all the
> > stuff before we do this?
>
> Since
explicitly
encode the carrot of dma-fence's positive guarantees, rather than just
the stick of 'don't do this'. ;) Either way, this is:
Acked-by: Daniel Stone
> What I'm not sure about is whether the text should be more explicit in
> flat out mandating the amdkf
On Thu, 9 Jul 2020 at 09:05, Daniel Vetter wrote:
> On Thu, Jul 09, 2020 at 08:36:43AM +0100, Daniel Stone wrote:
> > On Tue, 7 Jul 2020 at 21:13, Daniel Vetter wrote:
> > > Comes up every few years, gets somewhat tedious to discuss, let's
> > > write this down
Hi,
On Wed, 15 Jul 2020 at 11:23, Bas Nieuwenhuizen
wrote:
> My concern with going in this direction was that we potentially allow
> an application to allocate a lot of kernel memory but not a lot of fds
> by creating lots of fences and then closing the fds but never
> signaling them. Is that no
Hi,
On Wed, 15 Jul 2020 at 12:05, Bas Nieuwenhuizen
wrote:
> On Wed, Jul 15, 2020 at 12:34 PM Chris Wilson
> wrote:
> > Maybe now is the time to ask: are you using sw_sync outside of
> > validation?
>
> Yes, this is used as part of the Android stack on Chrome OS (need to
> see if ChromeOS spec
Hi all,
On Wed, 15 Jul 2020 at 12:57, Daniel Vetter wrote:
> On Wed, Jul 15, 2020 at 1:47 PM Daniel Stone wrote:
> > On Wed, 15 Jul 2020 at 12:05, Bas Nieuwenhuizen
> > wrote:
> > > Yes, this is used as part of the Android stack on Chrome OS (need to
> > &
On Wed, 8 Apr 2020 at 17:24, Daniel Vetter wrote:
> Resending because last attempt failed CI and meanwhile the results are
> lost :-/
Did anything happen with this?
Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists
Hi,
On Thu, 14 May 2020 at 08:08, Daniel Vetter wrote:
> > Did anything happen with this?
>
> Nope. There's an igt now that fails with this, and I'm not sure
> whether changing the igt is the right idea or not.
>
> I'm kinda now thinking about changing this to instead document under
> which exact
On Thu, 14 May 2020 at 08:25, Daniel Vetter wrote:
> On Thu, May 14, 2020 at 9:18 AM Daniel Stone wrote:
> > On Thu, 14 May 2020 at 08:08, Daniel Vetter wrote:
> > I'd be very much in favour of putting the blocking down in the kernel
> > at least until the kernel can
Hi Alex,
On Thu, 30 Apr 2020 at 22:30, Alex Deucher wrote:
> UAPI:
> - Add amdgpu UAPI for encrypted GPU memory
> Used by: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4401
Did this ever go through uAPI review? It's been pushed to the kernel
before Mesa review was complete. Even t
te since there aren't that many of them left and it's not an
extensible structure. Maybe proper mode handling is going to require
an expanded mode structure, but today is not that day, so:
Acked-by: Daniel Stone
Cheers,
Daniel
___
dri-devel mailin
On Wed, 21 Oct 2020 at 16:58, Daniel Vetter wrote:
> On Wed, Oct 21, 2020 at 4:59 PM Ken Huang wrote:
> > It's useful in Android and other embedded devices to implement Always On
> > Display (ex. showing clock faces with less than 15% OPR on screen).
> >
> > OPR (On Pixel Ratio) is the percentag
On Wed, 21 Oct 2020 at 17:34, Daniel Vetter wrote:
> On Wed, Oct 21, 2020 at 05:11:00PM +0100, Daniel Stone wrote:
> > It makes sense to me: some modes are annotated with a 'low-power'
> > flag, tucked away behind a client cap which makes clients opt in, and
> > the
Hi,
On Sun, 1 Nov 2020 at 20:35, Simon Ser wrote:
> Daniel, does this patch look good to you?
Unsure which Daniel you meant, but I would probably instead say:
'Userspace can release blobs as soon as they do not need to refer to
them by their blob object ID. For instance, if you are using a MODE_
Hi Dmitry,
On Thu, 11 Jun 2020 at 08:54, Dmitry Osipenko wrote:
> 10.06.2020 14:30, Thierry Reding пишет:
> > From: Thierry Reding
> > As of commit 4dc55525b095 ("drm: plane: Verify that no or all planes
> > have a zpos property") a warning is emitted if there's a mix of planes
> > with and with
Hi,
On Thu, 11 Jun 2020 at 09:44, Dave Airlie wrote:
> On Thu, 11 Jun 2020 at 18:01, Chris Wilson wrote:
> > Introducing a global lockmap that cannot capture the rules correctly,
>
> Can you document the rules all drivers should be following then,
> because from here it looks to get refactored e
Hi,
On Tue, 16 Jun 2020 at 22:16, Dmitry Osipenko wrote:
> The panel's orientation could be parsed by any panel driver and then
> assigned as the connector's property in order to allow userspace/FB-core
> to decide what to do with the rotated display. Apparently upstream
> kernel supports only th
Hi,
On Fri, 26 Jun 2020 at 10:00, Pekka Paalanen wrote:
> On Thu, 25 Jun 2020 12:44:36 +0200 Daniel Vetter wrote:
> > Maybe an aside, but the guideline is for autoconfiguration:
> > - Light up everything that has connector status connected.
> > - If nothing has that status, try to light up the c
Hi,
On Wed, 1 Jul 2020 at 20:45, James Jones wrote:
> OK, I think I see what's going on. In the Xorg modesetting driver, the
> logic is basically:
>
> if (gbm_has_modifiers && DRM_CAP_ADDFB2_MODIFIERS != 0) {
>drmModeAddFB2WithModifiers(..., gbm_bo_get_modifier(bo->gbm));
> } else {
>drm
t; Reported-by: Kuninori Morimoto
> Signed-off-by: Laurent Pinchart
Reviewed-by: Daniel Stone
Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Daniel (another one!),
On Thu, 2 Apr 2020 at 08:18, Daniel Dadap wrote:
> > I primarily asked about vgaswitcheroo since you didn't mention it at all.
>
> I had actually anticipated that vga-switcheroo would likely be
> suggested, and my first draft of my initial message had a lengthy
> explana
Hi Erik,
On Mon, 6 Apr 2020 at 20:01, Erik Jensen wrote:
> > Screen scraping like that will have big problems trying to a)
> > synchronize to the display updates correctly (was the screen
> > updated, did you get old or new frame, and you have to poll rather
> > than be notified), and b) synchron
Hi,
On Fri, 3 Apr 2020 at 13:24, Pekka Paalanen wrote:
> On Fri, 03 Apr 2020 10:15:21 + Simon Ser wrote:
> > At the very least, having a clear policy for both kernel public headers and
> > user-space would help a lot. Right now it's unclear for both parties what
> > to do
> > regarding enum
Hi,
On Tue, 7 Apr 2020 at 09:23, Pekka Paalanen wrote:
> Maybe I should underline the read/write race:
>
> You do not get notified when a display server updates the screen, so
> you poll. When your poll returns a new FB id,
And that's only useful for Wayland systems. On X11, the server can
(and
Hi,
On Tue, 22 Sep 2020 at 08:44, Tomi Valkeinen wrote:
> On 21/09/2020 14:49, Pekka Paalanen wrote:
> > would it not be simplest if KMS UAPI specification defined the abstract
> > color pipeline with all the blocks that may be exposed with
> > driver-agnostic UAPI, and then just say that if a bl
On Tue, 22 Sep 2020 at 15:04, Daniel Vetter wrote:
> On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote:
> > Gentle ping. I've tried out Linus's master tree and, and like Pekka,
> > I've noticed this isn't integrated/added.
>
> Defacto the uapi we have now is that userspace needs to ignore "spurio
Hi,
On Tue, 22 Sep 2020 at 17:02, Daniel Vetter wrote:
> On Tue, Sep 22, 2020 at 4:14 PM Daniel Stone wrote:
> > I think we need a guarantee that this never happens if ALLOW_MODESET
> > is always used in blocking mode, plus in future a cap we can use to
> > detect tha
Hi,
On Tue, 22 Sep 2020 at 19:18, Daniel Vetter wrote:
> + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> + affected_crtc |= drm_crtc_mask(crtc);
> +
> + /*
> +* For commits that allow modesets drivers can add other CRTCs to the
> +* atomic
Hi,
On Fri, 25 Sep 2020 at 09:46, Daniel Vetter wrote:
> Hopefully we'll have the drm crash recorder RSN, but meanwhile
> compositors would like to know a bit better why they get an EBUSY.
Thanks a lot, this is super helpful! Both patches are:
Reviewed-by: Daniel Stone
Che
Hi Mauro,
On Tue, 25 Aug 2020 at 12:30, Mauro Carvalho Chehab
wrote:
> Sorry, but I can't agree that review is more important than to be able
> to properly indicate copyrights in a valid way at the legal systems that
> it would apply ;-)
The way to properly indicate copyright coverage is to inse
Hi,
On Tue, 1 Sep 2020 at 08:13, Daniel Vetter wrote:
> I think right thing to do is *shrug*, please use modifiers. They're meant
> to solve these kind of problems for real, adding more hacks to paper over
> userspace not using modifiers doesn't seem like a good idea.
>
> Wrt dri3, since we do cl
gt; the driver pick "safe" modifiers in case passing the full list of
> modifiers results in a black screen. Later on wlroots will call
> gbm_bo_get_modifier to figure out what modifier the driver picked.
I think those are reasonable expectations to have, even though
arguably for
Hi Luben,
On Wed, 2 Sep 2020 at 15:51, Luben Tuikov wrote:
> Of course it's true--good morning!
>
> Let me stop you right there--just read the documentation I pointed
> to you at.
>
> No!
>
> I'm sorry, that doesn't make sense.
>
> No, that's horrible.
>
> No, that's horrible.
>
> You need to und
Hi Luben,
On Wed, 2 Sep 2020 at 16:16, Luben Tuikov wrote:
> Not sure how I can do this when someone doesn't want to read up on
> the kref infrastructure. Can you help?
>
> When someone starts off with "My understanding of ..." (as in the OP) you
> know you're
> in trouble and in for a rough tim
Hi,
On Fri, 14 Aug 2020 at 17:22, Thierry Reding wrote:
> I suspect that the reason why this works in X but not in Wayland is
> because X passes the right usage flags, whereas Weston may not. But I'll
> have to investigate more in order to be sure.
Weston allocates its own buffers for displaying
Hi,
On Thu, 14 May 2020 at 14:36, Alex Deucher wrote:
> On Thu, May 14, 2020 at 5:42 AM Daniel Stone wrote:
> > Did this ever go through uAPI review? It's been pushed to the kernel
> > before Mesa review was complete. Even then, Mesa only uses it when
> > behind a
Hi Alex,
On Fri, 29 May 2020 at 14:29, Alex Deucher wrote:
> On Fri, May 29, 2020 at 4:59 AM Simon Ser wrote:
> > OK. In this case I think it's fine to make the DMA-BUF import fail, as
> > we've suggested on IRC. The more-or-less planned fix for these buffer
> > sharing issues is to revive the b
On Fri, 29 May 2020 at 15:29, Alex Deucher wrote:
> Maybe I'm over thinking this. I just don't want to get into a
> situation where we go through a lot of effort to add modifier support
> and then performance ends up being worse than it is today in a lot of
> cases.
I'm genuinely curious: what d
On Fri, 29 May 2020 at 15:36, Alex Deucher wrote:
> On Fri, May 29, 2020 at 10:32 AM Daniel Stone wrote:
> > On Fri, 29 May 2020 at 15:29, Alex Deucher wrote:
> > > Maybe I'm over thinking this. I just don't want to get into a
> > > situation where we go th
Hi Alex,
On Mon, 1 Jun 2020 at 15:25, Alex Deucher wrote:
> On Fri, May 29, 2020 at 11:03 AM Daniel Stone wrote:
> > What Weston _does_ know, however, is that display controller can work
> > with modifier set A, and the GPU can work with modifier set B, and if
> > the clie
On Wed, 3 Jun 2020 at 19:53, Marek Olšák wrote:
> TMZ is more complicated. If there is a TMZ buffer used by a command buffer,
> then all other used buffers must also be TMZ or read only. If no TMZ buffers
> are used by a command buffer, then TMZ is disabled. If a context is not
> secure, TMZ is
Hi,
On Monday, May 11, 2015, Daniel Vetter wrote:
> On Sat, May 09, 2015 at 03:52:13PM +0100, Daniel Stone wrote:
> > Add an ioctl which allows users to create blob properties from supplied
> > data. Currently this only supports modes, creating a drm_display_mode
> from
Hi,
On Monday, May 11, 2015, Daniel Vetter wrote:
> On Sat, May 09, 2015 at 03:52:10PM +0100, Daniel Stone wrote:
> > 672cb1d6ae mistakenly added an extra parameter to the kerneldoc for
> > drm_property_unreference_blob which wasn't actually present.
> >
>
Hi Paul,
> On 12 May 2015, at 5:00 am, Paul Walmsley wrote:
>
> Hi folks
>
> Tegra124 Jetson TK1 hangs during boot in next-20150508 and beyond:
>
> http://nvt.pwsan.com/experimental/linux-next/testlogs/test_next-20150508/20150508101018/boot/tegra124-jetson-tk1/tegra124-jetson-tk1/tegra_defconf
Hi Paul,
On 12 May 2015 at 05:00, Paul Walmsley wrote:
> Tegra124 Jetson TK1 hangs during boot in next-20150508 and beyond:
>
> http://nvt.pwsan.com/experimental/linux-next/testlogs/test_next-20150508/20150508101018/boot/tegra124-jetson-tk1/tegra124-jetson-tk1/tegra_defconfig_log.txt
> http://nvt
201 - 300 of 753 matches
Mail list logo
