00:37imirkin: joepublic: what does the HDMI one say in xrandr? does it *think* it's on?
00:38imirkin: the lxde/xfce thing is something specific to what those window managers do. not sure what to say there. would need to be reported to them and debugged in coordination with those developers.
00:39imirkin: as for DP being off until a re-plug, that's very weird. however iirc you're using a pretty old kernel? i'd encourage you to try a newer kernel.
00:39joepublic: The HDMI monitor says "HDMI-1 connected (normal left inverted right x axis y axis)"
00:39imirkin: and there's a mode with a * next to it?
00:40joepublic: i.e. no resolution selected, no * by a mode
00:40imirkin: aha ok, so then everything's working as intended :)
00:40imirkin: if there were a * by a mode, then it'd be much worse
00:40imirkin: as for WHY it decides not to set a mode ... not sure.
00:40joepublic: and I am on 4.20-rc3 right now
00:41joepublic: well, if I tell it to light up, it does so reliably.
00:42joepublic: I have a launcher on my cairo-dock to turn it back on actually.
00:43imirkin: i just mean ... there have been situations where we've *thought* it was on, and it was actually off
00:43imirkin: which are much worse
00:43imirkin: at least here we think it's off and it's off
00:44imirkin: tbh, i'm not entirely sure what's supposed to happen when you power off a monitor
00:44imirkin: or when you power one on, actually
00:44imirkin: however i do know that this is controlled by your desktop environment
00:44imirkin: the only serious issue i see here is your #3 issue
00:44joepublic: perhaps I should chase it with the xfce folks.
00:44imirkin: can you describe your DP monitor?
00:45joepublic: that monitor is a displayport-to-vga adapter with an "element" brand 40" television's vga port connected to it.
00:45imirkin: a DP adapter misbehaving ... wouldn't be the first time
00:46imirkin: otoh, could be something we're doing wrong
00:46imirkin: unfortunate this is not a portion of the logic i'm familiar with
00:46imirkin: Lyude: ---^ anything jump to mind?
00:46joepublic: I could get another one and see what happens. I trust you more than cheap chinese electronics.
00:47imirkin: DP is all kinds of weird
00:47imirkin: the dongle could be totally fine
00:47joepublic: that dongle worked as i expected, in fact, when connected to a radeon card
00:48imirkin: yeah, so we know it's not totally busted
00:48imirkin: i don't suppose there's a native VGA port you could just plug into?
00:48joepublic: but two different cards, two different manufacturers (that one was MSI, this one EVGA), hard to say whether it's a quirk of the DP adapter
00:50joepublic: hmm, I could move my DVI-I monitor to the DVI-D port and get a DVI-I-to-VGA adapter to try, that's the closest thing. The card has DP, HDMI, DVI-D, DVI-I
00:50Lyude: is this a dp -> vga dongle?
00:50imirkin: k, if it's not something you have handy, i wouldn't worry about it
00:50imirkin: Lyude: yeah
00:51joepublic: I have one somewhere in the great junk pile but don't know where.
00:51Lyude: I've heard rumors and whispers they have issues but have never seen any issues with them myself, so maybe that's related. but if xrandr can see the modes and isn't selecting one then something else is likely going on
00:51imirkin: we're not detecting it as connected on module load
00:51imirkin: however on unplug/replug, it works
00:51Lyude: i might have something you can tyr
00:51Lyude: one second
00:52imirkin: maybe it doesn't raise hpd when it should? dunno
00:52Lyude: also, download this in the mean time https://gitlab.freedesktop.org/lyudess/auxrw since we'll need it in a second
00:52Lyude: imirkin: it's more likely we didn't implement a specific part of the spec I remember
00:53imirkin: highly likely - i think skeggsb was just going off of nvidia traces
00:53Lyude: lemme grab one of my vga connectors real quick to make sure i've got this right
00:53Lyude: *vga adapters
00:58Lyude: alright, mine doesn't seem to support it but joepublic: using that tool, could you go through and try running
00:58Lyude: auxrw r /dev/drm_dp_aux0 0-f
00:59Lyude: then repeat it for all of the /dev/drm_dp_aux* files
00:59Lyude: make sure the vga adapter is connected as well
01:00Lyude: imirkin: what's probably happening jfyi: I didn't think anything actually needed this to work, but there is a specific VGA force-probe cap that I don't think we actually do anything with in DRM
01:00joepublic: no such file or directory, it says, which ls confirms
01:00Lyude: joepublic: what kernel is this on?
01:01Lyude: joepublic: mind making sure you have CONFIG_DRM_DP_AUX_CHARDEV enabled in the kernel?
01:01joepublic: let me look
01:03joepublic: Man you guys are good. the kernel .config says "# CONFIG_DRM_DP_AUX_CHARDEV is not set"
01:03Lyude: hehe, I try :)
01:05joepublic: perhaps I should roll a new kernel with CONFIG_DRM_DP_AUX_CHARDEV set to something specific? "y" perhaps?
01:05imirkin: Lyude: does amdgpu do anything with it?
01:05imirkin: coz it works with amdgpu
01:05Lyude: imirkin: ugh.
01:05imirkin: [right, joepublic?]
01:05Lyude: i bet you they write it somewhere in their magic hal
01:05Lyude: instead of actually adding a helper for it
01:06joepublic: worked for me on amdgpu, anyway, and on "radeon" before it
01:07Lyude: i would try to look to see what they do but that's going to be a lot harder then just trying to force probe this ourselves
01:07imirkin: well - maybe they reprobe stuff unnecessarily
01:07imirkin: who knows
01:07Lyude: oh they do
01:07imirkin: still worth checking that force-probe cap
01:07Lyude: oh yeah, actually that's probably why it'd work anyway
01:08Lyude: anyway joepublic; let me know when you get the chardev stuff enabled and try the auxrw thing I suggested above again
01:08joepublic: okay. i am in the deep end of the pool here & takes me a little while to compile a kernel
01:09Lyude: np, there's not much rush
01:16joepublic: So, I am about 25 minutes away from having 4.20-rc4 with CONFIG_DRM_DP_AUX_CHARDEV=y
01:16imirkin: ouch =/ your computer is nearly as slow as mine
01:19joepublic: my kernel compile scripts need work. When I compile manually it takes about 15 minutes. When I use my set of kludgy scripts that edit all the makefiles to ask for -O3 and then monitors and the progress it takes much longer. message is, compile manually I guess
01:32Lyude: joepublic: hold on though, if you're recompiling and you haven't changed anything but that one config option shouldn't it just recompile only part of the kernel?
01:33imirkin: that's if you have a persistent tree
01:33joepublic: I have never got that quite down right. Yes, for someone competent.
01:33Lyude: imirkin: of course
01:36joepublic: the compiling part is done and now it's taking its sweet time making debian packages of the kernel for me to install
01:49joepublic: Lyude, imirkin, The information is as follows: http://paste.debian.net/1053354/
01:50joepublic: as I have just booted up, the connected DP is saying disconnected.
01:53imirkin:has no clue how to interpret that
01:53Lyude: looks like the force probe stuff wasn't added till 1.2, an that's 1.1 and definitely doesn't have the cap
01:54Lyude: but there's other ways to figure out if we need to do force detections/to do force detections I'm fairly sure
01:54joepublic: is there some equivalent to a "turn thyself on so I do not have to move the PC from the wall and monkey with the cables" command?
01:55Lyude: joepublic: no, but there's other ways to detect vga displays then load detection
01:55Lyude: joepublic: can you get auxrw r /dev/drm_dp_aux0 80-8f
01:55Lyude: actually, let me make this simpler
01:56joepublic: it's 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01:56joepublic: that's pretty simple :)
01:57Lyude: your vga adapter is mean
01:57imirkin: now it's personal!
01:57Lyude: it says it's VGA, and also that it has downstream HPD
01:57Lyude: imirkin: hehe
01:58joepublic: finest crap ever to arrive e-package from shenzhen.
01:58imirkin: Lyude: how does hpd normally work?
01:58imirkin: what causes it to get deasserted?
01:58imirkin: i thought it was normally a pulse
01:58imirkin: but then ... how do you check on startup
01:59Lyude: imirkin: normal DP hpd just happens through a long pulse on the hpd line of course, then I think we follow it up with trying to find an edid and all that jazz
01:59Lyude: but, hm.
01:59Lyude: maybe that isn't actually the problem here
01:59joepublic: I did find a DVI-I to HDMI adapter which could possibly eliminate displayport from being a thing in my configuration. Avoidance and denial at work.
01:59Lyude: mhm, it would be nice to actually get this fixed though
02:00imirkin: joepublic: an HDMI port can't take VGA
02:00joepublic: no worries, this little adapter just means that it will work eventually whether I benefit from the fix or not.
02:00imirkin: no matter how many connectors you hook up to it
02:00Lyude: joepublic: mind booting up with drm.debug=0x106 log_buf_len=100M with the adapter hooked up, then sending me that?
02:00joepublic: well, the monitor is VGA or HDMI, take your pick
02:00Lyude: want to make sure I've got this dp probing story straight
02:00imirkin: well that's just cheating
02:01imirkin: but DP -> HDMI should be easy with a passive adapter
02:01joepublic: HDMI just blinks off every time the beer fridge kicks on or off so I try to avoid it
02:01joepublic: for "drm.debug=0x106 log_buf_len=100M" what exactly do I add to the kernel line?
02:01joepublic: just that?
02:01Lyude: yep, just that
02:01joepublic: k will be back shortly.
02:01Lyude: (I am -so- glad I added dp aux tracing there :)
02:04Lyude: imirkin: so, I realized for devices like this where a hotplug can happen on the downstream port while the adapter is connected, it probably just sends another dp pulse
02:05Lyude: and likely doesn't keep it's hpd line asserted
02:09joepublic: do you want... dmesg maybe?
02:09Lyude: joepublic: yep
02:14Lyude: oh, hm. nouveau is actually doing everything it should be doing here (poking ddc, probing for edid)
02:14imirkin: drm:drm_dp_i2c_do_msg [drm_kms_helper]] native defer
02:14imirkin: what is that again?
02:14Lyude: imirkin: "i'm too busy talk to me again in a moment"
02:14joepublic: (other than something that seems to fail)
02:15imirkin: Lyude: hmmmm ... do we mess up the order of something?
02:15imirkin: or does link training fail?
02:16Lyude: imirkin: no, it's just not seeign anything on the port or we're not being patient enough with it. joepublic-did that boot have anything on the VGA port of the adapter?
02:16joepublic: yes the TV was on and set to VGA and complaining about no signal.
02:16imirkin: Lyude: you'll note the probe sequence repeats a few times
02:17Lyude: imirkin: yeah, which is weird because I don't see any actual hotplug signals being reported by nouveau
02:17Lyude: so it's gotta be userspace
02:18imirkin: perhaps joepublic running 'xrandr' :)
02:18Lyude: or the adapter is in some weird state on boot
02:18Lyude: i'm starting to become very suspecious of that
02:18joepublic: I think that the DP-1 disconnected at about 131 seconds is the TV turning itself off
02:19Lyude: joepublic: mind getting me a dmesg after you've replugged the adapter?
02:19joepublic: replugging now.
02:19Lyude: i'm worried something the vbios is doing might be upsetting the adapter
02:19Lyude: but usually I'd expect to see NAKs in that case
02:21joepublic: now xrandr reports "DP-1 connected (normal left inverted right x axis y axis)"
02:22Lyude: oh man, I think I see what it's doing
02:22Lyude: ...also it's quite concerning I don't actually see any debugging output from the DP AUX channel in this log despite the fact that seems to be enabled in the kernel commandline just fine
02:23imirkin: is it in that kernel?
02:23Lyude: imirkin: yes, since 4.19
02:23imirkin: [ 888.167157] nouveau 0000:04:00.0: DRM: unplugged DP-1
02:24imirkin: it clearly knows something's plugged in
02:24joepublic: cat /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-4.20.0-rc4-x64-joe-1 root=UUID=0090147c-5b19-4cee-926d-2b02b582a963 ro drm.debug=0x106 log_buf_len=100M
02:24Lyude: imirkin: it's not deferring enough after boot
02:24Lyude: 99% sure that's the problem here
02:24Lyude: notice how on the successful probes there's more defer notices and it doesn't give up as quickly
02:24imirkin: but ... why
02:24Lyude: yep, that's the question now :)
02:25imirkin: looks like it takes 2x as long in the post-boot case
02:27Lyude: joepublic: you got that dmesg just by using the normal `dmesg` command right
02:27joepublic: I did sudo dmesg > joe-dmesg2.txt
02:28Lyude: oh weird; there is one line of dpcd_read debugging up there
02:29joepublic: um, something just occurred to me
02:29joepublic: the TV is not connected to the DP adapter -- a KVM switch is. The TV is connected to the KVM switch. I probably should have mentioned this earlier.
02:30Lyude: probably, but at least I'm fairly sure I don't think that's related
02:31joepublic: the idea of the KVM switch is to pretend to be a monitor even if switched away from that input.
02:31Lyude: "We could check for I2C bit rate capabilities and if available adjust this interval. We could also be more careful with DP-to-legacy adapters where a long legacy cable may force very low I2C bit rates. For now just defer long enough to hopefully be safe for all use-cases"
02:32Lyude: hope only goes so far
02:32joepublic: Sometimes hopefully translates to wonderful things. Maybe so here, maybe not.
02:32imirkin: Lyude: but why does it try for longer in the later case?
02:32imirkin: does the i2c clock speed change?
02:33Lyude: imirkin: it must be, it calculates the retry count based on the aux req/i2c msg duration
02:33Lyude: we're seeing it do less then 7 retries, and on i2c defers acros dp aux that's against the spec-we always need to retry at least 7 times in cases of defers
02:33Lyude: but we aren't there
02:34Lyude: so i think it's likely we shouldn't even be paying attention to max_retries in that case-we should make sure we /always/ retry again on defer, up until we hit the count of 7
02:34joepublic: looks like 18 defers at 893 seconds
02:34Lyude: wait, no, there's 7
02:34Lyude: my eyes lied to me
02:36joepublic: groups of 7 starting at 2.42 seconds that each fail until the unplug/replug comes at it from a different direction.
02:37joepublic: One of these monitors is 1024x768 displaying a 1920x1080 desktop using --scale-from 1920x1080 --panning 1920x1080+3840+0
02:37joepublic: just want you guys to know that impressed me that that actually worked.
02:43joepublic: are the five lines starting at 2.419370 what it knows about the displayport device, and possibly enough information to identify a device with a quirk that it likes to be given more time?
02:43Lyude: joepublic: well yeah, we can add a quirk here. the problem is we don't know why it's retrying longer post-replug
02:44Lyude: because it should just be doing that from the start
02:45Lyude: hm, unless the native defers are coming from multiple transactions
02:45joepublic: this KVM is hell on EDID and I have to manually add the modes for that monitor.
02:45joepublic: I had forgotten about that.
02:45Lyude: so, actually now I am suspecious of the kvm behind that
02:46Lyude: can you try without the kvm to make sure that's not causing the issue?
02:46joepublic: that is probably a yes.
02:47Lyude: well if it is then problem solved: we can just give you a kernel cmdline option to force an edid on it and call it a day
02:48joepublic: i have plugged the monitor directly into the displayport adapter. will reboot to test.
02:48Lyude: I'm hungry, and it's getting late. both good reasons to head out of the office. joepublic: i'll still be here on my phone, but replies might be slow
02:48Lyude: oh ok
02:48Lyude: right, rebooting
02:49Lyude: imirkin: so, I think the multiple native defers that come after the plug are just multiple transactions with one or two defers per transaction
02:49Lyude: just going off the code
02:49Lyude: which means it's probably just a dumb kvm
02:50Lyude: adapter gets detected, but no edid over i2c makes us ignore it, so yeah
02:53joepublic: interestingly, all three monitors came up perfectly.
02:56joepublic: The displayport comes up at about 2.433
02:57Lyude: that's without the kvm?
02:58joepublic: no kvm, TV's VGA port connected to DP adapter
02:58Lyude: damn, knew it
02:58Lyude:was hoping for a fun bug :(
02:59Lyude: joepublic: so, workaround for you: add drm_kms_helper.edid_firmware=DP-1:edid/1920x1080.bin
02:59Lyude: to your kernel commandline
02:59Lyude: that'll force it to get an edid on there regardless of whether it actually finds one or not
02:59joepublic: you could consider it a bug if you want. there is a device connected but shows disconnected.
02:59Lyude: yeah, but there isn't much we can do since it seems the kvm is the one not responding here, not the adapter
03:00Lyude: that kernel cmdline option I just gave you should workaround it though, and you should remove it in the future if you plan on plugging something else into there someday
03:00joepublic: wonder why it responds later on unplug/replug?
03:01joepublic: Thank you for that, I am editing /etc/default/grub with it
03:01Lyude: joepublic: I dunno tbh, kvm adapters are unfortunately really notorious for this exact sort of thing
03:02joepublic: I would tell you the highly reputable brand name but it is written in chinese and I do not read chinese.
03:04joepublic: one more reboot to cancel the debugging and watch the magic drm helper do its thing.
03:04Lyude: joepublic: heading out of the office now but I'll have my phone on IRC, feel free to poke me again if you have any more issues
03:04joepublic: Thanks; I appreciate warmly and amply.
03:12joepublic: amazingly, now the menus work on the DP monitor. That's two for one.
03:15Lyude: Nice!, glad I could help!
03:19joepublic: Me too. Thanks again.
03:36pl44c: Lyude: any luck sourcing a dock for the w530?
03:39pl44c: Lyude: any luck sourcing a dock for the w530? (sorry if double message)
05:09bemeurer: Hi, can anyone tell me which family does the Quadro P2000 MaxQ belong to?
05:11bemeurer: HdkR: Ah, so half-working is the current status?
05:11HdkR: Although wikipedia says GP207 for the mobile chip which I have no idea wtf that means
05:12HdkR: It's Pascal regardless
05:12bemeurer: I have a laptop with one of those cards coming in tomorrow; I have no intention of using it, I just want to use intel drivers but I was worried nouveau would cause things to fail to boot
05:13bemeurer: And IIRC if you have an nvidia card, but don't load nouveau it'll still eat your battery away
05:14HdkR: No idea on that one
05:14bemeurer: HdkR: Well, guess I'll find out tomorrow and report back :)
22:27pl44c: ok so I'm still having that issue were when I set the provider offload sink with xrandr that the nvidia card outputs don't appear
22:27pl44c: not sure why this happened as it was working and I didn't change anything
22:28karolherbst: pl44c: mhh, interesting. Are you using the modesetting or nouveau ddx?
22:28karolherbst: pl44c: and do you know if the outputs are actually listed in sysfs?
22:28karolherbst: pl44c: you should have an entry for each output inside /sys/class/drm/
22:29pl44c: modesetting right now but when I switched to intel/nouveau the same result happened
22:29karolherbst: each with a status file saying connected/disconnected
22:31pl44c: I do see outputs there not in xrandr
22:31pl44c: also replugging a display will cause the laptop display to jitter as if it was plugged
22:34pl44c: here's dmesg and Xorg log
22:36karolherbst: pl44c: what does the card1-.../status file say?
22:36karolherbst: for the outputs you have a display connected
22:37karolherbst: but that means something in userspace is messed up
22:37karolherbst: pl44c: are you sure you setup the offloading correctly?
22:38pl44c: says that 3 are connected
22:38pl44c: which is true
22:38pl44c: or 4 rather
22:38karolherbst: sooo, the kernel side seems fine
22:38karolherbst: but xrandr isn't
22:39pl44c: seems that way
22:39karolherbst: how do you setup the offloading?
22:39karolherbst: the offload sink
22:40karolherbst: and what is "xrandr --listproviders" telling you?
22:40pl44c: https://dpaste.de/ZcWu I posted listproviders and I set it with xrandr --setprovideroffloadsink 1 0
22:41pl44c: when I switch to nouveau / intel it does the same
22:42karolherbst: ohh, because that's wrong
22:42karolherbst: xrandr --setprovideroutputsource 1 0
22:42karolherbst: you need that
22:42karolherbst: setprovideroffloadsink is for DRI_PRIME=... stuff
22:42karolherbst: setprovideroutputsource is for reverse prime
22:43karolherbst: and setprovideroffloadsink is only required if you don't have DRI3
22:43karolherbst: which you should have
22:43pl44c: and I guess if I wanted to offload rendering to the gpu?
22:44karolherbst: well, you kind of want to be able to do both
22:44karolherbst: the first thing doesn't change much by default
22:44karolherbst: it just tells if you render on nouveau, it displays on intel
22:44karolherbst: more or less
22:45pl44c: now if I wanted to completely unload nouveau and attach vfio-pci what's the reccomended way to do that
22:45karolherbst: so I guess the outputs are showing inside xrandr now?
22:45karolherbst: pl44c: stop X
22:45karolherbst: with reverse prime there isn't really a different way
22:45karolherbst: X claims references the driver
22:46pl44c: is there any other way to save the applications open at least?
22:46karolherbst: with the dummy DDX and DRI3 offloading you can remove nouveau while X runs
22:46karolherbst: but you can't use displays on the nvidia GPU then ;)
22:46karolherbst: pl44c: through your desktop environment
22:46karolherbst: gnome and plasma support this more or less
22:46karolherbst: they can save and restore your user session
22:47karolherbst: never used it though
22:47karolherbst: and I expect it doesn't work that well
22:47pl44c: it only saves open programs iirc
22:47pl44c: not the state they were in
22:47karolherbst: it's up to the application to save the state sadly
22:47karolherbst: no other way to do it ;)
22:47karolherbst: some application can do that though
22:48karolherbst: but yeah
22:48karolherbst: linux lacks in that regard quite a bit
22:49pl44c: well at least I can swap active driver of a video card to attach to a vm
22:49pl44c: something windows cannot do
22:53pl44c: Thanks a bunch I had those commands confused it seems
23:00pl44c: oh wait you mentioned that I could remove nouveau while X runs with dummy ddx
23:00pl44c: I mostly planned on using the vm when not docked
23:05HdkR: karolherbst: As far as I am aware, the only OSes that have managed to enforce apps reloading state effectively are mobiles
23:06karolherbst: HdkR: right
23:08pl44c: karolherbst: how would I configure X to be able to use the dummy ddx and dri3 offloading you described so that I can unload the nouveau module while keeping X up
23:10pl44c: I want to script it so that once I undock the laptop it will unload nouveau and load vfio-pci
23:14goonieb: hello theren I have abn inquiry: is multiple gpu supported in nouveau, say GTX760+1060 ?
23:38karolherbst: goonieb: depends on what features you expect. Rendering on both GPUs? no, Using displays of both GPUs? yes
23:40goonieb: karolherbst: I would just need a bunch of ports.*
23:40karolherbst: yeah, that should work
23:40goonieb: karolherbst: also,can nvidia driver be run alogsid nouveau for different gpus of course?
23:41karolherbst: i don't know if somebody actually tried
23:41gnarface: it can't
23:41gnarface: i've tried
23:41karolherbst: yeah, because nouveau claims all GPUs
23:41karolherbst: what if it didn't
23:41gnarface: no, because nvidia's driver fucks up the framebuffer somehow
23:41karolherbst: why would it?
23:41karolherbst: because it replaces the fb
23:41goonieb: gnarface: I think I have too and it didn't but I wanted to make sure
23:42karolherbst: gnarface: I think if nouveau claims the GPU having the framebuffer it should work alright?
23:42gnarface: karolherbst: whatever it's doing to the framebuffer it's not useful unless you count minimum text size +500% to be a useful feature
23:42karolherbst: would be interesting to play with
23:42goonieb: gotta hange my display setup due to ryzen
23:42goonieb: nvidia+itel so far
23:42goonieb: sorry, lame keyboard
23:43gnarface: karolherbst: yea i think it could work if you had two cards and you could get the nouveau one to let the nvidia one have the framebuffer for just one card
23:43gnarface: i think that could work but i'm not sure if the nvidia driver doesn't have some internal booby traps to prevent this
23:44goonieb: gnarface: it is pure nvidia limitations for sure for amd
23:44gnarface: the problem is if nouveau already has the framebuffer, even though nvidia's driver didn't plan on doing anything useful with it, it will still choke and fail to load
23:44goonieb: gnarface: no precedence to play with?
23:45gnarface: i guess i haven't tested it extensively
23:45goonieb: goonieb: Interested in reading about this
23:45gnarface: the basic experience i had was that whichever driver gets loaded first blocks the other one
23:45goonieb: gnarface: me too, then I switched to iGPU
23:46gnarface: blocks harmfully, as in if you don't blacklist it, problems could occur
23:46gnarface: though the problems themselves may not be uniform across versions or cards
23:46goonieb: thinking somebody will work it ouyt someday, somehow
23:47gnarface: with just one-card systems anyway, i've had weird issues just trying to switch drivers without reboot, suggesting the official driver can leave the hardware in a bad state
23:48gnarface: (their official documentation actually at least used to says you have to fully power the computer down and do a cold boot to even upgrade between official versions)
23:48gnarface: (though i haven't tested that extensively either, i did also discover it the hard way)
23:49gnarface: yea, so anyway, it might be doable in theory, but to have any chance of being reliable it also has to be done at boot time without unloading a driver from either card
23:50gnarface: that's where i gave up on trying
23:50goonieb: gnarface: same here
23:50gnarface: but other people here probably know relevant tricks that i didn't
23:51goonieb: ;) it would be awesome to hear it out
23:51gnarface: well, there might be a way to disable the nouveau framebuffer access now, but i don't think it's as simple as just disabling KVM
23:51gnarface: KMS i mean
23:52gnarface: if you disable KMS i think nouveau still grabs the framebuffer, it just doesn't change the fonts
23:52gnarface: but i could be wrong about that
23:53gnarface: nvidia's proprietary drivers don't work with KMS anyway
23:53karolherbst: gnarface: it does
23:53gnarface: really? since when?
23:54karolherbst: since a long time
23:54karolherbst: you have to enable it though
23:54gnarface: oh, i remember, we had this discussion and it was early last year or something
23:54gnarface: i still haven't tried it though
23:54karolherbst: it works quite nicely
23:54karolherbst: at least plymouth is able to display stuff on all attached displays :D
23:54gnarface: hmm. i wonder what the chances would be of that helping it share nicely with nouveau?