ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
melonai has quit []
tlwoerner_ has quit []
tlwoerner has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
lbia has joined #wayland
privacy has quit [Quit: Leaving]
nerdopolis has joined #wayland
glennk has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
kts has joined #wayland
melonai has joined #wayland
kts has quit [Quit: Konversation terminated!]
lbia has quit [Ping timeout: 480 seconds]
melonai has quit []
kts has joined #wayland
melonai has joined #wayland
kts has quit [Quit: Konversation terminated!]
DodoGTA has joined #wayland
riteo_ has joined #wayland
riteo has quit [Ping timeout: 480 seconds]
coldfeet has joined #wayland
rv1sr has joined #wayland
crazybyte has quit [Ping timeout: 480 seconds]
coldfeet has quit [Remote host closed the connection]
coldfeet has joined #wayland
coldfeet has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
leon-anavi has joined #wayland
tanty has quit [Ping timeout: 480 seconds]
rgallaispou has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
tanty has joined #wayland
crazybyte has joined #wayland
rasterman has joined #wayland
tanty has quit [Ping timeout: 480 seconds]
DodoGTA has quit [Quit: DodoGTA]
tanty has joined #wayland
DodoGTA has joined #wayland
sima has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
tanty has quit [Quit: Ciao!]
rasterman has joined #wayland
Brainium has quit [Ping timeout: 480 seconds]
neniagh has joined #wayland
garnacho has joined #wayland
nerdopolis has joined #wayland
tanty has joined #wayland
coldfeet has joined #wayland
lbia has joined #wayland
rgallaispou has quit [Read error: Connection reset by peer]
garnacho has quit [Ping timeout: 480 seconds]
<King_DuckZ>
hey all, so this week too I'll be trying to pass some parameters to weston (say, for example, "smoothness"), and I have a few questions: 1. how can I pass parameters from the outside? 2. which weston struct should hold them?
garnacho has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
coldfeet has quit [Remote host closed the connection]
mclasen has joined #wayland
Brainium has joined #wayland
ShapeShifter499 has joined #wayland
kts has joined #wayland
riteo_ has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
riteo has joined #wayland
larunbe has quit []
alarumbe has joined #wayland
alarumbe has left #wayland [WeeChat 4.2.2]
alarumbe has joined #wayland
Brainium has quit []
nerdopolis has quit [Ping timeout: 480 seconds]
kts has joined #wayland
nerdopolis has joined #wayland
kts has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
karenthedorf has quit [Remote host closed the connection]
<sewn>
wayland-server is ok to be used by normal wayland clients right?
<sewn>
for using things such as wl_event_loop
<sewn>
it seems counterintuitive to me, since it's intended for the server
<emersion>
it's not supposed to
<ManMower>
yeah, it's counterintuitive because you shouldn't be doing that
<sewn>
how come swayidle uses wl_event_loop, as it's provided by wayland-server?
<emersion>
it's lazy and should be rewritten to not do that
<sewn>
haha. guess i'll stick to manuall poll'ing
<sewn>
are there any sort of references/examples for manual polling of wayland fd? or is there no "right" way
<any1>
There are definitely many wrong ways of doing it
<sewn>
like? i'm curious to see if anyone was doing it wrong or if i was too
<ManMower>
I guess you could check out clients/window.c in weston, to see how "toy toolkit" does it
<sewn>
i'll assuem that's the 'rightest' way
<sewn>
nevermind, this is very complicated
<ifreund>
sewn: have a look at the doc comment for wl_display_prepare_read_queue() in libwayland if you haven't yet
<sewn>
afaik this is more so for multi-threaded applications
<ifreund>
it applies to single threaded applications as well
<sewn>
it seems to require the client managing it's own queue; there is no simpler variant to tis?
<ifreund>
wl_display_prepare_read() is just a wrapper for wl_display_prepare_read_queue()
<sewn>
atm i'm just using a while loop, flush, poll, dispatch on wl fd POLLIN
<emersion>
sewn: see mako for instance
<emersion>
but yeah it's super annoying/confusing boilerplate
<sewn>
yes i'm doing something similar mako
<sewn>
i'm intentionally not doing a dispatch_pending loop because it doesn't seem to be called more than once
<sewn>
s/called/looped
<kennylevinsen>
sewn: wlsunset has a simple dispatch loop that also wakes on a separate timer if you want inspiration.
<sewn>
why so complicated?!
<sewn>
surely wayland would have had the idea of putting all this boilerplate somewhere
<kennylevinsen>
It did, it’s called an event loop and there’s numerous options :)
<kennylevinsen>
Having one in libwayland makes no sense when others do it better (the one in libwayland-server was a mistake made early on)
<sewn>
interesting
<kennylevinsen>
The wlsunset example is for if you don’t want an event loop, like if you really *just* need dispatch + a timer.
<kennylevinsen>
Otherwise just pick from libevent, libuv, sd_event, …
<sewn>
the way slsunset does it is very interesting
<FreeFull>
If you're writing Rust rather than C, smithay_client_toolkit is quite nice
<FreeFull>
With calloop
<ifreund>
looks like wlsunset has pretty much the same control flow as what I did for waylock
coldfeet has joined #wayland
<kennylevinsen>
yeah I’m not going to win any patents on what wlsunset is doing :P
<ifreund>
I think it's a good sign that we wrote similar code :D
<kennylevinsen>
sewn: if you only need a short low-precision timeout rather than a wall clock time, you can also just specify a timeout to poll itself instead of using SIGALRM.
<sewn>
yep, already did that
feaneron has quit [Quit: feaneron]
<sewn>
kennylevinsen: should POLLOUT in wayland fd mean to flush?
<sewn>
i've noticed this in mako but not in wlsunset or any other client
<kennylevinsen>
it’s in case flush fails and you need to wait till there’s room to write
<sewn>
sorry, meant in revents
<sewn>
ive also noticed wl_display_dispatch_pending being called at the end of the function, which is also not present in waylock
rasterman has joined #wayland
iomari891 has joined #wayland
<ifreund>
sewn: in waylock wl_display_dispatch_pending() is called at the start of the next iteration of the loop, it would be redundant to call it at the end of the loop as well
<sewn>
yeppe
coldfeet has quit [Remote host closed the connection]
<ifreund>
(I think it is redundant in wlsunset as well but haven't read that code as carefully as waylock's)
<kennylevinsen>
ifreund: without, the effect if the incoming messages won’t have taken effect when dispatch returns and the logic outside cranks forward
<kennylevinsen>
like new output handling
<kennylevinsen>
So I don’t think it’s redundant in this case, but would have been if all reactions to Wayland events happened in listeners
<sewn>
something tells me these things should be added to the wayland book
<ifreund>
kennylevinsen: ah yeah I see, waylock just doesn't have logic that would be affected by that
<sewn>
in waylock comments, it is mentioned that EPIPE is sent to the app to signify wayland socket closure (supposed to be handled in wl_display_flush?), but it doesn't seem to apply and only errors at wl_display_read_events with EPIPE
<ifreund>
sewn: libwayland sets errno to EPIPE if it finds out the compositor has closed the socket while libwayland is trying to read events
<ifreund>
I don't know if this is documented anywhere, I'd just grep for EPIPE in wayland-client.c if you want details
<sewn>
ifreund: yeah i get that but shouldn't that be handled by the flushing part
<ifreund>
I don't understand what you are trying to communicate with that link
<sewn>
errno is set to EPIPE by the flushing
<ifreund>
and?
<sewn>
you said earlier it shouldn't
<ifreund>
by "handled by the flushing part" I understood that you meant there is nothing left for the client to do if flush returns EPIPE
<ifreund>
this is however not true
<ifreund>
wl_display_flush() only writes to the socket, it does not read events from the server that were sent before the socket was closed
<ifreund>
these events which have not yet been delivered may contain a protocol error
<ifreund>
and so the client should use wl_connection_read_events() or whatever to read those events and log the protocol error before exiting
<ifreund>
does that make things more clear?
Brainium has joined #wayland
<sewn>
ah so a protocol error has nothing to do with a socket error
<ifreund>
a protocol error is a normal wayland event on the wl_display interface
<sewn>
yep makes sense now
<sewn>
thanks ^^
<ifreund>
no problem :)
sima has quit [Ping timeout: 480 seconds]
neniagh has quit [Read error: No route to host]
neniagh has joined #wayland
cyrinux30 has joined #wayland
puck__ is now known as puck_
iomari891 has quit [Ping timeout: 480 seconds]
ofourdan has quit [Ping timeout: 480 seconds]
garnacho_ has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
garnacho_ is now known as garnacho
ofourdan has joined #wayland
feaneron has joined #wayland
ofourdan has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
ofourdan has joined #wayland
<sewn>
ifreund: interestingly the 'redundant' wl_display_dispatch_pending is actually required for my program
<sewn>
keep in mind the wayland doc for it also has it
<ifreund>
sewn: for waylock it is redundant as I don't have any logic that needs to be run after processing pending events and before the next event loop iteration
fmuellner has joined #wayland
<sewn>
interesting, for me i need it to process seat key events
karolherbst_ has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
karolherbst_ has quit [Quit: Konversation terminated!]
karolherbst_ has joined #wayland
karolherbst has quit [Ping timeout: 480 seconds]
karolherbst_ has quit [Quit: Konversation terminated!]
karolherbst_ has joined #wayland
karolherbst_ is now known as karolherbst
nickdiego[m] is now known as nickdiego[ooobackonjul22][m]
glennk has quit [Ping timeout: 480 seconds]
rv1sr has quit []
lsd|2 has joined #wayland
<mclasen>
are there any protocols in the works that let me hint the compositor about the preferred colorspace for compositing, when it comes to subsurfaces ?
<zamundaaa[m]>
mclasen: what do you mean? Blending?
<mclasen>
yes
<mclasen>
if gtk composites the textures itself, it might do it in a linear space, and it will look jarring if we switch between offloading and not if the compositor does something else
<zamundaaa[m]>
I don't think you'll get to choose the blending space any time soon. At best you'd get information about what blending space the compositor uses
<zamundaaa[m]>
Multiple blending spaces is quite difficult / inefficient to implement. One thing we talked about at the hackfest was doing linear in the compositor and potentially some calculations to modify alpha to make it look a bit more sRGB-like for apps that are written for it
<mclasen>
it doesn't matter for the common case
<zamundaaa[m]>
Since then I've been thinking about instead doing blending in gamma 2.2 in the compositor though, idk if offloading with linear blending in the app would still work in any way with that
<mclasen>
(a opaque subsurface on top)
Brainium has quit [Quit: Konversation terminated!]