Hi,
On Thu, 15 May 2025 at 19:02, Harry Wentland wrote:
> On 2025-05-15 13:19, Daniel Stone wrote:
> > Yeah, the Weston patches are marching on. We've still been doing a
> > little bit of cleanup and prep work in the background to land them,
> > but we also can't l
PI though: as said previously, the uAPI looks
completely solid and it's something we can definitely beneficially use
in Weston. (Even if we do need the obvious follow-ons for
post-blending as well ...)
Cheers,
Daniel
Hi Harry,
On Tue, 8 Apr 2025 at 18:30, Harry Wentland wrote:
> On 2025-04-08 12:40, Daniel Stone wrote:
> > OK, Harry's reply cleared that up perfectly - the flexibility that's
> > there at the moment is about being able to reuse colorops for CRTCs in
> > post
Hi there,
On Tue, 1 Apr 2025 at 20:53, Simon Ser wrote:
> On Tuesday, April 1st, 2025 at 17:14, Daniel Stone
> wrote:
> > 'plane' seems really incongruous here. The colorop can be created for
> > any number of planes, but we're setting it to always be bound t
/or igt.)
Either way, I suspect that clorop->plane is the wrong thing to do, and
that it maybe wants to be a list of planes in the drm_colorop_state?
Cheers,
Daniel
istro LLVM development packages which aren't
present in a clean distro install.
You're completely right though that it makes no difference to the
dependency chain whether the dependencies come from Meson subprojects
or previous installs though.
Cheers,
Daniel
sy subproject build turn into, well, a
full distribution?
I guess one thing we could do is to jazz the CI build up a little so
it's easier to pull the OCI and run it inside a toolbox, as well as
reuse those scripts locally.
Cheers,
Daniel
endencies in a local
prefix.
This might give you some insight however:
https://github.com/containers/toolbox/issues/992
It probably needs some minor changes in Weston but does at least seem doable ...
Cheers,
Daniel
| 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
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
pgrade to Weston 12/13 fixes it - we can just ask
people to upgrade to a fixed Weston.
> > Presuming this is not related to any TI specific code, I guess it's a
> > regression in the sense that at some point Weston added the support to use
> > planes for composition, so previously with only a single plane per display
> > there was no issue.
That point was 12 years ago, so not that novel. ;)
Cheers,
Daniel
transient seat protocol
Daniel Stone (1):
build: Bump version to 1.33
Jonas Ådahl (1):
xdg-shell: Clarify what a toplevel by default includes
Lleyton Gray (1):
staging/drm-lease: fix typo in description
MaxVerevkin (1):
linux-dmabuf: sync changes from unstable to stable
pos’ README and CONTRIBUTING files, but
> didn’t find anything.
https://discourse.gnome.org is probably your best bet there.
Cheers,
Daniel
to take advantage of it in the app code? (ie. run fullscreen?)
No need. We bypass composition as much as we possibly can. You can try
using weston-simple-egl with the flag to use direct-display if you
want to satisfy yourself, but it's in no way required to bypass GPU
composition and use the display controller to scan out.
Cheers,
Daniel
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
well, by telling all
applications to be fullscreen.
Cheers,
Daniel
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,
if the patch is available for the community to use.
>
The current resolution is provided as an event on the wl_output interfaces.
>From the command line, you can get this from wayland-info.
Cheers,
Daniel
urrently mirror it if the display driver directly supports it.
You can use the same-as configuration option (see man weston-drm) to enable
this. If your display driver doesn't support this in the kernel, then
Weston won't do it for now, but we are actively working on this and expect
to have a branch capable of this within the next couple of weeks or so.
Cheers,
Daniel
0.0, as long as you
also pull the other dependencies from OE such as libseat and probably a
newer version of Meson.
Cheers,
Daniel
Hi Joe,
On Wed, 14 Jun 2023 at 21:33, Joe M wrote:
> Thanks Daniel. Do you know if wl_output instances are decoupled from each
> other, when it comes to display refresh?
>
Yep, absolutely.
> The wl_output geometry info hints that each output can be thought of as a
> reg
consequential thing is that a wl_display really
just represents a connection to a Wayland server (aka compositor).
Display targets (e.g. 'the HDMI connector on the left', 'the DSI panel')
are represented by wl_output objects. There is one of those for each output.
Cheers,
Daniel
On Thu, 8 Jun 2023 at 16:54, Martin Petzold wrote:
> Am 08.06.23 um 16:58 schrieb Daniel Stone:
>
> On Thu, 8 Jun 2023 at 14:28, Pekka Paalanen wrote:
>
>> On Thu, 8 Jun 2023 14:49:37 +0200
>> Martin Petzold wrote:
>> > btw. we are using a Weston 9
ditch the NXP BSP and just use a vanilla Yocto
build for your machine. This will have upstream Weston which should solve
your problem.
Cheers,
Daniel
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
ke Laurent to ack the graph node infrastructure to make sure
we're missing any lesson they've learned already. If there's anything
else we should pull these folks in too ofc.
For merge plan I dropped some ideas already on Harry's rfc for
vendor-private properties, the only
Hi Daniel,
On Fri, 10 Mar 2023 at 14:28, Levin, Daniel wrote:
> We are currently attempting to update from Weston 9.0.0 to Weston 10+ and
> facing issues with GLES2 compatibility at both build time and run time.
>
> For instance, gl_renderer_setup() exits with error if GL_EXT_unp
that is the correct approach, or it might cause issues.
And instead we have to downgrade all the Wayland components to the same older
version (in our case: client 1.19, protocols 1.21, weston 9.0.0).
Thanks,
Daniel
ere on i.MX devices. If you're using a
downstream kernel/GLES/Weston/etc from NXP, then I'm afraid you need
to contact them for support.
Cheers,
Daniel
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:
> > >
s like the more consistent way to integrate this
feature. Which doesn't mean it has to happen like that, but the
patches/cover letter should at least explain why we don't do it like this.
-Daniel
>
> Changes in V3:
> - Fixed some logic errors in atomic checks (Dmitry)
> - Intro
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
> to output-power-management [1]), so that a single tool can work for
> multiple compositors.
Yeah, I mean, as one of the main people arguing that non-fully-integrated
desktops are not the design we want, I agree with Simon.
Cheers,
Daniel
pay the favour by investing some of your time
and effort to understand Wayland before proposing drastic changes to
it and demanding the developers justify why they won't be accepted.
Cheers,
Daniel
giving the entire
ecosystem more power. It takes more work to achieve than just blindly
taking the shortest possible path, but conversely it also saves us
from being painted into the same corners that made X11 no longer
viable.
Cheers,
Daniel
ontinuing to repeat the same thing over and over
without listening to anything else being said, your posts will now be
moderated.
Cheers,
Daniel
On Fri, 5 Aug 2022 at 17:21, Igor Korot wrote:
> On Thu, Aug 4, 2022 at 9:20 PM Thiago Macieira wrote:
> > No, they are about position too. 100,100 on a 1920x1080 resolution is about
> > 5%
> > to the right of the left edge and 10% from the top. 100,100 on 3840x2160 is
> > 2.5% from the left and
ry client
save their last-seen position and forcibly restore it no matter what.
Cheers,
Daniel
se
contribute to the development of those protocols in an issue on
https://gitlab.freedesktop.org/wayland/wayland-protocols/. If you want
to discuss whether Wayland's fundamental design concepts are or aren't
a good idea, or whether Windows is bad, please take that discussion to
Hacker News or Reddit or something.
Cheers,
Daniel
he n'th attempt. But a better
one would allow you to inspect the properties on each object in the
atomic state, and also things like framebuffer attributes (dimensions,
format, modifier, etc) so you could take action accordingly.
Thanks for taking this on! Really looking forward to it.
Cheers,
Daniel
27;is cursor' plane prop which userspace has to set to 1 to indicate
that the output is a cursor and has the hotspot correctly set and the
'display hardware' is free to make the cursor fly around the screen in
accordance with the input events it sends? That way it's really really
clear what's happening and no-one's getting surprised when 'the right
thing' doesn't happen, not least because it's really clear what 'the
right thing' is.
Cheers,
Daniel
Hi,
On Mon, 13 Jun 2022 at 08:39, Daniel Stone wrote:
> Yes, that's what's happening. Our (multi-host-replicated etc) Ceph
> storage setup has entered a degraded mode due to the loss of a couple
> of disks - no data has been lost but the cluster is currently unhappy.
>
but the cluster is currently unhappy.
We're walking through fixing this, but have bumped into some other
issues since, including a newly-flaky network setup, and changes since
we last provisioned a new storage host.
We're working through them one by one and will have the service back
up with all our data intact - hopefully in a matter of hours but we
have no firm ETA right now.
Cheers,
Daniel
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
nd debt (all these properties
predate the push to document stuff so we need to fix that), but I don't
think it's too much. And I think, from reading the threads, that this
should cover everything?
Anything I've missed? Or got completely wrong?
Cheers, Daniel
On Fri, Jun 03, 20
g? I don't understand how the root
meson.build could cause Meson to not be able to parse.
Cheese,
Daniel
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:
> >
il the right backlight shows up. And that needs to be behind a
Kconfig to avoid breaking existing systems.
Inflicting hotplug complications on all userspace (including uevent
handling for this hotpluggable backlight and everything) just because
fixing the old crap systems is work is imo really n
f brightness_max to avoid accidentally turning the screen off.
> >
> > Turning the screen off is quite bad to do on e.g. tablets where
> > the GUI is the only way to undo the brightness change and now
> > the user can no longer see the GUI.
> >
> > T
.g. NXP), they may have
substantially forked and changed Weston. In most cases, these bugs are
introduced by the vendor changes. If this is the case, please seek
support from your vendor, as unfortunately we can't support those
changes.
Cheers,
Daniel
_FORMAT_XRGB, given that we should be getting that through
fallback_format_for()?
- your EGL stack is buggy, because it declares a 8880 format (i.e.
XRGB) to be ARGB, so fixing that would likely solve the
immediate problem, but the fallbacks above should work
Best of luck.
Cheers,
Daniel
Hi Guillermo,
On Fri, 6 Aug 2021 at 10:44, Guillermo Rodriguez Garcia
wrote:
> El vie, 6 ago 2021 a las 10:14, Daniel Stone ()
> escribió:
>> kiosk-shell is something we have in newer versions of Weston which
>> sounds like it would work well for your usecases - it's de
ation patches never got merged because we had some issues with
the IIO integration in particular, but having runtime rotation tests
sure would be nice, and kiosk-shell should at least be a lot easier to
fix than desktop-shell, if it does even need any fixes.
Cheers,
Daniel
bar is the wrong length and my background is black. Other
> than that, pretty cool.
>
Yep, desktop-shell isn't designed to handle runtime rotation. It could be
made to pretty easily by working on the client code. For your case though
I'd assume something like kiosk-shell would be a much better bet.
Cheers,
Daniel
rotocols, not arbitrary clients.
Implementing a proxy just shifts this problem rather than solving it
once; every time someone adds a new protocol, you have to plumb it
through the proxy and add some kind of policy mechanism. But the
compositors themselves probably have their own policy mechanism,
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
ght’ and
flattened whenever modified? Something else?
Have a great weekend.
-d
> On 18 Jun 2021, at 5: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
>>
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
On Thu, Jun 17, 2021 at 09:37:36AM +0200, Christian König wrote:
> Am 16.06.21 um 20:30 schrieb Jason Ekstrand:
> > On Tue, Jun 15, 2021 at 3:41 AM Christian König
> > wrote:
> > > Hi Jason & Daniel,
> > >
> > > maybe I should explain once more whe
needs
> code modification?)
>
You should instead configure this through weston.ini, for example:
[output]
name=HDMI-A-1
mode=1920x1080
[output]
name=eDP-1
mode=off
You can find more details with 'man weston.ini'.
Cheers,
Daniel
___
should be attached to. It then handles those windows in a
completely consistent and uniform way between all your applications,
including positioning, stacking, and focus.
So, just use that. It works. :)
Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Hi all,
On Thu, 8 Apr 2021 at 12:20, Daniel Stone wrote:
> I propose that we do this for all the wayland/* repositories, either this
> weekend or next; I'm happy to make the changes (rename 'master' to 'main'
> and retarget all open MRs). Does anyone have any
Just 2 comments on the kernel aspects here.
On Tue, Apr 20, 2021 at 12:18 PM Daniel Stone wrote:
>
> Hi,
>
> On Mon, 19 Apr 2021 at 13:06, Simon Ser wrote:
>>
>> I'm working on a Wayland extension [1] that, among other things, allows
>> compositors to advert
accordingly. Thanks to the implicit device
selection performed when creating an EGLDisplay from a gbm_device, we
cannot currently discover what that device node is.
> Do you have any other potential solution in mind?
I can't think of any right now, but am open to hearing them.
> Which
On Thu, 8 Apr 2021 at 14:02, Jan Engelhardt wrote:
> On Thursday 2021-04-08 13:20, Daniel Stone wrote:
> >I propose that we do this for all the wayland/* repositories, either this
> weekend or next; I'm happy
> >to make the changes (rename 'master' to 'ma
pared a small Python
script which will retarget open MRs from 'master' to 'main'.
I propose that we do this for all the wayland/* repositories, either this
weekend or next; I'm happy to make the changes (rename 'master' to 'main'
and retarget all open MR
of a wl_display, even if it's the same server at the other
end of the connection.
Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
ction does internally:
https://wayland.freedesktop.org/docs/html/apb.html#Client-classwl__display_1a40039c1169b153269a3dc0796a54ddb0
Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
ieve OE core) carries a patch which removes PAM usage in
Weston; you might want to pick that up.
Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
7;t blank the screen. So both these issues are
something you'd need to raise with NXP support, as they are due to
NXP's changes to our code.
Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
imple" clients from Weston
> repository to there if that's appropriate.
+1 to all of the above. I'd be happy to see it in a utils and examples
repo, with at least the ones you mentioned here. I don't think
toytoolkit should ever be pushed in there, because then we run the
,
just run `git tag -l` on each of the two repositories (or `git
ls-remote --tags
https://gitlab.freedesktop.org/wayland/(wayland|weston).git`) and have
all the information you need?
Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
them for
you, but then you have additional protocols (with all the
synchronisation issues that implies) for the client and compositor to
co-ordinate rendering of the decorations and the content.
Neither is objectively better or worse, it's just a different design
whi
these issues, is to wrap the
Wayland library using the 'dispatcher' methods provided; there is more
background here: https://smithay.github.io/wayland-rs-v-0-21.html
Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
ke, however we never addressed the idea of
having multiple active applications, as it requires too many changes
in Android, such as deep changes to the Android activity manager to
deal with more than one application being current at one time.
Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
on a KMS plane (which is not guaranteed, as the driver can reject
planes for any reason or limitation), we need to be able to use the
renderer as a fallback to show the content.
Alternately, if your SoC has an Arm Mali GPU, you can use the Panfrost
driv
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
__
Just a quick reminder that both board nomination and membership
renewal periods are still opening:
- 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!)
Cheers, Daniel
On Sun, Mar 8, 2020 at 8:51 PM Daniel
ent kernel
> > support for implicit synchronisation (as everyone else has done),
> That would require major changes in driver architecture or a 2nd
> mechanisms doing the same thing but in kernel space - both are
> non-starters.
OK. As it stands, everyone else has the kernel mec
ment kernel
support for implicit synchronisation (as everyone else has done), or
implement generic support for explicit synchronisation (as we have
been working on with implementations inside Weston and Exosphere at
least), or implement private support for explicit sy
, 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
On Fri, Feb 28, 2020 at 9:31 PM Dave Airlie wrote:
>
> On Sat, 29 Feb 2020 at 05:34, Eric Anholt wrote:
> >
> > On Fri, Feb 28, 2020 at 12:48 AM Dave Airlie wrote:
> > >
> > > On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote:
> > > >
> >
Hi Jan,
On Fri, 28 Feb 2020 at 10:09, Jan Engelhardt wrote:
> On Friday 2020-02-28 08:59, Daniel Stone wrote:
> >I believe that in January, we had $2082 of network cost (almost
> >entirely egress; ingress is basically free) and $1750 of
> >cloud-storage cost (almost all
1 - 100 of 2285 matches
Mail list logo
