14:40banshi: hello all
14:40banshi: what about gtx 1030 ?
14:40banshi: does nouveau support it ^ ?
14:40banshi: GT 1030*
14:40imirkin: using one right now
14:41imirkin: although 'support' is a fairly ambiguous term
14:50banshi: imirkin: does 3D work?
14:51karolherbst: yes, it does
14:51karolherbst: but it's not fast
14:52banshi: not fast - how to understand? Not faster than with proprietary drivers or really slow?
14:52karolherbst: really slow
14:52karolherbst: because we can't change the clocks on the GPU
14:52karolherbst: but.. with a 1030 you aren't after speed in the first place anyway
14:52karolherbst: so.. probably doesn't matter
14:52banshi: which is the best low TDP video card with nouveau support then?
14:53banshi: I will be back later
19:23linkmauve: So, I finally have my GP104 plugged in!
19:24imirkin: weren't you gonna sell it?
19:24linkmauve: But I don’t see any node in /dev/dri, so I can’t send a drm_info. :/
19:24imirkin: linkmauve: need firmware with v5.6+
19:24linkmauve: Probably, but I first wanted to play a bit with it.
19:24linkmauve: Like, to see what Nouveau is doing with it. :)
19:24imirkin: otherwise pastebin dmesg
19:24linkmauve: Oh, 5.6.14.
19:24imirkin: it's in linux-firmware
19:24imirkin: so not very hard to get. but needs to be there at module load time.
19:25linkmauve: Dang, Total Installed Size: 541.56 MiB
19:25imirkin: you can just get the stuff you need
19:25linkmauve: Yeah, but it doesn’t matter much, I also got a super big SSD to go with it. ^^
19:25linkmauve: 921.2 GiB!
19:26karolherbst: bloating the initramfs is a bigger problem actually :p
19:26imirkin: for those crazy enough to stick modules into initrd...
19:26karolherbst: but usually those scripts are smart enough to only do it for important devices
19:26karolherbst: well.. you can also embed the firmware into your kernel
19:26karolherbst: same thing really
19:26imirkin: it's basically the worst place for the code
19:26karolherbst: modules? yeah...
19:27karolherbst: but I actually never had an issue wth initrd
19:28imirkin: neither have i. coz i don't stick modules into it ;)
19:28karolherbst: on my gentoo system I only have a couple of modules.. and all because of stupid reasons
19:29imirkin: given that i don't have some fancy raid controller, modules just live on the FS
19:29linkmauve: Perfect, I rmmod’d and modprobe’d nouveau and now I get the device. :)
19:29linkmauve: devices*
19:29karolherbst: imirkin: well.. with full disc encryption you kind of need most of the stuff loaded already before hitting the main fs
19:29karolherbst: and some net or gpu drivers are just silly :p
19:30imirkin: karolherbst: i use initrd with full disk encryption
19:30imirkin: and yes, don't forget to build your root fs into the kernel
19:30imirkin: or support for your disk controller
19:30imirkin: otherwise you're gonna have a bad time
19:30karolherbst: I was more refering to being able to use nvidia and dracut.. there isn't really another way
19:31karolherbst: if you want to have kms in initrd
19:31imirkin: is that such a necessity?
19:31karolherbst: yes
19:31imirkin: hehe ok
19:31karolherbst: external displays
19:31imirkin: hasn't come up as a problem for me
19:31karolherbst: my laptop is usually always closed
19:31karolherbst: so it's either that or nothing on the external screen
19:31imirkin: nothing sounds good
19:32karolherbst: well.. I guess I could type in the password bindly :p
19:32karolherbst: *blindly
19:32karolherbst: but then I don't see potential boot issues
19:32imirkin: isn't the keyboard underneath said lid?
19:32karolherbst: USB keyboard
19:32imirkin: heh ok
19:32linkmauve: /dev/dri/card1: data uploaded to https://drmdb.emersion.fr/devices/c49b7fc88f16
19:32karolherbst: but kms support in nvidia is quite reliable
19:32karolherbst: just the modesetting ddx doesn't work as nicely
19:33imirkin: linkmauve: fyi, capabilities don't really vary within a generation. so all pascal cards will have the same stuff.
19:33karolherbst: also.. with pascal gpus you won't have much luck perf wise anyway
19:33linkmauve: Makes sense.
19:33linkmauve: karolherbst, I still want to compare to the UHD630.
19:33karolherbst: it's worse
19:33imirkin: linkmauve: only exception to that is GF119 which has a diff display controller than the rest of the GF10x series
19:34imirkin: (and i think the original G80 is different than G84+)
19:34linkmauve: karolherbst, imirkin said it was better previously.
19:34karolherbst: I have a 1050 and UHD630 and hard time finding benchmarks where both GPUs are equally fast
19:34imirkin: i said it might be better
19:34karolherbst: I know some benchmarks where the 1050 is like 10% faster
19:35karolherbst: and like tons of benchmarks where the 1050 isn't even close
19:35imirkin: but this is GP104, so 1060+?
19:35karolherbst: ohhh. right
19:35karolherbst: yeah.. maybe it's better with a gp104 then
19:35linkmauve: imirkin, 1070 actually.
19:35imirkin: 1070 > 1060
19:35karolherbst: ahh.. yeah.. maybe those are equal in avg then
19:35imirkin: so ... within what i said :p
19:35karolherbst: but normally memory is a huge problem
19:36imirkin: yeah, coz it's clocked to like 10mhz :)
19:36karolherbst: yeah...
19:36karolherbst: it's bad
19:36karolherbst: but maybe the 1070 is fast enough
19:36karolherbst: dunno
19:37karolherbst: I doubt it kind of though
19:37linkmauve: I’m installing Dolphin, I’ll test it shortly. :)
19:37linkmauve: Is it still DRI_PRIME=1 to switch the rendering, on Xwayland?
19:38karolherbst: pmoreau: mind checking the HMM patches again? I think I am pretty much done with those patches
19:38karolherbst: linkmauve: yes
19:39linkmauve: Meh, ArchLinux still doesn’t have Citra or rpcs3 in their repositories…
19:39linkmauve: Stupid distro.
19:39ericonr: rpcs3 seems like a pain to build
19:39ericonr: you can just get their appimage instead
19:39linkmauve: It isn’t really.
19:39linkmauve: I was briefly working on it last year.
19:40ericonr: I looked at it briefly and gave up, but the appimage was enough for me so I didn't really have any great incentive
19:42linkmauve: I’m building the rpcs3-git package from AUR.
19:43karolherbst: pmoreau: image support for CL: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5242
19:43emersion: linkmauve: these planes are weird, they are missing basic properties?
19:44linkmauve: emersion, they’re what nouveau gives me, I haven’t checked plugging in an output yet.
19:46karolherbst: emersion: what do you think is missing?
19:46linkmauve: But yeah, how can you move e.g. a cursor without CRTC_X and CRTC_Y?
19:46emersion: CRTC_ID, CRTC_X/Y/W/H, SRC_X/Y/W/H
19:47karolherbst: this is with prime though, no?
19:47karolherbst: or shouldn't that make a difference?
19:47imirkin: none of the displays are lit
19:47imirkin: none of the planes are enabled
19:47imirkin: i don't think you get those properties
19:47linkmauve: I can plug in a display if you want.
19:47emersion: that's unrelated
19:47emersion: you can't create DRM properties on-the-fly
19:48emersion: (was discussed in dri-devel recently)
19:48imirkin: good point
19:48emersion: yeah, would be interesting to see what happens if you plug in something
19:49emersion: i expect errors from the compositor, if you try to use a compositor
19:49imirkin: iirc those properties are injected by the drm framework
19:49emersion: no idea how fbcon would handle it
19:49linkmauve: Even with the HDMI-A connector plugged in, I don’t get any image nor any additional plane.
19:49imirkin: so it's not anything that nouveau does or doesn't do...
19:49emersion: yeah, i think drm core creates them
19:49emersion: so i'm pretty surprised
19:50linkmauve: emersion, so fbcon doesn’t enable the display, how can I tell Weston to use this card?
19:50linkmauve: --drm-device=card1
19:50imirkin: yeah. that was added on my request :)
19:50imirkin: for people with 75 gpu's plugged in
19:50imirkin: and not wanting to bother with seats
19:51emersion: wlroots will try to use all drm devices, fwiw
19:51imirkin: emersion: oh, DRM_CLIENT_CAP_ATOMIC isn't there, i think those are atomic-only maybe?
19:51emersion: oh
19:51imirkin: nouveau doesn't expose atomic externally by default
19:51imirkin: largely due to someone being a yeller chicken
19:51emersion: i only checked DRM_CLIENT_CAP_UNIVERSAL_PLANES
19:52emersion: okay, that makes sense then
19:52imirkin: can boot with nouveau.atomic=1
19:53linkmauve: emersion, https://linkmauve.fr/files/card1.txt
19:53linkmauve: Still doesn’t lit up the screen.
19:53emersion: rip
19:53linkmauve: imirkin, can I rmmod nouveau and enable nouveau.atomic then?
19:53imirkin: linkmauve: yes, should be possible
19:53imirkin: i wonder why it gets llvmpipe
19:53emersion: weird, no error
19:53imirkin: do you need to install something for nouveau_dri.so to be installed?
19:54emersion: anything in dmesg?
19:55linkmauve: imirkin, no, just mesa.
19:55linkmauve: I do have nouveau_dri.so.
19:55imirkin: ok. i'll mirror emersion's question then ... antyhing in dmesg? :)
19:58linkmauve: https://linkmauve.fr/files/card1-dmesg.txt with the irrelevant parts cut out.
19:58linkmauve: If I’m missing any context, just ask me.
19:59imirkin: is the gpu plugged in weird somehow?
20:00imirkin: anyways, the issue is that you don't have firmware.
20:00imirkin: oh i see. second load, nevermind.
20:00imirkin: [ 3266.690002] nouveau 0000:01:00.0: sec2: cmdq: timeout waiting for queue ready
20:00imirkin: [ 3266.693602] nouveau 0000:01:00.0: gr: init failed, -110
20:00imirkin: that's not great.
20:00linkmauve: I plugged it in some slot marked PCIEX16.
20:01karolherbst: what kernel version is that?
20:01linkmauve: 5.6.14.
20:01karolherbst: huh
20:01karolherbst: msi stuff?
20:01linkmauve: How can I check?
20:01karolherbst: yeah.. that could explain it
20:01imirkin: and is that slot then attached to a controller that goes to serial, then phone line, then pringles can, back to pcie?
20:02linkmauve: imirkin, :D
20:02imirkin: iow, any funny business?
20:02linkmauve: I’m not marcan. :D
20:02karolherbst: if pci_enable_msi fails that's probably not good
20:02karolherbst: it's very bad
20:02imirkin: yes
20:02imirkin: very bad.
20:02imirkin: so i'm basically asking why does pci_enable_msi() fail
20:02karolherbst: maybe the falcons only work with msi enabled...
20:02linkmauve: imirkin, I think it’s a fairly normal computer, and the previous owner plugged it the same way on the same motherboard (plus a second 1070 because), on Windows.
20:02imirkin: you can boot with nouveau.config=NvMSI=0 to work around that
20:03karolherbst: imirkin: doubtful, it shouldn't change a thing, should it?
20:03linkmauve: Can I configure that after rmmod/modprobe?
20:03imirkin: yea
20:03karolherbst: we have this "pci->msi = pci_enable_msi(pci->pdev) == 0" line
20:03imirkin: karolherbst: if NvMSI = 0, it shouldn't even try
20:03karolherbst: yeah..
20:03karolherbst: but that shouldn't change a thing ;)
20:03karolherbst: maybe it does
20:03linkmauve: Hmm, “rmmod: ERROR: Module nouveau is in use”.
20:03linkmauve: I’ll just reboot.
20:03karolherbst: maybe pci_enable_msi breaks something if it gets tried
20:03karolherbst: dunno
20:04imirkin: linkmauve: anyways, it looks like the "secboot" firmware may be fucked too
20:04imirkin: so yeah, a cold reboot might be in order
20:04karolherbst: imirkin: I think we just don't get the interrupts... so we timeout
20:04linkmauve: Cold as in, poweroff/poweron?
20:04imirkin: yes
20:04karolherbst: and that's probably the msi issue
20:04karolherbst: mhh.... let me try with msi disabled :D
20:06karolherbst: heh.. actually this works for me
20:06karolherbst: maybe the system is just a little screwed up then
20:07linkmauve: I now have fbcon and weston displaying things!
20:07linkmauve: Ugh, I should add automatic Ethernet and DHCP stuff.
20:08linkmauve: Still llvmpipe.
20:09imirkin: ... dmesg
20:09linkmauve: https://linkmauve.fr/files/card1-dmesg2.txt
20:09linkmauve: (I was already at it.)
20:11imirkin: that looks _much_ happier
20:11imirkin: that's after weston fails to bring up accel?
20:11linkmauve: emersion, now I have properties in my planes.
20:11linkmauve: Long before.
20:11imirkin: ok
20:11imirkin: well the point of dmesg
20:11imirkin: is to find useful information relating to failures
20:11linkmauve: Yup. :)
20:11imirkin: so it's only useful to get it after the failures have occurred
20:12linkmauve: Oh, but I didn’t get any mention of nouveau in dmesg after starting weston.
20:12linkmauve: Should I increase the drm verbosity?
20:12imirkin: no
20:12imirkin: so there was no noise when weston started
20:12imirkin: about failures and whatnot?
20:12linkmauve: Nope.
20:13imirkin: ok, can you show weston log?
20:13linkmauve: https://linkmauve.fr/files/card1-2.txt
20:13linkmauve: It’s now happy about atomic.
20:14linkmauve: Uh, I also upgraded the kernel to 5.6.15 apparently, I hope it won’t affect the current debugging too much.
20:14linkmauve: I can downgrade if you want.
20:14imirkin: do you know if it will go to use renderD129 for GL?
20:14imirkin: it will not.
20:14imirkin: linkmauve: do you have piglit installed?
20:14linkmauve: Aside from the “[20:06:48.142] unexpectedly large timestamp jump (from 33794 to 35061)” line, everything looks similar in weston’s log.
20:15linkmauve: I can install it.
20:15imirkin: nah
20:15imirkin: just grab waffle
20:16imirkin: and run `wflinfo -p gbm -a gl`
20:16emersion: > unexpectedly large timestamp jump (from 33794 to 35061)
20:16emersion: fun
20:17linkmauve: Ugh… /usr/bin/ld: src/waffle/CMakeFiles/waffle-1.dir/wayland/wayland_platform.c.o:/usr/src/debug/waffle/src/waffle/wayland/wayland_wrapper.h:81: multiple definition of `wfl_wl_proxy_marshal_constructor_versioned'; src/waffle/CMakeFiles/waffle-1.dir/wayland/wayland_display.c.o:/usr/src/debug/waffle/src/waffle/wayland/wayland_wrapper.h:81: first defined here
20:17linkmauve: Works fine without wayland support.
20:18linkmauve: imirkin, segfault. :D
20:18imirkin: super.
20:18imirkin: sorry, this is turning into a long rabbit hole
20:18imirkin: i'd recommend you just use X, where everything Just Works (tm)
20:18linkmauve: Thread 1 "wflinfo" received signal SIGSEGV, Segmentation fault.
20:18linkmauve: wgbm_window_teardown () at src/waffle/gbm/wgbm_window.c:48
20:19imirkin: i have zero experience debugging stuff like this on wayland
20:19linkmauve: I’m actually not on Wayland atm, I’m on gbm.
20:19imirkin: s/wayland/gbm/
20:19linkmauve: xexaxo1, do you still care about waffle? ↑
20:19imirkin: piglit uses waffle
20:20xexaxo1: linkmauve: check latest version perhaps ;-)
20:20linkmauve: Waffle error: 0x2 WAFFLE_ERROR_UNKNOWN: gbm_surface_create failed
20:20linkmauve: xexaxo1, I’m building master.
20:20xexaxo1: linkmauve: github or gitlab?
20:21linkmauve: GitHub.
20:21imirkin: linkmauve: stupid question ... could it be a permissions problem?
20:21linkmauve: … Indeed it is. :x
20:22xexaxo1: linkmauve: this has fixed the GCC -fcommon issue https://gitlab.freedesktop.org/mesa/waffle/-/merge_requests/70
20:22linkmauve: OpenGL vendor string: nouveau
20:22linkmauve: OpenGL renderer string: NV134
20:22linkmauve: OpenGL version string: 4.3 (Compatibility Profile) Mesa 20.1.0
20:22linkmauve: OpenGL context flags:
20:22linkmauve: xexaxo1, so should I tell the AUR maintainer that development now happens there?
20:22xexaxo1: just pull master from gitlab and file any bugs
20:23linkmauve: xexaxo1, now it finds llvmpipe instead of segfaulting. :)
20:23linkmauve: And nouveau when ran as root.
20:24imirkin: linkmauve: ok cool
20:24xexaxo1: linkmauve: for llvmpipe https://gitlab.freedesktop.org/mesa/waffle/-/merge_requests/75
20:24imirkin: yeah, i always had to run weston as root
20:24linkmauve: oO
20:24imirkin: they try to prevent you, but ... there's basically no way to use the thing
20:25imirkin: (one of the reasons i stay on X)
20:25xexaxo1: linkmauve: aka it can fail - planning ot push ^^ in a day or so
20:25xexaxo1: linkmauve: aur - sure
20:25emersion: imirkin: do you have systemd?
20:27imirkin: lol no
20:27xexaxo1: imirkin: https://cgit.freedesktop.org/drm/drm-misc/commit/?id=45bc3d26c95a8fc63a7d8668ca9e57ef0883351c should give you weston w/o root (direct or setuid) when logind is missing
20:27linkmauve: Now that I’m in the video group, I can open() /dev/dri/card1 from python, but wflinfo still gives me llvmpipe.
20:27emersion: then KMS clients need to be suid to become DRM master
20:27imirkin: emersion: yeah. but weston isn't ready to be suid afaik
20:28emersion: ah, weston has a weird weston-laucnh thingie
20:28linkmauve: imirkin, weston-launch should be.
20:28xexaxo1: emersion, imirkin: see linked patch.
20:28imirkin: xexaxo1: yes, i saw.
20:28imirkin: linkmauve: ah right ... yeah
20:28imirkin: anyways
20:28imirkin: it always seemed like a pretty big pain
20:28linkmauve: xexaxo1, mpv people linked it to me a few months ago, pretty cool. :)
20:28imirkin: and given that it has literally zero benefit
20:28emersion: oh
20:28imirkin: and a ton of downsides
20:28emersion: oooooh
20:29imirkin: it never seemed like such an attractive thing to investigate
20:29linkmauve: imirkin, in my case, I’m pretty sure Xorg would also fail to open the card node.
20:29imirkin: linkmauve: as root?
20:29xexaxo1: linkmauve: can you strace wflinfo .... ?
20:30linkmauve: Ah no, I wouldn’t run such a monster as root. :x
20:30imirkin: i made my peace with that many years ago.
20:30emersion: ah, that still means the client needs to be suid right xexaxo1? it's just that now it can drop root?
20:30xexaxo1: emersion: nope.
20:31linkmauve: xexaxo1, https://linkmauve.fr/files/wflinfo.strace
20:31linkmauve: It seems to try both cards.
20:31linkmauve: Ending up picking none.
20:31xexaxo1: emersion: if the client was ever master - it can drop and _regain_ master
20:31linkmauve: Effectively making logind useless for the usecase of becoming DRM master.
20:32emersion: okay, so not as great as one would think
20:33xexaxo1: emersion: in what sense?
20:33imirkin: linkmauve: well, ultiamtely doesn't matter what wflinfo thinks. if weston (or sway or whatever) is picking the right thing, then all good
20:33xexaxo1: linkmauve: for some strange reason it fails to get the nouveau_vieux _name_
20:34imirkin: that was just a quick small utility i could point you to.
20:34emersion: well, we still need suid
20:34linkmauve: xexaxo1, where do you see that?
20:34linkmauve: imirkin, yeah, but I’m not gonna run weston as root either. :)
20:34emersion: we have a lightweight suid child process that we keep around, we could probably drop it with that patch
20:34emersion: but unsure what that means for input devices
20:35linkmauve: I’ve worked on this compositor, I know not to give it root. :p
20:35imirkin: linkmauve: any code you've touched shouldn't have root? :)
20:35emersion: maybe we still need the suid helper for input devices
20:35linkmauve: (I’ve also worked on Xorg, and I wouldn’t do that either.)
20:35imirkin: linkmauve: just don't ever look at 'sudo' :)
20:35linkmauve: imirkin, you know, don’t look at how sausages are made? :p
20:35imirkin: yeah, coz if you do, all you want is to make sausages after :p
20:36imirkin: [that's from 'the office']
20:36linkmauve: :D
20:36xexaxo1: emersion: we need root - citation needed. I've actually ran the patch with X and weston, w/o any logind and w/o root/setuid ;-)
20:37xexaxo1: linkmauve: in the log - nouveau_vieux_dri is never attempted.
20:37imirkin: well, nouveau_vieux_dri is probably not installed. and not extremely relevant i'd guess.
20:37xexaxo1: *my bad nouveau
20:37emersion: xexaxo1: oh, so maybe if we're the first client, it's fine
20:38emersion: that'd be extra nice
20:38xexaxo1: so either it never attempted the nouveau node, or it failed to get the name somehow
20:38emersion: still need to see what happens wrt. input devices
20:39xexaxo1: emersion: precisely. depending on distro + magic = the user needs to be in video/input groups
20:40emersion: right
20:41linkmauve: xexaxo1, do you want the strace of running waffle as root, using nouveau?
20:44xexaxo1: linkmauve: if possible, yes
20:44linkmauve: It seems to be doing the same dance, but earlier.
20:44linkmauve: xexaxo1, https://linkmauve.fr/files/wflinfo-root.strace
21:02xexaxo1: linkmauve: hmm which mesa version are you using?
21:02linkmauve: 20.1, from the extra repository.
21:02xexaxo1:wonders if something weird got pushed recently
21:02linkmauve: I haven’t built master yet.
21:04xexaxo1: MESA_LOADER_DRIVER_OVERRIDE=nouveau wflinfo ... should get you going. although I wonder what/where the bug is
21:04linkmauve: Indeed it does.
21:05linkmauve: I’ll test weston once rpcs3 is built, but it should be fine now.
21:17linkmauve: 13:31.00 total to build rpcs3, including LLVM. <3
21:17linkmauve: If anything, this will make a much better build machine than this laptop. ^^
21:21linkmauve: Weston finally loads Nouveau instead of llvmpipe, but it doesn’t display anything: https://linkmauve.fr/files/card1-3.txt
21:23xexaxo1: linkmauve: afaict the only way iris gets picked over nouveau is because the ^^ envvar was already set
21:24linkmauve: Oh, I’m dumb, I carried over my .zshrc and that’s the cause. >_<
21:24linkmauve: Indeed.
21:25linkmauve: But hmm, for wflinfo, shouldn’t it then use iris on the renderD128, instead of ending up with llvmpipe?
21:26xexaxo1: linkmauve: it tries to use iris - although i915 ioctls on nouveau DRM module don't seem to work.
21:26xexaxo1: so we fall back to llvmpipe.
21:27linkmauve: xexaxo1, but it has a second DRM module to use it on, where it should succeed, right?
21:28linkmauve: Why does it pick this one over the other, while I can see it attempt to do stuff with renderD128 (which is my i915 render node).
21:30xexaxo1: because EGL Device took forever to become reality. w/o it the which node/device is picked varies on moon-cycle
21:30linkmauve: In the strace it clearly attempts to do stuff with both.
21:31xexaxo1: or in particular - waffle uses udev to enumarate over the nodes and udev provides 129 first.
21:31xexaxo1: the 128 thing you see in the trace is from the drmDevice called by mesa.
21:32xexaxo1: depending on the path - it can either look for details of one drmDevice or all of them.
21:33xexaxo1: should really do another round of cleanups there... fingers crossed in the next few weeks
21:33linkmauve: So what’s actually missing is EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query to be wired up in waffle?
21:34xexaxo1: correct - in libwaffle and it's users.
21:34xexaxo1: on the weston front - forse non-atomic modeset, in case there are some glitches in there.
21:37linkmauve: WESTON_DISABLE_ATOMIC=1
21:38linkmauve: Nope, same black screen with nothing in the logs.
21:39linkmauve: Weston’s logs say that DRM atomic isn’t supported anymore.
21:39linkmauve: Nothing in dmesg.
21:39imirkin: silly question -- is nvidia card0 or card1?
21:39imirkin: udevadm info /dev/dri/card1
21:40imirkin: make sure it points to the right pci slot
21:41linkmauve: card1 points to the same PCI path as lspci says the Nvidia GPU is.
21:41linkmauve: And card0, to the Intel GPU.
21:42linkmauve: Oh I almost forgot, https://drmdb.emersion.fr/devices/e7a12247114d
21:43imirkin: ok
21:43imirkin: just checking. easy to get carried away and forget about the simple stuff.
21:44linkmauve: Indeed, as we’ve seen multiple times tonight. ^^'
21:46linkmauve: Just to make sure, I’ve plugged in the output to an Intel connector, ran weston on card0, and it starts just fine.
21:46imirkin: weston just hates nouveau i guess
21:46xexaxo1: linkmauve: have you tried something simple - kmscube or modetest -r (with and w/o -a)
21:46linkmauve: ^^'
21:47xexaxo1: the latter attempts the "default" resolutions on all connected displays (for the given device)
21:52linkmauve: So, for kmscube it blinks the top few lines with kmscube-gray, one line gray and the next one black, the rest of the screen black.
21:52linkmauve: Until I ^C, then it stops, and I have to start weston to get back fbcon.
21:52linkmauve: If I ask for atomic, it complains that eglDupNativeFenceFDANDROID isn’t implemented then exits with -1.
21:53linkmauve: Where do you find modetest?
21:54xexaxo1: libdrm/tests/modetest
21:55xexaxo1: kmscube uses EGL, just like weston. modetest uses dumb buffers.
21:55xexaxo1: should help track down where the problem is - DC and/or GPU side
22:03linkmauve: xexaxo1, I get a nice colour testing pattern with: % tests/modetest/modetest -M nouveau -r
22:03linkmauve: setting mode 1920x1080-60.00Hz on connectors 81, crtc 47
22:04imirkin: yay, something works
22:04imirkin:is going to pre-blame modifiers
22:04xexaxo1: hehe, priceless
22:06linkmauve: I’ll modify weston to not check whether DRM_CAP_ADDFB2_MODIFIERS is true.
22:10linkmauve: Nope, same black screen.
22:11linkmauve: Should I disable modifiers in more places?
22:11linkmauve: I’ll send this Weston patch first.
22:13linkmauve: Oh, it already wasn’t using them, first line of https://drmdb.emersion.fr/devices/e7a12247114d
22:13linkmauve: DRM_CAP_ADDFB2_MODIFIERS = 0
22:15linkmauve: This is still with atomic disabled, but enabling it didn’t change anything.
22:15linkmauve: It is enabled in the kernel.
22:17xexaxo1: tests/modetest/modetest -M nouveau -r -a << will use atomic modeset fwiw
22:20linkmauve: It works as well as without the -a.
22:23linkmauve: I’ll test modifying kmscube to allocate all linear, to make sure.
22:24linkmauve: imirkin, you were right!
22:25linkmauve: It works if I remove the check for EGL_EXT_image_dma_buf_import_modifiers.
22:26imirkin: he he he he he
22:26imirkin: J'accuse!
22:29linkmauve: Now what did I change, it’s back to the interlaced-like blinking lines at the top. >_<
22:29linkmauve: And runs at 30fps.
22:30linkmauve: I guess now would be the time to go to sleep, if I can’t remember what I did differently three minutes ago…
22:31linkmauve: And thanks all for this debugging session!