01:07mupuf: imirkin: I also remember that the VMA adresses are 40 bits
01:28pmoreau: So, the EVO engine on the G96 works before the MCP79 is initialised, but not afterwards.
01:29pmoreau: Except if the G96 is PCI reset'ed.
01:45pmoreau: Grrrr... Using the G96 as the main card used to throw some "unable to handle kernel page request" from nv50_crtc_prepare after allocating the fb, but now it just hangs after allocating and doesn't throw any error... --"
06:42mlankhorst: are you sure you don't have memory corruption somewhere?
06:47pmoreau: Maybe. How should I find it?
06:48pmoreau: The "unable to handle kernel page request" is probably due to EVO returning some bogus data (like 1.10^9), and then evo_sync tries to access the element at that index in some table, which fails.
06:48mlankhorst: so validate the data and ignore it if it's out of range :P
06:49mlankhorst: there's kmemcheck for uninitialised stuff, Documentation/kmemcheck.txt
06:49pmoreau: I tried it on a similar issue, but I end up with an intr 0x00000002 on PMC
06:50pmoreau: And the kernel is unhappy about some interrupt not being cared of and kills the card
06:50mlankhorst: I guess slub_debug could be used too
06:51mlankhorst: see Documentation/vm/ stuff
06:54pmoreau: I'm not sure kmemcheck will be able to find if we missed some GPU initialisation. See http://cgit.freedesktop.org/~darktama/nouveau/tree/drm/nouveau/nv50_display.c#n420 which is the one failing
06:54mlankhorst: probably not
06:54pmoreau: with put = 1073741823
06:55mlankhorst: what happens if you force post?
06:55pmoreau: Same thing
06:59pmoreau: ... I can't reproduce the behaviour I experienced before (https://bugs.freedesktop.org/show_bug.cgi?id=86537)...
07:00pmoreau: My GPUs hate me :(
07:02mlankhorst: does the blob poke any magic reg before touching it ? :P
07:03pmoreau: The blob does a lot of black magic on both cards imho :D
07:03mlankhorst: > use SCIENCE on BLACK MAGIC
07:04pmoreau: I had some fun reproducing the blob operations for PDISPLAY but ended up with a display switching from bright yellow to completely white and still the paging error
07:04pmoreau: The effect was nice, but... Not quite what I wanted ;)
07:08mlankhorst: > use MORE SCIENCE on BLACK MAGIC
07:12mlankhorst: no suspicious writes to PFB or anything?
07:13pmoreau: They are all suspicious, and they are quite a lot.
07:14pmoreau: But I'll probably go back to that solution. It did pay really well in getting the MCP79 to work.
07:15pmoreau: Or maybe you have a really good definition of "suspicious write"s which could greatly reduce the number of writes to consider? O;-)
07:15mlankhorst: no idea tbh :P
07:16mlankhorst: hopefully near a place that disables the display engine in the master control
07:16pmoreau: I'll start by adding all missing PFB regs to envytools, and one day I'll wake up and someone from NVidia will have UNK'ed them. :-)
07:18pmoreau: Could be a good idea indeed, let me check
07:32pmoreau: It reads some PFB regs before disabling, but no writes. I found some new PDISPLAY and PNVIO writes before disabling on the G96. I could try those.
09:54pmoreau: Found a few PFB regs which generates some nice display patterns
09:55pmoreau: A bit surprised that changing them on the G96 has an effect on the screen which is linked to the MCP79
11:39alexandernst: I have 2 NVIDIA GT610 and 4 monitors. I want to use all 4 monitors so NVIDIA's binary driver is not an option. I tried nouveau and it seems that it covers my expectations. The prooblem is that I can't make X to use all 4 monitors (it's using only 2 currently). I'm no Arch and I have X 1.16.4 and xrandr 1.4.3
11:39alexandernst: The funny part is that I tried a LiveUSB of Fedora 21 and it managed to configure all my 4 monitors!
11:39alexandernst: And Fedora 21 is using X 1.16.1 and xrandr 1.4.3
11:40alexandernst: on both distros "xrandr --listproviders" returns both graphic cards
11:40RSpliet: alexandernst: if Fedora can do it, it's unlikely to be a nouveau bug
11:40alexandernst: What kind of magic is Fedora doing to make all my 4 monitors run?
11:41alexandernst: RSpliet: yes, I agree. What I'm asking is how can I make Arch do the same thing
11:41alexandernst: btw, Debian 8 isn't able to do that either
11:41RSpliet: alexandernst: well, technically this is the wrong channel to ask; it should work out of the box
11:42RSpliet: you might get lucky and bump into an arch user though ;-)
11:42RSpliet: also: check your kernel version, make sure you're on the latest greatest
11:42alexandernst: this is Arch :) Everything is the latest gratest
11:42RSpliet: and ditch your Xorg.conf; you shouldn't need one for nouveau
11:42alexandernst: I tried that
11:43buhman: O.o randr can do >1 gc now?
11:43alexandernst: I alsoo tried making Fedora 21 go in init3 and "X -configure" and then copying the conf to my Arch. Still nothing
11:43RSpliet: buhman: for a long time; how'd you think optimus works?
11:44RSpliet: alexandernst: Fedora isn't using an xorg.conf file, so that's not helping you
11:44buhman: RSpliet: black magic?
11:44RSpliet: for the record: please post your kernel log from arch
11:44alexandernst: yes, but I'm at a point I don't know how to beg Arch to do it, so I'm doing desperate things...
11:45alexandernst: full kernel log: https://paste.kde.org/pteqpl6ct/wq0mar
11:46RSpliet: nothing odd there; Xorg log?
11:46alexandernst: full Xorg log: https://paste.kde.org/pq9q8ecin
11:47alexandernst: this is with custom xorg.conf file
11:47alexandernst: xorg.conf file: https://paste.kde.org/pzpl1y8uy
11:48RSpliet: alexandernst: and when you get rid of the config files?
11:48alexandernst: same effect, only 2 monitors work
11:48RSpliet: same log?
11:48alexandernst: pretty much, yes
11:48RSpliet: (also: the ones in /usr/share/X11/xorg.conf.d ?)
11:49alexandernst: should I remove this?
11:49RSpliet: or move it such that it's not found any longer
11:49RSpliet: just in case you want to restore
11:49alexandernst: content is "Identifier 'nvidia' ... Driver 'nvidia'"...
11:49alexandernst: ok, let me try
11:53alexandernst: removed the nvidia file and xorg.conf
11:53alexandernst: dmesg: https://paste.kde.org/pph5wrhgw Xorg log https://paste.kde.org/planxxift
11:54alexandernst: (still only 2 monitors)
11:55RSpliet: ok, now play with xrandr to see if you can enable the other two?
11:55alexandernst: ok, but how?
11:55RSpliet: man xrandr
11:55alexandernst: --listproviders shows both GPUs, but I don't know what follows next
11:57RSpliet: sry, phone
12:10mlankhorst: xrandr --setprovideroutputsource or xrandr --setoffloadsink
12:13RSpliet: mlankhorst: is that required if he's not trying to set up optimus?
12:13mlankhorst: yeah :P
12:14alexandernst: I ran setprovideroutputsource 1 0 and now all 4 monitors show "something", problem is that the 3rd and the 4th show the same thing that is rendered on the 1st and the 2nd
12:14RSpliet: alexandernst: got a GUI to configure your monitors (Gnome has control centre, KDE has... something; XFCE something else :p)
12:14alexandernst: oh, no. Actually
12:15alexandernst: ast and 2nd work fine
12:15alexandernst: 3rd and 4th show the same thing
12:19alexandernst: --setprovideroutputsource 0 1 crashes my X
12:19mlankhorst: try symbolic names
12:19mlankhorst: what's the the output from xrandr --listproviders?
12:20alexandernst: Provider 0: id: 0xbe cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 2 outputs: 3 associated providers: 0 name:nouveau
12:20alexandernst: Provider 1: id: 0x64 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 2 outputs: 3 associated providers: 0 name:nouveau
12:20mlankhorst: setprovideroutputsource 0x64 0xbe
12:20mlankhorst: and setprovideroffloadsink
12:20mlankhorst: then xrandr --auto :P
12:21alexandernst: ok ok, but what exactly are those two commands doing?
12:22alexandernst: also, setprovideroffloadsink 0x64 0xbe too ?
12:22mlankhorst: they're the id's from the list
12:22mlankhorst: connect 1 to 0
12:23alexandernst: setprovideroutputsource ran fine, but xrandr --setprovideroffloadsink 0x64 0xbe
12:23alexandernst: X Error of failed request: BadValue (integer parameter out of range for operation)
12:27mlankhorst: setprovideroutputsource probably?
12:27mlankhorst: xorg-server allows some stupid combinations btw, do it the wrong way around and it crashes
12:28alexandernst: xrandr --setprovideroutputsource 0x64 0xbe <----- this runs fine and enables me to see all my 4 monitors in KDE's display manager. The thing is that if I enable 3rd and 4th monitor, the both show the same thing
12:29alexandernst: (and they're actually showing what is rendered on the 1st screen)
12:34alexandernst: mlankhorst: out of ideas?
12:35imirkin_: alexandernst: once you get into a state where all 4 monitors are displaying things, pastebin the output of 'xrandr -q'
12:39alexandernst: imirkin_: https://paste.kde.org/pysatlqem
12:40imirkin_: alexandernst: xrandr --output DVI-I-1-2 --left-of HDMI-1 --auto
12:42RSpliet: Screen 0: minimum 320 x 200, current 3840 x 1080, maximum 8192 x 8192
12:43RSpliet: how... are you sure there's only one cloning?
12:43imirkin_: RSpliet: it's working fine
12:43alexandernst: imirkin_: that turned black all screens for a good miinute
12:43imirkin_: or rather... that seems fine and expected
12:43alexandernst: RSpliet: 3rd and 4th monitor are cloning the content of screen 1
12:43imirkin_: alexandernst: doh... did things come back at all?
12:43RSpliet: alexandernst: that explains more :)
12:44imirkin_: alexandernst: ok, plan b...
12:44alexandernst: imirkin_: yes, after a minute all 4 screens recovered
12:45imirkin_: alexandernst: xrandr --output DVI-I-1-2 --off --output HDMI-1-2 --off
12:45alexandernst: I kept hearing Spotify, but I could see was black
12:45imirkin_: and THEN do
12:45imirkin_: xrandr --output DVI-I-1-2 --left-of HDMI-1 --auto
12:47alexandernst: mmm. Now 3rd and 4th turned of. Then (after the second command) the 3rd turned on again, but the 4th is still off.
12:47alexandernst: All 3 monitors are showing independant content (good)
12:47imirkin_: so now do
12:48imirkin_: xrandr --output HDMI-1-2 --left-of DVI-I-1-2
12:48imirkin_: xrandr --output HDMI-1-2 --left-of DVI-I-1-2 --auto
12:49imirkin_: which should turn the 4th monitor on
12:51alexandernst: well... yes, but now 3 and 4 are showing the same thing again
12:51alexandernst: and also, I lost all my open windows somewhere in the dark void
12:51alexandernst: I can reach some of them dragging the mouse while holding Alt :D
12:52alexandernst: basically, all 4 monitors are on at this point, but my mouse is visible only in 3 and 4
12:52imirkin_: try moving the mouse in the other direction
12:52imirkin_: the internal geometry may not match up to how they're physically positioned
12:53alexandernst: oh silly me, indeed
12:53alexandernst: so now left is up
12:53alexandernst: right is left
12:53alexandernst: down is right
12:53alexandernst: err.... no...
12:53imirkin_: so my recommendation would be to do
12:53alexandernst: you get the point, this got screwed :D
12:53imirkin_: alexandernst: xrandr --output DVI-I-1-2 --off --output HDMI-1-2 --off
12:53imirkin_: which will turn off 3 and 4 again
12:54imirkin_: and then redo those commands and instead of --left-of
12:54imirkin_: do the right thing
12:54imirkin_: it can be --left-of or --right-of or --above or --below
12:54imirkin_: so like
12:55alexandernst: the main problem is that 2 of the screens are cloning theirselfs
12:55imirkin_: "xrandr --output HDMI-1-2 --left-of DVI-I-1-2 --auto" means "place the monitor HDMI-1-2 left of DVI-I-1-2 and turn it on"
12:55imirkin_: i'm guessing that happened coz you typo'd something
12:55imirkin_: e.g. DVI-I-1 vs DVI-I-1-2
12:56alexandernst: ok, how can I tell it this:
12:57alexandernst: HDMI-1 is primary -> DVI-I-1 is at the right -> HDMI-1-2 is on top of HDMI-1 -> DVI-I-1-2 is at the right of HDMI-1-2 ?
12:58alexandernst: visually speaking:
12:58imirkin_: ok, so the simplest thing to do
12:58imirkin_: is to turn everything off except DVI-I-1
12:58imirkin_: and then add them in
12:58imirkin_: so like
12:58alexandernst: HDMI-1-2 | DVI-I-1-2
12:58alexandernst: HDMI-1 | DVI-I-1
12:58imirkin_: xrandr --output DVI-I-1 --off
12:58imirkin_: now only HDMI-1 is on, right?
12:59imirkin_: so now you add them in one at a time
12:59imirkin_: xrandr --output DVI-I-1 --right-of HDMI-1 --auto
12:59imirkin_: xrandr --output HDMI-1-2 --above HDMI-1 --auto
12:59imirkin_: xrandr --output DVI-I-1-2 --right-of HDMI-1-2 --auto
12:59alexandernst: the first command segfaulted :(
13:01imirkin_: if you're unfamiliar with xrandr, you may benefit from a gui tool which wraps it in some nice "easy to use" ui
13:01alexandernst: yeah, KDE's display manager
13:01alexandernst: but then I hit the base problem
13:01imirkin_: i've definitely run into funky issues
13:02alexandernst: 3rd and 4th are cloning theirselfs
13:02imirkin_: turning monitors on and off tends to help such situations
13:02imirkin_: nah, that was just the initial state
13:02imirkin_: not a property of that display manager
13:02imirkin_: flip things on and off, that will often kick the internal state of these things if it's confused/stuck somehow
13:03alexandernst: xrandr --auto is segfaulting
13:03imirkin_: what does 'xrandr -q' output?
13:03alexandernst: all 4 outputs are connected
13:04mlankhorst: just pastebin it
13:04mlankhorst: we know it's connected, we care more about specifics
13:06alexandernst: now all 4 monitors are on
13:07alexandernst: (turned then on with KDE's tool)
13:07alexandernst: but same problem. 3 and 4 are cloning theirselfs
13:07imirkin_: it appears that it should all be correct
13:07imirkin_: that's very surprising
13:08imirkin_: i wonder if there's some new recent bug that causes that
13:08imirkin_: coz it definitely used to work
13:08alexandernst: if there is, it's between Xorg 1.16.1 and 1.16.4
13:08airlied:can't remember if all the fixes are inthe X server for multi-head reverse prime
13:08alexandernst: because I know this works in Fedora 21 LiveUSB
13:09airlied: fedora might have a patch in its server
13:09alexandernst: that is possible too
13:09imirkin_: airlied: is there an easily findable list of such beasts?
13:10airlied: looks likely
13:10airlied: should probably send that upstream for the nth time to not get it merged
13:10alexandernst: those 25 lines are screwing me?
13:13alexandernst: they are not there
13:14imirkin_: airlied: :( seems like multi-head reverse prime is a reasonable feature... it's the only way to do 4 monitors on not-super-recent gpu's...
13:15alexandernst: indeed, 4 monitors are posssible with a total of 80$ for 2 gc, instead of a Quadro 500$ card...
13:15alexandernst: but then again, why this patch hasn't been merged?
13:16imirkin_: alexandernst: well, you can get a 4-output nvidia kepler (or amd of some sort) card for a lot cheaper than $500
13:17alexandernst: imirkin_: won't work. NVIDIA disabled base mosaic for +3 monitors. Maybe with nouveau?
13:17imirkin_: alexandernst: well, the hw has 4 crtc's, so it'll work
13:17imirkin_: (kepler hw... pre-kepler only has 2 crtc's, so even if you have 3 or 30 connectors, only 2 images at a time per gpu)
13:18alexandernst: imirkin_: this one maybe ? http://www.asus.com/es/Graphics_Cards/GTX670DCMOC2GD5/
13:19alexandernst: oops, sorry, remove the "es/" from the link for english version
13:19imirkin_: yep, that'd work fine, but it's way overkill for just driving the 4 monitors
13:20alexandernst: imirkin_: can you recommend me the cheaper one that will work with 4 monitors?
13:21alexandernst: no, sorry, spanish, english, bulgarian, a little bit of russian, but not french :(
13:21RSpliet: no I mean what country you're from...
13:21alexandernst: ah :)
13:21RSpliet: interesting mix of languages btw
13:21airlied: the X server patch merging policy is kinda painful
13:21alexandernst: but I live in spain
13:21aaronp: You might need DisplayPort multistream for that. I don't know if there are any GT 640s with four physical connectors.
13:22airlied: so I send a patch, it gets ignored I move on and forget because its fixed in Fedora
13:22airlied: and I only get paid for that
13:22alexandernst: airlied: :(
13:22RSpliet: aaronp: ASUS GT640 does... one VGA, two DVI, one HDMI
13:22alexandernst: RSpliet: which one http://www.asus.com/Graphics_Cards/NVIDIA_Series_Products/ ?
13:22imirkin_: aaronp: nouveau doesn't support MST atm
13:22alexandernst: oh! saw it
13:23aaronp: imirkin_, oh, okay. Of course, then you need to use VGA. :)
13:23alexandernst: but can a VGA do 1080p?
13:23RSpliet: it can, but in my experience it doesn't give you very high quality
13:23RSpliet: given it's analogue
13:23aaronp: VGA can do anything that fits within the card's pixel clock, it just might get too blurry to be usable.
13:23alexandernst: then I'd rather stay with a higher-end gc
13:24imirkin_: alexandernst: http://www.newegg.com/Product/Product.aspx?Item=N82E16814121660 -- $120 after rebate
13:24imirkin_: i'd avoid VGA... but it can definitely do 1920x1200 without being too annoying.
13:24RSpliet: imirkin_: DVI, DVI, HDMI and... SATA? so that's what DP looks like :D
13:24imirkin_: depends on the monitor more than anything
13:24imirkin_: RSpliet: yes. SATA :p
13:25chrisf: has nvidia started putting decent DACs on their cards? that was the real problem with high resolutions over VGA with their hardware..
13:25imirkin_: actually a really clever use of DP or HDMI that i saw was as a ethernet switch trunk port (from netgear)
13:25aaronp: There was a huge improvement in DAC quality between NV1x and NV2x, if I remember correctly.
13:25aaronp: After that, I couldn't really tell a difference.
13:26imirkin_: aaronp: actually i have a NV34 with *terrible* vga output. really horrible.
13:26alexandernst: airlied: can you push for that patch again, please?
13:26imirkin_: aaronp: but the nv17 i have is totally fine
13:26aaronp: I think it depended on the board vendor... I think at least some of that stuff were external components.
13:26airlied: alexandernst: I'll try again now since 1.17 got released and its an ABI break
13:26imirkin_: i think just that one NV34 is bad. it's one of those DMS-59 connectors, and it looks worn
13:26alexandernst: airlied: maybe try to push all your patches that didn't get accepted?
13:27imirkin_: but i have a G98 with a DMS-59 as well, and it's fine. but it was brand new when i got it.
13:27RSpliet: imirkin_: I recall staring at such a connector once
13:27RSpliet: ... that's not a connector
13:27aaronp: I'm so glad DMS-59 has gone the way of the dodo.
13:28aaronp: Of course, now we have these finicky DP MST branches, which are often worse...
13:28imirkin_: but... fewer pins
13:28aaronp: Yeah. Mini-DP is actually really nice.
13:28imirkin_: and standard connectors
13:29aaronp: I'm looking forward to USB type C alt mode, if it lives up to the hype.
13:29RSpliet: aaronp: wait, a what... are you talking about http://club-3d.com/index.php/products/reader.en/product/mst-hub-1-3.html ?
13:29alexandernst: what about 2 Quadro K620 ? Would that work better? (Note that I don't play on the computer, I want it for work only, so I'm fine with low performance)
13:30aaronp: Not that one specifically, but I have one that mostly works but occasionally needs to be rebooted.
13:30imirkin_: alexandernst: 2 anythings will always work worse than 1 something
13:30airlied: the ancell one is better thant the club3d from my playing arounde
13:30RSpliet: ugh, Valve people with their "money" for "monitors" :p
13:31alexandernst: imirkin_: what about a Quadro NVS 510? Would that work fine with NVIDIA's driver? (and 4 monitors)
13:32RSpliet: alexandernst: why are you looking into quadro? I thought money was your foremost issue?
13:32aaronp: alexandernst, the Quadro K620 should be able to drive four monitors if you get an MST hub.
13:32RSpliet: there's ways of fixing your current set-up, Fedora has proven that, and Arch can pick up these fixes easily if upstreaming would just work
13:33imirkin_: aaronp: some recent monitors have a DP output too
13:33aaronp: alexandernst, this discussion might be better suited for #nvidia.
13:33alexandernst: RSpliet: no. I already had 1 GT610 and I got another one for 30€. I already had 4 monitors so I wanted to make this work with what I have currently, but if I can't get it work, I want to find the gc that will a) work better with NVIDIA driver b) less power consumption c) play nice with 4 monitors
13:34RSpliet: airlied: if you need bigger boots to kick stuff upstream, I'm sure we can start a kickstarter for you :p
13:34alexandernst: RSpliet: yes, but I don't have any power over upstream, sadly. If I had, that patch would be already merged and rebased in 1.16.4
13:34alexandernst: airlied: that I'll pay for!
13:35RSpliet: alexandernst: alternatively: patch up and build your own Xserver?
13:35RSpliet: there's some arch users that could help you with that I'm sure, right mupuf/pmoreau?
13:36RSpliet: aaronp: sorry for confusing you with Plagman btw...
13:36alexandernst: that is an option too, but I'd rather stay with vanilla-everything. Makes life easier
13:37alexandernst: aaronp: what iss a MST hub?
13:37aaronp: DisplayPort Multistream.
13:37RSpliet: alexandernst: then kick the Arch maintainer to see if he's up for accepting that patch until it went upstream
13:37aaronp: It allows you to connect more than one display device to a single DP connector on a GPU.
13:37RSpliet: plenty of options :D
13:37pmoreau: RSpliet: Using / configuring Arch probably, but getting patches upstream, not sure about that :D
13:37RSpliet: pmoreau: but building an Xserver?
13:38alexandernst: aaronp: why would I want that? The NVS 510 has 4 DP ports, so I should be able to plugin 4 monitors without any problems, right?
13:38pmoreau: RSpliet: Never tried that. Only building kernel/xf86-nouveau/mesa
13:38Plagman: <RSpliet> aaronp: sorry for confusing you with Plagman btw...
13:38Plagman: there are worse things in life!
13:38pmoreau: RSpliet: But, I guess using some PKGBUILD from AUR would do it.
13:39RSpliet: pmoreau: I'm not the one who might care :D I was merely making suggestions to alexandernst to fix his current set-up; of course he's free to empty his pockets and get a shiny new graphics card if he prefers :p
13:39aaronp: alexandernst, yeah, that will work too.
13:40pmoreau: RSpliet: ;)
13:40alexandernst: aaronp: how many displays (with different image) acn a single DP port drive?
13:40airlied: just use Fedora :-P
13:40RSpliet: (I'm a Fedora user, no bugs for me... *shuns*)
13:40alexandernst: airlied: :P
13:40pmoreau: Was a Fedora user
13:40aaronp: In theory, a lot. But you're limited by the bandwidth constraints of the source, and the number of heads in the GPU.
13:41alexandernst: How can I check how many monitors can a, let's say, Quadro K600 drive?
13:42aaronp: Kepler GPUs have 4 heads.
13:43alexandernst: yes, but we already said that 640 and 650 have one VGA and that would give me kind of poor results. So I'm stuck at 660+, which means a lot of $. That's why I'm comparing with Quadro cards
13:44pmoreau: Pfiou, finished adding a 100 or so regs to PFB in PFIFO for G96 and MCP79. Would need to check with the other Teslas... :/
13:44aaronp: I can never remember what the bandwidth limits for DP 1.2 end up being in terms of resolutions.
13:46alexandernst: so... let me clear my thoughts. According to this scheme, I can use a single Quadro K600 (which has 1 DP and 1 DVI) and a MST hub for 4 monitors, and all of them will work fine, showing different content on each monitorr?
13:46aaronp: Like I said it depends on the combined resolution of the monitors, but yeah.
13:46alexandernst: all 4 monitors are 1080p
13:48aaronp: I think so.
13:50alexandernst: holly ....
13:50alexandernst: a MST hub for 4 monitors in almost 200€ !
13:51aaronp: You only need 3, though.
13:51alexandernst: ah, indeed
13:51alexandernst: but still, the 3x is 150
13:51aaronp: Yeah. They're pretty new technology.
13:53RSpliet: aaronp: are those hubs pretending to be a single monitor and just chopping up the image? or is there actual protocol support for multiple monitors?
13:53alexandernst: airlied: http://lists.x.org/archives/xorg-devel/2014-August/043702.html
13:54alexandernst: https://freedesktop.org/patch/14207/ <-- oh, so it got merged!
13:55aaronp: RSpliet, there's actual protocol.\
13:55alexandernst: airlied: http://cgit.freedesktop.org/xorg/xserver/tree/dix/pixmap.c?h=server-1.17-branch <---- it's in 1.17
13:55airlied: oh so maybe its in 1.17 then
13:55airlied: oh good
13:55alexandernst: so I just need to bug Arch X maintainer until he upgrades the package
13:56alexandernst: let's search him on google and get his email, his phone, his address and the names of every person in his family
13:57pmoreau: alexandernst: 1.17.1 is in testing
13:57alexandernst: oh, 1.17 is already in testing!
13:57alexandernst: so it's a matter of days and I'll be able to use my monitors \o/
13:57pmoreau: Just need to change your pacman conf to use include testing too ;)
13:58alexandernst: let's not rush that much :P I can wait a few days
13:58alexandernst: pmoreau: are you X maintainer in Arch?
13:58pmoreau: pmoreau: Just a user :)
13:59aaronp: alexandernst, hmm, I managed to find a board that reports itself as a Quadro K600 and it apparently does only have 2 heads.
13:59aaronp: It's a weirdo prototype, though.
13:59pmoreau: mlankhorst: Eh eh eh, according to my nouveau trace nouveau's only writes to PFB are for MMU flush.
13:59alexandernst: aaronp: don't worry, it seems that today is my lucky day :) airlied's patch is in 1.17
14:00alexandernst: aaronp: so I won't need to buy more stuff
14:02alexandernst: airlied: funny thou how you sent that patch July 30, 2013 and it got a reply Aug 29, 2014 (after 13 months)
14:02alexandernst: is that normal?
14:05airlied: well I often forget to follow up on xserver fixes
14:06airlied: I think I fixed that for RHEL initially and moved onto other things
14:07alexandernst: airlied: how exactly does the entire "send a patch" thing works? You send an email with a patch and ... you wait for a reply?
14:08airlied: pretty much, and if nobody replies you go harass people
14:08alexandernst: this seems kind of ... broken, right?
14:08airlied: I just forget the go harass people since I've got a lot of other jobs
14:08alexandernst: why not use something like github so all the push requests can be easily found?
14:10aaronp: That's what patchwork does, sort of.
14:11airlied: the problem is lack of review not lack of syste
14:12alexandernst: is the review done by a single person?
14:13pmoreau: Everyone can review and comment, but the maintainer decides in the end to merge or not the patch
14:15airlied: review requires harassment mostly, also in an area where only one person knows the stuff
18:34gnurou: imirkin: re: gk20a mesa patches, that's fine actually. I still cannot make up my mind about the best way to do this, but will repost once I have