ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
keir- has joined #wayland
keir has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
CodeSpelunker has joined #wayland
bodiccea has joined #wayland
gwizon has quit [Quit: Lost terminal]
CodeSpelunker has quit [Ping timeout: 480 seconds]
CodeSpelunker has joined #wayland
Company has joined #wayland
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
CodeSpelunker has quit [Quit: CodeSpelunker]
dcz_ has joined #wayland
dcz has joined #wayland
dcz_ has quit [Read error: Connection reset by peer]
<ahmadraniri[m]>
<ifreund> "so remove them from the list? wl..." <- Hi, it works, thanks ifreund.
tzimmermann has joined #wayland
dcz has quit [Ping timeout: 480 seconds]
psykose has quit [Remote host closed the connection]
pbsds is now known as Guest810
pbsds has joined #wayland
Guest810 has quit [Ping timeout: 480 seconds]
pochu has joined #wayland
iomari891 has joined #wayland
fmuellner has joined #wayland
ahartmetz has joined #wayland
jmdaemon has joined #wayland
cmichael has joined #wayland
rasterman has joined #wayland
nomanias has joined #wayland
<nomanias>
Death metal exploit is not so difficult cause tcp is secure channeled communication protocol, only difficulty is to regenerate the hash of the communication https://github.com/Coalfire-Research/DeathMetal/blob/main/charles/charles.py their method is similar to uart, first they nop the load , then they inject the nonce or md5hash so everything would be juridically ok
<nomanias>
it is quite similar to uart, but the time they inject the nonce they can be already root
ahartmetz has quit [Quit: Konversation terminated!]
ahartmetz has joined #wayland
<nomanias>
so if it was a biggest level of threat to estonian country at the moment i would have to force my last liquid out, cause the defense to the commodity hw to annul those attacks is little more complex, it has quite medium complexity
<nomanias>
russians know all those vulnerabilities as americans and nato does, it's first they always used those simple intrusions over satellite guidance to send missiles to generals.
<nomanias>
things such as satellite phones were very big dark death
<nomanias>
but ukranian soldiers started to get training from nato and americans
fmuellner has quit []
fmuellner has joined #wayland
<nomanias>
Problem with me, everyone is so angry at me, and i got phone which is likely military tapped, but i am unsure which side of the conflict, so that is the problem when you author the code not yourself you have to trust others but i have kept using this phone and hopefully nothing happens, i think i am on the side of nato
<nomanias>
so i have not switched the phone
<nomanias>
hope that is the case otherwise i might get slaughtered
junaid has quit [Ping timeout: 480 seconds]
<nomanias>
used my hunch there, others thought this might be the technology for russians, cause they are advanced too, but i saw something that might be above russians according to my understandings and i think that might be the other side of the battle field.
<nomanias>
me i have never heard that russians posess such laser communication
<nomanias>
there are two sets of different implementations roughly, i call it bus guards, one that tries to service and defend against ddos too, but one that takes the abuse client off the line only
<nomanias>
so this looks like so, you have some bus content and you retime everything, depending what was posted on the bus your units can validate it and execute as delayed
<nomanias>
so the best one is that you hold the bus all the time open, but you have some fast networked computer resources
<nomanias>
but you add conent to the bus and decipher what attacker sent
<nomanias>
decoding what was sent, and should we react on executing ddos army at it
<nomanias>
first implementation can be thrown at the mix, but some claim it's more related already to military world
<nomanias>
cause it scrambles the bus while bus is held all the time open, it's not possible to read the circuits also
<nomanias>
and the level of complexity is not so dramatic high, it can be beautifully made for static location, one the wireless world, i do not have such backend equipment to draw back the ddos network of course.
<nomanias>
cause the mast in my house does not belong to me
nomanias was kicked from #wayland by ChanServ [You are not permitted on this channel]
<JEEB>
that was some weird spam
pochu_ has joined #wayland
pochu has quit [Ping timeout: 480 seconds]
<MrCooper>
not really spam per se, just ramblings of an individual with mental health issues
dcompoze has joined #wayland
dcompoze has quit []
<kennylevinsen>
Sure this isn't a Markov chain at this point?
<MrCooper>
yeah, he's been around for a long time
rasterman has quit [Quit: Gettin' stinky!]
cmichael has quit [Quit: Leaving]
cmichael has joined #wayland
<kennylevinsen>
Yeah fair enough, just feels like coherence is down
pochu_ has quit []
pochu has joined #wayland
nerdopolis has joined #wayland
psykose has joined #wayland
psykose has quit [Remote host closed the connection]
<Company>
like, if GTK was given a random icc profile (from a fullscreen gstreamer say) and wanted to pass it on, it seems suboptimal if stuff doesn't show up on screen
<Company>
otoh, GTK can likely just parse the profile and extract the stuff the shell cares about
<Company>
*the compositor
<jadahl>
yea, if it only cares about e.g. the primaries then it can extract them and create them via the other factory
<Company>
it seems a bit evil that we pass secret bianry blobs through the stack
<jadahl>
scary no doubt
<jadahl>
would have to wrap it in bubblewrap or something
<pq>
please do not assume that you can dissect all ICC files like that
<Company>
it's really convenient if you don't wanna touch the pixels
<Company>
pq: it feels weird to say "here's a magic blob that you don't understand, please just pass it on"
<pq>
yes?
<jadahl>
Company: if it's for a subsurface then it is just scary, not "bad" since you don't care about the content
<Company>
jadahl: if it's for a subsurface, GTK won't see it, because subsurfaces pass us by
<pq>
An ICC file contains a number of color transformations, from which you pick one based on your rendering intent, and connect it with the destination profile which may require additional comptation steps in between. You cannot assume that you can reduce an ICC file into anything else the protocol can carry.
<jadahl>
if its not a subsurface, you need to parse it and "composite" the content given the ICC profile in gtk
<Company>
jadahl: but even then it feels evil - there's 4MB of unknown data being happily passed through all sandboxes potentially into the kernel
<pq>
Company, it will definitely NEVER be parsed in kernel.
<jadahl>
pq: for "get pixels and ICC from gstreamer" I imagine the ICC profile as a whole has less meaning if the pixels are reprocessed by gtk thus it can use some other factory
<pq>
or even handed to kernel
<Company>
pq: passed to the kernel might happen sooner or later with things like virtio
<Company>
no idea if/when monitors are gonna start reading icc profiles
<Company>
but yeah, likely not in-kernel
<pq>
jadahl, sure, if GTK takes it onto itself to use the profile and produce pixels based on some other description, then that other description is what you'd use.
<JEEB>
I think at least some pro monitors boast that they can ingest some sort of ICC profiles?
<JEEB>
or at least LUTs based on them
<pq>
Company, ingesting a LUT is totally different from ingesting an ICC profile.
<pq>
like I said, an ICC profile contains possibly multiple color transformation pipeline definitions in both directions. It is nothing like what you see in the protocol elsewhere.
<Company>
yeah, icc profiles are wild
<Company>
which means they're an amazing path to exploit things
<Company>
buth in good and bad ways
<pq>
what isn't?
<pq>
However, it's a self-contained file of data. It's not executable, it does not contain bytecode or anything (yet), and it cannot refer to anything outside of itself.
<Company>
it feels to me like this should be some async call, so the app knows what it's getting into
<pq>
A wl_buffer is a huge binary blob.
<pq>
yes, jadahl raised a point there
<Company>
still not sure how i'd want to represent that in GTK
<pq>
in the end, you end up trusting the CMM you use to parse it
<pq>
what do you mean?
<Company>
do I send all the icc profiles to mutter just to have them ready when needed?
<pq>
all what icc profiles?
<Company>
do I have an API so people can say "make this icc profile usable with the compositor"?
<Company>
the ones people create ColorState objects with
<pq>
that's a way to make the app start-up heavy
<pq>
there is no "make this usable", either the compositor accepts it or it doesn't. If it doesn't, you get to fall back any way you like.
<Company>
well, if it's async, then the answer is "maybe" until I get a reply
<pq>
sure
<Company>
but attaching a buffer to the surface isn't async
<pq>
but you cannot use an image description anyway until it's ready, even if it is acceptable
<Company>
so I need to be sure the compositor has made the decision before I try to attach a surface
<pq>
yes
<Company>
so I need to make it acceptable
<Company>
asap
<Company>
because who knows how long it takes
<Company>
once I want to use it
<pq>
you can't
<Company>
well yeah, so I'm in a bit of a pickle
<pq>
just like you can't know when the surface commit is actually going to be shown
<pq>
until it actually is shown
<Company>
I can either parse the profile locally and do a fallback path, if the compositor can't handle it
<Company>
or I can let the compositor take care of things
<Company>
but if the compositor hasn't answered yet, what do I do?
<Company>
not attach a buffer yet?
<Company>
do the fallback until it replies?
<zamundaaa[m]>
You always need a fallback path, as the compositor isn't required to support icc profiles
<zamundaaa[m]>
Company: Yeah
<pq>
Why does it need to be so immediate? If it's a new window, why can't you fold that delay to the delay on mapping/showing the window? If it's an existing window, why can't you let it run without the new thing until the image description is ready?
<Company>
sure, but if my fallback is visually different, it will glitch once I get a reply
<Company>
pq: dunno - I'm just wondering
<Company>
there's probably multiple different use cases
<pq>
don't do the fallback in the meantime, that could lead to a glitch if the compositor accept and you move to relying on the compositor.
<Company>
not sure if videos can change the icc profile they use halfway through
<jadahl>
the mapping of a window is already pretty async, the difference would be if an existing window should suddenly get an ICC profile attached to it that it wants to forward, which seems a bit unlikely if it still needs to draw widgets etc
<pq>
so yeah, creating some image description in advance could be useful if you know you will likely need them
<Company>
jadahl: an example would be pressing the "next image" hotkey in fullscreen Loupe
<Company>
and the next iamge being one with a fancy new icc profile
<pq>
Company, then the photo is on a sub-surface. If you're not using a sub-surface, then you get to re-draw all your UI elements too using the photo's profile.
<Company>
fullscreen often has no ui elements
<pq>
ok
<Company>
but yeah, that would be another question
<Company>
should I use the typical path anyway if I might need UI elements later
<pq>
An image description is always set on a whole wl_surface, not a sub-region of it. If you change the image description, the whole surface is affected.
<Company>
yeah, but I could switch when not needing any UI elements
<pq>
I would very much recommend using sub-surfaces for photo etc. viewers, because you may not be able to match your UI element colors with the photo's profile.
<pq>
sure, you can switch
nomanias has quit []
<pq>
OTOH, an application could target the compositor recommended image description only, do all color management itself, and never relay any photo etc. profiles to the compositor.
<Company>
I generally assume that the app and compositor are equally capable in their color management features
<pq>
assuming the application understand the recommended image description
<Company>
and the goal is for app + compositor to get the original image to the monitor as unmodified as possible
<jadahl>
Company: but shouldn't moving the mouse and showing the overlay widgets show the exact same content, meaning you need to handle re-processing the pixels in gtk without any precision loss anyway
<Company>
ie it's about matching the monitor's abilities with the data
<Company>
jadahl: yes, it's a tradeoff
<Company>
jadahl: I cannot composite with subsurfaces like I can with textures, so using a subsurfaces is limiting there
<pq>
I would stay away from re-drawing UI elements using arbitrary image profiles. It's too high risk to not keep the color match.
<Company>
it's essentially a decision the app needs to make
<Company>
the app may even want to force the image into its colorspace, like if it wants to edit the image
<pq>
right
<Company>
and generally it doesn't matter if the app or the compositor does the compositing
<Company>
because I assume they are equally capable
<pq>
It does matter. The result may be different, and neither may be incorrecet.
<Company>
right, but then the app should always do it
<pq>
just don't switch between compositor-managed and app-managed color for the same image
<pq>
choose which way to play, and then keep it like that as long as the same content is up
<Company>
which kinda means GTK should probably never use the from_icc_profile API
<Company>
and leave that to apps that create subsurface
<pq>
that would make sense to me
<pq>
Anything that GTK draws probably has assumptions about the color space it uses, so makes sense for GTK to own it.
<dottedmag>
pq: If the protocol does not specify alpha blending mode, then how can "use subsurfaces" be reconciled with transparency of elements on top of it?
<dottedmag>
it = content displayed on the subsurface
<pq>
Then a wild profile or another from arbitrary sources cannot make the GTK UI unusable accidentally.
<pq>
dottedmag, by using semi-transparency *very* carefully. I.e. mostly for just shaping.
<pq>
a fade-in/out animation is probably fine too, since it's transient
<pq>
but permanent semi-transparent objects I'd be wary of
<kennylevinsen>
semi-transparency and color correct presentation feel like complete contradictions...
<pq>
heh
<pq>
well, if people will ever agree to commit to an wayland extension that defines the blending behavior...
<pq>
but before anyone jumps to that, I would hope they see the color-management saga into production first, because that's how you find out the opinions
<Company>
so far I don't see many cases where people care about color-correct alpha blending
<Company>
I do see that blending happening by accident though
<Company>
like when there's an animation in an image viewer that switches between 2 images
<Company>
using a crossfade or whatever
<Company>
or somebody overlays a semitransparent right-click menu
<MrCooper>
case in point, the incorrect blending is pretty obvious with light text over dark background, still nobody's bothered to address that in a good two decades
kts has joined #wayland
<Company>
unless it's about text
<Company>
then all blending is wrong
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
glennk has quit [Remote host closed the connection]
glennk has joined #wayland
glennk has quit []
glennk has joined #wayland
tzimmermann has quit [Quit: Leaving]
AJ_Z0 has quit [Read error: Connection reset by peer]
AJ_Z0 has joined #wayland
blottoman has joined #wayland
cmichael has quit [Quit: Leaving]
keir- has quit []
keir has joined #wayland
kts has quit [Quit: Konversation terminated!]
ybogdano has joined #wayland
gspbirel5687 has joined #wayland
gspbirel568 has quit [Ping timeout: 480 seconds]
pochu has quit [Quit: leaving]
iomari891 has quit [Ping timeout: 480 seconds]
Narrat has joined #wayland
kts has joined #wayland
rv1sr has quit []
cvmn has joined #wayland
caveman has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
fmuellner has quit []
fmuellner has joined #wayland
dcz has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
ahartmetz has quit [Remote host closed the connection]
ahartmetz has joined #wayland
kts has quit [Quit: Konversation terminated!]
fmuellner has joined #wayland
dcz has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
ahartmetz has quit [Quit: Konversation terminated!]
rasterman has quit [Quit: Gettin' stinky!]
Narrat has quit []
Company has quit [Quit: Leaving]
gspbirel56873 has joined #wayland
gspbirel5687 has quit [Ping timeout: 480 seconds]
manuels has quit [Quit: Ping timeout (120 seconds)]
manuels has joined #wayland
psykose has joined #wayland
psykose has quit [Remote host closed the connection]
manuels has quit [Quit: Ping timeout (120 seconds)]