Taiwins Wayland Compositor Switches From WLROOTS To Its Own Library

[t.s.]

When I referred to you as a troll, I[t] wasn't mean[t]ing to be [an] insulting. It's just an observation..

..and I can string a sentence together without making multiple grammatical errors. Seems like trolling is all you have.

Yeah, no insult. LOL. FYI. English is not my primary language, rarely used (written), and is self-taught. Let's see if you can self-taught language(s) and use it without making multiple grammatical errors, smart boy

BTW, maybe your grammar is good. But your comprehension is bad. You even not knowing what the meaning 'trolling' is, as you said 'someone is trolling' != insulting him/her. Figure!

Let me help you with the meaning of 'trolling': https://dictionary.cambridge.org/dic...glish/trolling

[t.s.]

This is a huge stack of mistake. Docker bars are unique per X11 DE and not in fact part of the X11 protocol in most cases. System tray is a good example.

..X11 protocol does not offer all the interfaces at all. Lot of the interfaces offered by X11 are broken and deprecated so other parties have implemented there own.

The amount of stuff that has come superseded/broken in X11 is massive.

Yep, that's why it's more efficient if X Foundation create specification for that too (maybe with application that handle that function, leveraging the API), something that we can have a 'default', like:
- Notification
- Docking
- Systray
- Task Manager
- System info
- theme?
Separate crucial part, main part, and optional part. Make it modular, so, if project not needing it, they can omit that part.
if we did it right, maybe we can use, say, gnome tray on lxde. Capture gnome + theme + screen from plasma. With efficient bandwidth (similar to windows RDP)

Notice something the replacement does not depend on X11. its neutral between wayland X11 or TTY. There is a long list of items that were implemented in X11 that are now super-seeded by something that uses dbus.

Yep, it should be done like this.

[dkasak]

<trolling snipped>

I will now respond to everything you said that wasn't trolling:

[oiaohm]

Yep, that's why it's more efficient if X Foundation create specification for that too (maybe with application that handle that function, leveraging the API), something that we can have a 'default', like:
- Notification
- Docking
- Systray
- Task Manager
- System info
- theme?
Separate crucial part, main part, and optional part. Make it modular, so, if project not needing it, they can omit that part.
if we did it right, maybe we can use, say, gnome tray on lxde. Capture gnome + theme + screen from plasma. With efficient bandwidth (similar to windows RDP).

Lets take apart that list.

Result is almost zero is X11 dependable.

Notificaiton and Systray that work with the most X11 WM/DE are defined in freedesktop standards using dbus. Yes dbus as in neutral to X11 or Wayland. If you use the X11 versions of those you are only supported by some WM/DE and it was deprecated out of KDE and Gnome over 5 years ago due to them being broken.

Task Manager the X11 Task Manager is avoided. You don't see modern WM/DE for X11 supporting using the skull and cross bones on a window that is using the X11 task management because the X11 task management is so far broken that you really risk killing the wrong process completely as when a process crashes the X11 server has only recorded the PID number and another application after crash can have taken it place so you task management commands using X11 protocol provided goes to the wrong things. None of the WM/DE task managers are depending on the X11 protocol in this area at all instead using processing of platform process list.

System info guess what X11 does not provide this either.

Docking of windows there are lot of windows managers on X11 that attempt to do specialist docking of windows that end up cat fighting with applications that are also attempting todo their own windows placement. So this is a broken mess.

Theme was attempted to be defined in freedesktop standards in 2000 never has got major support. X11 protocol never defined theme and X11 server never contained anything theme. Please note server side decorations done by windows manager were a later add on to X11 this is why at times you would end up with applications doing client side decorations on X11 with a server side decorations wrapped around that there is no in fact stable standard with X11 to tell Windows Manager that you are doing client side decorations in X11.

Freedesktop

https://www.freedesktop.org/wiki/Specifications/

The reality here is a lot of things people are like X Foundation should do it. The horrible reality is majority of what they are saying is not historic X Foundation solution but Freedesktop work. Xembed that is under X11 to allow you to embed a window from a different application inside you application is not X Foundation or X11 standard but Freedesktop. Heck the reason why Windows managers under X11 have somewhat the same kinds of interfaces is Freedesktop as well.

Capture being generic this requires video card drivers to sort out there stacks to provide decent interfaces that are not X11/Wayland dependant. You can already do generic capture using libdrm but that does not work if you are using Nvidia binary drivers of course.

There are a long list of things that are really not Wayland Standard or X11 Standard problems but Freedesktop problems to solve. Yes the freedesktop defined standards are lagging in a few areas around Wayland. There are other items that like accessibility support that are not under Freedesktop or x.org either.

Yes there is a lot of yelling that Wayland should support X feature when you look closer X feature was never supported by the X11 protocol either but is instead something the person is getting from freedesktop or other parties work just due to being broadly implemented is being incorrectly thought to be part of X11 protocol. Items that are implemented currently on freedesktop if you went and put them in Wayland protocol it would be really simple to result in this comic https://xkcd.com/927/ with just another competing standard.

