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
nsneck has joined #wayland
nigelvr has quit [Remote host closed the connection]
Lucretia has quit [Ping timeout: 480 seconds]
spstarr has quit [Remote host closed the connection]
ppascher has quit [Ping timeout: 480 seconds]
ppascher has joined #wayland
lagash has quit [Ping timeout: 480 seconds]
lagash has joined #wayland
soreau has quit [Read error: Connection reset by peer]
maxzor has quit [Remote host closed the connection]
maxzor has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
Azem has joined #wayland
whot1 has quit []
whot has joined #wayland
Emet-Selch has quit [Ping timeout: 480 seconds]
zebrag has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
zebrag has joined #wayland
bittin has quit [Remote host closed the connection]
bittin has joined #wayland
shankaru has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
colordrops has quit [Remote host closed the connection]
colordrops has joined #wayland
bittin has quit [Remote host closed the connection]
colordrops has quit [Remote host closed the connection]
colordrops has joined #wayland
reillybrogan has quit [Ping timeout: 480 seconds]
reillybrogan has joined #wayland
reillybrogan_ has joined #wayland
danvet has joined #wayland
reillybrogan has quit [Ping timeout: 480 seconds]
dcz_ has joined #wayland
reillybrogan has joined #wayland
jgrulich has joined #wayland
reillybrogan_ has quit [Ping timeout: 480 seconds]
reillybrogan has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
reillybrogan has joined #wayland
reillybrogan has quit []
reillybrogan has joined #wayland
bodiccea has quit [Remote host closed the connection]
bodiccea has joined #wayland
colordrops has quit [Quit: WeeChat 3.3]
maxzor has quit []
MajorBiscuit has joined #wayland
reillybrogan_ has joined #wayland
hardening has joined #wayland
reillybrogan has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
reillybrogan has joined #wayland
reillybrogan_ has quit [Ping timeout: 480 seconds]
jmdaemon has quit [Quit: WeeChat 3.4]
rgallaispou has joined #wayland
maxzor has joined #wayland
<pq>
Company, weston's clients/simple-dmabuf-egl.c does just that.
jmdaemon has joined #wayland
<emersion>
but it's not complete
<pq>
Company, the approach used in simple-dmabuf-egl.c requires you to render into a GL FBO. If it is easier for you to have an actual EGLSurface, then you could use GBM to create a gbm_surface. You can get the buffers out of that too.
<pq>
sure it's not complete, but a different example than Mesa
<pq>
it's missing dmabuf feebback handling I think? what else?
<emersion>
gbm_bo_create_with_modifiers2
<emersion>
it's using drmPrimeHandleToFD, which messes up the cleanup sequence
<emersion>
doesn't free swapchain slots
<pq>
ok, do we have a another non-Mesa example? you said wlroots?
<emersion>
yeah, but wlroots is a compositor
<emersion>
so it does things which may not make sense for a regular client
<pq>
what are those?
<jadahl>
Company: is there any other reason why you want to reimplement all the EGLSurface logic other than getting to call wl_surface_commit() yourself?
<emersion>
also it supports mixing and matching any of (pixman, gl vulkan), (gbm, shm, DRM dumb buffers), and (kms, wayland, x11, headless)
<emersion>
pq, emphasis on an architecture which allows easy passthrough of client buffers
<pq>
jadahl, is that not a big enough reason in GTK's internal architecture? Btw. would this affect custom surface role support or GL canvas?
<emersion>
Company: to be clear, i'm nbot saying it's a bad idea, just trying to explain what this implies
<emersion>
and also keep in mind all of that stuff is a moving target
<emersion>
not*
<pq>
I think alf is testing the gbm_surface way in Wine due to internal Wine architecture which makes anything else much more pain.
<jadahl>
pq: for me it has only caused minor pain, and wouldn't justify adding all that complexity, but Company have different ideas I guess
<pq>
like one Windows process rendering into another process' window
<emersion>
can't you export/import dmabufs without using gbm_surface for this?
<pq>
emersion, he could, but having an actual EGLSurface seems to make things easier.
<emersion>
this would let the EGL driver do the allocation
<pq>
gbm_surface buffers are allocated by the driver, no?
<pq>
while import/export buffers would not be
<emersion>
yeah, but not tied to the real underlying WSI
<pq>
can you clarify what possible problem you see?
<emersion>
you could use a regular EGLSurface in one process, then export/import individual buffers to a secondary process
<pq>
emersion, yeah, that's what it's going to do with gbm_surface.
<pq>
you have to back the EGLSurface with a gbm_surface, or you cannot get the buffers out.
<emersion>
well, let's say i don't trust random clients to implement dmabuf modifiers, feedback, device selection, wl_drm/modifierless fallbacks, etc
<emersion>
pq, can't you get the buffers out with an opaque EGLSurface?
<emersion>
hm
<pq>
no
<pq>
EGL does not give you buffers. Period.
<pq>
GBM is the escape hatch.
<emersion>
right, MESA_image_dma_buf_export takes an EGLImage
<emersion>
vulkan fixes this issue with a different design
<pq>
sure :-)
<pq>
if you want to use OpenGL any flavor, I know of only two usable ways to get dmabuf out: gbm_bo_create*() -> EGLimage -> render to FBO; or gbm_surface_lock_front_buffer() and render to EGLSurface.
<emersion>
yea
<pq>
existing code bases might have trouble adapting to "surprise, your window is actually an FBO" which means one has to intercept all switches of the active FBO at least.
<pq>
if you have a real EGLSurface, you don't need to play those tricks
<pq>
Company, ^
<pq>
Of course, even if one is separating the eglSwapBuffers from the actual wl_surface_commit, you still need careful synchronization between the two so that the content corresponds to the window state.
Major_Biscuit has joined #wayland
MajorBiscuit has quit [Ping timeout: 480 seconds]
eroux has joined #wayland
pnowack has joined #wayland
immibis is now known as Guest436
immibis has joined #wayland
Guest436 has quit [Ping timeout: 480 seconds]
taal has joined #wayland
taal has quit []
taal has joined #wayland
taal has quit []
piero has joined #wayland
piero has quit []
cvmn has joined #wayland
bittin has joined #wayland
maxzor has quit [Ping timeout: 480 seconds]
bittin has quit [Read error: Connection reset by peer]
flacks has quit [Quit: Quitter]
flacks has joined #wayland
<Company>
jadahl: I have no plans of doing it, this was purely a theoretical question because of hergertme's work with Mac OS
<Company>
but it might make sense at some point, even just for testing hidden behind an env var (like we did EGL + GLX on X11 for a while)
<Company>
I just never realized that it could be made to work
<pq>
It would be a significant chunk of work...
<Company>
yeah, that's what I learned
<daniels>
emersion: dma_buf_export also doesn't let you specify modifiers, you're just at the whim of whatever the driver happened to select, and you can't export from a surface ... ?
<daniels>
(unless I'm missing something which lets you get an EGLImage for whatever your current backbuffer is)
cabal704 has joined #wayland
cabal704 has quit []
cabal704 has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
maxzor has joined #wayland
immibis is now known as Guest445
immibis has joined #wayland
Guest445 has quit [Read error: Connection reset by peer]
devilhorns has joined #wayland
cvmn has quit [Ping timeout: 480 seconds]
<jadahl>
Company: it could definitely be done but feels rather pointless
<jadahl>
and you'd end up depending on not only egl but also gbm
l4s8g has joined #wayland
<Company>
so it's basically the same level as "write a gbm backend"
<Company>
I assume that's just a thin wrapper around the corresponding Wayland API?
<pq>
there are two different things with damage, and one of them Wayland has, the other has no relation to Wayland, and I always have to check which one is which
<Company>
I remember feaneron fixing that in Mesa when GTK4 started not sending proper damage regions to mutter
<pq>
the two things being: buffer damage and surface damage - Wayland only has the latter. The former is for a driver optimization.
<pq>
jadahl, if one goes the gbm_surface way, I think you can simply continue using the EGL extensions as-is. Just the surface damage you have to send manually through Wayland.
<jadahl>
Company: that one isn't related to wayland, it's hints to the driver of what will get damaged the next frame
<Company>
should we be using that in GTK? Are we?
cvmn has joined #wayland
maxzor_ has joined #wayland
cabal704 has quit [Quit: WeeChat 3.4]
maxzor_ has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
mvlad has joined #wayland
ofourdan_ has left #wayland [#wayland]
ofourdan has joined #wayland
<jadahl>
Company: don't think we are, but could probably do
<Company>
I have no idea what the benefit is
<Company>
and I have no idea how well our region tracking machinery would accomodate it
<Company>
plus, I don't know the semantics of all of this - are we allowed to accidentally render outside of that region (with undefined results) or do we have to make sure we don't?
<jadahl>
Company: only
<jadahl>
measuring will tell us that
<jadahl>
no the point is to tell what regions are relevant for the coming set of draw calls before the next swap buffer
<jadahl>
if you draw outside of that region, you did things wrong
<Company>
well, there's the change region
<Company>
but we set the scissor rect to the extents of that region
<Company>
because that's a rect after all
<Company>
and then we draw normally, trying to cull things we know are outside that scissor rect
<Company>
but sometimes we don't, but who cares because the scissor rect is there
<Company>
no idea how that translates to that API
<pq>
I think that should just work.
<pq>
The benefit of partial update depends on the driver and GPU hardware architecture I believe.
<pq>
it's never going to hurt, but on some systems it may be a win
<pq>
jadahl, is GTK using buffer_age already?
Lucretia has joined #wayland
<jadahl>
pq: IIRC yes
<pq>
good, it's a pre-requisite for using partial_update
<pq>
measuring probably won't tell you, unless you measure on the hardware where partial update actually makes a difference - I can't figure out what kind of hardware that might be.
<pq>
Knowing which parts of a buffer are *not* going to be touched would allow to not load them into a cache used for rendering.
Major_Biscuit has quit [Ping timeout: 480 seconds]
<pq>
I thought this would be useful on tiled rendering hardware, but then I suppose the binning pass should be able to tell the same? Or maybe not easily enough, hence allowing the app to explicitly give the information.
<jadahl>
when partial update was added to mutter, measuring using performance counters on the lima driver showed some improvements
<daniels>
Company: drawing outside the declared update region is UB
Major_Biscuit has joined #wayland
<pq>
ok, so on lima and that hardware would be a good platform to measure
<Company>
GTK was instrumental in robertmader[m] finding the buffer age bug!
<Company>
cactually, what happened to that?
cvmn has quit [Ping timeout: 480 seconds]
<Company>
so I'll leave such a patch to the lima people - because they can also test if it breaks stuff
<zebrag>
I have a trackball on Cherry g84-440 keyboard, the module could be Logitech, or not. Sometimes it is getting very sluggish, to the verge of totally unusable. I found a workaround that was not working a year ago. I've just done it minutes ago. I remove the "ball". I see a red LED. It is steadily on. After a few seconds it stars blinking. Then it turns full blinking mode. Then I put the ball back in and it is fixed. Hum, I had to do it twice. So
<zebrag>
it seems like a manual "reset" function. I'd be happy if I could do that without having to disassemble the thing.
<zebrag>
Maybe a better firmware?
<zebrag>
It's already, as I said, working way better that it was a couple of years ago.
hardening has quit [Ping timeout: 480 seconds]
immibis has quit [Remote host closed the connection]