ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
Dami-star has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
Guest4507 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest4844
nerdopolis has quit [Ping timeout: 480 seconds]
gnustomp[m] has quit []
caveman has joined #wayland
cvmn has quit [Remote host closed the connection]
Lightsword has quit [Quit: ZNC]
Lightsword has joined #wayland
sima has joined #wayland
tzimmermann has joined #wayland
<emersion>
> wl_coffee_machine
<emersion>
can't wait to get that in w-p!
<jadahl>
should be xdg_coffee_machine I guess, but why not
<jadahl>
a tea extension to the coffee shell would help?
<jadahl>
a bit calcified tea
carbonfiber has joined #wayland
<emersion>
tea is a subset of coffee now? :/
* emersion
sees his pu-erh make waves as a sign of protest
xhivo97 has joined #wayland
<zzag>
heh, with my tea and coffee drinking habits, I'm actually worried about kidney stones
<zzag>
just in case, citric acid cleans calcium buildup in kettles very well
<jadahl>
emersion: in coffee machines it seems common :(
<xhivo97>
would more water help with that lol, I switched to caffeine tablets because as much as I love coffee my stomach doesn't
<jadahl>
hot water with a teste of calcium from the coffee
<xhivo97>
I don't use kettles anymore after I saw chunks of calcium floating inside
* jadahl
does coffee in the morning, and tea in the afternoon
<xhivo97>
How should I do software rendering for a game in wayland? I need a way to tell the compositor to render when the buffer is ready? How to do that without added frames in latency? I want the game to have a target FPS and try to run at that and update as fast as it can to the compositor
rv1sr has joined #wayland
<jadahl>
I was at a "tea maker" once where one could wipe the outside of the tea fermentation machine thing with your finger to get a caffeeine directly from the source
<emersion>
ahah
<jadahl>
the more fermentation, the more caffeine stuck to the metallic fermentation .. oven thing?
<jadahl>
xhivo97: allocate an shm buffer, write pixels to it, attach and commit to a surface
<xhivo97>
How often should I do that is there a way to sync it? I have an shm buffer I am drawing to it's just the game FPS vs compositor drawing FPS being separate that confuses me as I kind of whant the render loop to run on it's own (probably on same thread for now)
<xhivo97>
I guess my question is, can I commit faster than the cserver can update?
<emersion>
you can, but it's wasteful
<emersion>
this will result in work (drawing frames) which will be unused (superseded by a more recent frame)
<xhivo97>
Wouln't ot potentially improve latency? Esp if I manage to do input handling at higher rates too?
<emersion>
the proper way to improve latency is to try to draw and commit a bit before vsync
<emersion>
but with shm, things are slow anyways
<rosefromthedead>
although i'm not sure game devs have got the memo yet
<emersion>
performance and shm, pick one :P
<jadahl>
we need a "use nearest" scaling extension so shm pixel graphics clients can create 480x320 buffers and scale up with viewporter
<xhivo97>
I am a beginner in all this (def not a game dev, I wish lol) that's why I am starting with shm and not using the GPU this early I want to understand how rendering works, but I think if I think about stuff like latency I'll get sidetracked and not learn what I really neeed to learn probably
<emersion>
jadahl: i think i have a branch with that somewhere…
<emersion>
(KMS has a prop for it)
manuel_ has joined #wayland
<emersion>
xhivo97: this stuff is definitely a more advanced topic
<kennylevinsen>
xhivo97: just clean or descale your kettle if it's that bad lol
<rosefromthedead>
is shm still slow if there's not much damage?
<xhivo97>
Tell that to my dad, he uses it and looks like he'd rather suffer through the pain of another kidney stone than clean it lol
<emersion>
rosefromthedead: games usually don't do damage tracking
<rosefromthedead>
i see people saying if you want any perf at all then avoid it but foot proudly talks about using shm right at the top of the performance page lol
<rosefromthedead>
yeah im thinking about regular apps now
<kennylevinsen>
It's faster with less damage, but it always requires slow pixel copy to a dmabuf
<emersion>
it will never be faster than uploading font glyths to the GPU once at startup and then texturing them
<rosefromthedead>
right, i guess what im really looking for is "do the relevant apis allow you to only copy the damaged part" which it seems like they do?
<kennylevinsen>
Yes
<emersion>
yes, damage tracking does help
<rosefromthedead>
cool
<xhivo97>
Is that copy something that is always there for software rendering or is it specific to wayland?
<kennylevinsen>
always true
<rosefromthedead>
i can put off learning enough gl/vk to render text for a little longer then :P
<emersion>
the copy is always there when shm is used and the computer has a GPU (internal or external)
Company has quit [Quit: Leaving]
<emersion>
yeah, proper font rendering on GPUs… sounds like a real pain for sure
<rosefromthedead>
it's basically just blitting, how hard could it be...
* rosefromthedead
was never seen again
<emersion>
lol
<JEEB>
emersion: yup. reminds me of someone having ideas of implementing something like that for the libass subtitle renderer, but that never went anywhere.
<emersion>
famous last words
<emersion>
oof, .ass gpu rendering
<emersion>
that sounds fun
<xhivo97>
i was curous about font rendering and concluded it's not an excersise I can do at my level it looks really hard. Whoever came up with .ass deserves a medal
<JEEB>
IIRC .ass was come up based on .ssa in a week or so (design during the work week, then hacking on the week-end for implementation)
<kennylevinsen>
fast forward to interchangeably right-to-left, left-to-right, top-to-bottom arabic-chinese-emoji text
<rosefromthedead>
i've learned that even if you defer as much work as possible to libraries, font rendering *still* manages to be a huge pain
<JEEB>
also it left a lot of stuff unspecified which ended up just being referenced to GDI/the initial implementation
<JEEB>
which seems to have been quite a PITA
<JEEB>
esp. when the ye olde reference implementation starts seeming like a bug
<JEEB>
I think jfs tried to define a better-defined multi-profile thing in the 2010s but that didn't go much anywhere
<JEEB>
rosefromthedead: yea, that's my experience as well looking from the side lines
<JEEB>
even with freetype2, harfbuzz, fribidi etc handling things for you
xhivo97 has quit [Remote host closed the connection]
Kerr has joined #wayland
rederick29 has joined #wayland
mvlad has joined #wayland
<emersion>
jadahl: by any chance, any progress on the flatpak stuff? would be nice to be able to release a new w-p
<emersion>
at some point maybe we should just link to the GitLab release page
<emersion>
instead of manually massaging the HTML each release
<jadahl>
what the gitlab release page is missing is the announcement
<vyivel>
how does one massage the html
<jadahl>
link to announcement
<emersion>
hm, true
<jadahl>
vyivel: with the right kind of oil
<emersion>
and GitLab releases are a but finicky: when editing them sometimes they loose the assets
<emersion>
bit*
<jadahl>
that sounds scary
<emersion>
it is :<
luna has joined #wayland
<pq>
kchibisov, what do you mean there are only downsides to doing decorations+app in the same surface? That's the ideal choice. No, you don't need to redraw everything to highlight a decor button, you track damage.
<kchibisov>
I think I'm just used to hw accelerated rendering here.
<kchibisov>
Or there're cases where you pass everything to e.g. skia.
<kchibisov>
But it has nothing to do with how much you draw?
<kchibisov>
you need buffer age.
<pq>
yes, buffer_age is the other part
<pq>
but without swap_buffers_with_damage, the compositor does too much work
<pq>
it all exists if anyone just cares to use it
<kchibisov>
I'm just saying that subsurfaces are way easy to set things up.
<pq>
guess I just disagree
<kchibisov>
I guess, I was just doing subsurfaces for decorations for a long time.
<kchibisov>
The only issue is that compositors tend to break with them.
<pq>
sub-surface seams have a risk of showing
<kchibisov>
But if compositor can at least follow what subsurfaces expect it should be all good, given that you have sync/desync behavior.
<pq>
compositor bugs and bugs, but even without those I wouldn't use sub-surfaces unless parts of the window may benefit performance by being on different buffers.
<pq>
*are bugs
<kchibisov>
I'd assume you're talking about video players.
<pq>
yes, those are a prime example, since the buffer from a hw decoder might be able to shown on KMS, or at least you can avoid one GPU blit per frame.
<kchibisov>
Like ideally you set `sync` on resizes, and then keep them desync.
<pq>
yes, but even if a compositor implementation is fully correct protocol wise, the seams might show.
<pq>
a compositor would need to do an intermediate composition of the window, and that would mostly void any benefits there were from sub-surfaces in the first place.
<kchibisov>
That's true, but realistically you see csd decorations only on a few compositors, and even gtk does subsurfaces (just one though) iirc.
<kchibisov>
Drawing decorations in your main surface could be better for perf in some clients, but it's way less convinient.
<pq>
less convenient being better for perf seems like a universal truth :-)
<kchibisov>
Also, decorations could be transparent, but main surface opaque, so main surface could be directly scanout.
<kchibisov>
And decorations in real world are often has transparent hidden areas.
<pq>
only as dmabuf
<kchibisov>
That what I only do :p
<pq>
btw. KMS does have some support for alpha-blending
<kchibisov>
It does, but not all hardware can.
<pq>
orowith2os, I still haven't read all gitlab backlog; both clients and compositors have the full right to have completely unusable GUI. It is not the protocol spec's purpose to demand that compositors and apps must "usable" - whatever that means. What do exist are app and compositor bugs and issues. All protocol violations are bugs, but not all bugs (or design choices) need to be protocol violations.
<pq>
Wayland leaves much more things undefined than it defines, and that's fine. We still get usable apps and usable compositors, because they want to be usable, not because a spec says so.
<pq>
I've had the same issue with some people about color management. It's hard to explain that things will be fine even if the protocol spec does not lock everyone into a single prescribed design.
<pq>
or that one can still file bugs even if they are not protocol violations
fmuellner has joined #wayland
<pq>
what we do need to make clear is the language that a client and a compositor speak to each other, and what the words there mean, so anything that *is* communicated is understood the same way by everyone.
<pq>
Before Wayland, the mantra was "mechanism, no policy". With Wayland, it's "descriptive, not prescriptive" which is almost the opposite.
kts has quit [Quit: Konversation terminated!]
mvlad has quit [Remote host closed the connection]
nerdopolis has joined #wayland
<WhyNotHugo>
cursor-shape doesn't allow hiding the cursor. Would be handy if wp_cursor_shape_device_v1::set_shape with shape==null hid the cursor.
<kchibisov>
It was discussed, but it's expected that you use the `set_cursor` API.
eroc1990 has quit [Ping timeout: 480 seconds]
Moprius has joined #wayland
eroc1990 has joined #wayland
<MrCooper>
kchibisov: FWIW, AFAICT GTK4 no longer uses sub-surfaces itself
Moprius has quit [Quit: bye]
mvlad has joined #wayland
Company has joined #wayland
leandrohrb5 has joined #wayland
<swick[m]>
if you're having meetings about wayland-protocols and we consider it a standards body you should probably also publish some minutes of the meeting
<swick[m]>
seems a bit opaque what's going on right now
<MrCooper>
I think the "meetings" are GitLab MRs/issues? :)
<drakulix[m]>
@pg agreed. I guess I should just sent out information on the next meeting on the mailing list then.
<drakulix[m]>
Apologies, as emersion pointed out this developed quite organically, I'll certainly try to make the process more open next time.
<jadahl>
being more public next time would be better indeed. the one that happened wal
<jadahl>
last week was more grown out of "put wlroots and kde in a room" that leaked
<drakulix[m]>
emersion: If you have notes from last time would you mind creating an issue for meeting notes and to summarize the last meeting? I'll try to do the same for the upcoming one.
<jadahl>
leaked into others brain, I mean
Moprius has quit [Quit: bye]
<emersion>
drakulix[m]: your email provider is generating DKIM signatures which are incompatible with mailing lists
<emersion>
(ended up in my spam folder)
<emersion>
(specifically, the ML adds a Sender header, and your DKIM signature forbits it)
<drakulix[m]>
emersion: I used my company mail, so I am quite surprised by that.
<drakulix[m]>
Thanks for the heads up though. I am trying to fix this. I guess this means I need to send out the mail again?
<emersion>
i don't think it's necessayr
<swick[m]>
drakulix: thanks!
junaid has joined #wayland
eroc1990 has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
Net147 has quit [Ping timeout: 480 seconds]
kenny has quit [Ping timeout: 480 seconds]
manuel_ has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
pasmer has joined #wayland
eroc1990 has joined #wayland
Net147 has joined #wayland
<Company>
swick[m], emersion: I think this "standards body" thing is not soemthing anyone can declare to be - it's earned when other assign that label to you
<emersion>
nope
<Company>
like, I don't think GTK devs consider any wayland entity to be in any way the arbiter for features GTK should implement
<emersion>
that's not what a standards body is or does
<emersion>
a standard body is a group of people who create standards
<emersion>
Khronos publishes many extensions, and Khronos does not force vendors to implement the extensions
<emersion>
the same goes for W3C, IRCv3, etc etc
<emersion>
IETF
<Company>
w3c works by Google submitting long drafts and Apple just implementing random things for iphones and then they argue in github issues why either approach is suboptimal
<psykose>
sounds worse than w-p !
<Company>
and it's still better than C++!
<Company>
I think in general the wayland appraoch works quite well - like with the hdr / color amanagement stuff now
<Company>
it just breaks down when multiple sides disagree on some fundamentals
<Company>
but I don't think that's something you can change via the process
pasmer has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
kts has joined #wayland
nerdopolis has joined #wayland
<dottedmag>
Clarifying moments like "is w-p a standards body?" in documentation makes certain kinds of bad arguments to disappear, which raises the general level of discussion.
mvlad has quit [Remote host closed the connection]
eroc1990 has quit [Remote host closed the connection]
junaid has joined #wayland
junaid has quit []
junaid has joined #wayland
Narrat has joined #wayland
Brainium has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
fmuellner has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
<orowith2os>
like, I get that it's for creating single-pixel buffers, but why would one want that?
kts has quit [Quit: Konversation terminated!]
<ifreund>
to make surfaces with only a single color cheaper
<ifreund>
(note that it can be used with viewporter as mentioned in the protocol)
<orowith2os>
what would a real-world use case be?
<orowith2os>
a GUI toolkit?
<kennylevinsen>
orowith2os: solid background filling entire surface for example
<kennylevinsen>
Using viewport
<rosefromthedead>
i feel like we're going in circles here :P
<rosefromthedead>
im writing a text editor and if kwin supported single-pixel-buffer then i'd be using them to draw the background, but really im not sure what that gets me other than changing the background colour being quick
<rosefromthedead>
which is gonna happen maybe once a month for a weird user
<psykose>
would it use less idle memory for just having the background painted or nah
<orowith2os>
kennylevinsen oooh, I see it now. I'm going through some protocols I've never understood, reading them to see what I can make sense of
<kennylevinsen>
Otherwise kind of expensive to fill a 4k monitor with black pixels - that's a 32MB buffer to fill. wldash2 (launcher) uses it for just that - then it only has to render the text bits here and there
<rosefromthedead>
oh yeah that's why i did it LOL
<rosefromthedead>
yeah my buffers that actually contain text can be smaller overall than the editor window, so the buffer is an easy way to fill in the whole background
<rosefromthedead>
so it isn't transparent
<emersion>
i use it for a client which gradually dims the screen
<emersion>
also used by swaybg for solid color backgrounds
<emersion>
some clients use it for window decorations
<orowith2os>
huh, this is... interesting. I'd think KDE would have some of the best Wayland support out there based on their recent improvements, but even Mutter is ahead for what looks like generally useful protocols?
<orowith2os>
depending on protocols, ofc
<orowith2os>
okay, never mind, maybe?
<rosefromthedead>
lol
<orowith2os>
so far, it's presentation-time and single-pixel-buffer
<rosefromthedead>
iirc the ones kwin has over mutter are generally the "insecure" ones like wlr-data-control
<rosefromthedead>
ones which bring the missing features that plasma/xorg had
<orowith2os>
seems more like "features" than features
<rosefromthedead>
well, klipper is fluff right until you need it ;)
<orowith2os>
I can see some more dedicated, secure APIs, like a portal, being more useful here?
<orowith2os>
then you don't have random clients trying to be a clipboard manager :)
<emersion>
wayland protocols can be secured
<orowith2os>
(I still don't get the idea behind a "privileged" protocol)
<orowith2os>
it sounds impossible without some form of sandboxing, so you don't have apps saying they're a shell when they're not
<emersion>
yes, just like flatpak
<danieldg>
orowith2os: basically yes, it requires either sandboxing or direct-launching of privileged helpers
<emersion>
and then use security-context to figure out the sandbox for instance
<danieldg>
the latter is mostly xwayland
<orowith2os>
danieldg: oh, so Flatpak can enforce that apps don't try to use the wrong reverse-dns names?
<danieldg>
yep
nerdopolis has quit [Ping timeout: 480 seconds]
<danieldg>
or to do thing that they aren't supposed to do (say, lock the screen)
<danieldg>
*things
<orowith2os>
can Flatpak also allow apps to take control of several names, or is it just the appid they're running inside of?
<orowith2os>
I know they allow it for dbus, at least
<emersion>
flatpak apps have a single appid
<emersion>
afaik
<danieldg>
libreoffice (which has a flatpak) does use multiple appids
<orowith2os>
yeah, that's why you have permissions like --own-name
<rosefromthedead>
if you want a client to be privileged, it has to open its wl connection in a special way right? or is there another way to identify trusted clients?
<orowith2os>
danieldg: their appid on Flathub is org.libreoffice.LibreOffice, let me see what happens when it's installed
<orowith2os>
if that's not set, it looks like the APPID is used, yeah
<orowith2os>
GNOME Builder, both stable and devel, have their appids set according to their package
<orowith2os>
this seems like it could cause issues, especially when it comes to bypassing the sandboxing, but w/e
fmuellner has joined #wayland
<danieldg>
one solution to this is to preface the application-provided app_id with the sandbox-provided ID (so org.libreoffice.LibreOffice.libreoffice-startcenter here), with similar changes to .desktop files so they are tied together
<danieldg>
or, like dbus ownership, just have a list of "allowed" app_id values
Moprius has joined #wayland
rederick29 has quit [Remote host closed the connection]
<jadahl>
orowith2os: iirc gnome-shell uses the flatpak app id for libreoffice as a "prefix" to allow associating e.g. writer vs calc with the right desktop file