<Lynne>
I can still replicate, it looks like a bitstream desync
<zzoon>
yeah totally I can see it
eukara has joined #dri-devel
<zzoon>
could u explain about the "bitstream desync"
vliaskov has quit [Ping timeout: 480 seconds]
<Lynne>
the decoder misreads a flag/is sent a bad flag, reads one more/one less bit, and from that point on, loses sync
<zzoon>
aha. okay thanks.
<Lynne>
it was a recent change, let me try to bisect
<zzoon>
you mean this issue happens recently?
glennk has joined #dri-devel
<Lynne>
yup, definitely did not happen last month
kasper93 has quit [Remote host closed the connection]
<Lynne>
I think it might be a kernel issue?
<Lynne>
I tried to find a working version, but nothing worked
<zzoon>
Mine is 6.13.2-arch1-1
<Lynne>
hmm, but then vaapi would be broken too
<zzoon>
yeah..
<Lynne>
and the dirty desktop machine I'm using I haven't upgraded the kernel in half a year
feaneron has quit [Ping timeout: 480 seconds]
kasper93 has joined #dri-devel
zzyiwei has quit [Ping timeout: 480 seconds]
sguddati has joined #dri-devel
feaneron has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
sguddati has quit [Ping timeout: 480 seconds]
<ndufresne>
Company: I haven't encontered YCbCr444 in 24bit packed from hardware yet. Though, I'm working on rk3588 HDMI receiver, and it produces 24bit packed RGB, since 444 is not enabled yet, I would not be surprised if it reused the same storage format
<ndufresne>
The main challenge for be is not owning a signal generator to ease testing all the combinations :-)
benjaminl has quit [Ping timeout: 480 seconds]
<Company>
so I'll better not add support for them to GTK yet until somebody actually has tests for them - so I don't use the wrong mapping
<ndufresne>
What kind of mapping you have in mind?
<Company>
Vulkan maps Y, U, V into G, R, B respectively
<Company>
so YUV888 would map to GRB - not RGB or BGR
KAL9000 has quit [Read error: Connection reset by peer]
KAL9000 has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
dsimic is now known as Guest12312
dsimic has joined #dri-devel
Guest12312 has quit [Ping timeout: 480 seconds]
kzd_ has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
sguddati has quit []
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
user0 has joined #dri-devel
HerrSpliet has joined #dri-devel
RSpliet has quit [Remote host closed the connection]
RSpliet has joined #dri-devel
HerrSpliet has quit [Read error: Connection reset by peer]
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #dri-devel
Company has quit [Quit: Leaving]
asrivats__ has quit [Ping timeout: 480 seconds]
user0 has quit [Read error: Connection reset by peer]
dolphin has joined #dri-devel
a-user has joined #dri-devel
a-user has quit []
a-user has joined #dri-devel
mangodev has joined #dri-devel
mangodev has left #dri-devel [#dri-devel]
fab has joined #dri-devel
YuGiOhJCJ2 has quit []
warpme has joined #dri-devel
gnuiyl has joined #dri-devel
warpme has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
<a-user>
I'm loading a minimal custom EDID (via drm.edid_firmware=) containing only these specific modes: 2160p60 (necessarily 4:2:0), 2160p30, 1080p60, 720p60, and 640x480. However, my xrandr/display settings are spammed with a dozen other modes that aren't in this EDID (eg 1920x1200, 720x480, etc). Where exactly are these extra modes being introduced? Is there any way to stop this?
<a-user>
AMD 5700 XT btw
Duke`` has joined #dri-devel
jsa1 has joined #dri-devel
<a-user>
(if this is the wrong place to ask please direct me to a better place)
amarsh04 has quit []
Duke`` has quit [Ping timeout: 480 seconds]
amarsh04 has joined #dri-devel
LeviYun has quit [Remote host closed the connection]
LeviYun has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
fab has quit [Quit: fab]
sima has joined #dri-devel
a-user has quit [Quit: Page closed]
a-user has joined #dri-devel
bolson has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
warpme has joined #dri-devel
warpme has quit []
mvlad has joined #dri-devel
fab has joined #dri-devel
tzimmermann has joined #dri-devel
vliaskov has joined #dri-devel
vliaskov_ has joined #dri-devel
warpme has joined #dri-devel
<MrCooper>
a-user: they're probably added by the Xorg modesetting driver
Hazematman has quit [Quit: WeeChat 4.6.0]
Hazematman has joined #dri-devel
Hazematman has quit []
Hazematman has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
asrivats has quit [Read error: Connection reset by peer]
asrivats has joined #dri-devel
<a-user>
Is there something I can do to make it not do that
<a-user>
Also: is this something that just always happens, or is this being triggered by something in my setup?
lsntvt has joined #dri-devel
jkrzyszt has joined #dri-devel
lynxeye has joined #dri-devel
<MrCooper>
a-user: AFAIR the xf86-video-amdgpu driver doesn't do that
aravind has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
gouchi has quit []
haaninjo has joined #dri-devel
helmhotz has joined #dri-devel
helmhotz has quit [Ping timeout: 480 seconds]
sguddati has joined #dri-devel
jsa1 has joined #dri-devel
sguddati has quit [Ping timeout: 480 seconds]
warpme has quit []
sguddati has joined #dri-devel
warpme has joined #dri-devel
sguddati has quit [Ping timeout: 480 seconds]
sguddati has joined #dri-devel
apinheiro has joined #dri-devel
sguddati has quit [Ping timeout: 480 seconds]
Nasina has quit [Remote host closed the connection]
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
warpme has quit []
JRepin has quit [Remote host closed the connection]
FireBurn has joined #dri-devel
JRepin has joined #dri-devel
<FireBurn>
mareko: The steam issue appears to be a general 32bit issue, I get segfaults running a 32bit glxinfo, I've put the back trace into the issue if it helps. If there's anything you want me to run in gdb, just let me know
pcercuei has joined #dri-devel
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
rasterman has joined #dri-devel
nerdopolis has joined #dri-devel
<FireBurn>
I'm just testing turning a lot of the static things back to not static
guludo has joined #dri-devel
mripard has quit [Quit: WeeChat 4.5.2]
<FireBurn>
Is there supposed to be 2 entry_patch_public ?
<FireBurn>
*multiple
dolphin has quit [Quit: Leaving]
Company has joined #dri-devel
feaneron has joined #dri-devel
<sima>
jfalempe, on your new panic kmap_local series, I'd just do a debug printk_once for the unsupported format case
<sima>
dumping an entire stack frame when we're already in panic is not a great idea imo
<sima>
otherwise lgtm, a-b: me
<sima>
jfalempe, I guess you'll look at kunit testing this all later on in a future series?
<jfalempe>
sima: ok thanks, you mean the DRM_WARN_ONCE() if the pixel width is unsupported ?
<sima>
yup
<jfalempe>
sima: Yes, I have to look at kunits, I didn't use them yet.
<sima>
also you might want to include the changelog in the patch, in drm we generally do that (but outside it's sometimes frowned upon for reasons I don't really understand)
<sima>
jfalempe, yeah makes sense to do that later, just think that we get to a complexity where unit testing all the cases is really good
<sima>
so that we can validate the panic printing code without requiring hw drivers that cover all the special cases
<sima>
since we now have vmap, pages and set_pixel cases, plus quite a pile of failure paths that all must be absolutely rock solid correct
<jfalempe>
sima: this patch series is mostly for virtio-gpu, so it's easier to test.
<sima>
jfalempe, kunit is more for keeping it all correct going forward
<sima>
eventually there's going to be enough panic enabled drivers that you wont be able to test them all, so we need to automate this
<sima>
and make sure we have pretty good coverage even if you don't have any of the special case drivers
<sima>
and kunit fills that need
<jfalempe>
sima: agreed, also I wasn't able to test 16 and 24bits because virtio-gpu doesn't support that, but it's symetrical to the mapped framebuffer which I have tested on Matrox.
<sima>
yeah that's another one, ideally we cover all combos so that people who enable more don't hit nasty surprises
<jfalempe>
sima: amdgpu and nouveau are merged, but I didn't get reviews for i915/xe
<sima>
I guess ping them again here
<sima>
jfalempe, we do have an igt to test-drive the entire thing with igt with the debugfs interface, right?
<jfalempe>
sima: sure, I will rebase it first, my latest patch is 2 months old
<sima>
so if you haven't yet, might be good to double-check that intel-gfx-ci does run your test and it passes
<jfalempe>
there is a debug interface, but it's not connected to igt. Also it's a bit unsafe to use it.
helmhotz has joined #dri-devel
<sima>
jfalempe, well igt is very controlled, nothing else should use the gpu
<sima>
so would be good to have an igt for this, so that we could CI it
<sima>
maybe even on gitlab with the stuff mripard is working on (with vkms or virtio-gpu), or perhaps on msm when that has support
<sima>
max out on the test coverage and all that
<jfalempe>
sima: ok, I will take a look. currently I made it work on all my intel-powered laptops (from Haswell to Lunar Lake).
jfalempe has quit [Quit: jfalempe]
jfalempe has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
Nasina has joined #dri-devel
guludo has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
<sima>
jfalempe, sounds good
KAL9000 has quit [Quit: KAL9000]
warpme has joined #dri-devel
guludo has joined #dri-devel
helmhotz_ has joined #dri-devel
coldfeet has joined #dri-devel
Nasina has joined #dri-devel
helmhotz has quit [Ping timeout: 480 seconds]
Nasina has quit [Ping timeout: 480 seconds]
bolson has joined #dri-devel
pjakobsson has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
warpme has quit []
warpme has joined #dri-devel
<MrCooper>
while I'm in favour of radeonsi dropping clover in favour of rusticl, it's kind of unfortunate that it still requires RUSTICL_ENABLE=radeonsi
warpme has quit []
fab has quit [Quit: fab]
aravind has quit [Ping timeout: 480 seconds]
haagch has joined #dri-devel
fab has joined #dri-devel
Nasina has joined #dri-devel
<karolherbst>
MrCooper: well.. if radeonsi maintainers are fine with it, it could be enabled by default
<karolherbst>
I don't really want to make the decision myself
<zmike>
you can enable it by default for zink
<zmike>
yolooooo
Nasina has quit [Ping timeout: 480 seconds]
a-user has quit [Quit: Page closed]
helmhotz has joined #dri-devel
a-user has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
a-user has quit []
helmhotz_ has quit [Ping timeout: 480 seconds]
a-user has joined #dri-devel
<alyssa>
asahi is the only driver it's default on for
<alyssa>
which is ironic because asahi isn't default on in Mesa at all
<alyssa>
(:
<a-user>
MrCooper: using modesetting (I think; not explicitly setting amdgpu; using nixos, and new to needing to care about this subsystem, so this is somewhat opaque to me) adds like 2x more unasked-for resolution spam
<a-user>
(sorry this is attempting to continue a conversation from 10 hours ago, not sure the etiquiette)
<MrCooper>
that's fine, if you don't like the modesetting driver's behaviour though, maybe try the amdgpu driver?
calico has quit [Remote host closed the connection]
<a-user>
Yes, sorry, I haven't been clear: I believe I've tried both. modesetting (or whatever it is nixos does when I don't explicitly specify amdgpu) adds like 2 dozen spam resolutions. amdgpu adds like 1 dozen spam resolutions. I'd like 0.
fomys_ has joined #dri-devel
calico has joined #dri-devel
<a-user>
This is using an edid override, because not using an edid override causes "no signal" on my tv after grub (works fine out of the box in windows on same machine, and with my old machine which has an old nvidia gpu)
<a-user>
Though I'm not sure if this is due to my edid override, or universal behaviour, because this is all I have on hand right now
jsa1 has quit [Ping timeout: 480 seconds]
<a-user>
Ideally there is an option to just say "stop adding all those resolutions not in my edid", but as far as I've been able to discover, there isn't? There might be on nvidia proprietary drivers.
<a-user>
But I wanted to check with actualy people who might know, rather spend another million LLM tokens chasing hallucinations
Duke`` has joined #dri-devel
<MrCooper>
does the /sys/devices/pci*/*/*/drm/card*/card*-<output name>-*/modes file not contain those modes?
a-user has quit [Remote host closed the connection]
a-user has joined #dri-devel
<a-user>
cat /sys/class/drm/card1-HDMI-A-1/modes does seem to list all the modes
<a-user>
I think I may have just discovered the edid-override is not working
<a-user>
Because edid-decode /sys/class/drm/card1-HDMI-A-1/edid shows the original edid
<a-user>
(ie that the tv sends)
<zamundaaa[m]>
a-user: FYI amdgpu adds non-native modes on the kernel side
<a-user>
But now the mystery is, if I do not include an edid-override kernel param, I get "no signal"
<zamundaaa[m]>
And afaik there is indeed no way to turn that off
<a-user>
perhaps I'm misunderstanding what I'm seeing here: am I actually just reading the i2c or whatever by doing edid-decode /sys/class/drm/card1-HDMI-A-1/edid ?
<a-user>
Because that returns the original tv edid, not the override (but booting withotu the override -> no signal)
calico has quit [Remote host closed the connection]
calico has joined #dri-devel
<a-user>
zamundaaa[m] thank you for the clarification. To be absolutely clear: that is the case even in the best case when everything is nice and happy?
<zamundaaa[m]>
Yes
<a-user>
Thanks. So I am assuming the only option to get rid of resolution spam is to xrandr delmode etc
<zamundaaa[m]>
Or patch your kernel. Or add an option upstream to disable this behavior
<MrCooper>
not sure xrandr delmode works for modes not added via RandR in the first place
<sima>
a-user, could be a kernel bug in not parsing the edid you have correctly
<sima>
unless your hw is busted override really shouldn't be needed
<sima>
also the spam resolution might actually be in your edid, hdmi cea encodes an enormous pile of modes
<sima>
and the kernel has become pretty good at parsing them all
<sima>
a-user, now if those additional modes are indeed incorrect, that would be a kernel bug, since we really should only be adding modes that the edid encodes in one fashion or another
<a-user>
Okay so stepping back, my situation is: new (used) computer w/ 5700 XT + c. 2015 TV that apparently only does 4k60 at 4:2:0 (everything else 4:4:4). TV works fine including at 4k60 with old computer w/ GTX 650, new computer on Windows, new computer using intel iGPU. TV works fine with new computer w/ 5700 XT... until after GRUB, then "No Signal".
<sima>
yeah that sounds like a kernel bug to me
<a-user>
I get an edid from linuxhw edid repo, override using kernel param, TV works fine with new computer using AMD now -- but edid does not list 4k60, and I want 4k60 which I know the TV can do
<sima>
but gtg now, heading out for a play in zürich
<zamundaaa[m]>
> if those additional modes are indeed incorrect, that would be a kernel bug, since we really should only be adding modes that the edid encodes in one fashion or another
<zamundaaa[m]>
That's not how that works with amdgpu, unfortunately
<a-user>
I edit the linuxhw edid to add a 4:2:0 block listing 4k60, now works at 4k60. While I'm in there, I also delete all the resolutions but the ones I actually foresee using. Still works fine, but xrandr/Gnome Setting > Display/various game display options still filled with garbage resolutions
<a-user>
Current side-confusion (last 20 minutes): when booting with my stripped-down edid override, why is `edid-decode /sys/class/drm/card1-HDMI-A-1/edid` still showing the TV's original edid, despite my override? Is that the edid it is actively using, or is it reading from the tv to answer that despite actually using my override
rgallaispou has joined #dri-devel
rgallaispou has quit []
a-user has quit [Remote host closed the connection]
a-user has joined #dri-devel
<a-user>
Okay I have resolved my confusion: I forgot I had booted with the earliest working version of my edited EDID for a sanity check. Rebooting with my fully stripped down edid, I can confirm: 1. /sys/class/drm/card1-HDMI-A-1/edid does indeed show my edid override (and not the tv's original edid). 2. /sys/class/drm/card1-HDMI-A-1/modes shows the same resolutions as xrandr 3. xrandr shows 8 resolutions that are not in my edid override
alanc has quit [Remote host closed the connection]
<a-user>
And this is using amdgpu (or whatever services.xserver.videoDrivers = [ "amdgpu" ] does in nixos, presumably that)
alanc has joined #dri-devel
davispuh has joined #dri-devel
<a-user>
And my understanding of the situation is that if I want to not have (or even just not see) those extra modes, options that will NOT work are: 1. any exist configuration options. 2. using a different display that naturally sends a rock solid edid and is perfectly fine in every way
<a-user>
Options which might work (or might not; just not yet explored): 1. get an nvidia card. 2. imperatively delmode/rmmode the extra resolutions from xrandr
Company has quit [Remote host closed the connection]
<mareko>
karolherbst: feel free to enable rusticl by default for radeonsi
<karolherbst>
I think this should probably be somehow handled in meson, but might be better to wait until the cross compilation problems are figured out?
<karolherbst>
lumag: I think the issue will be that you'll have to do that for a couple of other projects and targets as well
<karolherbst>
like I'm sure that NAK might run into similar issues
<karolherbst>
but maybe it doesn't matter there?
<K900>
lumag: It works in nixpkgs with no extra setup
<lumag>
karolherbst, well, the question if it should be kept OE-specific or whether we should submit it upstream (in some version).
<lumag>
K900, hmm.
<lumag>
K900 cross-compilation?
<K900>
Yes
<karolherbst>
lumag: I'd rather that somebody fixes it on the meson side. There are outstanding cross-compilation problems there
<K900>
Bindgen should respect normal CFLAGS things
<K900>
So it should work
<lumag>
K900, hmm.
Nasina has quit [Ping timeout: 480 seconds]
<lumag>
K900, do you have full clang toolchain or are you using gcc toolchain?
<lumag>
karolherbst, one of the issues is that meson doesn't provide an easy way to get target triplet...
<lumag>
also do you mean just bindgen or some other issues?
<lumag>
(and is there a meson issue for those troubles?)
<karolherbst>
generally. Like there is the outstanding issue on what if targets are used for host and target code
<K900>
lumag: GCC
<karolherbst>
and bindgen kinda has the same issue, that you might need it for both
<karolherbst>
but yeah.. normally the bindgen invocation should just use the target environment
<lumag>
K900: hmm. It totally fails without those flags by being unable to find headers.
<lumag>
hmm, I'll keep it as OE-Specific, claiming generic rust.bindgen() problems to be solved first
<lumag>
karolherbst, btw: I'm getting a weird issues when trying to build RustiCL for 32-bit ARM. Is it one of supported targets?
feaneron has quit [Ping timeout: 480 seconds]
lsntvt has joined #dri-devel
asrivats__ has joined #dri-devel
Calandracas__ has joined #dri-devel
fab has quit [Quit: fab]
Calandracas_ has quit [Ping timeout: 480 seconds]
pzanoni_ has joined #dri-devel
pzanoni_ has quit []
asrivats__ has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
pzanoni has joined #dri-devel
pzanoni has quit [Quit: WeeChat 4.5.2]
asrivats__ has joined #dri-devel
asrivats__ has quit [Remote host closed the connection]
asrivats__ has joined #dri-devel
pzanoni has joined #dri-devel
haaninjo has quit [Quit: Ex-Chat]
jfalempe has quit [Quit: jfalempe]
mvlad has quit [Remote host closed the connection]