SDL2 Lands Support For Client-Side Decorations On Wayland

[oiaohm]

The X Windowing system wasn't designed to avoid color graphics. Try again.

Sorry to say you are wrong. X11 was designed to avoid colour graphics up until version X9. Color graphics existed before X9 X11. Problem here was every vendor graphics card that did colour had different palettes in that time frame. So yes x1-X8 color graphics was was intentionally avoided with black or white or grey scale as the only 2 options. Yes grey scale palette was some what close between vendors.

https://utcc.utoronto.ca/~cks/space/blog/unix/X11PseudocolorAndWMs

Yes the palettes issue makes another fun problem with X11 in X9 and newer when you have globally shared palettes even today that can cause a nightmare of the worst screen flicker you have ever seen when two applications get the idea they want to change the colour global palette to their own then fight over over it when it not there one. This is quite a dangerous problem that can trigger epilepsy(remember this is about 3 percent of the population so not small number). This is another reason why we need to be able to run a X11 server per application so valves like color palettes that don't need to be global any more are not global any more. Note this cannot be a per process solution either.

Yes X11 at first avoid color and then has horrible implemented color wrong for modern hardware that results in a very dangerous flicker problem at times. Yes when hardware was more limited the flicker problem was not exactly avoidable also computers were not used by the great number of people so cutting out 3 percent of the population due to design defect back then was not a problem. Today this issue has to go away due to increase requirement for people to use computing devices so the 3 percent with epilepsy cannot always avoid computer usage.

There are reason for the push to XWayland running on top of the Wayland compositor. One of reasons to to allow individual instances of X11 per application so fixing up this problem.

[krzyzowiec]

OK, it's clear what territory we're heading into and this wouldn't be a productive use of my time. Enjoy believing you're right.

I believe that’s called projection.

Sorry to say you are wrong. X11 was designed to avoid colour graphics up until version X9. Color graphics existed before X9 X11. Problem here was every vendor graphics card that did colour had different palettes in that time frame. So yes x1-X8 color graphics was was intentionally avoided with black or white or grey scale as the only 2 options. Yes grey scale palette was some what close between vendors.

When I say avoid, I don’t mean “didn’t implement”, I mean they see it as a bad practice not to be encouraged. Everyone could see even at that time that color support was a good and necessary thing.

In this case, we’re talking about splitting a window into two separate parts, and then having them be rendered by two separate things and then stitched together, as opposed to a window rendering itself completely. Which approach is simpler? Obviously the latter.

[oiaohm]

When I say avoid, I don’t mean “didn’t implement”, I mean they see it as a bad practice not to be encouraged. Everyone could see even at that time that color support was a good and necessary thing.

between X7-X8 there were 22 vendor submits to support colour on their hardware that was rejected in the X11 development process. No what you just wrote is wrong that everyone could see that color support was a good and necessary thing. In that time frame there was a arguement that grey scale was good enough because there were not color printers either. So what reason was their for color on the screen when you could not print it anyhow. So that time frame did not see color support as a good and necessary thing this is you looking back with your current day bias its a very different world when you don't have color printers and your graphics card color support was not formalised in any sane way. Color support in hardware how to-do it was still being sorted out in the 1990s.

In this case, we’re talking about splitting a window into two separate parts, and then having them be rendered by two separate things and then stitched together, as opposed to a window rendering itself completely. Which approach is simpler? Obviously the latter.

What one provides information for security in a useful way. There is a reason as qubes OS demos for forced SSD. Rendering as two separate things has advantage when you are doing that for a security reason to provide context information to user what security privilege X application is running at.

CSD has advantage of being simpler. Full SSD as the option of providing users with trust-able security information about applications. The mix in the middle between SSD and CSD ends up with the worst of both options.

[renox]

In this case, we’re talking about splitting a window into two separate parts, and then having them be rendered by two separate things and then stitched together, as opposed to a window rendering itself completely. Which approach is simpler? Obviously the latter.

Simpler != always better
Simpler is good for embedded usage which was Wayland initial target.
But it isn't good enough when you want a secure desktop like Qubes OS does.

Also for desktops which shows windows with shadows, stitching together buffers in the compositor is a rather logical design no?

[krzyzowiec]

Simpler != always better

Simpler is always better, especially from a security standpoint, but also from a maintenance and feature development one. In programming there is never a situation where simpler is not better.

