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
ecloud_ has quit [Read error: Connection reset by peer]
Company has quit [Quit: Leaving]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
Seirdy has joined #wayland
HaikuUser has joined #wayland
HaikuUser has left #wayland [#wayland]
Moprius has quit [Quit: Konversation terminated!]
zebrag has quit [Quit: Konversation terminated!]
yoslin has quit [Quit: WeeChat 3.4.1]
yoslin has joined #wayland
Azem has joined #wayland
naveenk2 has joined #wayland
naveenk2 has quit [Read error: Connection reset by peer]
astlep has joined #wayland
Azem has quit [Ping timeout: 480 seconds]
sych1ll has joined #wayland
sychill has quit [Ping timeout: 480 seconds]
eroc1990 has quit [Ping timeout: 480 seconds]
dcz_ has joined #wayland
caveman has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
danvet has joined #wayland
c7s has joined #wayland
eroc1990 has joined #wayland
bindu has quit [Ping timeout: 480 seconds]
mvlad has joined #wayland
hardening has joined #wayland
mceier has quit [Quit: Reconnecting]
mceier has joined #wayland
rv1sr has joined #wayland
jgrulich has joined #wayland
caveman has quit [Quit: caveman]
MajorBiscuit has joined #wayland
astlep has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
<pq>
glennk, conceptual sub-texture would be right *if* the source rectangle was already snapped to full texels. But it may not be, and I can't tell what end result would be the best to define even. We do not want to mandate or assume any specific filter.
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
eroux has joined #wayland
<pq>
Maybe the sub-texture needs to include all texels that overlap at all the source rectangle.
<pq>
then we need to define what "overlap" means
zubzub has quit [Remote host closed the connection]
<pq>
is it the texel center position inside the source rect, or the closest texel for any location inside the source rect
<pq>
I suspect if one drew on paper the texel grid and the source rectangle coordinate system, the only right answer would present itself
<pq>
based on how integer-texel source rectangle must befave
<pq>
*behave
<emersion>
an ext to set the filter to nearest neighbour would help maybe?
<emersion>
unfortunately it's per CRTC and not per plane…
<pq>
...it's on CRTC??!?
<pq>
oh, it's the CRTC scaler
<pq>
IOW, when your userspace facing video mode is one thing, and the video signal has another resolution?
<emersion>
i'm confused as well
<emersion>
i'm not sure
<pq>
like when userspace tries to set a non-native resolution on a single-resolution panel, e.g. in laptops
<emersion>
vsyrjala: maybe you know?
<pq>
panels that do not come with a built-in scaler circuit like most external monitors have
<emersion>
it's used by kodi when it picks the preferred mode
<emersion>
so i think it still is about plane scaling
<pq>
that doesn't make sense to me
<pq>
if it pick a *non* preferred mode, then it would make sense to me
<pq>
I remember some discussions about some scasling property, and how it would be used with legacy games setting low resolutions and people wanting that blocky pixelated look
<vsyrjala>
what is the question?
louipcm has quit []
anomalous_creator[m] has quit []
psydroid[m]1 has quit []
Eighth_Doctor has quit []
go4godvin has quit [Quit: Bridge terminating on SIGTERM]
MatrixTravelerbot[m] has quit []
jmariondev[m] has quit []
unrelentingtech has quit []
idkrn[m] has quit []
Nico has quit [Quit: Bridge terminating on SIGTERM]
gnustomp[m] has quit []
YaLTeR[m] has quit []
hasebastian[m] has quit []
MA[m] has quit []
aplund[m] has quit []
emilio[m] has quit []
FbioPacheco[m] has quit []
ozwald1[m]1 has quit []
MarcusBritanicus[m] has quit []
feaneron has quit []
varlad[m] has quit []
zaibon[m] has quit []
enick_31 has quit []
nielsdg has quit []
Kelseyjgilbert[m] has quit []
danburd[m] has quit []
RomanGilg[m] has quit []
heftig has quit [Quit: Bridge terminating on SIGTERM]
DemiMarieObenour[m] has quit [Quit: Bridge terminating on SIGTERM]
ashketchum[m] has quit []
DrNick has quit []
ujineli[m] has quit []
arichardson[m] has quit []
toggleton[m] has quit []
Sumera has quit [Quit: Bridge terminating on SIGTERM]
doras has quit [Quit: Bridge terminating on SIGTERM]
robertmader[m] has quit []
bdaase[m] has quit []
digitalfavshetheyname[m] has quit []
shadowninja55[m] has quit []
GrahamPerrin[m] has quit []
ttancos[m] has quit []
AndrewAylett[m] has quit []
japchae[m] has quit []
pac85[m] has quit []
niecoinny[m] has quit []
botiapa[m] has quit []
cousinofthor[m] has quit []
vchernin[m] has quit []
pitsch[m] has quit []
rubo_[m] has quit []
d_ed[m] has quit []
junglerobba[m] has quit []
apol[m] has quit [Quit: Bridge terminating on SIGTERM]
deknos82[m] has quit []
zamundaaa[m] has quit [Quit: Bridge terminating on SIGTERM]
feta has quit []
i509VCB has quit [Quit: Bridge terminating on SIGTERM]
jryans has quit []
flyingketh[m] has quit []
nazarewk[m] has quit []
cb5r[m] has quit []
halfline[m] has quit []
JosExpsito[m] has quit []
Mershl[m] has quit []
teh1[m] has quit []
rails[m] has quit []
inkbottle[m] has quit []
smasher_tati[m] has quit []
ongy[m] has quit []
ammen99[m] has quit []
Levans has quit [Quit: Bridge terminating on SIGTERM]
Poly[m] has quit []
[old]freshgumbubbles[m] has quit []
Shimmy[m] has quit []
bluepenquin has quit [Quit: Bridge terminating on SIGTERM]
cmeissl[m] has quit []
davidre has quit [Quit: Bridge terminating on SIGTERM]
edrex[m] has quit []
<emersion>
vsyrjala: is SCALING_FILTER about plane FBs, or about something else?
<emersion>
e.g. about the final composited CRTC image being scaled again
<vsyrjala>
if it's on a plane then it's about plane scaling. if it's on the crtc then it's about crtc scaling
<emersion>
what is CRTC scaling?
<vsyrjala>
scaling of the entire composited image
<emersion>
(it's only on the CRTC, not on the plane)
<vsyrjala>
plane has it too
<emersion>
hmmm
<pq>
vsyrjala, what's the use for scaling the entire composited image again? Where do the source and destination resolutions come from?
<emersion>
ah indeed plane has it too but either no hw supports it either drmdb is buggy
<vsyrjala>
source resolution is the user mode hdisp/vdisp. dest is a bit complicated
<pq>
heh
<vsyrjala>
for laptop panels it comes from the panel's native resolution + scaling_mode prop
<vsyrjala>
for external displays it can be based on the user mode hdisp/vdisp + border properties
<pq>
oh, over/underscan related?
jmabr has joined #wayland
<vsyrjala>
yeah. originally the border props were only used for legacy tv connectors, but at some point it was extended to be usable for other connector types as well
DemiMarieObenour[m] has joined #wayland
<emersion>
is this documented?
<vsyrjala>
not sure which drivers implement it though
<vsyrjala>
haven't looked at the docs
<emersion>
ah, and I assume no way to check support?
<vsyrjala>
that is for the laptop panel case. the border stuff is something different. looks like it was "left margin" etc.
<emersion>
oh border props
<emersion>
right, i see
<vsyrjala>
dunno if anyone was crazy enough to expose both on the same connector. but i'm sure if they did they did not think fully how the props should actually interact
<pq>
userspace does not really have the luxury of assuming KMS properties not appearing in arbitrary combinations, which is why all interactions need to specified always - or literally document that it is forbidden to expose certain combinations.
ecloud__ has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
ecloud_ has joined #wayland
lxsameer has joined #wayland
slimbo is now known as slim
<emersion>
alright, drmdb bug fixed, both SCALING_FILTER props appear now
<emersion>
also added a page to show devices supporting a prop
slim has left #wayland [#wayland]
slim has joined #wayland
maxzor has joined #wayland
slim has quit [Quit: slim]
slim has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
ammen99[m] has joined #wayland
AndrewAylett[m] has joined #wayland
anomalous_creator[m] has joined #wayland
aplund[m] has joined #wayland
apol[m] has joined #wayland
arichardson[m] has joined #wayland
bdaase[m] has joined #wayland
Guest26 has joined #wayland
botiapa[m] has joined #wayland
cb5r[m] has joined #wayland
cmeissl[m] has joined #wayland
Eighth_Doctor has joined #wayland
cousinofthor[m] has joined #wayland
d_ed[m] has joined #wayland
danburd[m] has joined #wayland
davidre has joined #wayland
Nico has joined #wayland
deknos82[m] has joined #wayland
digitalfavshetheyname[m] has joined #wayland
Guest21 has joined #wayland
doras has joined #wayland
edrex[m] has joined #wayland
emilio[m] has joined #wayland
FbioPacheco[m] has joined #wayland
GeorgesStavracasfeaneron[m] has joined #wayland
flyingketh[m] has joined #wayland
[old]freshgumbubbles[m] has joined #wayland
gnustomp[m] has joined #wayland
Guest29 has joined #wayland
GrahamPerrin[m] has joined #wayland
halfline[m] has joined #wayland
hasebastian[m] has joined #wayland
heftig has joined #wayland
Guest40 has joined #wayland
i509VCB has joined #wayland
idkrn[m] has joined #wayland
feta has joined #wayland
inkbottle[m] has joined #wayland
japchae[m] has joined #wayland
Kelseyjgilbert[m] has joined #wayland
jmariondev[m] has joined #wayland
junglerobba[m] has joined #wayland
JosExpsito[m] has joined #wayland
jryans has joined #wayland
Levans has joined #wayland
louipcm has joined #wayland
MarcusBritanicus[m] has joined #wayland
Mershl[m] has joined #wayland
MA[m] has joined #wayland
nazarewk[m] has joined #wayland
niecoinny[m] has joined #wayland
nielsdg has joined #wayland
ashketchum[m] has joined #wayland
ongy[m] has joined #wayland
teh1[m] has joined #wayland
ozwald1[m]1 has joined #wayland
pac85[m] has joined #wayland
pitsch[m] has joined #wayland
Poly[m] has joined #wayland
psydroid[m] has joined #wayland
rails[m] has joined #wayland
robertmader[m] has joined #wayland
RomanGilg[m] has joined #wayland
rubo_[m] has joined #wayland
shadowninja55[m] has joined #wayland
smasher_tati[m] has joined #wayland
Sumera[m] has joined #wayland
Shimmy[m] has joined #wayland
toggleton[m] has joined #wayland
ttancos[m] has joined #wayland
ujineli[m] has joined #wayland
unrelentingtech has joined #wayland
varlad[m] has joined #wayland
vchernin[m] has joined #wayland
MatrixTravelerbot[m] has joined #wayland
YaLTeR[m] has joined #wayland
zaibon[m] has joined #wayland
zamundaaa[m] has joined #wayland
flacks has quit [Quit: Quitter]
flacks has joined #wayland
mooff[m] has joined #wayland
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<LaserEyess>
question about compositing/copies, so in mpv, there is the video, but also a subtitle overlay that's used for UI elements (and subtitles, obviously)
<LaserEyess>
this is done with libass and only supports RGB, but through https://github.com/mpv-player/mpv/pull/10115 work is being done to pass 'raw' vaapi buffers without conversion via dmabuf to avoid copies
<LaserEyess>
so formats could be nv12, for example
zebrag has joined #wayland
<LaserEyess>
would it be possible to have the subtitle overlay work as RGB as well as having the video be nv12, and still avoid a compositing copy?
<LaserEyess>
I would assume no, but I see this line in gamescope's README: "It can use DRM/KMS to directly flip game frames to the screen, even when stretching or when notifications are up, removing another copy."
<LaserEyess>
so it sounds like maybe it's possible?
<LaserEyess>
I might be out of my depth here I only have a rough understanding about how drm/wayland works
<emersion>
LaserEyess: yes it's possible
<emersion>
if you use a subsurface for the subtitles
<emersion>
whether this avoids composition in the compositor depends on the compositor and on the hw
<LaserEyess>
interesting
<LaserEyess>
compositor support aside, since I assume that's just an implementation problem, what sort of hardware support is required?
<LaserEyess>
most of mpv's usecase is on regular desktop, but I'm curious if there's anything needed on mpv's side for support of, uh, "exotic" hardware
<emersion>
if you want zero copies, with one fullscreen surface + one subtitle overlay, most desktop GPUs should support that
<emersion>
one fullscreen NV12 surface + one RGBA subtitle overlay
<LaserEyess>
neat
<emersion>
you can check on drmdb the planes
<emersion>
i know for sure it works on recent amd
<LaserEyess>
on wlroots stuff? I can't seem to get zero copy to work on my RDNA card
<emersion>
we use it in gamescope for steam play streaming + notification overlay
<LaserEyess>
that's onyl based on presentation feedback, though
<LaserEyess>
oh right, gamescope
<emersion>
though it uses hacks because X11 doesn't support passing NV12 buffers
<emersion>
so not really something one can use to test their client
<emersion>
really need to add proper wayland shell support at some point
<LaserEyess>
hm, now I'm wondering about the 1x1 viewporter hack that PR is using for black bars
<emersion>
hm, wlroots' DRM backend cannot do multi-plane scanout
<emersion>
(gamescope has its own backend based on libliftoff)
<emersion>
you might have better luck with weston
<LaserEyess>
yeah it's being tested on both sway and weston
<LaserEyess>
sway has been exceptional at finding bugs with resizing
<LaserEyess>
so I assume the wl_shm thing can be its own subsurface on its own plane
<any1>
Heh, ever thought about creating buffers that are serialised scene graphs for the compositor to render? :)
<emersion>
if you re-create the whole surface tree state each frame, that'll essentially be that
MajorBiscuit has quit [Quit: WeeChat 3.4]
<any1>
I'm just thinking, if toolkits like Qt were to use something like that to render widgets, it could be serialised much faster and more efficiently for remote desktop applications. It's not an original thought, of course...
<any1>
Might even make wayland network transparent after all... :p
<any1>
I jest
<pq>
LaserEyess, make sure your subtitles RGB uses dmabuf, so that it can go on an overlay.
<LaserEyess>
I don't know if they can, they're CPU rendered
dcz_ has joined #wayland
<pq>
LaserEyess, yeah, would need to use GL/Vulkan for those. If you don't, it reduces the likelyhood of getting direct scanout on the *video* greatly.
<pq>
depending on the compositor
<LaserEyess>
hmm, I shoudl test it on intel/wlroots, since I know direct scanout works there
<pq>
for any kind of video, RGB too, not just NV12
<LaserEyess>
video itself is from vaapi, or with --vo=gpu opengl/vulkan
<LaserEyess>
and yes direct scanout works there, at least on intel for me
<LaserEyess>
I don't actually remember if it works with subtitles as well
<emersion>
but the subtitle overlay isn't using a separate subsurface right?
<emersion>
it's just a single flat fullscreen GL surface?
floof58 is now known as Guest82
floof58 has joined #wayland
<LaserEyess>
emersion: yes, overlay is done via shaders iirc
Guest82 has quit []
<pq>
LaserEyess, so it's not CPU rendered ;-)
<LaserEyess>
well we're talking about two different things here
<LaserEyess>
--vo=vaapi_wayland -> subtitle overlay as a subsurface on top of the video
<LaserEyess>
--vo=gpu/gpu-next -> subtitles uploaded to the GPU and merged to a single surface before being sent to the compositor
<pq>
just use the exact same code path with shaders, simply with a 100% transparent fake-video, to create the sub-title overlay
<LaserEyess>
that woudl require CSC on the vaapi video though
<pq>
hmm?
<LaserEyess>
ohh, wait, sorry I misunderstood
<LaserEyess>
ok, so it doesn't actually matter where it comes from as long as it's on the GPU
<LaserEyess>
basically: don't send it as a wlshm thing
<pq>
I mean a real overlay, a separate wl_surface as a sub-surface
<LaserEyess>
yes
<pq>
yes!
<LaserEyess>
my question was more of "if it is a subsurface, but a CPU rendered one, will that still work without a copy?"
<LaserEyess>
and you asnwered that
<pq>
yup, wl_shm by definition cannot work without a copy (or two) in the compositor.
<pq>
and in the process, a wl_shm using surface is likely cause all other surface below it to not get direct scanout
<LaserEyess>
another reason for solid-buffer to be a thing
<pq>
that can be remedied somewhat with a smart compositor
<pq>
weeell... solid-buffer does not solve that problem
<emersion>
yeah, but really feels like a hack
<LaserEyess>
pq: sure I guess that still requires a smart compositor
<emersion>
solid-buffer + black, or solid-buffer + that old plane background color KMS proip
<pq>
a compositor could equally well special-case 1x1 wl_shm buffers as it could implement solid-buffer extension
<LaserEyess>
right now it doesn't particularly matter since on pretty much every compositor a windowed surface won't really do direct scanout
<pq>
all the benefits of solid-buffer protocol are purely client-side in making things less complicated.
<LaserEyess>
and in fullscreen the wl_shm 1x1 hack isn't really needed (I think?)
<LaserEyess>
though I think it's always on, for now
<daniels>
emersion: *CRTC background colour
<emersion>
ah, yes
kchibisov_ has joined #wayland
kchibisov has quit [Read error: Connection reset by peer]
astlep has joined #wayland
cool110 has joined #wayland
Guest29 is now known as go4godvin
cool110 has quit [Remote host closed the connection]