09:13 Weaselweb: pmoreau: for the record, i filed both bugs we were talking about as https://bugs.freedesktop.org/show_bug.cgi?id=90423 and https://bugs.freedesktop.org/show_bug.cgi?id=90424
09:19 yurikoles: I have problems while building master
09:19 yurikoles: ws-soap.cxx:(.text+0x35b3): undefined reference to `std::runtime_error::runtime_error(char const*)'
09:21 yurikoles: oh shi, wrong channel, sorry
09:27 imirkin_: Weaselweb: actually panel scaling used to be the default i think
09:27 imirkin_: Weaselweb: er... other way around, yeah
09:27 imirkin_: panel scaling is where the panel does its own scaling
09:28 imirkin_: Weaselweb: can you provide xrandr --verbose with whatever screen is having issues plugged in?
09:58 Weaselweb: imirkin_: here is xrandr --verbose: https://bpaste.net/show/25e564a608bd
10:57 imirkin_: oh dear
10:58 imirkin_: Weaselweb: is the 1360x768 a custom mode, or one of the available ones in the edid (too lazy to decode the edid...)
10:58 imirkin_: Weaselweb: actually also include your xorg.log
10:58 imirkin_: (in the bug, coz i'll just forget otherwise)
10:58 imirkin_: (along with the xrandr output)
10:59 imirkin_: anyways... panel scaling == give the requested mode to the panel, and let it worry about scaling
11:00 imirkin_: no panel scaling == ignore the requested mode entirely, and only ever give the preferred mode, and scale up/down using the gpu
11:00 imirkin_: aka the 'scaling mode' randr property...
11:19 imirkin_: Weaselweb: where does that 1360xwtvr mode come from?
11:20 Weaselweb: imirkin_: that question remindes of soething I needed to do some time ago. I created a custom modeline in /etc/X11/xorg.conf.d/01-layout.conf
11:21 Weaselweb: removing that file at least gets me a working screen again, but the resolution seems to be messed up
11:22 imirkin_: Weaselweb: define 'messed up'? and what *is* the resolution?
11:22 imirkin_: the preferred resolution of the monitor appears to be 1920x1080@50
11:23 Weaselweb: well, that is messed up. I have an AV receiver where the TV is attached to. So I only see the EDID from the AV receiver but not my TV. the receiver supports 1920x1080, but my TV has a native resolution of 1360x768
11:24 imirkin_: yeah, but the receiver can't handle it
11:24 Weaselweb: mythtv is configured to be 1360x768 but the actual X screen size is 1920x1080
11:24 imirkin_: that was the change -- to pass through the requested mode instead of always using the preferred mode
11:24 imirkin_: this is *generally* the right thing to do :)
11:25 Weaselweb: might be the problem. OTOH it seems that I can set X to 1920x1080 and the receiver scales it down for my screen
11:25 imirkin_: you can disable it if you like by switching the scaling mode to 'Full'
11:25 imirkin_: (xrandr --output HDMI-1 --prop 'scaling mode' 'Full')
11:26 imirkin_: which will go back to gpu scaling and you'd be able to set a fake-o 1360x768 mode that is then scaled up to 1920x1080 by the gpu, and scaled down by the receiver (i guess)
11:26 Weaselweb: full means that the driver/hardware does scaling?
11:26 Weaselweb: oh dear. that is a crazy thing to do
11:26 imirkin_: yeah, means that the gpu does the scaling up (or down) to the preferred mode (rather than the set mode)
11:26 imirkin_: this used to be the default :)
11:27 imirkin_: the problem is single-mode panels that don't do scaling, or even worse, single mode panels that don't do scaling but claim to support multiple modes
11:27 imirkin_: those tend to be internal laptop panels though, so i think for LVDS we just default to not using panel scaling
11:28 Weaselweb: yep, LVDS, LVDS_SPWG and eDP
11:29 Weaselweb: to summarize, if you want to use a custom modesetting you also need to configure full scaling mode, correct?
11:30 imirkin_: or use a monitor that supports the custom mode :)
11:30 imirkin_: your situation is extra-special since you have the receiver in the middle
11:33 Weaselweb: sure, it's not I like it much, but seems currently the only way to support the speaker placed in the room rather than the ones in the TV :)
11:36 Weaselweb: hooray, removing the custom mode setting (I hated it much when creating this, but it was necessary) and removing any geometry setting from mythtv, I now got a native resolution (relative to receiver) which is fully supported by Xorg and mythtv
11:38 Weaselweb: imirkin_: I'll add an info to the BR that this "regression" comes due to panel scaling and using a custom modesetting. either remove custom modesetting or manually switch back to full scaling mode
12:38 imirkin_: it actually wasn't necessary before, but the default was full scaling whereas now it defaults to no scaling
18:11 yusukesuzuki: hello
18:11 yusukesuzuki: i'm seeking the way to generate firmware binary header (fuc.h) from fuc3 files.
18:12 imirkin_: yusukesuzuki: envyas from envytools
18:12 yusukesuzuki: does anyone know this?
18:13 yusukesuzuki: imirkin: thanks. I've passed fuc3 to cpp -P and passed it to envyas, and get "no match" error.
18:13 imirkin_: envyas takes 75 arguments
18:13 yusukesuzuki: wow
18:13 imirkin_: you must have only passed in 74 of them :)
18:13 imirkin_: [i'm exaggerating]
18:14 yusukesuzuki: I've passed -m fuc -V fuc3, for gpcgf100.fuc3, is it not enough?
18:14 imirkin_: after cpp, yeah, that should be fine
18:14 imirkin_: ugh, there used to be a makefile in there
18:14 imirkin_: skeggsb: what happened to it?
18:15 imirkin_: yusukesuzuki: take a look at http://cgit.freedesktop.org/~darktama/nouveau/tree/lib/Makefile
18:15 yusukesuzuki: imirkin_: ah! that's really helpful! thanks :D
18:24 imirkin_: yusukesuzuki: mind if i ask what you're trying to accomplish?
18:24 yusukesuzuki: imirkin_: no problem :) I'm now seeking the way to set trap handlers.
18:25 imirkin_: oh, on fermi?
18:25 imirkin_: iirc it's semi-documented
18:25 yusukesuzuki: imirkin_: oh! that's really nice.
18:25 imirkin_: the trap handlers require shader code though, not falcon code
18:26 imirkin_: wait, which trap are you talking about?
18:26 yusukesuzuki: imirkin_: yes, shader code level traps. not falcon's traps (like ihbody)
18:27 yusukesuzuki: imirkin_: i'm now setting the bpt_control up, but maybe, i suppose i should set it in falcon.
18:27 imirkin_: https://github.com/envytools/envytools/blob/master/rnndb/graph/gf100_pgraph/tpc.xml#L556
18:28 imirkin_: i guess it works differently on kepler
18:29 yusukesuzuki: imirkin_: oh, but np :) i'm now trying it on fermi.
18:29 yusukesuzuki: imirkin_: does this pc means GPU virtual address in GPU context?
18:29 imirkin_: so basically you set that mmio reg to the PC of your trap handler
18:29 imirkin_: no
18:29 imirkin_: it's the PC as in shader instruction address
18:29 imirkin_: which is relative to some base
18:30 yusukesuzuki: imirkin_: offset from the base in gpu's VRAM physical address level?
18:31 imirkin_: yusukesuzuki: no, hold on... trying to find the relevant bit
18:32 imirkin_: yusukesuzuki: CODE_ADDRESS_HIGH/LOW pushbuf methods set it
18:33 imirkin_: there's probably a direct way to set it using mmio addresses since that'd be easier to debug the debugging
18:33 imirkin_: anyways, pc is relative to that code address
18:34 yusukesuzuki: imirkin_: IIRC, CODE_ADDRESS_HIGH/LOW is virtual address. so trap handler pc is the offset from it in virtual address level?
18:34 imirkin_: yep
18:34 imirkin_: things are always done in virtual address space
18:35 imirkin_: so yeah, there are various breakpoint/etc instructions. it's unclear to me *precisely* what they do, but probably *some* sort of trap :)
18:36 yusukesuzuki: imirkin_: ah thanks. I've got it! so i guess the easiest way to set a handler is locating the trap handler in the same cubin module, load it, and set it when launching the kernel.
18:36 imirkin_: yes
18:37 imirkin_: there's no way to set that trap pc thing, but you could write a software method for it
18:37 imirkin_: [i mean, no way from userspace]
18:38 imirkin_: yusukesuzuki: are you working on gdev?
18:38 yusukesuzuki: imirkin_: yes :)
18:38 imirkin_: ok, figured as much. you seemed to know a lot more about nouveau than the average passerby :)
18:39 yusukesuzuki: imirkin_: thx :D
18:40 imirkin_: please share if you learn anything concrete about how these things work
18:40 imirkin_: i think both mwk and calim know a bunch about it
18:40 imirkin_: but i haven't been able to get them to document it
18:40 imirkin_: if you search through old logs you may find them explaining it once or twice
18:41 yusukesuzuki: imirkin_: oh, that's pretty nice!
18:41 imirkin_: i'd love to add some sort of shader debugger support to nouveau, but i've gotten stuck on working out how such an interface would work
18:42 yusukesuzuki: imirkin_: sure. when i found the good way to debug, i'd like to share it and (maybe implement it in gdev side :D)
18:43 imirkin_: awesome. well keep us posted
18:43 yusukesuzuki: imirkin_: thank you for your help!
18:43 yusukesuzuki: imirkin_: I'll attempt to set the easiest handler. "bpt pause;rtt;".
18:44 yusukesuzuki: through libpciaccess
18:44 imirkin_: i think the idea is that the trap handler copies all registers to memory
18:45 imirkin_: what's "rtt"? is that "resume execution"?
18:46 yusukesuzuki: imirkin_: i've seen it in http://people.freedesktop.org/~chrisbmr/a0c0-counter.c and http://people.freedesktop.org/~cbrill/dri-log/?channel=nouveau&date=2013-06-26
18:46 yusukesuzuki: i guess rtt means "return from the trap"
18:47 imirkin_: oh nice. note that this is on kepler though
18:50 yusukesuzuki: imirkin_: ooo, are they so different in trap handler area?
18:50 imirkin_: anyways, this is about logging pm counters, not really about the trap stuff
18:51 imirkin_: apparently mwk has some notes on single-stepping somewhere
18:53 imirkin_: yusukesuzuki: probably this: http://ng.0x04.net/~mwk/singlestep.txt
18:54 yusukesuzuki: imirkin_: oh, that's great! i'll check it and attempt to set some really small trap handler.
18:54 imirkin_: seems like that doc has everything you need
18:54 imirkin_: i recommend reading the whole thing very carefully first :)
18:55 yusukesuzuki: imirkin_: great. this document is so helpful, thanks imirkin_ and mwk.
18:55 yusukesuzuki: so i'll attempt to set it on nvc0, fermi card.