ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Company has quit [Quit: Leaving]
radu24284303951534727071489559 has joined #wayland
pounce has joined #wayland
mvlad has quit [Remote host closed the connection]
radu24284303951534727071489559 has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
Dami_Lu has quit [Remote host closed the connection]
co1umbarius has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
columbarius has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
cool110 is now known as Guest8600
Dami_Lu has joined #wayland
Guest8585 has quit [Ping timeout: 480 seconds]
privacy has quit [Quit: Leaving]
garnacho has quit [Ping timeout: 480 seconds]
Guest8600 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest8610
Guest8610 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ is now known as Guest8611
nerdopolis has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
<rayrapetyan> are there any compositors implementing server side for libei except mutter?
privacy has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
kts has joined #wayland
rv1sr has joined #wayland
rasterman has joined #wayland
Company has joined #wayland
mvlad has joined #wayland
molinari has joined #wayland
sevz has quit [Quit: WeeChat 4.1.1]
glennk has joined #wayland
sima has joined #wayland
rgallaispou has joined #wayland
garnacho has joined #wayland
kyomawolf has joined #wayland
<whot> rayrapetyan: not yet, afaik
leon-anavi has joined #wayland
cvmn has joined #wayland
caveman has quit [Ping timeout: 480 seconds]
privacy has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
caveman has joined #wayland
cvmn has quit [Ping timeout: 480 seconds]
kts has joined #wayland
iomari891 has joined #wayland
cmichael has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
cmichael has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
cmichael has joined #wayland
kts has joined #wayland
kts has quit []
ascent12 has joined #wayland
ascent12_ has quit [Ping timeout: 480 seconds]
kts has joined #wayland
Moprius has joined #wayland
Brainium has joined #wayland
Net147 has quit [Ping timeout: 480 seconds]
Net147 has joined #wayland
narodnik has quit [Quit: WeeChat 4.1.1]
thron has joined #wayland
<thron> hello
thron has left #wayland [#wayland]
nerdopolis has joined #wayland
kts has quit [Quit: Leaving]
utsweetyfish has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
sevz has joined #wayland
cmichael has quit [Quit: Leaving]
cmichael has joined #wayland
iomari891 has quit [Remote host closed the connection]
sevz has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
leon-anavi has quit [Remote host closed the connection]
leon-anavi has joined #wayland
Moprius has quit [Quit: bye]
nerdopolis has joined #wayland
<JEEB> :)
agd5f has quit [Read error: Connection reset by peer]
randomher0 has joined #wayland
fluix_ is now known as fluix
<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?
<emersion> can you explain why you need this information?
<randomher0> I need to create windows for a remote desktop client and configure the rdp server desktop monitor resolution to match the local configuration.
<randomher0> I need the monitor resolution in pixels for this.
agd5f has joined #wayland
<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.
<vyivel> listen to wl_output.mode?
<randomher0> @vyivel you mean listen it is announced somewhere? can i look it up?
<emersion> is this for a specific compositor?
<emersion> you'll probably just want to listen to xdg_surface.configure and scale
<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.
<randomher0> on x11 there is xrandr.. i guessed there might be an equivalent on wayland
<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
<kchibisov> they add scrollbars iirc.
<emersion> window size + apply scale would be better imho
<randomher0> it will match it. I want to have a fullscreen remote desktop connection on two screens.
utsweetyfish has joined #wayland
<emersion> fullscreen doesn't mean that it matches
<randomher0> @emersion why not?
<emersion> the compositor can add some extra UI elements in fullscreen mode
<emersion> also notches etc
<randomher0> @emersion ok. didn't know that. So, how do I get the available fullscreen space in pixels?
<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
<kchibisov> no api for notches though.
<jadahl> or, rather, the surface size * scale
<emersion> kchibisov: just means the compositor or KMS will add some dead space
<emersion> which means the fullscreen size won't match
<kchibisov> emersion: we still don't have safe area api.
<kchibisov> nothing stops from communicating them to clients.
<emersion> yea, so rn KMS will add the dead space
<randomher0> @jadahl: ok, i floor that value probably? scale factor is a float
<kchibisov> so clients can just not draw into them.
<jadahl> can't remember if you're supposed to floor() or round() it
<emersion> iirc round
<randomher0> @emersion thanks
<kchibisov> it's round for toplevel and undefined for everything else.
<jadahl> lucky remmina's rdp view is a toplevel then
<emersion> randomher0: note, likely GTK has some API to expose this stuff instead of directly using wayland. but i don't know GTK
<emersion> jadahl probably is the right person for you to ask questions :P
* jadahl would have to look at gtk API docs to know :p
<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?
<jadahl> (I was not involved in the fractional scaling implementation in gtk)
<emersion> ouch GTK2
<emersion> GTK2 doesn't even have wayland
<emersion> did you mean GTK3?
<randomher0> no sorry it is gtk3 my bad
<emersion> ah makes sense
<randomher0> gtk4 has the scale factor
<jadahl> gtk3 doesn't have fractional scaling AFAIK
<kchibisov> doesn't gtk3 has api to get physical sizes of buffer?
<emersion> yeah, for GTK3 you'll need to do the wayland bits yourself indeed
<kchibisov> there's no way there's no API for that stuff.
<emersion> not super sure how you'd wire up viewporter w/ GTK
<jadahl> kchibisov: gtk3 effectively uses ceil(fractional_scale) so remmina wouldn't get the optimal buffer size
<kchibisov> yeah, but gtk can't do fractional at al.
<kchibisov> at least gtk3 iirc?
<randomher0> @jadahl yes, it can't compute pixel dimensions in my case the scale is 2 and should be 1.5
<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
<randomher0> @jadahl why is gtk3 pixel buffer larger than available fullscreen space?
<kchibisov> fractional scaling is not a thing in core, so you have to render at 2x downscale to 1.5.
rasterman has quit [Quit: Gettin' stinky!]
nerdopolis has quit [Ping timeout: 480 seconds]
<kchibisov> I wonder whether there was alternative fractional scalig protocol which bisacally works in physical pixels, and scale is just _suggested_.
<kchibisov> Like there're clients who always want to render at scale 1 and never be rescaled.
<kchibisov> But make some ui elements bigger a bit.
Brainium has quit [Quit: Konversation terminated!]
<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?
<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
<riteo> emersion: thanks a lot for making that MR!
<kchibisov> randomher0: you can't avoid that in all cases, though you can cover most cases.
<emersion> randomher0: the main issue is GTK3 getting in your way
<kchibisov> you can also not have fractional scaling protocol.
<kchibisov> you could have missmatches, etc.
<emersion> yeah, but the fallback is easy: just use integer scale
<emersion> the mismatch isn't too bad
<kchibisov> I mean it's visually unusable.
<emersion> no, just means there might be a 1px black bar at the bottom or something
<emersion> tbh, with GTK3, i'd just go for integer scale
<kchibisov> you can hit rounding missmatch or you can also hit a size you can't represent.
<emersion> and leave fractional scale for a GTK4 port
<kchibisov> Like there're scaling factors where you can't get X only X - 1 and X + 1.
<kchibisov> so if remote is X, but you can't make a buffer of X, you'll have to figure.
<emersion> kchibisov: local sends the size to remote
<jadahl> I'd do what emersion suggests; give up on pixel perfection in GTK3, and aim for pixel perfection after a GTK4 port
<jadahl> when it comes to fractional scaling at least
<randomher0> ok 1707x960 (available through GTK3) * 1.5 (where to get this) = 2560.5 x 1440 would be ok
<jadahl> an alternative is to try to use the subsurface stuff gtk3 kind of handles
<kchibisov> you'd have to render at 2561.
<randomher0> @kchibisov ok. but where do i get the 1.5 from?
<jadahl> randomher0: bind the fractional scaling extensin yourself and listen for events
<kchibisov> viewporter + fractional scale protocol.
<randomher0> ok understood, i'll look into that.
<kchibisov> And it's not _guaranteed_ to be available.
nerdopolis has joined #wayland
<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?
koty0f has joined #wayland
<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
<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.
<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.
<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.
privacy has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
<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.
<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.
<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?
<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)
<kchibisov> randomher0: app renders at 2560 x 1440 / 1.5 * 2.
<pq> randomher0, I have no idea what "app scale factor" is.
koty0f has quit [Quit: Konversation terminated!]
<kchibisov> pq: they mean the thing they get from the `scale` event.
<kchibisov> And 150% they mean in the gnome settings UI.
<kchibisov> And no fractional scaling is involved.
<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?
<kchibisov> They just want to communicate physical size and render remote at scale 1.
<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"
<pq> randomher0, ok, and you can automatically control that via RDP, right?
<kchibisov> At least that was initially, maybe app-scale is now remote-app-scale.
<randomher0> pg: i suppose i could tell rdp server on windows to render ui at scale 0.666 to an image of size 1707x960
<pq> I don't understand where those numbers come from.
<kchibisov> I don't get why it should be inverted scale on rdp side?
<kchibisov> Like can't you just passthrough?
<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.
<kchibisov> so you got scale 2, you send scale 2 to remote, and your buffer size as a resolution?
<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.
<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?
<pq> well, you'd get the UI size right that way, but the image will look really bad
<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.
<kchibisov> I don't think that's the only option though.
<kchibisov> you can tell 1080p at scale 1 as well.
<pq> sure, that's not reasonable
<kchibisov> why? You'll remote unscaled 1080p.
<kchibisov> All the thing that matters is the buffer size.
<pq> either the Wayland window would be twice the size of the output, or the UI would be too small to use
<kchibisov> wayland window's logical size is orthogonal to that.
<kchibisov> it's the same in every case said.
<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.
<kchibisov> yes, but it's image passing.
<kchibisov> image doesn't have a notion of too small.
<kchibisov> it's physical buffer.
<pq> yes it does, when it's displayed
<kchibisov> user can set scale in the UI settings.
<pq> wasn't the whole point that RDP would communicate the scale to the user does not need to touch it manually?
<pq> *so
<kchibisov> I mean you can, but there's no need to communicate 540p.
<pq> we are talking *so* past each other
<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.
<kchibisov> so if they want 540p they need scale 1 in client.
<pq> if you're happy to manually tweak the RDP server side, then sure, nothing really matters
<pq> Of course they must not lie to the Wayland compositor about the scale the image was rendered in.
<kchibisov> What I'm saying is that they should communicate buffer size + scale they wnat.
<pq> via RDP, yes, exactly
<kchibisov> and buffer size is always configure's size * scale.
<kchibisov> of the wayland client.
<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.
<kchibisov> I mean, they can not communicate that, it'll be just fine, they don't have to do 540p though.
<kchibisov> Like if they can't I'd rather let the user pick the scaling themselves instead of having blurry mess.
<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.
<pq> I didn't expect the answer to be "manually adjust DPI settings in Windows in the server". That seemed unacceptable to me.
<kchibisov> pq: "can't read text" is more unacceptable though.
<pq> it's the same thing
<kchibisov> I mean, compositor scaling can (and often does it) unreadable.
<kchibisov> user setting option never does that.
<kchibisov> they just have a bit small text for a bit.
<pq> randomher0, err, yeah, it may be more efficient, but it's also artifically low resolution.
<kchibisov> That's not just RDP thing, it's the same with qemu for example.
<kchibisov> I can't read anything in qemu due to re-scaling in compositor.
<pq> kchibisov, I think you are talking about a different "unreadable" than I am.
<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".
<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"?
<kchibisov> AA doesn't scale well, it's a blurry mess.
<pq> yes!
<pq> so you call blurry unreadable, I call too small as unreadable
<kchibisov> but it's small _crisp_ text.
<kchibisov> which you can fix yourself.
<pq> but too small to real
<pq> but too small to read
<kchibisov> you can't fix 540p yourself.
<kchibisov> other than forcing all your desktop to rescale.
<pq> no, that's a program bug
<kchibisov> that it can't communicate scale?
flom84 has joined #wayland
<pq> hardcoding something you didn't want
<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.
<pq> *when
<kchibisov> Maybe not for RDP, but in a qemu VM it's a perfectly resonable thing to do.
<pq> anyway, it sounds like the answer is "fiddle with it manually", and I can't argue with that
<kchibisov> I mean, answer is "communicate if you can, but not force rescaling on behalf of the users".
tzimmermann has quit [Quit: Leaving]
<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.
<kchibisov> you can have an option in RDP if someone really wants to have unreadable big text.
<kchibisov> RDP client.
<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.
<DemiMarie> Realtime software encoding is very expensive.
<DemiMarie> There is also the need to keep text readable and edges sharp, which general media encoding might not have.
<DemiMarie> So I would not at all be surprised if RDP uses RDP-specific codecs that are less optimized than general-purpose codecs.
<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.
<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.
<ManMower> errr, are you hoping to achieve multi-monitor rdp with wayland?
<ManMower> (asked without reading much scrollback...)
<randomher0> @ManMower: I'm currently implementing that. I din't anticipate determining the physical res of all connected monitors would be so difficult.
<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? :(
<ManMower> (ie: once scaling is considered, there are rdp monitor layouts that are unrepresentable in wayland)
iomari891 has joined #wayland
<ManMower> you might be interested in https://github.com/microsoft/weston-mirror
<ManMower> microsoft uses weston's rdp backend as part of WSLg, so you can see their code for validating multi-head configurations here
<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.
<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
flom84 has quit [Quit: Leaving]
<randomher0> didn't dive deep but since it is github.com/microsoft they should know what they are doing
kyomawolf has quit [Ping timeout: 480 seconds]
narodnik has joined #wayland
kts has joined #wayland
randomher0 has quit [Remote host closed the connection]
<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
kyomawolf has joined #wayland
rgallaispou has quit [Quit: Leaving.]
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
cmichael has quit [Quit: Leaving]
glennk has quit [Ping timeout: 480 seconds]
Moprius has joined #wayland
Brainium has joined #wayland
kts has quit [Quit: Leaving]
leon-anavi has quit [Quit: Leaving]
rv1sr has quit []
molinari has quit [Ping timeout: 480 seconds]
andreasbackx has joined #wayland
nerdopolis has joined #wayland
glennk has joined #wayland
fullstop_ is now known as fullstop
molinari has joined #wayland
yang is now known as Guest8684
Guest8684 is now known as yang
Brainium has quit [Read error: No route to host]
Moprius has quit [Quit: bye]
Moprius has joined #wayland
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
Moprius has quit [Quit: bye]
Brainium has joined #wayland
joshs has joined #wayland
<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?
<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.
___nick___ has quit [Ping timeout: 480 seconds]
<ManMower> wayland-1 is a connection to a compositor, it doesn't select a specific output
<ManMower> (I'm not sure how to do exactly what you want)
<soreau> joshs: have you tried to run two instances of the app (both on wayland-1) and drag one to the other output?
<soreau> not sure what you're trying to do exactly either
<soreau> but when you run weston, it drives all outputs connected to the gpu typically
<soreau> so there's only a single weston instance, this is why you only see wayland-1 socket
<joshs> yes, I can drag an app from one display to the other, I just can't launch on app on the second display
sima has quit [Ping timeout: 480 seconds]
<soreau> so you want to have it open on the second display automatically without having to drag it?
<joshs> I have 2 displays, I want 2 fullscreen apps. They need to run at startup, so manually moving them wont work
<joshs> @soreau, yes
<soreau> I'm not sure weston can do this, but I know many other compositors can, such as wayfire
<joshs> oh, for my case 'maximized' is just as good as 'fullscreen'. does that change anything?
<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)
<soreau> fluix: ah ok, thanks
<soreau> joshs: no, not really
<fluix> although, if you're okay with _some_ delay, you could automate the interactive movements with something like ydotool
<joshs> can i have 2 weston instances, one for each display?
<soreau> no
<soreau> not without different gpu's driving each display
<kchibisov> joshs: `set_fullscreen` accepts `wl_output` to open monitor on.
<kchibisov> So you can crate a window with `None` and then pick output not-matching the output you end up having.
<kchibisov> Some apps tend to do thing like that to show temporary preview, so it doesn't obscure main content.
<kchibisov> compositor can always deny opening, etc, etc, but it's not like you can't select.
randomher0 has joined #wayland
<joshs> `set_fullscreen` can be called by an app?
randomher0 has quit [Remote host closed the connection]
joshs has quit [Remote host closed the connection]
kyomawolf has quit [Remote host closed the connection]
nerdopolis has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
randomher0_ has joined #wayland
randomher0_ has quit []
<daniels> JoshuaAshton: you want kiosk-shell
<daniels> erk, joshs left
Company has quit [Quit: Leaving]
lsd|2 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]