00:03 Crocodillian: Hi, do I need to call gdk_init() before GDK_IS_WAYLAND_DISPLAY() will work?
00:03 Crocodillian: and if so, are there other ways to check for wayland?
00:10 danieldg: look for either wayland environment variable to be set
00:11 Crocodillian: I see, thank you.
03:50 wlb: wayland-protocols Merge request !246 closed (content-type: Add "sensitive" content type)
03:53 Company: Crocodillian: yes, gtk_init() needs to be called if you use GTK - and GDK_IS_WAYLAND_DISPLAY() is the best way to check with GTK
03:54 Company: Crocodillian: if you just want to write a simple tool that checks if you're on Wayland or X11, then calling wl_display_connect() is probably the best way
03:55 Company: though I'd not recommend that if you use GTK because people can send environment variables like GDK_BACKEND to influence if GTK will use Wayland or X11, so knowing if you're on Wayland won't help there
03:58 Crocodillian: yeah I ended up checking XDG_SESSION_TYPE and WAYLAND_DISPLAY like danieldg suggested
03:59 danieldg: ah, sorry, I meant checking for either WAYLAND_DISPLAY or WAYLAND_SOCKET being set; XDG_SESSION_TYPE is another good one, though
05:22 orowith2os[m]: emersion: thoughts on using inputfd as a private compositor protocol?
05:23 orowith2os[m]: for context, I'd like to see if it could be useful for wlroots to implement a VR portla
05:23 orowith2os[m]: *portal
05:23 orowith2os[m]: see https://github.com/flatpak/xdg-desktop-portal/issues/953 for more context
08:00 slattann: #TestMsg
08:20 dottedmag: slattann: passed
08:36 wlb: weston Merge request !1353 opened by Loïc Yhuel (hwti) gl-renderer: Do not attach the first buffer twice https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1353
08:37 wlb: weston Merge request !1354 opened by Loïc Yhuel (hwti) libweston: Do not include private headers in shell-utils.h https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1354
10:16 pq: orowith2os[m], danieldg, to me it feels like a bad idea to add things into content type extension that are not present in video signal specs like HDMI. It would confuse the whole extension, which your discussion seems to prove already.
10:30 emersion: completely agree
10:31 pq: looking at https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/150 though, seem it was intentionally decoupled from video signalling...
10:31 zamundaaa[m]: yes, the intention was to not couple it with HDMI
10:33 zamundaaa[m]: To not limit ourselves unnecessarily. If we want a "text" content type, or content types for game or video genres then there is nothing standing in the way of that
10:33 pq: why would one do that?
10:35 zamundaaa[m]: Because you might for example want to adjust the color temperature of text background for easier reading. Some Android vendors have a feature like that
10:35 pq: I worry it might easily slip into being e.g. a poor color management interface.
10:36 zamundaaa[m]: Why would it?
10:38 pq: maybe you start to assume that anything tagged as video needs a different kind of color management, because pushing video as-is to an sRGB display looks odd?
10:39 pq: I get the feeling that outside of monitor video signalling, which is still vague but at least somewhat specified, this is a solution looking for problems.
10:41 pq: tag surfaces as this and that, and then try to come up with how that's maybe useful
10:41 zamundaaa[m]: I already told you how having such information is useful in practice today in the real world
10:42 pq: I didn't get it.
10:42 zamundaaa[m]: <zamundaaa[m]> "Because you might for example..." <- That
10:42 zamundaaa[m]: And yes, handling video colors differently is also a possible use case. I know that Windows and Android both do such things
10:42 pq: If you want clients to be able to tag a surface as text so that the compositor can enhance contrast, why not do *that* rather than a generic type system trying to cover everything?
10:44 pq: why would handling video colorimetry differently be needed after we get color-representation and color-management extensions?
10:44 zamundaaa[m]: Because these things are exclusive
10:44 pq: which "these"?
10:45 zamundaaa[m]: pq: You can't have the primary content of a surface be a game, text, photo and video simultaneously
10:45 pq: yes, that's the point of in HDMI: it chooses between global image processing methods
10:46 pq: the content type you are now talking about is not staging/content-type
10:46 zamundaaa[m]: Yes it is
10:46 pq: no, it's not. staging/content-type is exclusive, like you said.
10:47 zamundaaa[m]: Yes? Why would adding a "text" type suddenly not be exlusive?
10:47 pq: video containing text, text based games, text in images...
10:48 zamundaaa[m]: That is not useful information for the use case I described
10:48 pq: but maybe "text" somehow still can fit to be exclusive from everything else
10:48 pq: what about some next type someone else wants?
10:49 zamundaaa[m]: That type can be looked at when it comes up. Like with literally everything else anyone wants to add to any protocol
10:49 pq: you only described "adjusting colorimetry to improve readability", yes? What if it's a game and it would also like low latency?
10:50 zamundaaa[m]: I don't understand what you're getting at
10:52 pq: It's really difficult to try to create a working taxonomy by adding concepts one by one as they are found. I'd suggest to not even try. Add each thing independently of anything previous, and see if it actually becomes exclusive or combining or whatever.
10:54 pq: Right now staging/content-type is probably somewhat useful when a compositor is trying to pick a HDMI content-type, but if you add more mutually exclusive things in it and they become used, it kinda thwarts the original idea.
10:54 pq: and you can't stop supporting them once added
10:54 zamundaaa[m]: I was the one that pushed for that protocol... the idea was very much not about HDMI content type at all
10:55 pq: right
10:55 pq: as you saw, I never reviewed it
10:55 zamundaaa[m]: pq: The types are nothing but hints for the compositor to do whatever it wants with it
10:55 pq: that's a bit of a problem
10:56 pq: the description of the four current entries do give some idea what kind of content they are intended to reflect
10:57 pq: they are also mostly non-overlapping, which makes using and handling them easy
10:58 pq: they carry client intent
10:59 pq: if you define a new mutually exclusive type "text", where the client intent is to let the compositor improve text readability in some way, that might be ok definition wise.
11:00 pq: then the question is, why should the compositor do that? why isn't the client doing that?
11:01 pq: if there is a good answer to that, then fine by me
11:03 pq: but if you start adding generic tags like "email", then I don't think staging/content-type is a good design for that because of the mutual exclusiveness and quite orthogonal intents (video processing vs. window management)
11:05 zamundaaa[m]: <pq> "then the question is, why should..." <- Because in order to do this well, the client would need to be given access to an ambient light sensor, potentially to night color settings of the user, to brightness settings and so on. The compositor can also have a unfiied setting for this kind of thing, and provide it for more than the two ebook readers that have the functionality
11:05 zamundaaa[m]: pq: I do very much agree that window management related things don't belong into content type
11:07 pq: color-management might end up providing much of that, but ok, color-management is also designed for clients that do not want to manage their own colors.
11:10 pq: I see content-type as providing informaation about the intended trade-offs between image quality and performance, I'm still not sure if accessibility belongs there.
11:54 dottedmag: pq: zamundaaa[m]: If there is a disagreement about the intended use of the protocol, maybe one should spell it out in the document, so that the discussion moves into "I don't agree to the documented intended use"?
11:54 dottedmag: At least this will allow one to point to the actual words of the proposed spec instead of IRC logs.
14:03 pq: That question about proxy-wrapping wl_display is actually a pretty deep one. Right now it's not supposed to work, is it?
14:05 pq: You can proxy-wrap a wl_registry to put all bound objects initially into your own queue, but the registry events themselves remain in the original queue.
14:05 pq: at least I don't see how one could reliably move the registry to your own queue, assuming you have other threads hammering the Wayland connection.
14:06 pq: other threads could flush the registry creation out, and read the socket for the registry events before your queue assignment goes through, right?
14:07 pq: does it then make sense to make wl_display proxy-wrappable in order to create wl_registry straight to the right queue?
14:08 elinor: Uh, wl_display is not proxy-wrappable?
14:08 pq: I'm not sure, it never even crossed my mind to try.
14:09 pq: and there is someone on the mailing list complaining it doesn't do what's expected
14:09 elinor: Because wayland-rs has been creating proxies out of wl_display for quite some time now, and we never encountered any visible issue...
14:10 pq: hmm, that's a good data point
14:11 pq: wl_proxy_set_queue on the original wl_display does not work, at least
14:11 elinor: Though we did not actively try to test it in an adverse multithreading context, so it might be there is a bug that we haven't noticed yet
14:12 pq: the problem is the events get dispatched from a wrong context
14:13 pq: ..or do not get dispatched when round-trippping the right context (queue)
14:14 elinor: could it be because they invoke wl_display_roundtrip_queue() by feeding it the wrapped_display instead of the original wl_display, maybe?
14:15 pq: that's a very good question
14:15 pq: bbl
14:21 elinor: Given a wrapped wl_display is just a wl_proxy, it seems to me that feeding it in place of the wl_display to the dispatching functions is pretty much UB (as they'll try to access the wl_display fields which are outside of the contents of the wl_proxy struct).
14:29 davidre: I am fairly certain mesa created a wrapper for wl_display
14:29 davidre: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/egl/drivers/dri2/platform_wayland.c#L774
14:30 davidre: It uses it at least to create callbacks
14:30 davidre: ` dri2_surf->throttle_callback = wl_display_sync(dri2_surf->wl_dpy_wrapper);`
14:35 pq: Thanks! I stand corrected. Good.
14:35 pq: I did start wondering how do you do roundtrips without wrapping the wl_display.
14:38 pq: lol, wl_display_roundtrip_queue() itself creates a proxy-wrapper of wl_display, no idea how I forgot that :-D
15:41 orowith2os[m]: pq: re the content type stuff, it could be used in coordination with many a other thing in order to enhance e.g. window management, for one example
15:42 orowith2os[m]: I might want video to go to a specific display or have the primary focus in a tiling window manager of some sort, for example
15:43 orowith2os[m]: paired with the categories listed in the desktop file
15:48 orowith2os[m]: the more information a compositor has, the more it can optimize the user experience, among technical details
16:26 kennylevinsen: hmm, gotta admit I have a hard time seeing it. What is a web browser? Is a word document with diagrams and an inline video text? As a user, why is only some of my apps getting easier to read due to compositor contras enhancements?
16:27 orowith2os[m]: ideally a web browser would be a bit of a technical detail here
16:28 orowith2os[m]: it should, in this case, set a "document" content type when e.g. in Google Docs
16:28 orowith2os[m]: and the compositor would know it's a web browser based off of its desktop file
16:29 orowith2os[m]: but that also requires support in the web specs
16:29 orowith2os[m]: for native apps, like LibreOffice, the compositor would know it would map to the "document" content type based off the desktop file
16:31 kennylevinsen: "why does the video in my PowerPoint look uglier than my video in VLC" "because PowerPoint is a Document-type app so it gets contrast enhancement from the compositor"
16:32 orowith2os[m]: tbf this could also be helped with a color management protocol
16:32 kennylevinsen: your intent also seemed to be more aligned with wm features which might be less tricky, while zamundaaa mentioned different rendition
16:33 orowith2os[m]: the whole content-type protocol is a bit abstract, so defining any one way for it to be used is tricky in of itself
16:34 swick[m]: just don't implement it
16:35 swick[m]: this kind of stuff is just awful
16:35 swick[m]: shouldn't exist in display specs either
16:35 zamundaaa[m]: kennylevinsen: there's a reason content type isn't static. Like the name says, it's about the content, not about the app
16:35 swick[m]: it makes no sense to any composited environment at all
16:37 orowith2os[m]: it makes sense to TVs, which can apply optimizations when they e.g. know a game is running
16:37 orowith2os[m]: and I believe consoles use that feature a bunch
16:37 swick[m]: "optimize"
16:37 swick[m]: this is just complete bullshit
16:37 orowith2os[m]: yes, latency, looks, etc
16:38 orowith2os[m]: like it or not, this information is already being put to use in the real world
16:38 swick[m]: being put to use or being useful are two very different things
16:39 swick[m]: consoles etc use special modes which are not tied to content type
16:39 swick[m]: exactly because it's utterly stupid
16:39 orowith2os[m]: I'm sure Gamescope/Joshua Ashton could argue you on that
16:39 swick[m]: they have their own mode which makes more concrete, tangible changes
16:40 orowith2os[m]: you mean "Game Mode"?
16:41 swick[m]: there is a bunch of "standards"
16:41 swick[m]: ALLM, SBTM
16:41 orowith2os[m]: ah, but there's one standard to worry about here, and that's the HDMI one
16:41 orowith2os[m]: at least, afaik
16:41 swick[m]: oh noy
16:41 swick[m]: yes, afayk
16:42 swick[m]: no offense but you clearly don't know how HDMI works
16:42 orowith2os[m]: point me to the standards a console would use when playing a game on a TV, and I can read up on em
16:42 swick[m]: hdmi 2.1a contains SBTM
16:42 swick[m]: good luck sourcing that
16:43 wlb: weston Merge request !1355 opened by Loïc Yhuel (hwti) gl-renderer: use correct read-back format and support WL_SHM_FORMAT_ABGR8888 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1355
16:43 orowith2os[m]: 2022 release date, apparently
16:43 orowith2os[m]: I don't think my TV was released then
16:44 swick[m]: first displays with it released a few month ago
16:44 orowith2os[m]: then yeah, doesn't matter very much here
16:44 orowith2os[m]: wanna go again?
16:44 swick[m]: ofc it does
16:45 swick[m]: it's one of those things that was standardized after some proprietary exts
16:45 swick[m]: amd freesync pro for example
16:45 swick[m]: the point is that there are several vendor specific hdmi extensions which are used by consoles and windows drivers
16:46 swick[m]: all giving you more concrete benefits than just "this is game"
16:47 zamundaaa[m]: I have to repeat here that content-type is explicitly not just about HDMI. ChromeOS for example uses it to set the power profiles of the GPU
16:47 swick[m]: which is also not a good idea
16:47 swick[m]: it's literally never a good idea
16:47 swick[m]: as soon as you start having random properties with no meaning, things become horrible
16:48 orowith2os[m]: there is meaning here - it's just decided by different parties
16:48 swick[m]: which is exactly the same as no meaningf
16:49 swick[m]: they have no defined semantics which makes them per definition useless
16:49 swick[m]: but hey, have your opinion
16:49 zamundaaa[m]: It very obviously is not useless at all
16:50 swick[m]: i disagree
16:50 zamundaaa[m]: In an ideal world we wouldn't need such optimizations, GPUs would have perfect preemntion so that latency can always be constant, GPUs wouldn't need power profiles etc etc... but we aren't in that real world, so things like this are very much helpful
16:51 swick[m]: again, you're equating some undefined properties to a feature which might actually be useful
16:51 zamundaaa[m]: The feature is useful right now
16:51 orowith2os[m]: "might" be useful?
16:51 orowith2os[m]: it is useful
16:51 swick[m]: are you trying to misunderstand things here?
16:52 swick[m]: the feature itself is not what I'm arguing against
16:52 swick[m]: tying it to a sementically meaningless property is
16:52 orowith2os[m]: then we can just... not do that
16:52 orowith2os[m]: straight-up, just say "this surface gets marked as a video game by the compositor"
16:52 orowith2os[m]: nothing on what the compositor would do with that
16:53 swick[m]: I'm feeling like I'm getting trolled
16:53 swick[m]: Dallas Strouse (she/her) 🧑‍🏫: the discord server is not good for you
16:54 orowith2os[m]: and not the other way around?
16:54 orowith2os[m]: alright
16:54 orowith2os[m]: but the point still stands - the content-type protocol doesn't need to say what a compositor can, will, or won't do with content types
16:55 orowith2os[m]: in fact, right now, it's all a "the compositor may do this"
16:55 orowith2os[m]: one could very well put it to use outside of what it was originally designed with
16:55 orowith2os[m]: and nobody would bat an eye
16:56 orowith2os[m]: except you, apparently, for no reason other than to start things
16:58 swick[m]: like I said, the discord server and certain people there are not good for you
17:01 orowith2os[m]: you aren't too nice yourself, you know
17:01 orowith2os[m]: how nobody's warned you for that yet, I will never know
17:01 orowith2os[m]: but expect me to give back all of the shit that you give
17:11 kennylevinsen: both of you can have a warning if you want - play nice
17:18 YaLTeR[m]: which discord server tho
17:19 orowith2os[m]: YaLTeR: "Linux Gaming Dev", I don't like it too much myself but it tends to be pretty useful to get a full view of the situation and to waste time in
17:19 YaLTeR[m]: no worries i already have several screenfuls of servers to waste time in
17:20 orowith2os[m]: discord's new username system is goofy, lol
17:20 orowith2os[m]: can guess people
17:20 orowith2os[m]: 's usernames fairly easily....
17:21 YaLTeR[m]: if i didn't want my name to be guessed i wouldn't make it the most obvious one
17:22 orowith2os[m]: fair
17:55 zzag: Does Xwayland still require wl_drm?
17:56 zzag: ofourdan: emersion: ^
17:58 orowith2os[m]: huh, no description on the wl_drm protocol, looks like....
17:58 orowith2os[m]: (and why is it an external protocol?)
18:18 JoshuaAshton: Gamescope doesn't use the Wayland protocol for this, because there is no client that would work for it right now. Currently Gamescope just always sends "Game" as the content flag to put some TVs in their low latency game modes without the awful motion smoothing/sharpening.
18:19 orowith2os[m]: JoshuaAshton: probably would've been good to note where that comment was starting off from :P
18:20 orowith2os[m]: but yeah, right now the protocol looks like something more useful for a WM to deal with
18:25 JoshuaAshton: But generally my take is that having more hints in the compositor side is a good thing. It's why Gamescope literally uses Win32 window styles to make decisions about what windows to focus, what are *really* popups.
18:29 JoshuaAshton: zamundaaa[m]: Makes sense, there's some other rationale you could have to re. VRR and cursor usage if its a fullscreen surface
18:31 JoshuaAshton: also man... why does everything have to get so super heated in the Wayland space all the time. Mesa has no issues like this. :/
18:33 JoshuaAshton: and yes... I know what "certain people" means.
18:34 orowith2os[m]: if it's worth anything, I'm trying to bring it up with some relevant parties too.
18:35 orowith2os[m]: GNOME, specifically
18:51 i509vcb: orowith2os[m]: there actually is documentation for wl_drm, but it's xml comments so the protocol generator can't see it
18:51 orowith2os[m]: eugh
18:52 orowith2os[m]: sounds like something I could contribute, maybe
18:52 orowith2os[m]: wayland.app > bare xml
18:54 i509vcb: Raising the comments to be scannable by the protocol generator probably isn't a bad idea, although no one really is focusing on wl_drm these days
18:56 orowith2os[m]: more things for me to split my attention off into is always fun :)
19:10 dottedmag: JoshuaAshton: I guess the answer is that Mesa implements pre-specified APIs, so all the arguing is done in the corresponding commitees.
20:35 swick[m]: JoshuaAshton: maybe it's because certain people come in here and just want to pick a fight with me because they made their mind up that I'm a horrible person that needs to be fought
20:36 swick[m]: if you come in here hot like that you get the reaction you're looking for
20:37 swick[m]: Dallas Strouse (she/her) 🧑‍🏫: if you call me an asshole behind my back, then start shitting on me on gitlab without me ever having interacted with you, what do you think is going to happen?
20:38 orowith2os[m]: Am I wrong though?
20:39 orowith2os[m]: Saying "more developers should go caving" doesn't look nor sound so good.
20:39 swick[m]: and here come the justifications for constantly harassing someone
20:39 orowith2os[m]: Addressing your behavior doesn't make you not an ass. You're just changing the terms you're using in the hopes you look like less of one.
20:40 swick[m]: I have not done anything to you and you're harassing me
20:41 daniels: swick[m]: no-one picked a fight with you. you started calling things 'complete bullshit', saying that widely-used things were 'useless', then started sniping at particular people unprovoked. you already got a warning from kennylevinsen, so just stop.
20:42 swick[m]: daniels: this is a gross misrepresentation because you're missing a ton of context
20:43 orowith2os[m]: I can provide tons of context if necessary.
20:44 orowith2os[m]: Including several abusive comments from you and a few specific others within GNOME.
20:48 daniels: the best place to chase that up would be fd.o/GNOME CoC, or the admins of a Discord or something. they can make their own decisions. but I'm tired of discussions in here descending into either insisting that things people want are not actually wanted by anyone, or just flat-out personal sniping and arguments. no more of it in here. full stop.
20:49 swick[m]: there always is personal sniping. weather you can see it here or not is a different story.
20:49 swick[m]: *whether
20:49 swick[m]: and I'm tired of it
20:51 daniels: if you want to put forward a wider complaint, then https://www.freedesktop.org/wiki/CodeOfConduct/ is the best venue, but if it just carries on out of context here with no resolution ever, I'm going to put bans in place. far too much has been derailed already.
20:54 orowith2os[m]: daniels: I am already bringing it up with the relevant GNOME folks, but this behavior is also not specific to GNOME. As you've seen, and can find on the fd.o gitlab, it happens here too.
20:54 daniels: please CC conduct@lists.fd.o then - it's not the first time the two would've worked together
20:56 daniels: I can't do anything about LGD being a cesspit, but I can & will make sure that #wayland isn't as bad
20:56 orowith2os[m]: Noted, thanks.
21:00 swick[m]: Dallas Strouse (she/her) 🧑‍🏫: rest assured, everything I've ever done has been reported to both fdo and gnome already. what has not been brought there however is how you're constantly harassing me, other gnome contributors and, how you're brigading issues.
21:01 psykose: were the first two warnings not enough
21:06 kennylevinsen: swick[m]: not everything, you have also made important contributions that are much appreciated (color management stuff with pq comes to mind)
21:07 kennylevinsen: but we do need *all* parties to return to calm discussions