ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Crocodillian has joined #wayland
<Crocodillian>
Hi, do I need to call gdk_init() before GDK_IS_WAYLAND_DISPLAY() will work?
<Crocodillian>
and if so, are there other ways to check for wayland?
<danieldg>
look for either wayland environment variable to be set
<Crocodillian>
I see, thank you.
mblenc has quit [Remote host closed the connection]
mblenc has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
privacy has quit [Remote host closed the connection]
mblenc has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
nerdopolis has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest2453
cool110- has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
utsweetyfish has quit [Remote host closed the connection]
utsweetyfish has joined #wayland
Guest2453 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest2459
utsweetyfish has quit [Remote host closed the connection]
<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
<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
<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
Company has quit [Quit: Leaving]
<Crocodillian>
yeah I ended up checking XDG_SESSION_TYPE and WAYLAND_DISPLAY like danieldg suggested
<danieldg>
ah, sorry, I meant checking for either WAYLAND_DISPLAY or WAYLAND_SOCKET being set; XDG_SESSION_TYPE is another good one, though
floof58 has joined #wayland
utsweetyfish has quit [Remote host closed the connection]
utsweetyfish has joined #wayland
utsweetyfish has quit [Remote host closed the connection]
utsweetyfish has joined #wayland
the_sea_peoples has joined #wayland
utsweetyfish has quit [Remote host closed the connection]
utsweetyfish has joined #wayland
<orowith2os[m]>
emersion: thoughts on using inputfd as a private compositor protocol?
<orowith2os[m]>
for context, I'd like to see if it could be useful for wlroots to implement a VR portla
junaid has quit [Remote host closed the connection]
mblenc has joined #wayland
privacy has quit [Remote host closed the connection]
utsweetyfish has quit [Remote host closed the connection]
utsweetyfish has joined #wayland
dcz_ has joined #wayland
cmichael has joined #wayland
cstub has joined #wayland
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
<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.
<zamundaaa[m]>
yes, the intention was to not couple it with HDMI
fmuellner has joined #wayland
<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
<pq>
why would one do that?
<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
<pq>
I worry it might easily slip into being e.g. a poor color management interface.
<zamundaaa[m]>
Why would it?
<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?
<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.
<pq>
tag surfaces as this and that, and then try to come up with how that's maybe useful
<zamundaaa[m]>
I already told you how having such information is useful in practice today in the real world
<pq>
I didn't get it.
<zamundaaa[m]>
<zamundaaa[m]> "Because you might for example..." <- That
<zamundaaa[m]>
And yes, handling video colors differently is also a possible use case. I know that Windows and Android both do such things
<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?
<pq>
why would handling video colorimetry differently be needed after we get color-representation and color-management extensions?
<zamundaaa[m]>
Because these things are exclusive
<pq>
which "these"?
<zamundaaa[m]>
pq: You can't have the primary content of a surface be a game, text, photo and video simultaneously
<pq>
yes, that's the point of in HDMI: it chooses between global image processing methods
<pq>
the content type you are now talking about is not staging/content-type
<zamundaaa[m]>
Yes it is
<pq>
no, it's not. staging/content-type is exclusive, like you said.
<zamundaaa[m]>
Yes? Why would adding a "text" type suddenly not be exlusive?
<pq>
video containing text, text based games, text in images...
<zamundaaa[m]>
That is not useful information for the use case I described
<pq>
but maybe "text" somehow still can fit to be exclusive from everything else
<pq>
what about some next type someone else wants?
<zamundaaa[m]>
That type can be looked at when it comes up. Like with literally everything else anyone wants to add to any protocol
<pq>
you only described "adjusting colorimetry to improve readability", yes? What if it's a game and it would also like low latency?
<zamundaaa[m]>
I don't understand what you're getting at
<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.
<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.
<pq>
and you can't stop supporting them once added
<zamundaaa[m]>
I was the one that pushed for that protocol... the idea was very much not about HDMI content type at all
<pq>
right
xaizone4 has joined #wayland
<pq>
as you saw, I never reviewed it
<zamundaaa[m]>
pq: The types are nothing but hints for the compositor to do whatever it wants with it
xaizone4 has quit []
<pq>
that's a bit of a problem
<pq>
the description of the four current entries do give some idea what kind of content they are intended to reflect
<pq>
they are also mostly non-overlapping, which makes using and handling them easy
<pq>
they carry client intent
<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.
<pq>
then the question is, why should the compositor do that? why isn't the client doing that?
<pq>
if there is a good answer to that, then fine by me
<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)
<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
floof58 has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
pq: I do very much agree that window management related things don't belong into content type
<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.
<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.
floof58 has joined #wayland
slattann has quit [Ping timeout: 480 seconds]
Moprius has joined #wayland
utsweetyfish has quit [Remote host closed the connection]
utsweetyfish has joined #wayland
<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"?
<dottedmag>
At least this will allow one to point to the actual words of the proposed spec instead of IRC logs.
carlos_ has joined #wayland
carlos_ has left #wayland [#wayland]
carlos_ has joined #wayland
carlos_ has left #wayland [#wayland]
carlos_ has joined #wayland
carlos_ has left #wayland [#wayland]
ascent12_ has joined #wayland
ascent12 has quit [Ping timeout: 480 seconds]
carlos_ has joined #wayland
Company has joined #wayland
Moprius has quit [Quit: bye]
MrCooper has quit [Remote host closed the connection]
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
nerdopolis has joined #wayland
MrCooper has joined #wayland
manuel1985 has joined #wayland
slattann has joined #wayland
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
<pq>
That question about proxy-wrapping wl_display is actually a pretty deep one. Right now it's not supposed to work, is it?
<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.
<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.
<pq>
other threads could flush the registry creation out, and read the socket for the registry events before your queue assignment goes through, right?
<pq>
does it then make sense to make wl_display proxy-wrappable in order to create wl_registry straight to the right queue?
<elinor>
Uh, wl_display is not proxy-wrappable?
<pq>
I'm not sure, it never even crossed my mind to try.
cstub has quit []
<pq>
and there is someone on the mailing list complaining it doesn't do what's expected
<elinor>
Because wayland-rs has been creating proxies out of wl_display for quite some time now, and we never encountered any visible issue...
<pq>
hmm, that's a good data point
<pq>
wl_proxy_set_queue on the original wl_display does not work, at least
<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
<pq>
the problem is the events get dispatched from a wrong context
<pq>
..or do not get dispatched when round-trippping the right context (queue)
slattann has quit [Ping timeout: 480 seconds]
<elinor>
could it be because they invoke wl_display_roundtrip_queue() by feeding it the wrapped_display instead of the original wl_display, maybe?
<pq>
that's a very good question
<pq>
bbl
<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).
<davidre>
I am fairly certain mesa created a wrapper for wl_display
<pq>
I did start wondering how do you do roundtrips without wrapping the wl_display.
<pq>
lol, wl_display_roundtrip_queue() itself creates a proxy-wrapper of wl_display, no idea how I forgot that :-D
mohit815 has quit [Quit: mohit815]
mohit815 has joined #wayland
mohit815 has quit []
mohit815 has joined #wayland
mohit815 has quit [Quit: mohit815]
mohit815 has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
caveman has quit [Ping timeout: 480 seconds]
caveman has joined #wayland
tzimmermann has quit [Quit: Leaving]
<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
<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
bindu_ has joined #wayland
<orowith2os[m]>
paired with the categories listed in the desktop file
bindu has quit [Ping timeout: 480 seconds]
<orowith2os[m]>
the more information a compositor has, the more it can optimize the user experience, among technical details
glennk has quit [Ping timeout: 480 seconds]
junaid has joined #wayland
cmichael has quit [Quit: Leaving]
mblenc_ has joined #wayland
mblenc has quit [Quit: Quit]
<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?
mblenc_ has quit []
mblenc has joined #wayland
<orowith2os[m]>
ideally a web browser would be a bit of a technical detail here
<orowith2os[m]>
it should, in this case, set a "document" content type when e.g. in Google Docs
<orowith2os[m]>
and the compositor would know it's a web browser based off of its desktop file
<orowith2os[m]>
but that also requires support in the web specs
<orowith2os[m]>
for native apps, like LibreOffice, the compositor would know it would map to the "document" content type based off the desktop file
<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"
<orowith2os[m]>
tbf this could also be helped with a color management protocol
<kennylevinsen>
your intent also seemed to be more aligned with wm features which might be less tricky, while zamundaaa mentioned different rendition
<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
mblenc has quit [Read error: Connection reset by peer]
<swick[m]>
just don't implement it
<swick[m]>
this kind of stuff is just awful
<swick[m]>
shouldn't exist in display specs either
<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
<swick[m]>
it makes no sense to any composited environment at all
<orowith2os[m]>
it makes sense to TVs, which can apply optimizations when they e.g. know a game is running
<orowith2os[m]>
and I believe consoles use that feature a bunch
<swick[m]>
"optimize"
<swick[m]>
this is just complete bullshit
<orowith2os[m]>
yes, latency, looks, etc
juergbi has quit []
<orowith2os[m]>
like it or not, this information is already being put to use in the real world
<swick[m]>
being put to use or being useful are two very different things
<swick[m]>
consoles etc use special modes which are not tied to content type
<swick[m]>
exactly because it's utterly stupid
<orowith2os[m]>
I'm sure Gamescope/Joshua Ashton could argue you on that
<swick[m]>
they have their own mode which makes more concrete, tangible changes
<orowith2os[m]>
you mean "Game Mode"?
juergbi has joined #wayland
<swick[m]>
there is a bunch of "standards"
<swick[m]>
ALLM, SBTM
<orowith2os[m]>
ah, but there's one standard to worry about here, and that's the HDMI one
<orowith2os[m]>
at least, afaik
<swick[m]>
oh noy
<swick[m]>
yes, afayk
<swick[m]>
no offense but you clearly don't know how HDMI works
<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
<orowith2os[m]>
I don't think my TV was released then
<swick[m]>
first displays with it released a few month ago
<orowith2os[m]>
then yeah, doesn't matter very much here
<orowith2os[m]>
wanna go again?
<swick[m]>
ofc it does
<swick[m]>
it's one of those things that was standardized after some proprietary exts
<swick[m]>
amd freesync pro for example
<swick[m]>
the point is that there are several vendor specific hdmi extensions which are used by consoles and windows drivers
<swick[m]>
all giving you more concrete benefits than just "this is game"
<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
<swick[m]>
which is also not a good idea
<swick[m]>
it's literally never a good idea
<swick[m]>
as soon as you start having random properties with no meaning, things become horrible
<orowith2os[m]>
there is meaning here - it's just decided by different parties
<swick[m]>
which is exactly the same as no meaningf
<swick[m]>
they have no defined semantics which makes them per definition useless
<swick[m]>
but hey, have your opinion
<zamundaaa[m]>
It very obviously is not useless at all
nerdopolis has quit [Ping timeout: 480 seconds]
<swick[m]>
i disagree
<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
<swick[m]>
again, you're equating some undefined properties to a feature which might actually be useful
<zamundaaa[m]>
The feature is useful right now
<orowith2os[m]>
"might" be useful?
<orowith2os[m]>
it is useful
<swick[m]>
are you trying to misunderstand things here?
<swick[m]>
the feature itself is not what I'm arguing against
<swick[m]>
tying it to a sementically meaningless property is
<orowith2os[m]>
then we can just... not do that
<orowith2os[m]>
straight-up, just say "this surface gets marked as a video game by the compositor"
<orowith2os[m]>
nothing on what the compositor would do with that
<swick[m]>
I'm feeling like I'm getting trolled
<swick[m]>
Dallas Strouse (she/her) 🧑🏫: the discord server is not good for you
<orowith2os[m]>
and not the other way around?
<orowith2os[m]>
alright
<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
<orowith2os[m]>
in fact, right now, it's all a "the compositor may do this"
<orowith2os[m]>
one could very well put it to use outside of what it was originally designed with
<orowith2os[m]>
and nobody would bat an eye
<orowith2os[m]>
except you, apparently, for no reason other than to start things
<swick[m]>
like I said, the discord server and certain people there are not good for you
<orowith2os[m]>
you aren't too nice yourself, you know
<orowith2os[m]>
how nobody's warned you for that yet, I will never know
<orowith2os[m]>
but expect me to give back all of the shit that you give
<kennylevinsen>
both of you can have a warning if you want - play nice
ascent12_ has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
ascent12 has joined #wayland
<YaLTeR[m]>
which discord server tho
<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
<YaLTeR[m]>
no worries i already have several screenfuls of servers to waste time in
<orowith2os[m]>
discord's new username system is goofy, lol
<orowith2os[m]>
can guess people
<orowith2os[m]>
's usernames fairly easily....
<YaLTeR[m]>
if i didn't want my name to be guessed i wouldn't make it the most obvious one
<orowith2os[m]>
fair
Leopold___ has joined #wayland
Leopold has quit [Ping timeout: 480 seconds]
gspbirel56873408867061314487 has joined #wayland
gspbirel5687340886706131448 has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
slattann has joined #wayland
<zzag>
Does Xwayland still require wl_drm?
<zzag>
ofourdan: emersion: ^
<orowith2os[m]>
huh, no description on the wl_drm protocol, looks like....
<orowith2os[m]>
(and why is it an external protocol?)
Moprius has joined #wayland
Moprius has quit [Quit: bye]
junaid has quit [Quit: leaving]
junaid has joined #wayland
<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.
agd5f_ has quit []
agd5f has joined #wayland
<orowith2os[m]>
JoshuaAshton: probably would've been good to note where that comment was starting off from :P
<orowith2os[m]>
but yeah, right now the protocol looks like something more useful for a WM to deal with
slattann has quit [Ping timeout: 480 seconds]
junaid has quit [Quit: leaving]
<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.
<JoshuaAshton>
zamundaaa[m]: Makes sense, there's some other rationale you could have to re. VRR and cursor usage if its a fullscreen surface
<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. :/
<JoshuaAshton>
and yes... I know what "certain people" means.
<orowith2os[m]>
if it's worth anything, I'm trying to bring it up with some relevant parties too.
<orowith2os[m]>
GNOME, specifically
junaid has joined #wayland
<i509vcb>
orowith2os[m]: there actually is documentation for wl_drm, but it's xml comments so the protocol generator can't see it
<orowith2os[m]>
eugh
<orowith2os[m]>
sounds like something I could contribute, maybe
<orowith2os[m]>
wayland.app > bare xml
<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
<orowith2os[m]>
more things for me to split my attention off into is always fun :)
iomari891 has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
<dottedmag>
JoshuaAshton: I guess the answer is that Mesa implements pre-specified APIs, so all the arguing is done in the corresponding commitees.
sima has quit [Ping timeout: 480 seconds]
cstub has joined #wayland
<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
<swick[m]>
if you come in here hot like that you get the reaction you're looking for
mblenc has joined #wayland
<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?
<orowith2os[m]>
Am I wrong though?
<orowith2os[m]>
Saying "more developers should go caving" doesn't look nor sound so good.
<swick[m]>
and here come the justifications for constantly harassing someone
<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.
<swick[m]>
I have not done anything to you and you're harassing me
<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.
<swick[m]>
daniels: this is a gross misrepresentation because you're missing a ton of context
<orowith2os[m]>
I can provide tons of context if necessary.
<orowith2os[m]>
Including several abusive comments from you and a few specific others within GNOME.
<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.
<swick[m]>
there always is personal sniping. weather you can see it here or not is a different story.
<swick[m]>
*whether
<swick[m]>
and I'm tired of it
<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.
<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.
<daniels>
please CC conduct@lists.fd.o then - it's not the first time the two would've worked together
<daniels>
I can't do anything about LGD being a cesspit, but I can & will make sure that #wayland isn't as bad
<orowith2os[m]>
Noted, thanks.
<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.
<psykose>
were the first two warnings not enough
<kennylevinsen>
swick[m]: not everything, you have also made important contributions that are much appreciated (color management stuff with pq comes to mind)
nerdopolis has joined #wayland
<kennylevinsen>
but we do need *all* parties to return to calm discussions