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
Seirdy has quit [Quit: exiting 3.3-dev]
columbar1 has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
Seirdy has joined #wayland
boistordu has joined #wayland
boistordu_old has quit [Ping timeout: 480 seconds]
zebrag has quit [Remote host closed the connection]
pnowack has quit [Remote host closed the connection]
pnowack has joined #wayland
danvet has joined #wayland
jgrulich has joined #wayland
Erandir has quit [Remote host closed the connection]
Erandir has joined #wayland
erc has quit [Ping timeout: 480 seconds]
spstarr has joined #wayland
erc has joined #wayland
erc has quit [Remote host closed the connection]
erc has joined #wayland
pochu has joined #wayland
rasterman has joined #wayland
spstarr has quit [Ping timeout: 480 seconds]
agd5f_ has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
Lucretia has joined #wayland
<daniels>
pq: 'no-one makes commercial games for Wayland' - I don't believe that's entirely true
<pq>
I'd be glad to be proven wrong.
<pq>
btw. using a cross-platform toolkit does not count, if the toolkit forces or causes the game to work on the minimum common denominator across all platforms meaning that Wayland-specifics cannot be taken advantage of.
<pq>
particularly the aggressive throttling of frame callbacks should not cause any problems.
<MrCooper>
IME it does not cause any problems with the majority of games and other apps
<pq>
daniels, btw. I didn't come up with claim.
<daniels>
sure, I'm not attributing it specifically to you :)
<pq>
daniels, actually I can say it since he would be happy to have our email discussion published: Josh Simmons
<daniels>
yeah
<daniels>
I mean there are vanishingly few - if any - writing native Wayland backends directly from scratch themselves
<daniels>
but you can use SDL without being hobbled to the absolute minimum of everything
<daniels>
Unity has a native Wayland backend in beta (last I checked anyway)
<pq>
I kind of wish I had time for this whole thing, but I definitely won't until CM&HDR is done.
Spathoche has joined #wayland
<pq>
I suppose the points is, and I can agree with that, is to keep all the necessary backwards compat hacks in the compat layers: Xwayland and Wine. Which means they will not get the Wayland benefits when they work as the foreign platform originally worked and was expected by apps.
<pq>
then the question is, what do the compat layers need from Wayland to implement the foreign semantics
<MrCooper>
Xorg Present drops to 1 fps as well while the CRTCs are off (and possibly while the window is invisible, depending on Xorg driver)
<MrCooper>
so Xwayland is already backwards compatible in that sense
<pq>
but do people actually hit that, and if they do, do they simply learn to avoid it rather than file bugs?
<MrCooper>
I've seen a small number of reports, presumably most people just avoid it
<pq>
There was a time when I would dig up all the Win keys from a keyboard when playing a game, because the game would crash if the win95 Start-menu accidentally came up. :-P
xexaxo has joined #wayland
xexaxo_ has quit [Ping timeout: 480 seconds]
leon-p has joined #wayland
<pq>
emersion, <roll-eyes/> that mpv commit about locale brokenness, but I wonder, do we have a generic library that does not do the locale damage?
<emersion>
musl? :P
<pq>
can I easily use it in e.g. Weston without replacing the system libc?
<pq>
while other components in the process keep using the system libc
muhomor has joined #wayland
<emersion>
i don't know, tbh
<kennylevinsen>
It should just be a matter of doing CC=musl-gcc to use their wrapper
<pq>
I have a vague recollection of libraries that reimplement standard C functions if the platform lacks some or they don't exactly work right, but that's also not the right goal here.
<emersion>
kennylevinsen: wouldn't that replace the whole system libc?
<emersion>
weston itself could probably uselocale() once at startup
<emersion>
but that's not appropriate for libweston
<pq>
Existing function calls in code, subtly changing behavior without touching them is a bit scary.
<kennylevinsen>
oh, thought you meant without replacing system libc on the machine
<kennylevinsen>
Hmm
<kennylevinsen>
I wonder how cursed it would be to dlopen a libc
<emersion>
is it even possible if there are symbol name conflicts?
<pq>
I wouldn't try my luck. :-P
<pq>
I'd very much prefer a "normal" library, with namespaced symbols.
<emersion>
yeah
<emersion>
kennylevinsen: seems like dlmopen with LM_ID_NEWLM would need to be used
<emersion>
(GNU extension)
<kennylevinsen>
Slightly ironic that it would take a GNU extension to load musl
<emersion>
:^)
<emersion>
a new sane stdlib would be nice, OTOH many projects have their own NIH base lib and it's pretty annoying
muhomor has quit [Remote host closed the connection]
<emersion>
also, everybody is familiar with POSIX
<ishitatsuyuki>
sorry for interrupting, what is NIH?
<pq>
a new sane C stdlib-next implemented in Rust? :-)
<emersion>
Not Invented Here -- everybody creates their own
<emersion>
and everybody has opinions that their base lib is better
<emersion>
so you need to learn the base lib in order to contribute to the project
<ishitatsuyuki>
I see, thanks
<pq>
NIH can easily start with "I don't need all that bloat they have, I just need this one little thing." Repeat a 100 times, and you have your own bloated lib with conventions no-one else uses.
<emersion>
tbf, i think the real solution is "fix POSIX"
<emersion>
but that's slow and we're pretty far off
Spathoche has quit [Remote host closed the connection]
<wlb>
wayland Merge request !158 closed (shm: close FD on wl_resource_create error in shm_create_pool)
jgrulich has quit [Remote host closed the connection]
muhomor has joined #wayland
jgrulich has joined #wayland
<daniels>
literally the first thing I read in that mpv commit was 'C locales were utterly moronic even when they were invented.' and ... yes
<daniels>
emersion: 'fix POSIX' is GNU, except then everyone complains that BSD doesn't implement it and what about musl and this must compile on AIX as well
<emersion>
GNU adds a lot of "utterly moronic" stuff, too
<daniels>
no argument here :)
<daniels>
but also a bunch of actually useful things
<emersion>
but some of the stuff should be standardized, yes
<emersion>
e.g. asprintf
<emersion>
btw, "fix POSIX" is also BSD
<emersion>
except GNU and BSD have a different idea of what "fix" means
<daniels>
yeah, and BSD is ... not a statistically important target if you want to reach actual users
<daniels>
(unless your target audience is the Netflix servers)
<emersion>
i want to reach users without forcing them to use GNUware
muhomor has quit []
<emersion>
also, the statistical argument may be true for e.g. GNOME, but it's less true for sway
<emersion>
we have a lot of alpine/void/bsd users
<emersion>
oh well :P
muhomor has joined #wayland
<emersion>
in any case, GNU doesn't offer a way to fix this locale stuff, AFAIK
<emersion>
(musl "fixes" it by not implementing anything other than C.UTF-8 and C)
<daniels>
lols
<daniels>
(and yeah, locales are probably unfixable because it's so deeply baked in, and UNIX/POSIX is so dead that there is no actual forum to start working on anything else, so ... Rust?)
muhomor has quit []
muhomor has joined #wayland
muhomor has quit []
muhomor has joined #wayland
muhomor has quit []
muhomor has joined #wayland
pochu has quit [Ping timeout: 480 seconds]
pochu has joined #wayland
aleasto has joined #wayland
xexaxo has quit [Ping timeout: 480 seconds]
aleasto has quit [Quit: Konversation terminated!]
xexaxo has joined #wayland
<raghavgururajan>
> pq: raghavgururajan, no, there is no default Wayland terminal. Like there is no one Wayland compositor, either. Even de facto one like Xorg is for X11.
<raghavgururajan>
I see.
leon-p has quit []
<raghavgururajan>
> pq: raghavgururajan, do you have a reason to care about Wayland in particular?
<raghavgururajan>
Some applications defaults to xterm when ran under X11. So I wondered if wayland distributes any.
<emersion>
xterm doesn't sound like a good default
<emersion>
but sadly there's no standard way to discover the user's preferred terminal emulator
<emersion>
i've seen that and immediately discarded it since it requires dbus
<emersion>
most terminals i know don't have a dbus interface
muhomor has quit [Remote host closed the connection]
muhomor has joined #wayland
<pq>
raghavgururajan, Wayland does not provide anything you could actually run, really. All the clients and servers and tools that end users might run are not from the Wayland repository.
<pq>
raghavgururajan, there is a wayland-utils repository, but it only contains wayland-info IIRC. Which is a debug tool, basically.
<kennylevinsen>
A dedicated dbus protocol to open terminals seem odd. Isn't a "default app" mechanism (like the xdg-style .desktop mimetype stuff) more along what users want?
<kennylevinsen>
I imagine the problem isn't terminal emulator specific
<jadahl>
that 'intent-apps' won't help launching an actual command in a terminal app though I suppose
<kennylevinsen>
You can pass args to .desktop entries, so I guess one could
<jadahl>
isn't the problem that there is no standard nor discoverable way to pass args that works across terminals
<jadahl>
?
<emersion>
yes
<kennylevinsen>
Just define that args to a terminal .desktop file mean "run", just like args to a browser mean "open", applying whatever args are needed to get it done.
<jadahl>
"just"
<kennylevinsen>
Seems to me like it fits exactly with how that system was supposed to work
<kennylevinsen>
Yes yes, I know
<kennylevinsen>
But sidestepping the entire thing and making a dedicated protocol for this one thing just seems odd to me
<jadahl>
seems sane to me, since you likely want to control a bunch of things, e.g. whether to close the window after the command exited, current directory controls etc. it's a rather different problem from opening a URL
<emersion>
current dir can be controlled by… setting the current directory
<emersion>
as in, chdir(3)
<jadahl>
by first forking or what?
<emersion>
if you exec() something, you always need to fork before
<emersion>
regardless of whether or not you want to chdir
<emersion>
note, this doesn't even need to be standardized, this already works fine with current terminal emulators
<emersion>
well, except gnome-terminal
<jadahl>
forcing everyone to use fork(), chdir() and exec() seems bad
<pq>
launching a program generally does involve fork() and exec(), so I'm not sure what the point to avoid that is?
<jadahl>
pq: launching applications in gnome tends to use dbus activation and posix_spawn
<jadahl>
(afaik)
<pq>
oh, posix_spawn is new to me
<pq>
hmm, designed for "small, embedded systems lacking MMU support".
<emersion>
posix_spawn is missing quite a lot of stuff
<emersion>
posix_spawn_file_actions_addchdir will be in the next standard
<kennylevinsen>
That function signature... Hah
<emersion>
anyways, on linux posix_spawn just uses fork/vfork/clone
shrimpsizemoose has joined #wayland
shrimpsizemoose has quit []
shrimpsizemoose has joined #wayland
<swick>
urgh, the twitter comments from josh simmons are really ignorant
<pq>
eh, wonder if I care to know
<pq>
he didn't seem ignorant in private emails when complaining about my comments about naive main loops
<pq>
maybe it's just the social media factor
<MrCooper>
wasn't impressed by his GitLab comment either
<pq>
I get the point though: we did fundamentally change how the EGL etc. API worked.
<MrCooper>
so since glXSwapBuffers was invented in the 90s (if not 80s?), we have to treat every app which calls it as if there's a single CRT monitor which never turns off? ;)
aleasto has quit [Quit: Konversation terminated!]
<pq>
Also most of the relevant application were never written for Wayland, so we can't even say that that's how EGL Wayland platform works.
<pq>
Yes.
<pq>
Also with EGL X11 platform, and I suppose EGL Win32 platform too?
<pq>
Xwayland should do it.
<pq>
it actually can do it without breaking anything on the Wayland side, which is not true for many other things that are "broken" on Xwayland but not on Xorg.
<MrCooper>
fun fact: the GLX 1.2 spec in 1997 didn't specify when a buffer swap must complete; it just says it's "typically during vertical retrace of the display monitor"
pochu has quit [Ping timeout: 480 seconds]
<pq>
sure, but the specs mean very little after lots of apps have been written. We have had to fix Wayland specs to follow reality too, I'm sure.
<swick>
I guess he's talking about the forward progress issue on gitlab in which case... fix the WSI? should be just a few lines.
<swick>
and Xwayland already does it
<pq>
forward progress may be enough for many apps, maybe it could be enough overall, or not
<swick>
and in that case, add a fake WSI which does give you the weird guarantees which have no relation to the real world
<swick>
*fake present mode
<swick>
and add a quirk for those apps
<pq>
In the end, we have to decide what kind of apps we want to keep working and which are not worth to care about. And how well do we care about them working.
pochu has joined #wayland
<swick>
those apps are developed for other platforms and someone wants to make them run on wayland and then complains that they have to put in work to translate from the guarantees of the one platform to the guarantees which wayland provides
<pq>
yes - they also do not want to write a single bit of platform-specific code.
<swick>
it's not like they could not do that; they just don't want to. they want wayland to behave and give the exact same guarantees as another platform.
<pq>
yes.
<swick>
and I have no sympathy whatsoever for that
<pq>
They have a game to develop. They don't care about the platform.
<swick>
valve deloped a whole set of translation layers for DX but when it comes to the windowing system this suddenly is a problem?
<pq>
Until big game engines get first class Wayland support, or Wayland becomes a huge gaming platform in its own right, most game developers will not care.
<swick>
game devs who develop for windows obviously should not care but when valve wants to run those games on wayland... well
<pq>
we re just the niche of a niche
<pq>
yes, it does't become a problem, because Wayland is so very different to anything else. You can ask alf about the problems he has hit with the Wine-wayland driver.
<pq>
*does become a problem
<swick>
the surface suspension thread has someone working on dxvk and vkd3d answering the question of why they don't implement a swapchain that works for them in there and the answer was: i don't want to
<pq>
winsys does seem hard for Valve, having heard that the Steam client runs all its windows in sync.
<swick>
the wine-wayland thing is doing everything correctly
<swick>
translating from the requirements of one to the requirements of the other
<swick>
and not saying wayland is broken, fix wayland
<pq>
swick, that translation is impossible, as Wayland is now. Lots of heuristics that work often, and on several compositors, and a great pain trying to develop them.
<pq>
I'm not saying that Wayland must change.
<pq>
I'm saying the pain is real.
spstarr has joined #wayland
aleasto has joined #wayland
<kennylevinsen>
That reminds me that I should check on wine Wayland at some point
<pq>
by all windows in sync, I mean: for_each_window: eglSwapBuffers(), if I understood right.
<pq>
which then has the obvious consequence when one of the windows hits the 1 Hz fallback timer in Xorg or Xwayland.
<MrCooper>
right, and this can not work as intended even with Xorg if the windows are on different monitors with different refresh rates
<swick>
yeah, like, what do you expect?
<pq>
Everything unfamiliar is always hard. Make me do something on DX, and I'll scratch my head for a week.
<swick>
don't do that
<swick>
the steam client is on linux for what? 8 years now?
<swick>
they could have fixed that, they chose not to
pochu has quit [Ping timeout: 480 seconds]
<MrCooper>
Firefox has the same issue
<swick>
on wayland?
<swick>
I think over Xwayland it does
<emersion>
yeah, they have a vsync timer
<emersion>
on wayland
<MrCooper>
same as with Steam, it's most noticeable with Xwayland, but can be bad even with Xorg
<pq>
"chose not to" is relative. When you own the code, you could always fix it, but is it worth it? I would *want* to fix so many things in Weston, but I don't have the time for it.
pochu has joined #wayland
<kennylevinsen>
The Firefox vsync system requests frame callbacks as long as they want a "vsync" timer, which they enable and disable as needed.
<pq>
tbh, I'm still amazed that Steam on Linux is a thing.
<swick>
sure, but they depend on behavior that was never guaranteed and when that behavior changed they complained about the change in behavior
<swick>
when you write broken C code and then complain about your compiler that a change broke your app, it's the same thing
alf has joined #wayland
<MrCooper>
kennylevinsen: Firefox's native Wayland backend is fine
<pq>
swick, or in other words: it worked until someone else broke it. It's a matter of perspective.
<MrCooper>
pq: did you see the Steam Deck? If not, prepare to have your mind blown :)
<kennylevinsen>
MrCooper: it could be worse, but it could also be better. Tried to work on a revamp of their frame scheduling, but it ended up being way too much work on a mountain of legacy code :(
<pq>
swick, we have several examples on Wayland too, where the Weston implementation was originally sloppy, then everyone copied the behavior and apps started depending on it, and now the original intent doesn't work anymore.
<pq>
MrCooper, not yet.
<pq>
...usually around corner cases and situations unforeseen when writing the spec
<MrCooper>
kennylevinsen: I mean specifically WRT this issue; one window getting throttled doesn't affect other windows
<swick>
pq: difference here is that there is multiple layers between the game and wayland. with bad wayland native clients there is much less that can be done.
<pq>
yeah, we have some leeway on where to work around things
<swick>
I get the perspective but if you're not really careful about how much workarounds you accept and how much you want to guarantee you paint yourself in a corner with way too much complexity
<pq>
yup
<MrCooper>
there's a big difference between providing mechanisms to run apps as if it was the 90s, and making that the default
<pq>
default on what?
<MrCooper>
a Wayland desktop
<pq>
I wouldn't make it default on Wayland, but I would make it default on Xwayland.
<pq>
I wouldn't even allow it on Wayland.
<MrCooper>
why does Xwayland need to be holier to the 90s spirit than Xorg?
<pq>
no, just equal to Xorg
<MrCooper>
all the same issues can happen with Xorg as well more or less
<pq>
but didn't you say there are problems with Xorg too?
<pq>
violent agreement...
<pq>
I don't even have a horse in this game. :-)
<swick>
if the windows game potentially has issues on wayland and Xorg, the workaround belongs in a layer above it
<swick>
iow, wine/proton/dxvk/whatever
<pq>
yup
<ofourdan>
sorry, being curious but missing context, what is this all about?
<pq>
There are so so many Wayland "don't do that" that is not written down anywhere I'd know of.
<LaserEyess>
but what do you do about the chicken and the egg problem of applications either not wanting to change for wayland, or not being able to change for wayland (and therefore never working right on wayland)
<LaserEyess>
I mean, I'm simply a user, but I know first hand when I come to most software with "this doesn't work right on wayland", the default response is antagonism towards wayland
<LaserEyess>
even some software that tries to support wayland sometimes can't due to, specifically, the frame callback and event loop issue
alf has quit []
<LaserEyess>
mpv has struggled with that for a while and while there's a working solution now and an active, determined wayland dev, the idea of rewriting mpv's core render loop to work with wayland, when it works on every other OS and window system, is too much for him
<daniels>
the option the previous mpv maintainer gave us was to rewrite Wayland to be exactly the same as X11 (in which case you could just use X11), or ... well there was no second option really
<LaserEyess>
yes, well, wm4 had his issues
<LaserEyess>
but from his perspective mpv supports a vast amount of hardware, OSes, and window systems; and wayland was the one that didn't work with mpv's model
<LaserEyess>
actually that's a lie, macOS had some issues too
leon-p has joined #wayland
<LaserEyess>
and I mean, this isn't to say that wayland is doing it wrong, or that because everything else does it one way wayland should as well
<LaserEyess>
but some things just won't be fixed, you're never going to get dark souls working properly on wayland for example, so it will always have issues
<dottedmag>
pq: Re: locale weirdness -- maybe document a list of functions that change their behaviour based on locale, and drop in their local replacements that don't do that? asprintf et.al. have several reimplementations that do not suffer from this.
<dottedmag>
I remember having a libcompat in one project that contained just the reimplementations of native POSIX functions with various warts removed (not due to locale, but the idea was the same -- have a sane POSIXish base to build the code on).
flacks has quit [Ping timeout: 480 seconds]
flacks has joined #wayland
flacks has quit [Ping timeout: 480 seconds]
<raghavgururajan>
pq: I see. Thanks for the explanation.
pochu has quit [Ping timeout: 480 seconds]
flacks has joined #wayland
<raghavgururajan>
What is the difference in projects wlroots and weston? They both aim to make code that can be used to build any wayland compositors.
<raghavgururajan>
To be specific, wlroots vs libweston.
<emersion>
raghavgururajan: i'd say the main difference is that libweston has a "midlayer" approach, wlroots has a "toolkit" approach
<raghavgururajan>
emersion: I see. Thanks!
<emersion>
so, libweston will give you a working compositor faster, but might get in your way later on
<emersion>
for instance, libweston manages the rendering process -- you can't customize it
<emersion>
disclaimer: i'm wlroots' maintainer
<raghavgururajan>
I am gonna read more to understand what you said. ;)
glisse has quit [Read error: Connection reset by peer]
dri-logger has quit [Write error: connection closed]
flacks_ has joined #wayland
flacks has quit [Ping timeout: 480 seconds]
dri-logger has joined #wayland
aleasto has quit [Quit: Konversation terminated!]
* daniels
is a Weston developer, can confirm the article is good
<daniels>
(though I'd expand 'automotive' to 'things which aren't desktops i.e. you don't have people with a mouse dragging windows around to make them arbitrary sizes at arbitrary times')
jgrulich has quit [Ping timeout: 480 seconds]
muhomor has quit [Remote host closed the connection]
glisse has joined #wayland
leon-p has quit []
pnowack has quit [Quit: pnowack]
pnowack has joined #wayland
sychill has quit [Read error: Connection reset by peer]
sychill has joined #wayland
eck has quit [Quit: PIRCH98:WIN 95/98/WIN NT:1.0 (build 1.0.1.1190)]
eck has joined #wayland
cramur has joined #wayland
shrimpsizemoose has quit [Read error: Connection reset by peer]
AJ_Z0 has quit [Quit: I have to return some videotapes]
pochu has joined #wayland
pochu has quit [Ping timeout: 480 seconds]
zebrag has joined #wayland
AJ_Z0 has joined #wayland
AJ_Z0 has quit [Read error: No route to host]
AJ_Z0 has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
yoslin has quit [Quit: WeeChat 3.2]
cramur has quit [Ping timeout: 480 seconds]
yoslin has joined #wayland
spstarr has quit [Remote host closed the connection]