03:55 rayrapetyan: are there any compositors implementing server side for libei except mutter?
09:16 whot: rayrapetyan: not yet, afaik
11:24 emersion: riteo, kchibisov: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4467
12:48 thron: hello
14:13 pq: Just landed https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/wayland_qa.md#q-should-srgb-content-be-decoded-with-the-piecewise-srgb-transfer-function - please, direct your screaming into either a new issue or https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/30 depending on which one is more on topic. :-p
14:18 JEEB: :)
14:20 randomher0: Hi, I'm looking to get size of all monitors resolution used by wayland in physical pixels. Can you help me where to find this?
14:23 emersion: can you explain why you need this information?
14:25 randomher0: I need to create windows for a remote desktop client and configure the rdp server desktop monitor resolution to match the local configuration.
14:25 randomher0: I need the monitor resolution in pixels for this.
14:27 randomher0: @emersion I thought this would be a thing for Gtk.monitor - the app uses gtk. But as i found out in Gtk channel there is no pixel dimension available in GtkMonitor - thus I looked in wayland.
14:28 vyivel: listen to wl_output.mode?
14:29 randomher0: @vyivel you mean listen it is announced somewhere? can i look it up?
14:29 emersion: is this for a specific compositor?
14:30 emersion: you'll probably just want to listen to xdg_surface.configure and scale
14:30 randomher0: @emersion It is for an end user app (remmina remote desktop client). It is supposed to be platform independent and uses gtk. As gtk can't give me this info I wanted to look it up elsewhere.
14:31 randomher0: on x11 there is xrandr.. i guessed there might be an equivalent on wayland
14:31 emersion: i don't think using the physical monitor size is the right thing to do here, maybe your window doesn't match it exactly
14:31 kchibisov: they add scrollbars iirc.
14:31 emersion: window size + apply scale would be better imho
14:31 randomher0: it will match it. I want to have a fullscreen remote desktop connection on two screens.
14:32 emersion: fullscreen doesn't mean that it matches
14:32 randomher0: @emersion why not?
14:32 emersion: the compositor can add some extra UI elements in fullscreen mode
14:33 emersion: also notches etc
14:33 randomher0: @emersion ok. didn't know that. So, how do I get the available fullscreen space in pixels?
14:33 jadahl: randomher0: when you're fullscreen you can use the fractional scaling extension to get the factor that can be used for an optimal buffer size. maybe pass that to the RDP server
14:34 kchibisov: no api for notches though.
14:34 jadahl: or, rather, the surface size * scale
14:34 emersion: kchibisov: just means the compositor or KMS will add some dead space
14:34 emersion: which means the fullscreen size won't match
14:34 kchibisov: emersion: we still don't have safe area api.
14:34 kchibisov: nothing stops from communicating them to clients.
14:34 emersion: yea, so rn KMS will add the dead space
14:35 kchibisov: so clients can just not draw into them.
14:35 randomher0: @jadahl: ok, i floor that value probably? scale factor is a float
14:35 jadahl: can't remember if you're supposed to floor() or round() it
14:36 emersion: iirc round
14:36 randomher0: @emersion thanks
14:36 kchibisov: it's round for toplevel and undefined for everything else.
14:36 jadahl: lucky remmina's rdp view is a toplevel then
14:37 emersion: randomher0: note, likely GTK has some API to expose this stuff instead of directly using wayland. but i don't know GTK
14:38 emersion: jadahl probably is the right person for you to ask questions :P
14:38 jadahl:would have to look at gtk API docs to know :p
14:38 randomher0: @emersion gtk2 has only scale as int, it is useless. so to recap: i go fullscreen, measure the windows size (logical pixels) and multiply by scale and round?
14:38 jadahl: (I was not involved in the fractional scaling implementation in gtk)
14:38 emersion: ouch GTK2
14:38 emersion: GTK2 doesn't even have wayland
14:38 emersion: did you mean GTK3?
14:39 randomher0: no sorry it is gtk3 my bad
14:39 emersion: ah makes sense
14:39 randomher0: gtk4 has the scale factor
14:39 jadahl: gtk3 doesn't have fractional scaling AFAIK
14:39 kchibisov: doesn't gtk3 has api to get physical sizes of buffer?
14:39 emersion: yeah, for GTK3 you'll need to do the wayland bits yourself indeed
14:39 kchibisov: there's no way there's no API for that stuff.
14:39 emersion: not super sure how you'd wire up viewporter w/ GTK
14:39 jadahl: kchibisov: gtk3 effectively uses ceil(fractional_scale) so remmina wouldn't get the optimal buffer size
14:40 kchibisov: yeah, but gtk can't do fractional at al.
14:40 kchibisov: at least gtk3 iirc?
14:40 randomher0: @jadahl yes, it can't compute pixel dimensions in my case the scale is 2 and should be 1.5
14:42 jadahl: randomher0: a problem with gtk3 is that you'll scale up the content from the RDP server since gtk3's pixel buffer will be larger, which the compositer will then scale back down
14:43 randomher0: @jadahl why is gtk3 pixel buffer larger than available fullscreen space?
14:44 kchibisov: fractional scaling is not a thing in core, so you have to render at 2x downscale to 1.5.
14:51 kchibisov: I wonder whether there was alternative fractional scalig protocol which bisacally works in physical pixels, and scale is just _suggested_.
14:51 kchibisov: Like there're clients who always want to render at scale 1 and never be rescaled.
14:52 kchibisov: But make some ui elements bigger a bit.
14:53 randomher0: @kchibisov: sorry I'm confused. I'd optimally just blit the result from the remote (e.g. 1920x1080) on my screen (1920x1080) without rescaling, is that possible?
14:54 randomher0: if there is not enough fullscreen space and wayland needs to display some decoration I'd configure remote resolution just for that remaining space
14:54 riteo: emersion: thanks a lot for making that MR!
14:57 kchibisov: randomher0: you can't avoid that in all cases, though you can cover most cases.
14:57 emersion: randomher0: the main issue is GTK3 getting in your way
14:58 kchibisov: you can also not have fractional scaling protocol.
14:58 kchibisov: you could have missmatches, etc.
14:58 emersion: yeah, but the fallback is easy: just use integer scale
14:58 emersion: the mismatch isn't too bad
14:58 kchibisov: I mean it's visually unusable.
14:59 emersion: no, just means there might be a 1px black bar at the bottom or something
14:59 emersion: tbh, with GTK3, i'd just go for integer scale
14:59 kchibisov: you can hit rounding missmatch or you can also hit a size you can't represent.
14:59 emersion: and leave fractional scale for a GTK4 port
15:00 kchibisov: Like there're scaling factors where you can't get X only X - 1 and X + 1.
15:00 kchibisov: so if remote is X, but you can't make a buffer of X, you'll have to figure.
15:00 emersion: kchibisov: local sends the size to remote
15:00 jadahl: I'd do what emersion suggests; give up on pixel perfection in GTK3, and aim for pixel perfection after a GTK4 port
15:01 jadahl: when it comes to fractional scaling at least
15:01 randomher0: ok 1707x960 (available through GTK3) * 1.5 (where to get this) = 2560.5 x 1440 would be ok
15:01 jadahl: an alternative is to try to use the subsurface stuff gtk3 kind of handles
15:01 kchibisov: you'd have to render at 2561.
15:02 randomher0: @kchibisov ok. but where do i get the 1.5 from?
15:02 jadahl: randomher0: bind the fractional scaling extensin yourself and listen for events
15:02 kchibisov: viewporter + fractional scale protocol.
15:02 randomher0: ok understood, i'll look into that.
15:02 kchibisov: And it's not _guaranteed_ to be available.
15:32 pq: randomher0, do you also configure the scale into the RDP server? Maybe the local display needs things rendered in scale=2 to be legible, but if you communicate the physical pixels, how do you keep things legible?
15:36 randomher0: pq: i didn't think of desktop scale yet. If it is possible to tell freerdp about remote desktop scale factor I could pass that from wayland to rdp server. If I only had that scale factor already... looks like I have to polyfill https://docs.gtk.org/gdk4/method.Surface.get_scale.html as I cannot port that whole app to gtk4 just now
15:37 pq: randomher0, my point being, maybe you should start with logical, not physical, size. The image might be coarse, but at least it will be legible.
15:39 pq: The RDP server cannot provide a higher resolution image anyway if the software in the remote server is not rendering in high resolution (scale) to begin with.
15:41 pq: if the original content is rendered with scale=1, you may as well punt the up-scaling to the Wayland compositor where the RDP client is running on.
15:46 randomher0: pg: Could be a compromise. If windows only scales up bilinear if destop is scaled - which I doubt - this would give the same result.
15:52 pq: randomher0, I still don't undertand who is going to do the necessary up-scaling if you use the physical size of a scale=2 output.
15:56 randomher0: pq: consider a windows desktop on a 2560 x 1440 screen and app scale factor of 150%: does it mean windows renders an image of 1707x960 (with all elements scaled down to 0.6666) and then upscales bilinearly to physical res?
15:57 randomher0: if that is the case your solution would be more efficient as only the 1707x960 need to be transmitted (although compression artifacts might be more visible)
16:00 kchibisov: randomher0: app renders at 2560 x 1440 / 1.5 * 2.
16:00 pq: randomher0, I have no idea what "app scale factor" is.
16:00 kchibisov: pq: they mean the thing they get from the `scale` event.
16:01 kchibisov: And 150% they mean in the gnome settings UI.
16:01 kchibisov: And no fractional scaling is involved.
16:01 pq: but that's wayland, so RDP client side. How are they going to get the RDP server side to actually render at that scale?
16:01 kchibisov: They just want to communicate physical size and render remote at scale 1.
16:01 randomher0: pg: there is a setting in ms windows which can scale the ui of apps: https://www.digitaltrends.com/computing/how-to-adjust-high-dpi-scaling-in-windows-10/ screenshot "display settings"
16:02 pq: randomher0, ok, and you can automatically control that via RDP, right?
16:02 kchibisov: At least that was initially, maybe app-scale is now remote-app-scale.
16:02 randomher0: pg: i suppose i could tell rdp server on windows to render ui at scale 0.666 to an image of size 1707x960
16:03 pq: I don't understand where those numbers come from.
16:04 kchibisov: I don't get why it should be inverted scale on rdp side?
16:04 kchibisov: Like can't you just passthrough?
16:04 pq: If your goal is to have the remote render e.g. 1080p image at scale=2, then the image will be 1080p pixels of size, but all UI elements are drawn 2x their logical size.
16:04 kchibisov: so you got scale 2, you send scale 2 to remote, and your buffer size as a resolution?
16:06 pq: randomher0, you're not supposed to undo the Wayland scaling by rendering a tiny image and then letting the Wayland compositor to up-scale it. That would look horrible.
16:07 randomher0: if the remote renders half res image the ui will be double size if upscaled by 2 locally. Thus I need to tell remote to render the ui at half the size? it is late, am i wrong?
16:07 pq: well, you'd get the UI size right that way, but the image will look really bad
16:09 pq: Let's say Wayland output is 1080p at scale=2. You have two reasonable options: tell RDP server to render 540p at scale=1, or 1080p at scale=2.
16:11 kchibisov: I don't think that's the only option though.
16:11 kchibisov: you can tell 1080p at scale 1 as well.
16:11 pq: sure, that's not reasonable
16:12 kchibisov: why? You'll remote unscaled 1080p.
16:12 kchibisov: All the thing that matters is the buffer size.
16:12 pq: either the Wayland window would be twice the size of the output, or the UI would be too small to use
16:13 kchibisov: wayland window's logical size is orthogonal to that.
16:13 kchibisov: it's the same in every case said.
16:13 pq: I'm assuming the Wayland output is 1080p at scale=2 for the reason that if drawn at scale=1 the UI is too small to use.
16:13 kchibisov: yes, but it's image passing.
16:13 kchibisov: image doesn't have a notion of too small.
16:13 kchibisov: it's physical buffer.
16:14 pq: yes it does, when it's displayed
16:14 kchibisov: user can set scale in the UI settings.
16:14 pq: wasn't the whole point that RDP would communicate the scale to the user does not need to touch it manually?
16:14 pq: *so
16:14 kchibisov: I mean you can, but there's no need to communicate 540p.
16:15 pq: we are talking *so* past each other
16:15 kchibisov: yeah, but what I'm saynig is that what you want is that scale on wayland side for client matches scale on rdp side.
16:15 kchibisov: so if they want 540p they need scale 1 in client.
16:15 pq: if you're happy to manually tweak the RDP server side, then sure, nothing really matters
16:16 kchibisov: What I'm saying is that they should communicate buffer size + scale they wnat.
16:16 pq: Of course they must not lie to the Wayland compositor about the scale the image was rendered in.
16:17 pq: via RDP, yes, exactly
16:17 kchibisov: and buffer size is always configure's size * scale.
16:17 kchibisov: of the wayland client.
16:18 pq: I understood from randomher0 that he does not communicate scale though, so I was asking how do they communicate the scale and get the RDP server side to render with that scale.
16:18 kchibisov: I mean, they can not communicate that, it'll be just fine, they don't have to do 540p though.
16:18 kchibisov: Like if they can't I'd rather let the user pick the scaling themselves instead of having blurry mess.
16:19 randomher0: All is easy if scale and resolution is set to same values local and remote - i think scale can be set through rdp. But pg made me think about transmitting a smaller image with appropriately scaled ui from remote and upscaling locally could be more efficient.
16:19 pq: I didn't expect the answer to be "manually adjust DPI settings in Windows in the server". That seemed unacceptable to me.
16:19 kchibisov: pq: "can't read text" is more unacceptable though.
16:19 pq: it's the same thing
16:19 kchibisov: I mean, compositor scaling can (and often does it) unreadable.
16:20 kchibisov: user setting option never does that.
16:20 kchibisov: they just have a bit small text for a bit.
16:20 pq: randomher0, err, yeah, it may be more efficient, but it's also artifically low resolution.
16:20 kchibisov: That's not just RDP thing, it's the same with qemu for example.
16:20 kchibisov: I can't read anything in qemu due to re-scaling in compositor.
16:20 pq: kchibisov, I think you are talking about a different "unreadable" than I am.
16:22 kchibisov: I'm just saying that there's no point to always make users suffer because you decided to pass 540p due to "not able to communicate scale".
16:22 pq: If a font has been rendered 10px high, and that's 0.5 mm on screen, that's what I called "unreadable". If that same image is integer-up-scaled to 5 mm tall, that's what you call "unreadable"?
16:22 kchibisov: AA doesn't scale well, it's a blurry mess.
16:22 pq: yes!
16:23 pq: so you call blurry unreadable, I call too small as unreadable
16:23 kchibisov: but it's small _crisp_ text.
16:23 kchibisov: which you can fix yourself.
16:23 pq: but too small to real
16:23 pq: but too small to read
16:23 kchibisov: you can't fix 540p yourself.
16:23 kchibisov: other than forcing all your desktop to rescale.
16:23 pq: no, that's a program bug
16:24 kchibisov: that it can't communicate scale?
16:24 pq: hardcoding something you didn't want
16:24 pq: I never thought that manually fiddling with scale settings to make them match was a good answer then things could be made to do the right thing automatically.
16:24 pq: *when
16:25 kchibisov: Maybe not for RDP, but in a qemu VM it's a perfectly resonable thing to do.
16:25 pq: anyway, it sounds like the answer is "fiddle with it manually", and I can't argue with that
16:25 kchibisov: I mean, answer is "communicate if you can, but not force rescaling on behalf of the users".
16:27 randomher0: I think transmitting the full native remote resolution is the best can do. There is no real need to "save bandwith" or something. I just want the remote mirrored exactly on my local screens.
16:27 kchibisov: you can have an option in RDP if someone really wants to have unreadable big text.
16:27 kchibisov: RDP client.
16:31 DemiMarie: randomher0: it very much depends on the situation. If the client is on a slow or metered connection then bandwidth might matter a LOT. There is also no guarantee that one has hardware-accelerated codecs, or that the distribution has enabled them in the build.
16:31 DemiMarie: Realtime software encoding is very expensive.
16:32 DemiMarie: There is also the need to keep text readable and edges sharp, which general media encoding might not have.
16:32 DemiMarie: So I would not at all be surprised if RDP uses RDP-specific codecs that are less optimized than general-purpose codecs.
16:34 randomher0: DemMarie: true. Should optimally be configurable. I argue the case "I want to use all my screens for a remote session in best quality" is an important case. I might only be talking for myself which is in fact why I'm doing all this now.
16:35 randomher0: There are really good codecs in freerdp - was very happy using this app on x11. Unfortunately fullscreen multimonitor is not possible on wayland - that is why I'm working on it.
16:36 ManMower: errr, are you hoping to achieve multi-monitor rdp with wayland?
16:36 ManMower: (asked without reading much scrollback...)
16:39 randomher0: @ManMower: I'm currently implementing that. I din't anticipate determining the physical res of all connected monitors would be so difficult.
16:40 ManMower: have you hit the part where RDP sends all input in physical co-ordinates based in the top left corner of the monitor layout, so it's literally impossible to map that to logical coordinates on the wayland side once scaling is in play? :(
16:40 ManMower: (ie: once scaling is considered, there are rdp monitor layouts that are unrepresentable in wayland)
16:42 ManMower: you might be interested in https://github.com/microsoft/weston-mirror
16:43 ManMower: microsoft uses weston's rdp backend as part of WSLg, so you can see their code for validating multi-head configurations here
16:43 randomher0: I'd like to use separate channels for each monitor which is supported according to the folks at #freerdp. Display one window fulllscreen on each local monitor.
16:44 ManMower: ah, interesting. that sounds like a potentially viable approach and a much more solvable problem than "making a compositor with a fully functional rdp backend". I think you won't have the same input ambiguities
16:47 randomher0: didn't dive deep but since it is github.com/microsoft they should know what they are doing
17:25 wlb: weston Issue #847 opened by W Scott McKibbin (WMcKibbin) Weston Kiosk Shell chromium losing focus upon sad tab kill https://gitlab.freedesktop.org/wayland/weston/-/issues/847
21:07 joshs: Hi all, I have weston running on an embedded target with 2 displays. All I want to do is run 2 apps fullscreen, one on each display. I can't seem to find a way to target the second display?
21:07 joshs: I use WAYLAND_DISPLAY=wayland-1 to run an app on the first display. In XDG_RUNTIME_DIR, all I see is wayland-1. The displays appear to be 'extended' where a window can be split between the two by dragging it there.
21:09 ManMower: wayland-1 is a connection to a compositor, it doesn't select a specific output
21:10 ManMower: (I'm not sure how to do exactly what you want)
21:10 soreau: joshs: have you tried to run two instances of the app (both on wayland-1) and drag one to the other output?
21:10 soreau: not sure what you're trying to do exactly either
21:11 soreau: but when you run weston, it drives all outputs connected to the gpu typically
21:11 soreau: so there's only a single weston instance, this is why you only see wayland-1 socket
21:11 joshs: yes, I can drag an app from one display to the other, I just can't launch on app on the second display
21:12 soreau: so you want to have it open on the second display automatically without having to drag it?
21:12 joshs: I have 2 displays, I want 2 fullscreen apps. They need to run at startup, so manually moving them wont work
21:13 joshs: @soreau, yes
21:13 soreau: I'm not sure weston can do this, but I know many other compositors can, such as wayfire
21:39 joshs: oh, for my case 'maximized' is just as good as 'fullscreen'. does that change anything?
21:40 fluix: I believe the compositor determines where windows are drawn (unless the app uses layer shell?), and there's no way to do so non-interactively in weston (if I understand soreau correctly)
21:40 soreau: fluix: ah ok, thanks
21:41 soreau: joshs: no, not really
21:41 fluix: although, if you're okay with _some_ delay, you could automate the interactive movements with something like ydotool
21:47 joshs: can i have 2 weston instances, one for each display?
21:47 soreau: no
21:48 soreau: not without different gpu's driving each display
21:53 kchibisov: joshs: `set_fullscreen` accepts `wl_output` to open monitor on.
21:53 kchibisov: https://wayland.app/protocols/xdg-shell#xdg_toplevel:request:set_fullscreen
21:53 kchibisov: So you can crate a window with `None` and then pick output not-matching the output you end up having.
21:54 kchibisov: Some apps tend to do thing like that to show temporary preview, so it doesn't obscure main content.
21:55 kchibisov: compositor can always deny opening, etc, etc, but it's not like you can't select.
22:10 joshs: `set_fullscreen` can be called by an app?
22:24 soreau: joshs: yes, see https://wayland.app/protocols/xdg-shell#xdg_toplevel:request:set_fullscreen
23:29 daniels: JoshuaAshton: you want kiosk-shell
23:29 daniels: erk, joshs left