Live data from Hacker News

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

joshondesign.com

121–130 of 259 posts

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

#121
post #33

Earlier quoted context omitted.

> but I bet the original creators would be the ones most shocked that it's still a thing in 2019. Couldn't we say the same thing about bash or basically most tools in your typical Unix-based OS? Old code is solid code. If they're to be shocked it's for doing something so right that it's persisted all this time.

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…

I am very thank full that the plan to convert our entire engineering centre to some awful x windows tool set fell though at BT.

Though I still use the training I got in the accelerated 1 weekcrash course in unix we all did.

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

#122

Earlier quoted context omitted.

Photoshop pretty much got it right a couple decades or so ago, and they've just been porting it, smearing on new lipstick, and figuring out how to make more money with it ever since.

I would argue that this is true of most of Microsoft Office as well. When did they really add a new feature to PowerPoint that you had to have? And it's no surprise both Adobe and Microsoft have pushed people towards a subscription model for this software: Nobody in their right mind would pay for upgrades otherwise. Arguably Office you need every ten years to ensure you have security updates because of the amount of…

The feature set of Microsoft Office, yes. But I think Google Docs took some reasonable steps backwards in features in exchange for a big leap forward in collaboration. (Or a few steps towards but not nearly far enough to where Douglas Engelbart was in 1968.)

https://en.wikipedia.org/wiki/The_Mother_of_All_Demos

>The live demonstration featured the introduction of a complete computer hardware and software system called the oN-Line System or, more commonly, NLS. The 90-minute presentation essentially demonstrated almost all the fundamental elements of modern personal computing: windows, hypertext, graphics, efficient navigation and command input, video conferencing, the computer mouse, word processing, dynamic file linking, revision control, and a collaborative real-time editor (collaborative work). Engelbart's presentation was the first to publicly demonstrate all of these elements in a single system. The demonstration was highly influential and spawned similar projects at Xerox PARC in the early 1970s. The underlying technologies influenced both the Apple Macintosh and Microsoft Windows graphical user interface operating systems in the 1980s and 1990s.

http://worrydream.com/Engelbart/

>Engelbart's vision, from the beginning, was collaborative. His vision was people working together in a shared intellectual space. His entire system was designed around that intent.

>From that perspective, separate pointers weren't a feature so much as a symptom. It was the only design that could have made any sense. It just fell out. The collaborators both have to point at information on the screen, in the same way that they would both point at information on a chalkboard. Obviously they need their own pointers.

>Likewise, for every aspect of Engelbart's system. The entire system was designed around a clear intent.

>Our screen sharing, on the other hand, is a bolted-on hack that doesn't alter the single-user design of our present computers. Our computers are fundamentally designed with a single-user assumption through-and-through, and simply mirroring a display remotely doesn't magically transform them into collaborative environments.

>If you attempt to make sense of Engelbart's design by drawing correspondences to our present-day systems, you will miss the point, because our present-day systems do not embody Engelbart's intent. Engelbart hated our present-day systems.

And it's in the direction of multi-user collaboration that X-Windows falls woefully short. Just to take the first step, it would have to support separate multi-user cursors and multiple keyboards and other input devices, which is antithetical to its singleminded "input focus" pointer event driven model. Most X toolkits and applications will break or behave erratically when faced with multiple streams of input events from different users.

https://tronche.com/gui/x/xlib/input/XGrabPointer.html

For the multi-player X11/TCL/Tk version of SimCity, I had to fix bugs in TCL/Tk to support multiple users, add another layer of abstraction to support multi-user tracking, and emulate the multi-user features like separate cursors in "software".

Although the feature wasn't widely used at the time, TCL/Tk supported opening connections to multiple X11 servers at once. But since it was using global variables for tracking pop-up menus and widget tracking state, it never expected two menus to be popped up at once or two people dragging a slider or scrolling a window at once, so it would glitch and crash whenever that happened. All the tracking code (and some of the colormap related code) assumed there was only one X11 server connected.

