Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why don't we have Wayland on Raspberry Pi yet? (2018)

joshondesign.com

Post reply on HN
Print view View original

131–140 of 259 posts

Re: Why don't we have Wayland on Raspberry Pi yet? (2018)

#131

Post by cbdumas »

floatboth wrote: post #125
cbdumas wrote: post #74

Earlier quoted context omitted.

So I'm no expert but I believe there are actually two different notions of hardware acceleration at play here: 1) HW accelerated rendering in Firefox, which despite being unfortunately disabled by default on linux can in my experience be enabled (on about:config) without issues. This makes the experience of scrolling much smoother, so I usually do that. I don't think this has any observable effect on battery life for…

> enabling this in Sway results in some very odd behavior that breaks certain things I've been using Firefox Nightly in Wayfire (also wlroots based) with GL (and even WebRender) for quite a long time now, it works very well, about the only issue left is popover placement is odd occasionally. What issues do you have?

With hw rendering enabled, opening a single Firefox window and browsing works fine. However when I try to open a new window the browser and desktop immediately become incredibly laggy and eventually unresponsive. I think I was able to successfully open a different tty and kill Firefox, which then fixed the issue, but it repro'd every time. Open one Firefox window, everythings fine. Open two, things slow to a crawl.

I'm surprised you were able to get WebRender working as well, I think I recall Firefox instantly crashing when I tried that. This was a few weeks ago.

Re: Why don't we have Wayland on Raspberry Pi yet? (2018)

#133

Post by Thaxll »

cbdumas wrote: post #74
michaelmrose wrote: post #66

Earlier quoted context omitted.

Without hardware acceleration doesn't watching video in the browser pretty much destroy your battery life and use most of your cpu time?

So I'm no expert but I believe there are actually two different notions of hardware acceleration at play here: 1) HW accelerated rendering in Firefox, which despite being unfortunately disabled by default on linux can in my experience be enabled (on about:config) without issues. This makes the experience of scrolling much smoother, so I usually do that. I don't think this has any observable effect on battery life for…

If I disable HW acceleration on the desktop it's horrible perf wise, like VSCode and all the electron app are slow, there is aliasing all over the place when moving windows, slowness ect ...

( Ubuntu 18.04 / Unity on a Dell XPS 13 from 2016 )

Re: Why don't we have Wayland on Raspberry Pi yet? (2018)

#134

Post by jlarcombe »

jchw wrote: post #89
0xfaded wrote: post #67

Earlier quoted context omitted.

I've been reading through the Vulkan spec, which is in way similar in that OpenGL has been extended since its introduction in 1992 with more and more features to support new graphics capabilities as they evolved. I've seen Vulkan called the successor to OpenGL, but reading the spec it seems more like the end game for raster graphics card programming. OpenGL 4.0 was released in 2010, and since then changes have been i…

Qt Widgets is an amazing library, but honestly it is both more and less featureful than it needs to be in various cases. The rich text document stuff still holds up OK for basic cases, but I think the text rendering story could be a bit better. Last time I was doing low level text stuff in Qt, performance was not super impressive, and some of the APIs left a bit to be desired.

Well said. The notion that Qt widgets are "finished" was just an aspiration not to spend much more money on it I think; they sort of rowed back on this when it became apparent that Qt Quick isn't always appropriate, but by then it had sort of spread around as a "Qt fact" amongst people who didn't actually use it.

The number of rough edges, missing bits and outright bugs mean that it's certainly not "finished"... just like all software really.

Re: Why don't we have Wayland on Raspberry Pi yet? (2018)

#135

Post by chmln »

floatboth wrote: post #102
simion314 wrote: post #73

Earlier quoted context omitted.

X is good enough for majority of the users, even if the architecture is not perfect.

Screen tearing, bad performance, bad touchscreen support (not independent of mouse cursor), and especially important these days: no real HiDPI support (practically impossible to support different scales for different monitors). It's not good enough.

These claims are blown out of proportion and/or simply untrue.

Screen tearing: both Intel and AMD have hardware-backed "TearFree" buffering to prevent tearing. Bad performance: citation required - in my experience, Xorg is way faster. Touchscreen support - in most cases just works out of the box thanks to libinput. No HiDPI support for different scales per monitor - simply wrong - this is trivial with xrandr.

Re: Why don't we have Wayland on Raspberry Pi yet? (2018)

#136

Post by stefan_ »

c-smile wrote: post #129

