02:20rah: has there been any work on GPU in the Ouya console?
02:21rah: it's a Tegra 3
02:29rah: apparently there has.. http://tuomas.kulve.fi/blog/2013/08/11/debian-on-ouya/
02:32mlankhorst: but there's been more work on the newer tegra's :)
03:02Yoshimo: always difficult to get developers interested in very old hardware
05:11Hadit: Hi, i am having trouble with an retina mac book. Xorg starts normal and i can see that xrandr recognizes eDP-1 with a connected display. But the screen stays black: The problem occured since kernel 3.17.x . The properitary nvidia drivers works, but not with xrandr. The integrated intel driver seems to be deactivated.
07:29imirkin: Hadit: can you bisect?
08:55Hadit: Hi, i am having trouble with an retina mac book. Xorg starts normal and i can see that xrandr recognizes eDP-1 with a connected display. But the screen stays black
08:55Hadit: The problem occured since kernel 3.17.x . The properitary nvidia drivers works, but not with xrandr. The integrated intel device seems to be deactivated
08:55Hadit: it doesn't show up in the lpci output
08:56imirkin: Hadit: can you bisect?
08:57imirkin: Hadit: you might also try a more recent kernel
09:38Hadit: i've tried 3.18.10 and 3.19.2
09:38Hadit: 3.14.x worked...
09:39Hadit: you mean trying 4.0?
09:40imirkin: Hadit: no
09:40imirkin: 3.16 had some major DP-related rework
09:40imirkin: (or was it 3.15? i forget)
09:40Hadit: i think 3.17 was the line when it stopped to work
09:41imirkin: well, if you could bisect it to the commit that killed it, that'd be immensely helpful
09:43Hadit: okay ... the notebook is not at my place and is turned off now, so when i do some tests with it again, I'll post it to the mailinglist
09:44imirkin: sounds good
09:44imirkin: btw, do you remember what gpu it has?
09:44imirkin: is it that GTX 650 thing?
09:44Hadit: ha ... i still have the console :)
09:45Hadit: 01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT 750M Mac Edition] (rev a1)
09:45Hadit: 01:00.1 0403: 10de:0e1b (rev a1)
09:45imirkin: ftr, you can use -nn to get it all in one go :)
09:45Hadit: 01:00.0 0300: 10de:0fe9 (rev a1)
09:46Hadit: I'm not connected to it anymore, but i have the console output when i played with it
09:47imirkin: ah ok
09:48Hadit: that's all i have at the moment: http://pastebin.com/MM9iybA9
09:49imirkin: nouveau E[ PDISP][0000:01:00.0] 00:0006:0f44: link training failed
09:49imirkin: well, that's why the screen's black
09:49imirkin: do a boot with nouveau.debug=debug,VBIOS=trace drm.debug=0xe
09:50Hadit: yeah ... googled myself to death with that line ...
09:50Hadit: okay ... I'll do some tests on monday
09:51Hadit: what's the better way IRC or the mailinglist ?
09:51imirkin: whatever you prefer
09:51Hadit: k :)
10:00imirkin: Hadit: so yeah, 3.16 had all the dp rework... so if 3.16.x works fine but 3.17.x doesn't, that's extremely surprising
10:00imirkin: Hadit: a bisect would be most instructive...
10:02Hadit: hmmm sorry I only know the word bisect in the context "to halven something" ,-)
10:02Hadit: so i think i don't get it :)
10:02imirkin: read up on "git bisect"
10:03imirkin: basically it's a tool that assists you in doing a binary search for the commit that broke things
10:03Hadit: hahahaha we call it blame :)
10:03Hadit: okay :)
10:04imirkin: blame is usually an annotation of which commit was the last to touch a particular line of a file...
10:05Hadit: hmmmm ... so i think it would be the best to get the mac on front of me to do that....
10:27joi: fyi, I pushed two changes to mmt, which lets you omit --mmt-trace-file=... - if you add --mmt-trace-nvidia-ioctls / --mmt-trace-nouveau-ioctls / --mmt-trace-fglrx-ioctls it will detect which files it should trace
10:27imirkin: joi: cool :) does it deal with the device not being at /dev/dri/card0?
10:27imirkin: (e.g. /dev/dri/card1 or whatnot)
10:29joi: it seems in some cases (DRI3+something) you cannot rely on application opening /dev/dri/cardX
10:30joi: because it gets a file descriptor by unix socket
10:35joi: above triggered change on mmt/nouveau side, nvidia/fglrx fds are guessed just by looking at the path of opened files
10:40imirkin: you should still be able to tell where the passed fd points to no?
10:40imirkin: e.g. via /proc/self/fd/N
10:44joi: maybe, I can't check it now, because I've seen it only on mlankhorst's k1 box
11:32mlankhorst: just upgrade mesa and ddx :P
11:33mlankhorst: joi: something like in helgrind.h, but for mmtrace?
11:35mlankhorst: shrug, I'll add some code for it..
11:36joi: mlankhorst: not sure what are you talking about...
11:42mlankhorst: joi: it's easy to add annotation for tracing..
11:43joi: and adding few lines to mmt is hard?
11:44mlankhorst: joi: I mean adding stuff to nouveau_device_open to always cause the fd to be tracked automatically
11:45joi: I would prefer to not rely on annotations if detecting something on mmt side is easy
11:48mlankhorst: joi: I'm not sure it's easy
11:52joi: the whole point of mmt is tracing unmodified binaries
12:03mlankhorst: joi: yeah but this is a noop in case of no tracer..
12:12joi: that's irrelevant, you had to patch project which you want to trace
12:15mlankhorst: joi: no you dont, just libdrm :)
12:16mlankhorst: and in case of distros they might do it by default
12:20joi: libdrm is part of the project you are want to trace; ubuntu is not the whole world, I don't want to guide people how do they need to recompile libdrm on some obscure distribution to get the proper trace
12:21mupuf: joi: indeed, I would hate the world if ubuntu was the whole world :D
12:22imirkin: where "obscure distribution" == "ubuntu", i assume :)
12:23joi: no, ubuntu compiles libdrm with (some) vg support
12:25joi: (at least that's what mlankhorst told me few days ago)
12:28mlankhorst: debian too
12:33mupuf: joi, mlankhorst: vg?
13:10mupuf: imirkin: thanks
13:26mlankhorst: I need it for intel anyway
13:26mlankhorst: so I can profile ubuntu with the -dbg symbols without changing stuff