ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Brainium has quit [Quit: Konversation terminated!]
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
sima has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
rv1sr has joined #wayland
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #wayland
ciara has quit [Read error: Connection reset by peer]
junaid has joined #wayland
iomari891 has joined #wayland
pochu has joined #wayland
mvlad has joined #wayland
<pq>
daniels, a bit harsh to call me an enthusiast when pbuffers have always been just a trick to avoid complicating internal Weston APIs or to cater for proprietary drivers that cannot do surfaceless etc. EGL extensions. :-)
<daniels>
pq: sorry!
<pq>
daniels, I should asking *you* if there are any platforms left that need pbuffers, as I wouldn't know.
<daniels>
afaik no, happily!
<pq>
I'm not at all attached to pbuffers, if stuff works otherwise. :-)
<daniels>
\o/
<pq>
just make sure to get the coordinate systems right
<pq>
and none of that "I flipped it because I saw it upside-down" nonsense
Seirdy has quit [Ping timeout: 480 seconds]
<daniels>
/o\
<pq>
daniels, is the plan to get completely rid of EGLSurface usage on all platforms?
<daniels>
pq: that could happen as this makes it much easier but it wasn’t the plan - this is motivated by GL support for RDP/VNC
<pq>
even for X11 backend?
<daniels>
X11/Wayland/DRM are not touched in these MRs, but it would make it much easier to
<pq>
would be nice to have just a single renderer path
<pq>
no, I'm talking about future plans
<daniels>
ack
rasterman has joined #wayland
<daniels>
it would mean having those backends implement zwp_linux_dmabuf_v1/DRI3 which is annoying but doable
<pq>
so it actually is feasible for DRM-backend nowadays to stop using EGL GBM platform from the driver support perspective?
<pq>
even on embedded?
<daniels>
absolutely, I believe so
<pq>
cool
<pq>
I have nothing against such plans.
<pq>
but yeah, getting rid of the EGLSurface on Wayland and X11 may not be worth the cost, compared to having to maintain two paths (FBO and EGLSurface) in GL-renderer.
<jadahl>
I was considering getting rid of EGLSurface in mutter, but those plans were put on hold because some driver optimizations depend on EGLSurface being used
<emersion>
jadahl: if you have evidence that these optimisations matter, please comment on that issue
<pq>
daniels, so I read through the commit messages of 1106, even glanced at the code and left couple comments, but no objections to the idea.
cmichael has joined #wayland
<pq>
ooh, partial update
<emersion>
fwiw we've been using FBOs exclusively in wlroots for years
<jadahl>
emersion: "I checked the impact of this with the lima driver using the hardware performance counters for number of memory reads and writes done by the GPU.
<daniels>
emersion: amusingly, the people who passionately and vehemently insisted it was necessary, and that buffer_age+scissor+no-blend could never replicate the effect, which is why they blocked KHR for that extension and wrote buffer_age, are now being contradicted by their colleagues who shrug and claim it’s fine :)
<jadahl>
There is a drop in those numbers, sometimes significant"
<daniels>
great to see everything is still completely confused
<jadahl>
utter confusion is why AI can't replace us
<pq>
emersion, does wlroots run fine on separate and independent KMS and GPU devices on SoCs? daniels, are SoCs with no common formats between GPU rendering and KMS still a use case?
<daniels>
pq: I noted the FBO format thing in one of the sub-MRs btw - hopefully it could help clean up some of the internal-FBO code at some point
<daniels>
afaik it’s only i.MX6 left which does that, and you can I believe still render to linear gbm_bo (with an internal resolve)
<emersion>
lol
<emersion>
thanks jadahl
<emersion>
pq, yes, it runs fine, but had to carefully design the architecture for that
<emersion>
we don't support setups where there's no common format between render and display devices
<pq>
daniels, emersion, ok, thanks. Sounds good enough.
i509vcb has quit [Quit: Connection closed for inactivity]
<MrCooper>
emersion jadahl: AFAICT, without that MR mutter doesn't use glScissor for each rect though (possibly a single glScissor for the bounding box, not sure)
<pq>
Weston is not using Scissor at all...
<emersion>
wlroots was using scissors, but not anymore on GL (and soon will drop from Vulkan too)
<pq>
what made wlroots drop it?
<emersion>
we found that perf was better without scissors
<pq>
ha
<pq>
even on Vulkan?
<emersion>
haven't tried yet
<pq>
I'd totally believe that OpenGL state handling could have a perceivable overhead.
<daniels>
emersion: ... without?
<daniels>
on which hardware?
<pq>
I suppose Scissor cannot be arbitrarily complex, while lots of primitives could be packed into a single draw call...
<daniels>
mm, I guess the difference is that glScissor forces the implementation to clip and discard anything outside the bounds, whereas partial_update is a promise by the application that it won't be doing anything outside the bounds
<emersion>
it was surprising to me i must admit
<pq>
In Weston I would kinda like to batch all primitives (either opaque or blended) into a single draw call, but that means the geometry can be arbitrarily complex.
<pq>
Right now Weston is doing one draw call per damage rect.
Leopold___ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
junaid has joined #wayland
___nick___ has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
<mort_>
ever since the world moved to libinput I've felt like touchpad scrolling was way too sensitive... and I feel like I might've found a clue? Scroll speed feels perfectly reasonable when I put two fingers on the trackpad but only move one of them. So maybe the scroll delta which ends up being used is the sum of the two movements and not their average?
tjaden has joined #wayland
junaid has quit [Quit: leaving]
sima has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
iomari891 has joined #wayland
mvlad has quit [Remote host closed the connection]
<mort_>
I don't know, that might not be the explanation. But scrolling is for sure consistently at least twice as fast as it "should" be across all hardware I've tested (which includes a few different brands).
<ManMower>
doesn't your compositor have some sort of scroll speed setting you could just adjust to 1/2 of what it is now?
<ManMower>
I'm surprised moving a single finger of the two doesn't trigger as a pinch gesture. but I suspect the reason that moves 1/2 speed is just that the math ends up reporting the distance moved as the center between the fingers, giving you half of moving both
<ManMower>
I doubt this is really some kind of bug in libinput though - it just wasn't written with "maintain the exact behaviour of legacy systems" in mind, and just defaults to being faster
<ManMower>
but take all of that with a pinch of salt. I'm not really an input guy. :)
<mort_>
GNOME doesn't have a scroll speed setting
<mort_>
moving only one finger does trigger a pinch gesture, but if you start moving both fingers and then stop one it keeps the scroll gesture
<mort_>
there is *definitely* a bug here somewhere, since the scroll speed is truly ridiculously unbelievably fast across all hardware I have tested
<mort_>
as in "scroll tens of pages in one swipe" fast
<mort_>
maybe that's an exaggeration but you get the point. The way I've heard it described is that scroll distance should be about equivalent to cursor movement distance for the same sized movement, and it's very far from that
tent405 has quit [Ping timeout: 480 seconds]
jsto has quit [Quit: jsto]
i509vcb has joined #wayland
nerdopolis has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
kts has quit [Quit: Konversation terminated!]
jsto has joined #wayland
nerdopolis has quit [Remote host closed the connection]