00:39mupuf_: imirkin: you are right, pretty sure it won't work on secondary GPUs
00:39mupuf_: I am talking about fakebios
00:45mwk: mupuf_: should work if you load driver that POSTs it, unload, fakebios, load again - right?
00:45mupuf_: need to check
00:46mupuf_: mwk: so, speaking about this, where in memory does it land?
00:46mupuf_: and how do we not override it? Is there a reserved space for that in our TTM backend?
00:47mupuf_: in the case of karol, pretty sure the POSTing was not enough
00:48mwk: mupuf_: on g80 and up, it lands at end of memory - 128kiB
00:48mwk: although they may have changed it around Kepler, I don't remember
00:48mwk: and yeah, the allocator just ignores this area
00:49mupuf_: so, worst case scenario, we can compute the right value to write in the display register (forgot its address)
00:49mupuf_: and let the blob read from that
02:17drathir: imirkin: there is output from workin mplayer vs not workin mpv strace... https://gist.github.com/47d82c9af9d0cbeccf32 https://gist.github.com/e44b6cda7e03fbc7cea7
02:39thican: Hello everyone! When I tried to visit the website http://get.webgl.org/ with Firefox, my X session freezes completly (except the mouse can still moves), but once I kill the Firefox's process, the session comes back, with this messages in dmesg (I tried twice) https://zerobin.thican.net/?aeadd868a2d87f3a#EiX2dXYKDOv0ZugP9ShDxQcoomatHxTrjWfsqWfSEDA=
02:39thican: It looks like it's related to https://bugs.freedesktop.org/show_bug.cgi?id=70388
02:40thican: (I am currently using an oooollllddd Nvidia graphic card, a MSI card, GeForce 8600GT, released in April 2007 IIRC)
02:40thican: 01:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 GT] (rev a1)
02:41urjaman: well it isnt a TNT2 or smth
02:41thican: my kernel is 4.3.3-hardened-r4 on a x86_64 system
02:41thican: urjaman: I have no idea :/
02:42urjaman: that was a joke, usually i expect something much older when somebody uses that many o's in old ...
02:42thican: Ah :-)
02:43urjaman: (a Riva TNT2 (NV05) is from 1999)
02:43thican: if I was using that, I would have use 20 "o" :D
02:44thican: or 17, to be exact
02:44thican: So, therefore, do you have an idea, how I could "correct" this?
02:44thican: ah yes, I use Mesa version 11.1.1
02:45thican: with VDPAU (and VAAPI) support
02:46thican: I could provide the content of "glxinfo", if requiered (OpenGL renderer string: Gallium 0.4 on NV84)
02:48urjaman: 406040 and a G84 ... yeah sounds like a known thing that happens (also to me on a 9400 GT) but AFAIK nobody has figured out what actually goes wrong and why
02:49thican: Ah :/
02:49thican: Do you think I will have less "problem" with more recent devices?
02:50urjaman: I'm not one of the devs so maybe wait for their opinion, i dunno which are affected and how much.
02:50urjaman: Maybe dont use firefox :P /joke
02:51thican: ok, thanks anyway :-)
02:51thican: RHOOOO! no thanks now!
02:52urjaman:legit switched to chrome here because i was debugging stuff with firefox and it kinda stuck .... you could also disable webgl i guess
02:52thican: Well, indeed, I don't use WebGL
02:52urjaman: but if you went to a site named like that i guess you want webgl ? ...
02:53thican: but still, I won't change Firefox for a opt-in spyware
02:53thican: no, I was just trying
02:53thican: because before, I wasn't able at all
02:53thican: for example, this website and WebGL works
02:54urjaman: imirkin: btw, what happened with that demmt trace i took? useless?
02:54urjaman: (i guess it was useless :P)
02:54thican: here the link http://madebyevan.com/webgl-path-tracing/
02:55thican: it works, until firefox crashes because of the same problem in dmesg
02:55urjaman: ugh, thats reallly laggy here
04:02drathir: thican: im fightin with 8600gts ^^ ;p
04:03drathir: thican: and is still decent power as well... but little hungry one...
04:03drathir: urjaman: tnt2 workin last time was tryin...
04:06drathir: thican: try nightly i sugest...
05:16RSpliet1: gnurou: How likely do you think it is for a Tegra K1 to run with nouveau firmware rather than NVIDIA-provided?
05:18mupuf_: RSpliet1: he tried AFAIR
05:18mupuf_: and it did not work
05:20RSpliet: mupuf_: surely it can't be hard to get that to work
05:20mupuf_: that's what Ben said :p
05:22RSpliet: on karolherbsts headless Kepler, the difference between ctx size on blob vs. nouveau is 12 bytes
05:22RSpliet: that's pretty darn close :-P
05:22mupuf_: ah ah
05:22mupuf_: we need to copy more stuff actually
05:22mupuf_: some perf counters are missing
05:22mupuf_: hakzsam: am I right?
05:23hakzsam: I need time and patience :-)
05:23RSpliet:gives hakzsam some patience
05:23mupuf_: yep, gonna be a funny one :D
05:24mupuf_: RSpliet: Can I get some too? Looking at static analysis reports right now, and my brain is just screaming NOOOOOOOOOOOOOOOOO all the time
05:25RSpliet:hands mupuf_ some sugary jelly babies
05:25mupuf_: fuck yeah!
05:26mupuf: here we go, now I have my real name :D
05:26mupuf: we got donuts and heart-shaped chocolate at the office today
05:27mupuf: for ystävänpäivää ... which litterally means friend's day but actually means valentine's day
05:28thican: drathir: hello back
05:28thican: which "nightly"?
05:29thican: I don't see how it's Firefox's fault
05:29mupuf: he may have meant to try a git version of nouveau
05:31thican: Well, you mean, Mesa, right?
05:31mupuf: what bug do you have?
05:32thican: thican: It looks like it's related to https://bugs.freedesktop.org/show_bug.cgi?id=70388
05:32mupuf: well, mesa would be a good start for this
05:32drathir: thican: btw ff at 8600gts normally show get.webgl.org
05:33thican: Well, it shows it too on mine
05:33thican: but the X session is freezing
05:33thican: Even keyboard is out of order, until I kill Firefox
05:34drathir: thican: You using gamor + dri3?
05:35thican: yes for dri3, not sure for glamor
05:36thican: No, I don't have glamor with the package x11-drivers/xf86-video-nouveau on current stable version 1.0.11
05:36thican: should I?
05:37drathir: thican: no, only wonder if any extra tweaks used...
05:38drathir: i get for glamor [ 19.305] (**) NOUVEAU(0): Invalid AccelMethod specified
05:39drathir: [ 19.495] (II) NOUVEAU(0): DRI3 on EXA enabled
05:39mupuf: glamor is not going to help :D
05:40thican: ok, just I have no idea what it is or what it means
05:41drathir: mupuf: maybe, personally saw on different cards that different accel methods have diff in os performance speed...
05:42mupuf: drathir: definitely
05:42mupuf: but glamor is buggy
05:42drathir: mupuf: sna is supported by nouveau?
05:42mupuf: sna is intel only
05:42drathir: that no choice i see ;p
05:43mupuf: and for nouveau, if you want to use glamor, you should use the modesetting driver
05:43thican: drathir: strange, I see DRI2, but not DRI3 in my /var/log/Xorg.0.log
05:44drathir: [ 21.140] (II) GLX: Initialized DRI2 GL provider for screen 0
05:45thican: [ 72.510] (II) NOUVEAU(0): [DRI2] DRI driver: nouveau
05:45thican: [ 72.510] (II) NOUVEAU(0): [DRI2] VDPAU driver: nouveau
05:45thican: and same line as you, after
05:45drathir: yes correct have this one too...
05:46drathir: cat /etc/X11/xorg.conf.d/20-nouveau.conf heve anything there?
05:47thican: no, as 20, I only have "20opengl.conf"
05:48thican: (and only one other file named "30-keyboard.conf" that I created)
05:48drathir: thats interesting possible to share that conf?
05:48thican: Section "Files"
05:48drathir: opengl one mean
05:49drathir: lol not much ^^
05:49thican: only 2 lines
05:50drathir: Section "Device" Identifier "Nvidia card" Driver "nouveau" Option "Accelmethod" "Glamor" Option "DRI" "3"
05:50thican: the timestamp of the file is the same when I compiled and installed Mesa the last time
05:50thican: ok, I will try
05:50drathir: glamor one not need bc not enable it anyway...
05:50thican: but I don't have glamor
05:51drathir: always if problems able to comment out lines..
05:53thican: so, `Option "Accelmethod" "Glamor"` is a whole line, right?
05:56thican: I asked because I tought "option" was a list of options, not the value of Accelmethod
05:57thican: so, I have to disable the whole line, instead of just removing "glamor"
05:57thican: BRB restart my X session
05:58drathir: y whole line
05:58karolherbst: mupuf: saw my messages about the fan_mgmt table?
05:58mupuf: karolherbst: nope, let me scroll up
05:59mupuf: I will review your PMU patches on sunday
05:59karolherbst: mupuf: thanks :)
06:00mupuf: wonderful for the table
06:00karolherbst: mupuf: sadly I couldn't fake the vbios on your gm107 card so I couldn't play around with the fan_mgmt table, but the gpu/driver seems to use the table
06:00mupuf: karolherbst: so, I got information from mwk about that!
06:00mupuf: read up!
06:00karolherbst: I couldn't check the rpm because nvidia-settings was only telling me the rpm for the second fan
06:01karolherbst: I think it was for the kepler card, or the gpu has tw fans, no clue
06:01karolherbst: mupuf: about what, the fan?
06:01mupuf: and how to compute an address that will not overwrite anything
06:02karolherbst: well I managed to not crash my kernel
06:02mupuf: the last 128k of the RAM is reserved and the TTM allocator won't ewrite there
06:02karolherbst: I wrote a simple module for that
06:02mupuf: so, no need for a module
06:03karolherbst: anyway, if you want to write a module like that, GFP_DMA is the key :D
06:03thican: drathir: unfortunately, it looks like it didn't work :/ (WW) NOUVEAU(0): Option "DRI" is not used
06:03karolherbst: mupuf: okay, and where do we find out where to write?
06:04mupuf: karolherbst: well well, I guess we need a way to probe the RAM size
06:04karolherbst: system ram?
06:06thican: in worg.conf.d(5), I see Option "DRI2" "boolean"
06:06mupuf: karolherbst: nope, VRAM
06:06drathir: thican: how about [ 19.305] (**) NOUVEAU(0): Allowed maximum DRI level 3.
06:06mupuf: karolherbst: please read what mwk said
06:07thican: drathir: no such line :/
06:07drathir: X.Org X Server 1.18.0
06:09thican: ah, yes, I am still at the version 1.17, I wasn't sure if it was useful to be on the version 1.18
06:09thican: as earlier: NOUVEAU(0): Option "DRI3" is not used
06:10drathir: thican: or maybe full reboot needed...
06:10thican: of the service, I did, but of my system? well, why not
06:11thican: I prefer to emerge the new version :-)
06:11drathir: or bc of more fresh xorg... but will be strange bc of card version...
06:19karolherbst: mupuf: okay, so we just have to write into the last 128k of vram and load the driver
06:19mupuf: don't forget to change the register to tell where it is
06:19mupuf: the one that is set to 1 for you
06:20mupuf: and that should be enough
06:20karolherbst: how to I write into vram directly? :D I just remap the vram into virtual ram and then write stuff as if would be normal ram I suppose
06:21mupuf: for that, use PRAMIN
06:21mupuf: reg 1700
06:21mupuf: this is already what fakebios does
06:21thican: Oh come on! This DRI section is a joke! http://www.x.org/archive/X11R7.7/doc/man/man5/xorg.conf.5.xhtml#heading17
06:22karolherbst: mupuf: I have no idea what PRAMIN is exactly though
06:22mupuf: isn't that in readthedocs?
06:23karolherbst: ohh right I could check there
06:24mupuf: but, short version
06:24mupuf: it is a MMIO window
06:24mupuf: into the VRAM
06:24mupuf: and you change the base pointer of the VRAM by changing the reg 1700 IIRC
06:35drathir: thican: still no change?
06:36gnurou: RSpliet: I don't think it would be too hard if someone does some RE
06:36gnurou: RSpliet: the question is, is it worth the trouble
06:38thican: drathir: I am updating x11-base/xorg-server and with it, x11-base/xorg-drivers and x11-drivers/xf86-video-nouveau
06:39drathir: thican: ups bigger update i wish good luck with it...
06:39thican: Well, don't worry
06:39thican: just 20 MiB of source to compile :-)
06:40thican: no, even less, there is an update of something else with it
06:44karolherbst: mupuf: I don't think we need the total vram size though, because 0x0 pramin points to the end of vram anyway
06:44mupuf: I hope it is still true :D
06:44karolherbst: would make it easier
06:45mupuf: I would suggest checking the address that is in the reg vs what you compute
06:45mupuf: to make sure of your understanding
06:53RSpliet: gnurou: well, I guess the Libre people might appreciate it, I personally tend to remain neutral on that discussion
06:54mupuf: RSpliet: the libre people get rid of our open source firmwares too IIRC :D
06:54RSpliet: mupuf: that's probably because they're silly :-P
06:55RSpliet: gnurou: but I'm currently doing a bit of research towards context switching, so I find it rather interesting to look at... maybe I'll give it a go if it's nothing more than defining the right registers and strands
06:55karolherbst: mupuf: ohh we checked that again, they do not
06:55mupuf: karolherbst: ah, you did check it
06:55karolherbst: I jumped to fast into conclusions
06:55mupuf: I did not
06:55mupuf: ok, good
06:55karolherbst: I downloaded the libre source
06:55karolherbst: video firmware is disabled
06:55RSpliet: karolherbst: okay, then I hereby withtract my statement, they're not silly anymore
06:55karolherbst: the upload mechanism is patches unusable
06:56karolherbst: they look for a file name "<DEBLOBBED>" or something like that ;)
06:56gnurou: RSpliet: sure, it would be certainly educating and cannot be too different from what other keplers do
06:56karolherbst: what parts do you want to RE by the way?
06:56drathir: thican: how about gpu accelerated mpv play ?
06:57karolherbst: drathir: it should work as long as you don't use the gl version
06:57karolherbst: or a deblobbed kernel
06:57drathir: thican: mpv --hwdec=vdpau workin for You?
06:58karolherbst: drathir: well for me mplayer wors fine with vdpau
06:58drathir: karolherbst: 11:17 drathir: imirkin: there is output from workin mplayer vs not workin mpv strace... https://gist.github.com/47d82c9af9d0cbeccf32 https://gist.github.com/e44b6cda7e03fbc7cea7
06:58drathir: karolherbst: the mystery is mplayer workin mpv dont ^^
06:58thican: drathir: yeah, mpv works
06:59drathir: mpv give black screen...
06:59karolherbst: drathir: can you use the vdpau ffmpeg thing?
06:59karolherbst: not ffh264
06:59thican: well, strange, I have the line "Using software decoding." with the option --hwdec=vdpau
07:00thican: without, I don't have this line
07:00thican: BRB, Xorg compilation is done :-)
07:00orbea: do you have the nvidia firmware?
07:00orbea: you can't use hwdec without it
07:00drathir: karolherbst: https://gist.github.com/54a56884ecf18eae39ba
07:00orbea: anways mpv doesn't work well with nouveau currently
07:01karolherbst: try hwdec=vdpau and vo=vdpau
07:01drathir: thican: vainfo dpauinfo?
07:01orbea: vo=opengl-hq works fine in mpv
07:02orbea: well, as fine as mpv works in nouveau
07:02drathir: orbea: checkinn...
07:02karolherbst: no, I meant both --hwdev=vdpau _and_ --vo=vdpau
07:02orbea: only need hwdec=vdpau for mpv
07:02orbea: but if you get it working, make sure you dmesg is not getting spammed when watching videos
07:03drathir: karolherbst: correct workin with booth 16:02 < karolherbst> no, I meant both --hwdev=vdpau _and_ --vo=vdpau
07:03karolherbst: drathir: ahh okay, so it does use vdpau on the nvidia card with nouveau if you set both to vdpau
07:04thican: orbea: still the line "Using software decoding.", but indeed, I see "VO: [vdpau]" instead of "VO: [opengl]"
07:04orbea: mpv/novueau issues to watch out for https://github.com/mpv-player/mpv/issues/2798 & https://github.com/mpv-player/mpv/issues/2757
07:04drathir: karolherbst: yes its report correct hw decoding enabled...
07:04karolherbst: drathir: nice
07:04orbea: do you have the nvidia firmware?
07:04thican: orbea: yes, I have installed it, not sure if it works
07:04orbea: what video
07:05orbea: video format I mean
07:05karolherbst: thican: well you can't use every video with vdpau
07:05thican: the video I play with MPV?
07:05orbea: mpv removed a lot of hwdec support mplayer had for older formats
07:05thican: this? " (+) Video --vid=1 (mpeg4)"
07:06drathir: orbea: opengl-hq too blank screen...
07:06orbea: how about just opengl then?
07:06drathir: orbea: the same is at default used...
07:07drathir: looks like --vo=vdpau only workin...
07:07orbea: as much as I like mpv, mplayer will be easier...
07:08thican: drathir: vainfo dpauinfo http://paste.alacon.org/39578
07:08drathir: orbea: only need place in config 2 lines...
07:09thican: I don't have the command "vdpauinfo"
07:09orbea: why are you using libva? I thoguht that was for intel mostly
07:09thican: ah, I have to install it, BRB
07:10thican: drathir: vdpauinfo http://paste.alacon.org/39579
07:11karolherbst: okay, that looks wrong
07:12karolherbst: no video format supported
07:12drathir: thican: k looks like the same fw is missing check in dmesg
07:12thican: maybe too old card?
07:12karolherbst: check dmesg
07:13thican: drathir: indeed, I will paste what I found
07:17thican: those msg happend when I invoke the command "vdpauinfo"
07:17karolherbst: you need the nvidia video firmware
07:17drathir: thican: correct the same what i have...
07:17karolherbst: thican: https://nouveau.freedesktop.org/wiki/VideoAcceleration/
07:17karolherbst: "firmware" section
07:17thican: not sure if I understand correctly, but this is a "problem" with the driver in the kernel, right?
07:18drathir: i can point to aur package...
07:19karolherbst: thican: no, it is just nvidia being a dick and letting us not distribute the video firmwares
07:19thican: karolherbst: I already installed the package for my distribution :/
07:19karolherbst: thican: ls /lib/firmware/nouveau/
07:20thican: karolherbst: http://paste.alacon.org/39581
07:20karolherbst: nv84_xuc103@ ..
07:20karolherbst: why the @?
07:20orbea: does arch even use /lib? they're installing it in /usr
07:21karolherbst: mupuf: ?
07:21mupuf: karolherbst: yes?
07:21thican: karolherbst: it means it's a symlink
07:21karolherbst: your arch pacakge produces crazy file names
07:21karolherbst: thican: ahh
07:21orbea: yea, its prolly a symlink
07:21karolherbst: please check
07:21thican: currently to nv84_vp
07:21mupuf: hmm. regression I guess
07:21karolherbst: why doesn't the kernel load those files then
07:22karolherbst: nouveau/nv84_xuc103 this file is there
07:22drathir: lrwxrwxrwx 1 root root 7 Sep 30 21:17 lib -> usr/lib
07:23karolherbst: yeah no idea, I am also no arch user and it is mupuf package anyway :p
07:23orbea: did you already say waht card? some cards just dont work with teh fw, right?
07:24drathir: mine configured 8600gts
07:26karolherbst: drathir: do you compile your own kernel?
07:26thican: karolherbst: well, I will try to add the modules to load during boot
07:26karolherbst: orr right thican has the issue, sorry :D
07:26mupuf: karolherbst: I do get a nv84_xuc103
07:26mupuf: but how is that invalid?
07:26karolherbst: mupuf: I was confused by ls making that to nv84_xuc103@
07:27mupuf: ack :)
07:27thican: karolherbst: I compiled my own kernel
07:27orbea: it was prolly just coreutils and their new defaults
07:27karolherbst: especially becuase "@" is a valid filename
07:27thican: karolherbst: it's "--show-control-chars" from ls
07:28orbea: i had to alias ls to ls -N because they decided to break has has been working for ages
07:28karolherbst: oh yeah, I don't want to care about stuff like that, if a file happens to be a symlink, I don't care
07:28drathir: karolherbst: no arch default one...
07:28karolherbst: thican: you could try to compile those fiirmware files into the kernel
07:28thican: bruh, sorry, it's the option "--classify"
07:28karolherbst: thican: just add them to the firmware list
07:29karolherbst: thican: CONFIG_EXTRA_FIRMWARE
07:29karolherbst: set it to "nouveau/nv84_xuc00f nouveau/nv84_xuc103"
07:30karolherbst: and CONFIG_EXTRA_FIRMWARE_DIR should be /lib/firmware
07:36kisak: howdy, random webadmin feedback, the Page History link on https://nouveau.freedesktop.org/wiki/FeatureMatrix/ is dead
07:37kisak: mmm ... it's all the page history pages?
07:38imirkin_: kisak: hm yeah... should probably let #freedesktop know
07:38mwk: mupuf: umm, the NV1 doc you're pointing at only describes NV1 PRAMIN
07:38imirkin_: we don't admin that directly
07:38mwk: NV3 is different, NV4:G80 is different, and G80+ is entirely different
07:41mupuf: mwk: yeah, hence why I said: If it did not change :p
07:41mupuf: but sure, thanks for the precision :)
07:42thican: Oh! I don't have the dmesg errors in dmesg if I execute vdpauinfo as root!
07:43drathir: thican: and show it support?
07:43thican: and the content of "Decoder capabilities" from "vdpauinfo" is not empty!
07:43karolherbst: thican: I guess you have to be in the video group or something
07:43drathir: something isnt right?
07:43karolherbst: maybe udev says something in its logs?
07:44thican: karolherbst: I am in video group
07:44karolherbst: then check udev log
07:44drathir: thican: thats correct output...
07:45karolherbst: thican: and you should check if building the fimrware files into your kernel changes anything
07:45karolherbst: because if it works as a user with the files in the kernel it is the fault of udev I think, or does something else loads the firmware in userspace?
07:46thican: I have very low knowledges of modules and firmwares :/
07:46karolherbst: thican: yeah, that's why I told you what to do :p
07:46karolherbst: CONFIG_EXTRA_FIRMWARE="nouveau/nv84_xuc00f nouveau/nv84_xuc103" and CONFIG_EXTRA_FIRMWARE_DIR=/lib/firmware
07:47karolherbst: and then just rebuild your kernel and install it
07:49thican: yes, thanks, but I tought there was a way to work without recompiling it :/
07:50thican: because it works as root, so it should work as simple user, right?
07:50karolherbst: thican: well do you know why it doesn't work as a user?
07:50karolherbst: system logs can tell you and maybe udev prints an error, but I have no clue otherwise
07:51thican: what about this ? drwxr-x--- 74 root root 12288 févr. 2 03:05 /lib/firmware/
07:51thican: should it be (and its content) as 0644 ?
07:51karolherbst: check the system logs
07:52thican: I didn't find any :/
07:52thican: except in dmesg
07:53thican: FOUND! :D
07:53thican: it was the right on the directory \o/
07:54karolherbst: stupid udev :/
07:54thican: chmod o=rX on the directory, and it works!
07:54thican: it's not udev, who gave the rights on the directory /lib/firmware/
07:54thican: but the tool who "installed" the content
07:54karolherbst: well udev loads the firmware usually
07:54karolherbst: and udev runs as root
07:55thican: on my system, my umask is 027
07:55thican: well, yes
07:55thican: but why isn't it working once root already execute "vdpauinfo", therefore?
07:55thican: why does it need to be reloaded, again?
07:55karolherbst: no idea
07:55drathir: 1920x1080 smothly playing....
07:56drathir: drwxr-xr-x 80 root root 12K Feb 10 15:34 firmware
07:56karolherbst: maybe udev is a bitch or maybe firmware can be set as a per user base, no idea
07:56karolherbst: open a bug on on the systemd bugtracker for this and ask why it matters
07:57orbea: i use eudev on my arch ^_^
07:57drathir: thican: now user vdpau workin?
07:57thican: karolherbst: I don't use systemd
07:57drathir: thican: ++
07:57karolherbst: thican: you use udev, it's part of systemd
07:58thican: karolherbst: eudev, the fork
07:58karolherbst: ohh k
07:58karolherbst: mhh then open a bug against eudev and ask them why
07:58thican: but, I think it's the packet manager's problem
07:58karolherbst: yeah in the end it may
07:58thican: who didn't pay attention to umask, when creating the directory
07:58karolherbst: but I don't know why the access rights on the firmware should matter
07:58orbea: you could install teh firmware mnanually and see if that makes a diff
07:58RSpliet: karolherbst: to prevent loading firmware that was installed by an arbitrary user?
07:59thican: me neither x(
07:59karolherbst: RSpliet: we are talking about read rights
07:59thican: RSpliet: only root may write
07:59karolherbst: RSpliet: usually only root can write there, but eudev seems to block it when the user can't reat
07:59karolherbst: no idea why
07:59thican: but "anyone" can read the content
08:00orbea: ls -l /lib/firmware/nouveau ?
08:00drathir: thican: and if correct report check mpv and web browser...
08:00thican: drathir: do you talk about vdpauinfo? I have now the same list as root, and no more dmesg message :-)
08:01thican: orbea: http://paste.alacon.org/39586
08:01thican: I cheated, I did "chmod -R o=rX /lib/firmware/"
08:02orbea: it looks fine now
08:02orbea: as far as permissions go
08:02thican: yes, mostly a problem because of my "specific" umask
08:03drathir: thican: also You now can check dri 3
08:04thican: Haha, yes, I was forgetting
08:04drathir: and website mean ff stuck...
08:14thican: drathir: Well, now I have `(**) NOUVEAU(0): Allowed maximum DRI level 3.` instead of "2", but my X session is still freezing with WebGL
08:15thican: Well, I never use WebGL, instead for testing the abilities with Mesa
08:15thican: Anyway, thanks drathir, karolherbst and orbea :-)
08:16imirkin_: karolherbst: fyi, for pre-VP5, mesa needs access to the video firmware too
08:17karolherbst: imirkin_: ohhhh
08:17karolherbst: yeah then it makes sense
08:17imirkin_: and it hardcodes /lib/firmware, so none of this /usr/lib/firmware bs
08:21thican: imirkin_: so, putting other id as "rX" is "mandatory", right? I will make a bug report for my distribution, to warn them about the creation and installation of /lib/firmware/ …
08:22imirkin_: and rather similar logic in https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nv50/nv84_video.c#n100
08:23imirkin_: if there's a good way to make that distro-specific, i'm happy to enable that
08:23imirkin_: maybe a --with-firmware-prefix flag for mesa? dunno
08:23imirkin_: but i never put this stuff anywhere but /lib/firmware, so... my level of worry about it is quite low
08:24imirkin_: thican: one could argue that this is an abuse of the system, but.... meh.
08:25imirkin_: thican: it works well enough, this is the first time i've heard of /lib/firmware not being user-accessible
08:26karolherbst: imirkin_: I bet udev knows
08:26imirkin_: karolherbst: udev is usually not used for loading firmware
08:26karolherbst: who else?
08:26imirkin_: karolherbst: the linux kernel has a bunch of fallbacks, we could implement that
08:27karolherbst: imirkin_: udev calls firmware_helper when the kernel requests userspace to take care of the firmware
08:27imirkin_: all the firmware helper stuff is total bs
08:28imirkin_: normal kernels don't use that
08:28imirkin_: it just causes issues without any benefits
08:28karolherbst: right, but you know systemd and the other guys :p
08:28imirkin_: it got demoted to off-by-default around 3.10 or so
08:29imirkin_: +/- 5 :)
08:34karolherbst: imirkin_: linus was "unhappy" about a udev change and removed userspace firmware loading in 3.7 :D
08:35karolherbst: well kind of removed
08:36drathir: thican: yw im too learn there a lot...
08:37drathir: thican: extra/mesa 11.1.1-1
08:38thican: Well, I would like to avoid using the dev version
08:38thican: waiting for the next "true" version :-)
08:39drathir: thican: its in arch stable ^^
08:40drathir: extra/mesa 11.1.2-1 or even now...
08:41orbea: arch stable, heh
08:42drathir: extra/firefox 44.0.1-1
08:43drathir: orbea: /me see You never used arch,bc of sayin that ^^
08:43drathir: its a myth...
08:43orbea: yea, my t420 laptop doesn't have arch on it, its imaginary
08:43drathir: arch for real is stable as rock...
08:44orbea: maybe if the rock is limestone
08:45drathir: 6+y first install still runnin, only refreshed bc new hdd and honestly it could be one big nukes polygon ;p even not remember what was modified ;p
08:46orbea: i'm n ot saying my arch doesn't work, but that is no thanks to the arch maintainers
08:46drathir: oh i see...
08:48orbea: im mostly a slackware user and arch honestly seems sloppy to me, but they repo is useful for a package maintainer. Easy to find things eay to try to see if its worth making a slackbuild for
08:48orbea: I should stop trying to type with this 2 second lag...
08:48drathir: thican: thats interesting why do that...
08:49drathir: orbea: easy not problem for me...
08:50RSpliet: please try and avoid distro-discussions, they're mostly irrelevant for (upstream) nouveau
08:51orbea: i didn't realize their was any nouveau discussio we were impeding...
08:51drathir: RSpliet: sorry i will remember about that...
08:54RSpliet: orbea: this is a logged channel, analysing logs becomes harder when more off-topic talk takes place. Diverging a bit is not an issue, but in my experience distro's are a sensitive topic and I'd rather avoid escalation. No hard feelings otherwise ;-)
08:55orbea: well, w/e, just not how i would run a channel...
08:55drathir: RSpliet: fully understand now and have no offence at all...
10:02t4nk839: Hi, can anyone help me here to raise my cards performance mode. I have flickering in vertical and glitches from time to time when using multiple monitors.
10:04imirkin_: what gpu?
10:05imirkin_: lspci -nn -d 10de:
10:06t4nk839: 01:00.0 VGA compatible controller : NVIDIA Corporation GF108M [NVS 5400M] [10de:0def] (rev a1)
10:06imirkin_: there's no performance level switching for fermi, sorry
10:06imirkin_: however most artifacts tend to be caused by the intel ddx in your situation
10:07t4nk839: so I have no chance to get rid of them?
10:08imirkin_: what versions of Xorg, xf86-video-intel, xf86-video-nouveau do you have?
10:10t4nk839: xorg is at 1.17.1
10:11t4nk839: any quick way to tell about the others
10:13imirkin_: pastebin xorg log
10:23imirkin_: looks like nouveau 1.0.11 and intel 2.99.917
10:24imirkin_: i'd very much recommend updating xorg to 1.17.4 (or 1.18) and grabbing a copy of the intel ddx from git
10:27t4nk839: alright thx a lot imirkin, I'll try that out
16:52jeremySal: imirkin: did you take a look at the traces?
22:19mooch: imirkin_: do you know how the plls on nv4 work?
23:13mooch: also, what's all this stuff about fifos on in the crtc registers?