IRC Logs of #dri-devel on irc.freenode.net for 2015-08-04


Previous dayChoose dateNext day Show menu

00:24 #dri-devel: < degasus> imirkin: I did some dirty hacking, and u8vec4 arith was accepted by the nvidia driver. Sounds like a spec bug
00:51 #dri-devel: < danvet_> tagr_, do you have a bit of time to take a look at "[PATCH 1/4] drm/atomic-helper: Add an atomice best_encoder callback" and ack it?
00:51 #dri-devel: < danvet_> all 3 drm patches in there I mean
00:51 #dri-devel: * danvet_ wants to send a pull to linus later today with that series
01:53 #dri-devel: < zogi> MrCooper: ok, sorry.
01:57 #dri-devel: < tagr> danvet_: done
01:59 #dri-devel: < danvet_> tagr, thx a lot
01:59 #dri-devel: < danvet_> btw docbook limitations are getting fixed by danilocesar
01:59 #dri-devel: < danvet_> [PATCH] scripts/kernel-doc Allow struct arguments documentation in struct body
02:00 #dri-devel: < tagr> danvet_: on a quick look I can't find any legitimate cases where a connector's ->crtc would be NULL, though I seem to remember having to add special code in the Tegra driver to prevent NULL dereferences
02:00 #dri-devel: < danvet_> tagr, yeah there's really no legit case
02:00 #dri-devel: < tagr> but perhaps I'm misremembering, or things have changed in the meantime
02:00 #dri-devel: < danvet_> but it seems to be the place where it all falls apart if there's a bug somewhere
02:00 #dri-devel: < danvet_> and yeah I think we had a case with tegra blowing up there too
02:00 #dri-devel: < danvet_> plus at least a few with i915
02:01 #dri-devel: < danvet_> and iirc it was fireworks in there too when I hacked on exynos
02:01 #dri-devel: < tagr> hmm... perhaps this was plane atomic functions after all, we still have code there to deal with NULL CRTCs, which happens in the disable case
02:04 #dri-devel: < glennk> anholt, jekstrand, i'm reminded of http://research.swtch.com/sparse for avoiding some setup time in register allocators
02:05 #dri-devel: < tagr> danvet_: I still need to look at the kerneldoc patches
02:05 #dri-devel: < tagr> last time I looked there was talk of pandoc, which made me go: eww!
02:05 #dri-devel: < danvet_> tagr, there's still pandoc in there
02:05 #dri-devel: < danvet_> as the markdown->docbook converter
02:09 #dri-devel: < tagr> pandoc seems to be weird and non-standard, I wonder if we could make it work with a standalone tool that would process a subset of markdown features that we need in the kernel
02:11 #dri-devel: < danvet_> well I don't really want to write such a converter
02:22 #dri-devel: < cornair> hello, I want to dump the whole VBT and want to attach it accordingly to the fdo bug entry 90469. to dump the vbt, which tool of the intel-gpu-tool should I use ? intel_reg_dump??
02:28 #dri-devel: < tagr> danvet_: it's just that it has loads of dependencies, and the distribution that I use doesn't provide it, either
02:29 #dri-devel: < danvet_> tagr, you can still generate docs, they simply look a bit more meh
02:29 #dri-devel: < tagr> I'm perhaps not a good statistical sample, but there might be others in the same situation
02:29 #dri-devel: < cornair> also the dsi sequence parser, how is it called ? intel_gpu_dump is NOT in the package, yesterday I compiled igt from git - there is also no intel_gpu_dump anymore, so how do you dump the VBT and the DSI??
02:30 #dri-devel: < danvet_> tagr, and what distro is that?
02:41 #dri-devel: < tagr> danvet_: Arch Linux
02:41 #dri-devel: < danvet_> not even in AUR?
02:41 #dri-devel: < tagr> AUR has it, but it seems to have strange packaging
02:41 #dri-devel: < danvet_> I thought arch was generally the thing that has everything
02:41 #dri-devel: < tagr> I haven't looked at the patches yet, but perhaps it'd be easy to substitute something else for pandoc, depending on the users setup?
02:42 #dri-devel: < tagr> I think Debian is generally the thing that has everything =)
02:42 #dri-devel: < danvet_> yeah that would certainly be possible
02:42 #dri-devel: < danvet_> problem might be that we'll end up with certain slightly incompatible markdown dialects
02:42 #dri-devel: < danvet_> but that's already a risk with just different versions of the same parser
02:43 #dri-devel: < tagr> danvet_: there's this: https://github.com/MSmid/markdown2docbook
02:43 #dri-devel: < tagr> which looks really interesting
02:44 #dri-devel: < tagr> the advantage being that it's plain XSL, so it should pretty much work with what you need for the rest of DocBook -> HTML anyway
02:44 #dri-devel: < tagr> dependency-wise I mean
02:44 #dri-devel: < tagr> not sure how easy it would be to integrate, though
02:45 #dri-devel: < danvet_> seems to pull in an equally impressive list of depencies I think
02:45 #dri-devel: < danvet_> and debian doesn't have it ;-)
02:49 #dri-devel: < tagr> hmm? xsltproc should do it, and you need that for DocBook -> HTML already anyway
02:51 #dri-devel: < tagr> danvet_: anyway, this is all great work and very much needed, so: thanks!
02:52 #dri-devel: < tagr> danilocesar: ^^ goes for you too, of course
02:52 #dri-devel: < danvet_> tagr, hm right we need an xsltproc anyway
02:56 #dri-devel: < tagr> danvet_: anyway, I can try giving that a spin, based on danilocesar's patches if I really want to see beautified output
04:36 #dri-devel: < linkmauve1> tagr, if you don’t want to compile pandoc yourself, there is pandoc-bin in AUR which extracts pandoc from the .deb package they provide upstream.
04:36 #dri-devel: < linkmauve1> I find that pretty ugly, but it doesn’t have any runtime dependency other than gmp and zlib.
04:37 #dri-devel: < tagr> linkmauve1: oh, so the Haskell dependency goes away? how do they do that?
04:38 #dri-devel: < linkmauve1> ghc compiles the runtime in the binary, it only requires a libc.
04:38 #dri-devel: < tagr> ah, I see
04:38 #dri-devel: < linkmauve1> It’s still Haskell code that gets compiled, just like you don’t need gcc to be installed to run a C program.
04:39 #dri-devel: < tagr> I thought Haskell had some sort of runtime library as well, much like libgcc
04:40 #dri-devel: < linkmauve1> ghc usually embeds that into the final binary.
04:41 #dri-devel: < tagr> I don't mind very much building from source myself (provided the instructions work), I'm just wondering if it's a good idea to (potentially) require everyone working on the kernel to do the same
04:42 #dri-devel: < tagr> if it's too complicated, people will just not install it and end up with the "ugly" documentation, and that has the downside of the markdown not getting the coverage it probably should
04:45 #dri-devel: < linkmauve1> tagr, your assumption is that distributions don’t provide pandoc because yours don’t, I can see packages in Debian, Ubuntu, Fedora, and probably many more.
04:45 #dri-devel: < linkmauve1> Ask your distribution’s maintainers to support it too. :)
04:57 #dri-devel: < cornair> how can I dump the intel video bios ? I tried intel_bios_dumper, but all I got is Couldn't read graphics card ROM: Input/output error
04:57 #dri-devel: < cornair> drm is enabled, only blackscreen, so I am logged in via ssh to do or try to do the dump
 

Written by Christoph Brill © 2007-2015

Valid XHTML 1.0 Transitional

Available in Android Market