Lot of cases it really should not be Wayland should support X feature but why don't we have generic interface X feature that does not care if you are running X11/Wayland or TTY and how we are going to implement that generic feature.

Wayland is a good chance to clean up the house.

[t.s.]

..Lot of cases it really should not be Wayland should support X feature but why don't we have generic interface X feature that does not care if you are running X11/Wayland or TTY and how we are going to implement that generic feature.

Wayland is a good chance to clean up the house.

Well said! This is what I want to convey. Just can't explain it well.

What I want to say is, linux as of now is too fragmanted and not efficient. like compositor, every major DE creating their own compositor. Why don't they band together, casting their ego aside and create one very good compositor implementation that can be used across all DE. Same with other features.

[oiaohm]

What I want to say is, linux as of now is too fragmanted and not efficient. like compositor, every major DE creating their own compositor. Why don't they band together, casting their ego aside and create one very good compositor implementation that can be used across all DE. Same with other features.

There is a strict reasons why you don't want 1 good compositor idea.

I will just lay out a real world example with X11 and open source Nvidia driver nouveau this will play out the first problem/reason.

Reason 1. Abuse of the single compositor/server to mask over faults that should fixed.
Developers of Nouveau tell you to use their x.org driver over the modeset driver because the modeset driver one means X11 2d rendering is done with glamour using opengl that is going to hit issues in their opengl implementation because it has defects. Question is this really a fix to say use the nouveau targeted driver with X.org? The answer is strictly no because you use their driver and you run program running opengl that uses the same features as glamour you run into the same problems. This is very much the NZXT firehazard fix by putting in plastic screws instead of addressing the problem correctly. Yes Nvidia binary driver and screenshot tools others I could have made equal examples about fixing problems in wrong place

This is the first problem with everyone using the same server/compositor for graphical output its comes really simple to be masking over faults instead of fixing them correctly. There are a lot of cases where people are asking for more features in Wayland protocol where its really asking give as the ability to mask over this problem in the compositor instead of having to fix the problem in a correctly generic way.

Reason 2. Security faults.
You do want the ability to stop using your X11 server/compositor and use a different one if it has a major security problem until it is fixed. This has been a fairly recent problem if x.org X11 server has a problem what alternatives on Linux do you have had. In some ways for this you would prefer more fragmentation not less.

When I say more fragmentation I mean having compositor that share min amount common code so that a security fault effecting them all is less likely. This second also means we should be putting a high value in conformance suites and other items to ensure quality product is being made.

Lot of ways I would like to see a solid single conformance suite that all Wayland compositors have to pass including checking for things like threaded input and so on(so input processing in main thread with graphical process is straight up fail yes you can write tests to detect excess latency libinput developer embedded one). This could be a single thing it not a item end user will be running all the time that makes sure all Wayland compositors have some min quality standard.

We have freedesktop draft standards lot of those don't have conformance suite either. Really it would be good to be able to run a conformance suite and rate how good every Wayland compositor and X11 DE really is with real metrics instead of personal options. Yes we are missing something like the webbrowser acid test thing for the desktop.

Remember here you cannot really have 1 good compositor/desktop envornment without a good conformance suite to prove that it is in fact good and make sure all feature changes the resulting compositor is good. Its also how can we have correct copy paste.... an so on of we have nothing checking that it is implemented right and this requires automation because humans doing these test are error prone.

Really would not matter if we had 20 different Wayland compositors if they were all quality. Please note a good conformance test-suite would also weed the poorly developed ones out and encourage the poorly developed ones to merge. See I am not aiming for a single wayland compositor with this idea but that all compositors that remain existing be some form of quality. Yes a conformance test-suite over time can be demanding increasing quality.

[t.s.]

oiaohm,

Noted for compositor. If we still want to left compositor as it is, we must use agnostic part as much as we can. Like we do with notification.

Nate has example for that in commen section in (example: key-mapping & screenshoot): https://pointieststick.com/2021/01/3...5-21/#comments

I Agree with conformance test. Like Vulkan. But it's better if we have one implementation to fallback to. So, if every DE want to write their own compositor, go ahead. But write it according to the specs. Or.. you can use ours.

[oiaohm]

oiaohm,

Noted for compositor. If we still want to left compositor as it is, we must use agnostic part as much as we can. Like we do with notification.

Nate has example for that in commen section in (example: key-mapping & screenshoot):

People don't ask the question if the feature should be in the wayland compositor at all?

https://github.com/snyball/Hawck You can do key-mapping without being in the Wayland compositor., Please note this generic keymapping does not care if you are using X11, Wayland or console tty. So should keymapping be a wayland compositor feature possible no.

Screenshot is the same.

https://obsproject.com/forum/threads/experimental-zero-copy-screen-capture-on-linux.101262/

