Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wayland on OpenBSD

xenocara.org

Post reply on HN
Print view View original

141–150 of 214 posts

Re: Wayland on OpenBSD

#141

Post by vetinari »

rcxdude wrote: post #140
vetinari wrote: post #93

Earlier quoted context omitted.

Things "worked" by the virtue of being able to snoop on everything and inject anything; which is exactly what is wrong about the approach. On the other hand, Rome wasn't built in a day either. You want to do it right, not quickly. The final solution will be there for decades, so it better be not drag on maintenance and further development. Especially one, where the requirements are not so clear (no, register random k…

Sure, but you can understand why people are not so keen on moving to an unfinished system, then? Or at least one which has not yet reached parity with its predecessor for a large proportion of its users. Remember the excel effect: each feature which was previously implemented by snooping and injection may only have a small number of users, but there are many of them and most users will use at least one of them. If yo…

It is never finished; there's always something missing. It took X almost 4 decades to get where it is and during the ride it was abandoned as a mess. It was never finished either.

We see also arguing that something is missing, while it was there for years (like screenshots and capture), or nitpicking on global shortcuts. Global shortcuts are so incredibly long tail feature, so pointing it out is actually a a good thing. It means that Wayland is already here and nobody can find anything better or more important to point out (if it were up to me, I would agree with you on color management, but that is something that X never really had).

App support is something entirely different; apps like Krita can run under Xwayland just fine and transition on their own schedule.

Re: Wayland on OpenBSD

#142

Post by mananaysiempre »

kelnos wrote: post #2

I know this is just a "hack it together" effort, but I wonder if it even makes sense to emulate/support libevdev and libinput on non-Linux OSes. While the Wayland protocol does reuse some libinput names/enums/etc., I don't believe there's anything in it that requires those particular implementations or APIs (that is, wl_pointer and wl_keyboard doesn't have to be populated by libinput). Maybe wlroots should have OpenB…

> Maybe wlroots should have OpenBSD-specific parts to its backend abstraction that use OpenBSD's usual input handling primitives.

My (shallow and likely out-of-date) impression was that wlroots the library baking in Linux things was a more serious problem for porting than Wayland the protocol actually mandating anything seriously Linux-specific (I understand how the choice to use Linux key codes might be annoying, but still, meh). Have they gotten around to excising the event loop library out of there, for example?

Re: Wayland on OpenBSD

#143

Post by kaba0 »

didntcheck wrote: post #139
kaba0 wrote: post #78

Earlier quoted context omitted.

Gnome is not your window manager - it’s your display server. You can trivially install/write an extension to manage your windows differently and reuse everything gnome provides for example. A wm has always been trivial compared to a display manager, people just mistake one for the other.

Yes that's the point I'm making. It is now a display server. On X it was just a desktop environment. Traditionally that comprises * A set of utility X applications, like a panel and launcher * A recommended window manager * A recommended display manager And then this all runs on top of a separate X display server Generally the last two are easy to replace, for example I have used both Compiz and Xmonad on Gnome 2 and…

The Firefox one might be a good analogy to continue: a window manager is akin to a web extension. They are browser-dependent, a firefox one won’t work on chrome, and vice versa [1]

Gnome/KDE/wlroots are akin to separate browsers implementing the same (HTTP) protocol. It’s a lot of work, plenty choose to rather fork an already existing code base (chromium based ones), but with time people will consolidate on a few ones. But you surely wouldn’t want an all-Safari, or all-Chrome browser “ecosystem”, right? (Though unfortunately we are not far from the latter). That’s what Xserver gave practically.

[1] There is some compatibility but let’s forget about that for now.

Re: Wayland on OpenBSD

#144

Post by yxhuvud »

pravus wrote: post #114
kaba0 wrote: post #72

Earlier quoted context omitted.

Yeah, please repeat the same bullshit for the umpteenth time. This happens under every goddamn wayland-related thread from people who have never ever touched anything graphics related with this typical cocky attitude - at this point this is just fake news. So if X is so great, why exactly have the very developers who worked on it all switched to Wayland? Like, if they could made something you believe is good, shouldn…

> Yeah, please repeat the same bullshit for the umpteenth time. I'm currently streaming X11 over my LAN which is something I can't do with Wayland. Give me a fucking solution instead of telling me I'm doing it wrong. Yes, I'm tired of seeing all this bullshit, too. I'll switch immediately when Wayland gives me want I need to make me productive. Until then, I'm absolutely sick of this cocky attitude.

Eh, that has been possible for a while.

See https://gitlab.freedesktop.org/mstoeckl/waypipe

Re: Wayland on OpenBSD

#145

Post by erik_seaberg »

bitwize wrote: post #45
badsectoracula wrote: post #25

Earlier quoted context omitted.

I haven't tried it (because i do not really need network transparency and i'm using Xorg anyway) but supposedly this project[0] implements the Wayland protocol on top of Xorg in a way that integrates mostly seamlessly with X11-based desktops (instead of creating a window and running Wayland inside it as if it was a monitor isolated from the rest of the desktop). It might be useful to be able to run Wayland applicatio…

Waypipe can run Wayland applications remotely in a more modern fashion that doesn't suck ass on all but the fastest network links. But this will be a useful stopgap for those who stubbornly cling to X11 (or are forced to, e.g. by NVIDIA hardware) as more and more useful software drops X support and goes Wayland-only.

