ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
xantoz has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
xantoz has joined #wayland
Company has quit [Quit: Leaving]
stillinbeta has joined #wayland
<stillinbeta>
hello all, I'm on a deep dive into how Wayland handles monitor resolution and geometry. what abstractions for monitors does Wayland present? Is there a rectangle with empty spaces like X, or does every monitor get its own distinct framebuffer?
MrCooper_ has joined #wayland
MrCooper has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
<RAOF>
Mu; Wayland (the protocol) doesn't have anything to say about framebuffers.
<RAOF>
(But compositors may not support `xdg_output`, and may construct pleasant lies about anything in `wl_output`)
zebrag has quit [Quit: Konversation terminated!]
rv1sr has joined #wayland
danvet has joined #wayland
jgrulich has joined #wayland
kts has joined #wayland
tzimmermann has joined #wayland
rasterman has joined #wayland
MrCooper_ is now known as MrCooper
kts has quit [Quit: Leaving]
zvarde1988303 has joined #wayland
zvarde198830 has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
dcz_ has joined #wayland
<kennylevinsen>
stillinbeta: generally speaking, clients do not concern themselves with monitors at all. Currently there is a small "but" in the form of knowing the scale of the current output, but proposals to solve this are in progress
flibitijibibo has quit [Ping timeout: 480 seconds]
<pq>
haasn, the choice of language can also preclude a lot of potential contributors up to a point where the bus factor won't grow from 1, which then becomes a liability for potential user projects which might then look elsewhere. I mean Haskell.
<pq>
I'm not equally worried about Rust even though it has some of the same problem.
<pq>
stillinbeta, the answer to that question also depends on whether you looking at a generic desktop app environment, or maybe some special non-desktop environment. Or, maybe a desktop with lego-blocks architecture looking at the "desktop widget" programs, say, a panel or wallpaper.
<pq>
bbl
pq has quit [Quit: I'll be back.]
anomalous_creator[m] has quit []
MatrixTravelerbot[m]1 has quit []
psydroid[m] has quit []
Nico has quit []
ahmadraniri[m] has quit []
frytaped[m] has quit []
jryans has quit []
cmeissl[m] has quit []
underpantsgnome[m] has quit []
ki[m] has quit []
cb5r[m] has quit []
Naruto[m] has quit []
jasyuiop[m] has quit []
ujineli[m] has quit []
frytaped has quit [Quit: Bridge terminating on SIGTERM]
Joanna[m] has quit []
toggleton[m] has quit []
deknos82[m] has quit []
niecoinny[m] has quit []
i509VCB has quit [Quit: Bridge terminating on SIGTERM]
heftig has quit [Quit: Bridge terminating on SIGTERM]
nielsdg has quit []
DemiMarie has quit [Quit: Bridge terminating on SIGTERM]
JosExpsito[m] has quit []
Sumera[m] has quit []
YaLTeR[m] has quit []
RAOF has quit [Quit: Bridge terminating on SIGTERM]
Mershl[m] has quit []
tleydxdy has quit [Quit: Bridge terminating on SIGTERM]
robertmader[m] has quit []
gnustomp[m] has quit []
yshui` has quit [Quit: Bridge terminating on SIGTERM]
zamundaaa[m] has quit [Quit: Bridge terminating on SIGTERM]
ozwald1[m] has quit []
BilalElmoussaoui[m] has quit []
ongy[m] has quit []
Florian[m]1 has quit []
AndrewAylett[m] has quit []
smasher_tati[m] has quit []
drakulix[m] has quit [Quit: Bridge terminating on SIGTERM]
davidre has quit [Quit: Bridge terminating on SIGTERM]
ammen99[m] has quit []
rubo_[m] has quit []
rails[m] has quit []
cousinofthor[m] has quit []
zaibon[m] has quit []
j-james[m] has quit []
pitsch[m] has quit []
q234rty[envs][m] has quit []
arichardson[m] has quit []
diamondburned[m] has quit []
ambasta[m] has quit []
tzx[m] has quit []
[old]freshgumbubbles[m] has quit []
Guest3060 has quit []
botiapa[m] has quit []
ehfd[m] has quit []
vchernin[m] has quit []
japchae[m] has quit []
Levans has quit [Quit: Bridge terminating on SIGTERM]
hex[m]1 has quit []
FbioPacheco[m] has quit []
emilio[m] has quit []
d_ed[m] has quit []
edrex[m] has quit []
Max[m]123 has quit []
junglerobba[m] has quit []
Ryhon[m] has quit []
q234rty[m][m] has quit []
GrahamPerrin[m] has quit []
unix-supremacist[m] has quit []
Shimmy[m] has quit []
bluepenquin has quit [Quit: Bridge terminating on SIGTERM]
Bran[m] has quit []
qaq[m] has quit []
DrNick has quit []
hch12907 has quit []
furyishere[m] has quit []
FellFromTheSky[m] has quit []
hasebastian[m] has quit []
doras has quit []
halfline[m] has quit []
GeorgesStavracasfeaneron[m] has quit []
pac85[m] has quit []
xerpi[m] has quit []
marcusbritanicus[m] has quit []
Guest3052 has quit []
danburd[m] has quit []
apol[m] has quit []
MaxOOO-backon14thOct[m] has quit []
RomanGilg[m] has quit []
inkbottle[m] has quit []
ttancos[m] has quit []
Poly[m] has quit []
windowsxp[m] has quit []
bdaase[m] has quit []
jmariondev[m] has quit []
nazarewk[m] has quit []
Kelseyjgilbert[m] has quit []
varlad[m] has quit []
teh1[m] has quit []
hariselldon[m] has quit []
pq has joined #wayland
ahmadraniri[m] has joined #wayland
fahien has joined #wayland
stillinbeta has quit [Quit: Connection closed for inactivity]
<emersion>
pq, in color-and-hdr#14, i don't understand why step 7 is "undo step 6"?
<emersion>
it seems we apply input EOTF-1 in step 2, then we apply output EOTF in step 6?
<emersion>
and then we decode and encode again in steps 7 and 10?
columbarius has joined #wayland
<pq>
emersion, it's because of the ICC output profile, which might not allow to drop stage 6.
<emersion>
hm
<emersion>
and because we want to blend in output color space
<emersion>
i see
<emersion>
so technical limitations rather than theorical ones
<pq>
yes, and also in light-linear
<emersion>
light-linear?
<pq>
optical space
<pq>
not electrically encoded space
<emersion>
ah, right, linear but optical
<emersion>
s/but/and/
<emersion>
what's the upside of doing this in optical space rather than electrical>
<emersion>
?
<pq>
the same thing
<emersion>
okay
<pq>
physically correct blending, i.e. no hue or brightness distortion
<emersion>
so, blending in electrical is about as "wrong" as blending in non-linear?
<pq>
it's the exact same thing, just different words :-)
<emersion>
i'm confused now
<emersion>
ah
<pq>
we use "non-linear" and "electrically encoded" as synonyms
<emersion>
right, i see now
<pq>
we have been criticized of using "non-linear" because it's non-specific: it could be anything. We've even been criticised of using "linear" because linear is always relationship to something else.
<pq>
but lots of things already use these words
<pq>
so, "electrically encoded" is slightly more precise form of "non-linear"
<emersion>
i have to force myself to not use "gamma" already :P
<pq>
haha
<pq>
yeah
<pq>
amd I totally understand that being fully specific in terminology makes one fully incomprehensible. :-)
<pq>
*and
<emersion>
so, how would one perform the step 7 "linearization", if step 5 and 6 are indivisible?
<emersion>
are 5-6 indivisible but you can still grab enough info to undo or redo 6 alone?
<pq>
e.g. Weston has an algorithm to recover the approximate EOTF from an output ICC profile, given us by Graeme Gill.
<emersion>
hm
<emersion>
what's stored in the ICC exactly?
<pq>
we know that XYZ color space side of the transformation encoded in an ICC profile is linear in light.
<pq>
so we can use that with some practical assumptions to recover a curve that's good enough for blending
<pq>
IIRC, an ICC file that is of Display Class contains one or more color transformations between profile connection space (PCS) and the device space (electrically encoded RGB).
<pq>
There are essentailly two options for PCS: XYZ and CIELAB, was it...
<pq>
one color transformation can be encoded in a number of different ways
fahien has quit []
fahien has joined #wayland
<emersion>
okay, so it's a kind of abstract color pipeline already
<pq>
e.g. 3D LUT, and/or 1D LUT and/or 3x3 matrix and offset vector
<JEEB>
apparently they are going to add official hdr support with some v5 icc profile spec
<pq>
if it happens to be excatly one matrix and per-channel 1D LUTs, then you can actually figure out that the 1D LUT is likely the TF.
<JEEB>
haven't seen any irl yet
<pq>
but in any other case, you can't infer that.
<pq>
So each color transformation encoded in an ICC file is practically a color pipeline of its own between two defined color spaces.
<pq>
why would it have multiple different color transformations and which one do you pick, you might ask
<pq>
one thing is that PCS->device and device->PCS can be given separately, but it doesn't end there
<pq>
"render intents" are basically a way to choose from multiple flavors of color transformations in a single ICC profile. That goes beyond what I want to try to explain in IRC. :-)
<pq>
JEEB, yeah, but I'll just pretend it doesn't exist for real until there is a FOSS CMM that can read such profiles. I forget if v5 was actually iccMAX, or a subset of iccMAX, or evolution of v4, or...
<JEEB>
aye
<JEEB>
i have only seen it in those presentation pdfs
<JEEB>
and yea, ICC is one of those very flexible specs if I understand correctly
<pq>
emersion, so if this sounds like ICC profiles are too flexible for their own good, consider this: the currently used versions are deemed unsuitable for HDR, and the next generation spec iccMAX expands the flexibility by... an insane amount.
<JEEB>
yup
<emersion>
oh well…
<emersion>
thanks for the explanations!
<pq>
so much that they are writing specs about which sub-parts of iccMAX one should use for particular use cases
kts has joined #wayland
<pq>
oldschool color management is built upon ICC files through, and that's why they are important in Wayland too
<JEEB>
hopefully marked as prpfiles somewhere so implementations can.limit themselves similar to certain feature sets
<JEEB>
and yea classic imaging color management somehow ended up with that very freeform thing
<pq>
JEEB, yeah, I think that's a goal.
fahien has quit []
<JEEB>
basically an image containing the transformations to display it so that the output should be the same as what the person editing the image was seeing
<pq>
that's one goal, sure, depending how one defines "what the editor was seeing"
<pq>
usually the goal is to give an acceptable perception, as well as possible, rather than replicating the light emissions (colorimetry) of the mastering display.
<JEEB>
let's just say I'm happy png is adding coding points so I can just flag primaries and transfer as one of the standardized ones
<pq>
:-)
<JEEB>
their first attempt at hdr was by icc profile *names*. the embedded profile would have been an approximation of some sort provided by adobe or whateverr
mvlad has quit [Remote host closed the connection]
manuel_ has quit [Ping timeout: 480 seconds]
d_ed has joined #wayland
<i509VCB>
I've been thinking for protocol-next, would it be useful to have a default app id specified when the connection is created?
<i509VCB>
Obviously not for exposing specific protocols that's insecure
<i509VCB>
But rather for dealing with client bugs
<i509VCB>
Ideally the solution would be to make the protocols much more explicit in what's allowed, but we don't always have that luxury
<emersion>
no to workarounds
<i509VCB>
Asking on behalf of someone working on an XR compositor, what should compositors do about the fuzzy usage for seats and that. Some clients bind the first seat, some bind all and use devices from the first, some bind all and use all devices, some use the last advertised seat. Part of this is that in XR you can have multiple inputs on different surfaces from the same client and this seemed to be the easiest way for working with clients that have no
<i509VCB>
wl_touch support?
<emersion>
report and fix the bugs
wvanhauwaert has quit [Ping timeout: 480 seconds]
<i509VCB>
I guess what I am trying to get across is that there is no real standard to which clients are supposed to deal with seats and their wl_keyboard/pointer/touches. There isn't anything saying clients must bind the devices on every seat or use any more than one seat.
<Nova[m]>
though I still hate the concept of seats entirely
<i509VCB>
bl4ckb0ne: so if you have to fallback to pointer emulation you can't really have two hands using two windows from the same client then without swapping focus between the windows during each event?
<bl4ckb0ne>
yeah
<Nova[m]>
yea, I'm content with 1 seat per surface
<bl4ckb0ne>
its less headache
<i509VCB>
Or do you just give up and have one hand take focus only
<bl4ckb0ne>
havent found a valid use case for multi window focus
<bl4ckb0ne>
plus it helps to not always have the controller as a pointer
<bl4ckb0ne>
its annoying
<Nova[m]>
bl4ckb0ne: yea that's fair
<bl4ckb0ne>
also my valve knuckles have emulated hand tracking, its very useful
<Nova[m]>
that feature made things worse in stardust
<bl4ckb0ne>
most client have touch support, makes it easier
<Nova[m]>
I know, but is it enough to count on?
<bl4ckb0ne>
probably not
<Nova[m]>
so there's no way to fix multiseat?
<bl4ckb0ne>
i havent tried it
<bl4ckb0ne>
id make one seat for each hand
<Nova[m]>
but I could have 1 hand interact with multiple surfaces
<Nova[m]>
stardust literally has no concept of focus on purpose
<bl4ckb0ne>
sounds like headache
<i509VCB>
Even with one seat for hand, some clients ignore this second seat
<Nova[m]>
yea
<Nova[m]>
that's another issue
<Nova[m]>
clients cannot handle any more than 1 seat and I have no idea how to switch input seamlessly
<bl4ckb0ne>
yeah, nothing olbiges the client to do multi seat
<bl4ckb0ne>
either send them a patch or live with it
<Nova[m]>
bl4ckb0ne: the protocol should
<bl4ckb0ne>
why?
<Nova[m]>
that's the whole point of it
<bl4ckb0ne>
i can make a client that doesnt take input
<bl4ckb0ne>
thats the beauty of it
<Nova[m]>
but I'd know about that as the server
<Nova[m]>
since it wouldn't bind to the seats
<Nova[m]>
it'd be defined behavior
<bl4ckb0ne>
its defined
<bl4ckb0ne>
you bind to the seat you know what you get
<Nova[m]>
with multi seat it's supported in the protocol but undefined behavior in clients
<Nova[m]>
which shouldn't ever ever happen in protocols like Wayland
<Nova[m]>
so I'm just not sure what to do
<bl4ckb0ne>
the client handle it how it wants, the server just sends data
<Nova[m]>
but it's broken
<Nova[m]>
it's not able to cope with all the features the protocol exposes
<Nova[m]>
ultimately if the protocol says clients need to handle new seats
<Nova[m]>
they need to or things will break
<bl4ckb0ne>
how come? clients are free to do as they want
<Nova[m]>
as long as they follow the protocol
<i509VCB>
A client that's known to not handle any input is fine, but a client which only functions with one seat when there are multiple is a different thing
<bl4ckb0ne>
its the client's choice
<vyivel>
how are you even going to enforce that
<bl4ckb0ne>
^
<i509VCB>
And even if the protocol did change to force that, old clients still exist
<Nova[m]>
conformance tests like every good protocol has
<bl4ckb0ne>
the protocol just defines what's send to the client and what the client send to the server
<Nova[m]>
openxr for one
<Nova[m]>
bl4ckb0ne: and requirements for they should be handled
<bl4ckb0ne>
wayland is just a bunch of protocols, its not a spec like openxr
pw has left #wayland [Leaving]
<Nova[m]>
ultimately this isn't OK because it's undefined behavior
<Nova[m]>
if clients take shortcuts and end up with state that doesn't match the server's... that's a serious problem
<bl4ckb0ne>
its their problem
<Nova[m]>
but it's my problem
<Nova[m]>
I'm implementing a compositor that follows the spec
<Nova[m]>
and the clients are unable to understand what I'm giving them
<emersion>
clients don't have to support all features the compositor supports
<bl4ckb0ne>
^
<emersion>
e.g. some clients don't support wl_touch
<emersion>
or tablet
<bl4ckb0ne>
thats why thy bind interfaces they need
<Nova[m]>
sure, but they tell the compositor that
<emersion>
but i agree they shouldn't bind to multiple wl_seats if they don't support that
<emersion>
i don't see how a confirmance test for a client would work
<emersion>
conformance*
<Nova[m]>
some parts could
<Nova[m]>
like getting a cursor after a seat is focused I think
<emersion>
how would the test suite know whether the client supports or processes multi-seat events?
<Nova[m]>
that's the thing, according to the protocol they all should
<emersion>
you mean setting the cursor?
<emersion>
the protocol doesn't say anything
<Nova[m]>
from what I read
<emersion>
the protocol doesn't force clients to bind to anything
<emersion>
the globals advertise things clients can use, but clients are not forced to use them, nor use them all
<Nova[m]>
I know...
<Nova[m]>
I'm just not sure how to get this working
<Nova[m]>
I wanted to do 1 seat per surface but looks like that won't happen, guess I'll need to use 1 seat per client and switch inputs like mad
<Nova[m]>
i have zero clue how to do that though
<bl4ckb0ne>
with a few headache pills and a big glass of water
<i509VCB>
Gallons lol
<Nova[m]>
I'm still worried about the axis events when you leave a surface
d_ed has quit [Ping timeout: 480 seconds]
ybogdano has joined #wayland
<daniels>
seats don't create new problems in and of themselves; they simply expose the problems which conceptually exist. you _must_ group devices together (rather than just exposing a pile of keyboard/pointer/touch/hand/eye/etc) because ctrl+click needs to work, so you already have to have something like a seat ...
<daniels>
the easy cut-out is to say that you can make it surface-specific, but are clients really able to deal with that? bear in mind that surfaces can be stacked via subsurfaces, so it comes down to whether or not the client is prepared to deal with two of its surfaces having active focus at once
<daniels>
if they are, great, they can bind multiple seats; if not, then removing seats doesn't solve that issue
<daniels>
going past that, ideally you don't want the arbitrary surface division: why shouldn't you be able to grab one photo from your photo viewer app with your left and one with your right? which again devolves to an app problem of needing to be aware of multiple areas of focus i.e. seats
<daniels>
I agree it would be nice to say that 'every client must be prepared to deal with a completely arbitrary number of interactive focus inputs at any time', but well ... we needed to ship at some point.
<daniels>
(I would not recommend hotplugging seats in the protocol because it's unpleasantly racy)