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]
cobralt^ has quit [Ping timeout: 480 seconds]
cobralt^ has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
alarumbe has quit [Remote host closed the connection]
alarumbe has joined #wayland
nerdopolis has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
bim9262_ has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
cool110 is now known as Guest3030
mclasen has joined #wayland
Guest3009 has quit [Ping timeout: 480 seconds]
agd5f_ has quit [Read error: No route to host]
agd5f has joined #wayland
sjao2 has quit [Quit: WeeChat 3.4.1]
Guest3030 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest3041
bindu has quit [Ping timeout: 480 seconds]
bindu has joined #wayland
that_guy_ has joined #wayland
that_guy has quit [Read error: Connection reset by peer]
mclasen has quit [Ping timeout: 480 seconds]
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
gallo_ has quit []
gallo has joined #wayland
tzimmermann has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit []
gallo_ has joined #wayland
sima has joined #wayland
Leopold_ has joined #wayland
junaid has joined #wayland
gallo has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
rasterman has joined #wayland
junaid has quit [Remote host closed the connection]
sevz has quit [Quit: WeeChat 4.0.5]
oldbabyface has joined #wayland
oldbabyface has left #wayland [Leaving]
ManMower_ has joined #wayland
ManMower has quit [Read error: Connection reset by peer]
Company has quit [Remote host closed the connection]
neniagh has joined #wayland
Kerr has quit [Read error: Connection reset by peer]
mvlad has joined #wayland
Kerr has joined #wayland
i509vcb has quit [Quit: Connection closed for inactivity]
manuel1985 has joined #wayland
junaid has joined #wayland
iomari891 has joined #wayland
junaid has quit [Remote host closed the connection]
dcz_ has joined #wayland
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
koty0f has joined #wayland
<koty0f>
Greetings. I would like to ask for help. I'm using A64 (Mali-400MP2) with lima. I just bumped my Yocto build to kirkstone which has Weston 10.0.2 and Mesa 22.0.3 (previously on honister with Weston 9.0.0 and Mesa 21.2.4 worked OK) and started to get error messages for all of the outputs `format 0x34325258 not supported by output` when I start Weston.
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
<pq>
pitust, the authoritative spec of the Wayland wire format is libwayland. Everything else is just reflecting or documenting that. Likewise, the authoritative spec of handling the XML language is wayland-scanner, unless it's something it doesn't care about but others do (like annotating something as a bitfield).
<pq>
I agree things could be better, but that's how it is today.
<mvlad>
koty0f, 0x34325258 matches that of XR24, which should be supported by the KMS driver (ubiquitous format). modetest or drm_info should tell you what driver says about it. Last time when this come up, it looks like IN_FORMATS property was found but it couldn't be decoded, which pretty much says that the format couldn't found. It suggest an issue with the driver.
<mvlad>
koty0f, if possible suggest trying a newer version of the driver, yocto/OE.
mclasen has joined #wayland
<pq>
the DRM KMS driver, which lima is not, is it?
Moprius has joined #wayland
<koty0f>
mvlad it seems supported by drm_info https://pastebin.com/GPpmMBwN I noticed I don't have libdrm up to date 2.4.110 while compiling the drm_info.
<emersion>
the IN_FORMATS is borked
<pq>
koty0f, you are looking at the legacy info. The IN_FORMATS plane property OTOH is totally broken. This is a bug in the sun4i-drm kernel driver.
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
<pq>
swick[m], thanks a lot for the SMPTE follow-up!
<koty0f>
emerson,pq huh. Sry never used drm_info before. Thanks for pointing it out. Lets bump the kernel then.
nerdopolis has joined #wayland
<swick[m]>
pq: I'm still failing to follow your interpretation of the HDR static metadata
<swick[m]>
I'd like to add something to color-and-hdr about the metadata but if you disagree with the interpretation I'm not sure if it's worth it
<pq>
swick[m], hmm? Where did I disagree?
<swick[m]>
> I could perhaps argue that chromatic adaptation could be still be fitted there
<pq>
...but I won't.
<swick[m]>
got it :)
<pq>
that would be a play with the meaning of the word "color" used in some of the texts we're looking at
<pq>
like, is it a perceptual color or colorimetric color
<swick[m]>
especially "any color present in the image signal that is within the mastering color volume is assumed to have been presented as-is on the mastering display during creative approval." would have been much clearer if it said colorimetry
<swick[m]>
at a few places they are not clear about this, indeed
<pq>
yeah, that
<pq>
it could be a "slightly incorrect simplification to help an uneducated reader" like I have a habit of doing, or not
<pq>
(e.g. my use of the wording "color of light")
<pq>
ehm, s/uneducated/non-expert/ perhaps
kts has joined #wayland
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
ManMower_ is now known as manmower
Moprius has quit [Quit: bye]
kts has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
leon-anavi has joined #wayland
nerdopolis has joined #wayland
Leopold_ has quit [Remote host closed the connection]
junaid has joined #wayland
Leopold_ has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
AnuthaDev has joined #wayland
junaid has quit [Remote host closed the connection]
<pq>
There is no way to make sure that a shared fd stays O_NONBLOCK, is there?
<emersion>
if you can open it twice, there is
<pq>
I've no idea where it was opened from.
<pq>
nor if I would have access to that path
<emersion>
there is the Linux-specific trick of /dev/fd/<n>
qaqland[m] has left #wayland [#wayland]
<pq>
yeah... eh
<emersion>
but no portable way
<pq>
read()'ing a shared fd has this problem, and mmap()'ing it has the SIGBUS catastrophe. *sigh*
<manmower>
heh, can you dup the fd and trust your private copy?
<pq>
dup does not make a copy
<manmower>
unix was a mistake
<pq>
adding more threads could unblock this...
<pq>
nnnno-
<pq>
oh hey, EINTR is a thing, just schedule continuous SIGALRM
<pq>
manmower, see, I'm learning from the best. You.
<manmower>
that does have a certain manmower charm to it
<emersion>
in wlroots we just have our own SIGBUS logic
<pq>
could do that, doesn't make it any prettier
* emersion
remembers about that kernel patch
kenny has quit [Remote host closed the connection]
kenny has joined #wayland
<pq>
wait a minute... if I try to read from a middle of a file with pread(), and I get EAGAIN, how does the kernel know when the fd should poll as readable again?
<pq>
maybe the kernel is smart, or maybe I'd just busyloop until the pread proceeds
<manmower>
I'm a little curious as to pread() behaviour in the non-EAGAIN case too.
<pq>
I'll leave this question to dan, it'll make a nice present when he comes back from holidays.
<pq>
which poison to pick
<kennylevinsen>
pq: does pread on a seekable file affect readability state in the first place? :S
<manmower>
^ that's my wonder
<pq>
kennylevinsen, the thing I want to protect against is flaky network file systems or rotating disk gone to sleep kinda things. I *hope* getting EAGAIN there and then later poll signalling readable.
<pq>
but no, I don't know
<pq>
but if I mmap, it's guaranteed to block me, right?
<pq>
there's no SIGTRYMEMORYACCESSLATERKTHXBYE
<pq>
though that too has a "solution"
<pq>
moar thread
<pq>
s
<pq>
^ example result
<kennylevinsen>
Hah
<pq>
hmm, or was there some mincore kind of magic to lock stuff into memory...
fmuellner has quit [Ping timeout: 480 seconds]
<pq>
madvise, MADV_POPULATE_READ...
<pq>
aaargh, SIGBUS on error >_<
<pq>
what is it with throwing everything under a SIGBUS
kenny has quit [Quit: WeeChat 4.0.5]
<kennylevinsen>
Ah yeah, there we go: > Regular files shall always poll TRUE for reading and writing.
<pq>
pfff
<kennylevinsen>
so to answer your question: yes, it will poll as readable again :D
<pq>
Are we going to need library to hide all the horribleness of accessing shared fds in? Oh, but that won't work because SIGBUS.
koty0f has quit [Quit: Konversation terminated!]
<kennylevinsen>
we'll make our own kernel! in webassembly! with hoo...
<manmower>
sounds like a solid GSoC project
<pq>
kennylevinsen, where did you find that note?
<kennylevinsen>
I imagine reviving emersion's old thread about new mmap flags might be a good way forward, at least for Linux...
<kennylevinsen>
pq: man 3 poll
<pq>
oh 3, not 2
<bl4ckb0ne>
linux 2 memory boogaloo
<pq>
....maybe Linux is more useful than posix requires?
<kennylevinsen>
the manpage reads more like their good intentions than their implementation...
<kennylevinsen>
I doubt it - how would nfs know in advance that a future read RPC operation won't stall?
<pq>
is someone from the matrix trying to speak again?
<pq>
ah, no, I guess
<kennylevinsen>
(it was a response to you pq)
<pq>
nfs could cache the part of the file that was attempted
<pq>
sure, it could be out of date again, but then again
<pq>
so the only way things could be async is... threads
<kennylevinsen>
io_uring!
<kennylevinsen>
but yeah, from a portable perspective... everything blocks I/O for regular files, so a thread is an option
<pq>
good note
rederick29 has joined #wayland
junaid has joined #wayland
AnuthaDev has quit []
AnuthaDev has joined #wayland
sevz has joined #wayland
junaid has quit [Remote host closed the connection]
iomari891 has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
glennk has joined #wayland
AnuthaDev has quit []
AnuthaDev has joined #wayland
tzimmermann has quit [Quit: Leaving]
mort_3 has joined #wayland
mort_ has quit [Quit: Ping timeout (120 seconds)]
bbhtt- has joined #wayland
qyliss has quit [Remote host closed the connection]
bbhtt has quit [Quit: Bye!]
CME has quit []
Plagman has quit [Remote host closed the connection]
CME has joined #wayland
* emersion
opens social thread about GNOME removing X11 session
* emersion
closes thread
qyliss has joined #wayland
Plagman has joined #wayland
co1umbarius has quit [Remote host closed the connection]
pounce has quit [Read error: No route to host]
pounce has joined #wayland
bbhtt- has quit []
FLHerne has quit [Quit: There's a real world out here!]
FLHerne has joined #wayland
bbhtt has joined #wayland
tzafrir has quit [Quit: No Ping reply in 180 seconds.]
CME has quit []
co1umbarius has joined #wayland
tzafrir has joined #wayland
CME has joined #wayland
junaid has joined #wayland
manuel1985 has quit [Quit: Leaving]
AnuthaDev has quit []
<kennylevinsen>
are you saying the thread wasn't... social?
rv1sr has quit []
<manmower>
he merely said he closed the thread, no other inference should be made. ;)
AnuthaDev has joined #wayland
i509vcb has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
dcz_ has quit [Read error: Connection reset by peer]
dcz_ has joined #wayland
leon-anavi has quit [Remote host closed the connection]
<Riolku>
curious, whats blocking ext-session-lock-v1 from becoming stable?
bim9262 has joined #wayland
AnuthaDev has quit []
dcz_ has quit [Read error: Connection reset by peer]
<bl4ckb0ne>
isnt it already?
iomari891 has quit [Read error: Connection reset by peer]
iomari891 has joined #wayland
<zzag>
bl4ckb0ne: no, it's not in stable/ directory
<bl4ckb0ne>
isnt staging the new stable
<kennylevinsen>
No, staging is the new "unstable" beacuse the name was confusing people a lot
<zzag>
bl4ckb0ne: no, it's considered as a testing ground
<bl4ckb0ne>
> gAfter a staging protocol has been sufficiently tested in the wild and proven adequate, its maintainers and the community at large may declare it "stable", meaning it is unexpected to become superseded by a new major version.
<bl4ckb0ne>
Riolku: probably time
<kennylevinsen>
it does not matter that much to implementers, protocols in staging are safe to implement and we avoid breaking them all the same
<JoshuaAshton>
I think the entire split system is just... :/
* zzag
would prefer not to split protocols in stable and staging but it's bring old discussions up.....
<zzag>
bringing*
<JoshuaAshton>
srry i already did :D
<kennylevinsen>
idea: rename stable to something equally vague
<bl4ckb0ne>
horsey
<vyivel>
not_staging
<kennylevinsen>
"staged"
<bl4ckb0ne>
stalwart
<zzag>
JoshuaAshton: either way, it was discussed, but I don't remember the arguments in favor of still having "stable" protocols
<JoshuaAshton>
I've been making your point about not needing to get everything right from the start for a while
<JoshuaAshton>
Really we are in the best situation we have ever been for iterating on this side of the stack and discarding baggage, yet things move significantly slower than they did back on X11 :s
<zzag>
I think it's connected to the requirements that have to be met in order for a protocol to get in. A protocol must be agreed upon by some number of communities, but it's **also** has to be implemented by some number of compositors and clients
<zzag>
Depending on member priorities that can be challenging
<zzag>
On X11, you've got effectively only one server
<zzag>
So you don't need to worry about various members prioritizing implementing particular protocol
<JoshuaAshton>
I mean you also do not need to worry about that for Wayland. Wayland Protocols is just a repo of some protocol xmls, anyone can implement something in their compositor and have clients use it.
<zzag>
Sure, but depending on the protocol namespace, N parties have to implement the protocol so it can land in wayland-protocols
<JoshuaAshton>
Nothing technically has to land in wayland-protocols :p
<manmower>
oh come on, let's not give up entirely. we could just make everything ext- protocols. ;)
<Riolku>
looks like gnome, kde, and weston all dont support ext-session-lock-v1 yet
<JoshuaAshton>
I iterate pretty quickly on SteamOS/Gamescope using private protocols implemented in Gamescope + a Vulkan Layer. It's a pretty nice environment to play with. Stuff there could probably also be ext protocols, but not having to worry about API/ABI between Gamescope<->Layer is nice so I can just chop and change at wll.
<kennylevinsen>
Riolku: stable != supported
<Riolku>
Do those compositors have their own screen locking protocol? and... why?
<kennylevinsen>
The "ext_" namespace is for protocols that aren't necessarily meant to be supported across the entire ecosystem, just ones that are useful to a number of compositors/clients and would be good to not be private.
<kennylevinsen>
which is also why it's easier to get an ext_ protocol in than, say, wp_ or xdg_
<Riolku>
ah. Compatability would be nice
<kennylevinsen>
Riolku: GNOME handles screen locking internally in their shell with some integration with GDM IIRC
<kennylevinsen>
no wayland protocols in sight
<Riolku>
oh
<vyivel>
is there an easier way to run locally built weston than `WESTON_MODULE_MAP=<comically large mapping of at least 4 components> build/compositor/weston"?
qaqland6 has joined #wayland
qaqland has quit [Ping timeout: 480 seconds]
<pitust>
okay so i'm trying to draw like actual content into my buffer now
<pitust>
and my seemingly correct rendering code (and its 2 for loops, you cant really fuck it up that hard) draws completly wrong
<manmower>
I guess stride, format, and modifiers are the easy traps to fall into...
<manmower>
you're using shm? probably a stride error?
<pitust>
wl_shm, yes
<pitust>
er, i'm setting my stride to buffer width * 4
<pitust>
setting it to one less makes sway really upset and it doesn't draw it anymore
<manmower>
width * 4 is pretty normal
<pitust>
not a hard error because who would want hard errors in this kind of scenario!
<kennylevinsen>
for ARGB8888 that would be correct. You're probably just mathing wrong. Position starts upper left, each line is *stride* long, remember alpha...
<pitust>
i'm drawing without alpha, format = wl_shm::format::xrgb8888
<pitust>
xrgb8888 is one of the two default ones, so i figured it's a safe bet
<manmower>
you're still throwing in a byte for alpha though, right?
<manmower>
it's just ignored, but still present
<pitust>
yes of course
<pitust>
i'm doing ((uint32_t*)buf2.mem)[x + y * maxW] = 0xffffff; to draw pixels
<pitust>
buf2.mem is memory_mapped_region + buffer_ofset, maxW is the width of the buffer
iomari891 has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
<pitust>
hmm okay
<pitust>
sway seems to have decided to scale my buffer for some reason?
<pitust>
okay so i needed to tell the viewporter that it should take [0x0, WxH] as the sourcce
<kennylevinsen>
only if your buffer isn't WxH
<pitust>
oh well yeah that makes sense
<pitust>
i preallocate a bunch of buffers that are really large, and then just use the viewporter to clip off all the stuff i don't need
<kennylevinsen>
why? wl_shm_pool lets you make multiple wl_shm from the same array if you for some reason want it to be one big allocation
<kennylevinsen>
s/array/anonymous file/
<pitust>
i know, but allocating contignous regions from a file is super pain
<pitust>
and my ID allocator is also incredibly crap and i'm sorta worried about running out of IDs
sima has quit [Ping timeout: 480 seconds]
<kennylevinsen>
maybe fix that first then, pretty core to dealing with the wire protocol
<pitust>
well no i mean i can allocate them, i just don't handle freeing them yet
<pitust>
i should probably handle that too
<kennylevinsen>
sounds like a good idea
<pitust>
i can reuse an ID the moment i get a delete_id event from the compositor, right?
<kennylevinsen>
yeah, delete_id means the compositor acknowledged the ID as dead
<pitust>
cool. so that's implemented now
<kennylevinsen>
until then the ID is zombie-fied - not referring to anything, not valid to allocate
<pitust>
i guess if the compositor is slow enough at deallocating callbacks i'll just commit lots of ids
<pitust>
but thats fine
<kennylevinsen>
just remember to service your display connection to pick up the delete_ids, but yeah - allocate away
<pitust>
my absolutely incredible design choices have led me to construct a system where the event loop is handled by the wayland mini-library exclusively
<pitust>
i mean i read that this was definitely a bad idea for libwayland
<pitust>
but nahh
<kennylevinsen>
yes that is definitely a bad idea for any client that wishes to do anything *other* than talk to wayland
___nick___ has joined #wayland
<kennylevinsen>
if you want an event loop in there, make sure it can be sanely driven by a parent event loop from the client
<pitust>
yeah i'll probably have to rework that part
<vaxry>
there is a typo in the governance.md of w-p in point 2.2 :(
<vaxry>
2.3*. It says "if if" :(
<i509vcb>
vaxry: file an MR lol
<vaxry>
I find typo mrs low quality, can't someone who's a member just make a commit? lol
<i509vcb>
Or make an issue and let a bunch accumulate before someone makes a batch mr?
<vaxry>
fair point, I could do that. I'll scrub the MRs and see if any other are hiding
<vaxry>
MDs*
___nick___ has quit []
junaid has quit [Remote host closed the connection]
<daniels>
pq: I assume that question is for sima rather than me … ?
<ojhsdfmne>
Hello wayland friends! I am currently trying to implement the wayland protocol, but I am confused about returning errors. The documentation says "Events can be error conditions" "Each interface provides requests, events, and errors (which are really just special events)". But what does that actually mean? what kind of special events? what error conditions? the wl_shm enum says "These errors can be emitted in response to wl_
<ojhsdfmne>
[23:24] <ojhsdfmne> shm requests." but how do i emit them? with wl_display::error? That appearently is only for fatal errors though so are all errors considered fatal?
<ifreund>
yes, all protocol errors are fatal
<ifreund>
(to the client, the server of course keeps running)
<ojhsdfmne>
alright. so i have to use wl_display::error?
<ifreund>
that is the event to send error codes yes
<i509vcb>
I think wl_display::error is where the internal machinery for protocol errors is sent?
<i509vcb>
Non-fatal errors you'd just send via a plain ol event on the protocol object that raises the error
<i509vcb>
i.e. zwp_linux_dmabuf_params_v1::failed
<ojhsdfmne>
but not all interfaces with errors have such an error event. how would i decide what is fatal and what not then? or is the dmabuf extension just an exception?
<i509vcb>
for fatal errors use the *_post_error functions
<i509vcb>
for falliable errors send an event
<i509vcb>
Although if the protocol does not define an event to handle fallible errors then that's a whole other issue
<ojhsdfmne>
thats libwayland specific though right? i am writing my implemntation from scratch
<i509vcb>
Ah from scratch
<i509vcb>
The error in dmabuf is just a regular event
<i509vcb>
I'm less sure about the wl_display::error, if you can understand rust maybe look at the wayland-rs implementation?
<ojhsdfmne>
hm never used rust. i will try peeking at the scanner for guidance
<ifreund>
the description of wl_display.error in the protocol xml explains how it should be used
<ifreund>
also, just look at what wayland-scanner generates, it's like 1 line of code
rederick29 has quit [Remote host closed the connection]
<ifreund>
see the wl_shm.error enum for an example of how interfaces define error codes
<ojhsdfmne>
i cant find anything generating the *_post_error functions in the scanner
<ojhsdfmne>
yeah yeah i get how the errors are defined, just not how they are sent
nerdopolis has joined #wayland
<ifreund>
oh whoops, I forgot wayland-scanner doesn't generate interface-specific types on the server side
<ifreund>
it's just wl_resource_post_error()
<ojhsdfmne>
alright i think i figured it out. wl_resource_post_error just calls wl_resource_post_event(client->display_resource, WL_DISPLAY_ERROR, resource, code, buffer);
<ojhsdfmne>
so yeah it is using wl_display::error
<ojhsdfmne>
thank you so much for your help everyone. gn o/
ojhsdfmne has quit [Quit: Konversation terminated!]
<Riolku>
Curious, are some shm formats more efficient than others? Or does it depend solely on what my GPU supports, or something?
mvlad has quit [Remote host closed the connection]
<kennylevinsen>
Riolku: the compositor isn't passing shm formats to your GPU, it's uploading it to a GPU texture first
<kennylevinsen>
Well I guess that copy counts as "passing to the GPU", but not in the efficient zero-copy sense
<kennylevinsen>
If you need performance or efficiency on the GPU side, you want dmabufs from a GPU resource (gl, vulkan, vaapi, etc.)
trclst has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
<Riolku>
oh, so i pay a copy regardless, interesting
<Riolku>
is linux-dmabuf an implementation of dmabufs that avoids a copy?
<Riolku>
as in, my buffer would not need any transformation before being sent to the gpu?
nerdopolis has joined #wayland
tristianc6704 has quit [Read error: Connection reset by peer]