ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Company has quit [Quit: Leaving]
mclasen has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
ghishadow has quit [Remote host closed the connection]
nerdopolis has joined #wayland
ahartmetz has quit [Quit: Konversation terminated!]
nerdopolis has quit [Remote host closed the connection]
ShapeShifter499 has quit [Read error: Connection reset by peer]
ShapeShifter499 has joined #wayland
ShapeShifter499 has quit []
mclasen has quit [Ping timeout: 480 seconds]
crazybyte has quit [Read error: Connection reset by peer]
crazybyte has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
mxz_ has joined #wayland
ukiran1 has quit [Remote host closed the connection]
mxz has quit [Ping timeout: 480 seconds]
mxz__ has quit [Ping timeout: 480 seconds]
mxz_ is now known as mxz
mclasen has joined #wayland
atticf has joined #wayland
glennk has joined #wayland
julio7359 has quit [Ping timeout: 480 seconds]
agd5f_ has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
mxz_ has joined #wayland
julio7359 has joined #wayland
Sid127 is now known as tiredchiku
mclasen has quit [Ping timeout: 480 seconds]
julio7359 has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
sima has joined #wayland
kts has joined #wayland
kts has quit []
privacy has quit [Quit: Leaving]
kts has joined #wayland
rasterman has joined #wayland
kts has quit [Quit: Konversation terminated!]
karolherbst has quit [Quit: Konversation terminated!]
kts has joined #wayland
mvlad has joined #wayland
carbonfiber has joined #wayland
guru__ has quit [Remote host closed the connection]
leon-anavi has joined #wayland
guru__ has joined #wayland
<MrCooper>
could be just one of those Phoronix mysteries, e.g. why is there no hit with CS2 at 1080p (gnome-shell even took the overall win there)
kts_ has joined #wayland
<davidre>
I wonder how rigurous their setup is
<davidre>
How do they control what else the machine is doing in the background
garnacho has joined #wayland
<davidre>
Ah I see they take three runs
<davidre>
And even state the standard error but don't show it in the graphs
<davidre>
But I do wonder that in one case everything is N=3 but gnome shell x11 is N=4
<davidre>
IN gravity mark even n=12
kts has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
<MrCooper>
yep, evidence pointing toward something else affecting the test runs
kts_ has quit []
mart has joined #wayland
<dwfreed>
on most of the results on that page, the SE value is so small that trying to reflect that on the graph is basically meaningless
<dwfreed>
but you can see it in the gravitymark 1.82 result for 4k vulkan, on the x11 gnome shell result
kts has joined #wayland
tombl has quit [Remote host closed the connection]
tombl has joined #wayland
<MrCooper>
dwfreed: if it takes 12 runs to reach "reasonable" standard deviation, that still points to some of the runs being affected by some unknown factor
<dwfreed>
heat throttling, maybe
<MrCooper>
for example
<emersion>
MrCooper: I think gbm_bo_map undoes the multi plane tiling no?
<emersion>
it won't work for YUV ofc
<emersion>
iirc minigbm has a thing to map a specific plane
<MrCooper>
don't remember seeing anything like that in Mesa code
<MrCooper>
swick[m] was struggling with this a while ago
<emersion>
it's done on the kernel iirc
<pq>
emersion, I don't mind a wayland release. I haven't even kept an eye on what landed or is pending.
<emersion>
that's the difference with raw mmap() on dmabufs
<emersion>
GBM map is same as Vulkan/GL map
<emersion>
s/the difference/a difference/
Company has joined #wayland
kts has quit [Quit: Konversation terminated!]
<MrCooper>
emersion: the kernel does special handling for gbm_bo_map?
<emersion>
the gbm_bo_map uses a kernel API that maps in a way that undoes the tiling iirc
<vyivel>
aside from kde, are there any other more or less updated transactions_v1 compositor implementations? every other impl linked in the MR is from years ago and presumably doesn't reflect newer clarifications wrt. synchronized subsurfaces
<MrCooper>
emersion: IIRC Mesa internally uses Gallium transfers for gbm_bo_map, which don't necessarily directly map the buffer storage
<MrCooper>
vyivel: the mutter one definitely needs to be mostly redone
hendry has joined #wayland
<vyivel>
right
<vyivel>
i'll be testing against kwin then
<emersion>
MrCooper: means tiling is undone but not in the kernel?
ahartmetz has joined #wayland
<emersion>
i haven't look at how it work i lust admit
<emersion>
looked*
<emersion>
must*
<emersion>
phone keyboards :(
<kennylevinsen>
lust is a bit strong of an emotion here
<MrCooper>
haha
<MrCooper>
the memory returned by gbm_bo_map is always linear, AFAIK it doesn't handle multiple planes though
fmuellner has joined #wayland
<emersion>
right, that's my understanding as well
<emersion>
well
<emersion>
you mean not even the tiling kind of planes?
<emersion>
my understanding is that it handles say Intel CCS, but not YUV
<zzag>
vyivel: just one thing, I have not actually tested it with a real client yet. my original plan was to test it with gtk later.. but I _think_ that the MR should work
<emersion>
vyivel: there was a wl meeting yesterday and more sub-surface related comments are likely to come in
<vyivel>
zzag: i have some test clients
heftig has quit [Quit: Bridge terminating on SIGTERM]
Nico1 has quit []
gnustomp[m] has quit []
YaLTeR[m] has quit []
doraskayo has quit []
RobertAyrapetyan[m] has quit [Quit: Bridge terminating on SIGTERM]
cmeissl[m] has quit [Quit: Bridge terminating on SIGTERM]
ongy[m] has quit [Quit: Bridge terminating on SIGTERM]
go4godvin has quit [Quit: Bridge terminating on SIGTERM]
zamundaaa[m] has quit [Quit: Bridge terminating on SIGTERM]
teaper[m] has quit [Quit: Bridge terminating on SIGTERM]
Diamonditshe[m] has quit [Quit: Bridge terminating on SIGTERM]
vulpes2[m] has quit [Quit: Bridge terminating on SIGTERM]
ahmadraniri[m] has quit [Quit: Bridge terminating on SIGTERM]
drakulix[m] has quit [Quit: Bridge terminating on SIGTERM]
vchernin[m] has quit [Quit: Bridge terminating on SIGTERM]
arichardson[m] has quit [Quit: Bridge terminating on SIGTERM]
emilio[m] has quit [Quit: Bridge terminating on SIGTERM]
modelockedcat has quit [Quit: Bridge terminating on SIGTERM]
nielsdg has quit [Quit: Bridge terminating on SIGTERM]
luks2[m] has quit [Quit: Bridge terminating on SIGTERM]
Russ[m] has quit [Quit: Bridge terminating on SIGTERM]
ttancos[m] has quit [Quit: Bridge terminating on SIGTERM]
rails[m] has quit [Quit: Bridge terminating on SIGTERM]
botiapa[m] has quit [Quit: Bridge terminating on SIGTERM]
windowsxp[m] has quit [Quit: Bridge terminating on SIGTERM]
Eighth_Doctor has quit []
basemale has quit [Quit: Bridge terminating on SIGTERM]
furyishere[m] has quit []
<zzag>
nice
shawn[m]1 has quit [Quit: Bridge terminating on SIGTERM]
mrkzboo[m] has quit [Quit: Bridge terminating on SIGTERM]
zaibon[m] has quit [Quit: Bridge terminating on SIGTERM]
Nova[m] has quit [Quit: Bridge terminating on SIGTERM]
Coelacanthus[envsnet][m] has quit [Quit: Bridge terminating on SIGTERM]
hex[m]1 has quit [Quit: Bridge terminating on SIGTERM]
orowith2os[m] has quit []
robertmader[m] has quit []
q234rty[m][m] has quit [Quit: Bridge terminating on SIGTERM]
j-james[m] has quit [Quit: Bridge terminating on SIGTERM]
yshui` has quit [Quit: Bridge terminating on SIGTERM]
Max1 has quit [Quit: Bridge terminating on SIGTERM]
mboudr35[m] has quit [Quit: Bridge terminating on SIGTERM]
d_ed[m] has quit [Quit: Bridge terminating on SIGTERM]
Coelacanthus[m]1 has quit []
[old]freshgumbubbles[m] has quit [Quit: Bridge terminating on SIGTERM]
apol[m] has quit [Quit: Bridge terminating on SIGTERM]
japchae[m] has quit [Quit: Bridge terminating on SIGTERM]
varlad[m] has quit [Quit: Bridge terminating on SIGTERM]
davidre has quit [Remote host closed the connection]
nep_nep has quit [Write error: connection closed]
krathul[m] has quit [Remote host closed the connection]
danburd[m] has quit [Remote host closed the connection]
daissi has quit [Remote host closed the connection]
YHNdnzj[moz] has quit [Remote host closed the connection]
cousinofthor[m] has quit [Remote host closed the connection]
joantolo[m] has quit [Write error: connection closed]
colinmarc has quit [Remote host closed the connection]
rajveermalviya[m] has quit [Remote host closed the connection]
KingoftheElves[m] has quit [Remote host closed the connection]
anonymousanomoly[m] has quit [Remote host closed the connection]
elinor has quit [Remote host closed the connection]
JakeSays has joined #wayland
<MrCooper>
emersion: ah, you mean it may use the metadata in a separate plane to handle tiling? What I mean is it can't be used for accessing the contents of additional planes
<emersion>
i mean that an XRGB8888 buffer may have 2 or 3 planes on Intel/AMD due to modifiers
<emersion>
and that gbm_bo_map() takes care of that
<emersion>
but yeah, different story for YUV formats
JakeSays1 has quit [Ping timeout: 480 seconds]
<emersion>
or 3-plane R/G/B
<emersion>
hm
<pq>
given that YUV formats are the only pixel formats that can have multiple planes that apps might want to access, multiplane support is kinda the same thing as YUV support
<emersion>
was thinking of 2-plane RGB_A, not 3-plane R/G/B
<emersion>
yeah
wildwestrom[m] has quit [Ping timeout: 480 seconds]
MartinsWorld[m] has quit [Ping timeout: 480 seconds]
hariselldon[m] has quit [Ping timeout: 480 seconds]
kts has joined #wayland
mart has quit [Read error: Connection reset by peer]
mart has joined #wayland
<Consolatis>
I do have to say that I find it very concerning to host spec bodies like wayland-protocols on a platform that more or less randomly bans people (and by extent projects) based on something that happened outside of that platform.
<Consolatis>
I would very much like to read an official statement of FDO regarding the ban of the lead dev of hyprland (which also excludes them from stating their opinion in e.g. the wayland-protocols repo).
<kennylevinsen>
Consolatis: #wayland is not the right place to discuss freedesktop code of conduct. Consider #freedesktop, or the CoC email address. Also, please read https://www.freedesktop.org/wiki/CodeOfConduct/ first, "Scope" in particular.
<Consolatis>
kennylevinsen: my main point here is about the wayland-protocols spec body
<MrCooper>
it can't be hosted in a vacuum, there would be rules anywhere
navi has joined #wayland
<emersion>
Consolatis: it seems you have misunderstood the reason for the ban
<kennylevinsen>
I'd suggest understanding the incident a bit better before suggesting our projects are severed from freedesktop. In particlar, the consideration that we have wayland people on the CoC team...
<kennylevinsen>
well, person, but it's a small group and simon *basically* counts as more than one person anyway
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #wayland
<pq>
yeah, I'm amazed how emersion finds the time and energy to do everything he does. :-)
glennk has joined #wayland
YaLTeR[m] has joined #wayland
<YaLTeR[m]>
Is there a client that just destroys some subsurface without any commits or destruction of any other surface? I want to test if my compositor correctly redraws in this case (and other commits or toplevel destroys will cause a redraw on their own)
<pq>
YaLTeR[m], I don't know of a stand-alone client doing that, but weston test suite has some, highly weston specific due to screenshooting.
<vyivel>
not exactly like that, but subsurface_interactive_recreate_without_parent_commit is close, would probably need some roundtrip+sleep to test that specifically
<MrCooper>
doesn't it already just wl_subsurface_destroy and then wait for the toplevel to be closed?
<vyivel>
it also recreates the subsurface and iirc smithay has a problem with that
<MrCooper>
gotcha
<vyivel>
it's all immediate so won't be very useful to test rendering
kts has quit [Ping timeout: 480 seconds]
Dami_Lu has quit []
Dami_Lu has joined #wayland
Brainium has joined #wayland
privacy has joined #wayland
<emersion>
Consolatis: with my CoC team hat on, we'll see if we decided to share a detailed public statement, for now here's our explanation:
<emersion>
After receiving concerns from FDO community members, we sent a warning to vaxry to make it clear what the Code of Conduct rules are on FDO, since they historically have had some incidents in their community.
<emersion>
Unfortunately vaxry didn't acknowledge the warning, reacted by posting a reactionary blog post attacking one of the FDO CoC team members, and stated that they will ignore the FDO CoC team messages.
<emersion>
This is not acceptable behavior, so the CoC team has decided to ban vaxry from FDO.
<emersion>
we'll see if we decide to*
<emersion>
anyways, this is a bit off-topic here, but i understand why people would be confused
kts has joined #wayland
<MrCooper>
thanks for the clarification
<vyivel>
where would that be on-topic btw
<emersion>
that's a good question
<emersion>
i suggested sending an email to the CoC mailing list
<emersion>
but that's not a public list
cmichael has joined #wayland
mclasen has joined #wayland
<emersion>
another issue is that in general we don't want to share all of the details of incidents for privacy, so other people are working with partial information (even if here vaxry decided to publish some of the details)
<emersion>
it's a balancing act
<vyivel>
fair
JakeSays1 has joined #wayland
ghishadow has quit [Remote host closed the connection]
JakeSays has quit [Ping timeout: 480 seconds]
<Consolatis>
just for the record, I've read the mails published by vaxry and while I definitely don't agree to most what has been said there (and how it has been said) I also don't see it as enough of a reason to ban a wayland compositor's lead dev to interact with the wayland-protocols repo. This just leads to even more unnecessary fragmentation.
<ebassi_>
Other people from the hyprland community (such as it is) can collaborate
<ebassi_>
But, once again: this isn't the right place
ebassi_ is now known as ebassi
<emersion>
in general, the CoC team doesn't decide based on the "importance" of people
<emersion>
IOW: a kernel maintainer doesn't have more room for CoC violations than a drive-by contributor
<ebassi>
that would defeat the point of the code of conduct, indeed
<Consolatis>
I agree, but it still raises the question of FDO being the right place for spec bodies like wayland-protocols.
<emersion>
i do agree that the outcome is unfortunate in terms of Wayland collaboration, for sure
kts has quit [Ping timeout: 480 seconds]
<emersion>
i absolutely do want wayland-protocols to be under a CoC
<Consolatis>
even if that CoC expands outside of wayland-protocols?
<pq>
I don't think any spec body can function if the members must not be bound by a CoC like the fd.o's.
<emersion>
the ban is not directly due to past behavior here
<emersion>
and if the FDO CoC doesn't apply the CoC properly, that's a thing to fix in FDO
<emersion>
not a reason to go elsewhere
<ifreund>
I agree, there's no healthy way to do wayland-protocols development without a CoC
<ifreund>
er, the CoC is just a piece of text. There's no healthy way to do it without people behaving kindly and the CoC helps set that standard
<ifreund>
one thing I personally believe is important when dealing with bans is to make them long (at least a year) but temporary at first
davidre has joined #wayland
<ifreund>
Ideally this would give people time to grow up and change their ways, worst case they get permanently banned
<davidre>
Imho if you need to check the CoC whether what you are writing is ok you are on the wrong track. I didnt read the CoC yet but I hope and assume I didnt violate it! :D
<ifreund>
yeah, same sentiment here
<Consolatis>
davidre: that seems to depend on how any external project of yours (e.g. not hosted at fdo) sets its moderation guidelines and how you reply to emails.
<alice>
i've never read any coc either in my life
<davidre>
If people were snesible "dont be an asshole" would be enough
<davidre>
alas
<kennylevinsen>
if you adhere to that you will be in compliance with pretty much all CoCs
<kennylevinsen>
even if you never read them
<ifreund>
I do think it's nice explicitly state that we welcome people regardless of race/gender identity/sexual orientation/religion/etc.
<ifreund>
s/nice/nice to/
<ifreund>
otherwise, yeah the rest might as well be "don't be an asshole"
aaron465 has joined #wayland
<kennylevinsen>
It also makes sense that horrible behavior outside what is strictly defined as "the platform" also leads to exclusion, as most of our interactions are outside. Having others' play with you is a privilege, not a right, and for others' to bother with you you need to treat others with decency and respect...
<kennylevinsen>
although I don't really know a lot about this particular instance
<kennylevinsen>
(you can argue that decency/respect is subjective, but I don't think we're dealing with fine print here)
kts has joined #wayland
<carbonfiber>
fwiw. As an outsider (so you probably don't care). Then I think it is unacceptable that a person gets banned based on something they did on an entirely different platform. You can of course do what you want. But it makes me want to have as little to do with FDO as possible (and it has the same effect on multiple people I know). If you just want to ignore that, then go ahead. But it saddens me if that is the case. Compared to
<carbonfiber>
other CoCs then it is really unique behavior from FDOs CoC, and other CoCs do not work in the same way. That should be something that is weighed deeply in when you are analysing this. Are you really so special as so be the only project that has a CoC that also bans people for stuff on other platforms?
<emersion>
that's not what happened
<Consolatis>
well, it kind of is. The whole thing started only because of the fdo warning due to something that happened outside of the platform.
kts has quit [Read error: Connection reset by peer]
<emersion>
everything would've been fine if they replied with "yeah, i agree with the CoC"
<Consolatis>
its still FDO trying to impose its COC on external projects so I kind of understand the resistance to that behavior. (although personally I would never reply / react in such a way and instead likely simply ignore the mail)
<emersion>
that's not what it is
<privacy>
another power trip in my opinion. Will never willinly use anything related to KDE or mandated acceptance of personally believed immoral behavior. My 2 cents, but agree with Vaxry's rights.
<emersion>
since when is it a right to say that you'll ignore the CoC team? and to attack its members personnally?
<privacy>
your opinion only
<privacy>
don here - exiting channel for a day - don't agree with you - period.
privacy has left #wayland [Leaving]
<kennylevinsen>
someone should set a quota on their use of hyphens
<Company>
Consolatis: no, the coc is for people who participate in fdo - and the ban is only for fdo, no discord ban happened due to fdo
<kennylevinsen>
and the appropriate way to reconsider clauses in the CoC is to raise it in a formal (and respectfully executed) discussion with freedesktop
<Company>
Consolatis: and that's not really the coc, that's "decent behavior"
<ifreund>
honestly, if someone is an intolerant asshole in unrelated public spaces I personally don't want to interact with them as part of an open source project I contribute to
<ifreund>
I imagine this feeling would be much more extreme if I was part of a marginalized group this hypothetical asshole publically harrased elswhere
kts has joined #wayland
<carbonfiber>
So just to be clear. I am genuinely asking because I want to make sure I understand this with complete clarity. Lets say I have a discord channel for my own project (and it is public, but I have never invited any FDO contributors to this channel), and I make a joke about pronouns, or I mention that I like Jordan B. Peterson, or something like that, and I then get an email from a FDO contributor telling me to be sorry about it,
<carbonfiber>
then I am not allowed to tell that person that they should mind their own business? And If I do, I will get banned from FDO?
bindu_ has joined #wayland
bindu has quit [Ping timeout: 480 seconds]
<YaLTeR[m]>
well, you're allowed to say whatever you want, but be prepared for others to decide whether or not they want to keep engaging with you after the fact
<davidre>
privacy how did KDE involved into this
<davidre>
oh they left
<kennylevinsen>
carbonfiber: depends on the joke. Try to substitute it for a racist or antisemmetic comment and it might be easier to understand the issue
<Company>
carbonfiber: the details matter, but I think if any coc enforcement entity contacts you and you tell them to fuck off, you shouldn't be surprised if you get banned
<kennylevinsen>
(heck in that case, you'd also be looking at legal repercussions in some countries where that's flat out illegal)
<carbonfiber>
Company: does that also apply if they contact me by knocking on my door in the middle of the night? because in that case I would definitely tell the person to fuck off, and expect not to be banned over it.
<kennylevinsen>
carbonfiber: at the same time, we are not dealing with immediate, zero-tolerance punishment. If you make a distasteful joke, people will mostly just go "wtf". If you behave like that in general, you'll probably get a warning
<ifreund>
carbonfiber: CoC rules are inherently flexible. It seems like you're looking for something in the spirit of "if the person says X word 10 times that's a warning, 100 is a ban"
<ifreund>
but that's not how moderating a community works
<carbonfiber>
ifreund: No I am not. Not at all.
<ifreund>
you are literally asking "if hypothetical situation with no context happens do I get banned?"
<ifreund>
this is in the same spirit as my absurd 100 words example
<ifreund>
there is no context, so there is no way to say what the correct moderation decision is
<carbonfiber>
I prefer a CoC that doesn't ban people because you tell someone to mind their own business. Even if you are not banned from FDO, individual developers can still choose not to interact with you (based on whatever they want and from any sources they want), that is fine and something completely different.
<Company>
the coc doesn't do anything - this is about people
<ifreund>
the CoC doesn't ban anyone, the community leaders/moderators do based on what they think is best for the community
<carbonfiber>
well substitute CoC for FDO leaders/moderators then.
kts has quit [Ping timeout: 480 seconds]
<ifreund>
again, "FDO leaders/moderators banned someone for being told to mind their own business" completely disregards the larger context
<ifreund>
this discussion is obviously going nowhere, so I'm done here o7
kts has joined #wayland
kts has quit [Remote host closed the connection]
kts has joined #wayland
kts has quit []
mkoncek has joined #wayland
eroc1990 has quit [Read error: Connection reset by peer]
eroc1990 has joined #wayland
qaqland has joined #wayland
feaneron has joined #wayland
kts has joined #wayland
ghishadow has joined #wayland
leon-anavi has quit [Quit: Leaving]
<MrCooper>
Company: in case you haven't seen it, it's doubtful there's a mutter issue behind those Phoronix numbers, e.g. CS2 didn't take any hit at 1080p, and some tests required 12 runs for standard deviation to drop below some threshold
<feaneron>
i'm just looking at the benchs. did phoronix really test a 2-year-old gnome against bleeding edge kde?
<feaneron>
that's a little disappointing (and, practically, unactionable)
<mclasen>
and yet, 90% of the results were "no difference at all"
<mclasen>
like most of the time
* feaneron
doesn't spend more time looking at that
<kennylevinsen>
it means you'll get a free headline article when he finally upgrades :P
<jadahl>
"yay"
<kennylevinsen>
what, phorinix articles isn't part of your KPIs? :O
<jadahl>
only if we write them I guess :P
<kennylevinsen>
I do give him some credit for running a ton of benchmarks that *sometimes* reveal interesting things...
<jadahl>
(blogging etc is encouraged)
<kennylevinsen>
ah, nice
kts has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
<Company>
MrCooper: I hadn't, thx
<Company>
though I'm still curious what's causing it
rasterman has quit [Quit: Gettin' stinky!]
<MrCooper>
mclasen: no difference is expected with fullscreen benchmarks, since they mostly depend on things between the X server and the app, the Wayland compositor shouldn't really affect the results
<mclasen>
right, so he's testing entirely irrelevant things
<MrCooper>
so if there's any significant difference, my first suspicion is something went wrong
<Company>
mclasen: I think what he's testing is that compositors and applications actually work - which is important to test, though expressing it via fps is kinda useless
<Company>
and from the dmabuf stuff, we know how easy it is to make things look like thwy work, but not actually work
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #wayland
kts has joined #wayland
cmichael has quit [Remote host closed the connection]
<Company>
and it's really hard to document, because it depends on the mental model I operate under how I read this
<Company>
"just try it and if it rotates the wrong way, flip the values around"
<mclasen>
there is just so many "upwards" directions to line up: the buffer, the surface, the monitor, all have their own
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
feaneron has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
<emersion>
i think giving an explicit example would help
<emersion>
buffer with arrow pointing up, what happens when i set 90 degree transform?
<emersion>
what happens on an output with a 90 degree rotation?
<mclasen>
I think the real confusion sets in when trying to interpret what to do in response to the output rotation
rasterman has joined #wayland
<emersion>
simple: nothing!
<emersion>
wl_surface.preferred_buffer_transform is the replacement
<emersion>
and doesn't require you to second-guess
<mclasen>
that is better, indeed
<emersion>
but to reply to the question
<emersion>
i think with earlier wl_surface versions, clients are expected to use the same transform as the output on their surface
<emersion>
wl_output has TRANSFORM_90, that's a hint for clients to use the same transform
<Company>
emersion: the explicit example sstill doesn't help, because I need to be sure if that's the transform that is already applied or that will be applied
<emersion>
i think it helps if you pick an example with a fixed wl_surface transform and a fixed wl_output transform?
Brainium has quit [Read error: Connection reset by peer]
<emersion>
describe what's in the buffer and what's on screen
<emersion>
no?
<Company>
dunno, I know how it works and I'm confusing myself constantly