Did beos and haiku use X? I think not, then how do their graphics systems work?
Why don't we have Wayland on Raspberry Pi yet? (2018)
61–70 of 259 posts
Re: Why don't we have Wayland on Raspberry Pi yet? (2018)
#62I think the author is confusing something here > The reference implementation of the protocol (Weston and it's associated libraries) is written in C. That means you could wrap the C code with Rust, which several people have done already [1] However, I get the impression that the results are not very 'rustic', meaning it's like you are coding C from Rust, instead of writing real Rust code. > To address the problems of…
Perhaps the author meant Smithay, which, while it still depends on some C, is almost entirely Rust:
Re: Why don't we have Wayland on Raspberry Pi yet? (2018)
#63I've been using swaywm on my laptop (XPS 13) with XWayland disabled for a few months now and have had very few problems with it. As far as I can tell Firefox works perfectly, except for some very strange behavior if I try to enable hardware acceleration. I love how easy it is to configure via config files, external monitors work great, scaling on HiDPI displays has been totally painless. My days off fiddling with xor…
That is encouraging. What distro are your swaywm and Firefox running on?
Re: Why don't we have Wayland on Raspberry Pi yet? (2018)
#64Meh. As far as I'm concerned, Wayland is strictly inferior to X, so long as it fails to support network transparency / remoting. Talk to me when they have a real solution for this, besides VNC or supporting RDP.
Meh. As far as I'm concerned, Wayland is strictly superior to X, so long as it fails to support keyloggers.
Except it does actually support keyloggers while breaking the concept of global keybindings. It's like the worst of both worlds.
Re: Why don't we have Wayland on Raspberry Pi yet? (2018)
#65I 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…
Well at least it's the best kind of lock-in.
Re: Why don't we have Wayland on Raspberry Pi yet? (2018)
#66I've been using swaywm on my laptop (XPS 13) with XWayland disabled for a few months now and have had very few problems with it. As far as I can tell Firefox works perfectly, except for some very strange behavior if I try to enable hardware acceleration. I love how easy it is to configure via config files, external monitors work great, scaling on HiDPI displays has been totally painless. My days off fiddling with xor…
Without hardware acceleration doesn't watching video in the browser pretty much destroy your battery life and use most of your cpu time?
Re: Why don't we have Wayland on Raspberry Pi yet? (2018)
#67I 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…
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 incremental. We more or less have figured out how to do raster graphics (ray tracing may be a different story), so it made sense to invest tens (hundreds?) of millions of dollars to develop the Vulkan spec, and then many millions more to implement it.
What other technologies are there were we are more or less at the end game? I know Qt5 widgets is considered feature complete for desktop apps.
Re: Why don't we have Wayland on Raspberry Pi yet? (2018)
#68Earlier 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…
> 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 "./configure"?
I do, from people I chose to trust, whether by running the package build scripts written by the package maintainers of my distribution or from github accounts that I judge as trustworthy.
There is a lot of trust involved in using a computer. I mean, if something nefarious might be in the ./configure script, it's more likely to also be in a precompiled program, since more people touched it.
> Who in their right mind would ever write a shell script,
I do.
> when there are so many real scripting languages that don't terribly suck universally available,
Each language is good for different reasons. Shell languages are meant primarily to be used interactively, as opposed to languages like python or ruby. The fact that you can put your everyday interactions in a file and run that is an added bonus.
> that don't shit themselves when they encounter a file name with a space in it?
I rather not have filenames with spaces if it means having a language that allows me to communicate with my machine in a terse manner, allowing for super-easy automation of all sorts of interactions.
I mean, are you really suggesting to mandate quoting of all strings in a shell language? The quotes are optional. That's good! In a shell language, files are basically your variables, so why would you want more syntax around your variables when working interactively?
Re: Why don't we have Wayland on Raspberry Pi yet? (2018)
#69I've been using swaywm on my laptop (XPS 13) with XWayland disabled for a few months now and have had very few problems with it. As far as I can tell Firefox works perfectly, except for some very strange behavior if I try to enable hardware acceleration. I love how easy it is to configure via config files, external monitors work great, scaling on HiDPI displays has been totally painless. My days off fiddling with xor…
That is encouraging. What distro are your swaywm and Firefox running on?
I'm running Arch, which I find to be the most frictionless when you're trying to do sort of "bleeding edge" stuff like this.
Re: Why don't we have Wayland on Raspberry Pi yet? (2018)
#70This rant would be better directed at the landscape of cheap, poorly-supported ARM devices like the Raspberry Pi and its clones. These manufacturers should be developing proper GPU drivers for mainline with full KMS/DRM/mesa support before they even sell their boards to the public claiming Linux support. Wayland and Xorg work just fine on Intel integrated graphics, Intel has been setting the standard here for over a…
Some clones are better than others. This kernel https://github.com/TinkerBoard/debian_kernel supports DRM/KMS quite well.
Don’t know about Linux desktop, but for my embedded use case where I build stuff directly on top of drm, kms and gles, it works fine driving 2 displays, one of them is 4k.