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