ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
aswar002 has quit [Remote host closed the connection]
aswar002 has joined #wayland
ybogdano has quit [Remote host closed the connection]
Arnavion has quit [Quit: Arnavion]
ybogdano has joined #wayland
shankaru has quit [Remote host closed the connection]
shankaru has joined #wayland
GNUtoo has joined #wayland
<GNUtoo>
Hi, is it possible to run a graphical application as another user (not root) with wayland? If so what is a secure way to do that (for instance by only giving that other user access to the display and not all programs or users)?
<danieldg>
GNUtoo: connect to the socket as your user, then pass that open FD to the application using WAYLAND_SOCKET
<danieldg>
there are proposals for protocols to allow additional listening sockets (for sandboxing) but they're not part of the protocol yet
<GNUtoo>
ok, here I'm trying to do that from shell, so I'm unsure how to get a fd there
<GNUtoo>
Though if the idea is to give access to /run/user/1000/wayland-1 I might find a way to do that
<danieldg>
shell can't do it, but perl can
<danieldg>
it's easier in C, but almost any language that supports unix sockets and execve can do it
<danieldg>
just need socket+connect+setenv+exec
<GNUtoo>
That looks complicated to integrate in what I have, here I use a chroot to run applications from another rootfs, right now that works with the same user, but I'd like to execute an application as another user (for easier matching in ferm, a firewall)
<GNUtoo>
Anyway thanks for the information. I'll try to find more infos on how to make it reuse the same socket (after giving it permission on that socket file)
<danieldg>
you can always do what flatpak does and bind-mount the socket
<GNUtoo>
ohh good point, bind mount would work
ybogdano has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
<GNUtoo>
Is there some good reference documentation on all that?
<GNUtoo>
xhost + works but that's a bad workaround
<GNUtoo>
(for some reasons bind mounting /tmp/.X11-unix/ and /run/user/1000/* with the the right username doesn't work)
<danieldg>
no, bind-mount the socket only, not the whole user
<GNUtoo>
ok, that didn't work either
<GNUtoo>
I did touch /run/user/1003 (as user) + mount -o bind /run/user/1000/wayland-1 /path/to/chroot//run/user/1003/wayland-1 + chown on the /run/user/1003/wayland-1 file
<GNUtoo>
If I try xterm for instance (because it's simple to strace), it tries to open /tmp/.X11-unix/X1 (which is bind mounted in the same way) and then communicate with it and then it fails with "Authorization required, but no authorization protocol specified"
<danieldg>
sure, you need to xhost too if you use X
<danieldg>
xhost +SI:localuser:whateverusername
<GNUtoo>
strangely I get "Major opcode of failed request: 109 (X_ChangeHosts)"
<GNUtoo>
I'll try to create new users and try to debug that
<GNUtoo>
with xauth I managed to make it work finally, so it needed the bind mounts + xauth with the cookies
<GNUtoo>
Thanks a lot!!!
cool110_ has joined #wayland
cool110 has quit [Ping timeout: 480 seconds]
zebrag has joined #wayland
adarshgm has joined #wayland
adarshgm has quit [Read error: Connection reset by peer]
thevar1able has quit [Read error: No route to host]
thevar1able has joined #wayland
thevar1able1 has quit [Read error: No route to host]
Ampera has joined #wayland
<Ampera>
Quick question, what is the state of multi-GPU and Optimus/PRIME on Wayland? Assuming latest versions.
<Ampera>
I've been quite unhappy with how X handles multi-GPU (in that it basically doesn't), so I'm wondering if I might find salvation in Wayland
fahien has quit [Ping timeout: 480 seconds]
<pq>
Ampera, most aspects of that are not about Wayland at all, but the compositor you choose.
<pq>
I would think most of the actually Wayland bits are there now with the feedback update to the zwp_linux_dmabuf_v1 extension.
<Ampera>
That's the impression I got. My question is probably better rephrased as one about compositor support.
<Ampera>
I've made attempts in the past to get this working on KDE Plasma and Enlightenment, but found quite a lot of instability, even when just trying to get a single GPU working.
<pq>
Personally I only know about Weston, and there any multi-GPU support is still waiting in merge requests.
<pq>
Maybe try GNOME?
<Ampera>
I'm hesitant to, as I've never not had a bad time with GNOME. Regardless, I can give it a shot at some point.
<pq>
I know Mutter can do at least multi-GPU output, but I'm not sure how well it optimizes for Prime yet.
<Ampera>
I'm not wholly concerned with PRIME's typical implementation. My current setup uses nvidia as the primary screen/GPU, and then only uses what I think is considered reverse PRIME to enable the internal laptop screen when I need it.
<pq>
oh, Nvidia proprietary drivers? I have no clue about who supports what with those.
<pq>
what was wrong with Xorg though?
<Ampera>
Dynamic monitor reattachment is more or less busted, and traditional PRIME is very broken, either stealing 25-50% of performance, or breaking 3D applications entirely.
<Ampera>
It works fine if I take 15 minutes every time I get going to move around a few configs and manually set up my heads for that situation. Docking/undocking (thunderbolt) requires repeating this general process.
<pq>
Monitor layout management is up to the DE on Xorg too.
<Ampera>
I don't have a DE.
<pq>
maybe that's the problem them
<pq>
*then
<Ampera>
I effectively have null/manual layout management.
<pq>
well, yeah. Xorg does not do layout management on its own.
<Ampera>
Sure it does.
<pq>
Xorg only does what apps tell it through RandR.
<Ampera>
Well, depends on what you mean by, its own. The rat's nest of extensions and additions do that.
<Ampera>
Sure, but what makes that not layout management?
<Ampera>
It's not very dynamic, but it does what I tell it to.
<pq>
Xorg does not decide it takes a new output into use when it is plugged in. You need something poking at RandR to turn the newly plugged output on.
<pq>
or write the xorg.conf, but then that's totally static
<Ampera>
That's typically what I do.
<Ampera>
I haven't used a mainstream compositing DE in a couple years or so. None of them actually function as well as windowmaker.
<Ampera>
so it typically just ends up being a tradeoff of conveniences.
<Ampera>
leaving me wondering if I'm the only person actually overthinking their desktop /this/ much
<pq>
If you want to manually manage dynamic monitor attachment, I don't think that makes it "busted" in Xorg.
<Ampera>
That being said, this is not what's busted.
<Ampera>
The busted part comes with the inability to switch which GPU has what monitor.
<Ampera>
and that PRIME is pretty poor
<pq>
are you sure the hardware actually can switch monitors between GPUs?
<Ampera>
Nope
<Ampera>
I know it kind of can. If I disable the iGPU, all monitors are on the only GPU left. This would be fine, but it then breaks thunderbolt passthrough.
<Ampera>
This has been a sort of long running juggle for me. I have it in a usable state right now, but it's slowly trying my patience every time I basically have to coax it into working.
<kennylevinsen>
That requires a dedicated switch chip to work. Normal PRIME works by just having the iGPU own the output, with the dedicated GPU being headless or connected to auxillary ports only.
<Ampera>
I'm aware of that, and I know my laptop must have some sort of switching fabric. I just have no idea how to control it.
<pq>
have you played with vga_switcheroo? I think that was the switching thing...
<Ampera>
No, googling
<Ampera>
Like, I don't actually mind writing a small bit of code to automate this. I just don't know how to.
<pq>
I don't think Xorg would touch that switch.
<kennylevinsen>
Definitely not
<kennylevinsen>
I also don't recall any newer laptops using such switch chip, as it's not seamless and usually implies switching everything between GPUs, where modern PRIME just changes the render target per app.
<Ampera>
Yeah I can't seem to find the sys dir for it.
<kennylevinsen>
Is your bad multi-gpu/prime experience using internal or external monitors?
adarshgm has quit [Ping timeout: 480 seconds]
<Ampera>
both
<pq>
When passing a buffer rendered on one GPU to another GPU for display, there is always *some* performance loss compared to render+display on the same GPU. How much would be typical, I don't know.
<Ampera>
It destroys 3D performance by about half.
<Ampera>
For an RTX 3080 that's kind of bad
<kennylevinsen>
Often they connect external ports to the dedicated GPU, which gives a bonus penalty for PRIME stuff: render on dedicated, copy to integrated (primary) for composite, copy back to dedicated for scanout...
<Ampera>
This is a Thinkpad T15g Gen 2, for context
<Ampera>
The external ports are on the dedicated GPU, I can confirm that much.
<kennylevinsen>
yeah so for best performance on those you need "true" multi-gpu composite or to use the dedicated GPU as primary.
<Ampera>
Maybe I should try to focus more on why thunderbolt docking is so broken when just using the dedicated GPU. That seems like it might be the easier problem to fix.
<pq>
If you compare to Nvidia proprietary driver performance for render+display on the same GPU, I don't think that's even a fair comparison, because NVidia bypasses most(?) of the common graphics stack.
<Ampera>
compare what to the nvidia proprietary driver
<pq>
Ampera, your Prime experiments
<Ampera>
nouveau is unusable on 30 series cards
<pq>
if Nvidia proprietary has to interact with FOSS Intel driver, it cannot do its internal tricks, I assume
bruno_ has joined #wayland
<pq>
so comparing nvidia-exclusive to nvidia+intel-prime
<Ampera>
Well, what about reverse PRIME?
<pq>
I wouldn't know
<Ampera>
That's currently what I'm using. I have two "Screen" entries in my xorg.conf, one for nvidia, one for intel/modesetting. If I utilize the nvidia one, then the intel heads are still available for output, and I get full render performance (at least on the nvidia heads)
<kennylevinsen>
As long as the proprietary driver is involved in any way or form the answer is "idk", as everything it does is secret sauce.
<pq>
Ampera, that sounds good, right?
<Ampera>
I'm actually trying to remember what the problem with this was. I think it was just heads not working dynamically.
<Ampera>
I wonder if I could take the compositor logic from some other DE and apply it to mine.
<pq>
naturally heads won't work dynamically if you don't run any program that listens and uses RandR for hotplug events.
<Ampera>
Any idea if there's an environment agnostic such program?
<pq>
I don't know if Nvidia's driver does something automatically, but Xorg doesn't.
<Ampera>
nvidia's driver does actually have its own display management, sort of, but it is RandR complaint
<pq>
nothing comes to mind... but that's probably because I never look for one
<Ampera>
so I can control everything through xrandr just fine. I actually have to use xrandr to enable the intel display whenever X loads
<Ampera>
I mean, maybe if I can also just listen to display change events somehow I can script this all myself.
<Ampera>
That thought has come to mind, but I'm not sure how I'd do that.
* kennylevinsen
finds it slightly amusing that #wayland is being used for X11/nvidia assistance
<Ampera>
Well the original question was, can Wayland help solve this problem
<pq>
haha
<pq>
Wayland cannot, it's up to each compositor
<kennylevinsen>
Kwin or mutter might handle this well - don't they still have eglstream support?
<Ampera>
nvidia has GBM support now
<Ampera>
afaik anyways
<kennylevinsen>
For wlroots you'd rely on their new GBM support, and would have to pick the nvidia GPU as primary for full peeformance
<pq>
Wayland also does not offer scriptablity, so if your cmpositor does not do what you want (or offer scriptability itself), then Wayland won't work for you.
<kennylevinsen>
(but even when you pick it as primary you retain hot plug monitor support)
<kennylevinsen>
pq: maybe wr should have a bot that says "remember: Wayland is just a specification - a series of XML files" when you join. :P
<Ampera>
Alright, well, I think this was quite helpful. I have a few more ideas of what I can look for. Thank you very much.
nerdopolis has joined #wayland
<pq>
you're welcome :-)
<Ampera>
I both want to love and hate Wayland honestly. wlroots kinda gives me hope that this can be more modular than the monolithic nightmares that are KDE and GNOME.
<kennylevinsen>
There's many small compositors, and the variation is nice.
bruno_ has quit []
<kennylevinsen>
Even kde and gnome have the compositors as a standalone component that could be used on its own or be swapped out
<kennylevinsen>
(there's a kwin fork swapping the internals for wlroots for example)
<Ampera>
I'm occasionally tempted to write my own compositor. I'm sure X has plenty of time left, but I would love to bring windowmaker into the modern era a bit.
<kennylevinsen>
I run my own compositor - it's fun if you have an idea for alternative behavior
<kennylevinsen>
And you have a bit of time lol
<Ampera>
There's nothing else that's even remotely like it in terms of feel and function, imo. It combines the best of classic Unix icon metaphors, with the best stacking engine I've ever seen.
<Ampera>
just simple things like using super to maximize/unmaximize, modifiers+super to tile, while still being a stacking manager you can just grab and move things around with is something I've never seen done in that same way.
<Ampera>
Wayland is C right?
<pq>
Wayland is XML.
<Ampera>
I honestly have no idea how it even works.
<pq>
Wayland is a protocol specification, not an implementation.
<Ampera>
X is a network protocol, but utilizing various extensions, combined with a C library for clients.
<pq>
libwayland is in C, but it is very uninteresting, because it does only IPC and almost none of the implementation.
<Ampera>
Sure, X is a protocol specification too, with X.org being the most typical implementation.
<pq>
There is no single typical implementation of Wayland. There are a bunch of compositor libraries and client toolkit libraries.
fahien has joined #wayland
<Ampera>
Is there a server/client component?
<pq>
and projects that just implement Wayland themselves instead of using libraries
<pq>
yes, Wayland is client/server in concept.
<pq>
But there is no "the" Wayland server, or client.
<Ampera>
This is my main confusion, because in my mind a server and a client are implemented separately.
<kennylevinsen>
They are separate, "apps" are the clients, compositor are servers.
<pq>
yes, Wayland clients and servers are implemented usually separeately too
<Ampera>
Alright, that makes more sense.
<pq>
it's just that there is no single de-facto implementation of a server like Xorg is for X11.
<Ampera>
Alright, that clears things up significantly.
<pq>
Mutter, Weston, and KWin are all different Wayland compositors i.e. servers having nothing else in common that they all speak Wayland towards applications.
<pq>
*than
<Ampera>
Those compositors, however, still handle decoration and window management, though, right?
fmuellner has joined #wayland
<pq>
Yes, a Wayland compositor, equals Wayland server, does all of compositing, window management, input routing, and display.
<pq>
Decorations are drawn by clients themselves, unless both the client and compositor agree to have the compositor decorate windows.
<Ampera>
Interesting, so there's a major difference between X and Wayland
<Ampera>
although
<Ampera>
I suppose in a sense, not
<Ampera>
In X it's window manager by default, clients if the window manager permits them, so basically just the reverse?
<pq>
yeah, that's the tradition on X11 - also that window manager is one client and that fancy new thing compositor is another client
<pq>
on X11
rasterman has joined #wayland
<Ampera>
I actually have only recently started using a compositor on X, only for the fact that libreoffice is completely broken without one.
<Ampera>
X works remarkably well without one, imo.
<pq>
X11 works well for what it was designed for which is the hardware of... 80s? even 90s. But then GPUs and whatnot came and people became more demanding. It was almost vector graphics with nothing fancy.
luc4 has joined #wayland
<dottedmag>
Ampera: there's autorandr for randr management.
<Ampera>
this looks like the exact thing I need, tank you
<Ampera>
*thank
MajorBiscuit has quit [Quit: WeeChat 3.5]
MajorBiscuit has joined #wayland
rv1sr has quit []
rv1sr has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
thevar1able has quit [Read error: No route to host]
rgallaispou1 has quit [Read error: Connection reset by peer]
fmuellner has joined #wayland
naveenk2 has quit []
bruno_ has joined #wayland
ybogdano has joined #wayland
___nick___ has joined #wayland
pochu has joined #wayland
bruno_ has quit []
___nick___ has quit []
<Ampera>
Just to update on previous conversation, dottedmag this tool is excellent. It does everything I need it to do, and it's disturbingly easy to use. I also dug around in my window manager, and disabled its randr support, which magically makes everything stable again, so now I have dynamic screens with relative stability.
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
luc4 has quit []
tzimmermann has quit [Quit: Leaving]
thevar1able1 has joined #wayland
luc4 has joined #wayland
thevar1able has quit [Ping timeout: 480 seconds]
thevar1able1 has quit [Remote host closed the connection]
thevar1able has joined #wayland
manuel_ has quit []
mbalmer has quit [Remote host closed the connection]
Franciman has joined #wayland
fmuellner has joined #wayland
ybogdano is now known as Guest5636
ybogdano has joined #wayland
Guest5636 has quit [Ping timeout: 480 seconds]
eroux has joined #wayland
eroux_ has quit [Ping timeout: 480 seconds]
thevar1able has quit [Remote host closed the connection]
thevar1able has joined #wayland
ybogdano has quit [Ping timeout: 480 seconds]
thevar1able1 has joined #wayland
thevar1able has quit [Read error: Connection reset by peer]
ybogdano has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
fahien has quit [Quit: fahien]
fahien has joined #wayland
fahien has quit []
fmuellner has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
luc4 has quit []
aswar002 has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
<zubzub>
not wayland related but still linux graphics relevant. What kernel caps do I need to enable to make sure I can do *gl calls on a render device inside a container as a non privileged user? If I literally add *all* caps from https://man7.org/linux/man-pages/man7/capabilities.7.html as an unprivileged user, (e)gl calls still fail. I can however launch a privileged container, drop *all* caps (same list) and
<zubzub>
it will work...
<zubzub>
so like yeah, what's going on here...
<tleydxdy>
just make sure the user have rw access should be good enough zubzub
<zubzub>
nope, I have rw access, I can open the render device fine, I can query egl extensions and get an answer but eglQueryDeviceStringEXT(EGL_DRM_DEVICE_FILE_EXT) will fail
<zubzub>
(but will work fine if container is privileged + I always make program exec under uid=1000 with setpriv)
___nick___ has quit [Ping timeout: 480 seconds]
systwi has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
fmuellner has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
ahartmetz has joined #wayland
rv1sr has quit []
fmuellner has quit [Ping timeout: 480 seconds]
hardening has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
ybogdano has quit [Ping timeout: 480 seconds]
ybogdano has joined #wayland
Arnavion has quit [Ping timeout: 480 seconds]
Arnavion has joined #wayland
Arnavion has quit [Remote host closed the connection]