ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
Dami-star has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
Guest4507 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest4844
nerdopolis has quit [Ping timeout: 480 seconds]
gnustomp[m] has quit []
caveman has joined #wayland
cvmn has quit [Remote host closed the connection]
Lightsword has quit [Quit: ZNC]
Lightsword has joined #wayland
sima has joined #wayland
tzimmermann has joined #wayland
<emersion> > wl_coffee_machine
<emersion> can't wait to get that in w-p!
<jadahl> should be xdg_coffee_machine I guess, but why not
<zzag> then nobody will have coffee
<jadahl> xdg_coffee_esperesso, xdg_coffee_french_press, xdg_coffee_filter
* zzag runs away
<jadahl> a tea extension to the coffee shell would help?
<jadahl> a bit calcified tea
carbonfiber has joined #wayland
<emersion> tea is a subset of coffee now? :/
* emersion sees his pu-erh make waves as a sign of protest
xhivo97 has joined #wayland
<zzag> heh, with my tea and coffee drinking habits, I'm actually worried about kidney stones
<zzag> just in case, citric acid cleans calcium buildup in kettles very well
<jadahl> emersion: in coffee machines it seems common :(
<xhivo97> would more water help with that lol, I switched to caffeine tablets because as much as I love coffee my stomach doesn't
<jadahl> hot water with a teste of calcium from the coffee
<xhivo97> I don't use kettles anymore after I saw chunks of calcium floating inside
* jadahl does coffee in the morning, and tea in the afternoon
<xhivo97> How should I do software rendering for a game in wayland? I need a way to tell the compositor to render when the buffer is ready? How to do that without added frames in latency? I want the game to have a target FPS and try to run at that and update as fast as it can to the compositor
rv1sr has joined #wayland
<jadahl> I was at a "tea maker" once where one could wipe the outside of the tea fermentation machine thing with your finger to get a caffeeine directly from the source
<emersion> ahah
<jadahl> the more fermentation, the more caffeine stuck to the metallic fermentation .. oven thing?
<jadahl> xhivo97: allocate an shm buffer, write pixels to it, attach and commit to a surface
<xhivo97> How often should I do that is there a way to sync it? I have an shm buffer I am drawing to it's just the game FPS vs compositor drawing FPS being separate that confuses me as I kind of whant the render loop to run on it's own (probably on same thread for now)
<xhivo97> I guess my question is, can I commit faster than the cserver can update?
<emersion> you can, but it's wasteful
<emersion> this will result in work (drawing frames) which will be unused (superseded by a more recent frame)
<xhivo97> Wouln't ot potentially improve latency? Esp if I manage to do input handling at higher rates too?
<emersion> the proper way to improve latency is to try to draw and commit a bit before vsync
<emersion> but with shm, things are slow anyways
<rosefromthedead> although i'm not sure game devs have got the memo yet
<emersion> performance and shm, pick one :P
<jadahl> we need a "use nearest" scaling extension so shm pixel graphics clients can create 480x320 buffers and scale up with viewporter
<xhivo97> I am a beginner in all this (def not a game dev, I wish lol) that's why I am starting with shm and not using the GPU this early I want to understand how rendering works, but I think if I think about stuff like latency I'll get sidetracked and not learn what I really neeed to learn probably
<emersion> jadahl: i think i have a branch with that somewhere…
<emersion> (KMS has a prop for it)
manuel_ has joined #wayland
<emersion> xhivo97: this stuff is definitely a more advanced topic
<kennylevinsen> xhivo97: just clean or descale your kettle if it's that bad lol
<rosefromthedead> is shm still slow if there's not much damage?
<xhivo97> Tell that to my dad, he uses it and looks like he'd rather suffer through the pain of another kidney stone than clean it lol
<emersion> rosefromthedead: games usually don't do damage tracking
<rosefromthedead> i see people saying if you want any perf at all then avoid it but foot proudly talks about using shm right at the top of the performance page lol
<rosefromthedead> yeah im thinking about regular apps now
<kennylevinsen> It's faster with less damage, but it always requires slow pixel copy to a dmabuf
<emersion> it will never be faster than uploading font glyths to the GPU once at startup and then texturing them
<rosefromthedead> right, i guess what im really looking for is "do the relevant apis allow you to only copy the damaged part" which it seems like they do?
<kennylevinsen> Yes
<emersion> yes, damage tracking does help
<rosefromthedead> cool
<xhivo97> Is that copy something that is always there for software rendering or is it specific to wayland?
<kennylevinsen> always true
<rosefromthedead> i can put off learning enough gl/vk to render text for a little longer then :P
<emersion> the copy is always there when shm is used and the computer has a GPU (internal or external)
Company has quit [Quit: Leaving]
<emersion> yeah, proper font rendering on GPUs… sounds like a real pain for sure
<rosefromthedead> it's basically just blitting, how hard could it be...
* rosefromthedead was never seen again
<emersion> lol
<JEEB> emersion: yup. reminds me of someone having ideas of implementing something like that for the libass subtitle renderer, but that never went anywhere.
<emersion> famous last words
<emersion> oof, .ass gpu rendering
<emersion> that sounds fun
<xhivo97> i was curous about font rendering and concluded it's not an excersise I can do at my level it looks really hard. Whoever came up with .ass deserves a medal
<JEEB> IIRC .ass was come up based on .ssa in a week or so (design during the work week, then hacking on the week-end for implementation)
<kennylevinsen> fast forward to interchangeably right-to-left, left-to-right, top-to-bottom arabic-chinese-emoji text
<rosefromthedead> i've learned that even if you defer as much work as possible to libraries, font rendering *still* manages to be a huge pain
<JEEB> also it left a lot of stuff unspecified which ended up just being referenced to GDI/the initial implementation
<JEEB> which seems to have been quite a PITA
<JEEB> esp. when the ye olde reference implementation starts seeming like a bug
<JEEB> I think jfs tried to define a better-defined multi-profile thing in the 2010s but that didn't go much anywhere
<JEEB> rosefromthedead: yea, that's my experience as well looking from the side lines
<JEEB> even with freetype2, harfbuzz, fribidi etc handling things for you
xhivo97 has quit [Remote host closed the connection]
Kerr has joined #wayland
rederick29 has joined #wayland
mvlad has joined #wayland
<emersion> jadahl: by any chance, any progress on the flatpak stuff? would be nice to be able to release a new w-p
<wlb> wayland-protocols Issue #59 closed \o/ (linux-dmabuf: figure out a good way to broadcast set of supported formats/modifiers https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/59)
<wlb> wayland-protocols Merge request !223 opened by Simon Ser (emersion) linux-dmabuf: mark as stable https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/223
<orowith2os> It's funny how I ended up causing so much chaos over this with one simple patch update, lol
<orowith2os> Well, at least now that's all fixed up :)
<orowith2os> eventually I'll get to writing a compositor myself (definitely), so I don't have to keep asking around and bugging yall :P
<jadahl> emersion: smcv wanted alex to look again since he started. nagged alexl internally (he is at another dept at rh) but hasn't replied
<wlb> wayland-protocols Merge request !224 opened by Simon Ser (emersion) linux-dmabuf: require all planes to use the same modifier https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/224
rasterman has joined #wayland
<jadahl> emersion: will try again
<emersion> ty
<wlb> wayland-protocols Merge request !225 opened by Simon Ser (emersion) readme: reword intro for backward incompatible change section https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/225
<wlb> wayland-protocols Merge request !226 opened by Simon Ser (emersion) readme: version should be included in stable protocol filenames https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/226
<emersion> </patches>
kts has joined #wayland
<wlb> wayland-protocols Merge request !201 merged \o/ (xdg-shell: Add suspended toplevel state https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/201)
<wlb> wayland-protocols/main: Daniel Stone * xdg-shell: Add suspended toplevel state https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/c124b641b346 stable/xdg-shell/xdg-shell.xml
<wlb> wayland-protocols/main: Simon Ser * security-context-v1: new protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/12c063088e97 staging/security-context/README staging/security-context/engines.md staging/security-context/security-context-v1.xml meson.build
<wlb> wayland-protocols Merge request !68 merged \o/ (security-context: new protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/68)
<wlb> wayland-protocols/main: David Redondo * xdg-activation: Clarify that the token stays valid if the object is destroyed https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/3c1fb30817dc staging/xdg-activation/xdg-activation-v1.xml
<wlb> wayland-protocols Merge request !214 merged \o/ (xdg-activation: Clarify that the token stays valid if the object is destroyed https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/214)
<wlb> wayland-protocols/main: Kirill Chibisov * stable/xdg-shell: clarify initial wl_surface acknowledgement https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/174b3487a2ac stable/xdg-shell/xdg-shell.xml
<wlb> wayland-protocols Merge request !213 merged \o/ (stable/xdg-shell: clarify initial wl_surface acknowledgement https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/213)
<jadahl> merge fest
<jadahl> and its only monday
<emersion> i think that's everything which was ready
<jadahl> i'll spin a release then
<emersion> sweet
<jadahl> one is just better wording for the same thing and the other is obviously what we weed to do
<emersion> feel free to merge, but since they're just README updates, i'm not in a hurry to push them
<emersion> (people usually look at READMEs from the GitLab page, not the release tarball)
<jadahl> alright, lets not delay things
<wlb> wayland-protocols Merge request !227 opened by Jonas Ådahl (jadahl) build: Bump version to 1.32 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/227
<wlb> wayland-protocols/main: Jonas Ådahl * build: Bump version to 1.32 https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/681c33c8547d meson.build
<wlb> wayland-protocols Merge request !227 merged \o/ (build: Bump version to 1.32 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/227)
<emersion> thanks!
<jadahl> seems my glab is old
<jadahl> there we go
<llyyr> nice
<wlb> wayland.freedesktop.org Merge request !59 opened by Jonas Ådahl (jadahl) releases: Add wayland-protocols 1.32 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/59
<wlb> wayland.freedesktop.org Merge request !59 merged \o/ (releases: Add wayland-protocols 1.32 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/59)
<wlb> wayland.freedesktop.org/main: Jonas Ådahl * releases: Add wayland-protocols 1.32 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/cb30e2d47198 releases.html
<emersion> at some point maybe we should just link to the GitLab release page
<emersion> instead of manually massaging the HTML each release
<jadahl> what the gitlab release page is missing is the announcement
<vyivel> how does one massage the html
<jadahl> link to announcement
<emersion> hm, true
<jadahl> vyivel: with the right kind of oil
<emersion> and GitLab releases are a but finicky: when editing them sometimes they loose the assets
<emersion> bit*
<jadahl> that sounds scary
<emersion> it is :<
luna has joined #wayland
<pq> kchibisov, what do you mean there are only downsides to doing decorations+app in the same surface? That's the ideal choice. No, you don't need to redraw everything to highlight a decor button, you track damage.
<kchibisov> I think I'm just used to hw accelerated rendering here.
<kchibisov> Or there're cases where you pass everything to e.g. skia.
luna has left #wayland [#wayland]
luna has joined #wayland
luna has left #wayland [#wayland]
<kchibisov> But it has nothing to do with how much you draw?
<kchibisov> you need buffer age.
<pq> yes, buffer_age is the other part
<pq> but without swap_buffers_with_damage, the compositor does too much work
<pq> it all exists if anyone just cares to use it
<kchibisov> I'm just saying that subsurfaces are way easy to set things up.
<pq> guess I just disagree
<kchibisov> I guess, I was just doing subsurfaces for decorations for a long time.
<kchibisov> The only issue is that compositors tend to break with them.
<pq> sub-surface seams have a risk of showing
<kchibisov> But if compositor can at least follow what subsurfaces expect it should be all good, given that you have sync/desync behavior.
<pq> compositor bugs and bugs, but even without those I wouldn't use sub-surfaces unless parts of the window may benefit performance by being on different buffers.
<pq> *are bugs
<kchibisov> I'd assume you're talking about video players.
<pq> yes, those are a prime example, since the buffer from a hw decoder might be able to shown on KMS, or at least you can avoid one GPU blit per frame.
<kchibisov> Like ideally you set `sync` on resizes, and then keep them desync.
<pq> yes, but even if a compositor implementation is fully correct protocol wise, the seams might show.
<pq> a compositor would need to do an intermediate composition of the window, and that would mostly void any benefits there were from sub-surfaces in the first place.
<kchibisov> That's true, but realistically you see csd decorations only on a few compositors, and even gtk does subsurfaces (just one though) iirc.
<kchibisov> Drawing decorations in your main surface could be better for perf in some clients, but it's way less convinient.
<pq> less convenient being better for perf seems like a universal truth :-)
<kchibisov> Also, decorations could be transparent, but main surface opaque, so main surface could be directly scanout.
<kchibisov> And decorations in real world are often has transparent hidden areas.
<pq> only as dmabuf
<kchibisov> That what I only do :p
<pq> btw. KMS does have some support for alpha-blending
<kchibisov> It does, but not all hardware can.
<pq> orowith2os, I still haven't read all gitlab backlog; both clients and compositors have the full right to have completely unusable GUI. It is not the protocol spec's purpose to demand that compositors and apps must "usable" - whatever that means. What do exist are app and compositor bugs and issues. All protocol violations are bugs, but not all bugs (or design choices) need to be protocol violations.
<pq> Wayland leaves much more things undefined than it defines, and that's fine. We still get usable apps and usable compositors, because they want to be usable, not because a spec says so.
<pq> I've had the same issue with some people about color management. It's hard to explain that things will be fine even if the protocol spec does not lock everyone into a single prescribed design.
<pq> or that one can still file bugs even if they are not protocol violations
fmuellner has joined #wayland
<pq> what we do need to make clear is the language that a client and a compositor speak to each other, and what the words there mean, so anything that *is* communicated is understood the same way by everyone.
<pq> Before Wayland, the mantra was "mechanism, no policy". With Wayland, it's "descriptive, not prescriptive" which is almost the opposite.
kts has quit [Quit: Konversation terminated!]
mvlad has quit [Remote host closed the connection]
nerdopolis has joined #wayland
<WhyNotHugo> cursor-shape doesn't allow hiding the cursor. Would be handy if wp_cursor_shape_device_v1::set_shape with shape==null hid the cursor.
<kchibisov> It was discussed, but it's expected that you use the `set_cursor` API.
eroc1990 has quit [Ping timeout: 480 seconds]
Moprius has joined #wayland
eroc1990 has joined #wayland
<MrCooper> kchibisov: FWIW, AFAICT GTK4 no longer uses sub-surfaces itself
Moprius has quit [Quit: bye]
mvlad has joined #wayland
Company has joined #wayland
leandrohrb5 has joined #wayland
<swick[m]> if you're having meetings about wayland-protocols and we consider it a standards body you should probably also publish some minutes of the meeting
<swick[m]> seems a bit opaque what's going on right now
<MrCooper> I think the "meetings" are GitLab MRs/issues? :)
<wlb> weston Merge request !1298 opened by Marius Vlad (mvlad) clients/window: Allow smaller pending allocation in clients https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1298 [Desktop shell]
<pq> actually, I do know of one secret meeting about to happen
<emersion> sorry, we do have informal meetings sometimes
<emersion> has happened once for fractional-scale, and another time last week for… general stuff
<pq> I'm typing a request to be more open right now.
<emersion> i agree that discussing behind closed doors is not super great
<emersion> these meetings so far have been organized in an organic manner, soeone (generally from KDE ♥) says "we should talk" and then we do
<emersion> we do not have any person in charge of taking notes (i did try to take notes, but it's not exhaustive nor well-written)
<pq> are they audio calls or chat?
<emersion> audio calls
<wlb> weston Merge request !1299 opened by Marius Vlad (mvlad) desktop-shell: Handle all other shell surfaces in case of an output resize https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1299 [Desktop shell]
<wlb> weston Merge request !1300 opened by Marius Vlad (mvlad) backend-drm: Use resize_output to allow changing the fb https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1300 [DRM/KMS backend]
<psykose> emersion: spy!
<emersion> :D
Moprius has joined #wayland
manuel_ has quit [Ping timeout: 480 seconds]
<drakulix[m]> @pg agreed. I guess I should just sent out information on the next meeting on the mailing list then.
<drakulix[m]> Apologies, as emersion pointed out this developed quite organically, I'll certainly try to make the process more open next time.
<jadahl> being more public next time would be better indeed. the one that happened wal
<jadahl> last week was more grown out of "put wlroots and kde in a room" that leaked
<drakulix[m]> emersion: If you have notes from last time would you mind creating an issue for meeting notes and to summarize the last meeting? I'll try to do the same for the upcoming one.
<jadahl> leaked into others brain, I mean
Moprius has quit [Quit: bye]
<emersion> drakulix[m]: your email provider is generating DKIM signatures which are incompatible with mailing lists
<emersion> (ended up in my spam folder)
<emersion> (specifically, the ML adds a Sender header, and your DKIM signature forbits it)
<drakulix[m]> emersion: I used my company mail, so I am quite surprised by that.
<drakulix[m]> Thanks for the heads up though. I am trying to fix this. I guess this means I need to send out the mail again?
<emersion> i don't think it's necessayr
<swick[m]> drakulix: thanks!
junaid has joined #wayland
eroc1990 has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
Net147 has quit [Ping timeout: 480 seconds]
kenny has quit [Ping timeout: 480 seconds]
manuel_ has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
pasmer has joined #wayland
eroc1990 has joined #wayland
Net147 has joined #wayland
<Company> swick[m], emersion: I think this "standards body" thing is not soemthing anyone can declare to be - it's earned when other assign that label to you
<emersion> nope
<Company> like, I don't think GTK devs consider any wayland entity to be in any way the arbiter for features GTK should implement
<emersion> that's not what a standards body is or does
<emersion> a standard body is a group of people who create standards
<emersion> Khronos publishes many extensions, and Khronos does not force vendors to implement the extensions
<emersion> the same goes for W3C, IRCv3, etc etc
<emersion> IETF
<Company> w3c works by Google submitting long drafts and Apple just implementing random things for iphones and then they argue in github issues why either approach is suboptimal
<psykose> sounds worse than w-p !
<Company> and it's still better than C++!
<Company> I think in general the wayland appraoch works quite well - like with the hdr / color amanagement stuff now
<Company> it just breaks down when multiple sides disagree on some fundamentals
<Company> but I don't think that's something you can change via the process
pasmer has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
kts has joined #wayland
nerdopolis has joined #wayland
<dottedmag> Clarifying moments like "is w-p a standards body?" in documentation makes certain kinds of bad arguments to disappear, which raises the general level of discussion.
mvlad has quit [Remote host closed the connection]
eroc1990 has quit [Remote host closed the connection]
junaid has joined #wayland
junaid has quit []
junaid has joined #wayland
Narrat has joined #wayland
Brainium has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
fmuellner has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
rv1sr has quit []
___nick___ has quit [Ping timeout: 480 seconds]
<orowith2os> what's the point of the single-pixel-buffer protocol? https://wayland.app/protocols/single-pixel-buffer-v1
<orowith2os> like, I get that it's for creating single-pixel buffers, but why would one want that?
kts has quit [Quit: Konversation terminated!]
<ifreund> to make surfaces with only a single color cheaper
<ifreund> (note that it can be used with viewporter as mentioned in the protocol)
<orowith2os> what would a real-world use case be?
<orowith2os> a GUI toolkit?
<kennylevinsen> orowith2os: solid background filling entire surface for example
<kennylevinsen> Using viewport
<rosefromthedead> i feel like we're going in circles here :P
<rosefromthedead> im writing a text editor and if kwin supported single-pixel-buffer then i'd be using them to draw the background, but really im not sure what that gets me other than changing the background colour being quick
<rosefromthedead> which is gonna happen maybe once a month for a weird user
<psykose> would it use less idle memory for just having the background painted or nah
<orowith2os> kennylevinsen oooh, I see it now. I'm going through some protocols I've never understood, reading them to see what I can make sense of
<kennylevinsen> Otherwise kind of expensive to fill a 4k monitor with black pixels - that's a 32MB buffer to fill. wldash2 (launcher) uses it for just that - then it only has to render the text bits here and there
<rosefromthedead> oh yeah that's why i did it LOL
<rosefromthedead> yeah my buffers that actually contain text can be smaller overall than the editor window, so the buffer is an easy way to fill in the whole background
<rosefromthedead> so it isn't transparent
<emersion> i use it for a client which gradually dims the screen
<emersion> also used by swaybg for solid color backgrounds
<emersion> some clients use it for window decorations
<orowith2os> huh, this is... interesting. I'd think KDE would have some of the best Wayland support out there based on their recent improvements, but even Mutter is ahead for what looks like generally useful protocols?
<orowith2os> depending on protocols, ofc
<orowith2os> okay, never mind, maybe?
<rosefromthedead> lol
<orowith2os> so far, it's presentation-time and single-pixel-buffer
<rosefromthedead> iirc the ones kwin has over mutter are generally the "insecure" ones like wlr-data-control
<rosefromthedead> ones which bring the missing features that plasma/xorg had
<orowith2os> seems more like "features" than features
<rosefromthedead> well, klipper is fluff right until you need it ;)
<orowith2os> I can see some more dedicated, secure APIs, like a portal, being more useful here?
<orowith2os> then you don't have random clients trying to be a clipboard manager :)
<emersion> wayland protocols can be secured
<orowith2os> (I still don't get the idea behind a "privileged" protocol)
<orowith2os> it sounds impossible without some form of sandboxing, so you don't have apps saying they're a shell when they're not
<emersion> yes, just like flatpak
<danieldg> orowith2os: basically yes, it requires either sandboxing or direct-launching of privileged helpers
<emersion> and then use security-context to figure out the sandbox for instance
<danieldg> the latter is mostly xwayland
<orowith2os> danieldg: oh, so Flatpak can enforce that apps don't try to use the wrong reverse-dns names?
<danieldg> yep
nerdopolis has quit [Ping timeout: 480 seconds]
<danieldg> or to do thing that they aren't supposed to do (say, lock the screen)
<danieldg> *things
<orowith2os> can Flatpak also allow apps to take control of several names, or is it just the appid they're running inside of?
<orowith2os> I know they allow it for dbus, at least
<emersion> flatpak apps have a single appid
<emersion> afaik
<danieldg> libreoffice (which has a flatpak) does use multiple appids
<orowith2os> yeah, that's why you have permissions like --own-name
<rosefromthedead> if you want a client to be privileged, it has to open its wl connection in a special way right? or is there another way to identify trusted clients?
<orowith2os> danieldg: their appid on Flathub is org.libreoffice.LibreOffice, let me see what happens when it's installed
<danieldg> rosefromthedead: that's one way to do it; the other is to specifically de-privilege sockets that are used in sandboxes
<emersion> danieldg: only one flatpak app_id though, no?
<danieldg> emersion: correct
<danieldg> the reuse of appid for XDG is confusing
<emersion> yeah, i was talking about flatpak app_ids all along
<danieldg> yeah, I just realized that the names collided
<orowith2os> danieldg it looks like the LibreOffice flatpak only uses org.libreoffice.LibreOffice
<orowith2os> not even some extra --own-names, other than org.libreoffice.LibreOfficeIpc0
<orowith2os> there are several desktop files, but those aren't really relevant; you can have several desktop files within one appid
<danieldg> libreoffice has one flatpak appid, but multiple xdg/wayland app_id values (calc vs writer vs ...) - one per icon
<danieldg> I expect one desktop file per xdg appid
<orowith2os> is there a quick way I can check?
eroc1990 has joined #wayland
<orowith2os> the wayland app_id, that is
<danieldg> yes - /var/lib/flatpak/exports/share/applications has 8 .desktop files for it
<orowith2os> they're all within org.libreoffice.LibreOffice, at least
<danieldg> launch libreoffice and look at the window properties (with swaymsg -t get_tree for example)
<orowith2os> (on GNOME)
<danieldg> you can always launch with WAYLAND_DEBUG=1 and grep stderr for app_id
<danieldg> gnome might have a way to query appids but I don't know it
<orowith2os> ooooh this is cool
junaid has quit [Remote host closed the connection]
<orowith2os> not reverse-dns? huh
<danieldg> yeah, it's usually the icon name
<danieldg> I expect the actual .desktop field is StartupWMClass
nehsou^ has joined #wayland
<orowith2os> bingo
<orowith2os> StartupWMClass=libreoffice-startcenter
<orowith2os> if that's not set, it looks like the APPID is used, yeah
<orowith2os> GNOME Builder, both stable and devel, have their appids set according to their package
<orowith2os> this seems like it could cause issues, especially when it comes to bypassing the sandboxing, but w/e
fmuellner has joined #wayland
<danieldg> one solution to this is to preface the application-provided app_id with the sandbox-provided ID (so org.libreoffice.LibreOffice.libreoffice-startcenter here), with similar changes to .desktop files so they are tied together
<danieldg> or, like dbus ownership, just have a list of "allowed" app_id values
Moprius has joined #wayland
rederick29 has quit [Remote host closed the connection]
<jadahl> orowith2os: iirc gnome-shell uses the flatpak app id for libreoffice as a "prefix" to allow associating e.g. writer vs calc with the right desktop file
gfxstrand has quit [Ping timeout: 480 seconds]
Moprius has quit [Quit: bye]
<wlb> weston Merge request !1301 opened by Daniel Stone (daniels) tests: Initialise breakpoint list for all test types https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1301 [Testing]
carbonfiber has quit [Quit: Connection closed for inactivity]
systwi has quit [Ping timeout: 480 seconds]
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #wayland
DodoGTA has quit []
DodoGTA has joined #wayland
manuel_ has quit [Ping timeout: 480 seconds]
gfxstrand has joined #wayland
systwi has joined #wayland
Brainium has joined #wayland
Narrat has quit []
Brainium has quit [Quit: Konversation terminated!]
systwi has quit [Ping timeout: 480 seconds]
systwi has joined #wayland