01:06 whot: :q
06:46 wlb: weston Merge request !1604 opened by Marius Vlad (mvlad) build: bump to version 13.0.94 for the RC2 release https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1604
06:55 wlb: weston/main: Marius Vlad * build: bump to version 13.0.94 for the RC2 release https://gitlab.freedesktop.org/wayland/weston/commit/f81c0358c5c8 meson.build
06:55 wlb: weston Merge request !1604 merged \o/ (build: bump to version 13.0.94 for the RC2 release https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1604)
08:28 wlb: weston New tag: 13.0.94 https://gitlab.freedesktop.org/wayland/weston/tags/13.0.94
08:52 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.
08:52 daniels: we're all tired man
08:52 mvlad: =)
12:16 wlb: wayland.freedesktop.org Merge request !86 opened by Marius Vlad (mvlad) releases: add weston 13.0.94 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/86
12:18 wlb: wayland.freedesktop.org Merge request !86 merged \o/ (releases: add weston 13.0.94 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/86)
12:18 wlb: wayland.freedesktop.org/main: Marius Vlad * releases: add weston 13.0.94 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/2d24156b90f3 releases.html
12:36 wlb: wayland.freedesktop.org/main: Marius Vlad * _redirects: Add _redirects file https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/db13ee3810d8 _redirects
12:36 wlb: wayland.freedesktop.org/main: Marius Vlad * remotes/: Remove tarballs for weston > 10.0.0 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/e7d477b7bc6f releases/ weston-10.0.3.tar.xz weston-10.0.3.tar.xz.sig weston-10.0.4.tar.xz weston-10.0.4.tar.xz.sig weston-10.0.5.tar.xz weston-10.0.5.tar.xz.sig weston-11.0.1.tar.xz weston-11.0.1.tar.xz.sig weston-11.0.2.tar.xz weston-11.0.2.tar.xz.sig weston-11.
12:36 wlb: 0.3.ta
12:36 wlb: wayland.freedesktop.org Merge request !85 merged \o/ (remotes/: Remove tarballs for weston > 10.0.0 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/85)
12:53 wlb: weston Merge request !1605 opened by Derek Foreman (derekf) libweston: Fix crash with mirror-of https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1605 [Core compositor]
13:23 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.
13:30 kennylevinsen: DemiMarie: My point is that synchronization is irrelevant to remote solution that only shows the app window
13:30 kennylevinsen: because where the window is locally has no relation to where the window is remotely - only dimensions matter
13:32 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
13:33 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
13:36 DemiMarie: kennylevinsen: It's a problem when there are multiple windows.
13:38 kennylevinsen: multiple toplevels can be considered independently - it did not seem like the concern was parent/child relationships
13:55 DemiMarie: Windows applications are allowed to make decisions based on the absolute position of their windows.
13:58 kennylevinsen: This is not windows
13:58 kennylevinsen: The remote end is windows and can do whatever it wants
13:58 DemiMarie: kennylevinsen: thanks for the review on <https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/409>.
13:58 bl4ckb0ne: are we back to the "client should be able to position itself" debate?
13:58 kennylevinsen: That doesn’t mean that this needs to be replicated
13:59 kennylevinsen: You’re welcome
14:00 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
14:00 DemiMarie: David Redondo: that works but the UX is bad
14:01 davidre: I dont see the use case the window positions must be 1:1 but appear as local window
14:01 davidre: s/window/windows/
14:02 DemiMarie: bl4ckb0ne: there are some applications that cannot reasonably be supported without either ext-placement, ext-zones, or similar or a parent window.
14:03 DemiMarie: Choosing to not support those applications is a valid decision, but means certain applications will not work.
14:03 kennylevinsen: Maybe take a look at how wine Wayland does it
14:04 DemiMarie: That would be my recommendation too. It should work for most applications but not for all of them.
14:05 kennylevinsen: I wouldn’t say it won’t work for all without seeing it first
14:05 kennylevinsen: Working does not require an exact 1:1 replica of the original experience
14:05 DemiMarie: The ext-placement and ext-zones MRs have examples of applications for which it won’t work.
14:06 bl4ckb0ne: define "reasonably"
14:06 DemiMarie: See MRs for ext-placement and ext-zones.
14:07 DemiMarie: "Reasonably" means "with a user experience that is acceptable to their real-world users".
14:09 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
14:10 LaserEyess: "just keep using xwayland" is one answer, sure, but I think zones are another one that's wayland enough to work
14:13 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
14:14 kennylevinsen: It is an answer, not agreeing with it does not invalidate it as a concept
14:15 wlb: weston/main: Derek Foreman * libweston: Fix crash with mirror-of https://gitlab.freedesktop.org/wayland/weston/commit/50d92f9d6f15 frontend/main.c libweston/backend-drm/modes.c libweston/backend-pipewire/pipewire.c libweston/backend-x11/x11.c libweston/compositor.c libweston/libweston-internal.h
14:15 wlb: weston Merge request !1605 merged \o/ (libweston: Fix crash with mirror-of https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1605)
14:17 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).
14:18 daniels: that's very well understood by now, yes
14:19 DemiMarie: Would it be reasonable to require Linux shm clients to use memfds?
14:19 daniels: no
14:19 DemiMarie: The problem is that a client can use FUSE to lock up a compositor forever.
14:19 daniels: it would be great, but it would also be an api break
14:19 daniels: yeah, it's known that you need to be very defensive around wl_shm if it's not a memfd
14:20 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
14:20 DemiMarie: That defensiveness isn't enough for FUSE.
14:20 DemiMarie: Is "fuse OR tmpfs" okay?
14:20 DemiMarie: One can check that with statfs().
14:21 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…
14:22 daniels: you don't even need FUSE; there are plenty of other ways you can create a SHM segment which will ruin your day
14:22 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.
14:22 daniels: ok
14:22 daniels: in that case you'd want to create wl_memfd and make everyone port to it
14:22 daniels: then figure out what that means for the OSes which don't have memfd
14:23 DemiMarie: What are those other ways?
14:23 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
14:23 daniels: DemiMarie: you tell me
14:23 DemiMarie: daniels: you are the one who told me they existed
14:25 DemiMarie: I know about SIGBUS but that can be caught.
14:27 DemiMarie: If there are others I'd like to know
14:27 kennylevinsen: Swapped out shm with be one way
14:28 DemiMarie: Does that mean that dmabuf is the only robust approach?
14:30 kennylevinsen: Who says that a dmabuf can’t be swapped? :)
14:32 DemiMarie: kennylevinsen: are you saying robust systems should not have swap?
14:34 kennylevinsen: Or, have a reasonable expectation that robustness isn’t perfect
14:34 kennylevinsen: The latter is more important
14:37 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
14:43 LaserEyess: 10:21 < kennylevinsen> There’s no indication that these apps even consider porting to Wayland in the first place,
14:43 LaserEyess: they mostly use toolkits that would support wayland, but stub out window placement APIs
14:44 LaserEyess: once that broke, it's as DemiMarie said, basically, stay on x forever, or drop linux support
14:45 DemiMarie: kennylevinsen: that works until you have hard real-time requirements, which VR and XR do.
14:46 ManMower: ooi, what's the big loss here if they stay on X forever?
14:46 DemiMarie: HDR
14:46 DemiMarie: Which really matters for e.g. a microscope
14:48 ManMower: that sounds like a feature that the application author would want badly enough to bother to port to wayland for?
14:48 DemiMarie: ManMower: but they can't
14:48 DemiMarie: not without ext-zones or ext-placement
14:48 DemiMarie: The cost of rewriting the application to not rely on window positioning is prohibitive.
14:49 LaserEyess: ManMower: or fractional scaling, which still doesn't quite work right on xwayland
14:49 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
14:49 DemiMarie: They would be more likely to just drop Linux support altogether and only support Windows.
14:50 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.
14:51 DemiMarie: ManMower: The money to port simply is not there
14:51 DemiMarie: These are niche applications.
14:51 DemiMarie: You are asking them to redo their UI around a completely different paradigm.
14:51 ManMower: why should a niche application define wayland?
14:51 DemiMarie: That's a huge investment.
14:51 LaserEyess: it likely doesn't
14:52 DemiMarie: Are you saying that you are fine with these applications being kicked off of Linux altogether?
14:52 ManMower: I knew that was coming
14:52 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?
14:53 DemiMarie: ManMower: My understanding is that there are people willing to do the compositor-side part of the work
14:53 DemiMarie: And the toolkit side
14:53 LaserEyess: well I would argue that some of those people are contributing to open source? or trying to? https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264
14:54 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
14:54 LaserEyess: no one is talking about copying x11
14:54 zamundaaa[m]: yes, absolute positioning is copying X11. ext zones is just a very small step away from it
14:55 ManMower: zamundaaa[m]: thank you - that's what I meant, but I think I said it in a much more negative way.
14:55 MrCooper: it's not like an app is going to get HDR or good fractional scaling support without any effort
14:55 zamundaaa[m]: And still requires apps to port to this Wayland specific concept
14:55 DemiMarie: ManMower zamundaaa: what is the alternative?
14:55 LaserEyess: zamundaaa[m]: no... it does not
14:55 LaserEyess: these apps are not programming for wayland directly
14:55 ManMower: DemiMarie: get a comp sci student to bang on the app code for a semester as an honors project
14:55 LaserEyess: they are on qt, java, tk, even matlab (which is qt/java)
14:56 DemiMarie: ManMower: I suspect you seriously underestimate how hard it would be to do what you are talking about
14:56 zamundaaa[m]: LaserEyess: yes, it does. Zones do not work like positioning on any other platforms
14:56 ManMower: fix HDR and frac scaling on X11 is another option
14:56 DemiMarie: The entire user interface is designed around window positioning.
14:56 mclasen: so apps can be rewritten to support hdr and fractional scaling and whatnot, but not to fix the UX to work on Wayland ?
14:56 zamundaaa[m]: Demi: actual relative positioning, for example
14:56 mclasen: seems... questionable and pushy
14:57 DemiMarie: mclasen: I suspect most of the work is done by toolkits
14:57 LaserEyess: zamundaaa[m]: they don't need to work like positioning on other platforms
14:57 DemiMarie: mclasen: there is no bug to be fixed.
14:57 DemiMarie: This would require a completely different paradigm.
14:57 LaserEyess: that's the point, absolute positioning is just what other platforms give, most of these things just want position relative to other windows
14:57 zamundaaa[m]: LaserEyess: if you want the toolkit to automagically make it work, it has to be as similar as possible
14:57 davidre: That doesn't help with zones. The toolkit API is window->setPosition(x, y)
14:57 mclasen: DemiMarie: sorry, it doesn't make sense
14:58 davidre: with the x, y being soe global coordinates
14:58 davidre: s/soe/some/
14:58 ManMower: I don't understand what "the entire UI is designed around window positioning" means.
14:58 davidre: Everything is its own window
14:59 davidre: and they need to be arranges in some consistent/expected way
14:59 davidre: instead of things being widgets in a big window
15:00 LaserEyess: davidre: and that's stubbed out to the zone coordinates, which will work for a vast amount of the things
15:00 LaserEyess: most stuff does not need absolute positioning, they just need to know where they are relative to their other windows
15:01 LaserEyess: ManMower: because you're likely used to working with good software not written by people who have negative experience at making UIs
15:01 davidre: But those apps also expect those coordinates to be consistent what is reported through "screen/display" API which usually come from xdg_output
15:01 davidre: (or the toolkits do)
15:02 DemiMarie: These apps are written by people whose strength is not writing software, but rather their extremely deep knowledge of a specific problem domain.
15:02 davidre: ManMower: see for example this screen https://gitlab.freedesktop.org/-/project/2891/uploads/987d2d6db82ade219c40becfdd8521c6/Scientific_Linux_6_7_Lazarus_Successful_build.png
15:02 davidre: Where the toolbar is its own window for example
15:02 davidre: and the editor another
15:02 davidre: the sidebar another
15:03 dottedmag: Are there concrete examples of these UIs that are designed around window positioning?
15:03 zamundaaa[m]: davidre: Also, very importantly, a bunch of them expect coordinates to be consistent across multiple processes
15:03 DemiMarie: dottedmag: yes
15:03 zamundaaa[m]: You can't do that automatically as a toolkit
15:03 DemiMarie: zamundaaa[m]: Which works fine with zones.
15:03 mclasen:decides that the weekend is too close for such a pointless rehashing of known disagreements
15:03 dottedmag: DemiMarie: could you share a link?
15:03 davidre: See examples in in the orignal MR for some apps https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247
15:03 zamundaaa[m]: Not unless the app puts in the effort to port everything to use the zones
15:04 DemiMarie: zamundaaa: the toolkit deals with the zones
15:04 zamundaaa[m]: It can't
15:04 DemiMarie: to the app, the zone is the output
15:04 dottedmag: Ah, I see.
15:04 zamundaaa[m]: Demi: no, that doesn't work
15:04 davidre: which scale does the zone have?
15:04 davidre: how do I match wl_output to the zone?
15:04 zamundaaa[m]: Unless you guarantee that the zone is always equal to some output
15:04 dottedmag: I wonder how much work is that to just put all the widgets inside one window.
15:04 zamundaaa[m]: in which case, you just exactly copy X11
15:04 DemiMarie: zamundaaa: if it doesn’t work then comment on https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264 please.
15:04 LaserEyess: zamundaaa[m]: switching a couple of API calls but keeping your UI/UX the same is definitely easier than reworking your UI
15:04 ManMower: dottedmag: just make a big full-sized desktop window, and make everything a sub window of that?
15:04 dottedmag: It's not like these applications benefit from mixing their windows with some other unrelated windows.
15:05 dottedmag: ManMower: Yes. That's an easy way to port them.
15:05 zamundaaa[m]: LaserEyess: noone is asking to rework the UI
15:05 LaserEyess: zamundaaa[m]: I have yet to see an example of how a compositor could know enough information/hints/intents from an application to recreate https://gitlab.freedesktop.org/-/project/2891/uploads/987d2d6db82ade219c40becfdd8521c6/Scientific_Linux_6_7_Lazarus_Successful_build.png
15:05 ManMower: dottedmag: I kinda like that. and I feel like a toolkit could even provide that fairly directly for them.
15:05 LaserEyess: maybe I'm missing it?
15:06 zamundaaa[m]: dottedmag: they do use windows from multiple processes
15:06 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?
15:06 ManMower: ah yes MDI was the acronym I was trying to remember
15:06 dottedmag: zamundaaa[m]: ouch
15:07 DemiMarie: I doubt Qt or other toolkits supports MDI, and it has a terrible user experience
15:07 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
15:07 dottedmag: DemiMarie: note that the discussion is about choosing between terrible options
15:07 DemiMarie: dottedmag: to me, ext-zones is not a terrible option
15:08 dottedmag: DemiMarie: obviously there are conflicting opinions about that
15:08 LaserEyess: yes I fully admit all of this stuff that needs ext-zone is terrible software, and I mostly hate it
15:08 LaserEyess: but alas, it exists
15:08 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
15:09 LaserEyess: well then we're back to stick on X forever
15:10 zamundaaa[m]: again, please don't misrepresent the situation like that
15:10 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
15:10 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
15:10 LaserEyess: none of this is about copying x 1:1
15:11 LaserEyess: and your'e right, new software being written shouldn't use zones or anything, but rather work within the "proper" wayland paradigm
15:11 zamundaaa[m]: LaserEyess: like I already wrote, it is if you want toolkits to automagically make things work for apps
15:12 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
15:12 LaserEyess: has that been proposed?
15:12 davidre: Yes
15:12 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.
15:12 mclasen: every argument and every proposal can be found in the depths of that MR
15:13 zamundaaa[m]: LaserEyess: it was abandoned because it didn't cover 100% of apps
15:13 davidre: but relative of course cant work magically through toolkits without changing any applciation code
15:13 LaserEyess: zamundaaa[m]: none of this covers 100% of apps though
15:13 zamundaaa[m]: yeah I agree with that. And it's not like we need to cover all the crazy cases either
15:13 LaserEyess: davidre: changing a couple of API calls is much easier than fundamentally changing how your window management works
15:13 davidre: But apps want nice wayland stuff but do not want to rewrite anything seems bit of a weird goal
15:14 LaserEyess: 20 lines vs 2000 lines
15:15 ManMower: I feel like those numbers may have been made up without actually trying :)
15:15 LaserEyess: they're engineering judgement having authored several shitty window placement app things myself
15:16 LaserEyess: but otherwise, yes, made up
15:16 davidre: Sometimes you have to bite the bullet and have to refactor things though
15:16 davidre: Why should window managment be exempt
15:17 DemiMarie: I think this discussion should be moved to https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264 and continued there.
15:17 LaserEyess: I don't, because this is just a rehashing of most of those points
15:17 ManMower: I think some of the grander philosophical debate is on topic here
15:17 davidre: The exact same discussion is probably in one of the MRs/issues
15:18 davidre: already
15:18 zamundaaa[m]: probably multiple times at this point :D
15:19 LaserEyess: actually I thought there was a relative placement MR somewhere but I don't see it?
15:21 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
15:21 davidre: There are two open MRs and one closed
15:21 davidre: iirc
15:22 LaserEyess: no I didn't mean zones/placement but an alternative
15:22 davidre: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247
15:22 colinmarc: does anyone want to weigh in on https://github.com/KhronosGroup/Vulkan-Docs/pull/2410? if it's not something that's wanted I can just close it, no big deal
15:23 davidre: LaserEyess: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/249 this one?
15:23 davidre: so there are two closed ones actually
15:24 LaserEyess: no... I thought someone else besides mklumpp made one
15:24 LaserEyess: well, doesn't really matter
15:25 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
15:25 LaserEyess: s/good/any, rather
15:25 davidre: Lock everyone who commented in those Mrs in a room and wait until there is something
15:27 LaserEyess: I think they'd die of starvation first
15:27 ManMower: please. we would give them food. we're not monsters.
15:35 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.
15:35 any1: The interface is very slow and rather unintuitive.
15:37 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.
15:38 any1: I'm talking about multiple threads on the same MR
15:38 ManMower: ahhh yeah, that's Hard
15:38 ManMower: AI will save us. ;)
15:39 any1: Also, once a thread is "resolved", it's pretty much gone because no one will bother expanding all threads and looking through them.
15:40 ManMower: was thinking of that too. when a new commenter shows up and says something that's already resolved 5 times
15:40 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
15:41 any1: ugh, please don't remind me. I was that person for 2 years.
15:41 ManMower: thank you.
15:46 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
16:22 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
16:22 kennylevinsen: mes, memory utilization leading to swappiness, etc - but it’s not unreasonable to have hiccups in response to a bad or unreasonable state.
16:23 DemiMarie: kennylevinsen: is that what VR actually does?
16:23 kennylevinsen: Most VR doesn’t have hard guarantees
16:23 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.
16:24 kennylevinsen: AR might - I think he Vision Pro thing runs the video stuff on its own chip?
16:24 kennylevinsen: DemiMarie: you can only make those guarantees when you use the system in a way that enables it
16:25 kennylevinsen: And running random third party “malicious” code with overcommitted resources isn’t such a case
16:25 DemiMarie: kennylevinsen: these systems don't have swap or paging for one
16:26 DemiMarie: kennylevinsen: As long as one does not overcommit resources, one can provide extremely strong guarantees.
16:26 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
16:26 kennylevinsen: You can provide acceptable guarantees if you strictly limit resource allocation and configuration
16:27 kennylevinsen: But realtime usually means “everything has to promise to play nice or the thing implodes”
16:33 DemiMarie: My understanding is that safety-critical hard real-time systems often resort to static time-slicing.
16:38 wlb: wayland.freedesktop.org Merge request !87 opened by Marius Vlad (mvlad) _redirects: Add .sig and .sha256sum for redirection as well https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/87
16:58 wlb: wayland.freedesktop.org/main: Marius Vlad * _redirects: Add .sig and .sha256sum for redirection as well https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/d4834c50a7e2 _redirects
16:58 wlb: wayland.freedesktop.org Merge request !87 merged \o/ (_redirects: Add .sig and .sha256sum for redirection as well https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/87)
17:24 wlb: wayland-protocols/main: Simon Ser * xdg-toplevel-icon: add error for destroyed wl_buffer https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/c4df317ea6aa staging/xdg-toplevel-icon/xdg-toplevel-icon-v1.xml
17:24 wlb: wayland-protocols Merge request !331 merged \o/ (xdg-toplevel-icon: add error for destroyed wl_buffer https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/331)
20:56 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?
21:07 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.
21:08 dottedmag: I don't know why an exception for this request instead of specifying name & version in the protocol description though.
21:11 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
21:11 kennylevinsen: communicate consistently - bind just happens to be the only user.
21:12 kennylevinsen: user of this construct that is
21:17 dra: dottedmag, kennylevinsen: Thanks, that clears it up.