00:50zezba9000: Hey so I'm on KDE trying to get server side decorations to work in a test C app but nothing is working
00:51zezba9000: https://redstrate.com/blog/2023/07/how-to-use-xdg-decoration-in-a-wayland-client/
00:52zezba9000: Based on this link and others I've looked at I'm not finding what I'm missing to get it working
00:52zezba9000: struct zxdg_toplevel_decoration_v1* decoration = zxdg_decoration_manager_v1_get_toplevel_decoration(decoration_manager, window->xdg_toplevel);
00:53zezba9000: zxdg_toplevel_decoration_v1_add_listener(decoration, &decoration_listener, NULL);
00:53zezba9000: zxdg_toplevel_decoration_v1_set_mode(decoration, ZXDG_TOPLEVEL_DECORATION_V1_MODE_SERVER_SIDE);
00:53zezba9000: No errors, KDE reports correctly ZXDG_TOPLEVEL_DECORATION_V1_MODE_SERVER_SIDE is the default etc
00:54zezba9000: Am I suppose to grab or pass a surface to anything?
00:55zezba9000: Also is there a Discord for Wayland?
01:26danieldg: 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?
01:41zezba9000: Is there a good example of KDE Wayland decorations working?
01:41zezba9000: I for the life of me can't get them working
01:46soreau: gtk uses it IIRC
01:46soreau: then there's always https://gitlab.freedesktop.org/wlroots/wlr-clients/-/raw/master/toplevel-decoration.c
01:51zezba9000: Why are all these examples using EGL and not just portable Wayland buffers that don't require a GPU
01:52zezba9000: Are KDE decorations not working because it wants the Wayland surface buffer to be OpenGL based?
01:52danieldg: that's unlikely
01:53zezba9000: If that was true then Vulkan compositors wouldn't work so I would hope not
01:53danieldg: pretty sure vulkan can accept dmabuf too
01:59zezba9000: I am doing everything these examples are just not using OpenGL
02:01Consolatis: 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
02:01Consolatis: you could use the WAYLAND_DEBUG=1 env var to compare the result of eg the wlroots example client to your application
02:01Consolatis: maybe there is a commit missing or something along that line
02:05zezba9000: Ok guess I needed to do "wl_surface_commit" in the "decoration_handle_configure" callback
02:05zezba9000: That was it
02:06zezba9000: Should you always call "wl_display_flush" after "wl_surface_commit" ?
02:09Consolatis: not my area of expertise, I guess that completely depends on your application flow but it shouldn't hurt
02:09danieldg: you need to eventually call it
02:09danieldg: just like you need to eventually call commit, but it doesn't have to be right after you change decoration settings
02:19zezba9000: Well this is odd. Setting client decorations on only works when it call zxdg_toplevel_decoration_v1_set_mode in wl_pointer_listener
02:20zezba9000: 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
02:21zezba9000: The fact the examples are only doing this in the mouse button down is odd in and of itself
02:22danieldg: zezba9000: if you have a toplevel decoration object, then you can call it anywhere
02:23danieldg: I would not call it from a mouse button handler
02:23danieldg: the configure handler would be sensible, for example
02:27zezba9000: Ok configure seems to work. Ok finally I have everything I need to finalize this I think.
02:30zezba9000: 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?
02:31zezba9000: Maybe something XWayland exposes I could hook into?
02:32Consolatis: regarding xwayland: no. Unless you write a X11 application and not a wayland native one
02:33Consolatis: also I'd expect most stacking compositors to center new windows, are gnome and kde doing something else?
02:34danieldg: zezba9000: there was some discussion on window type hints for a while, but I think that just turned into the content_type protocol
02:34danieldg: the real question is "what causes you to want it centered"
02:35danieldg: and yes, normal window creation position is generally centered already
02:37zezba9000: Do you realize how unprofesional a game looks opening up in some rando location?
02:38danieldg: no, I don't realize
02:38zezba9000: THen you're in a ideological bubble
02:38danieldg: mmkay so are you
02:38zezba9000: Incorrect
02:38danieldg: that's what everyone says
02:38zezba9000: Its not your job to tell me how my app should be made
02:39danieldg: fullscreen it then
02:39zezba9000: LMFAO
02:40zezba9000: 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"
02:40Consolatis: I see it similar, either be a window and be under the control of the compositor / user (including initial placement) or be fullscreen
02:40danieldg: ok, you're trolling now. Bye.
02:41zezba9000: k good ridence. Try expanding your perspective outside the Linux echo chamber for once
02:41Consolatis: 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
02:41zezba9000: This isn't a RANDOM spot...
02:41zezba9000: The app IS NOT SETTING ITS POSITION
02:42zezba9000: This is a hint like X11 ATOM, WinRT requests, macOS center Window request etc etc etc
02:43Consolatis: 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.
02:43zezba9000: Center is random? lol, what do words mean?
02:43zezba9000: Do you know what center Window request does on macOS?
02:44danieldg: it makes apple money
02:44zezba9000: 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
02:45Consolatis: 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"
02:45zezba9000: "Gnome3 litterlly puts Windows in rando positions... but but centering a Window is "random". Just wow
02:45danieldg: zezba9000: this sounds like a good proposal for a protocol, if people think it's important
02:45zezba9000: Yes thats all I'm suggesting.
02:46danieldg: please cite apple here, not just "obviously" and "clearly I want it BECAUSE CENTERING DUH"
02:46zezba9000: Something an app can request BUT a user or compositor can change
02:46zezba9000: Centering exists in ALL operating systems With Windows since the 80s. I am NOT making this up
02:46zezba9000: There are very valid reasons for this
02:46zezba9000: And I don't need to argue every one here
02:47danieldg: yet you are?
02:47danieldg: has someone made a protocol proposal for this?
02:47zezba9000: 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
02:48zezba9000: Is there a better place to suggest?
02:48danieldg: no, I'd call that gnome's fault
02:48danieldg: suggest to gnome they fix it, perhaps by adding a protocol
02:49zezba9000: I love zero standards don't you?!
02:49zezba9000: No I'll suggest a standard please that Gnome can choose to ignore
02:49danieldg: that's gnome's problem
02:49danieldg: they ignore lots of things
02:50danieldg: maximize buttons? No, gnome knows you don't want that.
02:50psykose: 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?
02:50psykose: now you do
02:51Consolatis: zezba9000: feel free to open a MR at https://gitlab.freedesktop.org/wayland/wayland-protocols/ with a new protocol
02:51zezba9000: @Consolatis Thanks. Will do
02:53danieldg: zezba9000: ext-placement may already be what you want
02:55zezba9000: danieldg: is this an existing suggestion not implementation correct?
02:55danieldg: zezba9000: correct; see the MR list there
02:55danieldg: there are a lot of comments (over 200) on the two MRs
02:55danieldg: maybe you have something to add, maybe you don't
02:57zezba9000: Ok thanks. I think 35 years of reasons behind Windows opening centered hasn't changed with the introduction of Wayland.
02:58danieldg: then gnome is wrong to position stuff in the corner
02:58danieldg: that does sound wrong
02:58zezba9000: Yes I agree, Gnome3 drives me up a wall
02:58zezba9000: Can't wait for PopOS Cosmic
05:24smop: I was wondering if there is any such capability in wayland compositors where I can draw on certain regions of the screen.
05:25Company: there are not
05:25smop: For example, I have a chrome window open, and I want to maybe outline a piece of text or highlight something
05:25smop: I see would that be a useful feature or is it probably too much to handle given how wayland handles windows?
05:26Company: I'd think you'd have a hard time knowing where all the other windows are in the first place
05:29Company: it sounds like something that would probably be easier to implement as a compositor plugin/extension
05:38smop: 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?
08:11wlb: wayland Issue #443 opened by Mathieu Comandon (strycore) Does our code suck or is there something we're not seeing? (Lutris, high DPI mouse) https://gitlab.freedesktop.org/wayland/wayland/-/issues/443
08:57MrCooper: soreau: GTK doesn't use SSD
08:58zezba9000: daniels: FK you, ya low IQ dumb shit. Keep rattling around in your echo chamber. (boo hoo, something disagrees with me)
08:58zezba9000: By
09:01soreau: MrCooper: it can
09:01soreau: at least gtk3
09:06MrCooper: maybe on X, "git grep zxdg_decor" comes up empty though
09:06soreau: MrCooper: of course some apps can refuse to do this, i.e. if they put the menu button in the titlebar
09:06Company: it implements some form of support for the KDE thing
09:07soreau: see wlr_server_decoration_manager_set_default_mode()
09:07soreau: it basically tells all gtk clients the preferred mode
09:07Company: the precursor to the current one
09:07soreau: but if you try to change the mode later, gtk refuses strongly
09:08Company: 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
09:11MrCooper: no hits for wlr.*decor on main or gtk-3-24
09:11soreau: MrCooper: grep for KDE
09:11Company: it's org_kde_whatever
09:12soreau: MrCooper: the wlr function is a wlroots function that is the server side portion to the puzzle
09:12davidre: "The compositor decides in the end" sounds like it should be
09:12davidre: Not sure why decorations should be different compared to everything else
09:12MrCooper: Company: got it, thanks
09:29JEEB: OD
09:29JEEB: whoops
09:50Company: davidre: that only works if you ensure that *all* applications are tested to work properly with both modes
09:51Company: and that generally doesn't happen
09:52Company: because many app developers use exactly 1 desktop and that desktop uses exactly 1 mode
09:52Company: whereas most compositor developers use many apps that support many modes
09:55davidre: Hmm that should mean mutter should gain support for ssd ? we almost never test our apps with CSD
09:58Company: that's a question you'd need to argue community-wide
09:59Company: because originally it was very clear that the one option must be csd
09:59Company: and so far everyone has added decorations to their apps
10:02kennylevinsen: 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 :`
10:03Company: 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
10:04Company: in the same way that GTK can always add a resize grip and a titlebar, but that doesn't make GTK apps CSD compatible
10:04kennylevinsen: 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
10:05Company: the important thing to me is that switching between ssd and csd needs to be opt-in by the app developer
10:05kennylevinsen: *maybe* expose the info to the app so it could change its mind about its widgets, but communicating is the most important part
10:06kennylevinsen: 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.
10:06kennylevinsen: there could be any number of reasons. heck, special accessibility decorations
10:07kennylevinsen: but on the other hand, most compositors should just play ball when you explicitly request CSDs
10:07Company: yeah, ideally everyone would just maintain 2 UIs and do twice the work, so the end user could play with another option
10:07kennylevinsen: the ability to override is more of a "compositor says this is happening, can you try to accomodate it a bit?" situation
10:07Company: but that's not what's happening
10:07kennylevinsen: yeah but that would be unreasonable
10:08Company: and I want to avoid the bullshit that happened with menus in GTK3
10:08kennylevinsen: 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.
10:08kennylevinsen: what bullshit?
10:09Company: GTK3 added a menubar somewhere to your window when the compositor had no menu support
10:09Company: in the days when unity and gnome had application menus
10:09Company: so you got a gray bar somewhere that said "Application"
10:10Company: if you ran on xfce or whatever desktop didn't have a menu
10:10kennylevinsen: ah, the macos unified menu bar phase?
10:10Company: yup
10:11kennylevinsen: 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 :/
10:11Company: 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
10:11davidre: FWIW KWin right now respects the preferred mode of the app
10:13Company: 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
10:13Company: 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
10:14kennylevinsen: no one is forced to do any work they don't care for
10:15Company: yeah, just saying that because sometimes there are things that are no-gos
10:16kennylevinsen: 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
10:17kennylevinsen: at least for things with reasonable maintenance and app developer consequences
10:18Company: 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
10:18Company: that's been changing, but it's still there
10:19Company: and CSD was one of those things
10:19Company: layer-shell was another one
10:19Company: notification-area
10:19Company: (though that's no longer a GTK problem)
10:20Company: also, about your statement with GTK being a big deal outside of gnome - there's a problem with that
10:20Company: because the development of GTK is driven pretty much entirely by gnome
10:21kennylevinsen: I mean, the two big toolkits account for a huge portion of all linux apps, and linux is famously not just one desktop
10:21Company: core devs are all gnome people, but even the drive-by contributions are almost all from gnome devs
10:22kennylevinsen: it's a problem that if there isn't enough external help and external stakeholders
10:23Company: 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
10:24kennylevinsen: 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
10:25kennylevinsen: hostility towards other goals might lead to fewer contributions, few foreign contributions might lead to hostility towards their goals, round and round we go
10:28Company: yeah
10:29kennylevinsen: 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. :)
10:30Company: I'm already in this channel where it's always "the compositor should have all the power" as a lonely app developer ;)
10:48wlb: wayland Issue #444 opened by Vlad Zahorodnii (zzag) Cursor updates during drag and drop https://gitlab.freedesktop.org/wayland/wayland/-/issues/444
12:46kennylevinsen: hmm, didn't someone have the idea of using the kernel buffer as indicator for busy clients?
12:46kennylevinsen: i.e., full socket buffer being an indicator to throttle events
13:14ifreund: 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
13:15ifreund: it just destroyed the xdg-decoration object if the compositor tried to force ssd xD
13:16ifreund: 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...
13:18pq: kennylevinsen, hmm, SO_RCVBUF... man 7 socket
13:20pq: and SO_SNDBUF, but does it apply to unix sockets... RCVBUF is on the "wrong" side
13:22kennylevinsen: should be easy to test
13:22pq: ooh
13:22pq: "The SO_SNDBUF socket option does have an effect for UNIX domain sockets, but the SO_RCVBUF option does not."
13:23kennylevinsen: 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
13:24kennylevinsen: and in that case consider the queue full and signal it
13:26pq: the only culprit could be /proc/sys/net/core/wmem_max which on my system is 208 kB
13:26pq: aaand the default is the same
13:28kennylevinsen: same here
13:28kennylevinsen: so that's already *way* above our 4k limit
13:28pq: yes, it pretty much always was
13:28kennylevinsen: I would really like to see a WAYLAND_DEBUG=server from one of the fast crash cases
13:29pq: SIGSTOP an arbitrary client? :-)
13:29kennylevinsen: to get a mental idea of just how much buffer is needed to keep it alive for, say, 5 seconds
13:29kennylevinsen: well, I don't have those fancy schmancy super high res/high poll rate mice
13:29pq: you can extrapolate that
13:29kennylevinsen: yeah, just don't know how fast those mice go :/
13:30pq: the same sequence of events for each motion event, multiplied
13:30kennylevinsen: I can manage the multiplication if I knew their motion event rate
13:30pq: it's not HiDPI but the rate - I hear 1 kHz is common
13:31kennylevinsen: I have never experienced the issue myself, so I assume they're *way* faster than my MX Master/touchpad/touchscreen/tablet
13:34kennylevinsen: so it's a motion event (3 args) + frame, so I gues ~40 bytes per movement and around 40KB/s at 1kHz?
13:34kennylevinsen: the kernel buffers should give roughly 5 seconds of buffer at that rate
13:36pq: wonder if high precision timestamps extension might be in use
13:36kennylevinsen: 8kHz mice seem to be a thing though, in which case we're dealing with ~312KB/s
13:37pq: oh, maybe relative motion as well?
13:38kennylevinsen: with input timestamps 1kHz is 70KB/s, 8kHz is 562KB/s
13:39pq: hmm, I counted 28 bytes for basic motion?
13:40kennylevinsen: isn't wl_pointer::motion 8 byte header + 3 8-byte arguments (32) + 8 byte header for wl_pointer::frame?
13:42kennylevinsen: header is 4 byte OID, 2 byte opcode and 2 byte length
13:42pq: arguments are 4 byte
13:42kennylevinsen: doh
13:42kennylevinsen: monday
13:42kennylevinsen: 32 bit, right
13:45kennylevinsen: so relative input, high res timestamp, motion and frame: 8+4*6 + 8+4*3 + 8+4*3 + 8 == 80 bytes
13:45kennylevinsen: so if we do that whole ordeal, 78KB/s at 1000 Hz, 625KB/s at 8000 Hz
13:46pq: that's the ballpark
13:46kennylevinsen: a more reasonable 48 bytes without relative input: 46KB/s and 375KB/s for those two cases
13:47kennylevinsen: so let's say for a worst case scenario of 10 seconds at 8kHz, we'll need around 3.5MB of buffer
13:54MrCooper: I'd argue worst case is unlimited (client execution stopped)
13:55kennylevinsen: I don't personally care about clients that are stopped indefinitely
13:55MrCooper: because client developers never need a debugger? ;)
13:56kennylevinsen: 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
13:56kennylevinsen: 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
13:57MrCooper: sounds like "you're holding it wrong"
13:57kennylevinsen: 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
13:57kennylevinsen: 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
13:58kennylevinsen: I do like the throttle idea, but if "just make it big enough" does the trick with almost zero effort...
14:01pq: we also have the "add a socket reading thread in libwayland-client" idea...
14:02pq: I'm really not sure how much that belongs in libwayland-client though
14:02kennylevinsen: I think we've had the idea before, but feels a bit "eh" about having libwayland thread on its own :/
14:03pq: exactly
14:03MrCooper: many libraries are spawning threads these days
14:03pq: but if it fixes real issues for lots of cases...
14:04MrCooper: it wouldn't solve the client execution stopped case though
14:04kennylevinsen: MrCooper: yeah, but the moment you thread you're subject to a long list of libc caveats that you weren't before
14:04kennylevinsen: so it does make a difference
14:04kennylevinsen:is also *not* happy about automatic mesa threads...
14:04pq: OTOH, it can break programs that used to work, who fork() and do things before/instead of exec()
14:05kennylevinsen: exactly
15:37inkubot: 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
15:37inkubot: and dpms on) ... my question is: what's the recommended.. custom res or scale ??
15:38inkubot: xrandr shows all the res available, but swaymsg -t get_outputs only 2560x1600
15:38inkubot: and the same happens on hyprland anda swayt
15:40inkubot: btw i'm happy with the scale, just curious what's the best option
15:44kennylevinsen: 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.
15:45pq: Xwayland will emulate video mode changes, hence xrandr mode list is mostly invented by Xwayland itself.
15:46kennylevinsen: 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.
15:47kennylevinsen: so unlike lowing resolution it isn't really going to help cool down your laptop
15:47kennylevinsen: *lowering
15:50kennylevinsen: also make sure you're not using cpu rendering (check #sway@irc.libera.chat for help), and consider playing with fan controls
15:50kennylevinsen: (old macbooks used to run hot as heck to stay quiet IIRC)
15:52inkubot: thanks kennylevinsen ! interesting i do see the benefinit doing scale... before thise my ondemand mode for the cpu was always at the max
15:52inkubot: now i see the cores going to as low 500MHz
15:52inkubot: before realising the resolution was the main issue i even disable the turbo boost
15:53kennylevinsen: that sounds like a disproportional change - making sure sway is not using software rendering
15:53kennylevinsen: again - #sway@irc.libera.chat
15:53inkubot: yeps! thanks a lot