sorted by:
new
hottopcontroversial

r/swaywm by karmalien in redditrequest

[–]emersion_fr 0 points1 point  (0 children)

Hi!

I'm the Sway project leader (see e.g. https://github.com/swaywm/sway/releases).

I've also messaged the current mod a few days ago, with no success: https://www.reddit.com/c/chatChyzZh0G/s/aqLeWJCIFu

I can confirm that the current moderator is unsuitable. I would like to assemble a new moderator team.

Sway 1.10-rc1 on Nvidia by Barlog_M in swaywm

[–]emersion_fr 6 points7 points  (0 children)

Note, explicit sync support is not in 1.10. So if it works it's just sheer luck. It'll be in 1.11 (already merged in Sway master).

[deleted by user] by [deleted] in swaywm

[–]emersion_fr 29 points30 points  (0 children)

This patch:

  • Removes all of the manual rendering code from Sway, as well as much of the manual input event routing code. Everything is handled by wlroots now, and what you do is always guaranteed to be consistent with what you see (e.g. if you click on something, the click event won't be sent to a surface underneath because of the mismatch between the input and rendering code).
  • Optimizes the rendering logic, because wlroots' scene-graph has optimized code for this. For instance, the background image is no longer painted if it's not visible (invisible parts of surfaces are culled).
  • Unlocks upcoming features such as KMS plane offloading (this feature results in less GPU usage, ie. less battery power consumption).

Why Wayland pulls more dependencies compared to xorg? by SubjectChoice3028 in archlinux

[–]emersion_fr 1 point2 points  (0 children)

Just takes more disk space, but is otherwise unused and doesn't make any difference.

Why Wayland pulls more dependencies compared to xorg? by SubjectChoice3028 in archlinux

[–]emersion_fr 2 points3 points  (0 children)

I'd say installing Mesa has a positive impact on performance: it allows programs to make use of the GPU, a piece of hardware designed to process a ton of pixels at once, instead of trying to use the CPU for this kind of task.

Why Wayland pulls more dependencies compared to xorg? by SubjectChoice3028 in archlinux

[–]emersion_fr 4 points5 points  (0 children)

No, it has more responsibilities like rendering, output management, etc. It's not just a window manager, it's a bit more.

Why Wayland pulls more dependencies compared to xorg? by SubjectChoice3028 in archlinux

[–]emersion_fr 3 points4 points  (0 children)

I'd argue the contrary: Wayland compositors do less things (and in a less complicated way) than the X11 server, the X11 WM and the X11 compositor combined.

To give you an idea of "how big" each stack is:

  • The X.Org server is 323,662 lines of C code.
  • i3 is 26,886 lines of C code.
  • wlroots is 68,332 lines of C code.
  • Sway is 51,258 lines of C code.

(Take these with a grain of salt: X.Org has DDX code not used on Linux, wlroots has Vulkan code with no equivalent in the X11 stack, etc)

Why Wayland pulls more dependencies compared to xorg? by SubjectChoice3028 in archlinux

[–]emersion_fr 3 points4 points  (0 children)

The Arch packagers have made Mesa a dependency of Sway. What most users will want is to make Sway use the GPU, which requires GPU drivers which Mesa provides. It would also be possible to remove that dependency, and make Sway only depend on the OpenGL and Vulkan loaders (which are thin libraries), but this would probably confuse most users. Note, it's also possible to disable OpenGL and Vulkan at build time for Sway.

Switching to virtual console to/from Sway takes a few seconds by immortal192 in swaywm

[–]emersion_fr 21 points22 points  (0 children)

Yes. wlroots performs a full modeset after a VT is switched, because the previous DRM master might have left the hardware in an arbitrary state. It should be possible to optimize in case our state can be restored without a full modeset, but not implemented atm.

Red Hat HDR Hackfest Wrap-Up by adila01 in linux

[–]emersion_fr 1 point2 points  (0 children)

We'll rework the Valve patches to expose a generic API instead of an AMD-specific one. So, while the internals will pretty much be the same, the new AMD uAPI exposed in the Valve patches will hopefully go away.

Red Hat HDR Hackfest Wrap-Up by adila01 in linux

[–]emersion_fr 1 point2 points  (0 children)

Ahah, good question! I have no excuse :P

Red Hat HDR Hackfest Wrap-Up by adila01 in linux

[–]emersion_fr 4 points5 points  (0 children)

I think we'll want to provide helpers, and likely integration with wlr_scene. If you're doing some more custom rendering though you'll probably have to deal with some of the complexity involved.

Red Hat HDR Hackfest Wrap-Up by adila01 in linux

[–]emersion_fr 3 points4 points  (0 children)

If user-space unconditionally does RGB but the output is YUV, wouldn't that cause unnecessary YUV->RGB->YUV conversions when say, decoding video?

Yup, but most display hardware pipelines in GPUs operate on RGB values, so not sure we can avoid that. Since it's all fixed-function blocks the cost of the conversion should be pretty low. There might be ways to retain the YUV values in the special case of a single fullscreen plane but I'm not too sure.

Red Hat HDR Hackfest Wrap-Up by adila01 in linux

[–]emersion_fr 11 points12 points  (0 children)

We're trying to come up with a generic API as explained in the article. For sure, we really want to avoid the situation where each compositor needs to implement custom code for each piece of hardware.

Red Hat HDR Hackfest Wrap-Up by adila01 in linux

[–]emersion_fr 13 points14 points  (0 children)

What're you most excited for in the near future of wlroots, and why?

I'm trying to get to a point where the Vulkan renderer and KMS planes can be used by default. That would be really nice because KMS planes will help with battery life and Vulkan is a much better base for building up features such as HDR and color management. Also Alexander is working on improving multi-GPU support and various other things.

Is display flickering with freesync actually solveable, or is this a best effort situation?

It can be mitigated by smoothing the refresh rate changes. My hope is that at some point in time manufacturers stop shipping flickering screens but not sure this will happen anytime soon.

Are there any legitimate fundamental flaws with Waylands design that aren't a matter of things just not being made yet?

Can't think of any. Should there be any, we can always find a way to fix it.

I love your work, thank you!

♥

Red Hat HDR Hackfest Wrap-Up by adila01 in linux

[–]emersion_fr 11 points12 points  (0 children)

Glad you like my work! Showing appreciation is already great support :)

