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
Arnavion has quit [Quit: Arnavion]
Arnavion has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
kchibisov has quit [Read error: Connection reset by peer]
<pq>
tleydxdy, it might have been a good idea orignally, but nowadays it would be difficult for apps to rely on, because they might be running against an older libwayland-client.
<pq>
still, I guess it wouldn't hurt, even though it's not really a fix for that crash.
kenny has joined #wayland
ufo-piloot has quit [Ping timeout: 480 seconds]
jmabr has joined #wayland
rasterman has joined #wayland
<pq>
Sometimes I wonder if libwayland-client should have an internal thread to continuously read the Wayland socket and queue incoming events, to work around the "server floods the connection while the client is busy" problem.
<pq>
If that's too drastic, maybe the thread could be opt-in. Or simply a helper API so we don't change the currently existing libwayland-client code at all.
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<kennylevinsen>
But it won't be much different from the user starting a thread and reading the socket which I at least think is relatively trivial...
<pq>
exactly
<jadahl>
has that idea been considered in / suggested to SDL?
<pq>
it just avoids every user copying code, they could just call the helper
<kennylevinsen>
The main question is whether that's what we want to suggest as a "solution"...
<pq>
jadahl, this is about Xwayland actually
<pq>
kennylevinsen, indeede
<jadahl>
ah, #237
<pq>
jadahl, yup, and !188
<jadahl>
doesn't seem like it will reliably solve it. what if the reader thread doesn't get the cpu time it "deserves"?
<pq>
jadahl, nothing will reliably solve the problem, evern.
eroux has joined #wayland
<pq>
jadahl, as long as there are two async processes, and no infinite memory, you can always OOM somewhere.
<pq>
but I think the thread will solve the cases that are actually fixable and worth to fix and happen in practise.
manuel1985 has quit [Remote host closed the connection]
<jadahl>
dynamically growing and mitigating in the compositor does seem more reliable though
<kennylevinsen>
mstoeckl had a patch for dynamic buffer sizes, and not sure where we landed on mitigation
<jadahl>
as in, if the compositor gets cpu time to send events, it also gets cpu time to detect that there is too much in the queue so that it can e.g. unfocus etc
<jadahl>
kennylevinsen: it was revived by ofourdan in !188
manuel1985 has joined #wayland
<pq>
jadahl, it exposes the compositor to OOM instead of the client, and also accounts the memory used to the compositor instead of the client. To mitigate the compositor OOM, you need to set arbitrary limit again, just bigger than now.
<jadahl>
pq: not necessarily, it can apply mitigation strategies
<pq>
jadahl, ah, unfocus is a good point.
<jadahl>
such as the unfocus to stop sending events
<pq>
unfocus is such a good point that now I favor that instead of the client thread :-)
<mceier>
in my opinion, the wayland-server api should let decide the compositor what to do with such client e.g. disconnect it, mark it as unresponsive etc. but I guess that's a lot to redesign
<kennylevinsen>
did we have any proposal for how to detect the condition? Poking at socket stats?
<pq>
kennylevinsen, looking at how much is in the libwayland-server per-client buffer.
<pq>
and whether flushing to the socket doesn't drain it enough
<kennylevinsen>
mceier: yeah without the mitigation work it would be hacks as we're in a situation where we can't write anything more to the client. It'll be rather annoying to deal with "gracefully". What the mitigation technique will do is basically allow the compositor to know that it's happening and react in the ways you suggest.
jmdaemon has quit [Ping timeout: 480 seconds]
<mort_>
"good" news, I have confirmed that the SDL issue from yesterday isn't due to broken mali drivers, since it also happens in a VM on my laptop
<kennylevinsen>
I wonder if the mitigation is effective enough to just maybe just bump the static buffer size and call it a day...
___nick___ has joined #wayland
<jadahl>
kennylevinsen: for the Xwayland issue, bumping the size is probaby enough, but not for the "move super high frequency mouse in a circle during loading screen while game main loop is blocked" disconnects
<pq>
unfocus mitigation for that case would unfocus the game? then users wonder why the game is not taking input?
<jadahl>
it would, but an implementation could refocus when it notices the pipe was unclogged
<jadahl>
and it'd practically go by unnoticed
<kennylevinsen>
yeah I mean that if we unfocus, maybe we just need slightly bigger buffers instead of fully dynamic buffers
<pq>
maybe
<pq>
would unfocus also mean un-fullscreen?
<jadahl>
I would say no
<jadahl>
it could just be wl_pointer.leave an no more events until unclogged
<jadahl>
pointer events, that is
<pq>
yeah, so "unfocus" would actually be a very specific operation that has nothing to do with active window handling.
<pq>
Sounds good to me.
MajorBiscuit has quit [Quit: WeeChat 3.4]
<jadahl>
pq: that's kind of what mutter does now, but with rather aggressive xdg_wm_base::ping's
MajorBiscuit has joined #wayland
<kennylevinsen>
if an apps ping pong game isn't world table tennis championship level it gets killed
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ifreund>
detecting the issue through pings and sending fewer events sounds far more robust than making the buffers dynamically sized to me
<ifreund>
I don't want my wayland compositor's memory usage to skyrocket because I'm moving a high frequency mouse over a blocked client
<pq>
it won't sky-rocket, if you detect and mitigate
<ifreund>
yeah, that's what I'm saying no?
<pq>
no, I meant detect buffer filling, not with pings
<pq>
pings only work for xdg-shell, and extra pings are wasteful
<pq>
e.g. Xwayland does not use xdg-shell at all, I believe. It has no need to.
<ifreund>
ah, yeah that makes sense
<jadahl>
kennylevinsen: not world tennis => no pointer focus, not pre-school tennis => disconnected
MrCooper has quit [Remote host closed the connection]
erle- has quit [Remote host closed the connection]
<mort_>
does weston have some form of IPC thing you can use to control it programmatically?
ufo-piloot has joined #wayland
<pq>
mort_, no.
<dottedmag>
Well, one can send signals to it...
<pq>
only the test suite has some private protocol
fmuellner has joined #wayland
MrCooper has quit [Quit: Leaving]
mclasen has joined #wayland
MrCooper has joined #wayland
jgrulich_ has quit []
jgrulich_ has joined #wayland
flacks has quit [Quit: Quitter]
flacks has joined #wayland
erle- has joined #wayland
Azem has joined #wayland
<mort_>
for some reason, weston is ignoring requests to set window geometry
<mort_>
if weston doesn't let windows resize themselves, and doesn't let windows reposition themselves, and deleting the surface doesn't work (due to the SDL bug), and setting window opacity isn't supported, and SDL doesn't let you draw transparent pixels to the window... I'm not sure what I'm supposed to do
<pq>
mort_, maybe you misunderstood what window geometry is?
<pq>
you resize a window by creating a buffer of the new size, painting that, and attach+damage+commit that.
<mort_>
set_window_geometry is just the thing which looked most relevant with what SDL_SetWindowSize does
<pq>
window geometry is just metadata that allows the compositor to know where the real window contents is, apart from non-content like shadows
<mort_>
that's trying to resize from 100x100 to 20x20
<pq>
You cannot resize a window on Wayland without actually painting the window in the new size first.
<mort_>
maybe I have to swap buffers after to make weston update
<pq>
yes, at the very least
<mort_>
alright that works at least
<pq>
Maybe it helps to think of surface size and window size as two different things.
<mort_>
it would if I was using wayland directly but that's abstracted away through SDL
<pq>
yes, but this should help understand what "window geometry" is.
<pq>
Normally surface size is determined by the buffer size directly. You cannot resize the surface without attach+commit a buffer of another size. (Ignoring wp_viewport and buffer scale/transform etc. for now.)
<pq>
a "window" could be understood to be the (sub-)rectangle of the surface defined by window geometry
<pq>
window geometry is used for window management, like snapping two windows side-by-side
<pq>
the area that is outside of "window geometry" but inside the surface is decorative, like client-side window shadows
<mort_>
right
jgrulich_ has quit []
jgrulich_ has joined #wayland
devilhorns has joined #wayland
jgrulich_ has quit []
jgrulich has joined #wayland
MajorBiscuit has quit [Ping timeout: 480 seconds]
d42 has quit [Read error: Connection reset by peer]
MajorBiscuit has joined #wayland
MajorBiscuit has quit []
jgrulich has quit [Quit: Konversation terminated!]
jgrulich has joined #wayland
Azem has quit [Ping timeout: 480 seconds]
* ManMower
wakes up, nods at scrollback, wanders off. ;)
<ManMower>
the idea of "unfocusing" xwayland sort of hurts my brain a little, but I think all the points made still stand, since focus is just a *slightly* non standard meaning for the word.
<pq>
Actually, on Wayland it literally is "pointer focus".
<pq>
one might also take keyboard focus away temporarily, and still maintain the window active
<ManMower>
I guess only pointer events are going to be blasting the client when it's too stunned to be submitting any requests
<pq>
it's the easy way, but I bet there are people who manage to do it keyboard as well
<pq>
particularly after the pointer focus has already been taken away
<jadahl>
some people can type fast, but not *that* fast
<pq>
how fast depends on how long the client is stuck
<ManMower>
thank god we removed server side key repeat!
<mceier>
and depends on how much space is left in the buffer, I guess
<ManMower>
mceier: I think we're talking about unfocus in combination with MR 188, which allows the server to set the size of the buffer
<jadahl>
ManMower: would take a while to reproduce with key repeat, unless it's like 500+ a second
<ManMower>
jadahl: those old northgate keyboards...
<jadahl>
...triggered..
<ManMower>
:D
<pq>
I'd take away everything I can if a client is showing congestion (indigestion? ;-p)
<pq>
pointer, keyboard, touch, tablet...
<dottedmag>
I wonder where these 8kHz come from, 125us high-speed polling mode of USB?
<pq>
dottedmag, who says it's true 8kHz, maybe it's just on average?
<ManMower>
have we considered event streams in an fd? ;)
<pq>
i.e. the sensor may be 8 kHz, but the USB bus might be like 100 event burst every x us
* ManMower
shows himself the door
<ManMower>
oh god, yes, because pro gamers absolutely want bursty input
<dottedmag>
pq: HID is poll "give me current state", isn't it?
<pq>
if they include timestamps, no problem
<ManMower>
it's ok as long as the device doesn't have it sown clock source and time... wait
<pq>
if they don't include timestamps, marketing! \o/
<ManMower>
nod
<pq>
dottedmag, I wouldn't know.
<pq>
are they even HID?
<pq>
or maybe the sensor is 8 kHz, but using HID means you'll never actually get data at that rate?
<pq>
so much room for lies everywhere
<ManMower>
sadly I don't want to waste the apparently $70 to buy one on amazon
<dottedmag>
Even USB 2.0 specified 125us opt-in polling rate, so it's possible. The limit was always cheap slow IC on the mouse side
<pq>
ok
<pq>
(maybe I have something against marketing specs)
<dottedmag>
And I have no idea how new USB works, I have heard something resembling word "interrupt", but never checked
<pq>
IME "for gamers" means "it could have been good at half the price, but we also added all this bling that makes it actually crap"
<daniels>
1000 RGB LEDs aren't free
<ManMower>
now now, let's not call things you don't need crap. it merely raises the price for features you and I don't have interest in. ;)
<daniels>
^ has a gamer mouse
<ManMower>
<-- literally all his mice are gamer mice
<pq>
I have gamer monitor at home. That's why I'm sour.
<dottedmag>
Is there a non-gamer mouse with 1k polling rate? Cutting ~4ms latency is nice.
<kennylevinsen>
pq: you need the gaming hardware to match!
<kennylevinsen>
then you'd be able to more fairly distribute your frustration over a larger amount of hardware
<ofourdan>
a gamer mouse is nice, but I'd fancy a gamer cat to match it :þ
* ofourdan
hides
<pq>
in the mean time, I'm wondering if it's a good idea to printf("EOTF⁻¹"); in C... (utf-8)
* kennylevinsen
imagines the worlds tiniest gamer setup for that mouse
<ManMower>
clearly I need wireless mouse with a charger dock with ground effects lights that fade from green to red as charge depletes. and if that fade can be synchronized with lights on the mouse, but only work properly at all while running a 450 meg driver set under windows, how could I say no?
<ManMower>
pq: is your intent to log every time you're not at the end of a file? that seems verbose regardless of character representation
bittin has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
jgrulich has quit [Remote host closed the connection]
<dottedmag>
Looks like "Use UTF-8 on Windows" manifesto.
<swick>
ManMower: Electro Optical Transfer Function, not End of File
<ManMower>
haha thanks, that makes far more sense :D
<daniels>
I don't think we need to worry too much about Weston on Windows tbf
<kennylevinsen>
... yet
<ifreund>
wasn't there some talk by microsoft about using weston for WSL stuff on windows recently?
<daniels>
kennylevinsen: well I mean Weston does run on bajillions of Windows desktops, but it also runs on Linux
<ifreund>
weston was probably running under WSL though I suppose
<daniels>
(Weston doesn't run Windows-side, it runs inside the Linux 'VM', so is for all intents and purposes in fact running on Linux)
<daniels>
yeah
<kennylevinsen>
I feel like most of our problems are on Linux, so maybe we should just remove support for that and focus on the primary Windows target then :P
<ManMower>
we could deprecated it and wait a release cycle and see if anyone complains ;)
Company has joined #wayland
<pq>
daniels, I think we both suck at telling pixels and bytes apart. And the old GL-renderer code definitely does not help making the distinction.
<daniels>
pq: yeah I just read your message now - am learning Rust this afternoon so will have to get to it later on
<daniels>
(then I'll rewrite gl-renderer in Rust and it will be impossible for there to be any errors)
<pq>
yeah, don't hurry. This needs all brain cycles to get right. :-)
<daniels>
all good, now that we actually have bpp accessible I think this points to more cleanups
<pq>
x liters + y meters = weight in kg
<pq>
love that kind of code, especially *when it works*
tzimmermann has quit [Quit: Leaving]
ufo-piloot has quit [Quit: you click on fancy icons. i execute code !]
ufo-piloot has joined #wayland
<tleydxdy>
<pq> "tleydxdy, it might have been a..." <- yeah I think it's just less "gotcha"s, existing either already have the check and it won't hurt anything or they have this bug and this simple change will address it.
<tleydxdy>
of course it might be a good idea to do so for all "destroy" style function where appropriate
<pq>
but it makes new code work fine, until someone tries it on e.g. Debiand stable, or such
<tleydxdy>
yeah, best option is to do it years ago
<pq>
:-)
<tleydxdy>
maybe add the check AND add documentation that user must check for null for old version sake?
<davidre>
what did you gain then?
dcz_ has quit [Ping timeout: 480 seconds]
<tleydxdy>
less mistakes in application code
<tleydxdy>
and less and less mistakes as old version go out of use
<davidre>
Not checking would be still a mistake when the documentation says you have to check :-)
<tleydxdy>
well 1 crash is better than 5 crash, idk
<kennylevinsen>
well, 1 app crashing on 4 out of 5 systems isn't that much better
<tleydxdy>
I agree the best fix is to use time machine
<tleydxdy>
but time police is on my ass already
<kennylevinsen>
you're making it sound like an API change is the only option
<kennylevinsen>
but... the app could just use the existing API correctly
devilhorns has quit []
<davidre>
And if your object has a destructor that will not even use wl_proxy_destroy iirc
<davidre>
So you would need to rebuild with a newer wayland_scanner that also checks for null?