What WM/DE will Pyra OS use?

[RubisDrake]

I honestly think that there should be a Wayland desktop for Pyra, something like Enlightenment 20, Hawaii desktop. Heck, even Weston works good enough, except it's a little harder to customize. If Pyra is the future, then use future technology.

I currently use cwm, since it's the lightest, most usable one I've used, and it has features I like about it more than Openbox. Not really a good WM for portable systems and newbies for Linux, IMO. Also, yes, I'm still trying to figure out a way to transition from X to Wayland permanently, but the problem is a lot of Debian packages still need XWayland, so make sure it's installed and enabled. Many programs don't have Wayland display support at all. That really sucks. Though I have gotten specific applications working by overriding the backends, forcing it to not use X.

One big thing stopping Wayland support on ARM devices is that Wayland uses KMS, and KMS requires Linux drivers and firmware for the GPU. 2D support is easy for the Vivante GC320, there's etna_viv. 3D support in KMS will be harder if the source code for the PowerVR SGX remains closed, or they won't release it, so it unfortunately sounds like maybe Pyra will still be using X, at least for 3D acceleration.

 

[matzesu]

What happens to the good old minimenu ??
But i think i will be happy whit all windowmanagers you will decide for Pyra..
The XFCE on Pandora wasnt that diverent to standart Windows User Interface.. (there also was an design whit windows collours )

 

[Silent-Hunter]

Personally, I think X would be more battery friendly, Wayland should be avoided unless it can do software rendering like X can.

 

[txus]

Personally, I think X would be more battery friendly, Wayland should be avoided unless it can do software rendering like X can.

This is only the case if the GPU can successfully be switched off, and even then I'd have some doubts. This is not even considering the GC320 on board, a hardware specialised on 2D acceleration. A quick search on the internets shows quite a few results on how Wayland improves power consumption...

But anyway, both our assumptions are meaningless without some benchmarks on the real hardware... Let's wait and see

 

[ible]

Wayland would be great to support in the future, but it's not very stable just yet, and not many stable programs on top of it.

Pyra efforts should continue on with X, since it'd be nice to have all our current stable programs running there .

 

[RubisDrake]

I should clarify that I'm still not using Wayland as a full-time desktop, I'm still using cwm (which is still an X desktop). Mostly that's because libinput really sucks for Wacom device input. I know the linuxwacom drivers are really good for Xorg, but libinput can only handle the touch input, not stylus, etc... There is a dev build of libinput coming out that may bring these features in the future. So since the Pyra only has a touchscreen, I think libinput will work really great for the Pyra right now, as long as all standard udev and evdev inputs work with it, but it's hard to say the same for Wayland, yes.

I think X and Wayland will have close to the same battery performance. If not, maybe Wayland will be negligibly better, but not by much. There are other way more important factors that would help save battery, like a screensaver, or DPMS, or power-saving modes on hardware.

As far as I know, if anyone starts writing applications now, without using Xlib calls, in SDL 2, Qt5, GTK+3, Clutter and EGL, your program will likely be compatible with Wayland. I really love SDL apps, and I know a lot of games use it. Porting SDL games should be the easiest, so it really is time to start porting games to SDL 2 already!

I've gotten mpv-player to work with Wayland, and a lot of third-party browsers, and Firefox Nightly, all work without needing X. Many Gnome 3 and Plasma 5 apps work with Wayland, too. LibreOffice is transitioning to GTK+3, but it's hard to say if it's entirely fully Wayland compatible yet.

So all in all, I'm hopeful it will happen, but not keeping my fingers crossed that this will happen officially for the Pyra.

 

[kaprikawn]

Wayland would be great to support in the future, but it's not very stable just yet, and not many stable programs on top of it.

Pyra efforts should continue on with X, since it'd be nice to have all our current stable programs running there .

Wayland is perfectly stable and has been for a long time now. It just requires a compositor to take advantage, and that's the bit that isn't mature yet. The big toolkits (GTK and qt in particular) have good support, we're just waiting for the DEs to implement their Wayland compositors. Gnome with mutter is furthest along, it's currently useable, but not by default. Fedora is trying to knock a few last items off the todo list to reach feature parity with X in order to enable Wayland by default. A few others are making good progress like KDE and Enlightenment.

