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