01:27 danieldg: Riolku: linux dmabuf is how you pass a buffer already on the gpu around
01:54 Riolku:should probably spend some time figuring out how GPUs work
02:01 bl4ckb0ne: mean engraved rock goes fast and makes software people angry
09:03 oldbabyface: Ok so we start at what is the first google match on wayland, people yell it breaks everything, cause they want nvidia driver, well (yeah also slightly short sighted in fact)--- i do not want nvidia driver, i would be ok with nouveau, but i can not understand it all roots back to what i said and what i work on. Is that you do not need the higher clocks at all , you simply run a new extension to the compiler to run sane formats of
09:03 oldbabyface: instruction streams , cause my understanding is that nvidia offers 3d firmware for most (signed encrypted keyring), but nvidia has this extension in their driver egl buffers or whatever it was, it likely started on some later releases in other words, does not support vintage hw yes?
09:04 oldbabyface: any other than that, wayland should be fine , though i tested now 8years back or something
09:04 oldbabyface: but it worked yeah
09:04 emersion: your message is somewhat hard to grasp, do you have any question in particular?
09:05 emersion: fwiw, the nvidia proprietary driver now supports the standard GBM/DMA-BUF/etc stack that everybody uses
09:05 MrCooper: emersion: it's Joss
09:05 emersion: oh
09:05 emersion: indeed
10:52 pq: vyivel, yes. I just 'meson install' to a prefix in my $HOME, and simply run 'weston'. Needs the usual LD_LIBRARY_PATH setup but nothing even remotely as horrible as WESTON_MODULE_MAP.
10:52 vyivel: eh, i'd like to avoid installing anything
10:52 pq: vyivel, I think you could also just 'meson devenv' in weston, and run 'weston'.
10:53 pq: without installing
10:53 vyivel: TIL that's a thing
10:53 vyivel: it works, thanks
10:58 pq: daniels, no, the question is for you, I put it in gitlab mentioning you, but now I think we should simply YOLO it, because anything better is too complicated to implement for this task.
11:02 kennylevinsen: oooh, devenv, interesting
11:04 pq: I haven't got to the devenv boat myself yet, because I'm not in the "all deps are subprojects" boat either, and I tend to manually build some deps with downstream changes.
11:05 kennylevinsen: yeah with my squirrel-esque attention span I tend to work on a lot of unrelated things, and strongly prefer that projects stay in their project folder without too many workarounds...
11:07 kennylevinsen: but didn't know about meson devenv, I just ran things from the build folder and cursed whenever doing so was cumbersome :)
11:08 pq: it's all a trade-off of which setup things you likely forget the most, doing installs or making sure the right branch is checked out on every dep
11:09 pq: and I tend to switch checked-out branches often
11:10 pq: my "installed to $prefix" setup has all been scripted for years now, so I don't even think of it
11:16 kennylevinsen: If only those container thingies weren't a pain for this kind of work. Or I guess nixOS. One day maybe.
11:17 kennylevinsen: Containers for project work environment seems to be getting more popular, and maybe it wouldn't be so bad with podman... Hmm...
11:17 pq: toolbx? I've never tried, just heard about it.
11:18 daniels: pq: aha, just found it ... I've got 128 unreads in fdo-gitlab even after sifting to ignore the ones I don't really want to catch up on :(
11:18 daniels: luckily I also have a 4.5h train journey this evening
11:18 pq: daniels, ahahah. I'm intendting to post "let's just YOLO it" to it today.
11:19 pq: daniels, btw. I've taught my MUA to highlight all emails that mention @pq or such, so I see if I'm mentioned in gitlab. As I never learnt to use the Gitlab todo thingy.
11:20 daniels: pq: I've replied in record time! with what might be a useful suggestion!
11:21 pq: yay!
11:24 wlb: weston/main: Marius Vlad * compositor/main: Re-work plug-in loading to avoid an invalid color manager https://gitlab.freedesktop.org/wayland/weston/commit/df493400c1db compositor/main.c
11:24 wlb: weston/main: Marius Vlad * compositor/main: put remoting/pipewire outputs to the right https://gitlab.freedesktop.org/wayland/weston/commit/73138a194380 compositor/main.c
11:24 wlb: weston Merge request !1365 merged \o/ (main: Create a no-op color manager for the remoting plug-in https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1365)
11:34 pq: How would people feel about color-management extension requiring the use of sealed memfd for ICC file data? Relates to https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1356/diffs?commit_id=d8d6448af7a79e523bb3cc8d73ade801f0c72bcd#note_2125102 .
11:35 pq: Should we make a habit of requiring sealed memfd when passing bulk data for CPU as shared fds in general?
11:35 daniels: in general sealed memfds are the thing we want for a lot of things, and per discussion above all the alternatives are strictly worse; that was the background behind having OS-divergent instructions, so people can do the good thing where the OS allows and the bad thing where the OS doesn't give you an option
11:38 pq: daniels, would be forbid building Weston on non-Linux then?
11:39 daniels: pq: nope, just only check the memfds on Linux, and on non-Linux have /* this can DoS your compositor lol */
11:40 pq: oh, *so* bad thing. I thought the thread was the bad thing.
11:42 daniels: they're all bad :P
11:42 pq: shades
11:43 pq: I'd be fine with that, if we also log a warning in Weston start-up on no-sealing OS.
11:44 pq: daniels, ah, but sealing will not help with the compositor stalls though.
11:44 pq: hmm, but memfd does
11:49 pq: JoshuaAshton, yeah, it's awesome when you know all the users of a protocol extension are under your personal control, so you can update everything in sync and not think about interface stability at all. Certainly makes it easy and fast to get results and evolve when necessary.
11:51 daniels: pq: wfm
12:01 pq: swick[m], I think your rebase of your color-management protocol branch lost the commit "color: reference the color-and-hdr repository".
12:01 swick[m]: shit
12:02 pq: that's a really nice bunch of changes you proposed :-)
12:03 pq: I'll get through them... umm... soon I hope
12:03 swick[m]: oh wow, I didn't just drop the commit, I then noticed that we need to do exactly what the commit did
12:03 swick[m]: 🤦
12:13 pq: swick[m], I'm typing up the "must be sealed memfd" working for set_icc_file atm.
12:13 pq: *wording
12:18 davidre: FWIW FreeBSD has mem_fd and sealing as well now
12:18 pq: cool
12:19 davidre: adays
12:19 pq: I'm already wording it so that the OS does not need to be Linux, just have sealing
12:19 davidre: 13 I think. I was recently wondering if we could hardrequire it in KDE code :D
12:20 pq: ...umm, hmm. What if an OS *adds* sealing capabilities?
12:20 pq: that would then change the spec retroactively, because before, sealing was not necessary on that OS, and then it becomes mandatory. Is that a problem?
12:21 davidre: Can the compositor detect you didn't seal but you could have?
12:21 davidre: If not maybe not
12:21 pq: yes, I believe it can detect
12:22 zamundaaa[m]: The compositor can hardly detect whether or not the app, when it was written, could make use of the OS capabilities
12:22 pq: if you upgrade a compositor to require sealing, but not client, the client suddenly breaks.
12:22 pq: zamundaaa[m], that's the real problem, and also a different question.
12:24 pq: The whole point there is to protect the compositor when OS gives the tools for it, but if we also consider that apps could have been written before the OS got the tools, we essentially demand the compositor gives up permanently about protecting itself.
12:26 pq: you could always just run an ancient app and claim it needs to keep on working, so the compositor can never require seals, so all apps can always just forget about sealing anyway.
12:31 pq: hmm... maybe I make sealing requirement compositor-implementation-defined, and recommend clients always seal if possible or they risk a protocol error.
12:32 pq: awful for a spec, but I'm not sure how otherwise to avoid OS development from implicitly changing the protocol spec
12:38 wlb: weston Merge request !1372 opened by Derek Foreman (derekf) Draft: input: avoid crash by using surface directly https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1372 [Input]
12:40 zamundaaa[m]: pq: sounds like the least bad option to me
12:41 pq: hmm... what would be wrong with aio (man 7 aio)? just curious, it wouldn't offer safe mmap like sealing does.
12:46 kennylevinsen: I believe the main issue with AIO is that... it can block? https://lwn.net/Articles/724198/
12:53 kennylevinsen: quoting a 2016 article (https://lwn.net/Articles/671649/): The API is not considered to be one of our best and is not exposed by the GNU C library; indeed, the POSIX AIO support in glibc is implemented in user space and doesn't use the kernel's AIO subsystem at all. For files, only direct I/O is supported; despite various attempts over the years, buffered I/O is not supported. Even direct
12:53 kennylevinsen: not sure if still accurate
12:54 ascent12: io_uring solves a lot of that, but obviously a highly linux-specific thing
12:54 ascent12: It's also a pretty complex API to drag in for what could be a fairly small part of the code.
12:54 kennylevinsen: pq: heh, one of the suggested fixes to aio was to spawn kernel threads :)
12:55 kennylevinsen: An io_uring based solution should be hidden in the compositor event loop - makes it easier to fall back on other platforms
12:55 kennylevinsen: I'm all for compositors using io_uring, as long as we don't hard-break *BSD again
13:06 pq: kennylevinsen, oh gosh.
13:53 oldbabyface: MrCooper thinks he is a driver architect :) First you are not even that, and if you were you still are not forwarded any rights to come at my territory , we understand you are suicidal but your presence is obnoxious to all of us, having a break at overseas on my own territory from real work, not bullshit as what you do,You all are too bad jokes to make fun at. Put Your GBM/DMABUF into your asses, that is all you have achieved in 10years aside from
13:53 oldbabyface: pissing all intelligence off. Have you ever considered what projects i have lead?, there are also results considerably noticed
13:54 bl4ckb0ne: dont be rude
13:56 swick[m]: mentally stable
13:56 bl4ckb0ne: i did not expect that to work
13:56 pq: you never know
13:58 bl4ckb0ne: can we frame "Put Your GBM/DMABUF into your asses" please
14:24 MrCooper: pq: FYI, GitLab notification e-mails for comments which mention you have "X-GitLab-NotificationReason: mentioned"
14:26 pq: MrCooper, yeah, I use that.
14:27 MrCooper: cool
15:34 ids1024: AIO may be better on BSDs, though it looks like `EVFILT_AIO` (to poll for aio completion on a kqueue) is FreeBSD specific.
15:37 ids1024: I really wish Wayland could require (at least) `F_SEAL_SHRINK` for all shared memory fds it uses. But yeah, backwards compatibility and portability.
16:38 wlb: wayland-protocols/main: Vaxry * README: fix typos https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/9ffeb975c3e3 README.md
16:38 wlb: wayland-protocols/main: Vaxry * governance: fix typos https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/d70af2ea1e98 GOVERNANCE.md
16:38 wlb: wayland-protocols Merge request !254 merged \o/ (Fix typos/grammar in README.md and GOVERNANCE.md https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/254)
16:39 vaxry: thanks daniels ily :*
16:39 daniels: vaxry: thanks for the fix :)
16:40 vaxry: yours truly
17:10 Riolku: F_SEAL_GROW is not important, correct?
17:10 Riolku: just F_SEAL_SHRINK, from the POV of protecting compositors
17:17 danieldg: correct
17:17 danieldg: grow is useful when combined with the resize op on shm
17:22 Riolku: in this thread https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232878 emersion suggests that file sealing is worse than MAP_NOFAULT, I wonder why
17:22 danieldg: map_nofault doesn't require that the other side do sealing
17:23 Riolku: oh, right
17:23 danieldg: also it works for things beyond memfd, which is a real limitation of sealing
17:23 Riolku: The compositor cant protect itself, it has to ask clients to protect it
17:24 danieldg: well, it *could* try to seal FDs but that doesn't actually help if clients seal without shrink, or just pass normal shm (not memfd)
17:25 Riolku: right. didnt know seal fails on non memfd
17:25 danieldg: you wouldn't want sealing to work on an actual file anyway
17:26 pitust: couldn't one implement this without kernel features by handling the SIG
17:26 danieldg: yes, that's the usual solution
17:26 pitust: SIGBUS and mmaping over it with some map_anonymous pages?
17:26 danieldg: but that's rather inefficient
17:27 pitust: only in the failure scenario, and a malicious client can cause DOS in other ways anyway
17:27 danieldg: you have to record where all your maps are and walk them in your sigbus handler
17:27 danieldg: right, but you have to bookkeep always
17:27 pitust: well you need to know which client owns which region so that you know what to unmap, right?
17:27 danieldg: eh, you can just use the address and map over it
17:28 danieldg: if you know your compositor is bug-free and will never get a SIGBUS except from bad clients, you can make your handler much simpler: any SIGBUS gets a zero page mapped where it hits
17:28 danieldg: ... for some reason that's not the solution people use :D
17:28 pitust: you could map all client mapped buffers in a specific memory range
17:29 pitust: and then you know it's *definitely* okay to map over it
17:29 danieldg: that would be a nice way to do it, yes
17:30 danieldg: you'd have to manage allocations in the area yourself, ofc
17:30 danieldg: say on compositor startup, do a big PROT_NONE mmap of 1GB to reserve the area, then MAP_FIXED things into it
17:54 ids1024: I think the advantage of `MAP_NOFAULT` is mainly backwards compatibility. If the Wayland protocol were defined today, and only for Linux (or FreeBSD) you could make it a protocol error to send an shm fd that isn't a sealed memfd.
18:41 i509vcb: I get the feeling at the staging -> stable migrations are going to cause a lot of git history noise
18:41 i509vcb: Wouldn't an attribute of sorts you can attach to a protocol make the move less messy>
20:16 danieldg: ids1024: yeah, that was the goal when it was proposed, but not enough clients did it and so no compositor could start rejecting unsealed FDs
21:43 wlb: wayland-protocols Merge request !255 opened by Derek Foreman (derekf) Draft: presentation-time: Only use CLOCK_MONOTONIC from now on https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/255
23:10 oldbabyface: So the sports men, tiger woods vs nick faldo, or micheal jordan vs. drazen petrovic, say Ali mouhammed vs joe frazer or whatever from new ones, there are many in boxing, ronnie o'sullivan, i mean whatever you talk about one dude flies, there is one man who is bit more, and in my opinion that is micheal jordan
23:21 oldbabyface: but blacks are good especially when they are homied, tracy was good, orlando magic dunker was very shadow of micheal as tracy, but so good this man knew how to dunk, also vince carter was good
23:21 oldbabyface: Penny Hardaway
23:22 oldbabyface: good was also Grant Hill
23:22 oldbabyface: whatever math you do, it's micheal Jordan, the hugest goat
23:26 oldbabyface: Dwayne Wade was good, John stockton, there was Allen Iverson, but does any of them fancy playing against Micheal Jordan?
23:27 oldbabyface: not even the great of the 80s Larry Bird
23:28 oldbabyface: there is none to substitute Micheal Jordan
23:29 bl4ckb0ne: i love the game where michael jordan plays with bigs bunny and daffy duck
23:30 oldbabyface: bugs bunny yeah
23:30 oldbabyface: that's absolutely true, there was a movie
23:31 oldbabyface: this is the biggest human or most capable that i have seen, but there used to be very big ones in history that we have not seen
23:31 oldbabyface: before they started fixate the heights etc.
23:36 oldbabyface: but yeah macbook air is good stuff, such a legend, my work is lot easier
23:38 oldbabyface: so i just do not want to talk anymore, but you understand anyways, there was something special about the splits, computing terms they produced a special set from germans
23:38 oldbabyface: and those are british
23:38 oldbabyface: those did it
23:39 oldbabyface: french and germans have great talents too, but computing is mostly famous british win
23:40 oldbabyface: so british and united states combine noble wins is insane too hence
23:40 oldbabyface: my work is lot simpler, cause i was given a computer already :D
23:41 oldbabyface: for me to talk about those things is not a problem, i see those algorithms well, cause all is presented, something you read in between the lines
23:41 oldbabyface: it's all offered to you
23:42 oldbabyface: cause so magical people they can handle stuff
23:44 oldbabyface: I have seen lance armstrong the king of the mountains
23:45 oldbabyface: lances doctor said to that type of cancer, cause lances doctor was the best brain surgeon in united states
23:45 oldbabyface: lance asked, why i should trust my life in your hands
23:45 oldbabyface: ?
23:46 oldbabyface: that dude said, You know Lance, what you are in cycling i am many times better and higher in brain surgery
23:47 oldbabyface: this is a small case when some douche like me gets hurt , cause there are so many of those cases
23:47 oldbabyface: prolly i just was not good enough
23:48 oldbabyface: but from all the assaults my brain survived , so no problem you want to optimize code?
23:49 bl4ckb0ne: im ok
23:50 oldbabyface: yeah i think also, i am ok too
23:50 oldbabyface: there are safety issues, but there is no trouble at my side too, i know how to do it too
23:51 oldbabyface: its all done through the permutes which are a possibility set of any of the ALUs
23:52 oldbabyface: they can pack very high throughputs like this
23:52 oldbabyface: it obeys to certain very easy logics
23:55 oldbabyface: but i have understood the same, i can not see back from 1983 cause then i was born, but yeah i heard, there was one nation that got a lead, and today the lead is at the hands of united states when to pick out only one, they were doing mass productions indeed, i dunno what is so special about them, cause i do not see history before my birth
23:55 oldbabyface: true or false, they started to lead all the world
23:57 psykose: take ur meds
23:58 oldbabyface: this is crazy, one nation takes down remotely most the russian military
23:58 oldbabyface: and remotely
23:58 oldbabyface: not being at the zone not even close to it