The article is focused on essentially old idea of framebuffers: > Even more ideally these memory chunks would just be textures in the GPU. And that idea is very far from modern world of high-DPI monitors. In high-DPI UI you cannot operate on textures anymore. Window surface shall be represented not by bitmap (that is O(N) complex to fill by CPU) but rather CommandLists: [opFillRect,0,0,100,100] [opFillPath,...] [opBl…

I believe you are at the wrong stage, mentally. This is all about the compositor that puts the final image on your screen together. The input to this component is always a list of textures with associated meta information (offset on screen, scaling, alpha mixing, Z position.. whatever your compositor offers). How these textures are created is not the business of the compositor - and the routine case is of course through GPU drawing!

There are two things to mention here that are of particular importance on mobile systems. Lots of chips now have compositor hardware - separate silicon from the GPU that can read textures, scale them, blend them and push the resulting pixels directly to the screen. And second, the word "texture" is used here to mean "any format that GPU, compositor and video decode engine can read or produce" - in stark contrast to the old framebuffer approach, it is essential that things stay in their "native" format for as much of the pipeline as possible and are never CPU read or modified, which would require conversion.

Re: Why don't we have Wayland on Raspberry Pi yet? (2018)

#137

Post by mrb »

simion314 wrote: post #73
mwfunk wrote: post #9

I enjoyed the article but this quote jumped out at me: "What took thirty years to build isn't going to be replaced in a day." This was in regard to replacing X11 with Wayland. It's funny because it would be closer to the truth to say that X11 took 5 years to build, and for the last 25 years everyone has been trying to get off of it, but in the meantime piling more stuff on top of it since that's easier than starting…

X is good enough for majority of the users, even if the architecture is not perfect.

The fact X11, as the "standard" windowing environment for Unix operating systems, was ditched by literally all major Unix operating systems created in the last 20 years like Mac OS X, Android, iOS, etc, tells us that X11 is not good enough.

For example here is an Apple developer explaining why X11 wasn't chosen for Mac OS X: https://apple.stackexchange.com/questions/168980/if-os-x-doe...

(By "Unix operating system" I mean an OS based on a Unix/Linux kernel.)

Re: Why don't we have Wayland on Raspberry Pi yet? (2018)

#138

Post by [deleted] »

jolmg wrote: post #68
DonHopkins wrote: post #37

Earlier quoted context omitted.

Except that X11 isn't doing something so right -- it's still terrible, and it always has been, and we knew it was terrible at the time it was standardized. But it's funny that you would bring up something as terrible as a shell scripting language like bash to compare to how terrible X-Windows is. Have you ever read through a gnu configure file yourself, or do you just close your eyes and type "./configure"? Who in th…

> as terrible as a shell scripting language That's a strong opinion. I'm not going to argue for lack of time, but suffice to say that 99% of my interactions with my computer and sometimes with my phone is with a shell scripting language. Shell scripting is awesome. > Have you ever read through a gnu configure file yourself, Yes. Generated scripts make for a boring read. > or do you just close your eyes and type "./co…

[deleted]

Re: Why don't we have Wayland on Raspberry Pi yet? (2018)

#139

Post by blibble »

chmln wrote: post #135
floatboth wrote: post #102

Earlier quoted context omitted.

Screen tearing, bad performance, bad touchscreen support (not independent of mouse cursor), and especially important these days: no real HiDPI support (practically impossible to support different scales for different monitors). It's not good enough.

These claims are blown out of proportion and/or simply untrue. Screen tearing: both Intel and AMD have hardware-backed "TearFree" buffering to prevent tearing. Bad performance: citation required - in my experience, Xorg is way faster. Touchscreen support - in most cases just works out of the box thanks to libinput. No HiDPI support for different scales per monitor - simply wrong - this is trivial with xrandr.

I still find tearing to be problematic

I have a machine with a supported Radeon card (open-source driver), another machine with a supported nvidia card (binary blob driver), and another two machines using different intel onboard graphics chips (open-source driver)

the radeon and the intel (both drivers which work with it) have issues putting out a stable jitterless 60fps without tearing (with tearfree on, and various combinations of with/without compositing/glx/...)

Re: Why don't we have Wayland on Raspberry Pi yet? (2018)

#140

Post by stefan_ »

Sir_Cmpwn wrote: post #35

This article seems to be mixing up languages, which others have pointed out but not in full. wayland-rs does not wrap libwayland, but instead offers a pure Rust implementation of the Wayland protocol. Sway and wlroots are both written in C, but wlroots-rs is a project which wraps the wlroots C library in a Rust wrapper. There are currently no mature Wayland compositors written in Rust. Also, this article mainly focus…

The irony of the Raspberry Pi in particular is that while the ARM side has seen multiple order of magnitude jumps in performance, the GPU and compositor hardware have of course remained at its original 2009 atrocious level.

The result is that the CPU drawing on a screen-sized framebuffer is fast enough that Raspbian will probably never, ever make the jump to full bells-and-whistles mainline VC4 drawing and atomic DRM composition. It would just end up using a lot more memory and break a bunch of hacks in the proprietary drivers that people have come to rely on for essentially still garbage tier performance and a system that randomly freezes because you ran out of graphics memory (which is forever limited to 256 MiB, memory that you surrender on boot to the horrendous CMA system).

I like the Pi a lot as a PoC platform given the availability and the fully open-source supported driver we have for it. But the HW specifications of all the parts that Wayland cares about make it very clear that the thing was only ever meant to do 1080P when you are piping frames from the video decode engine straight to the compositor and out the pixel valves.

Post reply on HN