ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
nerdopolis has quit [Remote host closed the connection]
<mvlad>
fyi, seems that mailman is a bit tired, realized that I sent out two RC2 announcement for Weston (had a server mail change, sort of I assumed that was causing it). Please ignore dup of the same mail.
agd5f_ has quit [Remote host closed the connection]
agd5f has joined #wayland
agd5f_ has joined #wayland
agd5f has quit [Read error: Connection reset by peer]
<DemiMarie>
kennylevinsen: Windows allows applications to position themselves. Without a protocol like ext-placement the remote and local window positions will lose sync with each other.
<kennylevinsen>
DemiMarie: My point is that synchronization is irrelevant to remote solution that only shows the app window
<kennylevinsen>
because where the window is locally has no relation to where the window is remotely - only dimensions matter
<kennylevinsen>
I imagine that trying to manage window movement *through* synchronized position, even if it was allowed, would only cause really awkward UX with laggy window movement, and horrible corner-cases on mismatched output geometries
cool110 has joined #wayland
<kennylevinsen>
when disconnected, the window can just be moved freely by the remote client (robert), and wherever the window is on the remote server (bob) is inconsequential
cool110 is now known as Guest1896
fmuellner has quit [Remote host closed the connection]
<DemiMarie>
kennylevinsen: It's a problem when there are multiple windows.
Guest1813 has quit [Ping timeout: 480 seconds]
<kennylevinsen>
multiple toplevels can be considered independently - it did not seem like the concern was parent/child relationships
<DemiMarie>
Windows applications are allowed to make decisions based on the absolute position of their windows.
<kennylevinsen>
This is not windows
<kennylevinsen>
The remote end is windows and can do whatever it wants
<bl4ckb0ne>
are we back to the "client should be able to position itself" debate?
<kennylevinsen>
That doesn’t mean that this needs to be replicated
<kennylevinsen>
You’re welcome
<davidre>
If you want to 1:1 replicate a remote machine, isn't the usual thing to open a big window which just shows the remote machine fully
<DemiMarie>
David Redondo: that works but the UX is bad
<davidre>
I dont see the use case the window positions must be 1:1 but appear as local window
<davidre>
s/window/windows/
leon-anavi has quit [Read error: No route to host]
<DemiMarie>
bl4ckb0ne: there are some applications that cannot reasonably be supported without either ext-placement, ext-zones, or similar or a parent window.
leon-anavi has joined #wayland
vincejv has joined #wayland
<DemiMarie>
Choosing to not support those applications is a valid decision, but means certain applications will not work.
<kennylevinsen>
Maybe take a look at how wine Wayland does it
<DemiMarie>
That would be my recommendation too. It should work for most applications but not for all of them.
<kennylevinsen>
I wouldn’t say it won’t work for all without seeing it first
vincejv_ has quit [Ping timeout: 480 seconds]
<kennylevinsen>
Working does not require an exact 1:1 replica of the original experience
<DemiMarie>
The ext-placement and ext-zones MRs have examples of applications for which it won’t work.
<bl4ckb0ne>
define "reasonably"
<DemiMarie>
See MRs for ext-placement and ext-zones.
<DemiMarie>
"Reasonably" means "with a user experience that is acceptable to their real-world users".
<LaserEyess>
bl4ckb0ne: there are a lot of niche, proprietary scientific applications that rely on multiple windows being arranged for the UI/UX to work. They're garbage applications, truly awful, but they're purpose built and have a use
<LaserEyess>
"just keep using xwayland" is one answer, sure, but I think zones are another one that's wayland enough to work
<LaserEyess>
"just don't do that and let the compositor decide" is *not* an answer though, and it never will be. These things have shoestring budgets and half the time they're made by people who are engineers/scientists, and not developers at all
<kennylevinsen>
It is an answer, not agreeing with it does not invalidate it as a concept
<DemiMarie>
kennylevinsen: the consequence of not supporting ext-placement or ext-zones is that these applications will either be stuck with Xwayland, lose Linux support, or use a proxy compositor that does support ext-placement or ext-zones and wraps everything in one window (bad UX).
<daniels>
that's very well understood by now, yes
<DemiMarie>
Would it be reasonable to require Linux shm clients to use memfds?
<daniels>
no
<DemiMarie>
The problem is that a client can use FUSE to lock up a compositor forever.
<daniels>
it would be great, but it would also be an api break
<daniels>
yeah, it's known that you need to be very defensive around wl_shm if it's not a memfd
<daniels>
you could, as a compositor, refuse to import non-memfd shm fds, but the obvious consequence is that clients not using memfd wouldn't work
<DemiMarie>
That defensiveness isn't enough for FUSE.
<DemiMarie>
Is "fuse OR tmpfs" okay?
<DemiMarie>
One can check that with statfs().
<kennylevinsen>
There’s no indication that these apps even consider porting to Wayland in the first place, so the worry might be for nothing. That’s a more likely scenario for such apps in my opinion…
<daniels>
you don't even need FUSE; there are plenty of other ways you can create a SHM segment which will ruin your day
<DemiMarie>
What I am thinking right now is that the current API is fundamentally broken and that an API break might be the only solution for the security problem.
<daniels>
ok
<daniels>
in that case you'd want to create wl_memfd and make everyone port to it
<daniels>
then figure out what that means for the OSes which don't have memfd
<DemiMarie>
What are those other ways?
<daniels>
kennylevinsen: my take on that is the same as for all the other similar issues - go make zones work and be a thing, show it's sufficient for native apps, then if there ends up being some kind of glaring gap where the native solution is insufficient, figure out what you're going to do about the gap
<daniels>
DemiMarie: you tell me
<DemiMarie>
daniels: you are the one who told me they existed
<DemiMarie>
I know about SIGBUS but that can be caught.
<DemiMarie>
If there are others I'd like to know
<kennylevinsen>
Swapped out shm with be one way
<DemiMarie>
Does that mean that dmabuf is the only robust approach?
<kennylevinsen>
Who says that a dmabuf can’t be swapped? :)
<DemiMarie>
kennylevinsen: are you saying robust systems should not have swap?
<kennylevinsen>
Or, have a reasonable expectation that robustness isn’t perfect
<kennylevinsen>
The latter is more important
vincejv_ has joined #wayland
vincejv has quit [Ping timeout: 480 seconds]
<kennylevinsen>
Reasonable robustness can, for example, be the ability to get out of a negative scenario by ensuring that a degraded state can be escaped consistently or have its capacity to degrade somewhat limited, as opposed to trying to guarantee that it can never happen
<LaserEyess>
10:21 < kennylevinsen> There’s no indication that these apps even consider porting to Wayland in the first place,
<LaserEyess>
they mostly use toolkits that would support wayland, but stub out window placement APIs
<LaserEyess>
once that broke, it's as DemiMarie said, basically, stay on x forever, or drop linux support
<DemiMarie>
kennylevinsen: that works until you have hard real-time requirements, which VR and XR do.
Moprius has joined #wayland
<ManMower>
ooi, what's the big loss here if they stay on X forever?
<DemiMarie>
HDR
<DemiMarie>
Which really matters for e.g. a microscope
<ManMower>
that sounds like a feature that the application author would want badly enough to bother to port to wayland for?
<DemiMarie>
ManMower: but they can't
<DemiMarie>
not without ext-zones or ext-placement
<DemiMarie>
The cost of rewriting the application to not rely on window positioning is prohibitive.
<LaserEyess>
ManMower: or fractional scaling, which still doesn't quite work right on xwayland
<LaserEyess>
also yes if I was doing the math, I would just say "switch to windows", because a windows license and a dedicated windows workstation is cheaper than the man hours
<DemiMarie>
They would be more likely to just drop Linux support altogether and only support Windows.
<ManMower>
I'm cynical, but what I'm getting here is: any effort to port is too high, I'm going to take my football and go home. you must make wayland do these things you've resisted for years.
<DemiMarie>
ManMower: The money to port simply is not there
<DemiMarie>
These are niche applications.
vincejv has joined #wayland
<DemiMarie>
You are asking them to redo their UI around a completely different paradigm.
<ManMower>
why should a niche application define wayland?
<DemiMarie>
That's a huge investment.
<LaserEyess>
it likely doesn't
<DemiMarie>
Are you saying that you are fine with these applications being kicked off of Linux altogether?
<ManMower>
I knew that was coming
vincejv_ has quit [Ping timeout: 480 seconds]
<ManMower>
so open source kinda works like this: people all want a thing, so they put effort into making a thing. it sounds like these people want the thing without having to make the thing? I don't begrudge them that, and I understand, but that's not really a reason to guide our thing?
mripard has quit [Quit: mripard]
<DemiMarie>
ManMower: My understanding is that there are people willing to do the compositor-side part of the work
<zamundaaa[m]>
Demi: please, don't talk like the decision is between "copy X11" and "don't have these apps". That's just not even remotely true
<LaserEyess>
no one is talking about copying x11
<zamundaaa[m]>
yes, absolute positioning is copying X11. ext zones is just a very small step away from it
<ManMower>
zamundaaa[m]: thank you - that's what I meant, but I think I said it in a much more negative way.
<MrCooper>
it's not like an app is going to get HDR or good fractional scaling support without any effort
<zamundaaa[m]>
And still requires apps to port to this Wayland specific concept
<DemiMarie>
ManMower zamundaaa: what is the alternative?
<LaserEyess>
zamundaaa[m]: no... it does not
<LaserEyess>
these apps are not programming for wayland directly
<ManMower>
DemiMarie: get a comp sci student to bang on the app code for a semester as an honors project
<LaserEyess>
they are on qt, java, tk, even matlab (which is qt/java)
<DemiMarie>
ManMower: I suspect you seriously underestimate how hard it would be to do what you are talking about
<zamundaaa[m]>
LaserEyess: yes, it does. Zones do not work like positioning on any other platforms
<ManMower>
fix HDR and frac scaling on X11 is another option
<DemiMarie>
The entire user interface is designed around window positioning.
<mclasen>
so apps can be rewritten to support hdr and fractional scaling and whatnot, but not to fix the UX to work on Wayland ?
<zamundaaa[m]>
Demi: actual relative positioning, for example
<mclasen>
seems... questionable and pushy
<DemiMarie>
mclasen: I suspect most of the work is done by toolkits
<LaserEyess>
zamundaaa[m]: they don't need to work like positioning on other platforms
<DemiMarie>
mclasen: there is no bug to be fixed.
<DemiMarie>
This would require a completely different paradigm.
<LaserEyess>
that's the point, absolute positioning is just what other platforms give, most of these things just want position relative to other windows
<zamundaaa[m]>
LaserEyess: if you want the toolkit to automagically make it work, it has to be as similar as possible
<davidre>
That doesn't help with zones. The toolkit API is window->setPosition(x, y)
<mclasen>
DemiMarie: sorry, it doesn't make sense
<davidre>
with the x, y being soe global coordinates
<davidre>
s/soe/some/
<ManMower>
I don't understand what "the entire UI is designed around window positioning" means.
<davidre>
Everything is its own window
<davidre>
and they need to be arranges in some consistent/expected way
<davidre>
instead of things being widgets in a big window
<LaserEyess>
davidre: and that's stubbed out to the zone coordinates, which will work for a vast amount of the things
<LaserEyess>
most stuff does not need absolute positioning, they just need to know where they are relative to their other windows
<LaserEyess>
ManMower: because you're likely used to working with good software not written by people who have negative experience at making UIs
<davidre>
But those apps also expect those coordinates to be consistent what is reported through "screen/display" API which usually come from xdg_output
<davidre>
(or the toolkits do)
<DemiMarie>
These apps are written by people whose strength is not writing software, but rather their extremely deep knowledge of a specific problem domain.
<ManMower>
dottedmag: I kinda like that. and I feel like a toolkit could even provide that fairly directly for them.
<LaserEyess>
maybe I'm missing it?
<zamundaaa[m]>
dottedmag: they do use windows from multiple processes
<dottedmag>
Yeah, I remember Windows UI library that had that directly, you could switch from MDI to SDI interface pretty easily... MFC, it was named?
<ManMower>
ah yes MDI was the acronym I was trying to remember
<dottedmag>
zamundaaa[m]: ouch
<DemiMarie>
I doubt Qt or other toolkits supports MDI, and it has a terrible user experience
vincejv has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
LaserEyess: With relative positioning, you can express all window relationships. That's not to say that all of them are necessarily something that need to be supported
<dottedmag>
DemiMarie: note that the discussion is about choosing between terrible options
<DemiMarie>
dottedmag: to me, ext-zones is not a terrible option
vincejv has joined #wayland
<dottedmag>
DemiMarie: obviously there are conflicting opinions about that
<LaserEyess>
yes I fully admit all of this stuff that needs ext-zone is terrible software, and I mostly hate it
<LaserEyess>
but alas, it exists
<zamundaaa[m]>
LaserEyess: it's not just about that "terrible software". If toolkits were to somehow integrate it, **all** apps that do X11-style window management would replicate the same on Wayland automatically
<LaserEyess>
well then we're back to stick on X forever
<zamundaaa[m]>
again, please don't misrepresent the situation like that
<zamundaaa[m]>
There's plenty of options between "copy X11" and "not have apps work on Wayland". As has been visible with the last 10 years of apps being ported to Wayland
<ManMower>
making wayland into x11 by a death of 1000 papercuts so niche software can continue to be written to x11 paradigms isn't a wayland design goal
<LaserEyess>
none of this is about copying x 1:1
<LaserEyess>
and your'e right, new software being written shouldn't use zones or anything, but rather work within the "proper" wayland paradigm
<zamundaaa[m]>
LaserEyess: like I already wrote, it is if you want toolkits to automagically make things work for apps
<zamundaaa[m]>
Personally I'd like a relative (to other windows, not the screen) placement thing to be fully explored before going down that kind of route
<LaserEyess>
has that been proposed?
<davidre>
Yes
<dottedmag>
Isn't it funny how in Lazarus screenshot the layout is very similar to modern IDEs, but with some background picture showing through the cracks.
<mclasen>
every argument and every proposal can be found in the depths of that MR
<zamundaaa[m]>
LaserEyess: it was abandoned because it didn't cover 100% of apps
<davidre>
but relative of course cant work magically through toolkits without changing any applciation code
<LaserEyess>
zamundaaa[m]: none of this covers 100% of apps though
<zamundaaa[m]>
yeah I agree with that. And it's not like we need to cover all the crazy cases either
<LaserEyess>
davidre: changing a couple of API calls is much easier than fundamentally changing how your window management works
<davidre>
But apps want nice wayland stuff but do not want to rewrite anything seems bit of a weird goal
<LaserEyess>
20 lines vs 2000 lines
<ManMower>
I feel like those numbers may have been made up without actually trying :)
<LaserEyess>
they're engineering judgement having authored several shitty window placement app things myself
<LaserEyess>
but otherwise, yes, made up
<davidre>
Sometimes you have to bite the bullet and have to refactor things though
<LaserEyess>
I don't, because this is just a rehashing of most of those points
<ManMower>
I think some of the grander philosophical debate is on topic here
<davidre>
The exact same discussion is probably in one of the MRs/issues
<davidre>
already
<zamundaaa[m]>
probably multiple times at this point :D
vincejv_ has joined #wayland
tzimmermann has quit [Quit: Leaving]
<LaserEyess>
actually I thought there was a relative placement MR somewhere but I don't see it?
vincejv has quit [Ping timeout: 480 seconds]
<mclasen>
if you take it to the MR, mklumpp will show up and tell you that you're rehashing a discussion that can be found somewhere in the depths of that mr
<davidre>
There are two open MRs and one closed
<davidre>
iirc
<LaserEyess>
no I didn't mean zones/placement but an alternative
<LaserEyess>
no... I thought someone else besides mklumpp made one
<LaserEyess>
well, doesn't really matter
<LaserEyess>
it would just be nice if wayland had some sort of compromise for this, I don't really have a good idea other than zones though
<LaserEyess>
s/good/any, rather
<davidre>
Lock everyone who commented in those Mrs in a room and wait until there is something
bodiccea has joined #wayland
<LaserEyess>
I think they'd die of starvation first
<ManMower>
please. we would give them food. we're not monsters.
vincejv has joined #wayland
vincejv_ has quit [Ping timeout: 480 seconds]
vincejv_ has joined #wayland
<any1>
I think that one of the reasons why conversations get repeated in MRs is that it's just so damn hard to find previous conversations.
rebtoor_ has joined #wayland
<any1>
The interface is very slow and rather unintuitive.
vincejv has quit [Ping timeout: 480 seconds]
<ManMower>
it's probably not the worst thing for some conversations to be repeated in multiple tickets. we can't really close some new proposal as a duplicate of something tangentially related because an old conversation would block it.
<any1>
I'm talking about multiple threads on the same MR
<ManMower>
ahhh yeah, that's Hard
OrkooffSep2[m] has joined #wayland
<ManMower>
AI will save us. ;)
leon-anavi has quit [Quit: Leaving]
<any1>
Also, once a thread is "resolved", it's pretty much gone because no one will bother expanding all threads and looking through them.
<ManMower>
was thinking of that too. when a new commenter shows up and says something that's already resolved 5 times
rebtoor has quit [Ping timeout: 480 seconds]
<ManMower>
and the person trying to shepherd some work to the finish line suddenly has the responsibility of finding the old comments to close down the new iteration
<any1>
ugh, please don't remind me. I was that person for 2 years.
<ManMower>
thank you.
vincejv has joined #wayland
vincejv_ has quit [Ping timeout: 480 seconds]
<daniels>
speaking of repeating things, I think we've probably covered all the ground we need to - anyone interested in moving things forward should please start working on implementing any of the protocols in toolkits and/or compositors
mclasen has quit [Quit: mclasen]
mclasen has joined #wayland
vincejv_ has joined #wayland
vincejv has quit [Ping timeout: 480 seconds]
gryffus has quit [Read error: Connection reset by peer]
gryffus has joined #wayland
vincejv_ has quit [Ping timeout: 480 seconds]
gryffus has quit [Read error: Connection reset by peer]
gryffus has joined #wayland
vincejv has joined #wayland
kts has joined #wayland
vincejv_ has joined #wayland
vincejv has quit [Ping timeout: 480 seconds]
<kennylevinsen>
DemiMarie: re: “hard requirements like VR” - real hard requirements are handled with separate hardware. When sharing overcomitted resources without tightly controlling all code, you cannot have hard guarantees - a render task might take too long, another GPU task could end up robbing a priority task of time, CPU utilization could lead to GPU power budget reduction leading to missed fra
<kennylevinsen>
mes, memory utilization leading to swappiness, etc - but it’s not unreasonable to have hiccups in response to a bad or unreasonable state.
rebtoor has joined #wayland
<DemiMarie>
kennylevinsen: is that what VR actually does?
<kennylevinsen>
Most VR doesn’t have hard guarantees
<DemiMarie>
kennylevinsen: also, there _are_ hard real-time operating systems that guarantee some tasks will not miss deadlines even if others are buggy or outright malicious. It's just that Linux is not one of those.
<kennylevinsen>
AR might - I think he Vision Pro thing runs the video stuff on its own chip?
<kennylevinsen>
DemiMarie: you can only make those guarantees when you use the system in a way that enables it
rebtoor__ has joined #wayland
<kennylevinsen>
And running random third party “malicious” code with overcommitted resources isn’t such a case
<DemiMarie>
kennylevinsen: these systems don't have swap or paging for one
<DemiMarie>
kennylevinsen: As long as one does not overcommit resources, one can provide extremely strong guarantees.
<kennylevinsen>
Real-time for example requires excess resources and low enough rate of real time events - it’s much easier to make a system that attempts to be realtime lock up than one that doesn’t
<kennylevinsen>
You can provide acceptable guarantees if you strictly limit resource allocation and configuration
<kennylevinsen>
But realtime usually means “everything has to promise to play nice or the thing implodes”
rebtoor_ has quit [Ping timeout: 480 seconds]
vincejv has joined #wayland
rebtoor has quit [Ping timeout: 480 seconds]
vincejv_ has quit [Ping timeout: 480 seconds]
<DemiMarie>
My understanding is that safety-critical hard real-time systems often resort to static time-slicing.
bjorkintosh has quit [Remote host closed the connection]
mohit8158226353 has quit [Quit: mohit8158226353]
mohit8158226353 has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
bjorkintosh has joined #wayland
fmuellner has joined #wayland
vincejv_ has quit [Remote host closed the connection]
lsd|2 has joined #wayland
___nick___ has joined #wayland
coldfeet has quit [Remote host closed the connection]
fmuellner has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
Moprius has joined #wayland
Brainium has joined #wayland
coldfeet has joined #wayland
coldfeet has quit [Quit: leaving]
___nick___ has quit []
___nick___ has joined #wayland
Company has joined #wayland
Moprius has quit [Quit: bye]
___nick___ has quit [Remote host closed the connection]
coldfeet has joined #wayland
rgallaispou has quit [Read error: Connection reset by peer]
feaneron has joined #wayland
rgallaispou has joined #wayland
coldfeet has quit [Quit: leaving]
nerdopolis has joined #wayland
rv1sr has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
dra has joined #wayland
<dra>
Hello! I have a question regarding wl_registry::bind(). I understand that this is the special case where new_id must be preceeded by the interface string and the version. But why is it designed this way? The server should know the interface of the object it just gave though wl_registry::global(). In fact, sway complains if the interface names don't match. So why is it needed at all?
coldfeet has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
<dottedmag>
dra: Version you definitely need to be able to bind to a version supported by the client if the highest one is lower than the one advertised by the server. Interface name I'm not sure.
glennk has quit [Ping timeout: 480 seconds]
<dottedmag>
I don't know why an exception for this request instead of specifying name & version in the protocol description though.
<kennylevinsen>
dra: the server doesn’t create the object - the client tells the server that it has created an object of a certain type and would like functionality bound to it. This is just how the wire protocol defines creation of an object with a runtime defined rather than protocol defined type. The wire protocol does not concern itself much with what logic wl_registry::bind implements, just how to
<kennylevinsen>
communicate consistently - bind just happens to be the only user.
<kennylevinsen>
user of this construct that is
<dra>
dottedmag, kennylevinsen: Thanks, that clears it up.
mvlad has quit [Remote host closed the connection]
mclasen has quit [Ping timeout: 480 seconds]
mclasen has joined #wayland
lsd|2 has quit [Remote host closed the connection]
lsd|2 has joined #wayland
crazybyte has quit [Quit: Bye]
coldfeet has quit [Remote host closed the connection]