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