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
> > they can swit
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
e 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 mailing list
dri-devel@lis
Hi,
On Fri, 2 Oct 2020 at 08:31, Kristian Kristensen wrote:
> On Fri, Oct 2, 2020 at 8:14 AM Dave Airlie wrote:
>> My feeling is the pieces that would benefit the most are the things
>> touch the real world, GLSL compiler, SPIR-V handling, maybe some of
>> the GL API space, but I also feel
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
Cheers,
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
Cheers,
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 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 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 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
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
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
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
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
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
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
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
"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 consistency we shoul
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
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
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
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
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
Hi,
On Mon, 3 Aug 2020 at 17:16, Jason Ekstrand wrote:
> On Mon, Aug 3, 2020 at 11:12 AM Kenneth Graunke wrote:
> > Seems reasonable to me...in the old Subversion days, we called it
> > 'trunk'...then 'master' with Git...but calling the main development
> > branch 'main' is arguably the
Hi,
On Sat, 1 Aug 2020 at 06:28, Vadivelu Babu, Surendar (S.)
wrote:
> As Arun stated , we tried to boot the Weston application from initramfs ,
> however there is “pam” library dependency which is required for Weston . When
> we include all the “pam” libraries the initramfs size increases
Hi Arunkumar,
On Mon, 27 Jul 2020 at 06:59, arunkrish20 wrote:
> We are working with the i.MX8 platform. We are working with weston and DRM
> backend. Below are the version details.
>
> NXP BSP Version: 4.14.98_2.0.0_ga
> SC Firmware Version : 1.3.1
> wayland version 1.16 am
> weston- ivi -
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
> &
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
> &
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
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
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
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
Hi,
On Thu, 9 Jul 2020 at 15:38, Pekka Paalanen wrote:
> On Thu, 9 Jul 2020 10:32:56 +0200
> Olivier Fourdan wrote:
> > In the meantime, Peter has already submitted patches to wayland-info
> > (thanks Peter!) so the tip of wayland-info is different from
> > weston-info (basically, we have
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 once
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 once
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 once
icitly
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 amdkfd eviction fences for long run
icitly
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 amdkfd eviction fences for long run
icitly
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 amdkfd eviction fences for long run
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?
>
>
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?
>
>
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?
>
>
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,
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,
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,
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, 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 {
>
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 {
>
Hi,
On Wed, 1 Jul 2020 at 20:13, Simon Ser wrote:
> On Wednesday, July 1, 2020 8:49 PM, Jan Engelhardt wrote:
> > Usecases.. checking for releases, both new and, sometimes historic research,
> > old ones.
> >
> > A fileindex has a "tabular" appearance where each "row" contains filename
> > and
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
Hi,
On Thu, 25 Jun 2020 at 10:01, Brad Robinson
wrote:
> As a toolkit developer coming from Windows/OSX this is fairly shocking. I'm
> aware of the decoration protocol, but given it's not supported (and by the
> sound of it never will be) on some of the major distros makes it almost
>
Hi,
On Thu, 18 Jun 2020 at 07:25, Brad Robinson
wrote:
> I'm putting together a set of C# bindings for Wayland and it's coming along
> nicely but I've hit an issue with wl_registry_bind where its implementation
> doesn't seem to match the xml.
>
> The wayland.xml file declares it as:
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
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
Hi,
On Fri, 29 May 2020 at 10:08, Erik Faye-Lund
wrote:
> In the light of the explanation above, do you still have objections to
> this split?
>
> Obviously, we haven't moved forward yet ;-)
Well, we have now after getting some agreement. Please enjoy your
shiny new https://www.mesa3d.org and
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
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
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
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
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
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
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 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 through a lo
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
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
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 magic
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 magic
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
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
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 give
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 give
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
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
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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
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
Hi,
I'm generally ambivalent on which day it moves, though depending on
how late in the day it comes out, it might not actually be Thursday -
if the release comes out late at night, I'm more likely to finish up
the migration over the weekend.
On Wed, 13 May 2020 at 13:43, Brian Paul wrote:
> On
Hi Brian,
On Fri, 8 May 2020 at 15:30, Brian Paul wrote:
> Done. easydns says it may take up to 3 hours to go into effect.
Thanks for doing this! Could you please add the following TXT records
as well (note that they're FQDN, so you might want to chop the
trailing '.mesa3d.org' from the first
Hi,
On Thu, 7 May 2020 at 18:08, Erik Faye-Lund
wrote:
> On Thu, 2020-05-07 at 11:03 -0600, Brian Paul wrote:
> > It seems like only the front page is served at the moment. Is it
> > possible to get a look at the rest? The front page looks nice.
>
> Yeah, we need to set up docs.mesa3d.org
Hi,
On Mon, 27 Apr 2020 at 10:02, Pekka Paalanen wrote:
> On Mon, 27 Apr 2020 15:07:20 +0800 zou lan wrote:
> > I read some documents about chrome OS run Android Apks such as
> > https://qiangbo-workspace.oss-cn-shanghai.aliyuncs.com/2019-09-10-chromeos-with-android-app/Arcpp_Graphics.pdf
> >
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 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
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)
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
>
> 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 Oliver,
On Wed, 25 Mar 2020 at 10:31, Wohlmuth, Oliver
wrote:
> I just started to work with Wayland/Weston, so please forgive me if I ask
> silly questions.
>
> I’m running Weston (8.0.0) on a custom ARM SoC using the DRM backend. As the
> OpenGL
> driver is not (yet) adapted for Wayland,
Hi,
On Tue, 25 Feb 2020 at 23:42, Kristian Høgsberg wrote:
> It's been a while since Dylan did the work to make meson support
> Windows and there's been plenty of time to provide feedback or improve
> argue why we still need scons. I haven't seen any such discussion and
> I think we've waited
Hi Tomek,
On Mon, 16 Mar 2020 at 12:55, Tomek Bury wrote:
> I've been wrestling with the sync problems in Wayland some time ago, but only
> with regards to 3D drivers.
>
> The guarantee given by the GL/GLES spec is limited to a single graphics
> context. If the same buffer is accessed by 2
Hi,
On Mon, 16 Mar 2020 at 15:33, Tomek Bury wrote:
> > GL and GLES are not relevant. What is relevant is EGL, which defines
> > interfaces to make things work on the native platform.
> Yes and no. This is what EGL spec says about sharing a texture between
> contexts:
Contexts are different
Hi,
On Mon, 16 Mar 2020 at 15:33, Tomek Bury wrote:
> > GL and GLES are not relevant. What is relevant is EGL, which defines
> > interfaces to make things work on the native platform.
> Yes and no. This is what EGL spec says about sharing a texture between
> contexts:
Contexts are different
Hi,
On Mon, 16 Mar 2020 at 15:33, Tomek Bury wrote:
> > GL and GLES are not relevant. What is relevant is EGL, which defines
> > interfaces to make things work on the native platform.
> Yes and no. This is what EGL spec says about sharing a texture between
> contexts:
Contexts are different
Hi,
On Mon, 16 Mar 2020 at 15:33, Tomek Bury wrote:
> > GL and GLES are not relevant. What is relevant is EGL, which defines
> > interfaces to make things work on the native platform.
> Yes and no. This is what EGL spec says about sharing a texture between
> contexts:
Contexts are different
Hi Tomek,
On Mon, 16 Mar 2020 at 12:55, Tomek Bury wrote:
> I've been wrestling with the sync problems in Wayland some time ago, but only
> with regards to 3D drivers.
>
> The guarantee given by the GL/GLES spec is limited to a single graphics
> context. If the same buffer is accessed by 2
Hi Tomek,
On Mon, 16 Mar 2020 at 12:55, Tomek Bury wrote:
> I've been wrestling with the sync problems in Wayland some time ago, but only
> with regards to 3D drivers.
>
> The guarantee given by the GL/GLES spec is limited to a single graphics
> context. If the same buffer is accessed by 2
Hi Tomek,
On Mon, 16 Mar 2020 at 12:55, Tomek Bury wrote:
> I've been wrestling with the sync problems in Wayland some time ago, but only
> with regards to 3D drivers.
>
> The guarantee given by the GL/GLES spec is limited to a single graphics
> context. If the same buffer is accessed by 2
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
On Fri, 28 Feb 2020 at 09:40, Marek Szyprowski wrote:
> Signed-off-by: Marek Szyprowski
Reviewed-by: Daniel Stone
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
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
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
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
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
301 - 400 of 9465 matches
Mail list logo