@power useage discussion
Wayland has the potential to reduce power consumption, see Youtube vid below. I'm not saying that using Wayland on the Pyra will increase battery life, but if all else is equal, Wayland will use less power. Unfortunately it's likely that not all other things will be equal with the Pyra so we'll just have to wait and see. I'm sure a lot will depend on the drivers and whatnot.

 

[Binky]

How're the LXQT people getting on?

Anyone tried using it yet?

 

[bzar]

Wayland is perfectly stable and has been for a long time now. It just requires a compositor to take advantage, and that's the bit that isn't mature yet. The big toolkits (GTK and qt in particular) have good support, we're just waiting for the DEs to implement their Wayland compositors. Gnome with mutter is furthest along, it's currently useable, but not by default. Fedora is trying to knock a few last items off the todo list to reach feature parity with X in order to enable Wayland by default. A few others are making good progress like KDE and Enlightenment.

@power useage discussion
Wayland has the potential to reduce power consumption, see Youtube vid below. I'm not saying that using Wayland on the Pyra will increase battery life, but if all else is equal, Wayland will use less power. Unfortunately it's likely that not all other things will be equal with the Pyra so we'll just have to wait and see. I'm sure a lot will depend on the drivers and whatnot.

Yes, if you are doing something that uses the GPU anyway or majorly benefits from it a Wayland compositor has the potential to use less resources in total. If you're doing something that does not use the GPU at all, however, the situation is as far as I've understood different. In one case the GPU can be turned off and in the other it cannot. At least I haven't heard of a wayland setup that can swap between CPU(+ potential 2D accelerators) and GPU based rendering.

So the question is about 1) expected usage scenario profile and 2) power consumption profile of both options for varying intensities for each scenario.

If you intend to use a GPU composited desktop, (1) becomes pretty much irrelevant since you're using the GPU all the time anyway. If you intend to use Pyra like I'd assume was the most popular scenario for Pandora, namely non-composited desktop and running mostly non-GPU applications and games, the GPU would sit unused for most of the time. In this case I suspect (2) is better for the Xorg setup, since for wayland the GPU would only be powered on to perform buffer copying from the CPU generated images to the display texture.

It's not an automatic performance boost, but one depending on how you use the device. For CPU generated images you do extra buffer copying to the GPU when using wayland (with GPU acceleration), for GPU generated images you do extra work on the CPU when using Xorg. Using Wayland without the GPU acceleration is AFAIK less CPU efficient than Xorg.

 

[Plume]

I'm just wondering. How is the display controller wired? Is it accessible while turning of the GPU?

Anyway, shouldn't it be (technically) possible to design a compositor which suits the Pyras needs or is there a technical limitation of the Wayland protocol?

 

[levi]

Yes, if you are doing something that uses the GPU anyway or majorly benefits from it a Wayland compositor has the potential to use less resources in total. If you're doing something that does not use the GPU at all, however, the situation is as far as I've understood different. In one case the GPU can be turned off and in the other it cannot.

Since the GPU is in-package on the OMAP chip, can it even really be turned off? Or just left with nothing to do?

I guess the situation's likely to be the same as on the Pandora's OMAP chip. Does it take longer to do the first GPU operation than subsequent ones? If so it's entered some sort of reduced power mode, possibly turning off. If not, it's just sitting there waiting for something to do. It's probably more efficient to do certain tint and blit operations on the GPU in that case.

 

[kaprikawn]

@bzar Point taken, you are of course right,

@Plume The discussion could well be all academic. Wayland needs EGL and KMS, I don't know whether they're possible using the driver we'll get on the Pyra, but I suspect not. Maybe someone else more knowledgeable could chime in.

 

[bzar]

Prior conversation has implied turning off the GPU was an option.

 

[slaeshjag]

I would personally not buy a pyra or be even have the slightest interest in one if it can't run a fully functional and decently accelerated X server.

 

[Silent-Hunter]

Well fortunately even if we use Wayland, it can run an X server inside it.