ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<zezba9000>
No errors, KDE reports correctly ZXDG_TOPLEVEL_DECORATION_V1_MODE_SERVER_SIDE is the default etc
<zezba9000>
Am I suppose to grab or pass a surface to anything?
<zezba9000>
Also is there a Discord for Wayland?
aknot has joined #wayland
danieldg has quit [Read error: Connection reset by peer]
vincejv has quit [Ping timeout: 480 seconds]
danieldg has joined #wayland
guru_ has joined #wayland
<danieldg>
when using fractional scaling, am I right that it's best to avoid using set_buffer_scale becuase scale=2 will reject buffer attachments with odd dimensions?
guru__ has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
eroc1990 has joined #wayland
<zezba9000>
Is there a good example of KDE Wayland decorations working?
<zezba9000>
I for the life of me can't get them working
<zezba9000>
Why are all these examples using EGL and not just portable Wayland buffers that don't require a GPU
<zezba9000>
Are KDE decorations not working because it wants the Wayland surface buffer to be OpenGL based?
<danieldg>
that's unlikely
<zezba9000>
If that was true then Vulkan compositors wouldn't work so I would hope not
<danieldg>
pretty sure vulkan can accept dmabuf too
<zezba9000>
I am doing everything these examples are just not using OpenGL
<Consolatis>
zezba9000: zxdg_decoration_manager_v1_get_toplevel_decoration() + zxdg_toplevel_decoration_v1_unset_mode() to use the compositor default or zxdg_toplevel_decoration_v1_set_mode() to set your own preference should be enough
<Consolatis>
you could use the WAYLAND_DEBUG=1 env var to compare the result of eg the wlroots example client to your application
<Consolatis>
maybe there is a commit missing or something along that line
cool110 has joined #wayland
cool110 is now known as Guest191
<zezba9000>
Ok guess I needed to do "wl_surface_commit" in the "decoration_handle_configure" callback
<zezba9000>
That was it
Guest184 has quit [Ping timeout: 480 seconds]
qaqland has quit [Remote host closed the connection]
<zezba9000>
Should you always call "wl_display_flush" after "wl_surface_commit" ?
qaqland has joined #wayland
<Consolatis>
not my area of expertise, I guess that completely depends on your application flow but it shouldn't hurt
<danieldg>
you need to eventually call it
<danieldg>
just like you need to eventually call commit, but it doesn't have to be right after you change decoration settings
tent4051 has joined #wayland
tent405 has quit [Ping timeout: 480 seconds]
guru_ has quit [Ping timeout: 480 seconds]
<zezba9000>
Well this is odd. Setting client decorations on only works when it call zxdg_toplevel_decoration_v1_set_mode in wl_pointer_listener
<zezba9000>
I am having a real hard time being kind to this API. Its the most messy Windowing API Iv'e every used. And I've used pretty much all of them
RAOF has quit [Read error: Connection reset by peer]
<zezba9000>
The fact the examples are only doing this in the mouse button down is odd in and of itself
RAOF has joined #wayland
<danieldg>
zezba9000: if you have a toplevel decoration object, then you can call it anywhere
<danieldg>
I would not call it from a mouse button handler
<danieldg>
the configure handler would be sensible, for example
<zezba9000>
Ok configure seems to work. Ok finally I have everything I need to finalize this I think.
<zezba9000>
Does KDE or Gnome3 have any specific Wayland extensions I could invoke for center window requests on Window creation? I know its not Wayland spec but I'm hoping some extension still exists thats non-standard. Maybe distro specific?
<zezba9000>
Maybe something XWayland exposes I could hook into?
<Consolatis>
regarding xwayland: no. Unless you write a X11 application and not a wayland native one
<Consolatis>
also I'd expect most stacking compositors to center new windows, are gnome and kde doing something else?
<danieldg>
zezba9000: there was some discussion on window type hints for a while, but I think that just turned into the content_type protocol
<danieldg>
the real question is "what causes you to want it centered"
Net147 has quit [Ping timeout: 480 seconds]
<danieldg>
and yes, normal window creation position is generally centered already
fossdd has quit [Ping timeout: 481 seconds]
fossdd has joined #wayland
<zezba9000>
Do you realize how unprofesional a game looks opening up in some rando location?
<danieldg>
no, I don't realize
<zezba9000>
THen you're in a ideological bubble
<danieldg>
mmkay so are you
<zezba9000>
Incorrect
<danieldg>
that's what everyone says
<zezba9000>
Its not your job to tell me how my app should be made
<danieldg>
fullscreen it then
<zezba9000>
LMFAO
<zezba9000>
I ask you nerds how to do something every other OS supports since the 80s because it has use depending on app... and the response is "dur hur... why don't you make it like I want"
<Consolatis>
I see it similar, either be a window and be under the control of the compositor / user (including initial placement) or be fullscreen
<danieldg>
ok, you're trolling now. Bye.
<zezba9000>
k good ridence. Try expanding your perspective outside the Linux echo chamber for once
<Consolatis>
Me as a user wouldn't want to have random apps place themselves randomly just because some app dev decided that this is what works best for them personally
<zezba9000>
This isn't a RANDOM spot...
<zezba9000>
The app IS NOT SETTING ITS POSITION
<zezba9000>
This is a hint like X11 ATOM, WinRT requests, macOS center Window request etc etc etc
<Consolatis>
yes, it is a random spot. My compositor decides on initial placement and me as a user might also configure my compositor to adjust that to my personal preference. It is not any business of random applications.
<zezba9000>
Center is random? lol, what do words mean?
<zezba9000>
Do you know what center Window request does on macOS?
<danieldg>
it makes apple money
<zezba9000>
Its not actually the center of the screen. Its what the compositor things looks pretty to present soemthing to a user thats not actually some rando position like Gnome3 does
<Consolatis>
but that is just how I see it. Good look with your wayland endeavors and I suggest being a bit more professional if you expect others to spend their free time on helping you implement stuff for your "game"
<zezba9000>
"Gnome3 litterlly puts Windows in rando positions... but but centering a Window is "random". Just wow
<danieldg>
zezba9000: this sounds like a good proposal for a protocol, if people think it's important
<zezba9000>
Yes thats all I'm suggesting.
<danieldg>
please cite apple here, not just "obviously" and "clearly I want it BECAUSE CENTERING DUH"
<zezba9000>
Something an app can request BUT a user or compositor can change
<zezba9000>
Centering exists in ALL operating systems With Windows since the 80s. I am NOT making this up
<zezba9000>
There are very valid reasons for this
<zezba9000>
And I don't need to argue every one here
<danieldg>
yet you are?
<danieldg>
has someone made a protocol proposal for this?
<zezba9000>
O wow, sue me for saying a Windowed game looks like its the games fault for opening off in a corner unlike macOS or Windows, ChromeOS, etc
<zezba9000>
Is there a better place to suggest?
<danieldg>
no, I'd call that gnome's fault
<danieldg>
suggest to gnome they fix it, perhaps by adding a protocol
<zezba9000>
I love zero standards don't you?!
<zezba9000>
No I'll suggest a standard please that Gnome can choose to ignore
<danieldg>
that's gnome's problem
<danieldg>
they ignore lots of things
garnacho has quit [Ping timeout: 480 seconds]
<danieldg>
maximize buttons? No, gnome knows you don't want that.
<psykose>
did you know complaining about stuff in an irc chatroom doesn't actually change any of them in reality but only succeeds at making oneself angrier?
radu24284303951534727071489559 has quit [Ping timeout: 480 seconds]
mxz has quit [Ping timeout: 480 seconds]
smop has joined #wayland
sima has joined #wayland
<smop>
I was wondering if there is any such capability in wayland compositors where I can draw on certain regions of the screen.
<Company>
there are not
<smop>
For example, I have a chrome window open, and I want to maybe outline a piece of text or highlight something
<smop>
I see would that be a useful feature or is it probably too much to handle given how wayland handles windows?
tyzef has joined #wayland
<Company>
I'd think you'd have a hard time knowing where all the other windows are in the first place
<Company>
it sounds like something that would probably be easier to implement as a compositor plugin/extension
<smop>
Hmm, I'd imagine different compositors handle window location differentl. Does you happen to know if having "widgets" that live on top of the real window, is something that any wayland compositor is doing at all?
Leopold_ has quit [Remote host closed the connection]
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #wayland
Leopold has joined #wayland
junaid has quit [Remote host closed the connection]
zezba9000 was banned on #wayland by daniels [*!*@c-73-109-166-201.hsd1.wa.comcast.net]
zezba9000 was kicked from #wayland by daniels [bye]
flom84 has joined #wayland
flom84 has quit []
agd5f has joined #wayland
tyzef has joined #wayland
<MrCooper>
soreau: GTK doesn't use SSD
zezba9000 has joined #wayland
agd5f_ has quit [Ping timeout: 480 seconds]
<zezba9000>
daniels: FK you, ya low IQ dumb shit. Keep rattling around in your echo chamber. (boo hoo, something disagrees with me)
<zezba9000>
By
zezba9000 has quit []
rolf has joined #wayland
<soreau>
MrCooper: it can
<soreau>
at least gtk3
<MrCooper>
maybe on X, "git grep zxdg_decor" comes up empty though
<soreau>
MrCooper: of course some apps can refuse to do this, i.e. if they put the menu button in the titlebar
<Company>
it implements some form of support for the KDE thing
<soreau>
see wlr_server_decoration_manager_set_default_mode()
<soreau>
it basically tells all gtk clients the preferred mode
<Company>
the precursor to the current one
<soreau>
but if you try to change the mode later, gtk refuses strongly
<Company>
there were various attempts at implementing the newer one, but they all came with "the compositor forces the app to do what it wants" and I don't like that
<MrCooper>
no hits for wlr.*decor on main or gtk-3-24
<soreau>
MrCooper: grep for KDE
<Company>
it's org_kde_whatever
<soreau>
MrCooper: the wlr function is a wlroots function that is the server side portion to the puzzle
<davidre>
"The compositor decides in the end" sounds like it should be
<davidre>
Not sure why decorations should be different compared to everything else
<MrCooper>
Company: got it, thanks
rv1sr has quit []
navi has joined #wayland
<JEEB>
OD
<JEEB>
whoops
<Company>
davidre: that only works if you ensure that *all* applications are tested to work properly with both modes
<Company>
and that generally doesn't happen
<Company>
because many app developers use exactly 1 desktop and that desktop uses exactly 1 mode
<Company>
whereas most compositor developers use many apps that support many modes
<davidre>
Hmm that should mean mutter should gain support for ssd ? we almost never test our apps with CSD
<Company>
that's a question you'd need to argue community-wide
<Company>
because originally it was very clear that the one option must be csd
<Company>
and so far everyone has added decorations to their apps
<kennylevinsen>
Company: well, some compositors might always draw SSDs, and Gtk can already draw in ways that are SSD compatible. Say, the tiled/maximized mode, optionally combined with the behavior of `gsettings set org.gnome.desktop.wm.preferences button-layout :`
<Company>
kennylevinsen: that's not quite true - yes, you can always draw yet another set of decorations around a GTK app, but that doesn't make the GTK app SSD compatible
<Company>
in the same way that GTK can always add a resize grip and a titlebar, but that doesn't make GTK apps CSD compatible
<kennylevinsen>
I think that's just a matter of definition. I don't think anyone expects Gtk apps to be magically change their deisgn for SSDs. If the compositor is stubborn about SSDs, it could just try not to be ugly and call it a day
<Company>
the important thing to me is that switching between ssd and csd needs to be opt-in by the app developer
<kennylevinsen>
*maybe* expose the info to the app so it could change its mind about its widgets, but communicating is the most important part
<kennylevinsen>
Well, if the compositor disregards your `request_mode` call, it's because the end-user configured to have SSDs on. In that case, if the app doesn't do SSDs, using the already supported maximized rendition would be fine.
<kennylevinsen>
there could be any number of reasons. heck, special accessibility decorations
<kennylevinsen>
but on the other hand, most compositors should just play ball when you explicitly request CSDs
<Company>
yeah, ideally everyone would just maintain 2 UIs and do twice the work, so the end user could play with another option
<kennylevinsen>
the ability to override is more of a "compositor says this is happening, can you try to accomodate it a bit?" situation
<Company>
but that's not what's happening
<kennylevinsen>
yeah but that would be unreasonable
<Company>
and I want to avoid the bullshit that happened with menus in GTK3
<kennylevinsen>
the maximized UI is already present, and I think people would be quite happy with that as a first step. Then, it could be up to app developers if they care for special modes.
<kennylevinsen>
what bullshit?
<Company>
GTK3 added a menubar somewhere to your window when the compositor had no menu support
<Company>
in the days when unity and gnome had application menus
<Company>
so you got a gray bar somewhere that said "Application"
<Company>
if you ran on xfce or whatever desktop didn't have a menu
<kennylevinsen>
ah, the macos unified menu bar phase?
<Company>
yup
<kennylevinsen>
gotta admit, I was a fanboy of that at one point but in retrospect it was really odd to have part of the app UI detached from the app itself :/
<Company>
so what I want is a UI that is the default that app developers can develop against - I don't care if it's SSD or CSD, but I do care that by default it's only one
<davidre>
FWIW KWin right now respects the preferred mode of the app
<Company>
so if somebody came up with a GTK API that implemented the compositor telling you what it preferred and allowed the app to reconfigure itself to conform to that, fine with me
<Company>
but I'm not gonna do the work and inside Gnome there's also not much interest, because everyone implements the HIG and the HIG says CSD
<kennylevinsen>
no one is forced to do any work they don't care for
<Company>
yeah, just saying that because sometimes there are things that are no-gos
<kennylevinsen>
but it would be nice if there wasn't push back just because GNOME's HIG doesn't have SSDs - gtk is a big deal outside gnome too after all
<kennylevinsen>
at least for things with reasonable maintenance and app developer consequences
glennk has quit [Ping timeout: 480 seconds]
<Company>
GTK developers have in the Gnome 3 days gotten all the pushback that Gnome 3 got, so a bunch of them got into that mindset where they push back against everything
<Company>
that's been changing, but it's still there
<Company>
and CSD was one of those things
<Company>
layer-shell was another one
<Company>
notification-area
<Company>
(though that's no longer a GTK problem)
<Company>
also, about your statement with GTK being a big deal outside of gnome - there's a problem with that
<Company>
because the development of GTK is driven pretty much entirely by gnome
<kennylevinsen>
I mean, the two big toolkits account for a huge portion of all linux apps, and linux is famously not just one desktop
<Company>
core devs are all gnome people, but even the drive-by contributions are almost all from gnome devs
<kennylevinsen>
it's a problem that if there isn't enough external help and external stakeholders
<Company>
yeah, it ultimately leads to us prioritizing gnome even if we wouldn't want to - just because that's the people we work with all the time
<kennylevinsen>
although I suppose there could be a bit of a chicken and egg problem - being more open to external priorities due to external help, vs. accepting external priorities and such getting external help
<kennylevinsen>
hostility towards other goals might lead to fewer contributions, few foreign contributions might lead to hostility towards their goals, round and round we go
<Company>
yeah
<kennylevinsen>
either way, no one can demand other volunteers to spend energy working on *their* problem. Just would be nice if we could all cooperate better instead of throwing rocks at each other ideologies. :)
<Company>
I'm already in this channel where it's always "the compositor should have all the power" as a lonely app developer ;)
<kennylevinsen>
hmm, didn't someone have the idea of using the kernel buffer as indicator for busy clients?
<kennylevinsen>
i.e., full socket buffer being an indicator to throttle events
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
tristianc6704 has quit [Read error: No route to host]
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
rolf1 has joined #wayland
rolf has quit [Ping timeout: 480 seconds]
<ifreund>
fwiw my original patch implementing xdg-deco support in gtk3 years ago ignored the compositor's wishes in favor of CSD just like the current outdated kde protocol implementation does
<ifreund>
it just destroyed the xdg-decoration object if the compositor tried to force ssd xD
<ifreund>
I thought that concession would be enough to get it into gtk and finally drop that ancient kde protocol literally nobody else uses but I guess not...
<pq>
kennylevinsen, hmm, SO_RCVBUF... man 7 socket
<pq>
and SO_SNDBUF, but does it apply to unix sockets... RCVBUF is on the "wrong" side
<kennylevinsen>
should be easy to test
<pq>
ooh
<pq>
"The SO_SNDBUF socket option does have an effect for UNIX domain sockets, but the SO_RCVBUF option does not."
<kennylevinsen>
I suppose we might also be able to handle this a layer above by just stopping if sendmsg sent less than we tried to queue
kts has quit [Ping timeout: 480 seconds]
<kennylevinsen>
and in that case consider the queue full and signal it
<pq>
the only culprit could be /proc/sys/net/core/wmem_max which on my system is 208 kB
<pq>
aaand the default is the same
<kennylevinsen>
same here
<kennylevinsen>
so that's already *way* above our 4k limit
<pq>
yes, it pretty much always was
<kennylevinsen>
I would really like to see a WAYLAND_DEBUG=server from one of the fast crash cases
<pq>
SIGSTOP an arbitrary client? :-)
<kennylevinsen>
to get a mental idea of just how much buffer is needed to keep it alive for, say, 5 seconds
<kennylevinsen>
well, I don't have those fancy schmancy super high res/high poll rate mice
<pq>
you can extrapolate that
<kennylevinsen>
yeah, just don't know how fast those mice go :/
<pq>
the same sequence of events for each motion event, multiplied
<kennylevinsen>
I can manage the multiplication if I knew their motion event rate
<pq>
it's not HiDPI but the rate - I hear 1 kHz is common
<kennylevinsen>
I have never experienced the issue myself, so I assume they're *way* faster than my MX Master/touchpad/touchscreen/tablet
<kennylevinsen>
so it's a motion event (3 args) + frame, so I gues ~40 bytes per movement and around 40KB/s at 1kHz?
kts has joined #wayland
<kennylevinsen>
the kernel buffers should give roughly 5 seconds of buffer at that rate
<pq>
wonder if high precision timestamps extension might be in use
<kennylevinsen>
8kHz mice seem to be a thing though, in which case we're dealing with ~312KB/s
<pq>
oh, maybe relative motion as well?
<kennylevinsen>
with input timestamps 1kHz is 70KB/s, 8kHz is 562KB/s
<kennylevinsen>
header is 4 byte OID, 2 byte opcode and 2 byte length
<pq>
arguments are 4 byte
<kennylevinsen>
doh
<kennylevinsen>
monday
<kennylevinsen>
32 bit, right
<kennylevinsen>
so relative input, high res timestamp, motion and frame: 8+4*6 + 8+4*3 + 8+4*3 + 8 == 80 bytes
<kennylevinsen>
so if we do that whole ordeal, 78KB/s at 1000 Hz, 625KB/s at 8000 Hz
<pq>
that's the ballpark
<kennylevinsen>
a more reasonable 48 bytes without relative input: 46KB/s and 375KB/s for those two cases
<kennylevinsen>
so let's say for a worst case scenario of 10 seconds at 8kHz, we'll need around 3.5MB of buffer
aknot has joined #wayland
<MrCooper>
I'd argue worst case is unlimited (client execution stopped)
fossdd has quit [Ping timeout: 480 seconds]
<kennylevinsen>
I don't personally care about clients that are stopped indefinitely
<MrCooper>
because client developers never need a debugger? ;)
fossdd has joined #wayland
<kennylevinsen>
10 seconds was arbitrary though, but the significance of that number would be the hard limit for how long a client is allowed to block in worst-case scenarios
<kennylevinsen>
well, client developers with high-res mice can try to not to move the mouse on the window for over 10 seconds after pausing it :P
<MrCooper>
sounds like "you're holding it wrong"
<kennylevinsen>
8kHz also seem to be an extreme case way above normal high-*rate* (I keep saying res) mice, *and* that's with all the protocols enabled
<kennylevinsen>
as pq suggests, 1-4kHz seem like the norm, which gives you 2-4x as much time, and you get another roughly 2x for not using relative input
<kennylevinsen>
I do like the throttle idea, but if "just make it big enough" does the trick with almost zero effort...
<pq>
we also have the "add a socket reading thread in libwayland-client" idea...
<pq>
I'm really not sure how much that belongs in libwayland-client though
<kennylevinsen>
I think we've had the idea before, but feels a bit "eh" about having libwayland thread on its own :/
<pq>
exactly
<MrCooper>
many libraries are spawning threads these days
<pq>
but if it fixes real issues for lots of cases...
<MrCooper>
it wouldn't solve the client execution stopped case though
<kennylevinsen>
MrCooper: yeah, but the moment you thread you're subject to a long list of libc caveats that you weren't before
<kennylevinsen>
so it does make a difference
* kennylevinsen
is also *not* happy about automatic mesa threads...
<pq>
OTOH, it can break programs that used to work, who fork() and do things before/instead of exec()
<kennylevinsen>
exactly
privacy has quit [Quit: Leaving]
ity1 has quit []
ity has joined #wayland
tyzef has quit [Quit: WeeChat 3.8]
tyzef has joined #wayland
agd5f_ has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
inkubot has joined #wayland
inkubot has left #wayland [#wayland]
inkubot has joined #wayland
<inkubot>
hi all! quick question: my old macbook only shows one available resolution, the max that this device is capable 2560x1600 ... that resolution has a big impact on cpu temp/fan noise ... a lower res i can barely hear the fan from time to time (1920x1200) ... now if i do a custom res after going to dpms off does not recover with dpms on ... but i use the native res and scale 1.3 all i good again (no noise
<inkubot>
and dpms on) ... my question is: what's the recommended.. custom res or scale ??
<inkubot>
xrandr shows all the res available, but swaymsg -t get_outputs only 2560x1600
<inkubot>
and the same happens on hyprland anda swayt
<inkubot>
btw i'm happy with the scale, just curious what's the best option
<kennylevinsen>
inkubot: 1. that's a question for #sway, 2. swaymsg shows you what the driver tells us, laptop panels just usually only advertise their native mode and nothing else.
<pq>
Xwayland will emulate video mode changes, hence xrandr mode list is mostly invented by Xwayland itself.
<kennylevinsen>
you also generally don't want to run panels at non-native resolutions, you usually want scale. However, driving a panel at "native res", and driving things scaled is the same amount of work for hidpi-aware applications - only non-hidpi apps end up doing less work, getting upscaled instead.
<kennylevinsen>
so unlike lowing resolution it isn't really going to help cool down your laptop
<kennylevinsen>
*lowering
<kennylevinsen>
also make sure you're not using cpu rendering (check #sway@irc.libera.chat for help), and consider playing with fan controls
<kennylevinsen>
(old macbooks used to run hot as heck to stay quiet IIRC)
<inkubot>
thanks kennylevinsen ! interesting i do see the benefinit doing scale... before thise my ondemand mode for the cpu was always at the max
<inkubot>
now i see the cores going to as low 500MHz
<inkubot>
before realising the resolution was the main issue i even disable the turbo boost
<kennylevinsen>
that sounds like a disproportional change - making sure sway is not using software rendering
<kennylevinsen>
again - #sway@irc.libera.chat
<inkubot>
yeps! thanks a lot
mvlad has quit [Remote host closed the connection]
mvlad has joined #wayland
zxrom has quit [Read error: Connection reset by peer]
zxrom has joined #wayland
aknot has quit [Ping timeout: 480 seconds]
rolf1 has quit []
vincejv has joined #wayland
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
inkubot has quit [Quit: leaving]
Guru_DE has quit [Remote host closed the connection]