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]
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>
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.
<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)
<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]
<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.