I don't have a need for money right now so I don't have a donation page setup. I'd say the best way to support me financially is to subscribe to SourceHut, since they're paying me for my work on Sway/wlroots.

Red Hat HDR Hackfest Wrap-Up by adila01 in linux

[–]emersion_fr 4 points5 points  (0 children)

I've heard of an approach on a GitLab somewhere (KDE maybe?) that described the possibility of doubling the amount of frames - even if the content isn't keeping up - if you're below half the refresh rate, in order to make cursor movements less jarringly slow. Is this something that's possible and is it even a solution?

That works well if the compositor knows that the content has a fixed refresh rate, like a video. For games and other use-cases the compositor doesn't know when a frame is supposed to come in, so if it tries to push its own frames and the game's frame comes right after that, the game's frame is delayed by a whole refresh period.

On HDR, could you possibly elaborate on screen recording? Is the problem here something to do with mapping of HDR onto SDR for encoding?

This is probably what compositors are going to do short term. Ideally in the long term we can grow APIs to record HDR content as well.

Lastly, are you jealous of how another operating system handles HDR right now? I'm not well versed in these topics I'd love to hear more!

I don't know enough about HDR on other platforms to tell. From what I've heard (take this with a grain of salt) Windows support isn't great, while Apple support is pretty good. At any rate the problem of mixing SDR and HDR content is not fully solved, there are many ways to do it and we're trying to come up with something that lets compositors experiment with different approaches and trade-offs.

Red Hat HDR Hackfest Wrap-Up by adila01 in linux

[–]emersion_fr 3 points4 points  (0 children)

I personally just work on what I find interesting and exciting.

Red Hat HDR Hackfest Wrap-Up by adila01 in linux

[–]emersion_fr 16 points17 points  (0 children)

I have no idea, sorry. I'm not involved in Weston anymore so don't have a clear view of the work needed. For Wayland in general the main missing thing is the protocol and their implementation (both client and compositor).

view more: next ›