00:00Booti3869: it seems nouveau expects y >= 0, so it should be fixed there
00:01imirkin_: pretty sure that the gallium blit api requires y >= 0
00:01imirkin_: and the bug is in st/mesa
00:01imirkin_: (or somewhere else that calls that api)
00:01imirkin_: who said that negative y is ok in pipe->blit?
00:06Booti3869: imirkin: https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2018-02-15
00:07imirkin_: am i missing something?
00:07Booti3869: Your question at 03:58, the answer at 12:54
00:07imirkin_: oh. hm
00:07imirkin_: that was a diff q
00:07imirkin_: that was for too wide/high
00:08imirkin_: anyways, wtvr
00:08imirkin_: well, feel free to patch up nouveau
00:10imirkin_: fine wtvr
00:10imirkin_: i don't have the energy to fight it all.
00:10imirkin_: send patches.
00:11Booti3869: Well, in your opinion, where should it be fixed, in st/mesa or nouveau?
00:12imirkin_: the usual thing is for gallium api's to not take stupid broken values
00:12imirkin_: and not have to do error checking/etc
00:12imirkin_: there's an argument here that these are all actually legal values
00:15Booti3869: So i should probably take a look to other drivers, and if they do some error checking, move it to st/mesa
00:15imirkin_: it's not about error checking
00:15imirkin_: it's about adjusting the inputs
00:15imirkin_: and there's a 2d and 3d pipeline
00:15imirkin_: which might need to be handled differently
00:16Booti3869: Haha, why things are so simple :)
00:19Booti3869: Thank you for your time :)
00:24Booti3869: Mh... Inside st_BLitFramebuffer() : /* Destination dimensions have to be positive: */
00:25Booti3869: Looks like it was the original intention
00:29Booti3869: Or maybe not... Someday I'll send a patch, hopefully
12:35aphirst: Hi there. Back in ~October I was talking about an issue with certain Optimus devices(laptops?) where the HDMI/DP Audio needs some PCI bit-banging to work. Someone here made a mailing list thread with some kernel devs and there were references to an upstream forum thread at nVidia, but I was curious whether there were any updates on that, or what exactly was blocking progress?
12:37aphirst: Ah, it does seem there was some sort of progress https://bugs.freedesktop.org/show_bug.cgi?id=75985#c36
12:37aphirst: I'll re-read the last couple months of discussion.
14:47imirkin: aphirst: yeah, i think substantial progress has been made by some of the affected users, but i don't know anything about the details
15:32aphirst: imirkin, i set up the module, but have yet to test the machine on the docking station with the external monitor yet
15:33aphirst: however it did compile, install, and boot fine, and the DP/HDMI audio device does show up in pavucontrol
15:33aphirst: (i of course disabled my systemd service which had just done the bit-banging)
16:06imirkin_: aphirst: cool
16:06imirkin_: that all needs to be upstreamed somehow
16:19aphirst: well it's not my place to suggest that
16:19aphirst: i will however report back somehow once i test it fully
17:54orbea: nouveau keeps dying with 'nv50cal_space: -16'. http://dpaste.com/3RGN12R.txt Is there anything that can be done to avoid nouveau dying in these instances?
17:55orbea: this is with linux-4.15.7, but I have seen this for a while
17:55orbea: In this case I think testing compton just made it faster...
17:59imirkin_: that means "hang", i believe
17:59imirkin_: [44917.582207] nouveau 0000:01:00.0: fifo: read fault at ffb6b7e000 engine 07 [HOST0] client 07 [HOST_CPU] reason 00 [PDE] on channel 2 [00bf8c1000 Xorg]
17:59imirkin_: some paging issue.
18:00imirkin_: weird. i think that means that the host tried to access something illegal over imem or something? dunno.
18:04orbea: so potentiall compton and maybe other programs are doing silly things and the kernel segments of nouveau are failing in these instances?
18:05imirkin_: or more likely nouveau screws up
18:05imirkin_: this fix has been helpful to a bunch of people with various ailments:
18:06orbea: cool, I'll give it a try in a little bit when I rebuild a kernel
18:10orbea: I also found that turning on threading in driconf made it a lot faster too...I decided against doing that.