ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
Serus has joined #wayland
ahartmetz has quit [Quit: Konversation terminated!]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
naveenk2 has joined #wayland
hergertme has quit [Read error: Connection reset by peer]
rpigott has quit [Remote host closed the connection]
rpigott has joined #wayland
maxzor has quit [Ping timeout: 480 seconds]
zebrag has quit [Quit: Konversation terminated!]
Net147 has quit [Quit: Quit]
Net147 has joined #wayland
naveenk2 has quit []
Seirdy has joined #wayland
hergertme has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
naveenk2 has joined #wayland
naveenk2 has quit [Ping timeout: 480 seconds]
naveenk2 has joined #wayland
shankaru has joined #wayland
CME has quit [Ping timeout: 480 seconds]
CME has joined #wayland
danvet has joined #wayland
dcz_ has joined #wayland
manuel__ has quit [Ping timeout: 480 seconds]
shankaru has quit [Read error: Connection reset by peer]
MajorBiscuit has joined #wayland
Major_Biscuit has joined #wayland
duxsco has joined #wayland
MajorBiscuit has quit [Ping timeout: 480 seconds]
rpigott has quit [Read error: Connection reset by peer]
rpigott has joined #wayland
___nick___ has joined #wayland
pnowack has joined #wayland
manuel__ has joined #wayland
ahartmetz has joined #wayland
maxzor has joined #wayland
shashanks has joined #wayland
shashank_s has joined #wayland
lxsameer2 has joined #wayland
shashank_sharma has quit [Ping timeout: 480 seconds]
jmdaemon has quit [Ping timeout: 480 seconds]
shashanks has quit [Ping timeout: 480 seconds]
mvlad has joined #wayland
rasterman has joined #wayland
lxsameer2 has quit [Ping timeout: 480 seconds]
Company has joined #wayland
ahartmetz has quit [Quit: Konversation terminated!]
shashank_s has quit [Ping timeout: 480 seconds]
lxsameer2 has joined #wayland
hardening has joined #wayland
<DemiMarieObenour[m]>
pq: How big is libdisplay-info, and how of that code is parsing and processing EDID? I want to make sure it is robust against malicious EDID.
<emersion>
it's pretty small right now
<emersion>
0 lines of code ;)
<emersion>
EDIDs have a fixed block size
<emersion>
so that almost completely removes a whole class of vulns
<emersion>
d_ed: i'm on leave the whole time range ;_;
<d_ed>
then I shall do some ninja editing
<d_ed>
when are you back?
<emersion>
2022-04-27
<emersion>
or sometime this week before friday could also work
<emersion>
but probably too short notice for others
<emersion>
sorry for the fuss
<d_ed>
np
<d_ed>
changed it to this Thursday and Friday
<d_ed>
and can see if others fill things in soon
<d_ed>
if they don't, we'll try for the end of the month
<emersion>
thx
duxsco has quit [Quit: duxsco]
<marex>
in weston, is there some way to enforce vblank_mode=3 server-side ?
<marex>
or rather, compositor-side
<daniels>
no
<daniels>
aiui, the main thing of vblank_mode=3 is to force the client to block and pace itself to the refresh interval
<daniels>
the compositor can't force the client to not return from eglSwapBuffers
shashanks has joined #wayland
<marex>
daniels: I am looking for a way to pace a client on a ... blob ... driver
<marex>
daniels: with mesa drivers, vblank_mode=3 just works perfectly
<kennylevinsen>
there is nothing the compositor can do
<marex>
but on this ... stuff ... this is unsupported
<daniels>
marex: yeah, if you don't control either the clients or the blob to add pacing into them, you're down to doing stupid things with LD_PRELOAD
<marex>
LD_PRELOAD ?
<marex>
what can I do with that ?
<kennylevinsen>
you can inject implementations that override your blob
<marex>
(I loathe the blob ... good thing I can avoid it)
<kennylevinsen>
Bad Things™
<daniels>
provide a preload wrapper library that intercepts eglCreateWindowSurfaceEXT (or whatever) and eglSwapBuffers() and uses that to enforce wl_surface.frame
<daniels>
it's a really really bad idea
<marex>
well wait ... if that's what it is, I can just patch the application, no ?
<marex>
i.e. the client
<daniels>
yes
<daniels>
all vblank_mode=3 does is force clients to use eglSwapInterval(1)
<daniels>
so you can just ... make them use eglSwapInterval(1)
<kennylevinsen>
assuming eglSwapInterval(1) works as expected on the blob driver :P
<marex>
ahhhh
<marex>
kennylevinsen: that
<kennylevinsen>
(if eglSwapInterval(1) doesn't work at all, then your remaining option is to do manual frame scheduling in the client.)
<kennylevinsen>
(or something extremely terrible with LD_PRELOAD where you hook wl_surface.commit itself)
<daniels>
or sit down and talk with them about using etnaviv instead
<marex>
daniels: already done, this is the legacy goo
<marex>
thaks, I'll try the eglSwapInterval(...1)
<daniels>
kennylevinsen: you can just hook eglSwapBuffers and force a frame wait
<kennylevinsen>
yeah true
<pq>
or as said, if you can patch the app, wait for the previous frame callback and do a wl_surface_frame() just before calling eglSwapBuffers.
<marex>
so far the application is glmark, so I surely can
shashank_sharma has joined #wayland
shashank_s has joined #wayland
shashanks has quit [Ping timeout: 480 seconds]
shashank_sharma has quit [Ping timeout: 480 seconds]
devilhorns has quit [Remote host closed the connection]
devilhorns has joined #wayland
nerdopolis has joined #wayland
<kchibisov>
Were there discussions wrt ordering of layer surfaces or at least visibility guarantees?
duxsco has joined #wayland
<pq>
related to the layer shell, or?
<kchibisov>
yes.
<kchibisov>
Since right now sway opens new background layer bellow the current background layer and I'm not sure any compositor should do so.
<kchibisov>
Since it basically means that you can't temporary use background layer.
<kennylevinsen>
jadahl: I'm on vacation, so if I'm lucky I've also had some alcohol before the call :D
<kennylevinsen>
I feel liek that's needed
<kchibisov>
emersion: yeah, it just seems a bit strange that new background layer is always being opened below the current one.
<kchibisov>
Since user won't ever see new windows.
<kennylevinsen>
that's also why I only had a late night slot, my wife would strangle me if I interrupted sight-seeing with open source video calls :S
<jadahl>
kennylevinsen: its holiday the day after so it's not unlikely I'll be tipsy as well
<kennylevinsen>
we should aim for it, a little lubrication makes the discussion flow better
<jadahl>
we'll end up hand wave away all problems
<jadahl>
"it'll be fine, lets deal with it another day" is a common flaw of being tipsy
<kennylevinsen>
beer goggles might also blur any rendering problems
<kchibisov>
emersion: but I think the order in the same namespace is also undefined?
<emersion>
yes
<kchibisov>
it's kind of sad, given that swaybg out1.jpg, swaybg out2.jpg will always show first.
<kchibisov>
something like 'layers in the same namespace are ordered in the order of appearing on screen or something'.
<kchibisov>
Or is there a motivation for the undefined ordering?
<emersion>
well, another user may come up tomorrow arguing that the old behavior should be retained
<emersion>
it's kind of arbitrary anyways
<kchibisov>
I'm not sure why anyone would like to open invisible windows.
<jadahl>
kennylevinsen: excellent point
<emersion>
and should def not be in the protocol (just like xdg-toplevel doesn't guarantee any z-order between surfaces)
<kchibisov>
I guess, but it's probably a sway specific bug then and the way to solve is user defined ordering for layers?
<kchibisov>
Though, I wonder if specifying ordering preference in protocol would make sense?
<kchibisov>
e.g. above/below/don'tcare
<emersion>
that sounds like you're just adding more layers
<kchibisov>
Yeah, I guess.
<emersion>
and a client isn't aware of other clients
<emersion>
so can't make a meaningful decision
<kchibisov>
The problem is that I want to put something on background layer without reloading sway and disabling background image.
<kchibisov>
but bottom layer should be above that layer.
<kchibisov>
e.g. run `swaybg image` and preview it before reloading sway and changing background image.
<emersion>
can't you kill the old swaybg?
<kchibisov>
well, and how would I bring it back?
<emersion>
if it's going to be hidden,no point in keeping it around
<emersion>
spawn it again
<varbhat>
emersion,if you don't mind me asking, what Wayland setup do you daily drive ?
<kchibisov>
I could open transparent background overlay on top of background?
<emersion>
kchibisov: I think I don't understand your use-case properly
<emersion>
varbhat: just sway
<kchibisov>
I mean my use is to being able to see the window I'm opening without killing other windows.
<kchibisov>
Since I'd like to open e.g. swaybg for a short period of time for preview.
<kchibisov>
if it requires me 'killall swaybg, swaybg new_image; swaymsg reload' I don't really like it.
<varbhat>
emersion: do you use swaybar or waybar? if swaybar,then do you use program such as i3status ?
<kchibisov>
Or if I want to open some overlay on top of swaybg, I'd basically should `killall swaybg; overlay; swaybg`.
<kchibisov>
To sum up, I want to open something without killing swaybg I've specified in compositor config, since the application I'm opening is for short term and should persist.
maxzor has quit [Ping timeout: 480 seconds]
Major_Biscuit has quit [Ping timeout: 480 seconds]