On 2025-04-01 14:32, Shengyu Qu wrote:
> 在 2025/4/1 17:56, Michel Dänzer 写道:
>> On 2025-03-31 19:42, Alex Hung wrote:
>>> On 3/31/25 11:04, Shengyu Qu wrote:
>>>> Or we can add some kind of "linked with" info to plane's COLOR_PIPELINE
>>>&
plane, or at least provide proper "no color
pipeline" behaviour for it. Letting the effective behaviour be determined by
the other planes which happen to be behind the cursor plane isn't usable for
Wayland compositors.
--
Earthling Michel Dänzer \GNOME / Xwayland / Mesa developer
https://redhat.com \ Libre software enthusiast
On 2024-04-29 23:38, Bruce Steers wrote:
>
> There is worry in our community that Wayland is going to take over and x11
> will become obsolete.
There's no need to worry about that. X clients will keep working in a Wayland
session via Xwayland.
--
Earthling
ng
> older X11/GL applications this way compared to simply running: ssh -X
> owner@172.28.0.179?
It makes no difference whatsoever, since Waypipe isn't involved in any way with
X clients.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
wing process
> get created:
glxgears doesn't have anything to do with Waypipe. This is probably just
missing the ssh -Y/-X option to enable SSH X forwarding.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
On 11/13/23 10:47, Simon Ser wrote:
> On Monday, November 13th, 2023 at 10:41, Michel Dänzer
> wrote:
>
>> On 11/13/23 10:18, Simon Ser wrote:
>>
>>> On Monday, October 23rd, 2023 at 10:25, Simon Ser cont...@emersion.fr wrote:
>>>
>&g
g any prop = same value as
>> previous one will result in a new page-flip for asynchronous page-flips,
>> but will not result in any side-effect for asynchronous page-flips.
>>
>> Does it actually matter though? For async page-flips, I don't think this
>> would result in any actual difference in behavior?
>
> To sum this up, here is a matrix of behavior as seen by user-space:
>
> - Sync atomic page-flip
> - Set FB_ID to different value: programs hw for page-flip, sends uevent
> - Set FB_ID to same value: same (important for VRR)
> - Set another plane prop to same value: same
A page flip is programmed even if FB_ID isn't touched?
> - Set another plane prop to different value: maybe rejected if modeset
> required
> - Async atomic page-flip
> - Set FB_ID to different value: updates hw with new FB address, sends
> immediate uevent
> - Set FB_ID to same value: same (no-op for the hw)
No-op implies it doesn't trigger scanning out a frame with VRR, if scanout is
currently in vertical blank. Is that the case? If so, async flips can't
reliably trigger scanning out a frame with VRR.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
at all would be overkill, since it would mean you can't use the
> preblending
> scaler or tonemapper, and animation isn't necessary for that.
>
> The AMD 3DLUT is another example of a LUT that is slow to update, and it would
> obviously be a
esktop.org/freedesktop/freedesktop/-/wikis/home#warning-restrictions-due-to-spam-warning
?
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
On 8/21/23 22:02, André Almeida wrote:
> Em 17/08/2023 07:37, Michel Dänzer escreveu:
>> On 8/15/23 20:57, André Almeida wrote:
>>> From: Pekka Paalanen
>>>
>>> Specify how the atomic state is maintained between userspace and
>>> kernel, plus the spe
On 8/17/23 12:37, Michel Dänzer wrote:
> On 8/15/23 20:57, André Almeida wrote:
>> From: Pekka Paalanen
>>
>> Specify how the atomic state is maintained between userspace and
>> kernel, plus the special case for async flips.
>>
>> Signed-off-by: Pekka Pa
effect with VRR: It could trigger scanout of
the next frame before vertical blank has reached its maximum duration. Some
kind of mechanism is required for this in order to allow user space to perform
low frame rate compensation.
--
Earthling Michel Dänzer| https://red
ugh that first page-flip is not
>> + * asynchronous.
>
> What would happen if one commits another async KMS update before the
> first page flip? Does one receive EAGAIN, does it amend the previous
> commit?
Should be the former. DRM_MODE_PAGE_FLIP_ASYNC just me
;>> Maybe check what xrandr says while you have no displays connected? That
>>> might give a clue, assuming the Java stack listens to RandR.
>>>
>>
> Interesting: It changes from XWAYLAND0 to XWAYLAND1 to XWAYLAND2 [...]
FWIW, the RandR ou
Note that this involves
some Wayland state management challenges for correct operation in all cases
though.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
would look right to an end user.
There's https://gitlab.freedesktop.org/wayland/wayland/-/issues/266 about this.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
> from the other simple demos?
And from the corresponding glxinfo / vulkaninfo & friends, which don't
have their own repositories either. The only exception that comes to
mind offhand is xdpyinfo, but that's just because every single app got
its own repository w
ered jobs don't exist at all in the pipeline, so they can't
be triggered by any means. :)
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> pre-merge CI.
Thanks for the suggestion! I implemented something like this for Mesa:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432
--
Earth
t;
> Implicit sync really means that apps and compositors don't sync, so
> the driver has to guess when it should sync.
Making implicit sync work correctly is ultimately the kernel driver's
responsibility. It sounds like radeonsi is having to work around the
amdgpu/radeon kern
isn't enough with amdgpu)
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.fr
On 2020-03-16 7:33 p.m., Marek Olšák wrote:
> On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer wrote:
>> On 2020-03-16 4:50 a.m., Marek Olšák wrote:
>>> The synchronization works because the Mesa driver waits for idle (drains
>>> the GFX pipeline) at the end of command
.
Not sure what difference it would make, since the same thing needs to be
done for explicit fences as well, doesn't it?
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
__
be only triggered manually instead of automatically on every push.
That would again break Marge Bot.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
which is somewhat more robust:
>> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2569
>
> I'm not sure it's more robust, but yeah that a useful tool too.
>
> The reason I'm skeptical about the robustness is that we'll miss
> testing if this misses
an one which is already caught earlier.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://
On 2019-03-08 9:41 a.m., Graeme Gill wrote:
> Michel Dänzer wrote:
>
>> It was never reliable for that. Other clients using any of those
>> mechanisms could always interfere, at least for the RandR compatibility
>> output.
>
> I disagree. It was reliable in the se
On 2019-03-07 10:07 p.m., Graeme Gill wrote:
> Michel Dänzer wrote:
>
>> Yep. The alternative is that the different mechanisms clobber the
>> hardware LUT from each other, which sucks from a user POV.
>
> Which user though ?
>
> It certainly does the opposite o
On 2019-03-07 1:43 p.m., Kai-Uwe wrote:
> Am 07.03.19 um 11:15 schrieb Michel Dänzer:
>> On 2019-03-07 8:05 a.m., Chris Murphy wrote:
>>> On Wed, Mar 6, 2019 at 10:02 PM Graeme Gill wrote:
>>>> [ And why should Linux/Wayland be crippled compared to
>>>&
and
> characterization. In particular if I have 2, 3 or even 4 displays
> connected I'd want to calibrate them in sequence while the others are
> being used for useful tasks.
It sounds like KMS leases could be a pretty good fit for a calibration
application. It can lease each output individu
On 2019-03-07 5:38 a.m., Graeme Gill wrote:
> Michel Dänzer wrote:
>> As of xserver 1.19, if the Xorg driver calls xf86HandleColormaps(), all
>> relevant mappings (colormap, global gamma, xf86VidMode per-X-screen
>> ramp, RandR per-CRTC ramp) are composed, and the result
-screen
ramp, RandR per-CRTC ramp) are composed, and the result is applied to
the hardware LUT for all CRTCs.
(A bug snuck into 1.19 which resulted in the composed mapping being
incorrect for the RandR compatibility output between setting the global
gamma value and setting the RandR per-CRTC ramp.
enough address
> space free to do that.
FWIW, /dev/dri/* files are supposed to be always opened with O_CLOEXEC,
to prevent the file descriptors from leaking to children. There were
bugs in libdrm meaning this didn't always happen, but those are fixed in
current upstream.
--
Earthling Mich
say why fps decreases, but the
> order of sending event first and updating the timestamp later does
> sound wrong to me.
Yes, drm_handle_vblank must be called before drm_crtc_send_vblank_event,
otherwise it's not surprising that the timestamp in the event is wrong. :)
--
Earthlin
On 2018-04-13 11:43 AM, Daniel Stone wrote:
> On 13 April 2018 at 10:17, Michel Dänzer wrote:
>
>> Also, both higher-level APIs I know of which allow the application to
>> specify a target timestamp for presentation (VDPAU and
>> VK_GOOGLE_display_timing) use "not
quot;not before" semantics. So, maybe the
not_before flag can be dropped, and flags can be added later for
different semantics, if a need for them ever materializes.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
oseconds"/>
>
> I wonder if people would find use for MSC counter in this event? Roman
> Gilg for Xwayland/Present perhaps?
Yes, that would be useful, since PresentCompleteNotify events always
include an MSC value.
--
Earthling Michel Dänzer | http:
oved.
>
> Signed-off-by: Peter Hutterer
> Reported-by: Michel Dänzer
> ---
> meson.build | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meson.build b/meson.build
> index e77f7d13..e122dd97 100644
> --- a/meson.build
> +++ b/meson.buil
is work for Valve, not AMD.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
signature.asc
Description: OpenPGP digital signature
___
wayland-devel mai
e X11 Present extension specification already
includes support for specifying a target time instead of a target
refresh cycle. This isn't implemented yet though, but it should be
relatively straightforward to implement using the kind of kernel API you
describe.
--
Earthling Michel Dänz
e Wayland compositor
directly uses the KMS API of /dev/dri/card*, but it may be possible if
the Wayland compositor uses the fbdev API of /dev/fb* instead (e.g. if
weston uses its fbdev backend).
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthus
void reaching the maximum number of clients prematurely.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=91072
>
> Reported-and-tested-by: Olivier Fourdan
> Signed-off-by: Chris Wilson
With the above fixed,
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer
would address my main concern.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
x27;d recommend
double-checking this with Mario Kleiner (Cc'd) and the dri-devel mailing
list.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
way
xterm. I've biscected it down the the above
merge commit by running glxgears on each checkout.
Am I the only one seeing this?
No:
https://bugs.freedesktop.org/show_bug.cgi?id=81800
I think Axel Davy (Cc'd) tracked down the problem at some point.
--
Earthling Michel Dänzer
On 29.07.2014 16:36, Jason Ekstrand wrote:
> On Tue, Jul 29, 2014 at 12:17 AM, Michel Dänzer <mailto:mic...@daenzer.net>> wrote:
>
> On 29.07.2014 16:01, Jason Ekstrand wrote:
> > Couple thoughs. First, we need to also update
> > drm_output_prepare_cu
else
> + ec->cursor_height = 64;
> +
>
>
> I think this was asked before, but never answered. Do we have known
> bounds on these values? I guess they come from GBM so we can probably
> trust that they're reasonable, but what are the gu
On 04.07.2014 18:17, Michel Dänzer wrote:
> On 04.07.2014 17:51, Ander Conselvan de Oliveira wrote:
>> On 07/04/2014 04:13 AM, Michel Dänzer wrote:
>>> On 03.07.2014 21:27, Ander Conselvan de Oliveira wrote:
>>>> On 06/25/2014 05:09 PM, Alvaro Fernando García wrote:
&
On 04.07.2014 17:51, Ander Conselvan de Oliveira wrote:
> On 07/04/2014 04:13 AM, Michel Dänzer wrote:
>> On 03.07.2014 21:27, Ander Conselvan de Oliveira wrote:
>>> On 06/25/2014 05:09 PM, Alvaro Fernando García wrote:
>>>> Init cursor size to 64x64 if drmGetC
d fail
> otherwise.
No, that check was removed when adding GBM_BO_USE_CURSOR.
> So this could just be
>
> flags = GBM_BO_USE_CURSOR | GBM_BO_USE_WRITE;
>
> and a
>
> #ifndef GBM_BO_USE_CURSOR
> #define GBM_BO_USE_CURSOR GBM_BO_USE_CURSOR_64X64
> #endif
&
On Mon, 2013-12-02 at 10:36 +, Richard Hughes wrote:
> On 2 December 2013 03:24, Michel Dänzer wrote:
> > No colour management is fine, but a 16bpp gamma ramp (let alone an 8bpp
> > palette) just doesn't look very good in 32bpp. :)
>
> If you can tell me how to adj
n't look very good in 32bpp. :)
> On Sun, Dec 1, 2013 at 9:30 PM, Michel Dänzer
> wrote:
>
> Without loading the cms-colord module, weston never calls
> drmModeCrtcSetGamma(). This means that weston's gamma ramp is
> whatever
>
Without loading the cms-colord module, weston never calls
drmModeCrtcSetGamma(). This means that weston's gamma ramp is whatever
was set previously. This is particularly bad when weston is launched
from a console using a different depth than weston itself.
--
Earthling Michel D
6-video-ati xwayland branch commit
> 8dc07e63eaf8909f7046bf746a119ec749352441
What about Mesa, the kernel and libdrm?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debi
54 matches
Mail list logo
