Future of the Raspberry Desktop

[szapo]

With the currently available, quite capable hardware and a possible longer wait for a next gen platform, I was wondering about a possible stronger focus on the software in the meantime.

With reference to a thread about the status of Wayland from last year, I would like to discuss possible overhauls of the Raspbian desktop in the future.
All major desktop OSs (even the free ones) have switched to modern, fluent, hardware accelerated UIs years ago, leaving Raspbian - despite its fine software offerings - quite behind.

1. Are there any plans to take similar paths for Raspbian? What are the reasons why this hasn't been done yet?
2. I would be thankful for some guidance on available projects/sources for tinkering around by myself.

[Andyroo]

Re part 1 - the Foundation does not have a history of releasing news till they are ready. There are the odd interview or two where bits of VERY generic futures have been said but do not hold your breath.

A post in the last few days on the file manager stated the current desktop did what was required by the Foundation and any extra work would have to be justified for cost vs benefits. I know (again from a recent post) automated test tools would be a benefit to James first

As for a different desktop - some folk here have started with Lite and added their own choice of window manager. Maybe you could kick of a Project to do that?

[fruitoftheloom]

With the currently available, quite capable hardware and a possible longer wait for a next gen platform, I was wondering about a possible stronger focus on the software in the meantime.

With reference to a thread about the status of Wayland from last year, I would like to discuss possible overhauls of the Raspbian desktop in the future.
All major desktop OSs (even the free ones) have switched to modern, fluent, hardware accelerated UIs years ago, leaving Raspbian - despite its fine software offerings - quite behind.

1. Are there any plans to take similar paths for Raspbian? What are the reasons why this hasn't been done yet?
2. I would be thankful for some guidance on available projects/sources for tinkering around by myself.

Simon Long is the Desktop GUI Developer and the only person who would have insight into future plans:

https://www.raspberrypi.org/blog/author/simon-long/


There are several different Desktops Environments which you can install and many posts already on this subject, such as this old thread:

viewtopic.php?t=133691


As already stated ad-infinitum there is no public roadmap of future directions...

[jamesh]

The dev focus with regard to graphics is the Mesa graphics driver. Make that work fully and you get desktop acceleration. So work is being done.

[k-pi]

One reason to stick with using a window manager, rather than a desktop environment, is size, but also speed will come into it, & maybe even ease of configuration.

Anyone can add whatever they want, if it's in the repos, so the best option is to keep the basic distro as lightweight as possible so that it runs on all the RPi hardware.

[szapo]

OK I was under the impression that a) accelerated desktops are around since the (very old) G4 Macs and b) the reason for the Raspberry Foundation to choose the RPi's particual GPU hardware is its openness and assumed very good state of driver & software. This led me to state my question.

Thanks for all the replies, especially the link to the different desktop environments is very interesting.

[jamesh]

OK I was under the impression that a) accelerated desktops are around since the (very old) G4 Macs and b) the reason for the Raspberry Foundation to choose the RPi's particual GPU hardware is its openness and assumed very good state of driver & software. This led me to state my question.

Thanks for all the replies, especially the link to the different desktop environments is very interesting.

b) Is wrong. The SoC was chosen because Eben works for Broadcom and designed parts of the GPU, was very familar with the device overall, and was able to get a good deal on the chips.

[stuartiannaylor]

OPenCL is now available https://github.com/doe300/VC4CL

It did a good job of display composition, multi-standard video encoding and decoding to 1080p resolution, but sort of showing its age now when compared to what other SoCs are employing.

[ghans]

The work on the "proper" DRM/Mesa3D stack was started in 2014 - that means accelerated desktop environments were dysfunctional for quite some time and are just now starting to work out-of-the-box. Just choose "Enable/Disable experimental desktop GL driver" in raspi-config. Any accelerated desktop environment should pick it up automagically.

Wayland/Maynard turned out to be a dead end. So far i know the Raspberry Pi specific code (the dispmanx? backend) was removed some time ago anyway.

ghans

[cjan]

Wayland/Maynard turned out to be a dead end. So far i know the Raspberry Pi specific code (the dispmanx? backend) was removed some time ago anyway.

not yet, i used drm-backend and run pretty well.

[jamesh]

OPenCL is now available https://github.com/doe300/VC4CL

It did a good job of display composition, multi-standard video encoding and decoding to 1080p resolution, but sort of showing its age now when compared to what other SoCs are employing.

OpenCL is a open standard for getting access to GPU processing units. Most SoC's use HW CODEC's for video encoding (including the VC4), not OpenCL.

[stuartiannaylor]

OPenCL is now available https://github.com/doe300/VC4CL

It did a good job of display composition, multi-standard video encoding and decoding to 1080p resolution, but sort of showing its age now when compared to what other SoCs are employing.

OpenCL is a open standard for getting access to GPU processing units. Most SoC's use HW CODEC's for video encoding (including the VC4), not OpenCL.

Yeah shouldn't of put them together but noticed a OpenCL version had arrived. So posted as only thing I could think of that was relatively new.

It did a good job of display composition, multi-standard video encoding and decoding to 1080p resolution, but sort of showing its age now when compared to what other SoCs are employing.

Was just an after thought that irrespective of Mesa, HW CODEC's, OpenGL or OpenCL the Broadcom VideoCore IV is starting to show its age.
I would be surprised if and when the Pi4 turns up that VideoCore IV is the GPU as its pretty amazing how much as been squeezed out of it but yeah its really starting to show its age even with clock bumps.

[jamesh]

OPenCL is now available https://github.com/doe300/VC4CL

It did a good job of display composition, multi-standard video encoding and decoding to 1080p resolution, but sort of showing its age now when compared to what other SoCs are employing.

OpenCL is a open standard for getting access to GPU processing units. Most SoC's use HW CODEC's for video encoding (including the VC4), not OpenCL.

Yeah shouldn't of put them together but noticed a OpenCL version had arrived. So posted as only thing I could think of that was relatively new.

It did a good job of display composition, multi-standard video encoding and decoding to 1080p resolution, but sort of showing its age now when compared to what other SoCs are employing.

Was just an after thought that irrespective of Mesa, HW CODEC's, OpenGL or OpenCL the Broadcom VideoCore IV is starting to show its age.
I would be surprised if and when the Pi4 turns up that VideoCore IV is the GPU as its pretty amazing how much as been squeezed out of it but yeah its really starting to show its age even with clock bumps.

Well, it is over ten years old....and historically even older if you count VC1,2,3,4.

[stuartiannaylor]

Yeah not a criticism but just acceptance that it is a veritable age and that it is what it is