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
fmuellner has quit [Ping timeout: 480 seconds]
gusnan_ has left #wayland [#wayland]
herbcat has joined #wayland
Seirdy has quit [Quit: exiting 3.2]
Seirdy has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
wolfshappen has quit []
glennk has joined #wayland
herbcat has quit []
<DemiMarieObenour[m]>
<soreau> "wayland and weston were named..." <- Interesting. I thought Wayland was named after Wayland the smithy.
cyberpear has quit [Quit: Connection closed for inactivity]
wolfshappen has joined #wayland
wangledorf_ has quit [Read error: Connection reset by peer]
wangledorf_ has joined #wayland
boistordu_ex has joined #wayland
boistordu_old has quit [Ping timeout: 480 seconds]
wangledorf_ has quit [Ping timeout: 480 seconds]
ofourdan_ has joined #wayland
ofourdan has quit [Ping timeout: 480 seconds]
<whot>
DemiMarieObenour[m]: i think plymouth was named after that scheme too, and possibly others
<DemiMarieObenour[m]>
Is there a Wayland version of `WM_NORMAL_HINTS`?
<DemiMarieObenour[m]>
That allows clients to specify a size they must be a multiple of.
<DemiMarieObenour[m]>
Terminal emulators need it
boistordu_old has joined #wayland
boistordu_ex has quit [Remote host closed the connection]
ecocode_ has quit [Read error: Connection reset by peer]
ecocode_ has joined #wayland
JPEW_ has joined #wayland
pedro1___ has joined #wayland
zmike_ has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
daniels has quit [Ping timeout: 480 seconds]
daniels has joined #wayland
pedro1__ has quit [Ping timeout: 480 seconds]
JPEW has quit [Ping timeout: 480 seconds]
pedro1___ has quit []
zmike has quit [Ping timeout: 480 seconds]
wangledorf_ has joined #wayland
yoslin has quit [Quit: WeeChat 3.3]
yoslin has joined #wayland
leon-p_ has joined #wayland
leon-p has quit [Ping timeout: 480 seconds]
yoslin has quit [Quit: WeeChat 3.3]
yoslin has joined #wayland
leon-p_ has quit []
leon-p has joined #wayland
leon-p has quit [Quit: leon-p]
tzimmermann has joined #wayland
jgrulich has joined #wayland
hardening has joined #wayland
leon-p has joined #wayland
danvet has joined #wayland
dcz has joined #wayland
pnowack has joined #wayland
ofourdan_ has left #wayland [#wayland]
ofourdan has joined #wayland
<emersion>
DemiMarieObenour[m]: no. instead, clients can pick a size which doesn't exactly match the one requested by the compositor
<DemiMarieObenour[m]>
emersion: That is going to be tricky to deal with, given my backend (which semantically maps to a small, safe subset of X11). I will need to figure out how to prevent loops.
<kennylevinsen>
In Wayland, the client always dictates the window size.
cyberpear has joined #wayland
<kennylevinsen>
You should try to only command the window size when there is a compositor initiated resize action going on. If trying to fill a preallocated space, you could also send a single event at the beginning.
<kennylevinsen>
(that's what sway does)
<vyivel>
DemiMarieObenour[m]: client can pick a size smaller than requested, but not bigger
<DemiMarieObenour[m]>
vyivel: Ah okay, thanks!
<vyivel>
DemiMarieObenour[m]: ...or maybe not; can't really find that in the protocol, hm
dreda has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
novakane has joined #wayland
<DemiMarieObenour[m]>
Thanks kennylevinsen and emersion! Problem was that my compositor wasn’t properly sending configure requests to my backend.
novakane has quit [Quit: WeeChat 3.3]
<pq>
romangg, there is no default destructor. The function generated by wayland-scanner in that case is just free(), more or less.
<pq>
romangg, and that exactly is the problem that required us to add "release" requests to fix that gap. We could not add a request called "destroy" because that would have broken clients that got simply recompiled with a new libwayland/scanner.
<kennylevinsen>
vyivel: what do you mean by the client only being able to pick a smaller size? The client can make its window larger if it wants to by just posting a bigger buffer.
<vyivel>
kennylevinsen: i remember noticing that virtually every client i used for testing didn't pick bigger size, so i incorrectly assumed that behavior is enforced in some way. yeah, clients can pick any size (or ignore the configure completely)
<vyivel>
sorry for the confusion
<romangg>
pq: So if in a protocol an interface does not have some kind of destructor explicitly written down the server-side resource never gets destroyed? Is that the same for global binds, they never get unbound until compositor execution stops?
<kennylevinsen>
DemiMarieObenour[m]: ^ just a heads up, not client choice is not limited to smaller-than
<DemiMarieObenour[m]>
kennylevinsen: Thanks! My compositor handles this fine.
shankaru1 has joined #wayland
<pq>
romangg, all protocol objects get automatically disposed of when the client connection dies.
<pq>
romangg, but yes, if you do not explicitly write the messages for destroying a protocol object, then it won't get destroyed as long as the connection is alive.
<romangg>
pq: ah yes, I forgot that the on client disconnect the objects get destroyed. so it's not that bad. only if a client rapidly creates and destroys objects without explicitly written down destructor.
<romangg>
(and without disconnecting. then you might have a lot of dormant objects server-side)
<pq>
Also "global binds" are not special, it just creates a new protocol object like any other request with a new_id.
<romangg>
But they feel special. :P
<romangg>
But good to know that the same rules of object lifetime apply to them like any other ressource.
<pq>
swick, I just realized we pretty much cannot use the white point from EDID for, well, anything. You change monitor color temperature, EDID does not change.
<pq>
I guess the same applies to the primaries as well, cannot tell if the monitor is in sRGB or full gamut mode. Or in something else.
JPEW_ is now known as JPEW
<MrCooper>
pq: AFAIK some monitors do change EDID according to some configuration changes, probably not for every little thing though
<pq>
MrCooper, I tested mine, mine doesn't.
<MrCooper>
sadness
<pq>
I see that EDID spec says the white point applies after monitor settings reset.
<pq>
I guess I should order a display profiler now to have one next year...
tzimmermann has quit [Remote host closed the connection]
tzimmermann has joined #wayland
creich has quit [Remote host closed the connection]