What one provides information for security in a useful way. There is a reason as qubes OS demos for forced SSD. Rendering as two separate things has advantage when you are doing that for a security reason to provide context information to user what security privilege X application is running at.

But it isn't good enough when you want a secure desktop like Qubes OS does.

I honestly believe using QubesOS is crazy. It reminds me of the paranoid l1d cache flushing on context switches. Or people who talk about using expensive equipment to analyze encrypted hard drives. There are many easier ways to compromise security that don't even involve someone's operating system, or a computer for that matter.

Also for desktops which shows windows with shadows, stitching together buffers in the compositor is a rather logical design no?

It's certainly not illogical, but if I'm already making my windows draw themselves, why not have them draw their own shadows as well? Logically a shadow is just additional space around an existing window.

[ssokolow]

Simpler is always better, especially from a security standpoint, but also from a maintenance and feature development one. In programming there is never a situation where simpler is not better.

Go run MS-DOS then. It must be the most secure, maintainable, feature development-friendly mainstream OS to ever run on PC Compatible hardware.

For those who are too thick to get the underlying message, I'll refer to the famous Einstein paraphrase, "everything should be as simple as possible, but not simpler". Of course you can make things simpler by arbitrarily punting on responsibility for things end-users need and declaring the end-users wrong.

That's how Stallman gets away with saying GNU contributes a significant enough part of "the Linux OS" for it to be called "GNU/Linux". He defines "the operating system" to exclude a GUI and include GCC and terminal-mode GNU Emacs, because his definition of an operating system is "everything you need for self hosted development and nothing more".

(Spoiler: Last time I saw someone tally things up, X11 was bigger than all the GNU componentry combined, and GCC is a huge part of the GNU line-count that only nVidia users need on a typical desktop OS... and this was before more and more of the userland started moving under the systemd umbrella.)

[oiaohm]

I honestly believe using QubesOS is crazy. It reminds me of the paranoid l1d cache flushing on context switches. Or people who talk about using expensive equipment to analyze encrypted hard drives. There are many easier ways to compromise security that don't even involve someone's operating system, or a computer for that matter.

The problem is not all use cases of the Linux desktop are 100 percent sane.

http://linuxgizmos.com/u-s-military-uav-control-systems-switch-to-linux/

Its really simple to forget the Linux desktop is also used for controlling military UAV with live weapon systems and this is only one example of high questionable computer usage where Linux is. Yes the more dangerous the risk the more paranoid can seam to be.

Yes there may be simpler ways to breach security but when you get into the military complex they will use every single option they can including options people would normally class as expensive/hard.

It's certainly not illogical, but if I'm already making my windows draw themselves, why not have them draw their own shadows as well? Logically a shadow is just additional space around an existing window.

Depends if you want those shadows transparent effect or not. Wayland for security attempts to make sure application cannot see anything other than themselves without permission. So drawing transparent shadows can be a major problem.

[Jaxad0127]

Depends if you want those shadows transparent effect or not. Wayland for security attempts to make sure application cannot see anything other than themselves without permission. So drawing transparent shadows can be a major problem.

Transparent images don't seem to have that problem. Why should an application draw buffer be different? Just allow an alpha channel and make sure you composite it correctly to avoid leaking info to the app.

[ssokolow]

Transparent images don't seem to have that problem. Why should an application draw buffer be different? Just allow an alpha channel and make sure you composite it correctly to avoid leaking info to the app.

What about Aero Glass-style blur effects? The window may be able to use an ARGB visual, but the compositor still needs to be responsible for accessing the pixels below it and applying a blur effect. Sooner or later, you get back to "If we have to get the compositor involved anyway to achieve what we want, why not just let the compositor do it all and gain some robustness in the process?"

[renox]

Simpler is always better, especially from a security standpoint, but also from a maintenance and feature development one. In programming there is never a situation where simpler is not better.

Sigh, as ssokolow wrote: use MS-DOS then, it's much simpler than Windows or Linux..

I honestly believe using QubesOS is crazy.

And I believe you didn't fairly evaluate it (probably because it shows that Wayland's design is *too simple*), what's the alternative for a 'secure' desktop OS?
Rewrite everything in Rust? Well, you'll have to wait a long time, in the meantime QubesOS is here now.