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
thevar1able has quit [Ping timeout: 480 seconds]
zebrag has quit [Quit: Konversation terminated!]
thevar1able has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
chip_x has quit [Remote host closed the connection]
erodrgz has quit []
fmuellner has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Company has quit [Quit: Leaving]
nerdopolis has quit [Ping timeout: 480 seconds]
<i509VCB>
yshui IRC can't hear you unless you register with NickServ
naveenk2 has joined #wayland
slattann has joined #wayland
yshui` has quit [Quit: Reconnecting]
yshui` has joined #wayland
yshui` has quit []
yshui` has joined #wayland
<yshui`>
is the wayland coordinate system explicitly defined in the spec? I assume it's X to the left, Y down, (0, 0) at upper-left. But I can't seem to find it in the docs.
luyn has joined #wayland
<soreau>
yshui`: a wayland compositor can choose how it wants to define this, but opengl is X to the left, Y up
<i509VCB>
If every vulkan app isn't upside down, then there has to be some sort of convention around
<soreau>
s/left/right/
<soreau>
for vulkan, y is down
<i509VCB>
I recall when I worked on more direct presentation using dmabufs (sidestepping EGL) in Smithay I had to manually flip the rendered output.
<yshui`>
soreau: but if the compositor and clients are using different coordinate systems, wouldn't the clients' buffer be presented flipped? is there a protocol to communicate which system is used?
<yshui`>
or, do the interchange formats (shm, dmabuf, etc.) define their own coordinate systems, and the compositor would transform the buffers based on that?
<soreau>
I don't know there is a protocol for it, the compositor just has to do The Right Thing so everything works out
<RAOF>
The underlying buffer submission implementations handle it, mostly.
<RAOF>
(`wl_drm`, `linux_dmabuf`, etc)
<RAOF>
SHM buffers are implicitly in whatever coordinate system `glTexImage2D` will give the right thing for (I forget which that is 😜)
<yshui`>
ok, that makes sense. shouldn't wayland define how pixels are laid out in a shm buffer?
<RAOF>
Yes
<RAOF>
It's possible that it's documented somewhere, but “the way you'd like it, if you were to naively use GL” is easy enough that maybe most people just guess correctly?
<yshui`>
i see 😅 thanks for explaining! maybe I could open an issue?
slattann has quit [Quit: Leaving.]
<RAOF>
A PR to the protocol XML explicitly adding the coordinate system to the `wl_shm_pool` interface would probably be acceptable!
slattann has joined #wayland
<RAOF>
Or an issue ;)
naveenk2 has quit []
mxz has quit [Quit: cya]
mxz has joined #wayland
soreau has quit [Remote host closed the connection]
soreau has joined #wayland
naveenk2 has joined #wayland
tzimmermann has joined #wayland
tzimmermann_ has joined #wayland
tzimmermann has quit [Read error: Connection reset by peer]
soreau has quit [Remote host closed the connection]
soreau has joined #wayland
soreau has quit [Remote host closed the connection]
soreau has joined #wayland
jgrulich has joined #wayland
adarshgm has joined #wayland
ofourdan has joined #wayland
hardening has joined #wayland
danvet has joined #wayland
<zzag>
vyivel: speaking of kwin, we want it to behave similar to how it's done in wlroots so we can handle serials wrapping around better
<jadahl>
vyivel: the wl_surface can, the xdg_popup cannot
<jadahl>
iirc
rv1sr has joined #wayland
mvlad has joined #wayland
tzimmermann_ has quit []
tzimmermann has joined #wayland
manuel1985 has joined #wayland
rasterman has joined #wayland
pH5 has joined #wayland
fahien has joined #wayland
Lucretia has quit [Ping timeout: 480 seconds]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
MajorBiscuit has joined #wayland
<pq>
yshui`, before you can ask which orientation does as coordinate system have, you need to explain which coordinate system you are talking about. There is no single "the Wayland coordinate system".
<pq>
what APIs like OpenGL or Vulkan define is irrelevant
<pq>
RAOF, no, shm buffers are not in glTexImage2D orientation. shm buffers are on top-left origin (but we likely forgot to document that).
<pq>
RAOF, and the glTexImage2D convention is the opposite of the shm definition.
<RAOF>
pq: Weird, because we very happily feed them to teximage?
<RAOF>
We might accidentally flip them again later, I guess!
<pq>
RAOF, ...and flip with vertex/texture coordinates.
<emersion>
thanks for the feedback jadahl
<jadahl>
emersion: sorry for being slow. also should probably try to get feedback from smcv
<pq>
yshui`, wl_surface "surface-local coordinates" have top-left origin. Each wl_buffer factory has it's own convention for buffer layout. OTOH, when the protocol talks about buffer coordinates, they are top-left origin (transformed from the actual data layout).
adarshgm has quit [Ping timeout: 480 seconds]
<yshui`>
ah, so there are multiple coordinate systems in wayland? surface-local coordinates, buffer coordinates, maybe also input event coordinates? are there more?
<emersion>
pq, i guess my main point wrt that color-representation threads is that nitpicking like this doesn't make sense
<yshui`>
pq, are they all top-left systems?
<emersion>
there are upsides/downsides to each wording, and it doesn't really matter
<yshui`>
i think we better document this. from the responses i got i think people are confused.
<emersion>
ultimately i don't care at all, i just want to avoid getting people in the habit of extreme nitpicking
<kennylevinsen>
yshui`: most positions for a surface is in surface-local coordinate, being top-left. Buffer-local coordinates are also used in some places - the difference is just scaling.
adarshgm has joined #wayland
<kennylevinsen>
yshui`: but wayland does have a *global* coordinate system in the sense that coordinates only exist for a surface (window), and with a minor shm exception, we do not concern ourselves with the rendered content of buffers sent to us and so have no coordinate system covering that.
<yshui`>
we do care about putting the rendered content right way up though. i think this is the wl_buffer factory coordinates pq mentioned.
<pq>
yshui`, input interfaces define the coordinates to the surface-local.
<pq>
emersion, explain it in more words so there is no room for misunderstanding. Being forced to attach metadata to wl_surface that should really be on the wl_buffer is really unfortunate, and it would be good to explain better than just adding/removing one word.
<emersion>
i don't believe explaining this is in the scope of the protocol XML
<pq>
emersion, it's not good to have to choose between documenting semantics vs. protocol, when semantics and protocol disagree due to unfortunate practical reasons.
manuel1985 has quit [Remote host closed the connection]
<emersion>
the request takes a wl_surface, so i don't think there's any room for ambiguity here
<pq>
In that request, no. But it's in a whole different interface.
<emersion>
well, whatever. i'm tired of this pointless discussion
<kennylevinsen>
yshui`: for dmabuf, the buffer layout is gpu, driver, format and modifier dependent and cannot be reasoned about. Defining "top left" in the buffer loses meaning, leaving you with "If your GPU rendered it right side up it should also scanout right side up".
<pq>
emersion, I'm really "glad" to hear you consider my review comments pointless.
<pq>
makes it much easier for me concentrate on my own tasks.
<emersion>
i do consider *some* of your review comments to be too nitpicky, drawing off contributors
<pq>
naturally I cannot tell when my comments are too nitpicky or not - if I could, I wouldn't post nitpicky comments.
<emersion>
that's why i'm trying to bring that to your attention here -- but, this is my own opinion, i might be wrong, others might see it differrently, etc
<pq>
I've been struggling with my time usage for years, and while I've got better in it, this makes it even easier to ignore even more. That actually helps me.
<pq>
I'm an addict, that I know.
<emersion>
i'm not talking about time usage here
<pq>
I do spend huge amounts of time in reviews, which is time not spent in my own tasks.
<emersion>
i'm just saying that if one had infinite time to review a patch, commenting on each and every detail might not be the best approach
<pq>
Making me less likely to discuss reviews is better for my own tasks. Thank you for that.
<emersion>
i suffer from the same issue, and before i comment, i try to question myself, does it really matter
<yshui`>
kennylevinsen: so in that case I guess the compositor should just import the dmabuf and render it out?
<jadahl>
IMO "nitpicks" are not bad, it's about addressing less critical details, which is still good
<emersion>
why are you always coming back to time usage? that's not what i'm talking about at all
<kennylevinsen>
yshui`: exactly :)
<pq>
emersion, because time usage is everything to me. Everything comes back to time usage.
<yshui`>
should i open a issue to add the "top-left coordinate system" language?
<emersion>
jadahl: this can be harmnful too, leaving the patches in an always-nitpicky-comments state
<emersion>
tiring new contributors
<emersion>
new and old, tbh
<pq>
yeah, I agree with that harm, and it has two alternatives:
<emersion>
i think pointing out nitpicks is fine, but if the contributors comes back with "i disagree", it's fine to just drop it
<pq>
- don't nitpick, merge the patch, create your own patch that fixes everything up
<pq>
- reject the patch, write and merge your own doing the same
<emersion>
would you really send a patch to change "surface buffers" to "surface"?
<emersion>
does it really matter that much, to warrant a time slot in your busy schedule?
<pq>
if I couldn't nitpick on the MR, I probably would.
<pq>
it doesn't, but also I'm an addict
<pq>
so it does
<emersion>
okay, i wouldn't have expected this to matter that much in your eyes
<pq>
if I didn't care, I wouldn't have commented
<emersion>
there's a whole range between "i don't care" and "it really matters, i'll NACK the patch if it isn't changed"
<pq>
I've trying to learn to not care for a long time, and I've made progress in that, but I still have ways to go.
<pq>
Just look at all wayland-protocols MRs I've never commented on. Those are my victories.
<emersion>
lol
<emersion>
i mean, we all are addicts to some extent
<emersion>
anyways, food for thought
<pq>
I rarely threaten with a NAK. Nitpicks aren't worth of that.
<emersion>
and sorry for the aggressive start of discussion
<pq>
NAK is different from not accepting
<pq>
yeah... me too
<emersion>
unresolved review comments are difficult to ignore when pushing for merging
<pq>
emersion, you know what also helps me to ignore things? Seeing you active there. I know they are likely in very good hands.
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
WhizzWr has quit [Ping timeout: 480 seconds]
Lucretia has quit [Ping timeout: 480 seconds]
Lucretia has joined #wayland
manuel1985 has quit [Ping timeout: 480 seconds]
fahien has quit []
<pq>
RAOF, actually there is a double-flip with glTexImage2D: OpenGL defines bottom-most row first in data, but also origin at bottom-left corner. So if you feed in data with top row first, and use top-left origin texture coordinates, you do a double-flip giving you want you wanted as texture samples.
<MrCooper>
pq: not sure that description is consistent with FBOs using top-left origin for drawing?
<pq>
MrCooper, yes, that's extra difference when a texture is bound into FBO, IIRC.
<pq>
FBO doesn't use texture coordinates, it uses... winsys coordinates?
<pq>
no, device coordinates?
<pq>
and yes, while the double-flip reverts itself with glTexImage2D, fooling you to believe top-row-first with top-left origin, using an FBO will reveal the truth. :-)
rv1sr has joined #wayland
jgrulich has quit [Ping timeout: 480 seconds]
mlankhorst has quit [Quit: Reconnecting]
mlankhorst has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
chipxxx has quit [Read error: Connection reset by peer]
rv1sr has quit [Remote host closed the connection]
rv1sr has joined #wayland
tzimmermann has quit [Quit: Leaving]
devilhorns has quit []
naveenk2 has quit []
rv1sr has quit []
MajorBiscuit has quit [Ping timeout: 480 seconds]
DemiMarieObenour[m] is now known as DemiMarie
rv1sr has joined #wayland
soreau has quit [Read error: Connection reset by peer]
soreau has joined #wayland
<yshui`>
I think normalized device coordinates are lower-left too? are FBOs really top-left? kinda difficult to remember all these..
<qyliss>
Regarding 'Protocols in the "xdg" and "wp" namespaces must have at least 3 open-source implementations [...] to be eligible for inclusion.', what counts as an implementation?
<qyliss>
Can it be just in a PR to the Wayland implementation? Just a patch, not yet suitable for upstreaming?
<LaserEyess>
I've asked this before, and a qualifying implementation must work, e.g. be at least tested
<qyliss>
Okay, that's not a big hurdle
<LaserEyess>
the point of having implementations is to make sure the protocol even *can* be implemented in the first place, I think
<qyliss>
Great, thanks
<emersion>
the implementations should never be merged before the protocol
<emersion>
but ideally should be patches submitted to the original project
<emersion>
(and ideally have positive feedback from said project's maintainers)
<daniels>
++
<daniels>
the point is to have independent implementations from different codebases with different constraints to make sure it can be implemented across the board rather than being an unrealistic pipe dream
<emersion>
btw, the implementations absolutely do not need to be for w-p members projects
rv1sr has quit [Remote host closed the connection]
<emersion>
they can be for other compositors and clients not listed in MEMBERS.md
<qyliss>
I'd assumed so, but good to have it confirmed
<puck_>
emersion: aha, good; i've got an implementation of security-context-v1 for crosvm, but haven't quite attempted upstreaming it yet
rv1sr has joined #wayland
<emersion>
oh, nice
<emersion>
wlr + flatpak + crosvm would meet the requirements, for instance
<qyliss>
that was what we were hoping
<qyliss>
(and that's why I've been pushing so hard to not assume anything about Flatpak or namespaces in the protocol)
<puck_>
emersion: speaking of; i have some changes for your draft mr on wlroots, since the protocol changed a bit after you wrote them :p
<emersion>
oh, you're this person then!
<puck_>
yup!
<emersion>
cool, i'll pull in your changes in my MRs
<puck_>
awesome
Leopold has joined #wayland
rv1sr has quit []
Moprius has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
Moprius has quit [Quit: bye]
alatiera has joined #wayland
<DemiMarie>
I was a bit surprised on Weston not being suitable for memory constrained environments. I thought most environments using Weston were memory constrained.
mvlad has quit [Remote host closed the connection]
<kennylevinsen>
"Memory constrained" is a relative term
<kennylevinsen>
To some that means "a few megs at most", to others "a few gigs" :)
<bl4ckb0ne>
i wonder if anybody bothered mesuring wlroots memory footprint
plarke has joined #wayland
<kennylevinsen>
I guess one could compare compositors using a dedicated test client or two...
<i509VCB>
Just the compositor arguably isn't a completely fair comparison. Sure you could measure purely the compositor, but it's not representative of actual usage without a dock/bar or background image.
<i509VCB>
Reproducability on hardware also is an issue we need to account for. radv probably uses more ram than v3dv.
<kennylevinsen>
Testing a DE != testing compositors, so I would only be interested in having the same series of test clients on all compositors, no bars.
<kennylevinsen>
Especially if we're looking at what compositor is the most appropriate for some constrained environment that needs no fluff
fmuellner has joined #wayland
<plarke>
Hello, is there a curses-like library for creating wayland clients? I'd like to be able to do something like, new_window(width, height, "My Window); pixel_on(20, 20, my_color); get_key(); close_window();
<plarke>
If not, I'm thinking about writing this.
<bl4ckb0ne>
maybe sdl/glfw with cairo?
<plarke>
Sdl does seem close, good point.
<bl4ckb0ne>
wayland support was abysmal but its getting better
<bl4ckb0ne>
dont forget SDL_VIDEODRIVER=wayland
DonRichie has quit []
ybogdano has joined #wayland
DonRichie has joined #wayland
Narrat has quit []
danvet has quit [Ping timeout: 480 seconds]
zebrag has joined #wayland
hardening has quit [Ping timeout: 480 seconds]
Leopold___ has joined #wayland
Leopold has quit [Ping timeout: 480 seconds]
fmuellner has quit []
fmuellner has joined #wayland
fmuellner has quit []
rasterman has quit [Quit: Gettin' stinky!]
caveman has quit [Remote host closed the connection]