05:56 hno: skeggsb, thanks. Found it already and just about to reboot to test.
06:25 hno: skeggsb, thanks. That fixed the bootup issues at least, mostly. There is some strange screen flickering during login screen but it no longer hangs.
06:26 hno: and clock scaling seems broken. "CLK][0000:01:00.0] failed to raise voltage: -22".
06:28 hno: lets see if suspend works, or if it still fails with "failed to idle channel".
06:30 hno: Yay! It surived suspend! Where do I send a cake to celebrate?
06:35 hno: Almost... seems it hang in some very power hungry state on second resume. Network came up, but not screen and fan quickly entered turbo-jet mode. Didn't know the fan could run that fast.
08:38 AnAkkk: imirkin: have you been able to make any progress with reclocking on nv50? :)
08:38 imirkin: no, nor have i tried.
08:39 imirkin: i think roy was playing with it, but he ran out of hardware -- works on everything he has
08:39 AnAkkk: ok :(
08:39 imirkin: what gpu do you have?
08:40 AnAkkk: 8800GT
08:41 imirkin: i'm looking for Gxx
08:41 imirkin: or GTxxx
08:42 AnAkkk: I need it, can't really send it, sorry :/
08:42 imirkin: (lspci should tell you)
08:42 AnAkkk: mine is a G92
08:43 imirkin: ok. that's what i meant by "looking for" :)
08:43 imirkin: 8800GT is pretty meaningless to me
08:43 AnAkkk: ah ok ;)
08:44 imirkin: reclocking should have mostly worked on that gpu with linux 3.12
08:44 AnAkkk: yeah, more or less, if you remember, it killed my screen :D
08:44 imirkin: oh, and we recently worked out (or remembered?) about changing pcie speed, so if you have a PCIe 2.0, i can help you get the speed up
08:44 AnAkkk: I had some quite bad flicker and after a will it died
08:44 imirkin: ok yeah, that's consistent with reclock fail ;)
08:44 AnAkkk: a while*
08:45 AnAkkk: ah, isn't it on the max speed by default?
08:45 imirkin: apparently not =/
08:46 AnAkkk: is there a patch for this?
08:46 imirkin: no, but i can guide you through the nvapeek/poke commands to get it done...
08:46 AnAkkk: ok, do I need to use the proprietary nvidia driver for this?
08:46 imirkin: nope
08:47 imirkin: you do need envytools though, which has those commands :)
08:47 AnAkkk: right, do I need to switch to nouveau then? or will the result be the same?
08:47 imirkin: oh, well if you're on the blob, it will upgrade the speed automatically
08:47 imirkin: this is only if you're using nouveau
08:48 imirkin: which leaves it at the default
08:48 AnAkkk: sure, I mean, to give you useful info (I guess that's what you meant?)
08:48 imirkin: no
08:48 imirkin: we have all the relevant info
08:48 imirkin: just to make it run faster on nouveau for you. if you're using the blob anyways, then wtvr
08:49 AnAkkk: ah ok
08:49 AnAkkk: apparently my PCI link speed is 2.5x
08:49 imirkin: 2.5GT/s
08:49 AnAkkk: (with the blob)
08:49 imirkin: that means you must have a PCIe 1.0 motherboard
08:50 AnAkkk: ah ok, nevermind then
08:50 imirkin: or the blob, for some reason, decided not to switch to the higher speed
08:50 imirkin: perhaps it does this at the lower power levels
08:54 AnAkkk: there's only one performance level if that's what you're talking about
08:55 AnAkkk: but it does say "PCIe Generation: Gen1"
08:55 imirkin: ah ok
08:55 AnAkkk: btw, I think this it out of date https://wiki.freedesktop.org/nouveau/FeatureMatrix/ - for tessellation for example :)
08:57 imirkin: oh yeah, good point
08:58 imirkin: otoh should probably nuke it and replace with like GL version
08:58 imirkin: those things never meant much
08:58 RSpliet: they are kind of arbitrary, aren't they
08:59 RSpliet: Perhaps the codenames on the top are not very informative and require updating too?
08:59 imirkin: RSpliet: we need to figure out how to get a truckload of G8x/G9x gpu's at your door...
08:59 RSpliet: Yes
08:59 RSpliet: and/or fermis
09:00 imirkin: the G8x/G9x's are probably on the order of $10-20 on ebay
09:00 imirkin: so... $500 should more than cover it
09:00 imirkin: yes?
09:00 RSpliet: I guess, but in the near future I probably have no money to spare
09:01 imirkin: sure, i'm just trying to get a handle on the amounts required
09:02 RSpliet: gnurou: could you try and find out whether there still is a pile of old cards at your St. Johns innovation park site?
09:03 RSpliet: oh... no gnurou
09:04 imirkin: bleh, wiki editing seems broken
09:57 paulk_: hi there
09:58 paulk_: does nouveau rely in any way on the video bios like radeon does?
09:58 mlankhorst: yes
09:58 paulk_: ouch, really?
09:58 paulk_: is it not usable without it?
09:58 imirkin_: paulk_: in much the same way
09:58 paulk_: mhh that's rather sad
09:58 mlankhorst: why?
09:58 imirkin_: paulk_: there's no way to obtain the information without the vbios
09:58 paulk_: because it's non-free
09:59 mlankhorst: it encodes a whole chunk of hardware specific crap
09:59 imirkin_: different boards are different... vbios describes how things are hooked up
09:59 mlankhorst: it's not meant to be modified..
09:59 paulk_: well, is it code or just some hw description?
09:59 mlankhorst: both
09:59 mlankhorst: it contains the sequence to power on the hw during resume
09:59 imirkin_: there is also "code" in that it's a list of instructions that nouveau has an interpreter for
10:00 imirkin_: (and it also has 16-bit x86 code in its option rom that is run on boot so that your bios can display things on the screen, but nouveau doesn't touch that)
10:00 paulk_: well, is it an instruction set?
10:00 mlankhorst: in a way
10:00 imirkin_: sort of. it's probably turing-complete.
10:00 mlankhorst: yeah it is..
10:00 paulk_: mhh
10:00 paulk_: so that's something that could be replaced, right?
10:00 mlankhorst: conditionals branching and memory poking/reading, ought to be enough..
10:01 imirkin_: not by people who aren't the board manufacturer
10:01 imirkin_: each board has a diff sequence of junk
10:01 paulk_: well of course, but at least we'd know what's in there…
10:01 imirkin_: yeah, it's easier to make it definitely not work ;)
10:02 paulk_: mhh
10:02 imirkin_: removes any sort of doubt
10:03 imirkin_: paulk_: what's your concern?
10:04 imirkin_: paulk_: how would you feel about hardware whose docs said "you must run exactly this sequence of operations if it's going to work"?
10:05 paulk_: still I'm not very happy with nouveau executing code pre-installed on the card…
10:05 paulk: mhh, got disconnected, sorry
10:06 paulk: and I cannot scroll up, goddamit
10:06 imirkin_: would you be happy if the card came with documentation saying "you must execute this sequence of instructions to init the card"?
10:06 paulk: that would be a blob in the litterature
10:06 paulk: I get that we have to do that sometimes when writing drivers
10:06 paulk: but at least let it be written by us
10:06 imirkin_: the vbios is precisely that documentation.
10:06 paulk: I understand
10:07 imirkin_: nouveau supports you loading your own vbios instead of reading the on-card one
10:07 imirkin_: should you want to rewrite the one on your card
10:07 paulk: okay
10:07 imirkin_: the instructions are all pretty simple, the "programs" are readable
10:07 imirkin_: even though it's a turing-complete "language", that doesn't mean they solve traveling salesman in it :)
10:07 paulk: well, at least, if I get rid of the bios that is executed by the BIOS (or don't run it at all in the BIOS), should I expect nouveau to be hapy with it?
10:08 paulk: of the blob executed by the bios*
10:08 imirkin_: nouveau doesn't execute anything on init usually since the vbios will be executed on boot
10:08 imirkin_: however it has to reinit the card on resume
10:08 paulk: what if it's not?
10:08 paulk: oh
10:08 imirkin_: well, the init sequence has to be done one way or another
10:08 imirkin_: otherwise the thing don't work
10:09 imirkin_: the init sequence is different for every board
10:09 paulk: so I gather that the code executed in the bios does card setup + VBE setup?
10:09 imirkin_: happy to hear alternate proposals for dealing with this situation.
10:09 paulk: my question is, what if I skip VBE setup?
10:09 imirkin_: then the card's not initialized
10:09 paulk: can nouveau handle it when the module is probed?
10:09 imirkin_: and most likely won't work until it is.
10:10 paulk: if not, is it easy to make it do it?
10:10 imirkin_: sure. it just executes the init scripts from the vbios.
10:10 mjg59: There used to be a module parameter to tell it to rePOST the card
10:10 mjg59: But that appears to have gone
10:10 imirkin_: mjg59: yeah, still is.
10:10 imirkin_: mjg59: nouveau.config=NvForcePost=1
10:10 paulk: ok nice
10:10 mjg59: Oh, ok, it's in config now
10:10 mjg59: That's why I can't find it in modinfo
10:10 imirkin_: mjg59: http://nouveau.freedesktop.org/wiki/KernelModuleParameters/
10:10 mjg59: Yeah
10:10 imirkin_: i've outlined the various bits there
10:11 paulk: so that's only the part that reads the pm init script, right?
10:11 mjg59: I guess it ought to be possible to check some register state to get a good idea of whether the card's been initialised and then force a POST automatically
10:11 paulk: it doesn't need the x86 code that sets up a framebuffer, does it?
10:11 imirkin_: paulk: no, also stuff can get executed on modeset
10:11 imirkin_: paulk: nouveau never executes x86 code that sits on the card
10:11 paulk: good
10:11 imirkin_: that only ever happens when the BIOS executes the option rom
10:12 paulk: but is it somewhat needed by nouveau?
10:12 mjg59: No
10:12 imirkin_: mjg59: yep, we do that.
10:12 paulk: if it's not executed by the BIOS
10:12 RSpliet: maybe a bit nitpicky, but POST isn't really the right term for something that does more than power-on self-test is it?
10:12 imirkin_: paulk: nope.
10:12 paulk: so nouveau doesn't rely on VBE at all, correct?
10:12 mjg59: RSpliet: It's not, but it's been the term we've used forever
10:12 mjg59: paulk: Correct
10:12 paulk: only on the script that is found on the PCI address space
10:12 paulk: good
10:12 imirkin_: paulk: dunno if PCI address space is the right term, but novueau looks in several places for it.
10:13 paulk: well, either way
10:13 imirkin_: it'll be in PROM or ACPI for modern machines (or in VRAM if the card's been posted already)
10:13 paulk: ACPI suggests it's taking it from the BIOS then, right?
10:14 imirkin_: paulk: ACPI is platform data
10:14 mjg59: It may be embedded in the system BIOS rather than a separate image on the card, yes
10:14 imirkin_: you'll see it there on laptops
10:14 paulk: ah yes, for laptops, sure
10:14 paulk: they usually don't have an eeprom attached behind the pci
10:14 paulk: where the GPU is
10:14 imirkin_: exactly
10:15 paulk: but I expect that actual cards do
10:15 imirkin_: no point in doing that since you aren't likely to unsolder the gpu and stick a diff one in.
10:15 paulk: of course
10:15 paulk: I'm familiar with that from the coreboot side
10:15 imirkin_: and if you do, you can handle such trivialities as supplying a diff acpi blob :)
10:15 paulk: ok
10:16 imirkin_: the no-bios-init thing is very similar to the secondary gpu situation
10:16 mjg59: paulk: The scripts that nouveau executes would probably allow you to do bad things to the host OS if they're malicious
10:16 imirkin_: bios usually doesn't init the second gpu, so nouveau has to handle that itself
10:16 imirkin_: mjg59: what did you have in mind?
10:16 hno: probablh no where as bad things as ACPI thou..
10:17 imirkin_: mjg59: they only let you write to pci registers
10:17 imirkin_: er, mmio registers
10:17 paulk: imirkin_: good point
10:17 imirkin_: and execute high level commands like "set pll" or whatever
10:17 imirkin_: there are a few "indirect" opcodes, but those will only ever read from within the vbios
10:18 paulk: either way, since it's a script, you could sandbox it
10:18 paulk: restrict the I/O space, etc
10:18 imirkin_: that's what the nouveau interpreter does :)
10:18 paulk: nice
10:18 mjg59: imirkin_: Can you hit arbitrary mmio registers or just the ones that the high-level commands provide?
10:18 imirkin_: mjg59: arbitrary
10:18 imirkin_: mjg59: you could def write to vram
10:19 mjg59: imirkin_: Anything other than iommu stopping you from setting up a DMA transaction?
10:19 imirkin_: i guess you could get the card to write to sysram if you don't have an iommu
10:19 mjg59: Right
10:19 mjg59: Most distributions still don't enable the iommu by default :(
10:19 imirkin_: it'd be tricky... dunno if that vbios would fit in the 64k
10:19 imirkin_: the isa isn't exactly optimised for that use-case
10:20 imirkin_: mjg59: why don't distros enable iommu??
10:20 paulk: mjg59: so arbitrary registers, within the GPU I/O space or virtually any address for the host?
10:21 imirkin_: paulk: well, the gpu can write to the host. if you control the gpu, you could presumably get it to do that.
10:21 paulk: (well, virtually is poorly chosen in this context)
10:21 paulk: imirkin_: but that "script" is interpreted by the host (nouveau), not by the GPU, right?
10:21 imirkin_: paulk: yes, but that script could tell the gpu to do things
10:22 paulk: oh I see
10:22 imirkin_: good thing that nvidia is signing all these things now
10:22 paulk: so it could e.g. tell the GPU to setup a DMA request by writing to its mmio space directly?
10:22 imirkin_: *that*'ll solve every problem
10:22 imirkin_: paulk: yes
10:22 paulk: imirkin_: are you being sarcastic?
10:22 mjg59: imirkin_: Still bugs on some hardware
10:23 imirkin_: i'm def serious that nvidia is signing things and the hw refuses to load unsigned things starting with GM20x
10:23 paulk: well I know they're doing it
10:23 paulk: I'm just surprised you think it's good…
10:23 imirkin_: that bit was sarcastic.
10:23 paulk: good then :)
10:23 paulk: we're on the same page
10:23 imirkin_: but it resolves your issue nicely
10:24 imirkin_: of "what if someone makes a malicious vbios"
10:24 paulk: well I don't care so much about that
10:24 paulk: I know many people do
10:24 paulk: but really, I want to be in control of my computing
10:24 paulk: and not rely on proprietary stuff
10:24 imirkin_: yeah... sadly things got too complicated and too varied for that =/
10:25 imirkin_: complicated --> every stupid little thing has a cpu now
10:25 paulk: yeah
10:25 imirkin_: which also means it has code running on it
10:25 paulk: well, hopefully we can motivate people to work on that :)
10:25 paulk: I'm starting to free my laptop's EC
10:25 paulk: (not the one I'm typing on right now, that one's already free)
10:26 paulk: and actually, I'm pretty sure every single piece of code on this one is already free
10:28 Karlton: if you can't replace the vbios wouldn't it make it more possible to be malicious?
10:28 paulk: Karlton: if you ask nvidia about binaries signed by nvidia, they'll say no
10:28 imirkin_: just coz it's signed doesn't mean you can't read it
10:29 imirkin_: they're just signed, not encrypted
10:31 Karlton: ah, so it isn't as bad as intel then
10:32 Karlton: they actually encrypt it
10:58 paulk: Karlton: wait, that's about firmwares running on Intel GPUs?
10:59 imirkin_: everything needs firmware now
10:59 imirkin_: i'm sure your mechanical watch has firmware by now
10:59 paulk: hehe
11:00 paulk: Still, I'm interested in details about intel
11:50 paulk: so do you think it's be doable to implement native graphics init (read, only seting up a framebuffer) in Coreboot?
11:51 paulk: Something that would use the "script" we talked about earlier
11:51 paulk: for nvidia cards
11:51 paulk: that way we could have a fully free graphics path, from startup to linux
11:51 imirkin_: sure, just do what nouveau does
11:51 paulk: how big would you expect something like that to be?
11:52 imirkin_: it'd be a considerably large project... getting screens up and running is surprisingly difficult in a generic fashion
11:52 paulk: ah I see
11:52 imirkin_: coz of stupid DP, etc
11:52 imirkin_: not to mention MST when that becomes supported
11:52 paulk: mhh
11:52 paulk: well, if we stick to the "easy" ones
11:52 paulk: how hard is crtc?
11:53 imirkin_: errr
11:53 imirkin_: huh?
11:53 imirkin_: VGA and TMDS are generally pretty easy
11:53 paulk: ok
11:53 imirkin_: (that's DVI/HDMI)
11:53 paulk: ok
11:53 paulk: right, I read some code for those for some display controllers found on ARM SoCs, didn't seem too big
11:53 imirkin_: but it's still a pretty big project
11:54 imirkin_: nv50+ takes a command stream, so you have to set up a ring/etc. i think you can avoid setting up a MM though
11:54 paulk: awww, this much…
11:54 paulk: it sucks
11:54 imirkin_: and all the joy that comes with that
11:54 imirkin_: well, on the bright side you have nouveau to copy from :)
11:55 paulk: what I'm used to is hardware framebuffer, where you just give the controller some address and it does its own thing
11:55 imirkin_: the "nvkm" bits of it are pretty untied to linux
11:55 imirkin_: so it shouldn't be too hard to export them to a diff project
11:55 paulk: oh
11:55 paulk: well that could work
11:55 paulk: no need to start from scratch if it's too big indeed
12:09 mupuf: cool to see paulk here :)
12:12 imirkin_: who is he? coreboot guy?
12:19 mupuf: imirkin_: replicant
12:20 mupuf: student I met in Bordeaux. He reimplements bootloaders
12:20 mupuf: I helped him debug an i2c issue on one board with my osciloscope
12:21 Yoshimo: replicant is a great idea, but very slow progress keeps it from being usefull
12:21 imirkin_: mupuf: ah cool. too bad replicant won't work on qualcomm stuff... otherwise it'd be a nice fit for freedreno
12:21 mupuf: http://www.replicant.us/ <-- he is the paul K who keeps on posting
12:23 Yoshimo: well lima is also there
12:23 imirkin_: got it
12:23 imirkin_: lima doesn't exist
12:23 imirkin_: freedreno does
12:41 karolherbst: does replicant add something special to make it possible to have more privacy?
12:42 imirkin_: karolherbst: oh, if you're up for it, could use a mmt trace for 'bin/varying-packing-simple float separate -auto'
12:42 imirkin_: i can't figure out how to get the last 4 fp inputs to work =/
12:42 karolherbst: I mean not in a way as not including stuff, but making the core more "robust" against attacks
12:43 karolherbst: ohh replicant is basically Cyanogenmod with just missing stuff :/
12:43 karolherbst: imirkin_: yeah no priblems
12:43 karolherbst: *problem
12:44 karolherbst: Yoshimo: do you know this java API intercept thing for android?
12:45 karolherbst: where you can intercept every call to the system API and just return fake data for like everything?
12:45 Yoshimo: no
12:45 karolherbst: don't remember the name though :/
12:45 Yoshimo: xposed?
12:45 karolherbst: yeah
12:46 karolherbst: its based on it
12:46 karolherbst: doesn't work with ART though :/
12:46 karolherbst: XPrivacy it was
12:47 karolherbst: you can configure it like it will always prompt for new applications for new API calls and decide everytime
12:47 karolherbst: its pretty verbose if you want it to be
12:48 karolherbst: but if you install stuff like that and for example adaway you really notice how crappy most of the apps are developed :D
12:48 karolherbst: like they assume everything works and will just eat everything
12:50 karolherbst: there are even apps/games which give you bonus for watching adds, even if there is none at all
12:51 karolherbst: how well is a nouveau + nvidia blob installation supported across distributions in general?
12:52 imirkin_: afaik gentoo is the only semi-reasonable one
12:53 karolherbst: I know that debian based ones sometimes messes up the alternatives
12:53 mlankhorst: ubuntu uses alternatives, but that usually requires regenerating initramfs
12:53 karolherbst: or you have to blacklist very new nvidia releases with their version numbers
12:53 karolherbst: really?
12:53 karolherbst: I thought that works without it
12:53 karolherbst: alternative is only for the libGL stuff, isn't it?
12:54 karolherbst: imirkin_: http://www.filebin.ca/2ARqB9Lb9ufB/varying-packing-simple_float_separate.mmt.xz
12:55 imirkin_: yay, and thanks for giving it a good filename ;)
12:55 karolherbst: :D
12:56 imirkin_: whaaaa
12:57 karolherbst: imirkin_: anything you didn't expect?
12:57 imirkin_: yeah
12:57 imirkin_: the shader header is confusing.
12:57 karolherbst: I am on the new module now if that makes a difference
12:57 imirkin_: btw, this goes without saying, but i assume it passes?
12:58 karolherbst: yeah
12:58 karolherbst: it does
12:58 karolherbst: newest piglit
12:58 imirkin_: k, just checking :)
12:58 karolherbst: ahh the vernum is in the trace, okay, didn't know that, allthough it would have been save to assume it
12:59 imirkin_: 0x2a2a2a2a INPUT_EN_8 = 0x2a2a2a2a
12:59 imirkin_: why is it 0x2a
12:59 imirkin_: why isn't it 0xaaaaaaaa :(
12:59 karolherbst: I could write a script to create these traces automatically and uplaod them
12:59 imirkin_: although i'm going to go ahead and guess it has *something* to do with it working
12:59 karolherbst: :)
12:59 karolherbst: :D
13:00 imirkin_: karolherbst: can you also do 'int' instead of float?
13:00 imirkin_: want to see if it's any different with constant vs smooth
13:01 karolherbst: yeah, wait, will try out the script then :D
13:02 imirkin_: wtf. it looks like it skips the .w's of the last bunch of vectors
13:12 imirkin_: wait wtf
13:12 imirkin_: it looks like nvidia also only did 124 components
13:12 imirkin_: not 128
13:12 imirkin_: it just laid them out slightly differently
13:13 imirkin_: karolherbst: sorry. you're all good. ignore me.
13:13 imirkin_: i managed to confuse myself
13:14 karolherbst: :(
13:14 karolherbst: now the script is working
13:14 imirkin_: it'll come in useful next time ;)
13:15 karolherbst: mmt_run_upload varying-packing-simple_int_separate.mmt "bin/varying-packing-simple int separate -auto"
13:15 karolherbst: prints the url for download :)
13:15 imirkin_: hehehe
13:15 imirkin_: i might have a patch to a piglit test
13:15 imirkin_: hold on
13:15 karolherbst: also starts the second X server and everything
13:17 imirkin_: karolherbst: http://hastebin.com/raquhuwino.md
13:17 imirkin_: does the blob still pass with that? if so, would love a trace
13:17 imirkin_: i assume it doesn't
13:17 karolherbst: sometimes my laptop just kills power with no reason, actually i doesn't handly keyboard eventy anymore, and 2 or 3 seconds later power off
13:18 imirkin_: (do it with 'int', not 'float', for variety)
13:19 karolherbst: same binary, but int?
13:19 imirkin_: yeah
13:19 imirkin_: but apply that patch and rebuild
13:19 karolherbst: yeah, fails
13:19 imirkin_: yeah ok
13:19 karolherbst: "line 275, column 1: error: too many result variable components written"
13:19 karolherbst: do you still want the trace?
13:20 imirkin_: nope
13:20 karolherbst: maybe I get the script to also write into IRC :D
13:21 karolherbst: but then I have to be really lazy and motivated enough how to actually do it clean
13:21 karolherbst: don't want to print the entire error output
13:22 imirkin_: hehe
13:35 karolherbst: imirkin_: what do you think about the idea of having two init and fini functions for debugfs? one for the drm stuff and one for the non drm stuff
13:35 karolherbst: currently I do something like that and find it kind of unclean: https://github.com/karolherbst/nouveau/commit/e1bcbf1ada6c08228b009976ea8da7abb81d36d8
13:55 karolherbst: stupid modem :/
13:57 imirkin_: karolherbst: why can't you do that stuff in nouveau_debugfs_init?
13:57 imirkin_: just pass drm into it and you're set, right?
13:58 karolherbst: no
13:58 karolherbst: its called before load by drm itself
13:58 imirkin_: why
13:58 karolherbst: its actually called right before open, while doig the drm_minor stuff
13:58 imirkin_: er let me rephrase
13:59 imirkin_: create a nouveau_debugfs_init which does that stuff
13:59 imirkin_: and keep the other one too
13:59 imirkin_: the two are doing diff things, i guess
13:59 imirkin_: one thing is about creating files
13:59 imirkin_: the other is about having a ctrl object
13:59 imirkin_: if you don't have a ctrl object, just return EINVAL or something
14:00 karolherbst: yeah, the other one we could call inside open or after it or just like the sysfs thing
14:00 karolherbst: that was my idea. The drm debugfs thing is kind of called pretty early
14:00 karolherbst: so there is not much ready yet
14:02 imirkin_: or perhaps move the drm debugfs init down... not sure if that'd be ok
14:05 karolherbst1: meh
14:06 karolherbst1: imirkin_: the debugfs stuff is called within drm_dev_register through drm_minor_register
14:06 karolherbst1: don't know if there can be much done :/
14:07 imirkin_: ah ok
14:08 imirkin_: so yeah, just have a separate debugfs init thing for when the device is there
15:27 karolherbst: imirkin_: any pointers how I could debug this metro memory issue? I am not that well with how drm works and how OpenGL works :)
17:18 carajean: Hey need help on something. I was trying to switch between nouveau to nvidia rebooted now I can tget back in
17:18 carajean: Stuck at boot
17:21 specing: nvidia replaces the graphics libraries
17:22 specing: how did you install it?
17:39 carajean: I installed it like the wiki said
17:40 carajean: Basically I followed the Installation part in the wiki to a T
17:40 carajean: pacman -S nvidia
17:40 carajean: pacman -S nvidia-libgl
17:40 specing: does Arch have a way to manage those libraries?
17:40 specing: Gentoo has 'eselect opengl'
17:40 carajean: Got me. New to arch
17:41 specing: I did use Arch with NVidia, but that was 7 years ago
17:42 carajean: My issue now is when i go to nvidia-setting I get " Unable to init server: Could not connect: Connection refused. ERROR: The control display is undefined please run nvidia-setting --help
17:42 skeggsb: carajean: this is #nouveau, not #nvidia
17:43 carajean: Well #archlinux point me over here
17:43 carajean: I guess I will go over to "nvidia now
17:43 Karlton: nvidia-setting is unique to nvidia blob
17:43 Karlton: not nouveau
17:45 carajean: Yeah its what I need to game though.... At least for the couple games I do play