ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
fmuellner has quit [Ping timeout: 480 seconds]
shoragan has quit [Quit: quit]
shoragan has joined #wayland
hch129072 has joined #wayland
hch12907 has quit [Ping timeout: 480 seconds]
hch129072 is now known as hch12907
garnacho has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
user21 has joined #wayland
kts has joined #wayland
kts_ has joined #wayland
kts_ has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
yshui has joined #wayland
yshui_ has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
yshui_ has joined #wayland
mxz_ has joined #wayland
yshui has quit [Ping timeout: 480 seconds]
mxz has quit [Ping timeout: 480 seconds]
mxz__ has quit [Ping timeout: 480 seconds]
mxz_ is now known as mxz
iomari891 has quit [Ping timeout: 480 seconds]
user21 has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
glennk has joined #wayland
dviola has quit [Remote host closed the connection]
glennk has quit [Remote host closed the connection]
larunbe has quit [Ping timeout: 480 seconds]
alarumbe has joined #wayland
user21 has joined #wayland
kts has joined #wayland
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
kts has quit [Quit: Leaving]
mxz_ has joined #wayland
manuels2 has joined #wayland
crazybyte has quit [Quit: Bye]
crazybyte has joined #wayland
kts has joined #wayland
abhimanyu has joined #wayland
Fxzxmic has joined #wayland
larunbe has joined #wayland
alarumbe has quit [Ping timeout: 480 seconds]
dviola has quit [Quit: WeeChat 4.4.3]
iomari891 has joined #wayland
abhimanyu has quit [Read error: Connection reset by peer]
abhimanyu has joined #wayland
kts has quit [Quit: Leaving]
KarenTheDorf has joined #wayland
<KarenTheDorf>
Morning all. Trying to understand the interaction between wl_surface::preferred_buffer_scale and wp_fractional_scale_v1::preferred_scale. If I have the following: An 800x600 window, with a preferred_buffer_scale of 2 and a preferred_scale of 180. I should attach a 1600x1200 buffer with buffer_scale of 2. But what scale/dpi should I then render the UI at, 3x as large as the nominal size?
<kchibisov>
fractional scaling means that you draw at scale 1 and use viewporter for the desired size.
<kchibisov>
so in your case you draw 1200x900 and use viewporter with 800x600 destination size.
coldfeet has joined #wayland
<KarenTheDorf>
And ignore the preferred_buffer_scale completely?
<kchibisov>
yes.
<KarenTheDorf>
:thumbs_up:
<kchibisov>
All of those are hints, nothing really mandates that you must use the scales you're getting.
<KarenTheDorf>
Yeah, that's why they are 'hints' :)
<KarenTheDorf>
The rendering is done by vulkan though, I'm just thinking what the best way to expose this is.
<kchibisov>
Always draw in physical pixels then.
<KarenTheDorf>
And just ignore all this completely?
<kchibisov>
It really depends what you're doing, but you could have a scale exposed for components where it matters.
<KarenTheDorf>
My original goal was to just expose a "Hey, btw, the compositor is configured for 150% dpi, so scale your UI appropriately"
<KarenTheDorf>
And leave the vulkan side to deal with that
kts has joined #wayland
<kchibisov>
if it's a game, then it doesn't make much sense.
<kchibisov>
since you'd need to scale only certain elements.
<KarenTheDorf>
Yeah, I can't do the scaling with buffer_scale/wl_viewporter.
<kchibisov>
like each case in terms of scaling is special, so you should just expose scale factor and communicate what buffer sizes should be used.
<KarenTheDorf>
kchibisov: Yeah, we're in agreement here. I just am trying to work out what scale factor I should expose and what buffer sizes should be used.
<kchibisov>
buffer size is always scale * logical_size.
<kchibisov>
otherwise you'll get rescaled.
garnacho has joined #wayland
<kchibisov>
and if you don't match the compositors desired scale, you'll also get rescaled.
<kchibisov>
so you should always apply scale to buffer you're drawing in.
<kchibisov>
either with viewporter + fractional scaling or preferred_buffer_scale.
<KarenTheDorf>
xdg_surface::configure says "800x600". wl_surface::prefered_buffer_scale says 2. wp_fractional_scale_v1::preferred_scale says 180. I should tell vulkan to create a 1200x900 swapchain, scale it's UI by 150%, and use a wl_viewporter?
<KarenTheDorf>
And if I don't want to support fractional scaling (or the compositor doesn't), I'd suggest a 1600x1200 buffer, 200% UI scaling and set buffer_scale=2?
<kchibisov>
KarenTheDorf: surface coordinates/etc are logical sizes.
<kchibisov>
buffer coordinates/sizes are physical.
<kchibisov>
KarenTheDorf: but basically yes.
<kchibisov>
The scale compositor tells you is a UI scale. You app can scale differently though.
<KarenTheDorf>
Sure, all of this is hinting to the vulkan side. Presumably the application would have it's own settings screen and the hints from the compositor would be used as initial values.
<kchibisov>
yeah, but the scale compositor tells should be applied anyway.
<kchibisov>
regardless of what app is doing, app can then pick scale 1.25, it'll just scale itself.
<KarenTheDorf>
If the user wants a scale factor of 1.25, the buffer size doesn't change (1.5x the surface size), and the vulkan side just uses a different value for rendering it's UI and that's of no concern to the wayland side.
<KarenTheDorf>
We give the hint for the UI scaling, but user settings override that.
<kchibisov>
yes.
kts has quit [Quit: Leaving]
<kchibisov>
just on a wayland side of things you should always apply the scale compositor tells you and inform users of that, what they do, is up to them
<KarenTheDorf>
kchibisov: That's awesome, thank you for the help!
<kchibisov>
And keep in mind that scale shoud be applied when you about to submit the buffer.
<kchibisov>
well, before new rendering phase.
<kchibisov>
Well, better to say, that you should avoid changing scale when you have an ongoing rendering.
<KarenTheDorf>
Well. Currently I configure the surface and wl_surface_commit/wl_display_roundtrip, and then use the values after the roundtrip. If they change after that intiial configuration... Yuck.
<KarenTheDorf>
My experience as a user is apps often don't rescale until they are restarted in that scenario.
<kchibisov>
KarenTheDorf: I mean if you have an on-going rendering, and compositor rescales, and e.g. toolkit applies scale in the middle of the renderieng, the app will likely crash because the buffer dimensions won't divide by scale factor.
<kchibisov>
this doesn't apply to fractional scaling though.
<kchibisov>
it's a matter of syncing in case you have multi-threaded rendering.
<KarenTheDorf>
Oh, well, no multithreading here.
<KarenTheDorf>
Unless the driver does stuff internally, but that would at least be on a different event queue.
abeltramo5895238 has quit [Ping timeout: 480 seconds]
<KarenTheDorf>
Hmm, I'm confused what I should do in the case of preffered_scale being 180 and preffered_buffer_scale being 2. I keep getting a window that's too big.
mriesch_ has joined #wayland
<kchibisov>
kaathewise: you set viewporter to the size you get in 'configure', you draw the 1200x900 buffer, and not use the scale 2 at all.
KarenTheDorf is now known as karenw
<karenw>
Yet I'm getting scaled by kwin to be much larger than 800x600 physical pixels.
mriesch has quit [Ping timeout: 480 seconds]
<kchibisov>
800x600 is logical size.
<kchibisov>
it'll be 1200x900 physical on screen.
<karenw>
Right.
<karenw>
Sure, myunderstanding was backward because I've gone and asked for scaling on a screen that's really too small to need it. That makes sense.
<kchibisov>
If you have a scale of 2 on a 4k display, it feels like 1080p.
<kchibisov>
So if you have a configure of 800x600, you draw a 1600x1200 buffer, but it'll feel like 800x600 in terms of ui scale in it.
<kchibisov>
like 2x bigger of every element in it.
<kchibisov>
it'll still occupy the 1600x1200 of physical pixels on screen, since 2 physical pixels map to one logical, and every positioning/sizing is in logical pixels.
<karenw>
So if I ignore fractional scale. I would draw into a 1600x1200 buffer, and kwin would scale it to 1200x900 screen pixels.
<karenw>
If I use fractional scale, I would draw into a 1200x900 buffer, and kwin would apply no scaling
<kchibisov>
yes.
<kchibisov>
but it'll feel like 800x600 window in both cases.
<kchibisov>
but scaled.
<kchibisov>
(that means that you don't have more space, but rather sharper UI).
<karenw>
Except I'm confusing everything by having my window actually be a vulkan rendering that uses physical pixels.
<karenw>
:D
<karenw>
Now to just work out why maximizing with fractional scaling is resulting in a nonesense aspect ratio
<karenw>
It's still 4:3 despite being maximized on a ~15:9 area. (16:9 minus left side taskbar)
mriesch_ has quit []
mriesch has joined #wayland
<kchibisov>
karenw: the aspect ratio is defined in configure, since multiplying sizes doesn't change it.
<kchibisov>
I'd also assume that you mean fullscreening.
<karenw>
No, I did mean maximized. I was not setting the viewport dest if the size changed but fractionalscaling didn't. *Any* resize after the initial roundtrip was broken.
<karenw>
I assume it's fine to never touch the viewport src as it defaults to "the whole wl_buffer"?
<kchibisov>
karenw: when the size is changed you set the viewport _destination_.
<kchibisov>
So configure -> viewport.set_destination(width, height).
<kchibisov>
you don't touch _source_ generally.
<karenw>
Yup
<karenw>
Well, unless you are using viewport for something other than (fractional) scaling.
yaslam has joined #wayland
adamtajti has quit [Remote host closed the connection]
adamtajti has joined #wayland
<karenw>
Interesting, weston supports wp_viewporter, but doesn't support fractional scale nor wl_compositor v6
<karenw>
That's trivial to support, just seems a strange set of protocols to support
<karenw>
That's trivial for my application to support, just seems a strange set of protocols for weston to choose to support
<kchibisov>
viewporter was way before any of that.
<karenw>
Fair enough, I'm sure there are other uses of viewporter
HyprArch has joined #wayland
kts has joined #wayland
fmuellner has joined #wayland
coldfeet has quit [Remote host closed the connection]
HyprArch has quit [Remote host closed the connection]
rasterman has joined #wayland
Moprius has joined #wayland
Moprius has quit []
sima has joined #wayland
kts has quit [Quit: Leaving]
Fxzxmic has quit [Remote host closed the connection]
yaslam has quit [Ping timeout: 480 seconds]
coldfeet has joined #wayland
yaslam has joined #wayland
kts has joined #wayland
user21 has quit [Ping timeout: 480 seconds]
iomari891 has quit [Ping timeout: 480 seconds]
karenw has quit [Ping timeout: 480 seconds]
OtzmaYehudit has joined #wayland
kts has quit [Quit: Leaving]
OtzmaYehudit has quit []
OtzmaYehudit has joined #wayland
yaslam has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
nerdopolis has joined #wayland
yaslam has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
garnacho has quit [Read error: Connection reset by peer]
garnacho has joined #wayland
CuteMath has joined #wayland
<daniels>
we’d happily take patches for fractional
iomari891 has joined #wayland
kts has joined #wayland
glennk has joined #wayland
yrlf has quit [Ping timeout: 480 seconds]
yrlf has joined #wayland
mxz is now known as Guest9002
mxz_ is now known as mxz
kts has quit [Quit: Leaving]
fabcal has joined #wayland
fabcal has quit []
Fxzxmic has joined #wayland
Fxzxmic has quit []
nerdopolis has joined #wayland
OtzmaYehudit has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
<DemiMarie>
What are some characteristics of well-behaved Wayland clients? I know that they are expected to be fully event-driven, so latency is decoupled from frame rate, but I want to know what arbitrary limits I can impose. Can I assume that a client creating 500 nested popups can be disconnected?
rasterman has joined #wayland
<kennylevinsen>
Having a maximum number of popups is unlikely to cause issues, but such limit is also not very useful. You don’t need to nest popups to be annoying, nor do you need permission to make 500 nested popups to try to DoS the compositor
<DemiMarie>
kennylevinsen: What I am looking for is client behavior that will take untested (and therefore likely buggy) codepaths in compositors.
<DemiMarie>
My job is to ensure that the proxy I am writing always behaves like a well-behaved client and exercises well-tested code paths in the compositor, even if its own client is malicious, all without breaking legitimate clients.
Narrat has joined #wayland
<kennylevinsen>
N > 1 might be untested, but N>500 won’t tell you anything useful other than how well you handle load
<kennylevinsen>
This will likely hold for any parameter: 0, 1 or 2 are the likely numbers revealing bugs - larger numbers might just exaggerate those same bugs, as well as suboptimal CPU and memory utilization. The limit to protect is too low, the practical limit too high.
<soreau>
an arbitrary number, it could be different depending on resources available
<kennylevinsen>
Maybe you could have a configurable maximum number of surfaces as a DoS guard for each domain, configurable being key.
<DemiMarie>
Does this mean that the task I have been given is impossible?
<kennylevinsen>
Trying to guard against untested code paths purely using random restrictions on object counts or other trivial passive checks? I’d say yes.
<kennylevinsen>
I think your effort would be better spent creating a client that intentionally goes past all the limits you have in mind to exercise those code paths :)
<DemiMarie>
And then fixing the bugs in compositors that I run into?
<soreau>
DemiMarie: FWIW, there is wleird
<DemiMarie>
soreau: thanks! I might try extending that.
<DemiMarie>
kennylevinsen: are you saying that if Qubes OS needs a hardened compositor, it should use a hardened compositor and not try to add security with a proxy?
abhimanyu has quit []
Arnavion has quit [Remote host closed the connection]
Arnavion has joined #wayland
lsd|2 has joined #wayland
fmuellner has quit [Read error: Connection reset by peer]
fmuellner has joined #wayland
coldfeet has quit [Remote host closed the connection]
yaslam has quit [Ping timeout: 480 seconds]
<kennylevinsen>
DemiMarie: I am suggesting that the specific hardening approach of such limits would likely be ineffective, and that instead testing the limits (e.g., before packaging) would have *some* effect
fmuellner has quit []
fmuellner has joined #wayland
<kennylevinsen>
The question of whether a proxy can meaningfully increase security is a bit too large and vague, but I do suspect that it’s efficacy will generally be limited as you do not need invalid or even unusual input to hit “untested code” - it can be triggered something as simple as a valid client that is just rarely used with a particular compositor
puck_ has joined #wayland
<soreau>
compositor with a particular configuration, even
<soreau>
we had one wayfire issue where it turned out that gtk4 sends unfullscreen request on/before titlebar drag move request, even though it was windowed, and this tricked wayfire into setting a new geometry for it, which caused an offset jump when you grab-moved it
<soreau>
but it didn't happen in a certain configuration which I happen to use, so it was a bit of a conundrum at first
<soreau>
nothing to do with security really, but bugs can and will crop up where you least expect