Wayland Ported To DragonFlyBSD (phoronix.com)

An anonymous reader writes: Wayland 1.9 and the reference Weston compositor have been ported to DragonFlyBSD. Significant changes were made to get Wayland/Weston running, and you must either already be running an X.Org Server or be using the Linux-ported Radeon and Intel kernel mode-setting drivers, plus jump through a few setup steps.

Comments

Re:I find it amusing

[Anonymous Coward]

Yada yada, yoda yoda. Get this. There are some of us that spend their nights and weekends making free software. You don't have to use our software. Distributions don't have to package our software. But they do, and no matter how many swear words you know is not relevant. The distributions make their own decisions and if you don't like that then you can start your own distribution with just the software you want. End of discussion.

Re:I find it amusing

[bluefoxlucid]

Old init ran init scripts. New init manages complex dependencies, makes sure the system state stays proper, journals failures, and generally does a lot of system component integration. People prefer cobbled together over complex architecture.

Re:I find it amusing

[Lunix Nutcase]

Plenty of people are asking why we want to fork lift X out for something completely different.

And how many of them are current X.org developers? Because most of the Wayland developers are long time X.org and previously FreeX86 developers.

Lots of people are arguing the handful of real and actual problems that do exist with X can by solved by adding (some of which has already happened) a few more extensions and that if you don't care about the old X protocol stuff well don't use its mostly harmless to you just sitting there.

Then those "lots of people" should put up or shut up. On the other hand, the people who actually have been trying to do that with X.org for nearly a decade say its horrendous and thus that's why they're working on Wayland.

Re:I find it amusing

[PPH]

These days, the X server doesn't do anything,

What about receive connections from remote x clients and put them on the display.

Linux/*NIX is used for more than gaming. Shocking, I know. But you'll get over it.

Re:I find it amusing

[PPH]

install both X11 and wayland and run one or the other

And what happens when some major app switches to the Wayland libs, leaving X networking behind? Sure, there's an X compatibility layer. But given the attitude of Wayland supporters ("nobody networks clients anymore, so lets throw this stuff out") I don't anticipate support for that feature to be long lived.

There are too many people running around, both in the systemd and Wayland camps who think that, because they don't do something or understand it, it just doesn't need to be done. Why don't we all take up a collection to buy them GameBoys or XBoxes and keep them away from important systems stuff?

Re:I find it amusing

[serviscope_minor]

The trouble with Wayland, or rather why I'm deeply suspicious of it is that some of the claims from the devs about wayland and X11---and bear in mind they're X11 devs too---are flat out wrong at best and deeply deveptive at worst. Why the need for a FUD attack? If Wayland is better it ought to win on merit, not FUD.

Tahe for example this article: http://www.phoronix.com/scan.p... [phoronix.com]

Going through one at a time.

1. Extensions are what X11 calls API updates. Wayland will get API updates too, so this is not an advantage of wayland beyond version 1.0.

1. A, B, C: Almost all extension version updates add new API calls and keep the old ones. Sending Foo 2.0 calls to Foo 2.2 works just fine. Not to say that versioning isn't a problem, but then fixing the API is apparently bad for X but nothing else.

2. Well core X11 is super simple and a tiny setup of Xinput 2. This leaves essentially 2 input systems left of any complexity, 2.2 and 2.0, and as far as I can tell 2.0 isn't actually separate from 2.2. So, basically X has one major input system which actually looks kinda similar to the Wayland one.

3. That's a misunderstanding of "mechanism not policy"

4. So Xorg and Xfree86 got a bit crazy and then got refactored. Apparently historical cleanups are a bad thing? This happens in any project of any age.

5. Apparently it's impossible to add a new API call for synchronisation because from (1) that X11 isn't allowed api updates unlike every other system.

6. Yeah OK, fonts are not great.

7A A badly designed chunk of Xorg is apparently a problem with X11 now. Oh and it's been fixed so it's not a problem at all. But apparently every misstep in one implementation of an X server fixed 5 years ago is a reson it's bad now.

7B That was pure fud in 2013 when it was written. Xrandr and monitor hotplugging has worked flawlessly for years.

7C Huh? There's been xrandr front ends for years which remember certain layouts. Hell, Arandr, the nice GUI point and click one in all the repos remembers layouts just fine.

7D That smells like bullshit to me. Unless the second monitor is a separate screen (X11 term for something little used now) they it'd be impossible for one to have compositing and one not. I've not heard of anyone using screens in years.

8 Yeah and real toolkits are poorer for it. The window tree is a really nice thing when you have latency. Because with tree'd systems the server remembers which sub-sub-sub window a mouse click went to, and you could ignore the absolute position. With a treeless system all you have to go on is the position.

With latency, if you click, then the display updates then it processes the click, your click goes not where you want, but where the GUI is now. This I find happens more often than I'd like in web "apps". With tree based systems, sure the widget moved, but the assignment of the click to the window was latency free, so your click ends up correctly on the now-moved widged.

IOW tree based systems are superior. Many toolkits abandoned it for compatibility with non tree based systems. What we have now is actually fundementally worse in high latency environments.

9 Yes this is finally a genuine, no-nuance flaw.

10 C this is not correct if you have a compositing window manager, because it can do whatever it likes with the final display.

10 D their solution is to make the compositor do all this shit in Wayland. That could be done equally well in X. Sure, the current convention has a small flaw, but X11 now supports the Wayland way too.

10 E just use the features of the compositing window manager. It intercepts all key presses and windows anyway.

So without getting into the merits or demerits of Wayland, it's disappointing to see the devs engaging in a colossal FUDstorm.

RDP is NOT a replacement for network transparency

[billstewart]

RDP is simply not an adequate substitute for a network-transparent window system. Yes, it'll let you do some things badly, and other things mediocrely, but that's about it. And I haven't seen any evidence that the Wayland folks understood that early on, so I haven't kept up with Wayland when there's working X.Org.