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
<LaserEyess>
but still, that function never returns, and I'm unclear why that is
<LaserEyess>
"When being called at a point where other threads have been prepared to read (using wl_display_prepare_read_queue() or wl_display_prepare_read()) this function will sleep until all other prepared threads have either been cancelled (using wl_display_cancel_read()) or them self entered this function. The last thread that calls this function will then read and queue events on their corresponding event
<LaserEyess>
queues, and finally wake up all other wl_display_read_events() calls causing them to return."
<LaserEyess>
there's no other thread that's calling this though...
jmdaemon has joined #wayland
<repetitivestrain>
is there a way to hang user data off a struct wl_client?
<repetitivestrain>
the data is presumably created upon client connection
<repetitivestrain>
and released upon disconnect
<emersion>
with the destroy listener yes
<repetitivestrain>
yeah but i can't find anything along the lines of wl_client_set_user_data :(
Dami_Lu has quit [Read error: Connection reset by peer]
<romangg>
Are there some good test clients for xdg-shell popups protocol version 2 and 3?
slattann has joined #wayland
<Compy_>
Alright, so I have a kiosk shell configured for 1280x720@60. I have an auto-start application (say either SDL2 or gstreamer with a waylandsink). I've set the shell background to red, and assigned the appropriate appids to the HDMI output. When kiosk shell runs, I see the red background, I can see my apps running and reporting to stdout, but I never see anything on screen. However if I swap the shell directive out for
<Compy_>
desktop-shell, I can see both apps. Any idea why this is? I've been poking and prodding at logs and code and can't seem to figure out what would cause it.
nerdopolis has quit [Ping timeout: 480 seconds]
<tleydxdy>
the app need to support kiosk shell too I think
mxz has quit [Quit: cya]
mxz has joined #wayland
Guest586 is now known as DrNick
jgrulich has joined #wayland
kts has joined #wayland
tzimmermann has joined #wayland
cvmn has joined #wayland
slattann has quit [Read error: Connection reset by peer]
kts has quit [Quit: Leaving]
hardening has joined #wayland
<daniels>
tleydxdy: no they don’t need specific support, just xdg
<daniels>
Compy_: are you running 11.0 release or git?
<pq>
tleydxdy, to clarify, "kiosk shell" is not a protocol extension, it's only a shell plugin in Weston. Confusingly, "fullscreen shell" is a protocol extension *and* a Weston shell plugin requiring clients to use that extension. Also "fullscreen shell" has nothing to do with the fullscreen window state (of xdg-shell).
<pq>
Kinda makes me wish "fullscreen shell" was named something else.
<pq>
LaserEyess, if you call wl_display_read_events() without first polling the socket fd and ensuring there is something to read, then yes, it will block until there is something to read.
<pq>
LaserEyess, FWIW, if you use EGL Wayland platform as well, then the EGL implementation will be reading the Wayland socket too (but not in its own hidden thread, only when you call EGL or GL).
kts has quit [Quit: Leaving]
slattann has joined #wayland
Dami_Lu has joined #wayland
pax^ has joined #wayland
pax^ has quit [Excess Flood]
sudocurse_ has quit [Write error: connection closed]
daniels has quit [Write error: connection closed]
hwentlan_ has quit [Read error: No route to host]
hwentlan_ has joined #wayland
jimjams has quit [Read error: Connection reset by peer]
smurray has quit [Read error: Connection reset by peer]
panzeroceania___ has quit [Write error: connection closed]
jimjams has joined #wayland
bwidawsk has quit [Remote host closed the connection]
zzag has quit [Remote host closed the connection]
sudocurse_ has joined #wayland
zzag has joined #wayland
bwidawsk has joined #wayland
Major_Biscuit has quit [Ping timeout: 480 seconds]
<LaserEyess>
pq: no, I'm really not sure of anything at this point, not even sure enough to ask the right questions if I'm being honest
<LaserEyess>
I am not the original author of this code
<LaserEyess>
I am only trying to get it merged, since the original author has a particular disdain for linux it seems
<LaserEyess>
dolphin is tricky because it's tryign to create a new window with EGL/Vulkan for the game, separate from the qt window being used for the general UI
<pq>
however, mind to not call roundtrip functions from inside an event handler
<zzag>
so should other compositors stop honoring the y invert flag? or what's the fate of the y inverted flag? will it be or is it deprecated?
<LaserEyess>
pq: there is a second roundtrip call in the wayland input code
<LaserEyess>
and it mentions something like that
<LaserEyess>
the thing is, this deadlock is occuring between the wayland input event code and the QT UI code, I assume they're both stepping over each other or something
<LaserEyess>
but dolphin needs separate input handling code for the game window, so I cannot really be sure how badly of an API misuse this is, or if it's just a small abuse and the rest is bad dolphin code given its architecture
<LaserEyess>
¯\_(ツ)_/¯
<pq>
LaserEyess, sorry, the deadlock is completely separate from that roundtrip comment. The roundtrip is just some unrelated oddity I noticed.
<davidre>
LaserEyess: Which Qt version are you using? Qt was somewhat wrong in the past
<LaserEyess>
6
<pq>
LaserEyess, so do you have a deadlock somewhere else, or do you see the program sleeping in a readmsg syscall?
cool110 has quit [Ping timeout: 480 seconds]
<davidre>
Ok 6 has no problem
<LaserEyess>
pq: correct, the deadlock is immediately when the program starts, before any window even opens and is displayed
<LaserEyess>
dolphin goes through and enumerates its input devices (including special things like wiimotes), and a wayland keyboard/mouse is an "input device", so it starts listening for inputs
<pq>
LaserEyess, is something calling wl_display_read_events() with some dolphin or Qt locks held?
<LaserEyess>
in that, it calls the device lock, but it can't, because in a separate thread the listener queue for wl_display_read_events is continually waiting for "something"
<LaserEyess>
so it just sits there in wl_display_read_events(), holding the lock that the main UI thread needs to start the window
<pq>
wl_display_read_events is waiting for other "threads" that have already called wl_display_prepare_read(), IIRC.
<LaserEyess>
yes
<LaserEyess>
but no one call tell me what those threads are...
<LaserEyess>
any dolphin devs, I mean
<LaserEyess>
clearly you guys don't know
<pq>
EGL has one, but EGL also does not hold internal locks while doing it
<LaserEyess>
that EGL code sholdn't be running at all
<LaserEyess>
it's only for the game window, and the main UI window hasn't even started yet
<pq>
also Qt pretty surely has one or more
<LaserEyess>
I would assume, yes
<LaserEyess>
but why aren't they calling wl_display_prepare_read()?
<pq>
surely they are?
<pq>
that's the whole reason why wl_display_read_events() does not make progress: someone called prepare_read, but then did not actually read nor cancel.
<LaserEyess>
oh, then that
<pq>
so, set up a breakpoint on prepare_read and see where it gets called from, and for read_event and cancel_read too
<LaserEyess>
hm
<LaserEyess>
I forgot I could do that
<pq>
heh
<Compy_>
daniels: I tested on both 10.0.1 and 11.0.0. Same behavior was observed. Both applications work fine with desktop-shell, but won't show up on kiosk shell.
<pq>
hopefully you can identify each "context"
<pq>
LaserEyess, wl_display_prepare_read_queue() is the one, and you also need to observe its return value, because if it fails, it doesn't count and is retried.
<pq>
but maybe that's obvious from the context
<LaserEyess>
none of this is obvious to me :')
<pq>
I mean the stack trace
<LaserEyess>
as I said before, one of my first steps is to learn enough to ask teh right questions
<davidre>
In the above backtrace you posted "WaylandEventThread" are threads created by Qt, so it might be useful to see what the y are doing in that moment of time
<daniels>
Compy_: can you please try git main? there’s a fix in there which might help
<LaserEyess>
I wonder if this issue is that this initalization code is just happenign too early
<LaserEyess>
because QT should be handling everything until the game window comes up
<LaserEyess>
and I assume it stops reading events when it's not in focus
<LaserEyess>
anyway, more work to do but thank you for the hints, pq and others
<pq>
good luck :-)
<pq>
LaserEyess, I don't think postponing things is going to solve anything, at worst it might hide problems.
<LaserEyess>
I just don't see why the keyboard/mouse game input needs to be listening before a game has even started
<LaserEyess>
to be clear, dolphin has two primary windows: the QT UI window, and a separate window that is started for games, that shares no focus with the QT UI
<pq>
sure
<LaserEyess>
wayland input is only needed for that window
<pq>
but all those windows will share the wl_display, right?
<LaserEyess>
I guess?
<pq>
that would be the Wayland way, anyway
<pq>
since if you have two wl_displays, you cannot cross-reference any Wayland objects between the two.
<pq>
all Wayland objects are private to the wl_display where they were created.
<LaserEyess>
I'm struggling to think what those two windows would want to share together though
<LaserEyess>
in theory they're completely separate
<pq>
mm, perhaps, I'm not familiar with the UI
fmuellner has joined #wayland
<LaserEyess>
well, I just thought of an even easier way to determine if qt is blocking this
<LaserEyess>
dolphin has a nogui mode that launches only a game window
<pq>
libwayland-client is designed so that any number of threads (or contexts, does not need to be actual threads) can attempt to read the Wayland socket at any time. Only one at a time will actually read the socket, but it will read everyone's events from that socket. Dispatching the events is separate.
fmuellner has quit [Remote host closed the connection]
<LaserEyess>
that is actually exactly the function causing the deadlock
<pq>
it all depends on where does KeyboardMouse::UpdateInput() get called from.
<pq>
yeah, but it's blocking on the mutex and cond var, not in actual read syscall, right?
<pq>
ISTR your stack trace has pthread_cond_wait something in it, not recvmsg?
<LaserEyess>
yes
<pq>
right
<LaserEyess>
no one owns the mutex, so it's waiting on the cond var
<pq>
so it is a real deadlock and not just a blocking read.
<LaserEyess>
yes
<pq>
the way that can happen is that someone does prepare_read, but no raed_events nor cancel_read :-)
<LaserEyess>
yes, as you alluded to earlier
<LaserEyess>
a very useful hint
<pq>
good, so I think you're on to it, and we're on the same page
<LaserEyess>
the only other thing that *should* be reading events is QT
<pq>
that UpdateInput() function is suspicious for a reason separate from the daedlock you have
<LaserEyess>
this KeyboardMouse object here is an emulated device abstraction for e.g. mapping a keyboard/mouse to a controller/wiimote
<LaserEyess>
before a game starts, I don't think it needs to read *any* inputs
bilelmoussaoui has joined #wayland
<LaserEyess>
I have to confirm that with dolphin devs, though
<pq>
if the user stops pressing any keys and moving the mouse, should the game engine freeze until they move and type again? :-)
<LaserEyess>
pq: yes, it's continuously polling in another thread, and when it polls it gets the devices lock which prevents dolphin from loading/checking input configs
<LaserEyess>
and then the UI cannot proceed in loading
<LaserEyess>
something is wrong here, and I suspect it's a subtle combination og wayland API misuse and dolphin cointroller API misuse
<LaserEyess>
man I suck at typing
nerdopolis has joined #wayland
<pq>
me too
<pq>
I didn't quite understand but "continuously polling in another thread" sounds a little odd... depending on what that means exactly.
<pq>
is it polling the Wayland socket, and then telling another thread to go call KeyboardMouse::UpdateInput()?
<LaserEyess>
there's another thread that polls all inputs for updates
<LaserEyess>
no, for dolphin to process keys
<LaserEyess>
when it's polling those inputs, it takes the devices lock so no new devices can be added (I think)
<pq>
anyway, we are digressing here - these are just theoretical problems and not the deadlock you have
<LaserEyess>
yeah
<pq>
have fun with breakpoints :-)
<LaserEyess>
thanks...
<Compy_>
daniels: Yeah, thanks for the tip! I'll pull down the latest main branch of weston and send off a new build. :)
<pq>
maybe they change the timings and it won't deadlock...
<LaserEyess>
wouldn't that be fun
<pq>
threads often are
<LaserEyess>
threads are very good when there are like 2 of them, or a threadpool that syncs with only one thread
<LaserEyess>
12 is a nightmare... especially when mo less than 4 are interacting
<tleydxdy>
for multithread and wayland, one of the thread need to handle the wayland connection exclusively right?
<emersion>
libwayland has a concept of queues
<emersion>
for sharing the same wl_display across multiple processes
<emersion>
err, threads
<tleydxdy>
but there's still a thread that owns the queue?
<emersion>
one queue per thread, yeah
<pq>
tleydxdy, read a little above, I just explained that.
<emersion>
even with 2 threads there's already plenty of potential for headhaches :P
<emersion>
headaches*
bilelmoussaoui has quit [Remote host closed the connection]
<pq>
Event queues are indeed what allow dispatching events in the correct context, and not from the random thread that happened to read the socket.
<pq>
this way all sockets can read, they don't need to tell another thread to read
<tleydxdy>
pq: I see so there's a way to tell which event is for which thread?
<pq>
err, all threads can read
<pq>
tleydxdy, Wayland objects are associated with event queues. Any events for the object is placed into the respective queue.
<emersion>
tleydxdy: wl_proxy objects belong to one queue, their thread will get all events for that wl_proxy
<LaserEyess>
two threads are fine imo as long as you're not doing silly things like reading and writing to the same resources while using locks
<LaserEyess>
but unfortunately, that's exactly what's going on...
<pq>
then it's up to the caller to ensure they dispatch the right queue from the right thread, and that the queue assignments are right
<tleydxdy>
basically all thread could read from the socket, and they'll put the events into the right queue, then the correct thread can pick up the event from the correct queue
<pq>
exactly
rv1sr has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
tlwoerner_ has quit []
tlwoerner has joined #wayland
ybogdano has joined #wayland
Company has joined #wayland
mokee has quit [Remote host closed the connection]
devilhorns has quit [Remote host closed the connection]
devilhorns has joined #wayland
tzimmermann has quit [Quit: Leaving]
columbarius has joined #wayland
ybogdano has quit [Read error: Connection reset by peer]