ChanServ changed the topic of #wayland to: | 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> To the extent that it has anything to say about the positioning of outputs, you're looking for and
<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
<JEEB> which thankfully tanked
anarsoul has quit [Quit: ZNC 1.8.2 -]
anarsoul has joined #wayland
kts has quit [Quit: Leaving]
mvlad has joined #wayland
ahmadraniri[m] has quit [Remote host closed the connection]
ahmadraniri[m] has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
devilhorns has joined #wayland
<emersion> pq, would a compositor use the CMM to do steps 2-8 in "one go"?
<emersion> e.g. compile them into a single 3D LUT?
<emersion> or is that not possible?
<pq> it could, yes
<pq> it's what Weston is aiming for, in case the pipeline does not fit the renderer otherwise
Company has joined #wayland
fmuellner has joined #wayland
ahmadraniri[m] has quit [Remote host closed the connection]
ahmadraniri[m] has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
anarsoul|2 has joined #wayland
anarsoul has quit [Remote host closed the connection]
nerdopolis has joined #wayland
adia has quit [Quit: The Lounge -]
adia has joined #wayland
adia has quit []
adia has joined #wayland
<wlb> weston/main: Derek Foreman * libweston: Split notify_pointer focus into notify/clear compositor/screen-share.c libweston/backend-wayland/wayland.c libweston/backend-x11/x11.c libweston/backend.h libweston/input.c
<wlb> weston Merge request !1038 merged \o/ (libweston: Split notify_pointer focus into notify/clear
jmdaemon has quit [Ping timeout: 480 seconds]
<wlb> weston Merge request !1039 opened by Alexandros Frantzis (afrantzis) kiosk-shell: Respect xdg surface relationships when activating surfaces.
Leopold has joined #wayland
d_ed has joined #wayland
wolfshappen has joined #wayland
Bran[m] has joined #wayland
Leopold has quit []
DemiMarie has joined #wayland
ambasta[m] has joined #wayland
ammen99[m] has joined #wayland
AndrewAylett[m] has joined #wayland
anomalous_creator[m] has joined #wayland
apol[m] has joined #wayland
arichardson[m] has joined #wayland
bdaase[m] has joined #wayland
BilalElmoussaoui[m] has joined #wayland
bluepqnuin has joined #wayland
botiapa[m] has joined #wayland
Naruto[m] has joined #wayland
cb5r[m] has joined #wayland
RAOF has joined #wayland
cmeissl[m] has joined #wayland
cousinofthor[m] has joined #wayland
d_ed[m] has joined #wayland
danburd[m] has joined #wayland
davidre has joined #wayland
Nico has joined #wayland
deknos82[m] has joined #wayland
DemiMarieObenour[m] has joined #wayland
diamondburned[m] has joined #wayland
DrNick1 has joined #wayland
doras has joined #wayland
drakulix[m] has joined #wayland
edrex[m] has joined #wayland
ehfd[m] has joined #wayland
emilio[m] has joined #wayland
FbioPacheco[m] has joined #wayland
GeorgesStavracasfeaneron[m] has joined #wayland
FellFromTheSky[m] has joined #wayland
Joanna[m] has joined #wayland
[old]freshgumbubbles[m] has joined #wayland
frytaped[m] has joined #wayland
furyishere[m] has joined #wayland
gnustomp[m] has joined #wayland
Guest4044 has joined #wayland
GrahamPerrin[m] has joined #wayland
halfline[m] has joined #wayland
hariselldon[m] has joined #wayland
hasebastian[m] has joined #wayland
hch12907 has joined #wayland
Florian[m]1 has joined #wayland
heftig has joined #wayland
Guest4057 has joined #wayland
hex[m]1 has joined #wayland
i509VCB has joined #wayland
inkbottle[m] has joined #wayland
j-james[m] has joined #wayland
japchae[m] has joined #wayland
jasyuiop[m] has joined #wayland
Kelseyjgilbert[m] has joined #wayland
jmariondev[m] has joined #wayland
junglerobba[m] has joined #wayland
JosExpsito[m] has joined #wayland
jryans has joined #wayland
Levans has joined #wayland
marcusbritanicus[m] has joined #wayland
DemiMarie is now known as Guest4064
Max[m]123 has joined #wayland
Mershl[m] has joined #wayland
Max[m]1234 has joined #wayland
nazarewk[m] has joined #wayland
niecoinny[m] has joined #wayland
nielsdg has joined #wayland
ongy[m] has joined #wayland
teh1[m] has joined #wayland
ozwald1[m] has joined #wayland
pac85[m] has joined #wayland
pitsch[m] has joined #wayland
Poly[m] has joined #wayland
psydroid[m] has joined #wayland
q234rty[envs][m] has joined #wayland
q234rty[m][m] has joined #wayland
qaq[m] has joined #wayland
rails[m] has joined #wayland
robertmader[m] has joined #wayland
RomanGilg[m] has joined #wayland
rubo_[m] has joined #wayland
Ryhon[m] has joined #wayland
smasher_tati[m] has joined #wayland
Sumera[m] has joined #wayland
Shimmy[m] has joined #wayland
underpantsgnome[m] has joined #wayland
tleydxdy has joined #wayland
toggleton[m] has joined #wayland
ttancos[m] has joined #wayland
tzx[m] has joined #wayland
ki[m] has joined #wayland
ujineli[m] has joined #wayland
unix-supremacist[m] has joined #wayland
varlad[m] has joined #wayland
vchernin[m] has joined #wayland
MatrixTravelerbot[m]1 has joined #wayland
windowsxp[m] has joined #wayland
xerpi[m] has joined #wayland
YaLTeR[m] has joined #wayland
yshui` has joined #wayland
zaibon[m] has joined #wayland
zamundaaa[m] has joined #wayland
kts has joined #wayland
tzimmermann has quit [Quit: Leaving]
jgrulich has quit [Ping timeout: 480 seconds]
flibitijibibo has joined #wayland
<wlb> weston Merge request !1040 opened by Derek Foreman (derekf) helpers: Add a u64 from 2 u32 helper [Core compositor]
kts has quit [Quit: Leaving]
wvanhauwaert has joined #wayland
pochu has joined #wayland
rv1sr has quit []
ybogdano has joined #wayland
<wlb> weston Merge request !1041 opened by Derek Foreman (derekf) fullscreen-shell: refactor configure_presented_surface [Fullscreen-shell]
rv1sr has joined #wayland
devilhorns has quit []
zebrag has joined #wayland
columbarius has quit [Quit: columbarius]
DrNick1 is now known as DrNick
d_ed has quit [Ping timeout: 480 seconds]
manuel_ has joined #wayland
anarsoul|2 has quit [Read error: Connection reset by peer]
anarsoul has joined #wayland
rv1sr has quit []
manuel_ has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
fmuellner has joined #wayland
ybogdano has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
andyrtr has quit [Quit: ZNC 1.8.2 -]
<wlb> weston Merge request !1042 opened by Derek Foreman (derekf) Draft: libweston: Split up touch handlers [Input]
andyrtr has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
manuel_ has joined #wayland
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.
<i509VCB> Gtk seems a little hesitant on multi seat for input as well, but I think this is more clipboard related:
<emersion> a client coule also ignore all input
<bl4ckb0ne> i509VCB: i have a draft for an xr input protocol
Nova[m] has joined #wayland
<bl4ckb0ne> otherwise xdg clients get touch/pointer emulated from the controller/and tracking, all in the same seat
<i509VCB> Well even with an XR protocol, (Nova who just joined, give them a moment to register with NickServ) you'd still have xdg clients
<i509VCB> And most xdg clients probably won't implement an XR protocol?
<i509VCB> Nova irc can't hear you unless you registered with NickServ
<Nova[m]> I should be now
<bl4ckb0ne> depends on the client
dcz_ has quit [Ping timeout: 480 seconds]
<Nova[m]> i509VCB: yea xr-shell isn't made for this either
<bl4ckb0ne> you can make an xdg client that implements xr input
<i509VCB> You'd still have the problem of two hands using two windows from the same client trying to share pointer focus though?
<Nova[m]> can you read my messages bl4ckb0ne:l
<bl4ckb0ne> thats why i emulate pointer and touch
<bl4ckb0ne> i can Nova[m]
<Nova[m]> OK cool
<bl4ckb0ne> i do single pointer, as in controller enters pointer mode
<bl4ckb0ne> so you dont have 2 controller pointers
<Nova[m]> yea I emulate pointer and touch too but stardust has no such concept of focus
<i509VCB> (let's not mention winit always providing touch but not always using it)
<Nova[m]> plus even if I did have a single focus system I have new inputs constantly being added and removed
<Nova[m]> it's a stress test of multiseat
<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)
ybogdano has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland