ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
glennk has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Ping timeout: 480 seconds]
Lucretia has quit [Ping timeout: 480 seconds]
Lucretia has joined #wayland
Serus has joined #wayland
melnary has joined #wayland
dami__ has joined #wayland
dami_ has quit [Ping timeout: 480 seconds]
dami_ has joined #wayland
dami__ has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
dami_ has quit [Remote host closed the connection]
adamtajti has quit [Remote host closed the connection]
rasterman has joined #wayland
leon-anavi has joined #wayland
tzimmermann has joined #wayland
andymandias has quit [Ping timeout: 480 seconds]
andymandias has joined #wayland
andymandias has quit [Ping timeout: 480 seconds]
andymandias has joined #wayland
andymandias has quit [Ping timeout: 480 seconds]
<jadahl>
pq: how does weston's icc client support deal with parsing client provided icc profiles?
Calandracas_ has quit [Ping timeout: 480 seconds]
garnacho has joined #wayland
sima has joined #wayland
rgallaispou has joined #wayland
<pq>
jadahl, feeding the data to LittleCMS 2 and hoping it doesn't do anything bad.
MrCooper_ has joined #wayland
<pq>
jadahl, I wonder, if browsers do the same, then I would expect some hardening in LittleCMS 2, or someone fuzzing it. OTOH, maybe browsers rely on process isolation, so maybe not...
MrCooper has quit [Ping timeout: 480 seconds]
<jadahl>
pq: sounds scary (and it is what the mutter MR does too), but hard to say if "test parsing" in a sandboxed subprocess mitigates much, since one would have to eventually parse it in the compositor anyawy
<pq>
not necessarily
<pq>
if you feed both ICC profiles into the subprocess, let it compute the color transformation, and return it as a shaper + 3D LUT, I think it would be pretty safe.
<jadahl>
yea, that would be safe, but a bit of an overhead I guess
<jadahl>
depends on how often one need to do that, which I guess isn't very often hopefully
<pq>
the subprocess could maintain a cache of parsed ICC files
<jadahl>
true, that could be done by anything. I don't imagine the ICC files plumbing would add that much, it'd be an fd passed around, more about the context switches doing I/O instead of just math when calculating luts
<pq>
somehow I doubt the context switch is much compared to the calculations from cached profiles
<jadahl>
are they (calculation) generally heavy?
<jadahl>
then maybe a "ICC LUT calculator" helper process is the way to go to avoid parsing untrusted complex data in the compositor
<pq>
I think the heaviness comes from how many LUT elements you have to produce. For computing one element, lcms needs to traverse through a linked list of "stages", each of which contains some elementary operation like a matrix, a lut, or a parametric curve.
<pq>
I don't know if that would be much faster if you had a pre-made buffer of all input tuples to feed in with a single call.
<jadahl>
would be interesting to see numbers, to know whether one would have to offload such a thing to a thread anyway
<pq>
yeah, I've never benchmarked that - have bigger gaps :-D
<jadahl>
hehe
<jadahl>
fair enough
<pq>
also the approach to ICC files and lcms in general is pretty... elaborate in Weston, and I still don't know if it's better or worse than the simple shaper + 3D LUT approach.
<emersion>
pq: is it simple to extract a shaper + 3D LUT from lcms?
<emersion>
shaper is 3x1D LUT right?
<pq>
It is simple to use LCMS to compute color values. Coming up with the shaper + 3D LUT takes some additional code, but LittleCMS helps with that, too.
<pq>
Let me see where Leandro's MR about that was...
<emersion>
right i already have the simple 3D LUT working
<emersion>
but grabbing a shaper in front seems tricky
<pq>
ah, it's not even a MR yet, just a draft patch
rgallaispou has quit [Read error: Connection reset by peer]
<pq>
I believe it's also important that shaper + inverse shaper = exactly identity, so rather than compute an inverse shaper LUT, I would reverse-evaluate the shaper instead.
<emersion>
i see
<pq>
The reverse evaluation is probably a binary search.
<pq>
maybe there are more efficient algorithms, but a binary search is simple to understand.
mvlad has joined #wayland
Calandracas has joined #wayland
dami__ has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
dami_ has quit [Read error: Connection reset by peer]
dami_ has joined #wayland
dami_ has quit [Remote host closed the connection]
dami__ has quit [Read error: Connection reset by peer]
kts has joined #wayland
kts has quit []
kts has joined #wayland
yang2 has quit [Quit: Connection closed for inactivity]
feaneron has joined #wayland
kts has quit [Quit: Leaving]
Moprius has joined #wayland
Brainium has joined #wayland
Moprius has quit [Quit: bye]
fmuellner has joined #wayland
Lucretia has quit [Ping timeout: 480 seconds]
<leandrohrb56>
IIUC when playing with the shaper + 3DLUT on Weston, we were able to reduce the 3DLUT dimensions without loosing precision (on the test suite)
<leandrohrb56>
but it couldn't improve the precision
<leandrohrb56>
maybe on real world cases that would be different
<pq>
IIRC I had some reservations about those tests being fairly simple.
<leandrohrb56>
yes
<pq>
being able to reduce 3D LUT size is the point, it proves there are benefits to be had
kts has joined #wayland
<leandrohrb56>
nice, I'll work on this draft of shaper + 3DLUT and put in a MR
<leandrohrb56>
at the moment the code quality on this is horrible
<DemiMarie>
What is the advantage of giving Weston an ICC profile? Being able to offload to 3D LUTs?
<DemiMarie>
<pq> "being able to reduce 3D LUT size..." <- Why does one want a smaller LUT?
<pq>
DemiMarie, ICC profiles are the (printing) industry standard. They are used to describe displays as well, especially when profiled (measured) to produce predictable light.
<pq>
A Wayland compositor does not necessarily need to handle ICC profiles, but when it does, applications have it easier showing images with embedded ICC profiles.
<DemiMarie>
Is this because the application does not need to do the conversion itself?
<pq>
yes
<pq>
professional apps will still choose to do the conversion themselves, in order to control it in full detail, but doing so they can only target one monitor per window at a time.
<DemiMarie>
Ah
<pq>
for all other compositor outputs the compositor still needs to do an (additional) conversion
<DemiMarie>
Is this because compositors will not do as good a job as a professional app will?
<JEEB>
more like these apps and their users are more used to having the app have full control, so you just let them have it
<pq>
more like there are opnions and tastes of how things should be done
<JEEB>
:D
<pq>
yes, developers of those apps often believe that no-one else can get it Right(tm). :-)
<pq>
even if there was an objective definition of "right", which in many cases does not exist
<pq>
...other compositor outputs could be e.g. RDP remote viewer or screencasting
<pq>
and screenshots, of course
<feaneron>
it's all about the attitude and confidence :)
<pq>
DemiMarie, smaller LUT would be less data, which is somewhat valuable in itself, but the major value is not having to explode the LUT size for more complicated transformations.
<DemiMarie>
pq: at what point does one give up and just use shaders?
<zamundaaa[m]>
Demi: this is about shaders
<pq>
DemiMarie, this *is* for shaders.
<DemiMarie>
I thought shaders did not use LUTs and used code instead.
<zamundaaa[m]>
ICC profiles contain LUTs
<pq>
ICC spec is too complicated (too many different elements and possible combinations) to implement in shaders as-is, so why bother when you can get reasonable precision with a comparably very simple code.
<DemiMarie>
Ah
<DemiMarie>
Thanks for explaining!
<pq>
that doesn't stop me from trying in Weston though :-P
<pq>
but in Weston, we choose to handle just few element types in limited combinations, and when that's not enough, Weston falls back to a 3D LUT.
<pq>
the fundamental problem with a plain 3D LUT is that you need N³ table elements.
<pq>
So if you need 1000 elements in one dimension in order to model a curve with sufficient precision, you'd need 1G elements in a 3D LUT
Brainium has quit [Ping timeout: 480 seconds]
<pq>
if an element is 4 bytes which is practically the minimum viable...
<pq>
so, smaller LUTs are better in that they don't run out of memory
azerov has joined #wayland
<kennylevinsen>
And if you’re unlucky enough to need one on both the input and output side of an output’s intermediate blending buffer… and might be using F16 for precision…
paulk-bis has quit [Ping timeout: 480 seconds]
paulk has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
Brainium has joined #wayland
Brainium has quit [Ping timeout: 480 seconds]
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
<DemiMarie>
pq: why is it too complex to implement in a shader? That seems like a job for a ICC → SPIR-V compiler, if that would be a reasonable option.
paulk has quit [Quit: WeeChat 3.0]
fmuellner_ has joined #wayland
<pq>
if yo want to write such a compiler, go ahead
<pq>
if one wants to write such a compiler, they can go ahead :-)
paulk has joined #wayland
Fxzxmic has joined #wayland
<pq>
That might even be nice, but it's also much more work than a shaper + 3D LUT
<Fxzxmic>
Does wayland not allow an application to capture all keyboard input?
fmuellner has quit [Ping timeout: 480 seconds]
<pq>
Fxzxmic, correct.
<Fxzxmic>
But capturing all input from the keyboard is important for a remote desktop client.
<pq>
There are interfaces for that. Just not a Wayland interface free-for-all-apps.
<feaneron>
the Remote Desktop portal provides this functionaly on wayland
<feaneron>
it's not a wayland protocol or project though
<kennylevinsen>
Fxzxmic: why do think that is important? a remote desktop client only needs to receive input when focused, and there's a protocol for capturing focus (when granted)
<kennylevinsen>
(the portal that feaneron mentions is for making servers)
<Fxzxmic>
*there's a protocol for capturing focus* <- That's what I didn't know.
<feaneron>
maybe i didn't understand what you were looking after then
<kennylevinsen>
you're not allow to steal focus you didn't already have, but it lets you implement the usual "pointer capture" feature of these clients so that the user doesn't accidentally leave a window while trying to trigger something at the edge of a remote screen
MrCooper_ is now known as MrCooper
kts has quit [Ping timeout: 480 seconds]
<MrCooper>
it sounded like they just want a keyboard grab, I know that exists but don't remember offhand which protocol has it
<Fxzxmic>
What I'm looking for is the ability to send all events from the keyboard to the remote server when the user is focused on a remote desktop window.
Calandracas has quit [Remote host closed the connection]
Calandracas has joined #wayland
<bwidawsk>
Is there any protocol which would allow mirror mode to work in such a way that the client can be made aware of different refresh rates of the displays it is being presented on?
iomari891 has joined #wayland
andymandias has joined #wayland
<any1>
The client can know when it is presented, but it does not know anything about the hardware
linkmauve has left #wayland [Error from remote client]
<Ermine>
well, if he wants to work on x11, why not?
<kennylevinsen>
if someone desperately wants to maintain it, I’m certainly not going to stopping them by warning them :P
<kennylevinsen>
but saying they’re “doing most of the work” is maybe a bit grand
<dviola>
yeah I just think it's funny, the way they respond
<llyyr>
they got themselves banned from the lkml for being a troll too
<Ermine>
it would be nice to highlight "doing most of the work" in the quote. I've interpreted the message in another way (but it can be a bug in my interpreter :))
<dviola>
llyyr: yes, I've seen that, with all the antivaxx stuff, etc
iomari891 has quit [Ping timeout: 480 seconds]
<dviola>
have they done any substantial work on X at all, or it's been mostly trivial fixes?
<Ermine>
from what got merged, it seems like trivial fixes
<Ermine>
(I've updated the xorg for $distro two months ago, so I had a chance to look at commit histories)
karl5fox has joined #wayland
<karl5fox>
hi guys, could someone tell me how I can satisfy this requirement for using drm as a backend? "fatal: drm backend should be run using weston-launch binary, or your system should provide the logind D-Bus API"
<dviola>
Ermine: I see
<karl5fox>
I'm trying to use drm instead of the rdp-backend
<Ermine>
karl5fox: have you tried weston-launch binary?
<karl5fox>
I think I tried before with an unexpected respponse, but I will retry now to confirm :)
<karl5fox>
looks like the syntax is completely different and has to be run from a virtual terminal :/
<kennylevinsen>
karl5fox: with newer Weston you just start seatd as a daemon as root before launching Weston, or use seatd-launch -- weston (with seatd-launch having SUID)
<kennylevinsen>
For older Weston yeah you need weston-launch to be SUID and run that if you don’t have (e)logind installed and running (the default on systemd distros)