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