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

191–200 of 214 posts

Re: Wayland on OpenBSD

#191

Post by Ericson2314 »

1MachineElf wrote: post #184
Ericson2314 wrote: post #7

We've been doing some BSD cross work with Nixpkgs. A hope is that if we can extend that to NixOS too, and then it should be quite easy to checkpoint and share work like this for anyone to reproduce and pick up the baton on.

Can you share any more information about the BSD cross work with Nixpkgs?

How to use it? Or what we've done?

For using it, you can try

  nix-build 'channel:nixpkgs-unstable' -A pkgsCross.x86_64-netbsd.libcpuid

  nix-build 'channel:nixpkgs-unstable' -A pkgsCross.x86_64-freebsd.libcpuid
For the gory details, check out https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specifi... and https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specifi...

Re: Wayland on OpenBSD

#192

Post by throwawaylinux »

bandrami wrote: post #98
throwawaylinux wrote: post #71

Earlier quoted context omitted.

The existence of Wayland does nothing to detract from the existence of X or its users or developers. Nothing stops anybody from maintaining and developing X. You can download and install X for your Wayland distro. Not sure that anybody who "has a problem" has stepped up to really do much about it (most X development in the past few years is to support Xwayland), so it can't be that much of a problem.

This is about OpenBSD, whose team continues to maintain and update Xenocara. If I had to guess I would guess that when Linux distro grow tired of the new shiny they will switch to a port of Xenocara for their display systems.

> This is about OpenBSD, whose team continues to maintain and update Xenocara.

Did you reply to the wrong comment? How does this address what I wrote?

> If I had to guess I would guess that when Linux distro grow tired of the new shiny they will switch to a port of Xenocara for their display systems.

Linux distros are not going back to Xorg. Xenocara is basically just that adapted to OpenBSD, but all the Xorg developers remaining pretty much work for Linux distros so if they did go back they would just switch to what they already package and ship today.

Re: Wayland on OpenBSD

#193

Post by lmm »

happymellon wrote: post #50
lmm wrote: post #37

Earlier quoted context omitted.

> Wayland on the other had has just worked right out of the box since Debian 11. With a compositor other than the Gnome one?

Well, that would imply that it's not a Wayland issue but a compositor. Or is all maths broken because I found a calculator that doesn't have a working addition key?

If one calculator model agrees with your answer and every other calculator model doesn't, I wouldn't have a lot of faith in that answer.

Re: Wayland on OpenBSD

#194

Post by throwawaylinux »

erik_seaberg wrote: post #145
bitwize wrote: post #45

Earlier quoted context omitted.

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).

> Waypipe requires software rendering from any server that doesn't happen to have its own headless GPU.

X has to do that with DRI and client side rendering too, doesn't it?

> 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).

Why does that seem like the best path forward? Seems crazy. For incidental things, admin, etc., software rendering would be fine. The right path forward for a high performance application that needs to ship data to a client that can render it would be to transfer that data, not the drawing of it.

Re: Wayland on OpenBSD

#196

Post by kaba0 »

bandrami wrote: post #97
kaba0 wrote: post #77

Earlier quoted context omitted.

> Screenshots and sharing the screen Works for years. And global hotkeys are not trivial - no, that “everything listens to everything” that X did is not a proper solution.

It's worked fine for X for decades now, so simply claiming "it's not a solution" is kind of silly. I get that people pretend they are afraid some nefarious program is going to scrape their screen, but since I don't use closed source software this just isn't a real worry. Also do keep in mind this is about more than global hotkeys; there are several accessibility paradigms that simply don't and can't work on Wayland.

As I have said many times, a good intentioned program with a bug only needs bad intentioned data.

A malicious PDF file is enough to break havoc with a simple memory bug, so unless you claim that open source is also bug-free, or that you don’t use any external data (but visiting this site already invalidates that assumption), then you are just being naive.

There is nothing inherent that couldn’t work with Wayland - there is nothing preventing the relevant teams agreeing on a new interface to broadcast accessibility information to the wayland server, that can thus share that with specific accessibility software (which is explicitly permitted to do it).

Re: Wayland on OpenBSD

#197

Post by bandrami »

oynqr wrote: post #195
bandrami wrote: post #155

Earlier quoted context omitted.

Notice I said clickpads. Touchpads work fine once you work around Wayland's bizarre fear of enabling tap-to-click.

s/Wayland/Gnome/g

IIRC the culprit is libinput, which worries tap to click is "confusing" for some reason. Which is why I use synaptics when I'm on X.

Re: Wayland on OpenBSD

#198

Post by badsectoracula »

shmerl wrote: post #173
badsectoracula wrote: post #130

Earlier quoted context omitted.

> Not really. KWin has Wayland specific paths that simply don't work on X What exactly do you refer to? Note that i meant the kernel APIs to drive the hardware as what i replied to was Xorg not keeping up with newer hardware, not toolkits.

I mean stuff like bugs with boot screen leaking data not being fixed with X and so on.

How does that have anything to do with X not keeping up with new hardware or using the same kernel APIs as Wayland for communicating with said hardware?

What you describe is a minor annoyance at most, not at all on the same level as being unable to use X because of newer hardware. Even if it isn't fixed, one can still be worked around or just ignored, but the other just makes the whole thing literally unusable.

Re: Wayland on OpenBSD

#199

Post by happymellon »

lmm wrote: post #193
happymellon wrote: post #50

Earlier quoted context omitted.

Well, that would imply that it's not a Wayland issue but a compositor. Or is all maths broken because I found a calculator that doesn't have a working addition key?

If one calculator model agrees with your answer and every other calculator model doesn't, I wouldn't have a lot of faith in that answer.

There is only one that doesn't agree with my answer. It's also historically the one that have been generally buggy, even when running under X.

They don't have the financial backing that Gnome does, but doesn't accept itself as a smaller project.

Re: Wayland on OpenBSD

#200

Post by badsectoracula »

lproven wrote: post #149
zamalek wrote: post #8

Earlier quoted context omitted.

> 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 ren…

> If someone found a way to add variable DPI to Xinerama

What does different DPI mean for you though?

Xinerama causes the server to report the same fake DPI across monitors for backwards compatibility reasons (last year or so Xorg was released with a better approximation for DPI but it apparently broke a bunch of programs so it was reverted in the next release), but applications that care about DPI can still use the RandR extension to obtain not only per-output DPI but all sorts of output-specific information.

The X server had functionality for years, from what i can tell the issue isn't on X11/Xorg/Xinerama/Xwhatever anymore but on the clients (toolkits, window managers, etc) to use it to do something useful.

Post reply on HN