ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
mclasen has quit [Ping timeout: 480 seconds]
zxrom_ has joined #wayland
zxrom has quit [Ping timeout: 480 seconds]
mclasen has joined #wayland
Brainium has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
sevz has quit [Quit: Client quit]
sevz has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
Leopold_ has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
fmuellner has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
mxz has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
bindu has quit [Ping timeout: 480 seconds]
zxrom_ has quit [Quit: Leaving]
zxrom has joined #wayland
agd5f_ has joined #wayland
Leopold has quit [Remote host closed the connection]
bindu has joined #wayland
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #wayland
agd5f_ has quit [Read error: Connection reset by peer]
mxz has joined #wayland
zxrom_ has joined #wayland
glennk has joined #wayland
tzimmermann has joined #wayland
zxrom has quit [Read error: Connection reset by peer]
sevz has quit [Quit: Client quit]
sevz has joined #wayland
garnacho has joined #wayland
rv1sr has joined #wayland
pioyi has joined #wayland
<pioyi>
Hello! I'm trying to create a simple app using nothing but wayland's C API
<pioyi>
I'm trying to access wayland-book.com but its seems to be broken
<pioyi>
Is there some sort of book or detailed tutorial that I can follow to get started?
<pioyi>
I could read source code and the official docs but I'm looking for something that will guide me to the right path faster
<pioyi>
I don't want to create a compositor, just a simple client app, a status bar
<vyivel>
what is the expected behavior of "wl_surface.attach(buffer), buffer.destroy(), wl_surface.commit()"? mutter/kwin/weston unmap the surface (and allow to remap it without going through the initial configuration sequence…), wlroots/smithay show the contents of the destroyed buffer (which, i presume, is wrong too?)
<dubiousness>
I'd imagine the book will be back up at some point today
<pioyi>
Ok thank you so much!
<pioyi>
Will that book be enough for me to create a client?
<pioyi>
Or are there any crucial parts missing?
Leopold_ has quit [Remote host closed the connection]
paulk has joined #wayland
sima has joined #wayland
kts has joined #wayland
leon-anavi has joined #wayland
pioyi has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
kts has joined #wayland
<pq>
vyivel, I guess everyone thinks their behaviour is correct, because this is not explicitly spelled out.
<vyivel>
i'm just not sure what would be correct to do here because all of those sounds bad to me
<pq>
vyivel, you could even stretch the spec to claim that showing the destroyed buffer's contents is correct, because there is a phrase that allows the compositor using buffer contents even after its desctruction as long as the client is not re-using that storage.
<pq>
yeah
<soreau>
because that's a perfecet frame :P
<soreau>
perfect*
<pq>
soreau, for application shutdown reasons
<pq>
clients do not generally wait for the buffers to be released by the compositor when they are quitting
<pq>
they just quit, which automatically destroys the wl_buffer
<vyivel>
attach+destroy is fine
<pq>
but compositors may need the window contents for much longer, for window closing animations
<vyivel>
attach+destroy+commit is strange
<pq>
no, I would say attach+destroy without a replacement attach is definitely strange
<pq>
commit or not
<emersion>
the proto allows for things like:
<pq>
foremost, this is a client bug to need to even ask this question
<soreau>
clients do crazy things and the compositor should be do The Right Thing even when clients don't obey specs IMHO
<emersion>
to me not allowing attach(); destroy(); commit(); is a protocol design mistake
<pq>
soreau, well, that's why the spec was changed to allow compositors to read the buffer even if it was destroyed.
<emersion>
but this ship has sailed now...
<vyivel>
well it's not "not allowed"
<vyivel>
it's unspecified
<pq>
emersion, I didn't understand.
<emersion>
pq, there is an inconsistency between set_input_region() and attach() -- the former allows the region to be destroyed before commit, the latter doesn't
<pq>
oh that
<pq>
yes, it is. No problem.
<pq>
we could have forbid that desctruction, but it would make no practical difference
<emersion>
it would make clients more complicated to write
<pq>
The protocol allows attach(B); B.destroy(); commit(), but it does not specify what that does.
<emersion>
they'd need to wait for commit to be sent before destroying their regions
<pq>
sure
<emersion>
the set_XXX_region(); region.destroy(); …; commit(); pattern is widely used
<pq>
sure
<soreau>
but in reality, clients will just do whatever despite any new rules
<pq>
The spec also says that the region data is saved or copied on set, which means furhter changes the the region before commit will not affect the committed data.
<pq>
*to the region
iomari891 has joined #wayland
<soreau>
so you might as well make the compositor resilient and robust as possible instead of saying 'well it is a buggy client' only to get back 'but it works in this other compositor'
<pq>
wl_buffer is different, because do not want to mandate compositors making a full copy on attach, or ever.
<soreau>
barring any extreme special casing
<pq>
soreau, I understand that way of thinking, and it leads to hell.
<soreau>
pq: you can't win 'em all but you also can't just say 'oh I am making so if you do not follow the client rules, you will be punished!'
<soreau>
clients always do the unexpected wrong thing
<pq>
I don't know what you're arguing about. We do disconnect clients with protocol errors when a spec defines it.
<emersion>
compositors can reference the buffer
<soreau>
you can't detect every possible 'error' case, most clients gets disconnected for some low level resource error or otherwise installed incorrectly
<pq>
vyivel, my interpretation of the spec is that destroying the wl_buffer before commit will remove that wl_buffer from the wl_surface pending state. Other people think in terms of references to the underlying storage and not the protocol object, so they disagree.
<vyivel>
this works for me
<pq>
We do have explicit wording saying that the compositor cannot read the buffer contents before it has been committed. This means that a compositor cannot read buffer B1 based on the sequence attach(B1); attach(B2); commit;
vincejv has quit [Quit: Bye bye! Leaving for now...]
<pq>
whether one can draw any implications from that to the attach-destroy-commit case is another matter
<pq>
In any case, the client is confused if it does attach-destroy-commit, it's a nonsense operation.
<pq>
if it wants to undo the attach, it needs a new attach, not destroy
<pq>
if it wants to send that buffer, then don't destroy until you've given the compositor the permission to handle it.
<emersion>
agree on former, disagree on latter
<pq>
because you track storage, not protocol objects?
<pq>
btw. wl_buffer.release semantics are completely irrelevant in the attach-destroy-commit case, because the wl_buffer was not committed, therefore it's not used by the compositor, and there is no release coming.
<Eighth_Doctor>
pq: I think I've made progress on getting weston to work, now I just need to get xwayland to run properly... this would be easier if weston supported launching xwayland with a specific display number
<Eighth_Doctor>
would it be unreasonable to ask for a way to do that?
<soreau>
yes
<soreau>
IIRC you should have weston start whatever app you need so DISPLAY will be set already
<Eighth_Doctor>
why?
<Eighth_Doctor>
soreau: the problem is that the app launches the display itself
<Eighth_Doctor>
otherwise this would be easy
<soreau>
what do you mean by 'launches the display itself'?
iomari891 has quit [Ping timeout: 480 seconds]
<Eighth_Doctor>
the anaconda installer starts out as non-graphical and then boots up the graphics and attaches itself to the X display
<soreau>
so have weston start and write the DISPLAY somewhere, then have anaconda read it?
<soreau>
I mean if you're anaconda starting weston, and you're the only xserver around, the display number should be the same every time I would imagine
<Eighth_Doctor>
yeah I would hope so
<Eighth_Doctor>
I need to find all the places where the hardcoded display is set and change it though :/
<Eighth_Doctor>
s/set/used/
<soreau>
I don't think it's hardcoded at all
<Eighth_Doctor>
in anaconda it is
<Eighth_Doctor>
there's a constant and everything uses that to get the display number
<soreau>
oh, in anaconda..
<Eighth_Doctor>
it's not hardcoded in weston, weston just does its thing just fine
<soreau>
well you can run some stupid/non-graphical x11 app to get weston to launch Xwayland, then find it in the process tree and see what display it was started with and use that one
<Eighth_Doctor>
yes...
<Eighth_Doctor>
there are a few ways to do this
<daniels>
I'd say we'd take an option to set the display number, yeah
<Eighth_Doctor>
phew
<soreau>
but if it's in use, you have to pick a different one anyway
vincejv has joined #wayland
<soreau>
the other problem is that you end up with stupid scripts like startmycompositor & sleep 3; startmyx11app & yayanotherone &
<soreau>
and then you have people complain that they can set the x11 display number but not the WAYLAND_DISPLAY number
<Eighth_Doctor>
we can set that already
<Eighth_Doctor>
--socket does that
<Eighth_Doctor>
I'm already using it to have a different socket other than the default wayland-0
<q234rty>
every time I read "anaconda" I think the python thingy
<Eighth_Doctor>
well it is written in python 😅
<q234rty>
yeah, but you know what I'm talking about :)
<Eighth_Doctor>
yup
<Eighth_Doctor>
I know
Leopold_ has joined #wayland
Company has joined #wayland
vincejv has quit [Quit: Bye bye! Leaving for now...]
kts has quit [Quit: Leaving]
privacy has joined #wayland
Leopold_ has quit [Remote host closed the connection]
DodoGTA has quit [Remote host closed the connection]
DodoGTA has joined #wayland
DodoGTA is now known as Guest14663
DodoGTA has joined #wayland
garnacho has quit [Remote host closed the connection]
<ids1024>
It seems that Mesa (at least for EGL) always uses the `main_device` of default feedback as the "display GPU". Would it be correct to say the "display GPU" should change based on surface feedback, and always be the same as the render GPU if there's at least one tranche for the display GPU (with a format that can be used for rendering, at least?), and otherwise use the current surface
<ids1024>
feedback `default_gpu`?
<ids1024>
Changes like https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/268 may be necessary, but compositors and clients could also still make better use of the protocol as it exists. Unless the protocol just isn't currently capable of supporting the things it's designed to support.
Guest14663 has quit [Ping timeout: 480 seconds]
<ids1024>
As I understand, currently with EGL_PRIME=1, if I have a full screen surface on the prime monitor, Mesa will just copy to a linear buffer on the the main GPU which the compositor has the render/copy for the prime GPU. When it should be possible to use direct scan out.
Leopold_ has joined #wayland
garnacho has joined #wayland
zxrom_ has quit [Quit: Leaving]
bodiccea_ has joined #wayland
vincejv has joined #wayland
<Eighth_Doctor>
actually it looks like i might have a (semi-convoluted) way to avoid having a fixed display name
<Eighth_Doctor>
*number
cool110 has joined #wayland
cool110 is now known as Guest14669
cool110- has quit [Remote host closed the connection]
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #wayland
bodiccea_ has quit [Ping timeout: 480 seconds]
bodiccea_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
bodiccea_ has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
DodoGTA has quit [Read error: Connection reset by peer]
DodoGTA has joined #wayland
qaqland_ has joined #wayland
qaqland has quit [Ping timeout: 480 seconds]
qaqland_ is now known as qaqland
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #wayland
DodoGTA is now known as Guest14676
DodoGTA has joined #wayland
alatiera has quit [Quit: Connection closed for inactivity]
Guest14676 has quit [Ping timeout: 480 seconds]
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #wayland
DodoGTA has quit [Read error: Connection reset by peer]
DodoGTA has joined #wayland
Brainium has quit [Ping timeout: 480 seconds]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Guest14533 has quit [Remote host closed the connection]
manuel_ has joined #wayland
Leopold_ has joined #wayland
DPA2 has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
DPA has joined #wayland
<Eighth_Doctor>
pq: well I figured out why weston was behaving so oddly, I forgot to close the files so they got written to disk 😅
<Eighth_Doctor>
so weston read an empty file and just said "meh" and did everything else instead
mvlad has quit [Remote host closed the connection]