Hi,
On 3 May 2018 at 20:12, Sean Paul wrote:
> On Thu, May 03, 2018 at 08:30:18PM +0200, Daniel Vetter wrote:
>> On Thu, May 3, 2018 at 5:04 PM, Sean Paul wrote:
>> > If you're still reading, I'll point out a couple other things:
>> > - There is a bug tracker on the gitlab instance, feel free to
On 30 March 2018 at 15:11, Daniel Stone wrote:
> Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we
> can remove it.
>
> Signed-off-by: Daniel Stone
> Cc: Sandy Huang
> Cc: Heiko Stübner
Ping?
Cheers,
Daniel
___
Hi Thierry,
On 30 March 2018 at 15:11, Daniel Stone wrote:
> Since tegra_fb is now the same as drm_framebuffer, we can just replace
> the type completely.
>
> Signed-off-by: Daniel Stone
> Cc: Thierry Reding
> Cc: linux-te...@vger.kernel.org
Did this still need some more te
Hi Rob,
On 30 March 2018 at 15:11, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle function the same as the GEM framebuffer helper, we
> can reuse that.
On 30 March 2018 at 21:53, Sebastian Reichel
wrote:
> On Fri, Mar 30, 2018 at 03:11:21PM +0100, Daniel Stone wrote:
>> drm_framebuffer already holds per-plane pitch and offsets, which is
>> filled out for us when we create the framebuffer. Nuke our local copy in
>> the plane
Hi CK, Philipp,
On 30 March 2018 at 15:11, Daniel Stone wrote:
> Now that mtk_drm_fb is an empty wrapper around drm_framebuffer, we can
> just delete it.
Did you get a chance to look at these three patches for Mediatek?
Cheers,
Daniel
___
dri
Hi Russell,
On 30 March 2018 at 15:11, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper,
Hi Ville,
On 23 March 2018 at 14:49, Daniel Stone wrote:
> On 23 March 2018 at 14:42, Ville Syrjälä
> wrote:
>> Hmm. I'm thinking we can stick to the single reference per fb.
>> IIRC this counter is there just to prevent changes of the obj
>> tiling mode as long a
Hi Heiko,
On 17 May 2018 at 14:42, Heiko Stübner wrote:
> Am Donnerstag, 17. Mai 2018, 15:08:15 CEST schrieb Daniel Stone:
>> On 30 March 2018 at 15:11, Daniel Stone wrote:
>> > Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we
>> > can remove
On 17 May 2018 at 16:26, Russell King - ARM Linux wrote:
> On Thu, May 17, 2018 at 02:15:40PM +0100, Daniel Stone wrote:
>> On 30 March 2018 at 15:11, Daniel Stone wrote:
>> > Since drm_framebuffer can now store GEM objects directly, place them
>> > there rather than i
We cannot create a framebuffer with no objects, so there's no point
testing for it.
v2: Remove the error entirely. (Sean, CK, Thierry)
Signed-off-by: Daniel Stone
Cc: Sean Paul
Cc: Thierry Reding
Cc: CK Hu
Cc: Philipp Zabel
---
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 5 -
1
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone
Reviewed-by: CK Hu
Reviewed-by
Now that mtk_drm_fb is an empty wrapper around drm_framebuffer, we can
just delete it.
Signed-off-by: Daniel Stone
Reviewed-by: CK Hu
Reviewed-by: Thierry Reding
Reviewed-by: Sean Paul
Cc: Philipp Zabel
---
drivers/gpu/drm/mediatek/mtk_drm_fb.c | 40 ++-
1 file
On Fri, 9 Nov 2018 at 19:13, Eric Engestrom wrote:
> Error message was invalid too, negative values aren't the number of
> devices, they're errno error codes.
>
> Signed-off-by: Eric Engestrom
Reviewed-by: Daniel Stone
___
dri-
On Wed, 22 Aug 2018 at 11:51, Daniel Vetter wrote:
> +See the gitlab project owners for contact details of the libdrm maintainers.
Think this should be 'See MAINTAINERS' ... ?
The rest looks good to me, though I would encourage linking to
Patchwork so people can find patches from others, as well
Hi,
On Wed, 22 Aug 2018 at 16:02, Emil Velikov wrote:
> On 22 August 2018 at 12:44, Daniel Vetter wrote:
> > I think it's time to brainstorm a bit about the gitlab migration. Basic
> > reasons:
> >
> > - fd.o admins want to deprecate shell accounts and hand-rolled
> > infrastructure, because i
Hi,
On Wed, 22 Aug 2018 at 15:44, Daniel Vetter wrote:
> On Wed, Aug 22, 2018 at 3:13 PM, Jani Nikula
> wrote:
> > Just a couple of concerns from drm/i915 perspective for starters:
> >
> > - Patchwork integration. I think we'll want to keep patchwork for at
> > least intel-gfx etc. for the ti
Hi Rodrigo,
On Wed, 22 Aug 2018 at 17:06, Rodrigo Vivi wrote:
> On Wed, Aug 22, 2018 at 10:19:19AM -0400, Adam Jackson wrote:
> > On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote:
> > > - Sticking to fdo bugzilla and disabling gitlab issues for at least
> > > drm-intel for the time being. D
Hi Satendra,
On Fri, 27 Jul 2018 at 11:13, Satendra Singh Thakur
wrote:
> Following changes are done to this func:
I would certainly agree with Sean, Martin, and Jani's comments. This
patch was difficult to follow as it made so many changes at once.
Being a crucial function which has many subtle
Hi Eric,
On Fri, 31 Aug 2018 at 15:22, Eric Engestrom wrote:
> +- LIBPCIACCESS_VERSION=libpciaccess-0.10 &&
> + wget --no-check-certificate
> https://xorg.freedesktop.org/releases/individual/lib/$LIBPCIACCESS_VERSION.tar.bz2
> &&
Why are you using --no-check-certificate?!
Cheers,
Dan
> > ---
> > See it in action on my fork:
> > https://gitlab.freedesktop.org/eric/libdrm/pipelines/3885
>
> With the --no-check-certificate things explained:
>
> Reviewed-by: Daniel Vetter
Indeed, and also:
Reviewed-by: Daniel Stone
Thanks for doing this!
Cheers,
Daniel
Hi,
On Tue, 4 Sep 2018 at 11:05, Daniel Vetter wrote:
> On Tue, Sep 4, 2018 at 3:00 AM, Bas Nieuwenhuizen
> wrote:
> > +/* The chip this is compatible with.
> > + *
> > + * If compression is disabled, use
> > + * - AMDGPU_CHIP_TAHITI for GFX6-GFX8
> > + * - AMDGPU_CHIP_VEGA10 for GFX9+
> >
Hi,
On Tue, 4 Sep 2018 at 11:44, Christian König
wrote:
> Am 04.09.2018 um 12:15 schrieb Daniel Stone:
> > Right. The conclusion, after people went through and started sorting
> > out the kinds of formats for which they would _actually_ export real
> > colour buffers f
GitLab CI already captures all the stdout/stderr output from the build
process as the log. However, some other important information is hidden
in other log files.
Taken from Wayland, capture logs from the configuration process as well
as from every check.
Signed-off-by: Daniel Stone
Cc: Rodrigo
Hi,
On Thu, 6 Sep 2018 at 10:11, Lucas De Marchi wrote:
> On Wed, Sep 5, 2018 at 7:00 PM Rodrigo Vivi wrote:
> > well it builds for me.
> >
> > but any idea what might be wrong here on gitlab ci?
You can simulate what happens in CI by running the same script inside
the same container. There
Hi Russell,
On Tue, 26 Jun 2018 at 15:49, Russell King - ARM Linux
wrote:
> On Thu, May 17, 2018 at 04:41:35PM +0100, Daniel Stone wrote:
> > Thanks Russell. I did do a build test locally as well which had no
> > complaints. I'll merge this through drm-misc.
>
> I
Hi,
The atomic API being super-explicit about how userspace sequences its
calls is great and all, but having shared global state implicitly
dragged in is kind of ruining my day.
Currently on Intel, Weston sometimes fails on hotplug, because a
commit which only enables CRTC B (not touching CRTC A o
Hey Jakob,
On Thu, 5 Jul 2018 at 14:32, Jakob Bornecrantz wrote:
> So from a VR compositor getting blocked like this is a no-go as the
> user would quickly throw EPUKE. The situation is compounded by the
> fact that the VR compositor has no idea what the display compositor is
> doing with regards
Hi,
On Mon, 9 Jul 2018 at 08:38, Daniel Vetter wrote:
> On Fri, Jul 06, 2018 at 04:43:09PM +0100, Mike Lothian wrote:
> > Any change of this moving to https or the gitlab instance where its on as
> > default?
>
> Moving all the drm repos over to gitlab is somewhere on the plans, but we
> need to
n reality.
>
> You've been an excellent leader of our community so far, and I don't
> expect that to change just because you officially wear a new hat.
>
> Acked-by: Eric Anholt
Eric speaks for me.
Acked-by: Daniel Stone
Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi,
On Sat, 15 Sep 2018 at 00:56, Lucas De Marchi wrote:
> -To apply for commit rights ("Developer" role in gitlab) send a mail to
> -dri-devel@lists.freedesktop.org and please ping the maintainers if your
> request
> -is stuck.
> +To apply for commit rights ("Developer" role in gitlab), check p
Hi Satish,
On Fri, 7 Sep 2018 at 23:04, Satish Nagireddy
wrote:
> The requirement is to render interlaced alternate buffers. In case of
> alternate, top field and bottom field are in two different buffers.
>
> The question is, can we pass existing flags DRM_MODE_PRESENT_TOP_FIELD
> and DRM_MODE_P
Hi Emil,
This is off-topic for the list, but ...
On Tue, 7 Aug 2018 at 14:46, Emil Velikov wrote:
> Aside: libdrm following X/Wayland in that it lacks contributor/push access
> docs.
> Might be worth, copying the Mesa ones and adding a doc in-tree.
https://gitlab.freedesktop.org/wayland/wayland
Hi Vignesh,
On Thu, 5 Sept 2024 at 10:41, Vignesh Raman wrote:
> Uprev IGT to the latest version and deqp-runner
> to v0.20.0. Also update expectation files.
Thanks! This is:
Reviewed-by: Daniel Stone
Hi,
On 04/09/2023 09:54, Daniel Vetter wrote:
On Wed, 30 Aug 2023 at 17:14, Helen Koike > wrote: >> >> On 30/08/2023 11:57, Maxime Ripard wrote: >>> >>> I
agree that we need a baseline, but that baseline should be >>> defined
by the tests own merits, not their outcome on a >>> particular plat
Hi Maxime,
Hopefully less mangled formatting this time: turns out Thunderbird +
plain text is utterly unreadable, so that's one less MUA that is
actually usable to send email to kernel lists without getting shouted
at.
On Mon, 11 Sept 2023 at 15:46, Maxime Ripard wrote:
> On Mon, Sep 11, 2023 at
Hi Shawn,
On Fri, 6 Oct 2023 at 08:38, Hsiao Chien Sung wrote:
> + Padding provides ability to add pixels to width and height of a layer with
> + specified colors. Due to hardware design, Mixer in VDOSYS1 requires
> + width of a layer to be 2-pixel-align, or 4-pixel-align when ETHDR is
> enab
On Fri, 6 Oct 2023 at 18:32, Rob Clark wrote:
> ssh logging is the default for mesa, as it is generally more reliable.
> But if there are kernel issues, especially at boot, UART logging is
> infinitely more useful.
Hmm, we should still be capturing the UART boot logs regardless. Those
go into a c
Hi Shawn,
On Mon, 16 Oct 2023 at 06:23, Shawn Sung (宋孝謙) wrote:
> On Fri, 2023-10-13 at 17:26 +0100, Daniel Stone wrote:
> > If I understand the driver correctly, padding is automatically
> > applied
> > to compensate for unaligned dimensions. The first/last rows/columns
&
Hi Vignesh,
On Thu, 19 Oct 2023 at 09:07, Vignesh Raman wrote:
> +# Some tests crashes with malloc error and IGT tests floods
> +# the CI log with error messages and we end up with a warning message
> +# Job's log exceeded limit of 4194304 bytes.
> +# Job execution will continue but no more outpu
ble at [3]. IGT test available
> at [4].
Series is:
Reviewed-by: Daniel Stone
te the link from anongit to the Gitlab server to prevent the build
> script from hanging indefinitely.
It should be fixed by now, but yeah, the canonical source has changed.
Reviewed-by: Daniel Stone
Thanks Deborah!
Cheers,
Daniel
ame change before:
> > Reviewed-by: Fei Shao
> > Tested-by: Fei Shao
>
> Thanks!
And:
Reviewed-by: Daniel Stone
> >> OOTH, Intel recently added a feature for enumerating "suggested"
> >> cursor sizes. See https://patchwork.freedesktop.org/patc
andle overlapping overlay planes, and
any userspace which supports overlays (including Weston) already looks
at zpos, handles immutable properties, and will dtrt.
Anyway, this is:
Acked-by: Daniel Stone
Cheers,
Daniel
Hi Piotr,
On Wed, 24 Jul 2024 at 23:06, Piotr Zalewski wrote:
> Add support for gamma LUT in VOP2 driver. The implementation is based on
> the one found in VOP driver and modified to be compatible with VOP2. Blue
> and red channels in gamma LUT register write were swapped with respect to
> how ga
Hi Vignesh,
On Wed, 24 Jul 2024 at 11:11, Vignesh Raman wrote:
> +dumb_buffer@create-clear,Fail
> +dumb_buffer@create-valid-dumb,Fail
> +dumb_buffer@invalid-bpp,Fail
> +dumb_buffer@map-invalid-size,Fail
> +dumb_buffer@map-uaf,Fail
> +dumb_buffer@map-valid,Fail
> +fbdev@eof,Fail
> +fbdev@read,Fail
Hi Vignesh,
On Wed, 24 Jul 2024 at 11:12, Vignesh Raman wrote:
> For rockchip rk3288 and rk3399, the display driver is rockchip
> and gpu driver is panfrost. Currently, in drm-ci for rockchip
> rk3288 and rk3399, only the gpu driver is tested. Refactor
> the existing rockchip jobs to test both di
Hi Piotr,
On Thu, 25 Jul 2024 at 20:06, Piotr Zalewski wrote:
> I based my patch on how gamma LUT is handled in VOP. There, in atomic
> enable, gamma LUT write takes places at the end too, after the mutex was
> already first-time unlocked. I understand the concept of DRM atomic state
> updates an
it series adds support in drm-ci to run tests
> for both GPU and display drivers for MediaTek mt8173/mt8183, Rockchip
> rk3288/rk3399, and Amlogic Meson G12B (A311D) platforms.
>
> Update the expectations file, and skip driver-specific tests and
> tools_test on non-intel platforms.
Tha
On Wed, 7 Aug 2024 at 09:21, Vignesh Raman wrote:
> Uprev mesa to adapt to the latest changes in mesa ci.
> Project 'anholt/deqp-runner' was moved to 'mesa/deqp-runner'.
> So update the link.
Reviewed-by: Daniel Stone
Hi José,
On Tue, 13 Aug 2024 at 11:51, José Expósito wrote:
> - When a CRTC is added and removed before device creation, there
>is a vblank warning.
>The issue is caused because vblanks are referenced using the
>CRTC index but, because one of the CRTCs is removed, the
>indices ar
Hey,
On Thu, 14 Sept 2023 at 10:54, Maxime Ripard wrote:
> On Tue, Sep 12, 2023 at 02:16:41PM +0100, Daniel Stone wrote:
> > Hopefully less mangled formatting this time: turns out Thunderbird +
> > plain text is utterly unreadable, so that's one less MUA that is
> > act
Hi Jason, CK,
On Tue, 19 Sept 2023 at 04:04, Jason-JH.Lin wrote:
> The patch series provides drm driver support for enabling secure video
> path (SVP) playback on MediaiTek hardware in the Linux kernel.
>
> [...]
>
> Memory Usage in SVP:
> The overall flow of SVP starts with encrypted video comin
On Mon, 18 Sept 2023 at 23:02, Helen Koike wrote:
> On 14/09/2023 05:12, Daniel Vetter wrote:
> > Also yes how that landed without anyone running lockdep is ... not good. I
> > guess we need a lockdep enabled drm ci target that runs vkms tests asap
> > :-)
>
> btw, I just executed a draft version
On Tue, 20 Feb 2024 at 09:05, Maxime Ripard wrote:
> On Tue, Feb 20, 2024 at 09:49:25AM +0100, Maxime Ripard wrote:
> > This will be mostly transparent to current committers and users: we'll
> > still use dim, in the exact same way, the only change will be the URL of
> > the repo. This will also b
Hi Stephen,
On Tue, 20 Feb 2024 at 22:46, Stephen Rothwell wrote:
> On Tue, 20 Feb 2024 11:25:05 +0000 Daniel Stone wrote:
> > cc sfr - once we move the DRM repos to a different location, what's
> > the best way to update linux-next?
>
> These are (I think) all the
Hi,
On Mon, 26 Feb 2024 at 03:21, Lucas De Marchi wrote:
> All of this should be fixed by now: dim is used for applying and pushing
> patches, which has additional checks so that doesn't happen again. Still
> pending confirmation from Daniel Stone if the git server hooks are ready
On Mon, 26 Feb 2024 at 11:57, Jani Nikula wrote:
> On Mon, 26 Feb 2024, Maxime Ripard wrote:
> > For the recent-ish subscriptions, it's possible since we've required to
> > open a Gitlab issue for a while, so we have the association between the
> > Gitlab account and the SSH account already.
> >
On Mon, 26 Feb 2024 at 12:03, Jani Nikula wrote:
> On Mon, 26 Feb 2024, Daniel Stone wrote:
> > It's a fair question. If you want to verify that someone is
> > @intel.com, maybe get them to email you out-of-band to check it. If
> > you want to check something else, j
/HEIGHT caps, which can only declare
> a one size fits all limit for the whole device.
Acked-by: Daniel Stone
Cheers,
Daniel
Hi Lucas,
On Fri, 26 Jan 2024 at 17:00, Lucas Stach wrote:
> The dma sync operation needs to be done with DMA_BIDIRECTIONAL when
> the BO is prepared for both read and write operations. With the
> current inverted if ladder it would only be synced for DMA_FROM_DEVICE.
>
> [...]
>
> static inline
Hi,
On Tue, 30 Jan 2024 at 18:39, Zack Rusin wrote:
> In general, yes. Of course it's a little more convoluted because we'll
> act like OpenGL runtime here (i.e. glXSwapBuffers), i.e. our driver
> will fake page-flips because the only memory we'll have is a single
> buffer as the actual page-flip
On Wed, 31 Jan 2024 at 02:31, Zack Rusin wrote:
> On Tue, Jan 30, 2024 at 6:50 PM Daniel Stone wrote:
> > The entire model we have is that basis timing flows backwards. The
> > 'hardware' gives us a deadline, KMS angles to meet that with a small
> > margin, the
Hi,
On Tue, 13 Feb 2024 at 10:18, Marius Vlad wrote:
> On Tue, Feb 13, 2024 at 11:57:59AM +0200, Tomi Valkeinen wrote:
> > I haven't. I'm quite unfamiliar with Weston, and Randolph from TI (cc'd) has
> > been working on the Weston side of things. I also don't know if there's
> > something TI spec
Hi,
On Fri, 16 Feb 2024 at 09:00, Tomi Valkeinen
wrote:
> On 13/02/2024 13:39, Daniel Stone wrote:
> > Specifically, you probably want commits 4cde507be6a1 and 58dde0e0c000.
> > I think the window of breakage was small enough that - assuming either
> > those commits or an up
Hi,
On Wed, 8 May 2024 at 16:49, Daniel Vetter wrote:
> On Wed, May 08, 2024 at 09:38:33AM +0100, Daniel Stone wrote:
> > Right now, if your platform requires CMA for display, then the app
> > needs access to the GPU render node and the display node too, in order
> > to a
nd its extensions, 2) Vulkan and its extensions, 3) libcamera.
But it doesn't really make much difference; people are going to get the point.
With whatever reasonable wording, series is:
Reviewed-by: Daniel Stone
Thanks Jacopo!
-d
Hi,
On Mon, 20 May 2024 at 08:39, Tomeu Vizoso wrote:
> On Fri, May 10, 2024 at 10:34 AM Lucas Stach wrote:
> > Am Mittwoch, dem 24.04.2024 um 08:37 +0200 schrieb Tomeu Vizoso:
> > > If we expose a render node for NPUs without rendering capabilities, the
> > > userspace stack will offer it to co
Hi Vignesh,
On Wed, 29 Nov 2023 at 12:19, Vignesh Raman wrote:
> Expected driver for mt8173 is "mediatek" and for mt8183
> it is "panfrost". Set IGT_FORCE_DRIVER to 'mediatek' as
> the expected driver for mt8173.
Actually, for mt8183 it's both. And for mt8173 it will probably be
mediatek+pvr pre
On Wed, 19 Jun 2024 at 12:31, Ville Syrjala
wrote:
> Export drm_plane_has_format() so that drivers can use it.
Acked-by: Daniel Stone
Hi Dave,
On Fri, 21 Jun 2024 at 14:19, Dave Stevenson
wrote:
> Add myself as maintainer for VC4 alongside Maxime, and
> our internal review list as reviewer.
Both patches are:
Acked-by: Daniel Stone
Cheers,
Daniel
Hi,
On Wed, 26 Jun 2024 at 09:28, Lucas Stach wrote:
> Mesa doesn't cope right now. Mostly because of the renderonly thing
> where we magically need to match render devices to otherwise render
> incapable KMS devices. The way this matching works is that the
> renderonly code tries to open a scree
On Wed, 26 Jun 2024 at 18:52, Daniel Vetter wrote:
> On Wed, Jun 26, 2024 at 11:39:01AM +0100, Daniel Stone wrote:
> > On Wed, 26 Jun 2024 at 09:28, Lucas Stach wrote:
> > > So we are kind of stuck here between breaking one or the other use-
> > > case. I'm leani
Hi,
On Fri, 28 Jun 2024 at 10:43, Tomeu Vizoso wrote:
> On Wed, Jun 26, 2024 at 9:26 PM Daniel Stone wrote:
> > It's not just etnaviv, it's literally every Mesa driver which works
> > with decoupled render/display. So that would be etnaviv-v2,
> > panfrost-v2,
Hi,
On Tue, 7 May 2024 at 12:15, Daniel Vetter wrote:
> On Mon, May 06, 2024 at 04:01:42PM +0200, Hans de Goede wrote:
> > On 5/6/24 3:38 PM, Daniel Vetter wrote:
> > I agree that bad applications are an issue, but not for the flathub / snaps
> > case. Flatpacks / snaps run sandboxed and don't ha
On Wed, 8 May 2024 at 09:33, Daniel Vetter wrote:
> On Wed, May 08, 2024 at 06:46:53AM +0100, Daniel Stone wrote:
> > That would have the unfortunate side effect of making sandboxed apps
> > less efficient on some platforms, since they wouldn't be able to do
> > direct
Hi Gerd,
On 14 March 2018 at 08:03, Gerd Hoffmann wrote:
>> Either mlock account (because it's mlocked defacto), and get_user_pages
>> won't do that for you.
>>
>> Or you write the full-blown userptr implementation, including mmu_notifier
>> support (see i915 or amdgpu), but that also requires Ch
Hi Inki,
On 13 April 2018 at 10:55, Inki Dae wrote:
> 2018년 03월 30일 23:11에 Daniel Stone 이(가) 쓴 글:
>> Since drm_framebuffer can now store GEM objects directly, place them
>> there rather than in our own subclass. As this makes the framebuffer
>> create_handle and destroy func
Hi Tomi,
On 20 April 2018 at 08:09, Tomi Valkeinen wrote:
> It's actually not quite clear to me how manual update displays work with
> DRM...
>
> As far as I see, we have essentially two cases: 1) single buffering,
> where the userspace must set an area in the fb dirty, which then
> triggers the
Hi Tony!
On 20 April 2018 at 15:25, Tony Lindgren wrote:
> * Daniel Stone [180420 10:21]:
>> On 20 April 2018 at 08:09, Tomi Valkeinen wrote:
>> > It's actually not quite clear to me how manual update displays work with
>> > DRM...
>> >
>> >
Hi,
On 20 April 2018 at 21:32, Manasi Navare wrote:
> On Wed, Apr 18, 2018 at 09:39:02AM +0200, Daniel Vetter wrote:
>> On Wed, Apr 18, 2018 at 5:58 AM, Keith Packard wrote:
>> > I'd also encourage using a single unit for all of these values,
>> > preferably nanoseconds. Absolute times should al
Hey,
On 9 October 2017 at 11:30, Jani Nikula wrote:
> On Tue, 03 Oct 2017, Jani Nikula wrote:
>> I merged this last week with Daniel's IRC ack. We'll need to give people
>> a little bit of time before updating nightly.conf. Sorry for the
>> inconvenience in the mean time.
>
> Andrzej, all the bi
Hi,
On 11 October 2017 at 08:46, Alex Ivanov wrote:
> Display power management should be available to user no matter whether
> display server implements it or not and should be made server agnostic
> (X.Org, Wayland compositor), without need of TTY change.
>
> Reasons:
> 1. User implements an own
Hi Alex,
On 11 October 2017 at 12:22, Alex Ivanov wrote:
> On 11.10.2017 13:13, Daniel Stone wrote:
>> If people are doing fancy new compositors without DPMS support, then I
>> recommend they use an existing compositor base, such as libweston
>> (others are also avai
fault behavior.
I don't think there's any reason to remain suspicious of
CLOCK_MONOTONIC in 2017. Not to mention that removing it wrecks
Weston/etc's ability to give clients present-timing feedback, so
removing it is a net uABI improvement.
Acked-by: Daniel Stone
Cheers,
Daniel
Hi,
On 16 October 2017 at 06:29, Dave Airlie wrote:
> This adds the infrastructure needed to quirk displays
> using edid and to mark them a non-standard.
>
> A non-standard display is one which doesn't work like
> a normal rectangular monitor or requires some transformation
> of the output by the
Hi Ankit,
On 17 October 2017 at 12:08, Nautiyal, Ankit K
wrote:
> On Similar lines, I was able to add the new DRM_CLIENT_CAP_ASPECT_RATIO. I
> also added a member 'aspect_ratio_required' in drm_file structure,
Quick bikeshed suggestion: aspect_ratio_supported. ;)
> Now what I want to do is
>
>
Hi,
On 25 October 2017 at 07:30, Dave Airlie wrote:
> This adds the infrastructure needed to quirk displays
> using edid and to mark them as non-desktop to denote
> that userspace shouldn't display a standard desktop on them.
>
> A non-desktop display is one which doesn't work like
> a normal rec
Hi,
On 19 October 2017 at 17:27, Keith Packard wrote:
> Daniel Stone writes:
>> Why not add a client cap which hides 'non-standard' displays
>> completely from non-aware clients? That way you can keep the connected
>> status as is, and clients either never
Hi Uma,
On 7 November 2017 at 12:06, Uma Shankar wrote:
> This patch series adds properties for plane color features. It adds
> properties for degamma used to linearize data, CSC used for gamut
> conversion, and gamma used to again non-linearize data as per panel
> supported color space. These ca
Object and property IDs cannot be zero. Prevent them from being added to
the request stream at all, rather than breaking at commit time.
Signed-off-by: Daniel Stone
---
xf86drmMode.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xf86drmMode.c b/xf86drmMode.c
index 15957ffc..bd59ef25
On 7 March 2018 at 16:42, Daniel Vetter wrote:
> On Wed, Mar 07, 2018 at 12:42:15PM +0000, Daniel Stone wrote:
>> Object and property IDs cannot be zero. Prevent them from being added to
>> the request stream at all, rather than breaking at commit time.
>
> Reviewed-by: Danie
Hi,
On 8 March 2018 at 17:08, Ilia Mirkin wrote:
> On Thu, Mar 8, 2018 at 11:57 AM, Mario Kleiner
> wrote:
>> Under EGL there is matching of channel masks, so only X11+GLX is
>> problematic. Not sure if anything special would need to be done for
>> XWayland, haven't looked at that at all so far.
Hi John,
On 8 March 2018 at 19:43, John Stultz wrote:
> On Thu, Mar 8, 2018 at 3:10 AM, Robert Foss wrote:
>>> @@ -76,8 +76,6 @@ uint32_t
>>> DrmGenericImporter::ConvertHalFormatToDrm(uint32_t hal_format) {
>>> return DRM_FORMAT_ABGR;
>>> case HAL_PIXEL_FORMAT_RGB_565:
>>>
/ 48 params
split would make more sense.
Either way, those are just my opinions (you did ask), and I don't see
anything really objectionable, so if you think that's a good split
then this is:
Acked-by: Daniel Stone
Cheers,
Daniel
_
getfb can only return a single plane, so reject attempts to use it with
multi-plane framebuffers.
Signed-off-by: Daniel Stone
Reported-by: Daniel van Vugt
Fixes: 308e5bcbdb10 ("drm: add an fb creation ioctl that takes a pixel format
v5")
Bugzilla: https://bugs.freedesktop.org/show_
Hi,
On 21 March 2018 at 08:27, Daniel Vetter wrote:
> On Tue, Mar 20, 2018 at 09:01:11PM -0400, Rob Clark wrote:
>> On Tue, Mar 20, 2018 at 6:58 PM, Daniel Stone wrote:
>> > getfb can only return a single plane, so reject attempts to use it with
>> > multi-plane fr
Hi Paul,
On 21 March 2018 at 15:29, Paul Kocialkowski
wrote:
> +/*
> + * Allwinner "MB32" tiled format
> + *
> + * This is the primary layout coming out of the VPU, where pixels are tiled
> + * 32x32.
> + */
Can you please be a bit more specific here, following the other
examples? In particular,
ype is just a hint anyway, and more
> useful for the kernel->userspace direction.
Reviewed-by: Daniel Stone
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi,
AddFB is single-planar, with no offset and only depth/bpp rather than
an explicit format, so we now have AddFB2 which can carry multiple
planes, an explicit format and also a modifier. At the time we never
actually did GetFB2 to go with GetFB.
This submission rights that historical wrong, whic
401 - 500 of 753 matches
Mail list logo
