ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
shoragan has quit []
shoragan has joined #wayland
amadaluzia has quit [Ping timeout: 480 seconds]
yshui_ has joined #wayland
yshui has quit [Ping timeout: 480 seconds]
karenw has joined #wayland
Drakulix has quit [Ping timeout: 480 seconds]
Drakulix has joined #wayland
karenw has quit [Quit: Deep into that darkness peering...]
Brainium has quit []
karenw has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
kts has joined #wayland
karenw has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
fatal has quit [Remote host closed the connection]
fatal has joined #wayland
glennk has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
eluks has quit [Remote host closed the connection]
mahkoh has quit [Read error: Connection reset by peer]
mahkoh has joined #wayland
tent4051 has joined #wayland
tent405 has quit [Read error: Connection reset by peer]
rasterman has quit [Quit: Gettin' stinky!]
bindu_ has joined #wayland
bindu has quit [Ping timeout: 480 seconds]
bindu has joined #wayland
bindu_ has quit [Ping timeout: 480 seconds]
amadaluzia has joined #wayland
amadaluzia_ has quit [Ping timeout: 480 seconds]
amadaluzia has quit [Ping timeout: 480 seconds]
tent4051 has quit [Remote host closed the connection]
tent405 has joined #wayland
fmuellner has joined #wayland
karenw has joined #wayland
nerdopolis has joined #wayland
Moprius has joined #wayland
juergbi` has quit []
juergbi has joined #wayland
karenw has quit [Quit: Deep into that darkness peering...]
kts has joined #wayland
Venemo has joined #wayland
feaneron has joined #wayland
<Venemo>
hey guys, is this the right channel for weston related questions?
<pq>
Venemo, yes
<Venemo>
I'd like to find a way to trigger a code path in weston that uses drm scaling, ie. the scaling functionality that is included in the display hardware.
<Venemo>
I'm working on DC display driver support for old GPUs and I strongly suspect that there is a bug in there somewhere but I don't even know how to exercise that code path
<pq>
it just occurred to me, I'm checking if any of the "simple" Weston demos would do that.
feaneron has quit [Read error: Connection reset by peer]
feaneron has joined #wayland
<Venemo>
I already tried running mpv on weston but it doesn't use this, or at least I couldn't figure out how to make it use this
<linkmauve>
weston-simple-dmabuf-v4l definitely does, but mpv (we already started debugging that in #mpv-devel) does it too with --vo=dmabuf-wayland.
<Venemo>
mpv doesn't do it with that
<pq>
weston-simple-dmabuf-v4l has the code to do it, but I wonder what video source would be direct-scanout compatible on amdgpu.
<Venemo>
weston-simple-dmabuf-v4l says: requested DRM format YUYV not available
<pq>
Venemo, try with --help, there are quite a fwe things to tweak.
<Venemo>
I have no idea what I'm looking at
<pq>
first you need to have a V4L2 device as the source, that's the purpose/weakness of weston-simple-dmabuf-v4l
<Venemo>
I don't know what V4L2 is or how it's connected to the topic at hand
<Venemo>
I'm really sorry
<daniels_>
easier option - printf "[output]\nname=HDMI-A-1\nscale=2\n" > ~/.config/weston.ini - start weston and run weston-simple-egl - weston-simple-egl should go on to a plane with 2x scale
<pq>
V4L2 is the Linux video device sub-system. Like webcams etc.
<Venemo>
I don't have a webcam
<daniels_>
pq: AMD doesn't do V4L2, because their codec isn't particularly fixed-function, it's more like a part of the GPU, hence they use VA-API / Vulkan Video via Mesa
<daniels_>
Venemo: just do that and ping me if it's not working for you for some reason (and that reason isn't that you didn't replace HDMI-A-1 with the real name of your output, e.g. DP-7 or whatever)
<Venemo>
daniels_: sorry, do what exactly?
<pq>
Venemo, right, then weston-simple-dmabuf-v4l is not a good tool for you. It is designed to test V4L2 playback.
<daniels_>
Venemo: a few lines up, starting with 'easier option'
<pq>
daniels_, oooh, simple-egl does not do scaling! That's a cool trick.
<Venemo>
thanks
<daniels_>
np
<daniels_>
pq: yeah, a happy unintended feature :)
<linkmauve>
Oh right, scaling everything will do.
<pq>
'weston-simple-egl -o' I suppose? Just in case.
<linkmauve>
pq, daniels_, with the vivid kernel module, you can create a V4L2 device with exactly the right properties you want to test.
<daniels_>
linkmauve: does vivid do dmabuf?
Tokoyami has quit [Quit: ~@~]
<linkmauve>
Yes.
<Venemo>
daniels_: I'm running now weston with that option, everything is scaled by 2, and it still looks like the code path I'd like to trigger isn't used
<daniels_>
linkmauve: huh
<pq>
linkmauve, does that actually make dmabuf that DC is happy to scan out from?
<daniels_>
Venemo: and you're running weston-simple-egl?
<Venemo>
yes
<linkmauve>
Back when I wrote simple-dmabuf-v4l, on the Intel display controller I had (IIRC that was an Ivy Bridge) it did.
<Venemo>
I'm running it from the terminal app inside weston
<pq>
linkmauve, intel is uniform memory, DC/radeon/AMD is not.
<Venemo>
I'm dumping the HW registers that would be used when programming scaling, and they are not set, so that makes me assume that scaling isn't used.
<linkmauve>
pq, I have no working AMD card to test stuff on atm.
<pq>
Venemo, maybe try weston-simple-egl -o
Tokoyami has joined #wayland
<pq>
linkmauve, I have, but I'm very skeptical it'd work, and not so interested to actually ry.
<pq>
*try
<Venemo>
I think I'll add a few debug prints to my kernel and maybe that will help me see what is happening
<pq>
Venemo, is the DC you are testing with supporting the atomic KMS API?
<Venemo>
pq: yes
<pq>
good
bindu has quit [Remote host closed the connection]
<Venemo>
long story short, there is some missing pieces to make DC the default display driver for old GPUs, and I'm adding those pieces
bindu has joined #wayland
<pq>
cool!
<Venemo>
my goal is to make amdgpu the default driver for these GPUs instead of radeon (the older kernel driver)
<linkmauve>
My only accessible AMD card is in a Wii U, and since there is no PCIe bus the card is exposed through MMIO, so radeon.ko doesn’t support it at all. :(
<Venemo>
I don't know anything about that, sorry
<pq>
daniels_, it looks like simple-egl can use wp_viewport but only(?) for fractional scale.
<daniels_>
pq: heh yeah, I'd just discovered the same
<daniels_>
Venemo: how old are we talking?
<daniels_>
not pre-gfx9 is it?
<Venemo>
daniels_: I'm talking about gfx6 and gfx7. both of them are supported by amdgpu but the support is not enabled by default due to a small handful of missing features compared to the older radeon driver.
<Venemo>
daniels_: more specifically, at the moment I care about dgpus of those generations. I've not made up my mind yet if I care enough about apus, probably not
<daniels_>
oh christ
<Venemo>
?
<daniels_>
sorry, I had no idea you were going back that far. since those cards don't do modifiers, we don't try to do direct scanout for them ever, since without modifiers who knows if it will ever work
<daniels_>
(and a lot of the time it doesn't, because if you happen to have enabled DCC, it just quietly displays garbage)
<Venemo>
hm, good point
<Venemo>
modifiers are on my todo list, but haven't got to them yet
<Venemo>
is there any way to try to force direct scanout anyway?
<daniels_>
you can try hacking out the check for mod == INVALID at the top of drm_fb_get_from_dmabuf_attributes() and see if that gets you any further (start weston with --debug then run 'weston-debug drm-backend' and it'll pour its heart to you about what's going on)
<daniels_>
we don't have a runtime switch for it because then people would use it
<Venemo>
hahaha
<Venemo>
well, maybe I could give this another try after I tackled modifiers
<daniels_>
woohoo
<Venemo>
it's really annoying because there is a user who seems to have some issues with scaling and I have no idea how to reproduce that
<Venemo>
it looks like either grub or the bios programmed a mode into his gpu that uses scaling, and DC doesn't properly clean that up
<Venemo>
I was hoping to repro it using something that uses scaling normally
<zamundaaa[m]>
[@_oftc_Venemo:matrix.org](https://matrix.to/#/@_oftc_Venemo:matrix.org): KWin allows direct scanout with implicit modifiers. Set scaling to some non-100% value in Plasma, set X11 scaling to "scaled by the system" and fullscreen any X11 app
<zamundaaa[m]>
FWIW we haven't received any bug reports about things going wrong with direct scanout and implicit modifiers; I only know of a few reports with explicit modifiers where things still went wrong because driver bugs :)
<Venemo>
zamundaaa[m]: thanks, that is worth a try, is that only on x11 or wayland too?
<zamundaaa[m]>
Only on Wayland
<Venemo>
oh okay
<pq>
zamundaaa[m], doesn't that just mean that all split KMS/render device systems have fully modifier-ful drivers? :-)
<zamundaaa[m]>
I mention the X11 app because it's an easy way to make sure scaling is involved
<MrCooper>
Venemo: seems unlikely that the driver would "forget" to disable scaling after enabling it explicitly as well
<Venemo>
zamundaaa[m]: DC isn't the default display driver, and amdgpu isn't the default kernel driver for these gpus, and on an upstream kernel some gpus don't even boot on this combination. so it's very unlikely that you'd receive any bug reports on this combination
<Venemo>
MrCooper: that's exactly what seems to be happening though
<MrCooper>
the drm_info output showed no KMS scaling being used
<zamundaaa[m]>
I was referring to [@_oftc_daniels_:matrix.org](https://matrix.to/#/@_oftc_daniels_:matrix.org) comment about Weston disallowing it in general
<pq>
MrCooper, the bootloader is not the driver, though.
<zamundaaa[m]>
pq: heh, all that Plasma is used on, perhaps
<Venemo>
MrCooper: no but some registers related to scaling were set, as I already explained to you yesterday.
<daniels_>
zamundaaa[m]: well, that and us disallowing it did help to force more people to implement it, so some of the cases which could never have worked started working, because they actually went to dtrt
<Venemo>
the issue is likely in dce60_setup_scaling_configuration or somewhere along those lines
<daniels_>
so we could re-enable it I suppose, but it would only benefit one person here who already has a broken driver anyway :P
<MrCooper>
pq: kind of my point, the driver may "forget" to disable scaling programmed by firmware, less likely so if programmed by itself though
Moprius has quit [Ping timeout: 480 seconds]
<pq>
MrCooper, ah, so your point is that doing scaling with Linux userspace would probably not trigger the problem.
<MrCooper>
right
<pq>
but maybe scaling from Linux userspace would not work at all, and that would be the issue?
<MrCooper>
maybe
<Venemo>
who knows, I don't think anyone ever tested it on this hw to be honest
<MrCooper>
FWIW, mutter can also use KMS scaling for direct scanout
<Venemo>
MrCooper: even without modifiers?
<daniels_>
MrCooper: just fullscreen or overlay now too?
<MrCooper>
just fullscreen, not 100% sure about modifiers but I want to say even without
<Venemo>
MrCooper: okay, so how do I trigger this stuff with mutter then?
<MrCooper>
e.g. by selecting a smaller-than-native fullscreen resolution in an X app
<Venemo>
how do I do that?
<Venemo>
like, specifically what app?
<MrCooper>
any which allows choosing the fullscreen resolution
<Venemo>
I don't know of any, hence the question
<pq>
games tend to have a resolution switch
<Venemo>
hm
<Venemo>
worth a shot
<Venemo>
zamundaaa[m]: looks like logging into KDE Plasma with DC enabled on this GPU just takes me to a black screen then "no signal"
<Venemo>
MrCooper: looks like mutter isn't doing direct scanout on this system
<Venemo>
zamundaaa[m]: that is probably my mistake though. I should reject some more modes in the driver
<jadahl>
Venemo: with an env vars you can have mutter print out why, if you want to know why it decided not to
<Venemo>
jadahl: I'd be happy to take a look at that if you can tell me how
randomfrost has joined #wayland
randomfrost has quit [Remote host closed the connection]
<MrCooper>
Venemo: in a gnome-shell session, 1. Press Alt-F2 2. Enter 'lg' at the prompt 3. Select the Flags tab and then enable 'RENDER' under MetaDebugTopic 4. attempt to achieve direct scanout 5. Disable the debug output again
<MrCooper>
then the journal should have debugging output about why direct scanout isn't possible
<zamundaaa[m]>
Venemo: might be because KWin uses 10bpc by default? You can set KWIN_DRM_PREFER_COLOR_DEPTH=24 to force it to reduce max bpc to 8
<MrCooper>
FWIW, mutter also uses 10 bpc formats by default
<MrCooper>
(and doesn't touch the "max bpc" property)
<zamundaaa[m]>
I recall max bpc being 8 by default on amdgpu, but I'm not sure
<MrCooper>
depends on the connector
<MrCooper>
AFAIK it's 8 only for DP MST connectors, otherwise 16
<Venemo>
zamundaaa[m]: no, the issue isn't the bpc. it tries to use a high refresh rate mode which I forgot to reject in the driver.
<zamundaaa[m]>
ah
<Venemo>
it works now that I fixed that
<jadahl>
Venemo: MUTTER_DEBUG=render
<jadahl>
or what MrCooper said
<Venemo>
zamundaaa[m]: thanks, I reproduced the issue with kde like you suggested!
<Venemo>
this is very helpful, thank you
<Venemo>
jadahl, MrCooper will do after I figure this one out
<MrCooper>
well, I'm currently having trouble getting any app to actually use direct scanout with scaling, so no rush :)
<Venemo>
basically there are two issues here: (1) scaling is buggy, (2) DC never turns of scaling, so once it's bugged, you can never get out of it
<Venemo>
there is also a kernel crash
<Venemo>
all kinds of fun
kts has quit [Quit: Konversation terminated!]
amadaluzia has joined #wayland
<wlb>
weston Merge request !1841 opened by Pekka Paalanen (pq) Draft: Parse parametric output color profiles from weston.ini https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1841 [color-lcms plugin], [Colour management], [Configuration / ini file], [Weston frontend]
<wlb>
weston Merge request !1594 closed (Allow users to craft parametric color profiles from .ini)
AJ_Z0 has quit [Read error: Connection reset by peer]
AJC_Z0 is now known as AJ_Z0
anetteaufseier has joined #wayland
anetteaufseier has quit [Remote host closed the connection]
MrCooper_ has joined #wayland
MrCooper__ has quit [Ping timeout: 480 seconds]
olivial has quit [Read error: Connection reset by peer]
olivial has joined #wayland
leon-anavi has quit [Quit: Leaving]
AJ_Z0 has quit [Remote host closed the connection]
AJ_Z0 has joined #wayland
kts has quit [Quit: Konversation terminated!]
<Venemo>
daniels_: maybe a silly question, but I can't figure it out. how is the compositor supposed to know what scaling range is supported by the driver?
<Venemo>
is it in the plane properties somewhere?
<emersion>
it doesn't, it tries and the driver may reject the atomic commit
<llyyr>
not the right place here, but can I enable HDR/color management with kwin_wayland if im not using the rest of the plasma stuff?
<Venemo>
emersion: there is no way for it to know? isn't there a drm property or something?
<Venemo>
heh okay
<emersion>
Venemo: hm what do you mean by "scaling range" exactly?
<Venemo>
emersion: well, whether it supports scaling in the first place, in within what range, eg. what is the minimum or maximum scale factor
<emersion>
these things aren't exposed
<emersion>
exposing such constraints in a declarative way turns out to be very funky in practice because drivers have such weird requirements
<emersion>
easy enough for userspace to try and fallback to shaders if KMS rejects it
<Venemo>
isn't there a bit of an overhead to that, though?
<daniels_>
yes, absolutely; the social contract is that the check should complete ‘very quickly’
<daniels_>
the hardware-specific constraints are weird enough that there’s no point in expressing them via uAPI; if you’re not just brute-forcing it then you need to have platform-aware userspace that can just dtrt
<emersion>
indeed
amadaluzia has joined #wayland
<Venemo>
hm, okay
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
<Venemo>
zamundaaa[m]: I found a bug while testing this stuff in KDE. basically it seems the cursor plane and the primary plane become out of sync when scaling, which makes it pretty difficult to click on anything. do you think this could be a KDE bug, or a driver bug? issue is present on newer hw generations too
amadaluzia has quit []
amadaluzia has joined #wayland
amadaluzia has quit []
amadaluzia has joined #wayland
amadaluzia has quit []
amadaluzia has joined #wayland
amadaluzia has quit []
amadaluzia has joined #wayland
mahkoh has quit [Remote host closed the connection]
mahkoh has joined #wayland
<zamundaaa[m]>
Each plane is treated basically entirely independently by KWin, I'd expect that to be a driver bug
<zamundaaa[m]>
I haven't noticed such an issue yet on my RDNA3 GPUs FWIW
Drakulix has quit [Ping timeout: 480 seconds]
karenw has joined #wayland
Drakulix has joined #wayland
amadaluzia has quit []
sima has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
fmuellner has quit []
fmuellner_ has joined #wayland
Psi-Jack has quit [Ping timeout: 480 seconds]
blueberrysnake8 has joined #wayland
Psi-Jack has joined #wayland
blueberrysnake has quit [Ping timeout: 480 seconds]