00:14jcadduono: imirkin yeah unfortunately i purchased a new screen for my laptop but nvidia's drivers refuse to allow it to turn on when they load because the EDID doesn't match the GPU whitelist, I would much rather modify the panel's EDID than the GTX 1080's vBIOS
00:15jcadduono: and nvidia drivers validate EDID directly with panel and will bypass whatever other methods are used, and nouveaufb does not appear to support GTX 1080 yet
00:20gnarface: i can't believe they actually bothered to add a bios whitelist for the builtin display panels
00:20gnarface: that's gotta be some sort of violation of anti-trust law
00:20gnarface: what about the right to repair?
00:20jcadduono: i think they did it because of g-sync
00:21gnarface: i'm gonna stick with my "what a bunch of douchebags" explanation
00:21gnarface: they'll get sued about this eventually, some day, and the government will make it illegal explicitly enough for people to stop being able to pretend otherwise
00:29jcadduono: i bought an spi/eeprom flasher just in case but upon disassembling the panel i can't find a single eeprom chip, so confuse
00:31gnarface: i think they could have hidden it anywhere
00:32gnarface: i think you can hide eeproms right inside the processor now
00:33gnarface: but also i think laptops usually have some sort of separate driver board between the video card and the display itself, not actually inside the panel housing
00:33gnarface: i don't think there's any particular reason they couldn't have just hidden it in the system bios or the video bios though, as you earlier suggested
00:36jcadduono: well the panel comes attached to a t-con board with an eDP input, and i can actually boot up with the stock panel allowing nvidia drivers to load, then put laptop in sleep mode and switch the panel around then come out of sleep mode and it works flawlessly :)
00:37jcadduono: t'was how i grabbed the EDID from it and fixed it up to pass the whitelist check, but i have not found a way to flash it yet
00:39jcadduono: the EDID must be stored on the t-con board somewhere, but all the chips are super tiny to the point i can neither desolder them nor attach chip clips to them, none of them actually have eeprom models written on them either
00:39gnarface: very interesting
00:39gnarface: so maybe it is doing it from the mainboard bios?
00:40jcadduono: whitelist is 100% in the vBIOS for the nvidia drivers to read
00:40gnarface: just speculating here, but it seems like very interesting evidence that the check only happens at POST and then you can hot-swap afterwards to trick it
00:40jcadduono: it does not happen at POST
00:40jcadduono: it happens when loading geforce driver kernel module
00:40gnarface: wait, it happens after that?
00:41jcadduono: i can use the panel perfectly fine in uefi bios and with vesa/efifb drivers
00:41gnarface: so you get a POST screen with the new panel attached, you see it boot, then when the OS loads the nvidia drivers, THEN it shuts it off?
00:41gnarface: man i'd be so pissed off
00:41jcadduono: ya, like i said, nvidia drivers say no thank you
00:41gnarface: like, i didn't even spend money on it and i'm a bit angry about it
00:44jcadduono: i see the t-con board actually has gold contacts in an area labeled GND DATA CLK, (no VCC) i wonder if that is an i2c connection for use when panel is online
00:44gnarface: still, you'd think they'd have left a way to tack new devices onto the list without flashing the vbios though
00:45gnarface: maybe i'm wrong though, maybe it's just my usual inability to fully anticipate the capacity for stupidity to self-organize into a sustainable pattern
01:22imirkin: jcadduono: GTX 1080 should be supported just fine...
01:22gnarface: imirkin: he's trying to replace the stock laptop LCD display panel with an aftermarket one and running into compatibility issues
01:23imirkin: eDP is finicky - i think not all displays have an EDID built into them
01:23gnarface: oh, well that would definitely hamper overwriting it...
01:23imirkin: either way, with nouveau, shouldn't matter -- just force an edid via drm.edid or whatever
01:23imirkin: (i forget how that works, but it definitely does work somehow)
01:23jcadduono: huh ok, what's the trick, i'm on linux 4.13.9 w/ 4.14-r6 but i cant boot unless i do nouveau.modeset=0
01:24imirkin: try booting without that and grab a dmesg to see what went wrong
01:24jcadduono: alright, i wonder if pstore works, i dunno how else to grab a dmesg of that
01:25jcadduono: as it does freeze the entire computer
01:35jcadduono: would you like dmesg from 4.13.9 or 4.14-rc6
01:36imirkin: ssh in
01:36imirkin: or netconsole
01:37imirkin: either dmesg is fine, i don't remember any GP102-specific fixes
01:38jcadduono: how do i ssh in before nouveau loads
01:38imirkin: (a) blacklist nouveau from loading, ssh in, and load nouveau
01:38imirkin: (b) perhaps it's not as frozen as you think
01:53jcadduono: hey, blacklisting then modprobe after network services come online worked!
01:53jcadduono: [ 118.081327] nouveau 0000:01:00.0: Direct firmware load for nvidia/gp104/gr/sw_nonctx.bin failed with error -2
01:54jcadduono: i guess i was just missing firmware
01:57jcadduono: and all is working...i feel like an idiot
01:58skeggsb: don't feel like one, it's not supposed to fail in that way even if you don't have fw :)
01:58skeggsb: not sure when it broke, but i'll fix it before i sent a pull request
02:08jcadduono: omg it works i can r/w edid over i2c with nouveau!
02:08jcadduono: something official nvidia driver cant even do yet with pascal
02:30gnarface: honestly if it's that simple, can't you even just plug the EDID file into your Xorg.conf?
02:30gnarface: i thought there was a mechanism for that, for displays that report the wrong EDID
02:31imirkin: yeah, plenty, at least in open-source land. dunno about nvidia blob. although it normally doesn't care until X loads
02:31imirkin: i guess they have some kind of kms thing nowadays too? dunno
02:46jcadduono: nvidia reads directly from the monitor
02:47jcadduono: blacklist will still trigger, tried that
03:01ylwghst: jcadduono: is possible to exit X11 back to tty with nvidiaLegacy340 on efi machine?
03:01jcadduono: i dont have any idea
04:18jcadduono: hmm weirdest thing with this panel, so i discovered the EDID at usual address 0x50, tried to write to it, nothing changed, assume it is write protected....then found EDID again at 0x65, write to it, it changed! read 0x50 and it now has the new EDID value, so ok that worked....until the panel is unplugged or powered off, now it is back to original value :(
04:23airlied: jcadduono: a lot of eDP read it into RAM
04:23airlied: even actually older VGA monitors sometimes did it
04:33jcadduono: theres probably a wire in the edp cable i can short to disable eeprom write protection if only i had a manufacturer specs sheet
04:37jcadduono: probably 3.3v to pin 24 <___<
04:58jcadduono: ok nevermind 34,35,40 in 4-lane EDP are labeled NC-reserved so for oem use, 39 is backlight power, could be short 39 to 40 which sounds like a simple job :o
21:22pounce: Hello when booting up I get a bus: MMIO read fault (relavant lines: https://gist.github.com/4e554c4c/c43a9262135c3234712c10f2283572cc ) Should I report a bug?
22:46RSpliet: karolherbst: do you have a little step-by-step guide on how to run a steam game on an optimus machine with the dedicated GPU using custom mesa? Which env variables do I pass where to?
23:16karolherbst: RSpliet: you know that field in steam to pass custom flags and such?
23:17karolherbst: this is basically a exec() call, you can do whatever there.
23:17karolherbst: just keep in mind to invoke the game binary through %command%
23:17karolherbst: I do stuff like this: DRI_PRIME=1 run_local_mesa %command%
23:18karolherbst: and run_local_mesa is simply a script to adjust LIBGL_DRIVERS_PATH and LD_LIBRARY_PATH
23:20gnarface: i'd like to add that if you can't figure out what's happening in there, redirects work too: DRI_PRIME=1 run_local_mesa %command% > ~/tmp_Steam_log.tmp.log 2>&1
23:20gnarface: (sometimes it's the only way to catch certain errors)
23:21gnarface: probably also worth mentioning too that there's a handful of games that at least used to have a bug where it wouldn't smartly launch the 64-bit version of the game unless you used something like %command_x86_64% or something like that
23:21gnarface: maybe it was just %command_64%
23:22gnarface: i think they fixed it on KSP but i don't know if it still affects others
23:28RSpliet: karolherbst: ah ok so I don't have to start steam itself with any flags. cool, cheers
23:28karolherbst: RSpliet: nope
23:28karolherbst: but a lot of steam games can also be started from the command line directly as well
23:28karolherbst: sometimes, the scripts invoke steam with a steam:// link
23:28karolherbst: which has to be disabled prior
23:29RSpliet: yeah, but often they use wrappers that reset your env vars or something similarly nasty
23:29karolherbst: steam steam://...
23:29karolherbst: but this can be disabled in the script
23:29RSpliet: run_local_mesa just sets env vars, or do you hack up something else in there?
23:29karolherbst: executing a steam link basically does IPC to the running steam insance
23:30karolherbst: RSpliet: just env vars
23:30RSpliet: and LD_LIBRARY_PATH is overriden to... point to system libdrm?
23:31karolherbst: internally in run_local_mesa I source another script to set the env like this:
23:31karolherbst: export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/home/karol/Dokumente/repos/mesa/build64/lib:/home/karol/Dokumente/repos/mesa/build32/lib"
23:31karolherbst: export LIBGL_DRIVERS_PATH="/home/karol/Dokumente/repos/mesa/build64/lib/gallium/:/home/karol/Dokumente/repos/mesa/build64/lib/:/home/karol/Dokumente/repos/mesa/build32/lib/gallium/:/home/karol/Dokumente/repos/mesa/build32/lib32/"
23:33RSpliet: k, hopefully I can just get away with pointing at my /usr/local/lib dir
23:38karolherbst: RSpliet: most games are 32bit ;)
23:41RSpliet: yeah, Fedora sticks 64-bit libs in /usr/[local/]lib64