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
fmuellner has quit [Ping timeout: 484 seconds]
abeltramo539129 has joined #wayland
abeltramo53912 has quit [Read error: Connection reset by peer]
coleman has quit [Remote host closed the connection]
coleman has joined #wayland
tlwoerner_ has quit []
tlwoerner has joined #wayland
kts has joined #wayland
cvmn has joined #wayland
d42 has quit [Read error: Connection reset by peer]
d42 has joined #wayland
smallville7123 has joined #wayland
<smallville7123>
is wayland capable of rendering a 1440 x 2960 resolution window?
repetitivestrain has joined #wayland
<repetitivestrain>
hi folks, i'm observing something that could either be a bug in sway, or in every other wayland compositor i tried (weston, my own, and mutter)
<repetitivestrain>
and it could be a bug in firefox as well
<repetitivestrain>
if you run firefox nightly with compositor integration enabled, and open a webgl page (where firefox uses a 180 degree transform)
<repetitivestrain>
firefox will assume the viewport source rect's Y coordinate must be transformed as well
<repetitivestrain>
the viewporter spec is unclear here, and wlroots seems to obey firefox's interpretation
<repetitivestrain>
while mutter, weston and my compositor treat the source rect as applying to the transformed and scaled buffer coordinate space
<repetitivestrain>
so who is correct here? weston or wlroots (and firefox)?
<vyivel>
repetitivestrain: link an example page please
<smallville7123>
is it possible to run wayland on windows and mac os
<repetitivestrain>
make the toplevel short enough to have to scroll through the webgl area
<repetitivestrain>
and scroll up and down so the area is occluded either at the top or the bottom
<repetitivestrain>
and see the difference in behavior between wlroots and mutter/weston
<repetitivestrain>
thanks
<vyivel>
welp, alpine doesn't package nightly, but can't repro with stable and developer edition in sway and weston
<repetitivestrain>
vyivel: i think both of those disable compositor integration
<repetitivestrain>
even if you try to turn it on
<repetitivestrain>
i used the nightly binaries from mozilla.org
<smallville7123>
anyone?
<repetitivestrain>
you have to go to about:config and set gfx.webrender.compositor.force-enabled
<repetitivestrain>
smallville7123: probably not, why are you asking?
<repetitivestrain>
and gfx.webrender.compositor.enabled
<vyivel>
yeah, i have all of those enabled since forever
<repetitivestrain>
go to about:support and see what is under WEBRENDER_COMPOSITOR?
<vyivel>
"blocked by runtime: Cannot be enabled in release or beta"... ugh
<vyivel>
is nightly packaged in arch?
<repetitivestrain>
vyivel: no idea, sorry; i use fedora
kts has quit [Quit: Leaving]
cvmn has quit [Ping timeout: 480 seconds]
<vyivel>
okay, can repro now
<repetitivestrain>
thanks
<vyivel>
another bug: in weston, if the window is shorter than a single ff subsurface (1024x512 iirc), damaging is broken
smallville7123 is now known as Guest4494
smallville7123 has joined #wayland
<repetitivestrain>
right, ig that should be fixed as well
<repetitivestrain>
but the important thing for me is still who has the correct viewport behavior
<repetitivestrain>
as mutter seems to behave like weston
<repetitivestrain>
and my compositor too
<vyivel>
mutter, kwin, weston, and smithay seems to behave identically, with weston and smithay (anvil) having damage issues
<vyivel>
wlroots draws everything as intended
<vyivel>
so, either wlroots is right, or firefox incorrectly depends on incorrect wlroots behavior
Guest4494 has quit [Ping timeout: 480 seconds]
<vyivel>
the spec says that cropping happens after transforming...
* vyivel
is confused
* repetitivestrain
too
<smallville7123>
is it possible to upload 17 MB to the GPU every frame with an FPS of 60 ?
danvet has joined #wayland
<repetitivestrain>
smallville7123: even if you could it would probably be a bad idea
<repetitivestrain>
battery usage and all that
<smallville7123>
why?
<repetitivestrain>
unless you were writing a video game
<repetitivestrain>
try it and look at intel_gpu_top
<repetitivestrain>
(or your gpu's equivalent)
<repetitivestrain>
so why exactly do you want to do that?
<smallville7123>
eg, full-screen 1440 x 2960 application
<smallville7123>
eg, full-screen 1440 x 2960 application with RGBA format *
<repetitivestrain>
smallville7123: any reason it can't do damage tracking and only damage parts of the buffer that actually changed?
<vyivel>
assuming that's a 3D game, tracking damage doesn't sound viable
<repetitivestrain>
vyivel: that's why i asked
<dottedmag>
smallville7123: One cannot "run Wayland" on macOS or Windows. Wayland is a protocol. It might be implemented in software that can be run on Windows or macOS, but so far nobody volunteered to make it happen.
<repetitivestrain>
i also can't imagine making a 3d game with shm buffers...
<smallville7123>
if a device wants to be able to run a 1440 x 2960 display at 60 FPS what would it's hardware requirements be?
<repetitivestrain>
smallville7123: that is too general a question
<smallville7123>
hmmm
<repetitivestrain>
can you explain what you're trying to do?
<dottedmag>
I really wish Wayland was named EUDMP
<dottedmag>
or something like this
<repetitivestrain>
*why* does your application need to upload a 1440x2960 buffer on each frame?
<smallville7123>
im trying to figure out how to make a compositor for a 1440 x 2960 display that can run at 60 FPS
<repetitivestrain>
smallville7123: any particular reason your compositor can't do damage tracking and culling and only upload parts that really changed and have to be drawn?
<dottedmag>
smallville7123: Are you making a compositor for a single app? Then you can skip the compositor and protocol part.
kts has joined #wayland
<smallville7123>
cus it may be compositing a full screen object
<smallville7123>
eg a 1440 x 2960 video or game
<smallville7123>
or simply a 1440 x 2960 app that constantly redraws itself
<smallville7123>
we cannot control how fast our client wants to draw
<smallville7123>
nor can we control how our client draws
<smallville7123>
at most, we can only assume our client will do a full redraw every single frame
<tleydxdy>
if the client already draws on the gpu (it probably does) then you won't need to update to the gpu, if not too bad perf will suck
<tleydxdy>
*upload
<smallville7123>
even if it never actually draws any changing content
<smallville7123>
eg it could simply draw a red screen every frame
<smallville7123>
or a bitcure or whatever
<smallville7123>
picture*
<smallville7123>
in fact it would NEED to do this cus opengl double buffering'
<smallville7123>
it needs only render a cached texture every single frame
<smallville7123>
and this texture object can be a max of 1440 x 2960 resolution
<smallville7123>
and we cannot determine if this texture object's contents have actually changed or not
<smallville7123>
anyway, every frame we would need to submit a 1440 x 2960 texture to the GPU, and we would need to be able to do so in under 16 ms if we want 60 FPS rendering
<smallville7123>
the only problem is the compositor and the client are in seperate processes
zebrag has quit [Remote host closed the connection]
kts has quit [Quit: Leaving]
<repetitivestrain>
smallville7123: you can more or less control how it draws by controlling how quickly frame callbacks are sent
<repetitivestrain>
if it draws via GL then you're probably importing dmabufs in which case the compositor needs to upload nothing to the gpu
<smallville7123>
nvm i need to figure out how to fork a process on windows ;-;
<repetitivestrain>
smallville7123: are you trying to port wayland to windows?
<smallville7123>
more or less
<smallville7123>
im trying to make a crash-resistant plugin system
<repetitivestrain>
wayland can't work there, it's built around notions specific to unix, e.g. file descriptors as ancillary data
<repetitivestrain>
or posix shared memory (if you're implementing keymaps or wl_shm)
<repetitivestrain>
but it isn't posix shared memory, where you allocate an fd, truncate it, and map it around
<smallville7123>
rip
<smallville7123>
hmmm
<smallville7123>
fork and pthreads are not compatible. If you fork a process containing semaphores, mutexes etc, their state in the new process is *undefined*. (I ran into this with another program where on some Linux systems it would work and on other Linux systems it would not work. Turned out that certain versions of the Linux kernel on certain architectures would silently unlock any semaphores when the process was forked.)
<smallville7123>
About the only thing you can do in a pthreads-using application with fork is to immediately exec afterwards, and even that's problematic (if another thread opens a file descriptor just before the fork the file descriptor will end up being propagated to the child process)...
dcz_ has joined #wayland
<repetitivestrain>
how is that related to wayland? (or fork in general)
rv1sr has joined #wayland
kts has joined #wayland
floof58 is now known as Guest4500
floof58 has joined #wayland
Guest4500 has quit [Ping timeout: 480 seconds]
mupuf has quit [Remote host closed the connection]
Leopold has joined #wayland
mupuf has joined #wayland
rasterman has joined #wayland
<dottedmag>
telegra
<dottedmag>
oops, wrong window
___nick___ has joined #wayland
systwi has quit [Read error: Connection reset by peer]
<repetitivestrain>
robertmader: you're Robert Mader from collabora, right? since you have lots of experience with both mutter and firefox, can you tell me whether or not firefox and wlroots are doing viewports correctly or not? thanks a lot. the context is that firefox seems to assume that if a counter-clockwise-180 buffer transform is set on a surface, the src_y of a viewport must be specified flipped as well
<repetitivestrain>
so if you go to a gl page and scroll to partly obscure a webgl subsurface (which has a 180 transform set) on mutter the actual source_y will not change
<repetitivestrain>
but if you do the same on wlroots it will
kts has joined #wayland
mokee has joined #wayland
<repetitivestrain>
which seems to contradict the spec
<repetitivestrain>
so i'm leaning towards wlroots being wrong here
kts has quit [Quit: Leaving]
<vyivel>
actually, i think src.y will change, in buffer-local coordinates
<vyivel>
viewporter.xml specifies that cropping is applied after transforming
<vyivel>
consider a buffer with flipped-180 transform and a viewport with source somewhere in the top left corner of the buffer
<vyivel>
after the buffer is flipped, the viewport source will point at the bottom left corner of the buffer
<vyivel>
repetitivestrain: you might want to make a minimal client which does that and check its behavior with different compositors
<repetitivestrain>
btw unrelated wlroots bug: if you run weston-simple-damage --rotating-transform in sway, the ball in the first frame is stuck
<repetitivestrain>
until further damage wipes it at some point
<repetitivestrain>
also i think the minimal repro is just weston-simple-damage --rotating-transform --use-viewport
<vyivel>
--rotating-transform is broken everywhere lol
<vyivel>
try running it in weston or mutter
<repetitivestrain>
it works in my compositor for some reason...
<vyivel>
kwin? maybe it reuploads the buffer every frame, idk
<repetitivestrain>
nope, what i wrote
<repetitivestrain>
i spent HOURS debugging
<repetitivestrain>
just to make rotating-transform work
<repetitivestrain>
what mutter does is very funny
<repetitivestrain>
looks like a game of snake
<repetitivestrain>
it kinda works in kwin but the viewport is messed up
<vyivel>
well, it doesn't work properly in wlroots, mutter, and smithay
<vyivel>
repetitivestrain: i've made a simple client which 1) creates a 600x600 buffer, with the upper half of it red and the lower half black; 2) sets flipped-180 transform; 3) sets x=150,y=150,width=200,height=200 viewport source
<vyivel>
the result (top 3/4 is black, bottom 1/4 is red) is identical in weston, mutter, and sway
Leopold has quit [Remote host closed the connection]
Dami_Lu has quit [Read error: Connection timed out]
<repetitivestrain>
i'll try to find out what exactly firefox does tomorrow, must've mixed something up looking at WL_DEBUG=all output
<repetitivestrain>
but if anyone else knows pls don't hesitate to share
jmdaemon has quit [Ping timeout: 480 seconds]
hendry has quit [Quit: brb]
___nick___ has quit []
___nick___ has joined #wayland
hendry has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
floof58 has quit [Remote host closed the connection]
floof58 has joined #wayland
rv1sr has quit [Ping timeout: 480 seconds]
hardening has joined #wayland
nerdopolis has joined #wayland
bluepqnuin is now known as bluepenquin
rasterman has joined #wayland
smallville7123 has quit [Ping timeout: 480 seconds]
Compy_ has joined #wayland
<Compy_>
Somewhat of a generic question: I'm trying to get both an SDL2 and GStreamer application to use Wayland (weston) on a buildroot based system, targeting an Allwinner H3/Mali400 hardware. I built SDL2 with wayland support and launch weston with "weston --backend=drm-backend.so --tty=2 --continue-without-input" which puts the shell on screen. However when launching SDL2, I get a bunch of undefined symbol messages like "DEBUG:
<Compy_>
Failed loading wl_egl_window_create: /usr/lib/libwayland-client.so.0: undefined symbol: _wl_egl_window_create" which state wayland isn't available. (I'm running SDL_VIDEODRIVER=wayland), and I set my LD_LIBRARY_PATH to /usr/lib where libwayland is. Anyone ever run into something similar on an embedded setup?
coleman has quit [Ping timeout: 480 seconds]
coleman has joined #wayland
kts has joined #wayland
<dottedmag>
This is more of a Buildroot question.
<Compy_>
yeah, I'm also shaking the SDL2 tree to see if they have any insight.
<Compy_>
I'll fire off a question to the buildroot mailing list, though they just provide the makefiles. Likely someone has run into this before.
<Compy_>
Thanks Misha!
rv1sr has joined #wayland
<dottedmag>
I don't think SDL2 is related: it tries to find wl_egl_window_create in libwayland-client.so.0, as it supposed to. However libwayland-client.so.0, presumably, does not have this symbol.
<dottedmag>
Compy_: Actually it is probably a red herring. SDL2 tries to load symbols in order in libwayland-client.so.0, libwayland-egl.so.0, libwayland-cursor.so.0 etc. wl_egl_window_create is in the second in the list, so the error is correct.
glennk has quit [Remote host closed the connection]
glennk has joined #wayland
<Compy_>
hmmm, yeah, you're right dottedmag. I see the symbol sitting in libwayland-egl.so. I'll splunk a bit more to see where its choking up
<Compy_>
Thanks again!
<Compy_>
Looks like a call via SDL2 internally to `wl_display_connect` fails (returns NULL).
<Compy_>
a ha. XDG_RUNTIME_DIR contains wayland-1, not wayland-0 that SDL2 is expecting
rasterman has quit [Remote host closed the connection]
rasterman has joined #wayland
kts has quit [Quit: Leaving]
Hypfer is now known as Guest4538
Hypfer has joined #wayland
Guest4538 has quit [Ping timeout: 480 seconds]
manuel_ has quit [Ping timeout: 480 seconds]
Hypfer has quit [Read error: No route to host]
Hypfer has joined #wayland
<Compy_>
Alright, looks like it is a bug in SDL2 where it segfaults if it runs on wayland without any inputs. Now a more generic wayland question. I'm trying to design an embedded application where the display is a composite of multiple processes. One process would be gstreamer rendering via waylandsink, and SDL2 sitting on top of that for OSD type things. However, I don't think wayland has any way to control the z-ordering of
<Compy_>
things. (So I could make sure that SDL2 always sits on top). Is that correct? (I'm using weston currently)