ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
glennk has joined #wayland
kts has joined #wayland
nerdopolis has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
Company has quit [Quit: Leaving]
Guest4510 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest4623
kts has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
Guest4623 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest4633
Leopold__ has quit [Remote host closed the connection]
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
floof58 has quit [Ping timeout: 480 seconds]
mbalmer has joined #wayland
<wlb>
wayland Merge request !349 closed (scanner: export interface should use protected visibility)
floof58 has joined #wayland
<pq>
heh, interesting to use Rust syntax highlighting for a gdb stack trace in Gitlab :-)
<pq>
oh my, I can resolve threads in Gitlab issues now!
qaqland has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
mvlad has joined #wayland
andyrtr_ has joined #wayland
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ is now known as andyrtr
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
pochu has joined #wayland
pochu_ has quit [Ping timeout: 480 seconds]
Moprius has joined #wayland
carlos_ has quit [Remote host closed the connection]
carlos_ has joined #wayland
Company has joined #wayland
<WhyNotHugo>
From an end-user perspective, is there a different between maximised and fullscreen? Or are the differences merely implementation details?
<emersion>
might want to draw decorations when maximized but not fullscreen
<kennylevinsen>
And maximized does not necessarily fill the screen
<WhyNotHugo>
kennylevinsen: maximised is limited by the size in set_max_size?
<emersion>
set_max_size is a hint that the window may not like being maximized
<emersion>
but the compositor can still put the window in that state afaiu
<kennylevinsen>
maximized could be some size chosen by the compositor for a "large" window - imagine an ultrawide monitor, where most apps make no sense in fullscreen
<kennylevinsen>
yeah min_size and max_size are worded rather weakly right now...
glennk has quit [Ping timeout: 480 seconds]
<WhyNotHugo>
I guess that set_max_size could also be taken as a hint that the window doesn't like to be fullscreened?
<emersion>
not necessarily -- the client can pick whatever size it wants in fullscreen mode
kts has quit [Ping timeout: 480 seconds]
<WhyNotHugo>
True. Weird, but true :P
<WhyNotHugo>
So maximised is something like "largest preferred size", not really fullscreen.
<kennylevinsen>
yes, and not exclusive like fullscreen requires
<zamundaaa[m]>
Fullscreen doesn't require exclusivity either
<emersion>
right, some compositors might have weird fullscreen modes
<emersion>
like covering all outputs, or covering just part of an output
<WhyNotHugo>
I see that my confusion was not unjustified.
glennk has joined #wayland
<kennylevinsen>
hmm? the spec states that if the surface does not cover the entire wl_output, the compositor will fill the rest, and that the compositor will ensure nothing else is visible through transparency
<kennylevinsen>
doesnt' cover the multi-output fullscreen case, but it's arguably a mistake to mention wl_output's here in the first place...
<pq>
What's an output if not wl_output?
<kennylevinsen>
if your fullscreen spans multiple outputs
<zamundaaa[m]>
I was more referring to the fact that you can have windows on top of the fullscreen window. Or a fullscreen window only spanning one tile
<pq>
No, I mean in general. If you write a spec for fullscreen, how do you define an "output"?
<kennylevinsen>
zamundaaa: one tile would conflict with the specific mention of output
<WhyNotHugo>
The way the spec is worded, it would seem that "fullscreen" covers 100% of a single output. If you have a 2x2 grid of monitors tiled together, fullscreen will only cover one.
<ascent12>
That assumes that output = monitor, which isn't something Wayland says
<pq>
WhyNotHugo, IMO that depends on how the monitor grid is exposed, as a single output or four outputs. (wl_outputs?)
<ascent12>
The vagueness gives compositors a lot of flexibility to do neat/werid things
<zamundaaa[m]>
what the spec says and what compositors do in practice aren't necessarily the same things
<WhyNotHugo>
Outputs have a make and model. It kidna leads you to think that 1 monitor is 1 output. Does any compositor currently allow configuring a grid of monitors as a single output?
<pq>
WhyNotHugo, wl_output has a make and model. "Output" might be something else, which we are trying to find out here. :-)
<pq>
besides, wl_output is one of the oldest interface still existing, and has met lots of critique.
<kennylevinsen>
pq: Hmm, I'd probably try to avoid it to not explicitly rule out e.g. the fullscreen-to-tile case zamundaaa mentions. Maybe "expanded to fill exclusively fill a larger area" rather than say output? idk
<WhyNotHugo>
kennylevinsen: A compositor can expose the entire grid of outputs as a virtual output (e.g.: another wl_output instance). It can then be passed as an argument to set_fullscreen without API changes.
<pq>
most of the events in wl_output probably should not exist
<kennylevinsen>
indeed
qaqland has joined #wayland
<pq>
WhyNotHugo, good point.
<kennylevinsen>
the argument to set_fullscreen is not particularly useful, as the app won't understand the grid - but yes, there could be arbitrary even overlapping outputs
<pq>
there are some technical details like the monitors in the grid should all be gen-locked if presentation-time is intended to be accurate
<WhyNotHugo>
kennylevinsen: That's the whole point: the grid is opaque to the client and looks like just one single big output (which is the intent).
<zamundaaa[m]>
WhyNotHugo: that doesn't work for any other case though. Exposing a wl_output per tile sounds like it might cause lots of fun issues
<pq>
might? Maybe. Hard to come up with an example, though.
<pq>
I think the protocol development has been quite good recently to move away from wl_outputs in general.
<WhyNotHugo>
I think recent protocol development reflects a lot of lessons learnt from the initial ones (I say this as a form of praise).
<MrCooper>
WhyNotHugo: hmm, I wonder if Xwayland could cope with such a virtual output though :/
nerdopolis has quit [Ping timeout: 480 seconds]
<WhyNotHugo>
Oh, yeah, if that tiled-output spans monitors connected to different GPUs then I can see how several things would quickly become a problem.
rasterman has quit [Quit: Gettin' stinky!]
qaqland is now known as Guest4691
Guest4691 has quit [Read error: Connection reset by peer]
qaqland has joined #wayland
io_ has joined #wayland
<zamundaaa[m]>
That would not be a problem at all, as the compositor is the one handling multi gpu, not Xwayland
<kennylevinsen>
WhyNotHugo: when wl_output is entirely arbitrary it also erases all meaning of a wl_output reference - the client cannot make sense of being entered on 12 different overlapping outputs, nor can it select one meaningfully
<kennylevinsen>
we're just bending the definition of the object to get around the fact that it's needed, and in that case it would be nicer if it just wasn't needed in the first place
<kennylevinsen>
but it's what we're stuck with for now so oh well :P
tristianc6704 has quit [Read error: No route to host]
<WhyNotHugo>
Formerly, clients needed output::enter to figure out a scale. With the new scaling protocols, do regular clients actually need to deal with outputs at all?
<emersion>
some clients still use subpixel
* kennylevinsen
shakes fist at subpixel rendering
<emersion>
some toolkits insist on exposing the output layout in their API
tristianc6704 has joined #wayland
iomari892 has joined #wayland
iomari891 has quit [Read error: Connection reset by peer]
carlos_ has quit [Ping timeout: 480 seconds]
<Company>
GTK wants to know the likely scale
<Company>
so it can create resources before creating surfaces
<Company>
ie in gtk_init()
<Company>
and when initializing resources from a UI file, which happens before allocation of surfaces
<Company>
and we use the scale of the first output for that
<kennylevinsen>
wouldn't picking the largest scale be better than first scale?
<Company>
dunno
<d_ed[m]>
even then you have an int -> fractional problem
<Company>
GTK3 used to pick the scale of the primary output
<Company>
but Wayland doesn't have that
<Company>
GTK's APIs are all ints
<Company>
so that number is either 1 or 2
<kennylevinsen>
yeah, have to wait for gtk5 for fractional scale
<Company>
o_O
<Company>
or you just use 4.12
<Company>
the bigger problem is that the whole asset infrastructure - ie icons - uses PNGs
<Company>
and so far nobody has volunteered to make it do all the caching and whatnot with fractions
<Company>
and figure out what scales to save PNGs at because loading SVGs is slow
<Company>
don't want inkscape or gimp to take twice as long to start just because it's scaling SVGs
<kennylevinsen>
if you're spending time scaling svgs something is wrong :P
<kennylevinsen>
drawing svgs or scaling pngs however...
<Company>
yeah
<Company>
I want the artist community to agree on a scalable format for icons
<Company>
but the artist community is not a fan of scalable formats anyway, they want their lines to be pixel-perfect
glennk has quit [Ping timeout: 480 seconds]
<Company>
so there's been lots of friction and burnout with people trying to push things
* kennylevinsen
can't wait for resolutions to get high enough that pixel perfect becomes irrelevant
<Company>
plus, there's no free tools other than inkscape really
<Company>
and SVG is this huge format and nobody has a fast and well-maintained renderer for a subset that everyone can agree on
<Company>
plus, so far with Gnome just doing 1x or 2x, you could just pre-render all the assets
<kennylevinsen>
not sure what state pathfinder is in, but yeah - could maybe use a less xml-ey overhaul
<Company>
you don't want to throw pathfinder at your icons 60 times per ssecond
<Company>
and if you're caching anyway, you can probably render things with a slow SVG renderer
<Company>
minus the startup issue
<kennylevinsen>
you also presumably don't decode pngs from disk 60 times per second, so either way you'd rasterize to a buffer and go from there
<kennylevinsen>
why do it slow if you can do it fast
<Company>
(GTK3 color-converts pngs 60 times per seconds)
<Company>
(because PNGs are GdkPixbufs and those are unpremultiplied RGBA and cairo wants premultiplied BGRA)
<Company>
(don't tell anyone)
<Company>
actually, GTK3 doesn't do it 60 times per second, it's not that fast
<d_ed[m]>
FWIW, we (qt/kde) have a relatively slow SVG renderer with a runtime png cache so we can do things natively at the right scale and it's fine
<Company>
d_ed[m]: we probably could, too, if anyone wanted to improve the existing asset pipeline - but I'd rather get a better asset pipeline
<Company>
the font pipeline deals with this scaling stuff way better for example
<Company>
kennylevinsen: side note: GTK is planning to add something like pathfinder to its renderer, too
iomari892 has quit [Read error: Connection reset by peer]
luna has left #wayland [#wayland]
iomari892 has joined #wayland
___nick___ has joined #wayland
lordmzte has joined #wayland
<lordmzte>
Hello and sorry if I'm asking in the wrong place: Is it possible to create a `zwlr_layer_surface` using the `zwlr-layer-shell-unstable-v1` protocol that spans all outputs? I'd like to create a desktop background application that spans all monitors. Thanks!
<emersion>
no, you need to create one per output
<YaLTeR[m]>
I think you need a surface per output
<lordmzte>
Alright, thanks!
glennk has joined #wayland
navi has joined #wayland
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
Guest4633 has quit [Ping timeout: 480 seconds]
<kchibisov>
When wl_compositor@v6 is being used should client still fallback to output scale when the compositor doesn't ever send `prefered_buffer_scale`? I'd assume no, and client should use this event or assume 1?
<vyivel>
i'd assume scale 1
<emersion>
yeah, scale 1
<emersion>
iirc the protocol says so
rasterman has joined #wayland
<kchibisov>
emersion: it doesn't.
<kchibisov>
But clients shouldn't fallback to output based scaling, right?
<kchibisov>
The protocol doesn't say so, but probably should.
<emersion>
hm, it was discussed in GitLab
<kchibisov>
🤔
<emersion>
but yeah apparently not in the protocol
<emersion>
clients shouldn';t fallback no
<kchibisov>
yeah, exactly.
<kchibisov>
I just got asked "why do you think that they shouldn't".
<kchibisov>
I can't just reply that there's no way anyone meant to do fallbacks...
<YaLTeR[m]>
It's not obvious when you haven't followed the discussion
<kchibisov>
YaLTeR[m]: you should just feel the wayland over the years.
iomari891 has joined #wayland
<YaLTeR[m]>
If I let too much wayland into my veins, I'll be unable to use google maps as I'll lose my global positioning