It is truly possible with open source drivers to screen capture generic way exploiting DMA BUF this should come true with Nvidia closed source when they release binary drivers supporting DMA BUF as well.

I Agree with conformance test. Like Vulkan. But it's better if we have one implementation to fallback to. So, if every DE want to write their own compositor, go ahead. But write it according to the specs. Or.. you can use ours.

No that plan does not work that was the X11 plan that leads us to only have X11 as x.org or nothing because vendors like Nvidia will only support the core compositor/server if they can instead of providing proper generic interfaces to their drivers.

Having generic input generation and screen capture is what you to make a proper conformance suite. Hawck there found that if you input too fast the output died in gnome due to everything being in a single thread.

[t.s.]

People don't ask the question if the feature should be in the wayland compositor at all?

https://github.com/snyball/Hawck You can do key-mapping without being in the Wayland compositor., ...

Screenshot is the same.
https://obsproject.com/forum/threads...-linux.101262/ ...

That's Nate experiences. Someone that have more knowledge than me about wayland + compositor and linux in general. I'm more or less believe what he's saying. You can discuss with him about your solution. Maybe your solution never occured to him, but I doubt it. But if it's true, then you'll helped him and all of us that in the future will using kde + wayland.

For me, like I said before, I'm all for having agnostic part rather than on compositor. If we can make do without compositor, and using just wayland + the part (that is DE/WM agnostic), why not? I'm happier that way. And I think everyone happier that way. Why must re-invent the wheel when we can use readily, stable part/library, right?

No that plan does not work that was the X11 plan that leads us to only have X11 as x.org or nothing because vendors like Nvidia will only support the core compositor/server if they can instead of providing proper generic interfaces to their drivers.

Having generic input generation and screen capture is what you to make a proper conformance suite. Hawck there found that if you input too fast the output died in gnome due to everything being in a single thread.

Like I said, we have one default implementation. If you want another, create one that suited your need. But make your other components conformance with the standard (so one can just swap your components with the default one if they want). If one is to deviate from the implementation, go ahead. But if they do that, I --and some other-- absolutely won't use their product except have no choices.

[oiaohm]

That's Nate experiences. Someone that have more knowledge than me about wayland + compositor and linux in general. I'm more or less believe what he's saying. You can discuss with him about your solution. Maybe your solution never occured to him, but I doubt it. But if it's true, then you'll helped him and all of us that in the future will using kde + wayland.

The concept of going direct for screen capture and custom short cuts was first put forwards by Kristian Høgsberg. Really you cannot get anyone who knows more about Wayland and with deep understand for what drivers provide than him. There are a lot like Nate who skipped over stuff that has been shown in examples. Some it comes from Nvidia saying that GBM/DMA BUF would not work for them so would come up with something different and Nvidia something different would mandate extra stuff done in the Compositor.

There is fight here pays to be aware of. Personally I would be pushing for generic interfaces nothing to-do with Wayland for screen capture and other things because that makes lot more sense long term. You don't really want a bug in processing screen capture to crash compositor also it would be highly useful at times if screen capture would work in case of crash of compositor both the ideal is screen capture and keyboard short cuts not part of wayland at all its not like they have to be.

For me, like I said before, I'm all for having agnostic part rather than on compositor. If we can make do without compositor, and using just wayland + the part (that is DE/WM agnostic), why not? I'm happier that way. And I think everyone happier that way. Why must re-invent the wheel when we can use readily, stable part/library, right?

This is in fact horrible wrong with the do without compositor. X11 bar metal server without a X11 compositor is still technically compositing the windows to screen adding at least a frame of over head so with X11 if you look closely you end up with two compositors stacked on top of each other this is what Kristian is attempting to avoid with wayland design.

This is also part of the problem people take about X11 compositor bipass this bi passes third party compositor but not the compositor in the X11 server. If you don't have compositor to link up multi windows into a single output you cannot have multi windows on screen at the same time. The way X11 protocol mandates screen capture means you have to have the X11 server make the composite image to capture it.

For virtual reality true no compositor is required this is where drm lease stuff is used where you are directly using libdrm means you are working directly without a compositor at all.

https://www.phoronix.com/scan.php?page=news_item&px=DRM-Leasing-Linux-4.15

Yes screen capture under X11 does not work for a DRM(direct render manager) leased screen this is what you truly have to use for a true 0 composited application under X11. Yes this means application using a DRM lease cannot be using X11 protocol to render on screen either..

Generic screen capture by DMA BUF we do need particular to capture true low latency stuff output the stuff that truly runs without a compositor between the application and output. Keith Packard is also another one of the people who has mentioned that screen capture does not have to be part of the DE or wayland compositor.

Its a good question to ask a person and point out they are wrong the following. If you are using X11 server on bare metal without X11 compositor are you compositor free? The correct is no because the X11 server it self is a compositor. Ideal world you want no more than 1 compositor loaded at a time.