ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Group-Deed has joined #wayland
nniro_ has joined #wayland
nniro has quit [Read error: Connection reset by peer]
glennk has quit [Ping timeout: 480 seconds]
ttancos[m] has quit []
Company has quit [Quit: Leaving]
lsd|2 has quit []
astralphnx has joined #wayland
astralphnx has quit [Remote host closed the connection]
vulpes2[m] has quit []
astralphnx has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
astralphnx has quit []
astralphnx has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
kts_ has joined #wayland
kts_ has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
bjorkint0sh has joined #wayland
kts has joined #wayland
Brainium has quit []
nerdopolis has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
bjorkint0sh has quit []
bjorkintosh has joined #wayland
kts has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
privacy has quit [Remote host closed the connection]
mxz__ has joined #wayland
mxz_ has quit [Ping timeout: 480 seconds]
mxz has quit [Ping timeout: 480 seconds]
kts has joined #wayland
kts has quit []
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
sima has joined #wayland
kts has quit [Ping timeout: 480 seconds]
AJ_Z0 has quit [Ping timeout: 480 seconds]
AJ_Z0 has joined #wayland
tristianc67048 has joined #wayland
tristianc6704 has quit [Read error: Connection reset by peer]
kts has joined #wayland
mxz__ has quit [Ping timeout: 480 seconds]
mxz has joined #wayland
kts has quit [Ping timeout: 480 seconds]
mxz_ has joined #wayland
kts has joined #wayland
glennk has joined #wayland
bodiccea has joined #wayland
Guest7393 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest7432
Guest7432 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ is now known as Guest7433
rv1sr has joined #wayland
IMTheNachoMan has quit []
manuel1985 has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest7436
zvarde19883032067791916857 has joined #wayland
Guest7433 has quit [Ping timeout: 480 seconds]
Guest7436 has quit [Ping timeout: 480 seconds]
mart has joined #wayland
zvarde1988303206779191685 has quit [Ping timeout: 480 seconds]
zvarde19883032067791916857 is now known as zvarde1988303206779191685
slim has joined #wayland
JakeSays has quit [Quit: later..]
JakeSays has joined #wayland
cool110_ has joined #wayland
cool110_ is now known as Guest7439
guy has joined #wayland
guy has left #wayland [#wayland]
Satan has quit [Remote host closed the connection]
Satan has joined #wayland
garnacho has joined #wayland
kts has quit [Read error: Connection reset by peer]
zvarde19883032067791916858 has joined #wayland
zvarde1988303206779191685 has quit [Ping timeout: 480 seconds]
zvarde19883032067791916858 is now known as zvarde1988303206779191685
feaneron has joined #wayland
feaneron has quit []
feaneron has joined #wayland
feaneron has quit [Read error: Connection reset by peer]
astralphnx has quit [Remote host closed the connection]
KDDLB has joined #wayland
fmuellner has joined #wayland
Ps1-Jack has joined #wayland
Psi-Jack has quit [Ping timeout: 480 seconds]
privacy has joined #wayland
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
luna__^ is now known as bittin
<kennylevinsen>
I wonder if anything bad would happen if a compositor decided to only advertise a single wl_output global, hiding all details about its output layout and having the scale just follow the preferred scale
<kennylevinsen>
(ignoring privileged protocols requiring knowledge about the actual outputs like wlr_layer_shell and wlr_output_power_management of course)
<daniels>
kennylevinsen: 'the' preferred scale being the one we'd send as preferred_scale for unmapped surfaces?
<kennylevinsen>
Hmm yes this falls apart when you have multiple surfaces from the same client
<kennylevinsen>
on multiple outputs
<kennylevinsen>
well, you could make the hack worse with an output per active scale... :)
<drakulix[m]>
kennylevinsen: I think the only immediate issue here is api consuming outputs as targets not working as expected.
<drakulix[m]>
xdg_toplevel::set_fullscreen most prominently, but also stuff like layer_shell or screencopy.
<kennylevinsen>
yeah, set_fullscreen is one thing but I don't think an application can provide a usable value as argument anyway
<davidre>
set_fullscreen can be useful for things like libreoffice impress
<YaLTeR[m]>
configure bounds as well
<davidre>
Where you can select a presentation screen
<davidre>
and a notes screen
<YaLTeR[m]>
ah, bounds is on the toplevel
<YaLTeR[m]>
nvm
<Consolatis>
kennylevinsen: out of interest, why do you think an application can not provide a usable value as argument for set_fullscreen?
<kennylevinsen>
The application does not know the output placement and preferences, nor might it necessarily know the dimensions.
<kennylevinsen>
So it does not know what screen is a good "presentation screen" for example. We had a discussion the other day about instead having the client associate a presentation content type with the surface, so that the compositor can pick a good output for presentation (say, an external monitor/projector instead of the laptop screen)
kts has joined #wayland
<kennylevinsen>
even if it did have full output layout information, The Wayland Way is to leave this up to compositor policy.
<swick[m]>
I would really like a set_fullscreen without outputs but surfaces giving hints towards what they are, and then some functionality for the app to request moving the fullscreen window to another output.
<swick[m]>
but I also really would like a set_fullscreen thing that can span over multiple outputs
<davidre>
<kennylevinsen> "So it does not know what..." <- But it knows by the balue of it having literally settings for it
<kennylevinsen>
and how would those settings work, when apps do not know anything about the outputs?
<Consolatis>
the decision might also come from some setting set by the user in the application, based on the output globals
<davidre>
yes
<kennylevinsen>
The application will not be able to present a very usable presentation of these though
<kennylevinsen>
So if a newer version of wl_output is used you can say "DP-9", but that's more or less it
<kennylevinsen>
This won't work for the presentation use-case for example
<davidre>
But it works
<kennylevinsen>
With modern laptops, the actual port changes like the wind, and it won't be configured in advance
<davidre>
Libreoffice literally has that setting
<kennylevinsen>
It might have a setting, but it won't do anything in many compositors and even if it did it cannot be set to the right thing
<Consolatis>
usually users know what their monitors are called though (e.g. the vendor / model) or where they are connected. I think allowing applications to target a specific output when requesting fullscreen is a good thing (even though most would just supply NULL) there and let the compositor decide.
<kennylevinsen>
what we discussed is a solution that lets libreoffice always do the right thing
<kennylevinsen>
You don't, specifically, in the presentation scenario know in advance. You just plug in a laptop to a random meeting room screen, and a new output with an unknown name and random connector shows up
<kennylevinsen>
You could try to go the other way and pick a random monitor that *isn't* the laptop monitor, but then we're also getting a bit fragile
<davidre>
How would a compositor know a random output is "a presentation output"
<kennylevinsen>
This is also before we start considering less standard scenarios, like large screens or VR where you might want the placement not to be "a screen" but "place and suitable dimensions for presentation"
<davidre>
It would need user configuring ahead of time as well
<kennylevinsen>
you most definitely do not want a powerpoint presentation to be fullscreen on an ultrawide
<davidre>
or random heuristics
rasterman has quit [Quit: Gettin' stinky!]
<Consolatis>
right, I am not saying that there couldn't be other solutions but that should IMHO not result in the existing ability to be removed as it has its purpose.
<kennylevinsen>
It is not really an existing ability. The current implementation is a hint ignored by many compositors.
<Consolatis>
well, that is up to the compositor and the user choosing that compositor then :)
<drakulix[m]>
Cosmic does as well, but I don't think that is the point. The issue at hand is leaving this issue either completely to application (status quo) and thus also their settings ui or being able to potentially configure this globally in the compositor (which still could offer per-app preferences).
<kennylevinsen>
Looking at wlroots compositors, I'm actually slightly surprised that sway seems to respect it. River, hikari, clay doesn't. niri does.
<drakulix[m]>
I don't think anybody disagrees that the current "solution" works most of the time in practice (and is what users coming from other OSes expect). I would still argue it is clunky and that the compositor has more information.
<kennylevinsen>
yeah the current solution was respected in more places than I anticipated, but I stand by that the compositor can make a better decision and be a better place to have logic for and configure what a good "presentation" output is
<kennylevinsen>
(the compositor has the full EDID, DRM props including connection path, connection time and possibly history, and even if you had to set it manually, telling the compositor once where you present would the user to specify once and have all apps follow, rather than needing to fix this independently in many apps)
<kennylevinsen>
*would let the user
<zamundaaa[m]>
I don't think anyone here is saying that the app deciding the output is a better design, but we can add a better API without removing the old one in this case
<zamundaaa[m]>
If it works well enough, apps that aren't games will port over to it
Brainium has quit [Quit: Konversation terminated!]
Lyude has quit [Ping timeout: 480 seconds]
<bjorkintosh>
thank you.
rasterman has joined #wayland
Lyude has joined #wayland
IMTheNachoMan has quit [Quit: Connection closed for inactivity]
<KarenTheDorf>
A wl_keyboard can't have focus on multiple windows right? (But there can be multiple wl_seats, each with their own wl_keyboard and therefore focus)
<KarenTheDorf>
More formally: there will always be a wl_keyboard::leave before a new wl_keyboard::enter?