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
ybogdano has joined #wayland
keir- has quit []
keir has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
flibitijibibo has quit [Quit: Leaving]
Guest2808 is now known as DrNick
nerdopolis has quit [Ping timeout: 480 seconds]
zebrag has quit [Quit: Konversation terminated!]
cool110_ has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 has quit [Remote host closed the connection]
<kchibisov>
emersion: what is desired way for GPU accelerated clients to detect GPU resets? I'd assume a GPU reset will result in some sort of reconfigure(not guaranteed)?
<kchibisov>
Right now I can detect gpu reset via robustness extension, but I'm not sure there's an event that could wake up the loop telling me that I need to redraw.
<emersion>
hm right, GL/Vulkan kind of assumes you'll render regularily
<emersion>
and so only allows you to detect GPU resets when submitting work essentially
<daniels>
yeah, EGL doesn't do push events, you just have to poll
<emersion>
for Vulkan you have to check the swapchain calls, or vkSubmitQueue
<emersion>
for VK_ERROR_DEVICE_LOST
<kchibisov>
My issue is not with polling, but with waking up to check.
<emersion>
yes
<emersion>
there is no solution to this
<emersion>
OTOH, if you don't use the GPU actively, you don't need to handle GPU reset
<emersion>
it's fine if it's delayed till the next rendering operation
<emersion>
but, that does mean that the wl ext to ask clients to submit a new buffer would be useful for DMA-BUF clients too
floof58 is now known as Guest2957
floof58 has joined #wayland
<kchibisov>
I think firefox handles GPU reset but stays blank until you interact with it.
Guest2957 has quit [Ping timeout: 480 seconds]
gschwind has joined #wayland
gschwind has quit []
gschwind has joined #wayland
MajorBiscuit has joined #wayland
<pq>
emersion, is there any reason to not use asprintf in libdisplay-info?
<emersion>
it's GNU
<emersion>
not POSIX
<pq>
so?
<emersion>
it's not portable
<pq>
to where?
<pq>
BSDs don't have it?
<pq>
oh well, I'll just bake my own then
<emersion>
the build system won't let you use GNU stuff
<daniels>
tbh it's hard to take BSD seriously when they don't have things which are useful like that in 2022
<pq>
emersion, so to it said, so I was about to fix it.
<emersion>
standards are important
<daniels>
though asprintf does appear to be implemented in FreeBSD, OpenBSD, and Apple
<emersion>
that's why we're here, after all
<daniels>
emersion: we're working on a living standard though
<emersion>
POSIX evolves too
<emersion>
slowly, by design
<kennylevinsen>
kchibisov: i guess it's blank till redraw? I'd expect it to redraw occasionally in it's own though, it's no saint when it comes to efficiency
<daniels>
too slowly, if we're 50 years into C and you're expecting people to hand-write their own function to return you an allocated formatted string
<daniels>
telling people to not use asprintf() and instead roll their own, when it's available in all GNU systems as well as the BSDs, seems like unhelpful dogma tbh
<kennylevinsen>
(on that note, firefox plans to implement fallback timers for stalled frame events because it apparently leaks memory if it doesn't get them when it thought it would... So I guess the surface suspension stuff is still relevant.)
<kchibisov>
kennylevinsen: As I said until I interact with it, don't remember it redrawing on its own for me. But I don't get GPU resets that often, more straight crashing.
<emersion>
it's a bit too easy to tell everbody "just use what i use: glibc", for the convenience of avoiding writing 2-3 extra lines of code
<daniels>
emersion: glibc, or musl, or BSD libc ... what else is there?
<kennylevinsen>
It is true that POSIX evolves too slowly and may sometimes be limiting, but supporting BSD and musl and stuff *is* important.
<daniels>
kennylevinsen: sure, I don't think that's unreasonable, but in this particular case asprintf _is_ supported by them
<emersion>
my friend is writing an OS, and i want my software to run on it
<kennylevinsen>
what you don't run Wayland on your vintage IBM mainframe? :)
<daniels>
emersion: can your friend not write the 2-3 extra lines of code to implement asprintf ... ?
<emersion>
opening the door to asprintf will allow people to use _all_ GNU functions
<daniels>
why would it, if the baseline is 'works on reasonable libcs from this century', rather than 'literally everything GNU has ever come up with'?
<emersion>
enabling GNU_SOURCE enables a lot of functions
<emersion>
then you just use them without thinking
<emersion>
memfd_create()? sure
<daniels>
and CI fails on BSD so you go open-code it or whatever
<daniels>
why not memfd, if it's conditional?
<emersion>
freebsd happens to have memfd_create()
<emersion>
just a wrapper around shm_open()
<daniels>
those two are not the same thing ...
<emersion>
for freebsd, they are
<pq>
reimplementing asprintf on top vsnprintf is surprisingly long
<pq>
emersion, can I somehow add the attribute-format-printf thing in libdisplay-info to a variadic function?
<daniels>
emersion: sure, so FreeBSD can have degraded functionality, and Linux users can have the upgraded functionality, and everyone's a winner?
<pq>
emersion, I guess not, since you don't use it.
<jadahl>
printf attributes, that's a gnu extension too isn't it?
<jadahl>
should be harmless to add anyhow and just ifdef to nothing for more primitive compilers
nerdopolis has joined #wayland
<kennylevinsen>
yeah the main problem with *just* relying on FreeBSD CI is that it then disregards all other BSD's...
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
<kennylevinsen>
Don't have a good way to "just use the good parts" of GNU right now, so I just usually don't go there.
<kennylevinsen>
but maybe one should just have a small libc-extras thing as a dedicated dependency instead of relying on non-standard things and weird compiler/libc-specifics
<kennylevinsen>
Especially as some feature flags for libcs enable some features but *disable* others, leaving everybody sad... Had to fight with that way too much in seatd.
<kennylevinsen>
So +1 for sticking to POSIX and pure dependencies rather than libc feature flags.
<pq>
like... glib or APR
<kennylevinsen>
APR?
<jadahl>
not enabling GNU compiler extensions which only purpose is to give better compiler warnings because you want to build on "worse" compilers seems like a bad thing to me. what's there to loose other than *some* compile finding bugs that others don't?
<kennylevinsen>
Was thinking more "lib of utility functions missing from libc" (what GNU extensions tend to be), rather than "framework that reinvents C as a whole" (what glib is)
<jadahl>
but for me writing C without the autofree GNU attributes is no a pain in the ass already
<jadahl>
s/is no a/is a/
<kennylevinsen>
defer like functionality is neat indeed
<emersion>
autofree is not defer, it's closer to unique_ptr
<emersion>
so, sounds like you want to write C++ or Rust instead of C
<kennylevinsen>
oh I was thinking of the __cleanup__ extension
<kennylevinsen>
Which I see used like Go`defer blah.Close()`
<emersion>
there was a proposal for defer for C23, sadly didn't make it AFAIK
<pq>
apache portability runtime, IIRC
<emersion>
GNU cleanup is when a variable goes out of scope, so e.g. if you return the thing it doesn't run?
<emersion>
or maybe it does, in which case it's a nice footgun?
<jadahl>
I'm talking about marking pointer so that when it goes out of scrope, it'll be freed
<jadahl>
in glib, that's 'g_autofree char *foo = NULL;', or with "g_autoptr/g_auto" for more glib:y things
<jadahl>
those are just wrappers around gnu compiler extensions anyhow
chipxxx has quit [Ping timeout: 480 seconds]
chipxxx has joined #wayland
agners has joined #wayland
<pq>
emersion, swick, should libdisplay-info do something like https://github.com/golightlyb/PNP-ID for high-level API to return proper vendor names?
<emersion>
pq, hwdata or udev-hwdb are alternatives
<pq>
yes, they are, but I didn't think you'd want libdisplay-info to depend on those.
<emersion>
the problem is that the data must be kept fresh, new entries are added regularily
<emersion>
hwdata, i'm completely fine with
<emersion>
just a bunch of text files
<pq>
aha
<emersion>
and IIRC also contains the DisplayID ID
<emersion>
OUIs?
<emersion>
i don't remember
<emersion>
but yeah, i've been also wondering whether it'd make sense for the lib to handle this