01:58 kayve: hello I am having an authentication problem I'm hoping someone can help me with
01:58 kayve: is anyone here?
02:04 kayve: hello I'm having an authentication problem I'm hoping to get help with. Is anyone here?
02:24 soreau: kayve: usually on irc, you just ask your question and then wait to see if anyone responds with an answer
02:35 kayve: yeah but this place seems so dead lol
02:35 kayve: okie dokie
02:35 kayve: https://imgur.com/a/8DvZaT2
02:35 kayve: https://imgur.com/a/EQvtDwG
02:37 kayve: I created a tarball from a HostGator cPanel of a website called regalchess.com. I unzipped the tarball on my Ubuntu system that apparently runs Wayland. I un-tarred the files and re-tarred the files and my issue is seen in the videos on imgur
02:37 RAOF: That does not appear to be a Wayland problem; that's probably a file-permissions problem.
02:38 kayve: I am able to use command lines to work with the files but for looking at things like images this is less efficient.
02:38 kayve: the Wayland problem arises when I follow the directions for https://www.feys.be/2022/03/21/ubuntu-20-04-annoying-popup-authentication-is-required-to-run-gvfsd-admin-daemon/
02:39 kayve: I am unable to use the method of alt-F2 and the error cites Wayland
02:39 kayve: if you watch the video to the end you will see this
02:39 RAOF: Ah, right..
02:39 kayve: sudo failed to chmod 755 but I managed to chmod everything evidenced by ls -l using a direct root prompt
02:39 kayve: the problem of having to authenticate repeatedly remains
02:39 RAOF: That's still not actually a Wayland problem (it's a particular feature of GNOME Shell)
02:40 kayve: well can I at least get some run around advice to some other IRC channel then?
02:40 RAOF: And, indeed, you can't restart GNOME Shell without logging out (when using the Wayland session)
02:40 RAOF: #ubuntu is probably a good choice for Ubuntu support?
02:41 kayve: well I already went there but in my experience #ubuntu never elicits help
02:41 kayve: I was asking on #linux but I crashed my firefox and now that discussion died
02:41 kayve: noone knows what to tell me
02:41 kayve: they all run KDE or have other issues
02:42 RAOF: Well, I've never seen that problem before and I'm not sure what change to your system has caused it. Maybe try htttps://askubuntu.com?
02:44 kayve: I think I found a dead question there but OK I will post a new one
03:18 wlb: weston Merge request !1235 opened by Tomohito Esaki (etom) ivi-layout: add description for layer_add_surface https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1235
06:39 wlb: weston Merge request !1236 opened by sophia gong (sophia) new feature: add secure display wayland protocol implementation https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1236
08:16 Oro: !nick orowith2os
08:17 Oro: Mmmm
08:17 Oro: Oh hey it's working. Hi IRC users!
08:18 psykose: it does indeed work
08:18 Oro: Using this from the Matrix bridge :D
08:19 Oro: Didn't want to deal with IRC clients and allat
08:19 Oro: anyways
08:19 Oro: Wayland stuff
08:19 Oro: I had an idea for a new protocol, and I was wondering if anybody wanted to take a look at the idea before writing a protocol for it
08:20 Oro: I want to be able to easily overlay stuff on other Wayland windows (that aren't mine)
08:21 Oro: The best way I've thought of that so far is a protocol that takes the normal Wayland stuff and just overlays that onto another window, identified with a Wayland handle
08:21 vyivel: hm what's the use case?
08:21 Oro: How the clients communicate which handle to use is dealt with by them, for example with Steam it would probably force apps to do so via LD_PRELOAD
08:22 Oro: vyivel: The Steam Overlay, mainly
08:22 Oro: Currently it's very hacky and relies on LD_PRELOAD to modify EGL and related stuff iirc
08:22 Oro: Doesn't work on native Wayland clients
08:25 Oro: Some slight modifications might need to be made for Xwayland, or let Steam handle that otherwise, like most apps do for X
08:26 Oro: So native Wayland clients communicate to Steam through their preferred method, I'd imagine forced to do so via dbus and ld_preload, and Xwayland clients do so via the same methods but do X stuff instead to get the overlay going
08:27 Oro: Unless a Wayland handle can be returned for Xwayland too?
08:27 Oro: Might need some translation
08:27 Oro: X11:XID -> wayland:handle
08:28 drakulix[m]: I had proposed such a protocol in the past, I believe. Essentially what you are asking for is XEmbed like functionality (no matter if initiated by the client or the overlay) and the response was, that synchronization across clients is a very large can of worms nobody wants to open and to use an embedded compositor instead.
08:29 emersion: are there other use-cases apart from steam?
08:29 emersion: this has security implications btw, we can't let any client create overlays
08:29 Oro: drakulix[m]: Why would synchronization matter here? It would literally be a Wayland window on top of another Wayland window
08:29 drakulix[m]: Panels were my use-case. Our panel is now just a compositor itself.
08:29 emersion: Oro: then the user resizes the window...
08:30 Oro: emersion: Any client can create an overlay, but it can't just toss it on top of any client it likes
08:31 Oro: The information to do that would be communicated between those two processes via something like dbus
08:31 emersion: tbh, if you need LD_PRELOAD anyways, you can insert a sub-surface
08:31 Oro: emersion: Yeah, that was an issue I thought of too. Best I can think of is the overlay gets the resize info and resizes with it, with a slight delay. The overlay could tell the compositor some preference for where to be, maybe?
08:32 emersion: wayland aims to be frame-perfect
08:32 emersion: ie, no delays, no races
08:32 drakulix[m]: Oro: Right, my proposal was talking specifically about subsurfaces, which obviously could be synchronized to parent surfaces.
08:32 drakulix[m]: But even without that you get issues. Like when the overlayed window is resized, you certainly want a notification for that size change.
08:32 drakulix[m]: What if the new size is smaller than the overlay? Does the compositor wait for a new overlay commit?
08:32 Oro: emersion: LD_PRELOAD might not always work though, like in a sandbox
08:32 Oro: This would be more sandbox friendly
08:32 Oro: Because the processes can communicate through dbus too
08:33 Oro: Or their preferred IPC mechanism
08:33 emersion: this sounds like a pretty weak use-case to me fwiw
08:33 drakulix[m]: Then just build an embedded compositor, I guess? E.g. gamescope could just render the steam overlay itself conceptually. That is sandbox friendly.
08:33 Oro: What if you want to run a game in its own sandbox though?
08:34 Oro: Then there's no way to get LD_PRELOAD to work
08:34 drakulix[m]: Oro: you have to pass a wayland-socket anyway? I don’t think nested sandboxes are an issue here.
08:34 Oro: Or to launch the desired game in gamescope
08:34 Oro: drakulix[m]: I mean completely different sandboxes
08:35 drakulix[m]: you can also expose the wayland-socket from the embedded compositor to the host and pass it down the game sandbox.
08:35 Oro: A game doesn't have to be in the launcher's sandbox to have integration with the overlay
08:35 Oro: Is the idea here
08:35 Oro: And won't have to deal with hacks like LD_PRELOAD which are very inconsistent
08:36 Oro: I actually do have a game that runs separately from Steam: FFXIV. It has a third party launcher that runs in its own sandbox, and LD_PRELOAD hacks applied by Steam won't work at all here, as Steam could be in a sandbox too.
08:37 drakulix[m]: If you launcher (supposedly running in something like flatpak) wants to overlay with something launched outside its sandbox, it can spawn processes outside the sandbox anyway.
08:37 drakulix[m]: So it has some form of communication to outside the sandbox. That part could help to expose the wayland-socket as well.
08:37 drakulix[m]: Sounds more like a portal problem.
08:37 Oro: The communication outside the sandbox here would be dbus
08:37 Oro: Ideally
08:37 Oro: Since that's the most sandbox friendly solution
08:37 drakulix[m]: right, it needs cooperation with some process running without a sandbox, but it is certainly possible.
08:38 Oro: --talk-name=com.valvesoftware.Steam, games pass through their Wayland handles and Steam IDs, and Steam tosses an overlay into them using the protocol.
08:39 Oro: if a game needs to be forced to pass through the needed information, a simple LD_PRELOAD workaround could be build and applied in the appropriate sandbox
08:39 Oro: Thus, no missing file hell like before
08:39 drakulix[m]: You could pass a wayland-socket the same way.
08:40 Oro: Why start up another compositor just for one game though? Not everything would need or benefit from that
08:40 Oro: ideally it blends in more seamlessly than a nested compositor
08:41 drakulix[m]: But its not a huge overhead either. Its mostly passing through dmabufs anyway and provides a clear way to modify the rendered image.
08:41 Oro: Not fully seamless, like resizing delays, but better than nothing
08:41 Oro: drakulix[m]: What about desktop integration?
08:41 Oro: The nested compositor might not provide the features of the host compositor
08:41 drakulix[m]: A nested compositor could blend very well. It could even just pass through everything just inject another subsurface.
08:42 Oro: That still feels like a lot more work than just a simple protocol for tossing a wayland window on top of another
08:42 emersion: i really don't think such a protocol would be "simple"
08:43 drakulix[m]: Also you are talking about sandboxed clients anyway, they don’t need access to every protocol under the sun. In fact once something like the security-context protocol is happening, the protocol surface is expected to be restricted anyway.
08:43 drakulix[m]: So that is kinda non-issue.
08:43 emersion: the synchronization problem can't just be shrugged off
08:43 drakulix[m]: Oro: That was exactly my argument back then, I have been convinced otherwise since.
08:43 drakulix[m]: Maybe I should dig up that issue, maybe you want to give it a read?
08:43 Oro: There wouldn't be much to synchronize
08:44 Oro: Yes please
08:44 emersion: not much, ie. the whole overlay state really
08:45 Oro: Continuing on sync: the overlay could add some preference for where it should be placed on the window. In the unlikely event the window is moved while the overlay is open, it stays centered at the preferred area until it receives the hint to resize too
08:45 emersion: no, there must be a way to implement a frame-perfect overlay
08:45 drakulix[m]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/74
08:45 emersion: with the compositor waiting for both surfaces to resize before repainting
08:46 emersion: (both = game and overlay)
08:46 Oro: So, for example, an overlay showing the currently speaking users in a voice chat would stay at the preferred region of a window with little issue. Moving around is fine, resizing is mostly fine
08:46 Oro: Mmmm
08:47 emersion: the synchronization issues happen more often than one would think
08:47 Oro: emersion: Without the compositor syncing both clients automatically, there's not much that can be done. But imo this is still way better than anything a nested compositor can do.
08:47 drakulix[m]: Also overlays like voice chat could just be layer-shell overlay surfaces?
08:47 drakulix[m]: If you want to hide those, if no game is visible, ext-foreign-toplevel could expose enough information.
08:48 emersion: also, keep in mind your protocol would require buy-in from steam and all compositors
08:49 Oro: I have no doubt Steam would like this very much, especially because they're suffering from lack of Wayland support. This would make it easier to do.
08:50 Oro: Compositors, that's another problem. Would help to get a dev from each to toss their thoughts into the ring on how it could be done.
08:51 Oro: Actually, going back to resizing, is there too much delay between sending two resize events to two clients and waiting for them both to resize before putting it onscreen?
08:51 drakulix[m]: Steam could just modify gamescope to do what they need for games. Or do another vulkan-layer hack and inject another subsurface from... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/utntmeezovwAigZpxZdxZkCP>)
08:51 emersion: your message got cut off
08:51 Oro: If the overlay dies no worries, and if it's not dead then it shouldn't be too hard to resize both within a reasonable timeframe
08:52 davidre: OOI are you working on Steam or is it an example to illustrate things? If the latter what's the use-case/problem you are interested in?
08:53 Oro: I want to have an overlay protocol for any potential use cases and maybe some I have in the future too. I'd like to rope Steam in when a protocol is actually submitted
08:53 d_ed[m]: We've definitely seen issues with Orca, a screen reader which on X11 shows highlight boxes of entries as a floating window above another window.
08:53 d_ed[m]: (or on wayland, randomly on the screen)
08:54 d_ed[m]: Dallas Strouse (Oro, any/all): I would strongly suggest collecting the use cases first, rather than starting with a proposal for potential users
08:54 davidre: I fear that's the wrong way around to go about this, creating a new protocol in case somebody might have a use-case in the future
08:55 psykose: the use case is already presented though
08:56 pq: Concrete use cases help move discussions forward, hand-waving just gets stuck in circles forever. To get attention, I guess a new issue in wayland-protocols would be fine to collect the discussion.
08:56 Oro: davidre: I know someone has a use case already, that would be Steam, but there are many potential users too, all of which are more or less the same or simple to implement
08:57 zamundaaa[m]: I can think of at least four other use cases
08:57 d_ed[m]: yeah, I'm not opposed to such a protocol
08:57 emersion: what are these?
08:57 Oro: Want me to pull up a document to keep track of everything?
08:59 davidre: Oro: You dont know if they would use it
08:59 davidre: maybe they are happy with their current approach?
09:00 Oro: Staying on Xorg?
09:01 Oro: Anyways here are three use cases I have so far:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/kbRILaLwrpNACmQRgkINoaif>)
09:01 MrCooper: for the Steam overlay, seems like a sub-surface should do, either directly or via a nested compositor
09:01 Oro: The steam overlay should be doable via an overlay protocol too though
09:02 zamundaaa[m]: emersion: Game performance overlays like Mangohud, Streaming overlays like in Zoom (for painting on top of the window), recording overlays like in OBS (that shows keypresses and stuff), community tools for games (don't remember which game had that exactly, can look it up later)
09:02 Oro: Then it's just figuring out how to sync the two windows
09:02 d_ed[m]: What's "User voice activity box (Discord)"?
09:02 MrCooper: any use case could be covered by a bespoke protocol for it, doesn't mean it's a good idea
09:03 Oro: d_ed[m]: On Windows, some games have Discord integration that will allow Discord to put a transparent box at the corner of the game window with some user profiles and names. If the user is talking, their profile picture lights up green.
09:03 davidre: If we want to support Steam with such an procotol we should know their actual requirements, instead of designing an overlay protocol that could or could not work for them
09:03 emersion: that discord thing is completely inside the client iirc
09:03 emersion: no need for an external overlay
09:04 Oro: Discord getting their user overlay info onto a game window?
09:04 Oro: That definitely sounds like it needs an external overlay
09:04 emersion: the game can just use libdiscord and let that paint a sub-surface
09:04 Oro: Wouldn't that need the game to know how to handle that though?
09:05 emersion: no
09:05 emersion: the OBS keypress overlay, isn't that on the whole screen, not tied to a specific window?
09:05 zamundaaa[m]: emersion: not if you're recording a window
09:05 Oro: That's something slightly different. This is focused on overlaying on top of individual windows, not everything
09:06 Oro: Doing everything would probably need a protocol like wlroots has right now
09:07 d_ed[m]: Oro: so is that more like a picture-in-picture type floating overlay generically on the screen rather than related to another window?
09:08 Oro: d_ed[m]: More or less. You do want the floating overlay to move with and be on top of a specific window though
09:09 Oro: It's not too bad to have it lag behind when resizing and moving around
09:09 Oro: Not ideal, but not bad
09:09 Oro: I don't believe my question earlier was answered, how easy would synchronization be?
09:10 Oro: Can't you wait for both windows to say they're ready to be displayed during a resize?
09:10 d_ed[m]: not trivially
09:11 Oro: Hmmm, what about if you downscaled the overlay?
09:11 Oro: Render at a slightly bigger size than needed, at this size it's not an issue, and just downscale that
09:12 Oro: I don't believe many games allow arbitrary sizes, so this could work
09:12 Oro: You'd just need a way for the compositor to know that information
09:13 Oro: For arbitrary sizes, wait for the overlay to give the okay
09:14 Oro: Then it's just a matter of does the overlay respond fast enough?
09:15 Oro: I believe that's similar to how a nested compositor would work
09:15 d_ed[m]: yeah, it's not trivial in a nested compositor either
09:15 Oro: If the compositor can't resize, the application won't either
09:15 Oro: Except in this case, if the overlay dies, we don't have to wait on it
09:15 Oro: And nothing completely breaks
09:16 Oro: If the process that handles the overlay gets killed, we just.... Stop overlaying it
09:16 Oro: Or if it hangs and doesn't respond
09:17 Oro: So, for resizing: why not try and apply the nested compositor logic? It's similar enough here, and it's an alternative solution (albeit maybe a worse one)
09:19 Oro: Wait for the overlay to resize if it's up, and if not, don't block on it
09:20 Oro: This might actually be slightly better than a nested compositor because then both windows can resize individually, with a nested compositor you wait for one to send the signal to the other
09:21 Oro: s/other/application /
09:28 Oro: Then you wait for the application to resize, the compositor, and the host gets the signal to resize and recomposite
09:29 Oro: With an overlay, both can resize at the same time and say they're ready in less time
09:30 Oro: If the overlay is up, the compositor would block on the overlay
09:43 drakulix[m]: Just forcing the latest overlay's buffer into a the same relative space of the overlays window by applying scaling is still against wayland's "every frame is perfect" philosophy. Essentially you would need to document inside the protocol, that your surface might be rescaled in completely unpredictable ways.
09:43 kennylevinsen: Oro: have you looked at xdg-foreign? That allows you to make your own window a child of another, and if you give it a null input region it'll be input transparent.
09:44 kennylevinsen: but it requires some initial cooperation, and of course means that composition will might be required as multiple surfaces are present
09:45 Oro: The hope is to require very little implementation for the overlayed game/app
09:45 Oro: If it absolutely refuses to implement it, an LD_PRELOAD hack can be done. If it cooperates, it'll communicate the handle for the overlay in the overlay's preferred fashion
09:46 kennylevinsen: Some compositors also have protocols for "desktop environment" level surfaces like bars, notification panels and launchers which can float over other things (wlr-layer-shell). That can give you a desktop-wide overlay, which might be useful enoufh
09:46 emersion: i don't think that's a good goal. any impl can be put into a library
09:46 kennylevinsen: A protocol to force an overlay on something else is unlikely to be accepted as it would be an obvious protocol for clickjacking/phishing/others
09:47 drakulix[m]: xdg-foreign also doesn't allow you to pick, where you window is positioned relative to the parent window. So it is not really a solution here.
09:47 kennylevinsen: that isn't necessarily a requirement
09:47 drakulix[m]: Though I personally think the discord or zoom use-case is covered by layer-shell pretty well.
09:47 kennylevinsen: Can just have the user put it where they want - might be better than a rigidly positioned overlay tbh
09:48 Oro: Desktop-wide overlays might want a protocol like wlroots has, not this one.
09:48 Oro: Also, this is for application-specific overlays like Steam, the user shouldn't put it where they want
09:48 Oro: The overlay should be over the game or app window and only that
09:48 kennylevinsen: that's sort of statement always needs to be challenged
09:49 Oro: Trying to move it, like a screen reader overlay, will not be fun
09:49 kennylevinsen: I.e. I might disagree with where the overlay went as a user. Top right? Maybe it blocks something and I want it bottom left.
09:49 Oro: The overlay should have some preferences for that then
09:49 kennylevinsen: Maybe all corners have important stuff and I want it a bit in
09:50 kennylevinsen: Forcing positioning should always be last resort where there is no alternative, and "we did it like this before" is not a reason :)
09:50 drakulix[m]: Also I don't think games are a good use-case either. Given these overlays are likely supposed to work over a range of different operating systems anyway, something that works on the GL/Vulkan API layer (like vulkan layers, which steam is already using anyway) is a much easier solution.
09:51 drakulix[m]: Which leaves the screen-reader use-case, which is a very legitimate problem, but also a much more isolated one, which might not need such a very broadly applicable protocol.
09:51 Oro: Maybe the protocol should have a way to say "hey, I'm fine with being in a different position, feel free to move me" so it doesn't break things that shouldn't be moved
09:52 kennylevinsen: I don't see an argument for not always allowing movement yet
09:52 Oro: Screen reader highlights
09:52 Oro: Mainly things that are closely tied to application content placement
09:52 kennylevinsen: screen readers cannot see content of a window without integration
09:53 kennylevinsen: So that might take something else anyway
09:53 kennylevinsen: Unless you screen record and OCR everything, in which case please don't :/
09:53 Oro: Yes, they'd provide that information through the a11y interfaces; but to get the screen reader overlay on the app, it could use this protocol
09:53 drakulix[m]: Screen-readers are a specific use-case. That is just like the same discussion about "wayland doesn't let me arbitrarily position my window". It doesn't do that for good reason and applications still manage to work in those constrains. If a specific use-case comes up a protocol is designed for that use-case alone, not for a dozen hypothetical ones.
09:54 kennylevinsen: The a11y use case could be covered through something similar to the IME protocols
09:54 pq: I get the feeling there are too many somewhat different use cases being shoved into a single extension that it falls apart in both design and discussion. :-)
09:54 kennylevinsen: Indeed :)
09:54 pq: like having decided on a solution and then looking for problems to fit
09:55 kennylevinsen: start with a specific problem to solve and let us find the best solution for that, and then one can consider making it generic enough to cover other issues as well
09:56 kennylevinsen: don't start from an overly generic solution - especially something as powerful as arbitrary window hijacking
09:56 Oro: Going with screen readers first: it should probably allow it to be precisely on the window, so any highlights don't break
09:56 Oro: For it to obtain the information to draw that overlay to the app, it provides the Wayland handle via a11y
09:57 kennylevinsen: Look at the IME protocols, they provide very specific positioning (i.e. adjacent to text input fields) without giving away unnecessary control
09:57 Oro: How would the screen reader put the highlights over the app?
09:57 pq: Why would the application not highlight itself the parts it gives to screenreader to read out loud? Does it not work like that?
09:58 kennylevinsen: Oro: as I said, look at the IME protocols, they solve "how does an IME put word suggestions and completions over the app"
09:58 Oro: You get into some very annoying inconsistencies there
09:58 kennylevinsen: similar problem, so we might be looking at a similar solution
10:00 Oro: IME seems to only be for text-based input
10:00 Oro: If I understand it correctly, it doesn't do things like app widget positioning
10:01 pq: "application" also includes any (standard?) a11y libraries it might be using in order to connect to a11y services, the highlight does not need to be application-invented. Or is that infrastructure just not there today, and the highlight must be done in a different process for infrastructure reasons?
10:01 kennylevinsen: it accurately places the IME surface in the correct position for the text input
10:02 Oro: Do you have anything I can look at for how it handles that?
10:02 Oro: https://wayland.app/protocols/text-input-unstable-v3, maybe?
10:04 kennylevinsen: https://wayland.app/protocols/input-method-unstable-v1#zwp_input_panel_v1
10:06 Oro: <pq> ""application" also includes any..." <- Honestly, I'm not all that sure on the current state of a11y infra right now. It seems to be in a very sorry state. I do know TalkBack on Android has them though, I just need to find the technical details.
10:07 pq: Would be good to know that before suggesting they should use a specific protocol. :-)
10:09 Oro: > <@d_ed:kde.org> We've definitely seen issues with Orca, a screen reader which on X11 shows highlight boxes of entries as a floating window above another window.... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/QmmIIpvXBACdffaUIyLRPWHS>)
10:09 Oro: * On the Matrix side here's a reply, @d_ed mentioned highlights so maybe the APIs are there.
10:09 Oro: You'll probably know more on this
10:10 kennylevinsen: Yeah it's plausible that there is a need for improvements in a11y, but we should take a step back and understand a11y first
10:11 kennylevinsen: you started with a steam overlay issue, which is something quite orthogonal to screen readers
10:12 Oro: Yes, then screen readers were mentioned, and some other small use cases
10:12 Oro: And then it all got to be a mess
10:12 Oro: For a11y, it sounds like it provides the needed info already, just no way to properly utilize it on Wayland
10:13 Oro: @d_ed can you confirm?
10:15 d_ed[m]: I meant accerciser not orca; we get relative positions of textboxes and such sent over DBus
10:15 d_ed[m]: and we get sent what the client thinks is the window position
10:18 Oro: d_ed[m]: And you can apply highlights over the positions you're given?
10:19 Oro: At least on X
10:41 Oro: Bleh, continuing on
10:41 Oro: The information is there
10:41 Oro: But not all screen readers or environments will utilize it in the same way
10:42 Oro: A simple box drawn by an application might not be desired unless it's heavily customizable, such as for contrast. It's probably easier to let a screen reader to overlay its own box on top
10:43 Oro: It could do that by tightly integrating with the DE, but a simple Wayland protocol that will work on all environments will be even better as it's way less work done
10:44 kennylevinsen: any protocol that gives you a surface will allow the client to show whatever content with whatever contrast
10:44 kennylevinsen: say, a protocol where a surface could be placed on a "token", could do that
10:45 kennylevinsen: a generic window hijack protocol would be simpler to define, and cover many things, but would be a much bigger discussion due to the high risk
10:45 kennylevinsen: definitely needs to be a highly privileged protocol
10:45 Berty: Guys, what's the deal with Nvidia? I have been using Qtile for almost an year now, but as soon as I switch to Wayland, it starts to misbehave. Last week only, I tried building Hyprland, but wasn't successful.
10:45 Oro: That only matters if the protocol can scan for arbitrary windows though, right?
10:46 kennylevinsen: (but a generic protocol would have significant synchronization issues, so it would likely not be glitch free)
10:46 Oro: If the protocol just accepts something like a Wayland handle, without specifying how the client obtains it, the client can get it though more secure methods
10:46 Oro: Like directly from the app in a11y
10:46 kennylevinsen: yeah if the original client "hands off" permission, taht would be better
10:47 kennylevinsen: but if content moves (reflow, resize), it would be hard to synchronize
10:47 Oro: For this protocol, we get the handle through a11y and the screen reader draws the desired contents on top of the app via the overlay
10:48 kennylevinsen: if the protocol instead specified anchors that the original client moved with content, that issue would go away
10:48 kennylevinsen: e.g., each word being a token/anchor
10:48 Oro: That would probably increase complexity vs just blocking on the overlay size though, right?
10:48 Oro: s/size/resize/
10:49 kennylevinsen: I imagine it would be less complexity than synchronizing surfaces from two clients in a non-glitchy manner
10:50 Oro: If the main window gets told to resize when the overlay does though, and it's only done when both say they're ready, wouldn't that work?
10:51 Oro: So the app says it's done resizing, blocked on the overlay. Overlay relies on the app to resize to a position before resizing
10:51 kennylevinsen: any buffer commit can be a resize, and words can reflow without resize (e.g., dynamic content)
10:51 Oro: Or both resize at the same time and the result is displayed when both say they're done
10:52 Oro: Then it's expected that the information would be sent through a11y and the overlay would update on that
10:53 kennylevinsen: that won't work, the buffer is already committed
10:53 Oro: At least on Android, it seems TalkBack will lag just slightly behind the app
10:53 Oro: Assuming you're doing something like scrolling
10:53 Oro: (just tested)
10:54 Oro: So the overlay would always be just slightly older than the apl
10:54 kennylevinsen: if we're going out of our way to make a protocol, wouldn't it be best to solve that? :)
10:54 Oro: s/apl/aplapp/
10:54 Oro: s/apl/app/
10:54 kennylevinsen: with an anchor approach (similar in nature to the input-method protocol), the compositor can keep the content aligned
10:55 kennylevinsen: every frame perfect
10:55 Oro: kennylevinsen: Well, we could block the result being displayed on the overlay being done, but it's not such a large issue that it should be considered imo
10:56 pq: The overlay can commit on its own volition, so the compositor could mistake an overlay commit to match a resize of the window.
10:56 Oro: And what if the a11y content changes, like box sizes? An anchor wouldn't be frame perfect either
10:56 Oro: Oro: (or afaiu)
10:57 Oro: pq: That shouldn't happen in the first place though
10:57 pq: why not?
10:57 Oro: They should only resize both
10:57 pq: cannot the overlay have animations?
10:58 pq: who's to say the overlay must change size to match a window resize?
10:58 Oro: The overlay would be tied to the app window in window size and everything. So a resize of the overlay should make the window resize too.
10:58 kennylevinsen: having every frame be perfect (by policy, not happenstance) is sort of the whole idea with wayland - so "content is not synchronized at all" seems like a pretty big issue to me
10:59 Oro: There are two solutions here: you're either just slightly behind, which is quite frankly not a large issue, or you need both overlay and app to update before pushing a new frame
10:59 kennylevinsen: and a mechanism to tie the two updates together
11:00 Oro: You'd send the same resize events to the overlay as you would the window, and when both are done, you push the new frame
11:00 Oro: Sounds simple enough
11:00 kennylevinsen: resize isn't an event
11:00 Oro: If ones not done, don't push a new frame
11:00 kennylevinsen: resize is what happens when a client commits a buffer of a different size than the previous one
11:00 kennylevinsen: can happen on any frame
11:00 kennylevinsen: and content can move without the window
11:01 kennylevinsen: scroll being your own example
11:01 Oro: In that case, you compare the size of one to the other, or add some way for a normal client in Wayland (not an overlay) to always specify its size
11:01 Oro: Comparing the two sizes should work here without being too bad
11:01 drakulix[m]: It does sound simple enough, in practice you make synchronization the issue of the compositor. and you simplify because you are only looking at resizing, while I bet there are far more nuanced interactions here, that are problematic.
11:02 kennylevinsen: size isn't an indicator for content
11:02 Oro: The content is not something we can or probably should be handling
11:02 drakulix[m]: Like this isn't an easy problem, just because the solution "sounds simple enough".
11:02 kennylevinsen: speaking from experience in sway's window transaction system, which uses size as a fallback for X11 windows when updating tiling layout
11:02 kennylevinsen: it's bad
11:03 kennylevinsen: any synchronization should be on a serial, token, whatever - an explicit thing where you can say "the overlay has ack'd content Y, so all is good"
11:03 drakulix[m]: Speaking from the transaction logic in smithay: yeah, it really is
11:04 pq: Content and size are inseparable, like is other window state. They all form a single atomic unit that must not be broken.
11:04 drakulix[m]: kennylevinsen: At that point you could just send every new frame to the overlay client and let it commit in place of the original surface. If the overlay has to ack all content anyway, we could basically treat the overlays commits as commits for the original window.
11:04 Oro: kennylevinsen: That sounds better, rather than letting the compositor handle it. When the app sends some new stuff over, the overlay has to put it out (where it makes sure it's up to date) and acks it
11:05 Oro: Or that?
11:05 Oro: Honestly I don't like the idea of the two being tied together like that
11:05 drakulix[m]: That is not a good solution either, because you can't serialize "all information relevant for a commit", because every new protocol can extend that state.
11:06 pq: The window and overlay contents are inherently connected, because the whole premise is that you want them to be coherent with each other.
11:06 drakulix[m]: E.g. your resizing logic gets much more complex as soon as you take wp_viewporter into account for example. And that is not just one new challenge to overcome. Every protocol adds state, that might be potentially relevant here.
11:06 kennylevinsen: and you wouldn't want to do this for every commit, only every commit with relevant changes...
11:06 kennylevinsen: and then we get back to having something like explicit tokens/anchors/boxes to update
11:07 Oro: drakulix[m]: So it's just simpler to do as you suggested and have the overlay handle committing it?
11:07 Oro: Better than the idea I was stuck on of having the two separate
11:07 kennylevinsen: the overlay cannot commit the original window state
11:08 kennylevinsen: I mean, the overlay "client" could be a full compositor proxy thingie wrapping stuff, but... That seems like an "interesting" solution :P
11:08 drakulix[m]: Oro: No, because the original commit would still be received by the compositor and needs to be send to the overlay. The overlay needs to know about viewporter (and every other protocol involved here).
11:08 drakulix[m]: Acking commits of the parent surface in the overlay is a more reasonable solution. But that is also just "cross-client synchronization".
11:10 drakulix[m]: Let me rephrase Dallas Strouse (Oro, any/all). I see no solution to this problem, that isn't either:
11:10 drakulix[m]: - cross-client synchronization, which so far has been a huge NACK from compositor developers.
11:10 drakulix[m]: - or solving the problem completely on the client-side, e.g. with a nested compositor, some wrapper, vulkan-layer, LD_PRELOAD-hack, you name it.
11:10 drakulix[m]: - (Or ignoring synchronization, which isn't flying with wayland's principles.)
11:11 Oro: And I'm strongly against handling it client-side with things like a nested compositor
11:11 Oro: For reasons stated before, they feel too icky
11:13 Oro: If I understand how subsurfaces work, they wouldn't be useful here, since an overlay needs to be applied at any time
11:13 Oro: Not when the app starts up
11:14 kennylevinsen: (note that a nested compositor moves it outside the target client - the nested compositor is the screen reader - but ickiness factor is still there)
11:15 drakulix[m]: No matter the type of surface, what you want to do then, is convincing compositor devs, that synchronization across clients, is the better solution. And "being" icky for a solution that is deployed and working for most users, is a weak use-case.
11:15 kennylevinsen: it would definitely be a good idea to have a good understanding of the various surface roles/shells, and the various synchronization issues we have already dealt with
11:15 Oro: I honestly don't see much bad with this:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/WLFPRBCFtAnBYxrgikunyJcQ>)
11:15 kennylevinsen: even subsurface synchronization within the same client can be a pain!
11:15 drakulix[m]: > <@orowith2os:tchncs.de> I honestly don't see much bad with this:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/XghuvsxZYUPxuSkSNxSJHzeR>)
11:16 kennylevinsen: can we not talk in matrix.org pastebin links please
11:16 Oro: (trying)
11:17 drakulix[m]: (sorry, to used to matrix reply feature, will try my best)
11:17 Oro: I would love to implemented it, but I probably can't do much outside of the sync part itself
11:17 kennylevinsen: one line messages :)
11:17 Oro: s/implemented/implement/
11:17 Oro: So give me an implementation that handles the overlay like I want, a handle that the overlay can use to draw on top of with another surface, and I can sync em together
11:19 Oro: And that would be the screen reader case done: just arbitrary content that the overlay has to ack before it's ever put on screen. Unless the app lies about where the content is, should be no issues with frame perfectness
11:20 Oro: And apps lying is not a good thing for a11y anyways
11:20 drakulix[m]: Honestly, I envy your drive to just tackle this, but multiple people with good understanding of different compositor code bases, are telling you, that it is not that easy.
11:20 pq: Pass libwayland objects and a11y metadata to a library, let it create any sub-surfaces it wants, and coordinate with surface commits to achieve atomic presentation. That's not different from any other library that wants to employ a sub-surface, say, a video player library. Keep everything under the same Wayland connection, so ordering can be guaranteed without compositor help. Might be totally not what
11:20 pq: existing a11y/whatever infra expects.
11:21 drakulix[m]: And they need to review, maintain and work with that. Even if I could build a prototype of that in day, I wouldn't want to maintain it, given all the pitfalls.
11:22 drakulix[m]: Right for the a11y use-case, you require client cooperation anyway in the first place. There is no reason that same client couldn't commit the screen reader overlays.
11:23 Oro: Wouldn't that client need to have the overlays in the surface as well, though?
11:23 pq: "overlays in the surface"?
11:23 Oro: Highlighting drawn inside of the app window
11:23 Oro: If those terms are correct
11:24 Oro: And that's an issue because then youd have dozens of different highlights drawn by different toolkits
11:24 pq: overlay is an overlay, a sub-surface, not painted into the original wl_surface
11:25 Oro: Hmmm, could you toss a subsurface into a client at runtime, after the original surface is done and made? You'd also need it able to handle applying that subsurface
11:25 Oro: (done and made being the app is already in use)
11:25 pq: what do you mean "toss"?
11:26 Oro: Apply any highlighting and everything from the subsurface into the main surface
11:26 pq: By sub-surface we mean wl_subsurface protocol object, in case that wasn't clear.
11:26 Company: question: does Wayland have an env var or something to downgrade versions of globals for testing?
11:27 emersion: Company: nope
11:27 kennylevinsen: Oro: subsurface is a specific surface role, any new protocol would introduce a new role with the relevant functionality
11:27 pq: Company, no. But middle-man debuggers might?
11:27 Company: I might just add one to GTK
11:27 kennylevinsen: but as mentioned, the input-method protocol allows a separate IME client to attach a surface windows with text fields
11:28 Oro: Just text fields aren't suitable here
11:28 kennylevinsen: so you can think of it like a "sub-surface" just not wl_subsurface
11:28 Oro: So this would be more expanding on that
11:28 kennylevinsen: the point of reference to that protocol is not to imply that it you're dealing with text fields, just to note how protocols allow foreign surfaces
11:28 Oro: Reading some stuff on wl_subsurface again, definitely sounds like what's desired here
11:29 kennylevinsen: subsurface would not apply, but like with input-method you can make a role that has the behavior you need
11:29 Oro: Going back to wl_subsurface though, apparently it will work, clients just need to use them
11:30 Oro: And that's where it gets nasty on that end, I believe
11:31 Oro: Unless the compositor can handle that?
11:31 kennylevinsen: subsurface will only ever allow a client to put content within their own surfaces - you need a new role for clients to place surfaces on a foreign surface
11:31 pq: My main point though is to completely give up the notion of multiple Wayland clients, and do everything though the original Wayland connection opened by the application. Then the compositor does not need to handle anything new.
11:32 kennylevinsen: pq: yeah an a11y library would be easier
11:32 pq: *through
11:33 kennylevinsen: but then it wouldn't even strictly speaking need to know about wayland, the application could render the returned content itself
11:33 Oro: Mmmm, alright, I'll mark it off
11:33 Oro: Should we get into things like game overlays?
11:33 pq: kennylevinsen, indeed, you could trade off Wayland to some buffer passing API or drawing API.
11:34 Oro: The steam overlay works by injecting itself into arbitrary windows (that had LD_PRELOAD hacks) and managing that
11:35 Oro: The point here is that games don't need to opt in to the overlay
11:36 drakulix[m]: I don't think it does? It just uses a vulkan-layer, no?
11:36 Oro: Or EGL, yes
11:36 pq: Given the premise of the Steam overlay is to work on non-cooperating applications that cannot be modified, the use case is fundamentally different.
11:36 Oro: But not all apps will work with this
11:37 Oro: The steam overlay doesn't work on native Wayland games, for some reason or another
11:37 Oro: That appears to need a fix on their end
11:37 kennylevinsen: "mess with content of an arbitrary window without its involvement" is a bit of a red flag for a protocol though. If implemented, it would have to be considered a privileged protocol that clients generally are not allowed to use - like wlr-layer-shell is meant for desktop environment widgets, not apps.
11:37 Oro: It's not exactly without involvement
11:38 Oro: The app being modified still has to provide its handle somehow
11:38 drakulix[m]: But that is an issue with their vulkan layer. In theory every vulkan-layer can work with every windowing system. It wouldn't surprise me, if they use the same layer for windows. The issue is more likely that almost nobody is shipping wayland-only games.
11:38 Oro: (except SDL games)
11:38 kennylevinsen: right but you said "don't need to opt in" though
11:38 Oro: Assuming they're using the same LD_PRELOAD hacks mentioned before
11:39 drakulix[m]: Steam can't and won't modify decade old games.
11:39 Oro: The difference is the overlay is applied through the Wayland protocol
11:39 Oro: And they usually don't need to
11:39 Oro: Eventually, one way or another, they'll run on Wayland
11:39 pq: I see no reason why one could not use the same hook-up points and just create wl_subsurfaces, like one hooks up on X11. Maybe there is something about event delivery having surprising wl_surface arguments the game does not expect?
11:39 Oro: Be it SDL or a nested compositor
11:39 drakulix[m]: If the client has to opt-in, you have to make the game send that opt-in command, no?
11:40 Oro: That's the point of LD_PRELOAD
11:40 Oro: Steam gets sent the Wayland handles of the game
11:40 drakulix[m]: If you don't get rid of LD_PRELOAD, how is the solution better using the wayland-protocol than the status quo.
11:40 Oro: This could be applied to any other protocol or application type, but the main use case is games
11:41 Oro: Because you dont have to modify EGL and use Vulkan layers and other potentially nasty hacks
11:41 Oro: It doesn't seem to be very well designed to get it onto the window right now
11:41 drakulix[m]: vulkan layers are no nasty hacks.
11:41 drakulix[m]: They are part of the vulkan-spec.
11:42 kennylevinsen: to clarify, you don't need to just read a handle, the LD_PRELOAD will need to hijack the wayland display to chat with the compositor and create said handles
11:42 Oro: Referring to the layer itself
11:42 kennylevinsen: so that would be a hack iself
11:42 drakulix[m]: If their layer is bad code, you don't work around that by inventing a new convoluted protocol. You tell them to fix their vulkan-layer.
11:42 kennylevinsen: at least while using LD_PRELOAD - more so than a vulkan layer - although it could be clean without
11:43 Oro: Fair enough
11:43 Oro: But what if you want an overlay outside of a game?
11:43 drakulix[m]: (Big if I don't know their overlay code. I would assume it doesn't work on wayland, because its not a high priority.)
11:43 drakulix[m]: Like for example?
11:43 Oro: Think system monitors
11:44 Oro: I could bind an overlay to a keyboard shortcut to pull up my system information and current info
11:44 kennylevinsen: don't search for problems fitting the solution
11:44 drakulix[m]: layer-shell.
11:44 Oro: s/information and current info/infoinformation/
11:44 Oro: drakulix[m]: And to include application-specific content there too?
11:44 Oro: Like an fps counter
11:45 pq: Compositors can have an UI to designate arbitrary windows on a "overlay window stacking plane". There is no need for protocol to do that.
11:45 drakulix[m]: FPS counters can be overlayed via layer-shell just the same. Where you get the information from is another question.
11:47 Oro: Layer shell can limit an overlay to a specific window?
11:48 drakulix[m]: no. if you are talking windowed games, I would say vulkan-layers like MangoHUD are a good solution.
11:49 kennylevinsen: attaching to a specific window is also only visually different if the window is occluded
11:50 Oro: Wayland feels like a much better place to handle overlays, with the information being handled outside of it
11:50 pq: The cleanest generic design to handle the Steam overlay case really seems to boil down to an intermediate compositor between the app and the host compositor. It has a bit of overhead, but it's a very simple design with no new protocol needed.
11:51 kennylevinsen: *cough* gamescope *cough*
11:51 pq: mmhm
11:51 Oro: Ideally, an intermediate compositor would perfectly blend in with the host save for the addons
11:51 Oro: Is that possible at all?
11:52 kennylevinsen: the imtermediate compositor will be a window just like the original, and can do whatever it would like to the game - including direct pass-through
11:52 kennylevinsen: it's what gamescope does
11:52 pq: what does "blend in" mean?
11:52 Oro: Make it look like the app is running as it would normally
11:52 Oro: No windoe decorations like gamescope hsd
11:52 pq: that's easy like kennylevinsen said: just pass through
11:53 Oro: Wouldn't you need to implement all of the protocols there too though? Or could you put a shim between the one you want and pass everything else though?
11:54 drakulix[m]: gamescope has decoration, because it just creates an SDLWindow and leaves it at that. There is nothing passed through like decoration-state of the internal window, etc. You can achieve all of that.
11:54 pq: one may need pass-through code for all protocol interface, but that could probably be automated - we have XML to describe all messages
11:54 drakulix[m]: You could probably also build a compositor, which just proxies through messages and only intercepts e.g. client buffers to draw an overlay on top.
11:54 drakulix[m]: Then you don't need to understand every protocol under the sun.
11:55 kennylevinsen: you probably wouldn't draw on top of them, just attach a subsurface on the way out
11:55 drakulix[m]: That said I doubt games will use more than a couple of well-known protocols.
11:55 pq: we also have pass-through examples in protocol dumpers: https://wayland.freedesktop.org/extras.html
11:57 Oro: So I guess the goal from here would be making a really small and really efficient Wayland compositor that applies the overlay
11:58 pq: It does not even need to apply an overlay, just make another wl_surface sub-surface for it, while passing all other messages through.
11:58 Oro: kennylevinsen I thought Wayland clients had to know how to handle subsurfaces in order to use them at all?
11:58 pq: the game would never know a sub-surface even exists
11:59 davidre: luckily valve has their own compositor already
11:59 kennylevinsen: Oro: From the parent compositor perspective, the nested compositor is the client with a surface containining the game. It can use subsurfaces there.
11:59 kennylevinsen: the game will only have its own main surface and never know about the subsurface
11:59 Oro: oh
12:00 kennylevinsen: (because what happens between host compositor and nested compositor, and what happens between nested compositor and game is completely distinct - the nested compositor would just use the game buffers)
12:00 kennylevinsen: and indeed - that's gamescope
12:01 drakulix[m]: If you have problems with gamescope - like decorations - I would rather suggest to just open issues and contribute to gamescope to fix these.
12:01 Oro: Will do
12:01 pq: The middle-man compositor cannot blindly pass messages through, it needs to translate object ids and filter out the messages not meant for the game, so that kind of overhead exists.
12:05 Oro: Oh, I guess a nested compositor like this could work for several clients too, right?
12:06 Oro: So, I could run a steam game and a non steam game in the same nested compositor and have the overlay on both
12:06 Oro: The compositor just needs to know how to make those two games separate windows
12:06 Oro: (gamescope right now only does one)
12:06 kennylevinsen: if you wanted to, but it doesn't need to
12:07 pq: yeah, it could, but if you want them separate, then why not run separate nested compositor instances?
12:07 drakulix[m]: If you wanted to avoid spawning multiple compositors (though there is no real harm in doing that), you could.
12:07 Oro: Alright, I just didn't want there to have to be one different socket for each game
12:08 pq: I'm not actually sure what would be simpler as the nested compositor implemententation in the end, if one would not want to assume a game has only one window at a time.
12:08 pq: Oro, why would a different socket be bad?
12:09 Oro: A different Wayland socket for each game feels unnecessary, since you could probably just reuse what already exists for the first one
12:09 drakulix[m]: If all you want to avoid is sockets cluttering up XDG_RUNTIME_DIR, you can use WAYLAND_SOCKET and just pass the file descriptor directly to the spawned client.
12:09 pq: you'd never configure a socket manually anyway
12:12 pq: a socket per game might even be useful, in case the game has multiple programs each connecting to Wayland either in turn or simultaneously
12:13 emersion: fwiw gamescope supports multiple Xwaylands
12:13 pq: cool
12:15 Oro: The intent here is just to get an overlay going, one extra Wayland socket (and compositor running) for that should be enough
12:15 Oro: Even for multiple games
12:15 pq: a socket per game is really no cost
12:17 pq: compositor instances cost some, but not much - at least they shouldn't as long as the overlay is hidden
12:28 akik: hi, how do i see if a program is wayland-only like the foot terminal emulator?
12:30 pq: hmm... set WAYLAND_DISPLAY environment variable to nonsense, and see if the program fails to run?
12:30 Oro: xprop, xeyes
12:30 soreau: to see if it's a wayland native app, you can use xprop and hover over the app to see if it has crosshairs (if so, it's xwayland)
12:30 akik: ok thanks
12:34 akik: mate-terminal seems to handle both
12:35 akik: this is a bit of a special environment where i'm running (a docker container inside wsl 2)
12:35 wlb: wayland Issue #381 opened by ali HOSSEINZADEH (ali.hosseinzadeh) right click bug in when menu covers ubuntu's Top Bar https://gitlab.freedesktop.org/wayland/wayland/-/issues/381
12:37 akik: so xprop is not changing the cursor
12:37 akik: but setting WAYLAND_DISPLAY= works to show what i wanted
12:38 pq: try setting it to nonsense, not empty
12:38 akik: pq: yes i did
12:38 emersion: empty should work
12:38 emersion: unset wouldn't
12:38 akik: i set export WAYLAND_DISPLAY=abc
12:39 pq: you never know if apps do their own checks in addition to libwayland
12:39 wlb: wayland Issue #381 closed \o/ (right click bug when its menu covers ubuntu's Top Bar https://gitlab.freedesktop.org/wayland/wayland/-/issues/381)
12:40 emersion: some apps are stupid and use XDG_SESSION_TYPE
12:41 akik: microsoft tells you to use XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR in wsl 2
12:41 akik: https://github.com/microsoft/wslg/blob/main/samples/container/Containers.md
12:42 emersion: XDG_RUNTIME_DIR is a standard, while XDG_SESSION_TYPE is a non-standard systemd invented thing
12:42 akik: hehe
12:42 akik: that project walks its own path
12:44 pq: didn't both come from systemd?
12:45 emersion: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
12:48 pq: https://gitlab.freedesktop.org/xdg/xdg-specs/-/commit/a0d218ad7da9f01fc5d01867f361aecc5cd61342
12:48 pq: lennart did it :-)
14:19 kennylevinsen: Yeah they just decided not to deal with xdg-specs after that...
14:19 kennylevinsen: so now there's this awkward case of some XDG vars being spec and others being systemd-internal, and no easy way to distinguish :/
15:11 akik: soreau: xprop doesn't work for that foot terminal emulator, but it works for checking out xclock properties
15:24 soreau: as I said, when it works (crosshairs cursor on hover), this means it's xwayland and not native
15:58 akik: soreau: oh i understood wrong
15:58 akik: thanks for the info
16:03 soreau: np