08:54wlb: wayland-protocols Issue #185 opened by Matthias Clasen (matthiasc) cursor shape issues https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/185
09:01pq: swick[m], awesome :-) I installed the vale extension in vscode too, but I guess I need to remove it, because it seems to run on all projects instead of configured ones. Worse, it is flagging every single word as failing spellcheck.
09:03pq: hmm, it wasn't vale...
11:44wlb: wayland-protocols Issue #186 opened by Matthias Clasen (matthiasc) More cursor shape issues https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/186
13:07oliver: Hi
13:39wlb: weston Issue #894 opened by Julian Orth (mahkoh) Commit state is lost when subsurface is destroyed. https://gitlab.freedesktop.org/wayland/weston/-/issues/894
13:51Nova[m]: is there a protocol in development for full application save/restore? like after the client has been launched it is given data from a previous session that it gave the compositor?
13:51davidre: xdg-session-restore
13:52davidre: *session-managment
13:52davidre: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18
13:53Nova[m]: ah, yeah that's not quite what i needed
13:53Nova[m]: with that one the app is the one to save the data and ask the compositor to restore its toplevel position but that doesn't work for the case where the compositor launches an app instance and gives it data
13:53Nova[m]: s/save/add/, s/data/toplevel/
13:54Nova[m]: basically, since the compositor i'm making is for AR/VR it's a necessity to have the compositor ask the app to give it all the data it needs to give back to it to restore its state
13:55Nova[m]: because if you leave a 2D app at your house, go 2 cities over, then come back it should be there but it can't be still running or suspended in RAM
13:55bl4ckb0ne: shouldnt that be handled by the compositor?
13:55Nova[m]: yes, but the compositor can't do it alone
13:56Nova[m]: it has to get some state data from the apps and then hand it back to the apps when launching again when they're reloading
13:56Nova[m]: i already got it working for the stardust protocol and it's very seamless, but it doesn't work for 2D apps since wayland doesn't have anything like it
13:56Nova[m]: basically, this is the equivalent of an android bundle object
13:57emersion: why can't the app save its state on its own?
13:57Nova[m]: because it could have multiple instances in different places
13:57emersion: yes?
13:57emersion: compositor gives the app an ID for the current session
13:58emersion: the app can save its state in a different place for each ID
13:58Nova[m]: right, but can the compositor say "ok now restore session from this ID" though?
13:58emersion: with the protocol, i believe so
13:58Nova[m]: looking at the protocol i thought the app was the one to decide which session it is using
13:59emersion: hm, maybe i'm misremembering
13:59emersion: at any rate, i don't think it's a good idea to pass around the app's state to the compositor
13:59bl4ckb0ne: ^
14:00bl4ckb0ne: also cant you just suspend the machine?
14:00Nova[m]: no because this is all day XR so it'd be wearing a headset all that time and needing to unload an app that's physically far away
14:00Nova[m]: it's for spatial persistence
14:01Nova[m]: the way it works in the stardust protocol is the client must implement a method that gives the compositor its state whenever the compositor requests it
14:01Nova[m]: s/compositor/server/
14:02Nova[m]: then the server might launch the app and will send it back the state it gave as the first message
14:02Nova[m]: so the app can now take that and restore its state
14:02Nova[m]: (including spatial anchors)
14:02Nova[m]:uploaded a video: (60637KiB) < https://matrix.org/_matrix/media/v3/download/matrix.org/iezXYqmvNwAVBhXHPMQJVPdV/save_restore_state.mp4 >
14:04Nova[m]: the water bottle model is exactly where it was left, but if you had multiple of them it'd launch multiple instances and give each different data
14:04Nova[m]: s/data/state/
14:05Nova[m]: s/data/state corresponding to all the instances in that location that were unloaded/
14:05Nova[m]: that's what i need that the session management protocol doesn't do
14:06Nova[m]: (i don't know how to launch apps just as they were launched before so for now just filtering out every one not being run by the same user as the compositor and yoinking their cmdline to use later)
14:07Nova[m]: will have to find a better method that takes into account flatpaks, but regardless... wayland clients can't be fed data they had previously
14:07Nova[m]: idk if this is better as a portal or a wayland protocol, but i'm willing to work on whatever is best to get this working
14:07bl4ckb0ne: how does it work? do you just copy all of the client's memory and put it back?
14:08Nova[m]: no, the client submits a byte array (eventually a fd or such) that the server stores
14:08Nova[m]: but if the client just submits a string and stores its own stuff in its own state folder that'd be fine too
14:08bl4ckb0ne: that sounds like a security issue
14:08Nova[m]: * server stores as well as spatial anchors (spatial positions that are persisted)
14:08Nova[m]: how would it be a security issue?
14:09Nova[m]: * fine too, the key is to be able to get it to load different data per instance
14:10Nova[m]: * fine too, the key is to be able to get it to load different data per instance so you can have the exact same app in the same state in the same physical position
14:10Nova[m]: it's what android and iOS both do for app save/restore
14:10Nova[m]: * server stores as well as spatial anchors (spatial positions that are persisted) and is given it back when it's started again by the compositor
14:11Nova[m]: * server stores as well as spatial anchors (spatial positions that are persisted) and is given it back when it's started again by the compositor... the byte array is serialized/deserialized by the client itself.
14:13Nova[m]: https://developer.android.com/guide/components/activities/activity-lifecycle#saras
14:15Nova[m]: many toolkits support this already, such as Qt: https://doc.qt.io/qt-5/qmainwindow.html#restoreState
14:16Nova[m]: a protocol for this would also benefit linux phones too, letting them kill processes to save resources instead of pausing them and then when the user switches back to them reloading them with their state given back to them to reload
14:16Nova[m]: s/reload/deserialize and apply/
14:18Nova[m]: it's a nice to have thing on phones but kinda crucial for all day XR
14:18zamundaaa[m]: Nova: we do need a way for the compositor (or rather, desktop environment or whatever starts apps) to tell apps to restore a specific session
14:18zamundaaa[m]: But it's not necessarily the compositor that has to store the app's session data
14:18Nova[m]: that's fine, as long as the session can be specified to the app then whoever stores it can do what they like
14:19Nova[m]: so, should i make a comment/PR to session management for this case?
14:19Nova[m]: probably just an event for the compositor to send over to tell the client that it should restore a given session ID
14:20zamundaaa[m]: I don't think that makes sense
14:20zamundaaa[m]: That's a bit late in the process
14:21zamundaaa[m]: Like, it could just be a flag in launch arguments for the app
14:21Nova[m]: oh it's about to be merged? shoot i was too late
14:21zamundaaa[m]: Nova: no, I mean late in the process of app startup
14:21zamundaaa[m]: The protocol is quite far from being done
14:21Nova[m]: oh well... idk how to do it across all apps and early in the process
14:21Nova[m]: this has to be a standard thing after all
14:22Nova[m]: actually... this is kinda universal across everything
14:22Nova[m]: so universal it might be best to use an environment variable
14:22zamundaaa[m]: yeah, that's what xdg activation does too
14:22Nova[m]: is xdg activation already covering the use case i want?
14:22zamundaaa[m]: no
14:22Nova[m]: ok, yeah i figured
14:22zamundaaa[m]: it's about window focus
14:23Nova[m]: xdg activation is so hard to understand for me
14:23Nova[m]: and DESKTOP_SESSION_ID doesn't actually work for most apps, they don't pass it to the compositor
14:23Nova[m]: * and `DESKTOP_SESSION_ID, * DESKTOP_SESSION_ID` doesn't
14:23Nova[m]: even though afaik they *should*
14:25Nova[m]: so... this is ideal as an XDG standard that doesn't fall under portals or wayland but is like the icon spec or such?
14:25Nova[m]: who do i even talk to about starting the process to make that standard? :S
14:25drakulix[m]: For wayland apps you want to use XDG_ACTIVATION_TOKEN instead of DESKTOP_SESSION_ID (or rather set both, since you can't know what window protocol the app uses).
14:26Nova[m]: right, but the app only sends that through to the compositor so you can tie the state of the launcher to the wayland client that connects to your compositor right?
14:26Nova[m]: * right, but the app only sends that through to the compositor so you can tie the state of the way it was launched to the wayland client that connects to your compositor right?
14:27wlb: weston Issue #895 opened by Алексей Худобин (alexey.khudobin) Keyboard(remote) not working with rdp when rdp is secondary backend and shell=kiosk https://gitlab.freedesktop.org/wayland/weston/-/issues/895
14:28drakulix[m]: Sure, you save the state, when the launcher creates the token and then use that, when you get the request from the application using the token.
14:28zamundaaa[m]: Nova: "XDG" is just a namespace for Wayland protocols here, nothing more or less
14:28zamundaaa[m]: defining a standard for session management can and should happen in the process of defining the protocol
14:29Nova[m]: wait so this is the right channel to talk about this in? i am so lost :S
14:29zamundaaa[m]: yes
14:29Nova[m]: ok good phew
14:30Nova[m]: so, i like the environment variable strategy... but somehow the app has to recieve a request to save its state from somewhere
14:30Nova[m]: * from somewhere and have an ID given to it
14:30Nova[m]: given that's not particularly tied to wayland or anything, would that be a portal?
14:31Nova[m]: * given that's not particularly tied to wayland or anything, would a portal be best?
14:31zamundaaa[m]: stopping a session would definitely be tied to Wayland
14:31Nova[m]: it wouldn't be stopping a session
14:31zamundaaa[m]: sure it would. Sessions are per app mind you
14:31Nova[m]: it'd just be going "hey app, save your state and associate that state with this ID that you might be launched with"
14:31Nova[m]: * launched with later"
14:32Nova[m]: that state isn't necessarily wayland state, it could be X state or stardust state or whatever
14:32zamundaaa[m]: session management with X11 is a lost cause, I wouldn't even think about it in this context
14:33Nova[m]: ok fair x is dead and we killed it
14:33zamundaaa[m]: How the proposed protocol works is pretty much that the app can ask the compositor to give it a session, and then it gets an ID for that session
14:33zamundaaa[m]: The app's own data could just be tied to that ID
14:33Nova[m]: but stardust has its own state too
14:33Nova[m]: i made a separate stardust protocol that's not tied to wayland given just how different stardust is from every wayland use ever
14:34Nova[m]: and ideally i'd like to use the same session IDs and all
14:34zamundaaa[m]: How to integrate between your protocol and the compositor is up to you
14:34zamundaaa[m]: You could just have the compositor associate IDs internally, or make it be passed through the protocol
14:34mclasen: xsmp never really got off the ground. I'm doubtful that a Wayland session save/restore protocol will fare much better
14:35davidre: Firefox uses xsmp on wayland :)
14:35Nova[m]: this is why i basically forced everyone using the stardust protocol to save their state if their app is more complicated than a static floating cube
14:35Nova[m]: saving/restoring state is stupidly important for XR
14:36Nova[m]: mclasen: why didn't it get off the ground?
14:36Nova[m]: zamundaaa[m]: what it currently doesn't do is tell the app that it should restore a given session ID from the start
14:36zamundaaa[m]: yeah, that could be done through an environment variable
14:37mclasen: I don't know that anybody has done a root cause analysis. My take is that its a mixture of complex/ambition protocol and insufficient toolkit-level support
14:37Nova[m]: ok awesome, so what should that be called?
14:37Nova[m]: `XDG_SESSION_ID` would be too confusing
14:37Nova[m]: since we have `XDG_ACTIVATION_TOKEN` and `DESKTOP_SESSION_ID`
14:38zamundaaa[m]: XDG_SESSION_RESTORE_ID maybe. The exact name isn't too important
14:38davidre: FWIW we Qt/KDE uses the XSMP hooks to store app state
14:38Nova[m]: that makes sense
14:38davidre: Stuff like toolbar config, window size, etc..
14:39Nova[m]: is xsmp tied to xorg? aka is it going to die soon?
14:40davidre: xsmp is not part of the xserver
14:40davidre: It's a protcol like wayland. But most clients do not use it on wayland
14:40Nova[m]: oh huh, is that something that is adequate for use or is it worth replacing?
14:41davidre: I only know of firefox which even uses it as a wayland client
14:41davidre: XSMP is not really nice in my opinion
14:41Nova[m]: reason enough to replace it if barely anyone uses it and it sucks
14:41Nova[m]: * it sucks and we need a session restore thing
14:42davidre: It involves client passing commands to the server to execute to restore/discard state
14:42zamundaaa[m]: yeah it's beyond "not really nice"
14:42davidre: Which is very questionable
14:42mclasen: xsmp is defined using ice - the dbus of a previous generation
14:42Nova[m]: ohno
14:43Nova[m]: it's worse than dbus? :0
14:43davidre: the actual wire procotol is the least of the problems
14:44Nova[m]: okay, so in practice if we say "this is the environment variable that if set you should restore the session for"
14:44Nova[m]: and then in the wayland protocol go "the session id you got might be passed back in this env variable"
14:45Nova[m]: * env variable and you must (or at least really should) restore its state"
14:45Nova[m]: and then have stardust use the same environment variable for its session IDs
14:45mclasen: I am very dubious about involving environment variables in this
14:46Nova[m]: okay, well what other mechanism could let the compositor/session manager tell the app to restore its state according to a given session ID early enough in the lifecycle that it won't cause a mess?
14:47Nova[m]: if we do it when the xdg session manager global is bound it may be too late
14:48Nova[m]: * too late, the app might have already started launching without the state we want it to start with
14:48mclasen: I think that is the apps problem to solve
14:48Nova[m]: * do it with a wayland event when the, * too late, the app might have already started launching without the state we want it to start with
14:48zamundaaa[m]: I think it depends a lot on what kind of state you want to restore too
14:48Nova[m]: it's easy to *say* but in practice i think most apps will just go "no not worth it"
14:48zamundaaa[m]: or rather at what level you want session restoration to happen
14:49zamundaaa[m]: If it's on the toolkit level, doing it when the global is bound should be fine
14:49zamundaaa[m]: If it's on the app level, the env var is probably better
14:49Nova[m]: what do you mean by toolkit vs app level?
14:49Nova[m]: like, if it's just the window sizes or if it's the exact page that was open before?
14:50Nova[m]: because in the case i'm talking about it should really be the entire UI that was open when its state was closed will be there when you get back...
14:51Nova[m]: like, the equivalent of https://developer.apple.com/documentation/foundation/nsuseractivity
14:51Nova[m]: so even the text editing field and open document should be as it was before
14:51Nova[m]: * was before ideally
14:52Nova[m]: but of course even just being the same window size and open document would be nice even if the smallest details aren't preserved
14:52Nova[m]: * size and position and open document
14:52mclasen: env vars have the wrong characteristics - they get inherited, and unsetting them isn't threadsafe
14:52zamundaaa[m]: If you want anything except window properties, you need the app to actually directly support it
14:53Nova[m]: zamundaaa[m]: yep, that's fine since toolkits can often assist there
14:53Nova[m]: idk if gtk can but i know Qt can since it does for macOS
14:53Nova[m]: * for macOS/iOS/android to some extent
14:53Nova[m]: * for macOS/iOS/android/windows to some extent
14:54Nova[m]: mclasen: ok the inheritance part is a problem, but what better mechanism is there?
14:56Nova[m]: wait hang on technically all the other platforms get their session save/restore from display server adjacent things... maybe it wouldn't be too late in the app launching?
14:57Nova[m]: but you can easily call the session save/restore stuff earlier except with android activities
14:57Nova[m]: but activities do way more than wayland anyway...
14:58zamundaaa[m]: We need some sort of race free way to detect that an app has been started for session restoration purposes
14:58zamundaaa[m]: Outside of that, going through the Wayland protocol would be fine
14:58mclasen: there's overlap here with activation, for sure
14:59Nova[m]: yeah, and that uses env vars
14:59zamundaaa[m]: mclasen: right, a special xdg activation token could work
14:59zamundaaa[m]: but the compositor doesn't get that until there's a window to activate
15:00Nova[m]: does it matter that unsetting env vars is thread unsafe?
15:00Nova[m]: if it doesn't really matter it'd be easy to just tell app devs "hey unset this env var the moment you read it"
15:01mclasen: it means you have to read, stash and unset the env var early on, before other threads start poking at the environment
15:01mclasen: and it is a bit hard to know when that is safe to do
15:02Nova[m]: what's wrong with other threads poking at the environment though?
15:03Nova[m]: hell, the only reason to unset the env var is to stop any processes launched by the app from trying to restore the same state
15:03kennylevinsen: env vars are suboptimal for things that aren't meant to affect the entire subtree of processes... It isn't entirely unheard of to unset env vars early on (like WAYLAND_SOCKET), but it feels a bit icky
15:03mclasen: a setenv call in thread A makes a getenv call in thread B crash
15:03Nova[m]: shoot memory unsafety >:(
15:03mclasen: and getenv is called e.g. by innocent looking things like _()
15:05Nova[m]: so... shoot
15:05Nova[m]: is there no good mechanism for this?
15:05Nova[m]: i mean, aside from a portal that an app calls early that is
15:05Nova[m]: wait but that wouldn't even work since you need a way to ID how the app launched...
15:06Nova[m]: unless you piped your xdg activation token into the session portal and got back out a session restore ID
15:06Nova[m]: but that's way to convoluted
15:06Nova[m]: s/to/too/
15:06zamundaaa[m]: You could use launch arguments
15:06zamundaaa[m]: Like dolphin --xdg-session-restoration=id
15:06Nova[m]: how is that supposed to be universal though?
15:06Nova[m]: every app has its own way of parsing them
15:07mclasen: you start to get an idea why xsmp failed...
15:07jadahl: or 'platform-data' via D-Bus activation
15:07zamundaaa[m]: Nova: if your goal is to have the app take part in session management, that's not an issue
15:08zamundaaa[m]: or you could leave the "figure out if app is session-restoration-started" up to implementations
15:08Nova[m]: yeah but there has to be a universal way to do this that doesn't screw up a whole area
15:08Nova[m]: zamundaaa[m]: that'd be even worse
15:08Nova[m]: jadahl: ooh what's this?
15:08zamundaaa[m]: No, I'm saying that the compositor could check if some special process has started the app
15:09zamundaaa[m]: And then tell the app through the protocol that it should restore its state with some session ID
15:09jadahl: D-Bus activation is a way to "activate" a service/app by doing a dbus call, by starting or just calling a method. the method takes a 'platform-data' that is like an environment (a key-value dict where the value can be "any" data structure)
15:09Nova[m]: zamundaaa[m]: how could it check?
15:10Nova[m]: jadahl: how can you activate an app when it wasn't running like that?
15:10jadahl: Nova[m]: they install a dbus activation service file that describes how to launch it
15:10davidre: jadahl: that only works for apps that always have maximum one process
15:10zamundaaa[m]: Nova: you have some sort of thing to start apps when the user is close to them in VR space, right?
15:11Nova[m]: davidre: i will when monado implements spatial anchors
15:11jadahl: davidre: can't there be a "outward facing" process that routes calls accordingly?
15:11jadahl: Nova[m]: look in /usr/share/dbus-1/services/ for examples
15:11zamundaaa[m]: You can have that thing signal the compositor through a special protocol about the app being started for example
15:11Nova[m]: zamundaaa[m]: i will when monado implements spatial anchors
15:11Nova[m]: for now i just launch all of them that were in a session
15:12davidre: jadahl: maybe
15:12Nova[m]: zamundaaa[m]: would it be early enough for the app to react and restore its state?
15:12bl4ckb0ne: we don't have anchors?
15:12davidre: But it means we would need to create such a router for every app that isn't dbus activatable right now
15:12davidre: or a generic router maybe
15:13davidre: no that woldnt work
15:13bl4ckb0ne: Nova[m]: you need XR_HTC_anchor ?
15:13bl4ckb0ne: or XR_MSFT_spatial_anchor
15:13Nova[m]: bl4ckb0ne: that one
15:13bl4ckb0ne: or XR_MSFT_spatial_anchor_persistence
15:14zamundaaa[m]: Nova: if the toolkit supports it, sure. Apps could connect to the Wayland session and check for session restoration first thing when they start up
15:14Nova[m]: no wait i was wrong
15:14Nova[m]: XR_MSFT_spatial_anchor_persistence
15:15Nova[m]: * `XR_MSFT_spatial_anchor_persistence`
15:15Nova[m]: that's the one i need
15:15Nova[m]: zamundaaa[m]: that's what worries me though, wayland might be started way later than the session would want to be restored for the app
15:16zamundaaa[m]: The compositor is always started before apps
15:16Nova[m]: i mean the wayland client
15:16Nova[m]: s/client/socket connection in the app/
15:17zamundaaa[m]: That's not how it works in the toolkits I know about
15:18Nova[m]: oh, well that's good
15:18jadahl: Nova[m]: the app that needs to talk to Wayland need to wait for the right systemd target before launching
15:19jadahl: otherwise there is no guarantee it'll be able to connect
15:19Nova[m]: jadahl: systemd target?
15:20kennylevinsen: or be started by the wayland compositor/otherwise synchronized to only connect *after* the wayland server is running
15:21Nova[m]: oh, well i can ensure that the wayland clients connect after the wayland server easily
15:21jadahl: sure, either if the compositor is the process lifetime manager, then no issue. if you're using systemd to manager your processes, there is a target that the compositor will "call" to say its ready to receive clients, and apps that need a Wayland compositor must only start after this target
15:22Nova[m]: sure, that's fine... but what about if an app connects to the compositor after it would have restored the state?
15:23Nova[m]: s/the/its/
15:23davidre: this would not happen
15:24davidre: as the app needs to add new code for session restore
15:24davidre: it can make sure it happens in the right order
15:24davidre: or am I missing something
15:24jadahl: I'm missing a lot of context fwiw :P
15:24Nova[m]: idk i might just be catastrophizing
15:25Nova[m]: davidre: except for the toolkits that do it
15:25Nova[m]: * do it already
15:35Nova[m]: wait a moment how would the compositor even know which app is which
15:35Nova[m]: s/which/the one to send the restore session ID to?/
16:15immibis: session restore is not a wayland specific problem. a restored app can be connected to many servers, not just wayland. e.g. an IRC app must reconnect to servers and rejoin channels exactly the same as it must reconnect to the display server and recreate windows
17:21mclasen: Reading the xdg-decoration spec, there seem to be copy-paste mistakes
17:21mclasen: "After requesting a decoration mode, the compositor will respond by emitting an xdg_surface.configure event. The client should then update its content, drawing it without decorations if the received mode is server-side decorations. "
17:21mclasen: that should probably xdg_toplevel_decoration.configure ?
17:22mclasen: since the xdg_surface.configure doesn't let you receive a mode
17:23mclasen: there's more like that. E.g. talk about configure_ack, when no such request exists in this protocol
17:26kennylevinsen: I believe the intention is that zxdg_toplevel_decoration_v1::configure is sent during a xdg_surface::configure sequence (which is acked), but the wording does leave something to be desired...
17:29emersion: xdg_toplevel_decoration.configure is always followed by xdg_surface.configure
17:29emersion: clients shouldn't do anything in response to xdg_toplevel_decoration.configure, except update their pending state
17:29emersion: specfcally, clients should redraw in response to xdg_surface.configure, not in response to xdg_toplevel_decoration.configure
17:49bwidawsk: Yeah, I think it would be good if the spec was more explicit that xdg_surface.configure is the ultimate configure event of all configure events. Before emersion et. al pointed out the intent I didn't find the current verbiage clear: "The configure event marks the end of a configure sequence. A configure sequence is a set of one or more events configuring the state of the xdg_surface, including the final xdg_surface.configure
17:49bwidawsk: event"
17:50bwidawsk: Now that the intent is clear however, the verbiage seems fine... so /shrug
18:08mclasen: if there was some conformance testsuite, maybe
18:11bwidawsk: well there is this: https://github.com/MirServer/wlcs/
18:12bwidawsk: and I'm working on one https://gitlab.freedesktop.org/bwidawsk/way-assay
18:17wlb: wayland-protocols Issue #177 closed \o/ (xdg_shell: xdg_positioner.set_constraint_adjustment does not specify bitflag enum type of `constraint_adjustment` argument https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/177)
18:17wlb: wayland-protocols Merge request !281 merged \o/ (xdg-shell: add missing enum attribute to set_constraint_adjustment https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/281)
18:17wlb: wayland-protocols/main: Sebastian Wick * xdg-shell: add missing enum attribute to set_constraint_adjustment https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/1c57b24ff867 stable/xdg-shell/xdg-shell.xml
18:40wlb: weston Issue #896 opened by Tomek Bury (tomek) The dmabuf stride has a defined meaning only for linear buffers https://gitlab.freedesktop.org/wayland/weston/-/issues/896
19:10wlb: weston Merge request !1481 opened by Tomek Bury (tomek) Check dmabuf stride only for linear buffres https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1481
20:41wlb: wayland-protocols Issue #187 opened by Beethoven (beethovenn) Gemini-PR or TX Bolt Stenography protocol support? Steno on Wayland? https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/187
21:48Nova[m]: <immibis> "session restore is not a wayland..." <- i agree, but idk where to put it more generally than an environment variable
22:04Nova[m]: i mean i guess d-bus activation could work but tbh that means *every app in existence* would need to use it
22:04Nova[m]: * use it ideally