| 16 +
> include/uapi/drm/drm_mode.h | 14 +
> 38 files changed, 3882 insertions(+), 30 deletions(-)
> create mode 100644 Documentation/gpu/rfc/color_pipeline.rst
> create mode 100644 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
> create mode 100644 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.h
> create mode 100644 drivers/gpu/drm/drm_colorop.c
> create mode 100644 drivers/gpu/drm/tests/drm_fixp_test.c
> create mode 100644 drivers/gpu/drm/vkms/Kconfig
> create mode 100644 drivers/gpu/drm/vkms/tests/.kunitconfig
> create mode 100644 drivers/gpu/drm/vkms/tests/vkms_color_tests.c
> create mode 100644 drivers/gpu/drm/vkms/vkms_colorop.c
> create mode 100644 drivers/gpu/drm/vkms/vkms_luts.c
> create mode 100644 drivers/gpu/drm/vkms/vkms_luts.h
> create mode 100644 include/drm/drm_colorop.h
>
> --
> 2.44.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Oct 12, 2023 at 01:39:44PM +0300, Pekka Paalanen wrote:
> On Thu, 12 Oct 2023 11:53:52 +0200
> Daniel Vetter wrote:
>
> > On Thu, Oct 12, 2023 at 11:55:48AM +0300, Pekka Paalanen wrote:
> > > On Wed, 11 Oct 2023 11:42:24 +0200
> > > Daniel Vetter wrote
On Thu, Oct 12, 2023 at 11:55:48AM +0300, Pekka Paalanen wrote:
> On Wed, 11 Oct 2023 11:42:24 +0200
> Daniel Vetter wrote:
>
> > On Wed, Oct 11, 2023 at 11:48:16AM +0300, Pekka Paalanen wrote:
> > > On Tue, 10 Oct 2023 10:06:02 -0600
> > > jim.cro...@gmail.co
oblem. Sessions could register what
kind of info they need for their session, and something like journald can
figure out how to record it all.
If you want the kernel to keep separate flight recorders I guess we could
add that, but I don't think it currently exists for the dyndbg stuff at
least
On Mon, 31 Jul 2023 at 04:01, André Almeida wrote:
>
> Em 13/07/2023 04:51, Pekka Paalanen escreveu:
> > On Tue, 11 Jul 2023 10:57:57 +0200
> > Daniel Vetter wrote:
> >
> >> On Fri, Jul 07, 2023 at 07:40:59PM -0300, André Almeida wrote:
> >>> From
ss crtc (and their connected
planes/connectors) might result in some oversynchronization issues, and
userspace should therefore avoid them if feasible.
With some sentences added to clarify this:
Reviewed-by: Daniel Vetter
> +
> +A "modeset" is a change in KMS state that might enable,
On Mon, 8 May 2023 at 10:58, Simon Ser wrote:
>
> On Friday, May 5th, 2023 at 21:53, Daniel Vetter wrote:
>
> > On Fri, May 05, 2023 at 04:06:26PM +, Simon Ser wrote:
> > > On Friday, May 5th, 2023 at 17:28, Daniel Vetter wrote:
> > >
> > > &g
On Mon, 8 May 2023 at 10:24, Pekka Paalanen wrote:
>
> On Fri, 5 May 2023 21:51:41 +0200
> Daniel Vetter wrote:
>
> > On Fri, May 05, 2023 at 05:57:37PM +0200, Sebastian Wick wrote:
> > > On Fri, May 5, 2023 at 5:28 PM Daniel Vetter wrote:
> > > >
>
On Fri, May 05, 2023 at 04:06:26PM +, Simon Ser wrote:
> On Friday, May 5th, 2023 at 17:28, Daniel Vetter wrote:
>
> > Ok no comments from me on the actual color operations and semantics of all
> > that, because I have simply nothing to bring to that except confusion :-)
&g
On Fri, May 05, 2023 at 05:57:37PM +0200, Sebastian Wick wrote:
> On Fri, May 5, 2023 at 5:28 PM Daniel Vetter wrote:
> >
> > On Thu, May 04, 2023 at 03:22:59PM +, Simon Ser wrote:
> > > Hi all,
> > >
> > > The goal of this RFC is to expose a gene
ation 42 (input CSC)
> └─ "matrix_data" = PQ → scRGB (TF)
> Color operation 44 (DeGamma)
> └─ "type" = Bypass
> Color operation 45 (gamut remap)
> └─ "matrix_data" = scRGB (TF) → PQ
> Color operation 46 (shaper LUT RAM)
> └─ "lut_data" = PQ → Display native
> Color operation 47 (3D LUT RAM)
> └─ "lut_data" = Gamut mapping + tone mapping + night mode
> Color operation 48 (blend gamma)
> └─ "1d_curve_type" = PQ
>
> I hope comparing these properties to the diagrams linked above can help
> understand how the uAPI would be used and give an idea of its viability.
>
> Please feel free to provide feedback! It would be especially useful to have
> someone familiar with Arm SoCs look at this, to confirm that this proposal
> would work there.
>
> Unless there is a show-stopper, we plan to follow up this RFC with
> implementations for AMD, Intel, NVIDIA, gamescope, and IGT.
>
> Many thanks to everybody who contributed to the hackfest, on-site or remotely!
> Let's work together to make this happen!
>
> Simon, on behalf of the hackfest participants
>
> [1]: https://wiki.gnome.org/Hackfests/ShellDisplayNext2023
> [2]: https://github.com/ValveSoftware/gamescope
> [3]:
> https://github.com/ValveSoftware/gamescope/blob/5af321724c8b8a29cef5ae9e31293fd5d560c4ec/src/docs/Steam%20Deck%20Display%20Pipeline.png
> [4]: https://kernel.org/doc/html/latest/_images/dcn3_cm_drm_current.svg
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Jan 06, 2023 at 04:33:04PM -0800, Abhinav Kumar wrote:
> Hi Daniel
>
> Thanks for looking into this series.
>
> On 1/6/2023 1:49 PM, Dmitry Baryshkov wrote:
> > On Fri, 6 Jan 2023 at 20:41, Daniel Vetter wrote:
> > >
> > > On Fri, Jan 06, 202
On Fri, Jan 06, 2023 at 05:43:23AM +0200, Dmitry Baryshkov wrote:
> On Fri, 6 Jan 2023 at 02:38, Jessica Zhang wrote:
> >
> >
> >
> > On 1/5/2023 3:33 AM, Daniel Vetter wrote:
> > > On Wed, Jan 04, 2023 at 03:40:33PM -0800, Jessica Zhang wrote:
> > >
_blend.c | 17 +++
> drivers/gpu/drm/drm_plane.c | 8 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 9 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 65 +++
> include/drm/drm_atomic_helper.h | 5 +-
> include/drm/drm_blend.h |
ion to "enabled", interpret
> it as "desired".
>
> [1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3794
>
> Signed-off-by: Simon Ser
Reviewed-by: Daniel Vetter
I think a doc patch which documents the guarantees we're trying to make
On Fri, Jun 10, 2022 at 09:15:35AM +, Simon Ser wrote:
> On Friday, June 10th, 2022 at 10:41, Daniel Vetter wrote:
>
> > Anything I've missed? Or got completely wrong?
>
> This plan looks good to me.
>
> As Pekka mentionned, I'd also like to have a con
kms driver stuff. I think we should also put in a
"limitations" part there and just spec that any kind of scaling is a no-go
on these (and that drivers better validate this is the case).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Jun 10, 2022 at 10:41:05AM +0200, Daniel Vetter wrote:
> Hi all,
>
> Kinda top post because the thread is sprawling and I think we need a
> summary/restart. I think there's at least 3 issues here:
>
> - lack of hotspot property support, which means compositors c
ne 2nd, 2022 at 17:42, Zack Rusin wrote:
>
> > - all userspace code needs to hardcore a list of drivers which require
> > hotspots because there's no way to query from drm "does this driver
> > require hotspot"
>
> Can you elaborate? I'm not sure I understand what you mean here.
>
> Thanks,
>
> Simon
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Apr 27, 2022 at 05:23:22PM +0300, Jani Nikula wrote:
> On Wed, 27 Apr 2022, Daniel Vetter wrote:
> > On Thu, Apr 14, 2022 at 01:24:30PM +0300, Jani Nikula wrote:
> >> On Mon, 11 Apr 2022, Alex Deucher wrote:
> >> > On Mon, Apr 11, 2022 at 6:18 A
Fri, Apr 8, 2022 at 10:56 AM Hans de Goede
> >> > wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> On 4/8/22 16:08, Alex Deucher wrote:
> >> >>> On Fri, Apr 8, 2022 at 4:07 AM Daniel Vetter wrote:
> >
ot a good idea. Much
better if we get to the correct future step-by-step.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
tcoming of the current
> > backlight API is that it does not let userspace know if the
> > number is a linear control of the time the LEDs are on vs off
> > (assuming a LED backlight) or if some component already uses a
> > lookup table to make 0-100% be more of a linear scale in the
> > human perception, which is very much non linear. See e.g.:
> >
> > https://www.sciencedirect.com/topics/computer-science/perceived-brightness
> >
> > "refers to the perceived amount of light coming from self-luminous sources"
> > "Perceived brightness is a very nonlinear function of the amount of light
> > emitted by a lamp."
> >
> > The problem is that at the kernel level we have no idea if
> > we are controlling "the amount of light emitted" or
> > perceived brightness and it would be sorta nice for userspace
> > to know. So the idea here is/was to allow userspace to make some
> > educated guess here. E.g. a bl_brightness_control_method of "PWM"
> > hints strongly at "the amount of light emitted" (but this is
> > not true 100% of the time). ATM userspace does not do any
> > "perceived brightness" curve correction so for the first
> > implementation of moving brightness control to drm properties
> > I believe it might be better to just park the whole
> > bl_brightness_control_method propery idea.
> >
> > Which would leave the problem of communicating the control_method=="none"
> > case but we can just use bl_brightness_max == 0 for that.
> >
> > Regards,
> >
> > Hans
> >
> >
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Jun 21, 2021 at 12:16:55PM +0200, Christian König wrote:
> Am 18.06.21 um 20:45 schrieb Daniel Vetter:
> > On Fri, Jun 18, 2021 at 8:02 PM Christian König
> > wrote:
> > > Am 18.06.21 um 19:20 schrieb Daniel Vetter:
> > > [SNIP]
> > > The whole
On Fri, Jun 18, 2021 at 8:02 PM Christian König
wrote:
>
> Am 18.06.21 um 19:20 schrieb Daniel Vetter:
> > On Fri, Jun 18, 2021 at 6:43 PM Christian König
> > wrote:
> >> Am 18.06.21 um 17:17 schrieb Daniel Vetter:
> >>> [SNIP]
> >>> Ignori
On Fri, Jun 18, 2021 at 6:43 PM Christian König
wrote:
>
> Am 18.06.21 um 17:17 schrieb Daniel Vetter:
> > [SNIP]
> > Ignoring _all_ fences is officially ok for pinned dma-buf. This is
> > what v4l does. Aside from it's definitely not just i915 that does this
> &
On Fri, Jun 18, 2021 at 4:42 PM Christian König
wrote:
>
> Am 18.06.21 um 16:31 schrieb Daniel Vetter:
> > [SNIP]
> >> And that drivers choose to ignore the exclusive fence is an absolutely
> >> no-go from a memory management and security point of view. Exclusi
On Fri, Jun 18, 2021 at 11:15 AM Christian König
wrote:
>
> Am 17.06.21 um 21:58 schrieb Daniel Vetter:
> > On Thu, Jun 17, 2021 at 09:37:36AM +0200, Christian König wrote:
> >> [SNIP]
> >>> But, to the broader point, maybe? I'm a little fuzzy on exactly w
ctl since it
> > > > seems
> > > > like there's no real disagreement on that one. The import ioctl,
> > > > however,
> > > > has a lot of debate around it so it's intended to be RFC-only for now.
> > > >
> > > > Mesa MR:
> > > > https://nam11.safelinks.protecti
device - for most current
> compositors as an EGLImage, for some others as a VkImage - and falling back
> to GL composition paths, or GL blits, or even ReadPixels if strictly
> necessary, so your client content continues to be accessible.
>
Another reminder that we're in the election process, and the next
deadline is approaching:
- Send board nominations to elections AT x DOT org
- Got to https://members.x.org/ to renew your membership (or become
one to begin with!)
On Tue, Mar 17, 2020 at 7:21 AM Daniel Vetter wrote:
>
rtwined with amdgpu's special interpretation of dma_resv
fences though, no idea. We might need to revamp all that. But for a
userspace client that does nothing fancy (no multiple render buffer
targets in one bo, or vk style "I write to everything all the time,
perhaps" stuff) there should be 0 perf difference between implicit sync
through dma_resv and explicit sync through sync_file/syncobj/dma_fence
directly.
If there is I'd consider that a bit a driver bug.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
t.. That said,
> I'm happy to leave that up to the actual video experts. (I just do 3D)
dma_fence has an error state which you can set when things went south. The
fence still completes (to guarantee forward progress).
Currently that error code isn't really propagated anywhere (well i9
be enough (and I guess Christian gets to fix up amdgpu more,
at least for anything that has a dma-buf attached even if it's not shared
with anything !amdgpu.ko).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_
gpus will nick your rendering
with a quick reset. Iirc someone (from cros google team maybe) was even
looking into making llvmpipe run on top of vgem as a real dri/drm mesa
driver.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
__
rs who received two year terms starting in 2019 wereSamuel
> Iglesias Gonsálvez, Manasi D Navare, Lyude Paul and Daniel Vetter.
> They will continue to serve until their term ends in 2021. Current
> directors whose term expires in 2020 are Eric Anholt, Bryce
> Harrington, Keith Pac
, Manasi D Navare, Lyude Paul and Daniel Vetter.
They will continue to serve until their term ends in 2021. Current
directors whose term expires in 2020 are Eric Anholt, Bryce
Harrington, Keith Packard and Harry Wentland.
A director is expected to participate in the fortnightly IRC meeting
to
lso still happen next year. Also fd.o
servers will keep running. The only thing we might need to switch off
is the CI support.
> Budgeting and cloud is hard, the feedback loops are messy. In the old
> system the feedback loop was simple, we don't have admin time or money
> for
On Fri, Feb 28, 2020 at 10:29 AM Erik Faye-Lund
wrote:
>
> On Fri, 2020-02-28 at 13:37 +1000, Dave Airlie wrote:
> > On Fri, 28 Feb 2020 at 07:27, Daniel Vetter
> > wrote:
> > > Hi all,
> > >
> > > You might have read the short take in the X.org boar
On Fri, Feb 28, 2020 at 4:38 AM Dave Airlie wrote:
>
> On Fri, 28 Feb 2020 at 07:27, Daniel Vetter wrote:
> >
> > Hi all,
> >
> > You might have read the short take in the X.org board meeting minutes
> > already, here's the long version.
> >
> &g
. The board is of course working on acquiring sponsors, but
filling a shortfall of this magnitude is neither easy nor quick work,
and we therefore decided to give an early warning as soon as possible.
Any help in finding sponsors for fd.o is very much appreciated.
Thanks, Daniel
--
Daniel Vetter
Softwa
gt; > > one or two hwpipe's from the devices global atomic state, depending on
> > > scanout width.. the hwpipe (sspp) is the physical resource behind a
> > > plane, so essentially the kms planes are virtualized. At some point
> > > if you have too many wi
On Mon, Oct 21, 2019 at 10:48 AM Pekka Paalanen wrote:
>
> On Fri, 18 Oct 2019 17:47:49 +0200
> Daniel Vetter wrote:
>
> > On Fri, Oct 18, 2019 at 4:34 PM Pekka Paalanen wrote:
> > >
> > > On Fri, 18 Oct 2019 16:19:33 +0200
> > > Daniel Vetter wrot
On Fri, Oct 18, 2019 at 4:34 PM Pekka Paalanen wrote:
>
> On Fri, 18 Oct 2019 16:19:33 +0200
> Daniel Vetter wrote:
>
> > On Fri, Oct 18, 2019 at 3:43 PM Pekka Paalanen wrote:
> > >
> > > On Fri, 18 Oct 2019 07:54:50 -0400
> > > "Drew DeVault&q
ant to stop this behaviour and require
CAP_SYS_ADMIN to become master, even accidentally.
- I thought you can always re-open your own fd through proc? Which
should be good enough for this use-case here.
- Non-master primary node should indeed give you all the GET* ioctls
for kms, and nothing else
On Tue, May 21, 2019 at 12:07:12PM +0300, Pekka Paalanen wrote:
> On Tue, 21 May 2019 10:48:49 +0200
> Daniel Vetter wrote:
>
> > With Eric's patch
> >
> > commit ba6e798ecf320716780bb6a6088a8d17dcba1d49
> > Author: Eric Anholt
> > Date: Wed Apr
rnel patch review. That's not reasonable, same way kernel
people can't review all the userspace we have. Try to clarify
expectations a bit more.
Cc: Eric Anholt
Cc: Pekka Paalanen
Cc: cont...@emersion.fr
Cc: wayland-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
Documentat
rd.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Mon, Oct 29, 2018 at 01:24:56PM +, Wentland, Harry wrote:
> On 2018-10-26 7:22 a.m., Daniel Vetter wrote:
> > On Fri, Oct 26, 2018 at 1:08 PM Daniel Stone wrote:
> >>
> >> Hi,
> >>
> >> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter wrote:
&
On Fri, Oct 26, 2018 at 1:08 PM Daniel Stone wrote:
>
> Hi,
>
> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter wrote:
> > On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> > > On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> > &g
On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone wrote:
> > >
> > > On Tue, 16 Oct 2018 at 08:17, Peter Hutterer
> > > wrote:
&
nces, travel sponsoring grants,
papers committee, and acquiring lots of sponsors. None of this is
spelled out in the bylaws, it's all in policies that the board
deliberates and approves. I think this same approach will also work
well for fd.o.
And if members are unhappy with what the boa
to send in your comments in private, please send them to
both the x.org board and gpul - they want to know how to improve and
what to keep for the next conference they're going to organize too.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 -
drmModeAtomicReq *req,
> @@ -2477,6 +2511,7 @@ drm_output_apply_state_atomic(struct drm_output_state
> *state,
> plane_state->dest_w);
> ret |= plane_add_prop(req, plane, WDRM_PLANE_CRTC_H,
> plane_state->dest_h);
> + ret |= plane_add_damage(req, backend, plane_state);
>
> if (ret != 0) {
> weston_log("couldn't set plane state\n");
> --
> 2.17.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
le.
>
> I am looking forward to seeing you there. If you have any
> inquiries/questions, please send an email to xdc2...@gpul.org, adding on
> CC the X.org board (bo...@foundation.x.org).
>
> Best regards,
>
> Sam
> ___
> mes
On Thu, Jun 21, 2018 at 11:16 PM, Daniel Vetter wrote:
> Hi all,
>
> The X.org board is soliciting proposals to host XDC in 2019. By the usual
> rotation a location in (North) America is preferred, but the board will also
> consider other locations, especially if there'
just have some questions about what organizing XDC entails,
please feel free to chat with a previous organizers, or with someone from
the board.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_
On Wed, Apr 25, 2018 at 01:27:20PM +0100, Emil Velikov wrote:
> On 24 April 2018 at 20:14, Daniel Vetter wrote:
> > On Tue, Apr 24, 2018 at 7:30 PM, Emil Velikov
> > wrote:
> >> On 13 April 2018 at 11:00, Daniel Vetter wrote:
> >>> This tries to align with t
On Tue, Apr 24, 2018 at 7:30 PM, Emil Velikov wrote:
> On 13 April 2018 at 11:00, Daniel Vetter wrote:
>> This tries to align with the X.org communities's long-standing
>> tradition of trying to be an inclusive community and handing out
>> commit rights fairly freely.
enneth Graunke
Cc: Kristian H. Kristensen
Cc: Maarten Lankhorst
Cc: Petri Latvala
Cc: Rodrigo Vivi
Cc: Sean Paul
Reviewed-by: Keith Packard
Signed-off-by: Daniel Vetter
---
If you wonder about the wide distribution list for an igt patch: I'd
like to start a discussions about x.org community
st) could bypass the one per-crtc
commit queue that atomic has. That would allow us to hand out overlay
planes using leases, while the compositor still composites everything
else.
But that's a quite a bit away, and there isn't really any real code yet
for it.
-Daniel
--
Daniel Vetter
Softwar
nd reject the modeset, and if the modeset passes, userspace
knows that the driver will make sure the flips will stay in sync forever.
Without that generic userspace can indeed not make any assumptions, since
different CRTC might have different clock sources and slowly drift.
> >> >
. Any testing reports
> at all would be awesome.
>
>
> Thanks,
> pq
> _______
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
D
Bunch of people decided not to do XDC this
year even, because too much travelling in one row. Plus Google's limit
in scheduling a room, plus Khr f2f. We'll try to do better next year,
but sometimes perfect scheduling is just not an option.
Thanks, Daniel
--
ready, we'd like to hear
more feedback. Just reply to this mail or send a mail to
bo...@foundation.x.org if you don't want the entire world to read it.
And if you want to send at pseudonymous feedback, drop a pastebin onto
the #xf-bod channel on the OFTC irc server.
Thanks, Daniel
--
D
On Fri, Jul 14, 2017 at 03:07:11PM +0530, Vikas Patil wrote:
> On Thu, Jul 13, 2017 at 7:20 PM, Daniel Vetter wrote:
> > On Thu, Jul 13, 2017 at 3:33 PM, Vikas Patil wrote:
> >> Dear All,
> >>
> >> I am looking for an solution to have early smooth splash
splash quits), then re-enable it when weston starts.
Cheers, Daniel
>
> Thanks & Regards,
> Vikash
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
Daniel Vetter
Software E
On Fri, May 12, 2017 at 12:08 AM, Daniel Vetter wrote:
> The X.org board is soliciting proposals to host XDC in 2017
That's meant to read 2018 too of course, I missed one date ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.
some questions about what organizing XDC entails,
please feel free to chat with a previous organizers, or with someone from
the board.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
On Wed, Nov 23, 2016 at 02:39:01PM +0100, Daniel Vetter wrote:
> On Mon, Nov 21, 2016 at 07:59:51PM +, Daniel Stone wrote:
> > Hi Varad,
> >
> > On 21 November 2016 at 10:17, Varad Gautam wrote:
> > > advertise the supported fourcc format modifiers along with
odifier[0]. Oops. Do we need to take adjustments in wayland now
too? At elast enforcing everywhere that modifiers match is probably a good
thing, and maybe even adjusting proto extensions and internal storage to
only carry one?
-Daniel
--
Daniel Vette
right NVIDIA people signed up.
Kernel folks should be there plenty relevant for this topic (me included),
and I think some google cros folks will show up too. There's even going to
be a presentation about google's drm_hwcomposer. I think mostly you need
to make sure nvidia folks show
some questions about what organizing XDC entails,
please feel free to chat with a previous organizers, or with someone from
the board.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Just a quick comment: I guess a piglit testcase to demonstrate the failure
(or well, just any minimal test) would be awesome. That way folks can
quickly figure out what all goes wrong without this.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
e display hw" like the drm master, I think this is not fixable.
At least not just in userspace. Also even with native KMS compositors
fbdev still doesn't have the concept of ownership, which is why it doesn't
bother clearing it's buffer before KMS takes over. I agree that this
sh
On Mon, May 16, 2016 at 11:12:35AM -0700, James Jones wrote:
> On 05/16/2016 02:36 AM, Daniel Vetter wrote:
> >On Sat, May 14, 2016 at 05:46:51PM +0100, Daniel Stone wrote:
> >>On 12 May 2016 at 00:08, James Jones wrote:
> >>>The EGLStream encapsulation takes into c
ch everything in the world about EGLstreams (vk,
v4l, drm, ...). Which as Daniel Stone pointed out, doesn't really work
well if you have IP blocks from multiple vendors on your SoC.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_
On Tue, May 03, 2016 at 09:29:58AM -0700, James Jones wrote:
> On 05/03/2016 09:06 AM, Daniel Vetter wrote:
> >On Fri, Apr 29, 2016 at 02:16:28PM -0700, James Jones wrote:
> >>Streams could provide a way to express that the compositor picked the wrong
> >>plane, but t
ms/buffers. And once you've decided to go
the fully hidden route hw composer seems to be the best choice really.
SurfaceFlinger isn't really great for multi-screen, but the hwc interface
itself is already fixed and handles that properly. But even with hwc you
don't have eglstreams
On Thu, Mar 24, 2016 at 10:06:04AM -0700, Andy Ritger wrote:
> On Wed, Mar 23, 2016 at 11:48:01AM +0100, Daniel Vetter wrote:
> > On Tue, Mar 22, 2016 at 05:33:57PM -0700, Andy Ritger wrote:
> > > On Tue, Mar 22, 2016 at 09:52:21PM +, Daniel Stone wrote:
> > > &
On Tue, Mar 22, 2016 at 05:33:57PM -0700, Andy Ritger wrote:
> On Tue, Mar 22, 2016 at 09:52:21PM +, Daniel Stone wrote:
> > Hi,
> >
> > On 22 March 2016 at 21:43, Daniel Vetter wrote:
> > > On Tue, Mar 22, 2016 at 01:49:59PM +, Daniel Stone wrote:
> [.
bled. If your hw can do it. It's supposed to be
black in that case, and there's some pages floating around to control the
background colour (if anyone ever wants to change that ...).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Sorry.
Well the thing that irks me is that this isn't aiming to build a common
platform. There's definitely issues with gbm/gralloc+kms+egl in upstream
repos, and vendors have hacked around those in all kinds of horrible ways.
But trying to fix this mess with yet another vendor-private solution just
doesn't help. Instead we need to fix what is there, for everyone, instead
of fragmenting more.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
re event
> (e.g. softirq handler), and use that instead.
nouveau bugs iirc. Yes, should never happen, it's a bug in the kernel
driver that iirc Mario recently tracked down. nouveau somehow started the
vblank machinery before the pipe was up, or something like that.
So yeah happe
+ b->gbm = create_gbm_device(b->drm.fd);
> + if (!b->gbm) {
> + weston_log("Failed to create gbm device. "
> + "Aborting renderer switch\n");
> + return;
> + }
> }
>
about that.
Please send in your proposal to bo...@foundation.x.org latest by 28th
Oct to make sure the baord can consider it.
Thanks,
Daniel, secretary of the board
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffw
cial
cursor hack in atomic helpers to make sure any new driver gets this
right).
Reviewed-by: Daniel Vetter
> ---
> src/compositor-drm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index f
like
what mesa might internally do for partial uploads). That will also extend
to a dma-buf mmap extension where we'll add explicit begin/end_cpu_access
ioctls for cpu-side access. If you really want to talk about coherency I'd
go with:
- clients must ensure that either all data
tes there's nothing like that. But givin that max size is just
a small part of figuring out what kind of surfaces a driver supports I
don't think that's a big deal really ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwl
everything is ok.
You could also just clear the plane->crtc link and the plane's
framebuffer and that's enough to disable a plane. Should be a lot
simpler than adding rollback support to libdrm.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - htt
In
commit f02ad907cd9e7fe3a6405d2d005840912f1ed258
Author: Daniel Vetter
Date: Thu Jan 22 16:36:23 2015 +0100
drm/atomic-helpers: Recover full cursor plane behaviour
we've added a hack to atomic helpers to never to vblank waits for
cursor updates through the legacy apis since that&#
On Wed, May 20, 2015 at 10:23:19AM +0300, Pekka Paalanen wrote:
> On Wed, 20 May 2015 09:04:52 +0200
> Daniel Vetter wrote:
>
> > On Mon, May 18, 2015 at 10:10:27PM -0400, nerdopolis wrote:
> > > Hardware cursors have been causing some problems with some drivers,
> &g
ing instead. */
> + ec->cursors_are_broken = 1;
>
> return 0;
> }
> --
> 2.1.0
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://l
On Tue, Jan 20, 2015 at 10:31:52AM +0200, Pekka Paalanen wrote:
> On Tue, 20 Jan 2015 07:41:52 +0100
> Daniel Vetter wrote:
>
> > On Thu, Jan 08, 2015 at 02:26:00PM +0200, Pekka Paalanen wrote:
> > > On Mon, 5 Jan 2015 11:44:49 +0100
> > > Daniel Vetter wrote:
On Thu, Jan 08, 2015 at 02:26:00PM +0200, Pekka Paalanen wrote:
> On Mon, 5 Jan 2015 11:44:49 +0100
> Daniel Vetter wrote:
>
> > On Thu, Dec 18, 2014 at 01:45:22PM +0200, Pekka Paalanen wrote:
> > > On Thu, 18 Dec 2014 10:25:09 +0100
> > > Daniel Vetter wro
On Thu, Dec 18, 2014 at 01:45:22PM +0200, Pekka Paalanen wrote:
> On Thu, 18 Dec 2014 10:25:09 +0100
> Daniel Vetter wrote:
>
> > On Fri, Dec 12, 2014 at 04:51:02PM -0500, Louis-Francis
> > Ratté-Boulianne wrote:
> > > From: Pekka Paalanen
> > >
>
-planar formats may require using more than one
> +dmabuf for passing all the data for one logical buffer.
> +This request adds one dmabuf to the set in this dmabuf_batch.
> +
> +When one dmabuf has several planar channels, offset1 & stride1
> and
> +
his and fix in a follow-up patch, that's
> > > probably ok,
> >
> > That would be great.
> >
> > > but let's make sure one is coming.
> >
> > Alvaro, do you want to send a follow-up patch addressing the issue Jason
> > described ab
(shm_buffer);
> > +
> > + ps->image = pixman_image_create_bits(pixman_format,
> > + buffer->width, buffer->height,
> > + wl_shm_buffer_get_data(shm_buffer),
> > + wl_shm_buffer_get_stride(shm_buffer));
> > }
> >
> > - buffer->shm_buffer = shm_buffer;
> > - buffer->width = wl_shm_buffer_get_width(shm_buffer);
> > - buffer->height = wl_shm_buffer_get_height(shm_buffer);
> > + if (dmabuf_buffer) {
> > + void *data;
> > + switch (wl_dmabuf_buffer_get_format(dmabuf_buffer)) {
> > + case WL_DMABUF_FORMAT_XRGB:
> > + pixman_format = PIXMAN_x8r8g8b8;
> > + break;
> > + case WL_DMABUF_FORMAT_ARGB:
> > + pixman_format = PIXMAN_a8r8g8b8;
> > + break;
> > + case WL_DMABUF_FORMAT_RGB565:
> > + pixman_format = PIXMAN_r5g6b5;
> > + break;
> > + default:
> > + weston_log("Unsupported DMABUF buffer format\n");
> > + weston_buffer_reference(&ps->buffer_ref, NULL);
> > + return;
> > + break;
> > + }
> >
> > - ps->image = pixman_image_create_bits(pixman_format,
> > - buffer->width, buffer->height,
> > - wl_shm_buffer_get_data(shm_buffer),
> > - wl_shm_buffer_get_stride(shm_buffer));
> > + buffer->dmabuf_buffer = dmabuf_buffer;
> > + buffer->width = wl_dmabuf_buffer_get_width(dmabuf_buffer);
> > + buffer->height = wl_dmabuf_buffer_get_height(dmabuf_buffer);
> > +
> > + data = wl_dmabuf_buffer_get_data(dmabuf_buffer);
> > + if (data) {
> > + ps->image = pixman_image_create_bits(pixman_format,
> > + buffer->width, buffer->height, data,
> > + wl_dmabuf_buffer_get_stride(dmabuf_buffer));
> > +
> > + pixman_image_set_destroy_function(ps->image,
> > wl_dmabuf_pixman_destroy, dmabuf_buffer);
> > + } else
> > + weston_log("failed to get data from dmabuf buffer");
> > + }
> > }
> >
> > static int
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
_YUV420 = 0x32315559,
> + WL_DMABUF_FORMAT_YVU420 = 0x32315659,
> + WL_DMABUF_FORMAT_YUV422 = 0x36315559,
> + WL_DMABUF_FORMAT_YVU422 = 0x36315659,
> + WL_DMABUF_FORMAT_YUV444 = 0x34325559,
> + WL_DMABUF_FORMAT_YVU444 = 0x34325659,
> +};
> +#endif /* WL_DMABUF_FORMAT_ENUM */
> +
> +struct wl_dmabuf;
> +
> +struct wl_dmabuf_buffer {
> + struct wl_resource *resource;
> + struct wl_dmabuf *dmabuf;
> + int32_t width, height;
> + int32_t stride;
> + uint32_t format;
> + uint8_t *data;
> + int mmapcount;
> + int refcount;
> + int fd;
> +};
> +
> +/* struct wl_dmabuf_callbacks
> + *
> + * @send_server_info: ask to the server to send all
> + * supported pixel formats and device name
> + */
> +struct wl_dmabuf_callbacks {
> + void (*send_server_info)(void *user_data, struct wl_resource *resource);
> +};
> +
> +struct wl_dmabuf *
> +wl_dmabuf_init(struct wl_display *display,
> + struct wl_dmabuf_callbacks *callbacks,
> + void *user_data, uint32_t flags);
> +
> +void
> +wl_dmabuf_uninit(struct wl_dmabuf *dmabuf);
> +
> +struct wl_dmabuf_buffer *
> +wl_dmabuf_buffer_get(struct wl_resource *resource);
> +
> +uint32_t
> +wl_dmabuf_buffer_get_format(struct wl_dmabuf_buffer *buffer);
> +
> +int32_t
> +wl_dmabuf_buffer_get_stride(struct wl_dmabuf_buffer *buffer);
> +
> +void *
> +wl_dmabuf_buffer_get_data(struct wl_dmabuf_buffer *buffer);
> +
> +void
> +wl_dmabuf_buffer_put_data(struct wl_dmabuf_buffer *buffer);
> +
> +int32_t
> +wl_dmabuf_buffer_get_width(struct wl_dmabuf_buffer *buffer);
> +
> +int32_t
> +wl_dmabuf_buffer_get_height(struct wl_dmabuf_buffer *buffer);
> +
> +#endif
> --
> 1.7.9.5
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
1 - 100 of 104 matches
Mail list logo