Waypipe requires software rendering from any server that doesn't happen to have its own headless GPU. As long as Wayland doesn't deliver a remote rendering protocol, the best path forward seems to be shipping Javascript apps to a browser on the end user's machine (where his GPU will be available).

Re: Wayland on OpenBSD

#146

Post by teekert »

bandrami wrote: post #99
teekert wrote: post #70

Earlier quoted context omitted.

When I'm on Gnome, and I select Gnome on X, my trackpad functions as one expects from Linux. When I'm on Wayland, it's like a macbook.

And can't be configured. The loss of function for clickpads is particularly egregious; they're basically unusable under Wayland.

It's funny how I finally find my touchpad usable under wayland ¯\_(ツ)_/¯

Re: Wayland on OpenBSD

#147

Post by andrewaylett »

SoftTalker wrote: post #32
kiwijamo wrote: post #28

Earlier quoted context omitted.

I use Wayland daily and haven't run into the issues you mention. It has worked better than X11 as a daily driver for a few years now. I appreciate may not work for some To be honest I associate 'barely usable' more with X11. I haven't forgotten the good old days when I had to hack various configuration files just to get a working desktop and then hack some more to work around issues with tearing, video acceleration,…

Your memory of config file nightmares (I had them too) is a decade old now. X11 works without config for the vast majority of users. Yes it took a while to get there, but it's been there for a good while now and not really anything for Wayland to point at as a differentiator.

Indeed, given it's often the same developers working on both, a reasonable amount of the effort put into getting X to work without needing configuration was people actually working on Wayland but also taking the time to pull X along for the ride where possible.

X has a lot of code in it which needs to be elsewhere in the design envisaged for Wayland. Once support (for example, for kernel mode setting) is available for Wayland to use it, it makes a lot of sense to also use it with X.

Re: Wayland on OpenBSD

#148

Post by ranixon »

orbital-decay wrote: post #76
growse wrote: post #59

Earlier quoted context omitted.

I disagree. The distro devs are pushing it because it furthers their mission, which on the face of it (for a lot of them) seems to be "ship software that works for people and have them stop bugging us". > However broken the past was, replacing it with something that is similarly broken but in different non-overlapping ways is not the proper way forward. That "opinion" is well founded. Most people don't care about net…

This is a strawman. There's a reason I mentioned color management in particular. Most people who aren't aware (even software developers) tend to make two assumptions: - that color management is needed for a tiny subset of users (those weird guys with printers and calibrators...). - that it can be delegated to 3rd parties or implemented later when the time comes. Neither of that is true. Color management is just anoth…

> that color management is needed for a tiny subset of users (those weird guys with printers and calibrators...).

Color management is need for full HDR support, it uses Wide Color Gamut instead of sRGB

Re: Wayland on OpenBSD

#149

Post by lproven »

zamalek wrote: post #8
hist_thr wrote: post #4

Earlier quoted context omitted.

Wayland is a replacement for X11 in the same way that a tricycle is a replacement for a tractor. They have thrown everything difficult out of the spec and only implemented the most trivial functionality around a security model which you must actively break to get actual work (like screen shots) done. That Wayland is 10 years old and still barely usable should tell you how far software developers have fallen in the la…

> They have thrown everything difficult out of the spec Not exactly, they have thrown out everything that almost nobody uses - such as networking. They have, however, added things that most people do care about - such as different HiDPI across multiple monitors and an extremely thin (low latency) render path. > That Wayland is 10 years old and still barely usable And that has changed in the past 2 years (with excepti…

« They have, however, added things that most people do care about - such as different HiDPI across multiple monitors and an extremely thin (low latency) render path. »

I keep hearing this: "they've added things people care about, such as..." then a shopping list of utterly irrelevant stuff I can't even see.

>1 screen with different DPI is THE ONLY thing Wayland does that I want.

I don't give a flying monkey about rendering pipelines, refresh rates, tearing, or any of that stuff.

If someone found a way to add variable DPI to Xinerama, job done, and I could continue to use X for another decade or two, and ignore the weird arcane stuff that the Wayland folks want and AFAICS nobody else cares about...

Just as with GNOME, or systemd, or OStree, or Flatpak, or almost anything else new out of Red Hat and its community in the last decade.

Re: Wayland on OpenBSD

#150

Post by tapoxi »

hist_thr wrote: post #4
themerone wrote: post #3

Earlier quoted context omitted.

I think this is about preparing for a post X11 future. As Wayland continues to mature, classic X will attract fewer developer resources. I think it will eventually start to suffer benign neglect, and stop keeping up with new hardware.

Wayland is a replacement for X11 in the same way that a tricycle is a replacement for a tractor. They have thrown everything difficult out of the spec and only implemented the most trivial functionality around a security model which you must actively break to get actual work (like screen shots) done. That Wayland is 10 years old and still barely usable should tell you how far software developers have fallen in the la…

Taking a screenshot isn't breaking the model, it's using a portal. It just means that instead of every application having complete access to everything on the display, you move the trust to the compositor.

I'm not a Windows user, but macOS behaves the same way. If an application wants to capture the screen, you need to give it explicit permission to do so.

Post reply on HN