So I had to rewrite all the menu and dialog tracking code to explicitly and carefully handle the case of multiple users interacting at once, and refactor the window creation and event handling code so everything's name was parameterized by the user's screen id (that's how you fake data structures in TCL and make pointers back and forth between windows, by using clever naming schemes for global variables and strings), and implement separate multi-user cursors in "software" by drawing them over the map.

Multi-Player X11 SimCityNet:

https://www.youtube.com/watch?v=_fVl4dGwUrA

X11 SimCity Pie Menus:

https://www.youtube.com/watch?v=Jvi98wVUmQA

Multi-user menu tracking (added "@$screen" parameterizations):

https://github.com/SimHacker/micropolis/blob/master/micropol...

Opening multiple X11 displays (multiple toplevel "head" windows per screen, each with a unique id, using $win parameterization):

https://github.com/SimHacker/micropolis/blob/master/micropol...

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

#123

Last time (which was when Fedora first shipped it by default) I looked at Wayland, it took me less than an hour to run into several showstopper issues and move right back. The ones I remember include being incompatible with the proprietary Nvidia drivers (and no plan to ever fix that), huge input lag (apparently stemming from the, um, "interesting" idea to make the compositor responsible for all input) and lots of ra…

> incompatible with the proprietary Nvidia drivers (and no plan to ever fix that)

I've heard that Nvidia is fixing this in KDE Plasma and maybe Gnome too. (Fuck proprietary drivers though, and fuck Nvidia.)

> huge input lag

that's odd. Gnome's compositor is not the fastest, but it generally works okay for many many people.

> the reasons one should consider a switch nowadays

- No screen tearing ever, every frame is perfect

- Real HiDPI support, different scales on different monitors, many compositors support "Apple-style" fractional scaling (render at ceil(scale) and downscale on GPU)

- Proper touchscreen support, without dragging the mouse pointer along

- Touchpad gesture support (this miiiight have been bolted onto X with XInput2 as well)

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

#124
post #33

Earlier quoted context omitted.

> but I bet the original creators would be the ones most shocked that it's still a thing in 2019. Couldn't we say the same thing about bash or basically most tools in your typical Unix-based OS? Old code is solid code. If they're to be shocked it's for doing something so right that it's persisted all this time.

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…

> Except that X11 isn't doing something so right -- it's still terrible

Yet your windows render and take input, life goes on, etc. I am pretty happy with it on systems where it runs. Some of the old criticisms like it being a resource hog - might have made sense in the specs of, say, 1993 or earlier, but even restricting the comparison to what most of us have loaded in Javascript at any moment it's pretty lightweight.

> Have you ever read through a gnu configure file yourself ... Who in their right mind would ever write a shell script

I really don't think it's fair to use machine-generated code as an example of why you shouldn't use a particular language. All of those alleged universally available, "real" scripting languages that don't terribly suck would also look pretty bad if you turned them into a target language for GNU autotools.

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

#125
post #74

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…

> 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?

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

#126

Wayland was designed to solve a very specific set of use cases and nothing more. The number of times I have read "wayland doesn't do that" or "that's not wayland's job" or "wayland is just the compositor" are telling. Of course a stack that is compositor + windowing toolkits is going to miss countless mission critical use cases in countless workflows, not to mention that it is an even further regression from composab…

Right, X11 made it possible to have literally hundreds of window managers written to fit all possible tastes. With Wayland, the ecosystem of window managers will never be as rich, because a window manager has to implement too many things to be usable.

You can always take a compositor and fork it to implement your window management features…

or, much better, use a compositor with a plugin system, so window managers can become plugins! :)

https://github.com/WayfireWM/wayfire

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

#127

Did beos and haiku use X? I think not, then how do their graphics systems work?

Direct to hardware. There is a framebuffer driver that IIRC uses VESA primitives, and a few other more generic drivers with bit blitting and OpenGL support.

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

#128
post #33

Earlier quoted context omitted.

> but I bet the original creators would be the ones most shocked that it's still a thing in 2019. Couldn't we say the same thing about bash or basically most tools in your typical Unix-based OS? Old code is solid code. If they're to be shocked it's for doing something so right that it's persisted all this time.

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…

> Who in their right mind would ever write a shell script

I quite enjoy writing fish scripts. Largely because I can actually remember the syntax for conditionals and loops.

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

#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,...]
   [opBlitBitmap,...]   
 
Window compositor shall pass such command lists to GPU for rendering.

This way to fill rectangle on window's surface will be O(1) complex operation - just to send [opFillRect,0,0,100,100] command to window (and so to GPU) for rendering.

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

#130
post #26

Earlier quoted context omitted.

The bar for being important enough to not discard when it works and is the only solution to particular problems is not very high. I know of no other method to forward individual programs GUIs to other machines. Abandoning X is abandoning a power we have. You're right that it may not be used as much. Last time I used it was to debug why selenium tests running in chrome were failing in a server with a virtual display (…

I just use ssh/screen/emacs to work on remote servers. Why would I ever want an xterm?

You're replying to a comment that gives an example of use of X11 forwarding that's not fulfilled by ssh/screen/emacs.
Post reply on HN