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]
Leopold_ has joined #wayland
sgm has quit [Quit: sgm]
co1umbarius has joined #wayland
sgm has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
cool110- has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest784
Leopold_ has quit [Remote host closed the connection]
garnacho has quit [Ping timeout: 480 seconds]
Dami_Lu has quit [Remote host closed the connection]
Dami_Lu has joined #wayland
Guest784 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest790
nerdopolis has quit [Ping timeout: 480 seconds]
sgm has quit [Remote host closed the connection]
sgm has joined #wayland
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
Company has quit [Quit: Leaving]
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
glennk has joined #wayland
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
qaqland has quit [Ping timeout: 480 seconds]
qaqland has joined #wayland
mxz has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
jkl has quit [Quit: Gone.]
Leopold_ has joined #wayland
mxz has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
kts has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
peeterm has joined #wayland
Leopold has quit [Remote host closed the connection]
Leopold has joined #wayland
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
sima has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has quit [Remote host closed the connection]
kts has joined #wayland
privacy has quit [Quit: Leaving]
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #wayland
<emersion>
pq, do you think it's fine if instead of the usual "child object inherits parent version" rule, it inherits another object
<emersion>
's poassed as argument?
<emersion>
passed*
<emersion>
e.g.
<emersion>
external_iface.foo(wl_data_device, new id wl_data_source)
<emersion>
where wl_data_source version is inherited from wl_data_device
<kchibisov>
The configure state in xdg_shell is double buffered, how it should work when I don't really need to draw? Like for example, my window is marked as suspended, should I just do wl_surface.commit and not draw? Or should I draw/finish drawing and stop drawing from the next loop iteration?
<kchibisov>
The same with activated, for example, activated doesn't result in the top-level commit/redraw in my case, but I just redraw subsurfaces in desync way, thus commit them.
<kchibisov>
But not the top-level surface.
<vyivel>
yeah just ack+commit without attaching a buffer
<kchibisov>
And I _must_ do that?
<vyivel>
preferably?
<kchibisov>
Like it's just I don't want commit on behalf of the user.
<kchibisov>
So they must draw via the infra I define.
<kchibisov>
Like the concept that you _commit_ some object you usually use for drawing is a bit weird.
<vyivel>
the idea is that you redraw in response to the configure
<kchibisov>
yeah, but suspended tells you to stop doing so.
<vyivel>
yeah this one's a bit weird
<vyivel>
iirc alacritty doesn't respond with a commit to it?
<kchibisov>
yeah.
<kchibisov>
well, it's winit problem in general.
<kchibisov>
Like we tell that once the window is Occluded you should stop drawing.
<vyivel>
it probably should respond without a buffer
<kchibisov>
Because it's common concept on all the platforms.
poke has joined #wayland
<kchibisov>
Yeah, but if you do multithreaded rendering and have a buffer in-flight it'll cause issue if you commit on behalf of the user.
<vyivel>
on the other hand, if the window is suspended, that's because it's invisible, so the compositor doesn't really care if it's updated or not…
<kchibisov>
yeah, but it may think that the state is not applied.
<kchibisov>
Thus it'll think that the window is not suspended.
<emersion>
clients are supposed to ack to configures in a timely manner'
<kchibisov>
yeah, I ack the things, the problem is commit.
<kchibisov>
Like I ack configure, but don't commit/draw if it's suspended state.
<emersion>
i mean ack+commit, an ack alone just populates the pending state
<vyivel>
can/does winit signal to the app that a redraw is required?
<kchibisov>
yeah, it can.
<kchibisov>
like it's not an issue, it's just probably will start masking some bugs.
<kchibisov>
Like the one when your window is suspended from the start.
<emersion>
can winit ask the app to redraw with an empty damage?
<kchibisov>
Hm, not yet, but I see what you're suggesting.
<kchibisov>
I guess for now I'll change to force redraw.
<kchibisov>
And then I'll change to somehow not really force redraw.
<kchibisov>
My main issue is that this concept can't be automatically added to some abstraction, because it's a wayland unique behavior.
<kchibisov>
Probably drawing one more time won't hurt, since damage tracking is on behalf of the client...
<kchibisov>
Hm, if I draw with vsync will I block when I get suspended state and commit a buffer with it?
<kennylevinsen>
It suggests that a surface frame callback might not fire anytime soon
<kchibisov>
yeah, so it wants an wl_surface.commit() without a draw.
<kchibisov>
Because asking me to draw here will block the clients.
<kchibisov>
I guess I'll just remove the suspended handling for now.
tzimmermann has quit [Quit: Leaving]
kenny has joined #wayland
AnuthaDev has quit []
kts has quit [Quit: Leaving]
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #wayland
___nick___ has joined #wayland
rasterman has quit [Ping timeout: 480 seconds]
nniro has quit [Remote host closed the connection]
nniro has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
rv1sr has joined #wayland
___nick___ has joined #wayland
JayBeeFOSS has quit [Ping timeout: 480 seconds]
JayBeeFOSS has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
Leopold_ has joined #wayland
<YaLTeR[m]>
mhm, some clients seem to treat zwlr_foreign_toplevel_handle_v1 state activated like the keyboard focus (i.e. only one window can have it)
Leopold_ has quit [Remote host closed the connection]
<YaLTeR[m]>
i suspect adding keyboard focus into there could help
mclasen has quit []
mclasen has joined #wayland
<emersion>
keyboard focus may not be exclusive either
<emersion>
there is multi-seat, and nothing in the spec prevents compositors from giving keyboard focus to multiple clients
nniro_ has joined #wayland
<YaLTeR[m]>
right
nniro has quit [Ping timeout: 480 seconds]
<kchibisov>
I just feel like fcitx a little bit abused it with per toplevel ime state.
<kchibisov>
Like it's a very useful feature when you use more than 2 languages at the same time, but probably there should be something else or maybe input-method-v2 itself should kind of broadcast focus.
<kchibisov>
Though, input-method-v2 is not seat aware as well iirc.
<emersion>
oh it's for fctix? yeah that wasn't designed for this at all…
<YaLTeR[m]>
emersion: sfwbar really dislikes multiple activated windows, and Waybar's taskbar handles them correctly but design-wise it really should be keyboard focus instead for indicating the "active" window
<emersion>
for a bar "active" seems the right thing to use
<emersion>
some devices don't have keyboards btw
<YaLTeR[m]>
i.e. I keep the active window on every workspace activated even when it's not the active workspace, so that switching workspaces doesn't cause unneeded window animations. This means the bar will show a lot of active windows, that's really not what you want to see on a taskbar
alatiera has joined #wayland
<YaLTeR[m]>
emersion: as a desktop compositor you can still track what the keyboard focus would be
<YaLTeR[m]>
oh oops i replied
<YaLTeR[m]>
oh that actually did the right thing on the irc side, nice
<emersion>
i'd rather not go deeper into the design mistake of "there will always be a keyboard"
<soreau>
this sounds like something that has more to do with compositor policies than protocol design choices
<emersion>
yeah…
<soreau>
for instance, the compositor could send active for only the window with focus if it's on the current workspace
<soreau>
and if you're doing things to avoid unecessary animations.. seems like your compositor could have an option or fix for this
<YaLTeR[m]>
like, that's what I will end up doing for my foreign toplevel impl, because that's what the clients seem to expect. Despite the fact the protocol says the states are the same as xdg-shell
<emersion>
"active" is about visual feedback
<emersion>
which is exactly what the bar wants to do
<kchibisov>
I think the right solution would be to add more tracking into input-method-v2.
<kchibisov>
Since a lot of IMEs kind of handles all the input.