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
rv1sr has quit []
co1umbarius has joined #wayland
<tleydxdy>
I wonder in what way would app break if the absolute position is not honored
columbarius has quit [Ping timeout: 480 seconds]
<tleydxdy>
e.g. if it's just restore window to last position then ignoring would be perfectly fine
nerdopolis has quit []
nerdopolis has joined #wayland
markbolhuis has quit [Quit: markbolhuis]
Consolatis_ has joined #wayland
Consolatis is now known as Guest1384
Consolatis_ is now known as Consolatis
pac85 has quit [Remote host closed the connection]
Guest1384 has quit [Ping timeout: 480 seconds]
pac85 has joined #wayland
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
danvet has quit [Ping timeout: 480 seconds]
thevar1able1 has joined #wayland
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #wayland
<pac85>
I think what would break apps is not allowing them to move their window. Breaking doesn't necessarily mean a catastrofic failure, for example you could have an app, perhaps running under some emulation layer, that positions windows close to the cursor for something like a tooltip or a context menu and that does it using absolute coordinates. It just won't work
<DemiMarie>
pac85 tleydxdy: once Qubes OS’s GUI daemon switches from being an X11 client to being a Wayland client, compositor support for XWayland simply will not be available, so a solution that does not require it will be the only way to run X11 applications at all.
<i509VCB>
does x11 have the concept of an interactive move? Or do clients just magically move around
<DemiMarie>
If I understand SpectrumOS correctly, compositor support for XWayland will never be available, as it would be a giant security hole. qyliss, please correct me if I am wrong.
<DemiMarie>
i509vcb: X11 does not have one natively, but basically every client/window manager combination implements one.
<pac85>
DemiMarie: then I think you should implement some Wayland extentions to expose enough functionality to do proper X11 emulation. There are just too many edge cases that cannot possibly be caught, you'd get a better user experience by doing an accurate emulation. Then agaim quebes has somewhat spevific usecasss so it might be ok to break some apps
<i509VCB>
Hmm
<i509VCB>
would responding to XMoveWindow as a result of the mouse button be pressed be a reasonable heuristic to determine whether an interactive move is occuring?
<DemiMarie>
One reason for the switch is because some X11 behaviors are incredibly difficult to deal with. For instance, override-redirect windows have been a problem for Qubes OS for as long as it has existing.
<pac85>
But in general I don't think it is a good idea to mock absolute windows locations. Many things break with current XWayland. For example rofi won't position it's window in the right screen if you don't have any xwayland windows in focus
<i509VCB>
hmm but a client attempting to move all the time would fling across the desktop by simplying clicking once could bypass it
<DemiMarie>
i509vcb: My current plan is to force server-side decorations (from the application perspective), so there is no real reason for a client to call XMoveWindow.
<DemiMarie>
Rofi?
<i509VCB>
well on qubes you probably won't be running steam which has CSDs on X11
<i509VCB>
I guess you could limit movement of the x11 window based on the distance the cursor has moved since the click?
<pac85>
Yep rofi, it does many things among which working as an app launxher
<DemiMarie>
i509VCB: that will hopefully change, once more GPUs get SR-IOV support.
<pac85>
Usually it spawns a window in the screen where the nouse cursor lies
<DemiMarie>
What is rofi? I have never heard of it.
<pac85>
Ehen running under xwayland it cannit determine where the cursor is when no x windows are in focus
<pac85>
This behavior makes it useless under xwayland
<DemiMarie>
i509VCB: Chromium already has CSDs on X11; they simply do not work reliably.
<i509VCB>
I'm just waiting for amd to come out with a consumer sr-iov gpu so I can use VMs much more
<DemiMarie>
(in Qubes OS)
<DemiMarie>
i509VCB: Intel already has, but kernel support is not upstream.
<DemiMarie>
pac85: rofi seems to need things (like global knowledge of input) that are inherently incompatible with sandboxing, so it won’t work anyway.
<DemiMarie>
My current Wayland compositor tells clients that that server-side decorations are in use. If a client doesn’t check for that, then it is going to have problems on other compositors as well, like Sway.
<DemiMarie>
At least if I understand correctly
<pac85>
DemiMarie: my point was that it doesn't currently work with xwayland. Just to say that xwayland is already inaccurate enough, making it even worse to save time spent in integrating it is not the right path. Ofc quebes os is a totally differrnt case smd rofi would be useless there anyway
<DemiMarie>
pac85: can you think of any *applications* (as opposed to what are essentially desktop environment components) that could not be implemented with an emulation?
<pac85>
I understand that quebes has stricter security requirements but you where talling about dropping xwm support right?
<tleydxdy>
I don't get it, so you don't want to have x support, but want x apps to keep working?
<pac85>
DemiMarie: yes, for example I use a program that imjects mouse motion in an emulator, it needs global access to inputs. Again thisnis not something that I'd expect to work on quebes, just talking about general desktop use cases.
<DemiMarie>
pac85 tleydxdy: The long-term plan is for the GUI daemon (which displays all windows from other VMs) to become a Wayland client (it is currently an X11 client). As a Wayland client, it will be limited to what a Wayland client can do.
<tleydxdy>
why not a wayland compositor?
<DemiMarie>
The GUI agent (which talks to the GUI daemon) will be a Wayland compositor, but the GUI daemon will not be.
<tleydxdy>
right ok
<DemiMarie>
As a Wayland client, the GUI daemon will no longer be able to pass information about absolute window positions to the GUI agent, because it itself no longer has that information.
<DemiMarie>
And since it can no longer set the absolute position of its own windows, it cannot provide an API for the GUI agent to set the position of the windows it creates.
<tleydxdy>
right
<tleydxdy>
tbh I don't know how big a deal that would be
<tleydxdy>
maybe some fake absolute coord so the relative position would be correct
<DemiMarie>
Possibly
<DemiMarie>
Obviously various heuristics will be needed
<DemiMarie>
Just like Wine
<pac85>
DemiMarie: When you control both the wayland server and client you can implement extentions to do whatever you want though, isn't that the case? In any case as I've said I thi k it would be ok for quebes to have stricter rules and break some apps, I was talkin in general about the idea of dropping explicit xwayland support and making it a regular client.
<DemiMarie>
pac85: yes, I can implement whatever extensions I want, but the GUI daemon cannot provide information it itself does not have.
<DemiMarie>
The root compositor (in the GUI VM) is the user’s desktop environment.
<tleydxdy>
may be have a dictated workspace for X apps that have to work
<tleydxdy>
and just do normal X stuff in there
<pac85>
So you don't have control over the actual wm, that makes sense
<pac85>
In anu case as I've said x11 shouldn't be a special case, compatibility layers should be feasable under wayland imho
<DemiMarie>
Yeah
<DemiMarie>
The question is how far can one go with Wayland as it is now.
<pac85>
Not that far imho as xwayland is breaking things despite having explicit support
<pac85>
I mean, perhaps you can run 95% of apps correctly
<pac85>
And that'd be great for quebes
<DemiMarie>
Yeah, I only really care about those 95%
<pac85>
But in general 5% of apps could matter a lot for wayland as userd will just stick to X otherwise
<pac85>
(Me included)
<pac85>
Or perhaps you can have lot's of apps runming but with many defects
<pac85>
And again in the contexy of quebes that would still be acceptable
<DemiMarie>
There are many X11 apps that do not work fully
<DemiMarie>
For instance, Qubes OS has the same problems as XWayland when it comes to drag-and-drop
<pac85>
Qubes is trying to solve lots of really hard problems so it can be excused. I had given it a try some time ago and was really impressed at how it manages to integrate different VMs. The same can't be said for wayland and xwayland though. I don't think it has any excuse to not support any usecase
<pac85>
DemiMarie: btw I remember that you talked about difficulties in securely providing 3d accelleration to guests in quebes. One of the problems was iirc that you don't like having a shader compiler running on the host taking inputs from your VMs. I kept thinking about it and though that you could implement a virtual machine in a shader and then have a "universal" shader compiler in the VMs. It might sound crazy but there are emulat
<DemiMarie>
pac85: that is actually interesting! I do not know if this could be made performant, but is an interesting thought.
GentooPhysicist39354 has quit [Ping timeout: 480 seconds]
<DemiMarie>
Also, the problem is more generally applicable to any sandbox (such as Flatpak) that wants to support legacy X11 applications.
<pac85>
Yeah it can be good tradeoff for sandboxed apps in general.
<pac85>
DemiMarie: a part of my message got cut out dolphim (the emulator) does it (to avoid stuttering due to recompilation) and the performance is actually reasonable. Perhaps you can take inspiration there
<pac85>
(In that case it's emulating a particular isa so the overhead could be even lowerr with something designed to be emulated)
caveman has quit [Remote host closed the connection]
zebrag has quit [Quit: Konversation terminated!]
markbolhuis has joined #wayland
markbolhuis has quit []
caveman has joined #wayland
zebrag has joined #wayland
zebrag has quit []
gallo has joined #wayland
bindu has joined #wayland
bindu has quit [Quit: leaving]
bindu has joined #wayland
bindu has quit [Quit: leaving]
bindu has joined #wayland
rasterman has joined #wayland
dcz has joined #wayland
cool110_ has joined #wayland
cool110 has quit [Ping timeout: 480 seconds]
caveman has quit [Ping timeout: 480 seconds]
cool110_ has quit [Remote host closed the connection]
cool110 has joined #wayland
rv1sr has joined #wayland
caveman has joined #wayland
danvet has joined #wayland
mbalmer has joined #wayland
<kennylevinsen>
DemiMarie: faking window positions and output geometries will break some applications, not showing neighbor X apps and allowing them to chat will break other applications, etc.
<kennylevinsen>
All that will be acceptable for some use-cases, but I doubt that, say, Mutter and Weston would accept those.
<kennylevinsen>
In my case I run pure Wayland and have no intentions of writing the xwm glue, so a good-enough standalone thing could be useful if I ran into a small issue where I needed Xwayland
<emersion>
Xwayland can be run rootful
<emersion>
showing the X11 desktop in a xdg-shell window
<wb9688>
Oh, really? And could you then also run a X WM in it?
<MrCooper>
sure
<MrCooper>
pac85[m]: surely way more than 95% of X apps work fine with Xwayland today, but it can never be 100%
<wb9688>
Ah, I've just been using normal Xwayland and then Xephyr in it for testing some stuff in X without logging out
<kennylevinsen>
this is about rootless standalone xwayland btw
<kennylevinsen>
And yeah rootful can be fine in a pinch
<pac85>
MrCooper: i think it could be 100%, after all xwayland is just X, if provided with the right information it will look the same to apps.
<MrCooper>
not really, e.g. think about how X screen capturing apps work
<pac85>
MrCooper: I well perhaps not 100%, but more than what currently works. Also really the fact that xwayland is currently the only mean through which you can do some things is something thet should change imho
<pac85>
Regarding screen capture I though it could be possible to sort of hook xcomposite to show somwthinf else right? a big problem though is that when individual windows are captured it can only work with X11 windows
<wb9688>
kennylevinsen: Yes, I understood, but if that could be used for my purpose as well, I could give it a try
<pac85>
XWayland :2 and a big (as big as all of your monitord combined) window appears, not sure how you can set geometry
<pac85>
A nice thing about rootless xwayland as opposed to something like xephyr is that 3d accelleration works inside it
vanveldt has quit [Remote host closed the connection]
vanveldt has joined #wayland
wolfshappen has joined #wayland
<DemiMarie>
kennylevinsen: Yeah this is not a replacement for native XWayland support in compositors. It’s meant as a fallback for when such support does not exist or cannot be safely exposed.
<DemiMarie>
emersion: being able to support a subset of applications rootlessly is better than none at all.
<DemiMarie>
The main use for rootful XWayland I can think of is allowing distributions to drop support for the full X server.
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
doppo has quit [Remote host closed the connection]
doppo has joined #wayland
AndroUser2 has joined #wayland
nyah has joined #wayland
pac85 has quit [Ping timeout: 480 seconds]
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #wayland
jmdaemon has joined #wayland
AndroUser2 has quit [Ping timeout: 480 seconds]
jmd has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
AndroUser2 has joined #wayland
AndroUser2 has quit [Read error: Connection reset by peer]
AndroUser2 has joined #wayland
jmdaemon has joined #wayland
jmd has quit [Ping timeout: 480 seconds]
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #wayland
danieldg has quit [Quit: back in a few days]
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #wayland
AndroUser2 has quit [Ping timeout: 480 seconds]
alatiera has quit [Ping timeout: 480 seconds]
jmdaemon has quit [Quit: WeeChat 3.6]
vanveldt has quit [Remote host closed the connection]
pac85 has joined #wayland
<pac85>
DemiMarie: rootful XWayland won't handle vsync when multiple monitors have different refresh rates (X does it though not when a composutor is used, however it still works for full screen apps that usually get unredirected). Also X can run on drm+gles so I don't see the point of having a wayland compositor in the middle.
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
slim has quit [Quit: slim]
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
luc4 has quit [Remote host closed the connection]
pac85 has quit [Read error: Connection reset by peer]