241–250 of 518 posts
Earlier quoted context omitted.
NVIDIA doesn't support GBM, which is the standard for buffer allocation. Use nouveau. >The last issue could be solved with a reusable library that provided basic compositor functionality for window managers. This is pretty much what wlroots is.
> NVIDIA doesn't support GBM If Nvidia don't support it, how much of a useful standard can it really be?
I would use Wayland, but the most actively-developed tiling window manager, sway, doesn't work with the NVIDIA graphics card I own. And come to think of it, isn't that a really weird problem to have? On X, the compositor (responsible for actually drawing all the windows on the screen) and the window manager (responsible for deciding how to arrange the windows and what their title bars/borders should look like) can be…
Or wait until Intel will release a new GPU next year, it should work well with upstream too.
Nvidia has no interest in making their cards play well with Linux, so just avoid them completely to keep your sanity and don't waste your time trying to work around their mess.
Going forward, DE / compositor developers will support Nvidia use case less and less (due to Nvidia market share taking a further dip on Linux and Nvidia still not upstreaming their driver). So save yourself the trouble already today.
Earlier quoted context omitted.
> On one boot I had an issue in init.el which caused emacs initialisation to hang, so the root cause wasn't systemd. But systemd didn't fail gracefully (or informatively) in this case. And it took me a while to figure out why systemd wouldn't bring up any services, since it wasn't reporting to me that the emacs service (or any service) had failed If it’s hanging it hasn’t failed. If that daemon is configured as a blo…
But as far as I can tell, the Emacs daemon shouldn't be a blocking dependency. Here's the systemd unit definition I would have been using at the time: https://wiki.archlinux.org/index.php?title=Emacs&oldid=46958... . And here's a more recent one: https://wiki.archlinux.org/index.php/Emacs#As_a_systemd_unit . Neither of these should be blocking dependencies, should they? `WantedBy=default.target` doesn't make it block…
in which case systemd is doing exactly as it's told.
Edit: That linked unit is for user level systemd, so it shouldn't be involved in the system boot at all.
Earlier quoted context omitted.
The problem is that wlroots is one of several libraries with this goal. Say I wanted to roll up my sleeves and implement NVIDIA's proprietary interface myself. (Or say in a few years we come up with some new, even better way to allocate buffers or whatever.) On X, I can write a compositor that uses that interface, and it'll work with basically every window manager written since the early 90's. On Wayland, I could pat…
>The problem is that wlroots is one of several libraries with this goal. The only successful one, to be clear. You would be unwise to base your compositor on any of the others (libweston, wlc, swc, etc). wlroots is suitable for basically any use-case.
Except the single largest GPU vendor, yes.
Earlier quoted context omitted.
> NVIDIA doesn't support GBM If Nvidia don't support it, how much of a useful standard can it really be?
NVidia has a horrible history of Linux support. GBM works just fine, they've simply chosen not to support it.
Earlier quoted context omitted.
It's an nvidia problem, not a standard problem.
This is a standard problem. You can't be a standard if the market does't care about you. You are just a specification and guidelines.
One of the comments on the article ( https://utcc.utoronto.ca/~cks/space/blog/unix/XDeathwatchSta... ) is also possibly of interest, suggesting possible technical routes for using existing windows managers on Wayland: > There is XWayland, and apparently it will support handling the root window, not just application windows: https://wayland.freedesktop.org/xserver.html > The missing piece of the puzzle is Xweston, whi…
Again -- XWayland is Xorg. The xorg-server codebase contains a number of components, one of which is a front end called DIX (Device Independent X) that handles protocol-level stuff, another of which are several backends collectively called DDX (Device Dependent X) that handle drawing to the actual video hardware or other graphics layer. One of these DDX backends is 'xwayland'. So the XWayland server incorporates the…
Well doesn't that mean XWayland will be easy to maintain since it has no hardware dependencies? X can completely stagnate so long as the Wayland back-end is kept up to date with any changes there - and no, people don't want to be changing Wayland protocols because every compositor would have to be updated. I think XWayland will be around for a while yet, but I'd rather have things run native Wayland.
Earlier quoted context omitted.
It sounds weird to me to claim the Wayland ecosystem is less modular than the X ecosystem. With X, you're depending on one huge monolithic display server implementation; with Wayland, you can switch display server at will and they all conform to a common protocol. I get the concern that most of the functionality which used to be in separate programs is now bundled with the Wayland compositor, and I used to share it,…
With X, you can switch your display server as well (and there were proprietary X server offerings available as late as the late 90s/early 2000s). It's just that Xorg, being internally more modular than XFree86, sapped the value add of redoing the entire X server and effectively "won". In fact, with X you can switch out your display server and keep your window manager. Can't do that with Wayland -- by design. Now who'…
Earlier quoted context omitted.
HiDPI. It's somewhat unusual for a top end laptop to have 1920x1080 screens these days, and Wayland doesn't support 4k very well. You can upscale, but it looks like garbage, or it has a 2x mode, which draws image and such slightly too large, or you can deal with everything being tiny. For gaming, the latency is bad and always on vsync is horrible. They've fixed the 60Hz lock though, fortunately. This only applies to…
A lot of what you're saying seems due to a particular Wayland compositor, not to Wayland.
Earlier quoted context omitted.
Thank you, I hadn't heard of it before so I'll check it out! I'm not optimistic about Wayland, since early on they decided not to use an extension language, and that's not something you can have a change of heart about later, and then just nail onto the side. It would be interesting to see how Arcan uses L ua, which is a great language for that kind of stuff. It's a lot smaller and sleeker and better designed than Ja…
>> I'm not optimistic about Wayland, since early on they decided not to use an extension language, and that's not something you can have a change of heart about later, and then just nail onto the side. I don't see a need for an extension language for a compositor. A miminum of DE features will be implemented in Wayland compositors and everything else will be other programs - write them in what you like. Or am I wrong…