[09:18] <garpy> v
[16:28] <kermit_> hello! Does anybody maybe know where /usr/libexec/colord resides in Ubuntu?
[16:29] <mlankhorst> ~$ dpkg-query -S colord
[16:29] <mlankhorst> afk
[16:35] <kermit_> @mlankhorst tnx. I'm guessing it will be /usr/lib/x86_64-linux-gnu/colord then.
[16:35] <udevbot> Error: "mlankhorst" is not a valid command.
[16:36] <kermit_> mlankhorst: tnx. I'm guessing it will be /usr/lib/x86_64-linux-gnu/colord then.
[18:24] <cjwatson> kermit666: /usr/lib/$(DEB_HOST_MULTIARCH)/colord/colord, by the looks of things, where $(DEB_HOST_MULTIARCH) is approximately the GNU triplet for the current architecture.
[18:25] <cjwatson> Though I'd have thought it would be a broken thing to do to rely on the path of something in libexecdir ...
[18:27] <cjwatson> The path is in the D-Bus system-services configuration for org.freedesktop.ColorManager
[18:28] <kermit666> cjwatson: thanks. Yes, I found it under /usr/lib/x86_64-linux-gnu/colord/colord and it seems to work. I was pointed to start the daemon like this by the upstream developer.
[18:31] <cjwatson> They presumably have some reason, but generally you are just meant to talk to the D-Bus service and let D-Bus automatically start it.
[18:31] <cjwatson> Perhaps they're trying to have you start it with some particular options or environment.
[18:32] <cjwatson> I'm just warning you not to hardcode that path in any scripts you distribute.
[18:35] <kermit666> cjwatson: sure. I think the reason is they can't collect the log files without me running systemd, so I had to run it manually with a -v flag and collect the output. https://bugzilla.gnome.org/show_bug.cgi?id=690349
[18:43] <cjwatson> OK
[19:51] <infinity> tjaalton: Remember how you couldn't reproduce that SandyBridge GPU lockup?  I've just gotten it twice in a row while swithing workspaces in Unity.  Just sprinkle some gnome-terminals and firefoxes (probably not required, but that's my desktop) around the place, and zip around with Ctrl-Alt-Arrows for a bit.
[21:35] <tjaalton> infinity: hmm ok, i do use that though, but will try harder
[22:26] <blami> infinity: btw. I had plenty of GPU lockups on my T420, not sure if it will help someone but I get rid of them by disabling VT-d IOMMU extension either in bios or by passing intel_iommu=something to kernel
[22:27] <blami> infinity: (when on intel only ofc as it is optimus system)
[22:58] <infinity> blami: Hrm.  I'll have to look for that BIOS setting.
[22:58] <infinity> tjaalton: Did you see the above?
[22:59] <blami> infinity: on thinkpads its in security/virtualization
[23:03] <RAOF> infinity: Intel has long had problems with the interaction between vt-d and other features (most recently, rc6)
[23:04] <blami> infinity: I can test a little more if you need. I have two t420's here putting some nouveau wmi patches together so I reboot very often
[23:04] <blami> RAOF: I remember terrible lockups in times of last 2.6 lines and then it was good up to 3.5 i believe
[23:05] <RAOF> I thought rc6-vs-VT-d was settled much later than 3.0.
[23:05] <RAOF> We may have simply quirked one of them off
[23:06] <blami> RAOF: also I believe only minority of software uses vt-d, right?
[23:07] <blami> RAOF: only thing I use and know it can benefit from vt-d enabled is vbox
[23:07] <RAOF> AFAIK it's only useful in to virtualise a PCI resource.
[23:09] <blami> RAOF: I'm not sure if I got it correctly but all that gpu offloading stuff using shared-buf can also use iommu to improve throughtput if one of gpus uses system memory area
[23:10] <blami> RAOF: but I'm not sure if it's already part of kernel drivers and userspace, it's pretty new I think
[23:11]  * RAOF is not sure how the iommu could come into play there, as the GPU has its own.
[23:11] <blami> on the other side when I have vt-d enabled and using nvidia only setting in bios even windows freeze
[23:11] <RAOF> But there's plenty I don't understand about the mysteries of the GPU
[23:13] <blami> RAOF: I probably misinterpreted this. I'm trying to learn about gpu and nouveau-devel is definitely good place to do so but sometimes I really don't understand anything :)
[23:13] <RAOF> There's always our very own mlankhorst :)
[23:14] <blami> :)
[23:21] <infinity> blami: I'll be sure to check that and turn it off the next time I reboot my 420s.  I'm somewhat sick of getting the same apport popup several times per day. :P
[23:21] <infinity> Actually, maybe I'll do that now.
[23:22] <blami> infinity: is it intel only or optimus (just curious)
[23:23] <infinity> Optimus, but I run it in Intel-only mode.
[23:25] <blami> infinity: be sure you have latest bios. It is probably firmware bug rather than kernel bug (imo).
[23:25] <blami> infinity: some folks on thinkpad forums reported that freezes dissapeared with newer version of firmware (but I can still reproduce even with latest)
[23:26] <infinity> blami: I updated the BIOS fairly recently to see if it would fix it, no luck.
[23:26] <infinity> Anyhow, rebooted, Vt-d turned off, we'll see how the behaves.
[23:27] <infinity> s/the/that/
[23:31] <penguin42> infinity: Is the 420 Intel only?
[23:31] <blami> penguin42: it depends
[23:32] <blami> penguin42: there are models with discrete nvidia and models withou
[23:32] <blami> penguin42: even on the models with nvidia card you can disable it (if you're ok with crippled multihead then)
[23:32] <penguin42> blami: ah, I'm unfortunate enough to use a 520 that has both, and it's a pit*
[23:33] <blami> penguin42: t420 is almost same
[23:33] <penguin42> blami: On the 520 the external VGA is only connected to the nvidia so if you want the external you need to use discrete nvidia (or optimus)
[23:33] <blami> penguin42: I bought it because I wanted tripple head at work but t420 has everything hardwired to nvidia except lvds
[23:34] <blami> penguin42: in case of t420s situation is a little better as lvds switches between nvidia and optimus regarding the bios setu
[23:34] <blami> p
[23:34] <blami> penguin42: so I am running optimus setup and when presenting or want multihead I launch another xserver on nvidia card
[23:35] <penguin42> blami: Yeh, I run the 520 in discrete mode with nouveau, turn gl off in KDE and it survives
[23:35] <penguin42> blami: I also need to pass noapic, otherwise it hard hangs most of the time apparently losing all interrupts - but only when in discrete mode
[23:35] <blami> penguin42: redhat guys are working on this. There should be gpu offloading and muxed xrandr in 1.14
[23:36] <penguin42> yep
[23:36] <blami> penguin42: hopefully nvidia will adopt this and release 1.14 drivers with support for prime framework
[23:36] <blami> penguin42: as I don't believe they will support wayland
[23:37] <blami> where ofc multihead handling is not decided yet
[23:37] <blami> as well as many other things
[23:37] <penguin42> blami: I need my extra pixels :-)
[23:39] <blami> penguin42: :)
[23:40] <blami> *30 line situation is better as they decided to hardwire only to intel card
[23:41] <blami> but they definitely killed the keyboard so I bought as much t420's as I could :)
[23:44] <penguin42> blami: The big escape key on the 520 is kind of nice for us vi users :-)
[23:45] <blami> yep :)
[23:45] <blami> penguin42: I really mourn about next/prev pages around arrows
[23:46] <blami> penguin42: I use them to switch workspaces in unity and they replaced'em with pgup/pgdn
[23:46] <penguin42> oh I could live with that
[23:51] <RAOF> penguin42, blami: You should be able to do gpu offloading & xrandr in Ubuntu 12.10; the GPU offloading bit at least works here.
[23:52] <blami> RAOF: using xrandr gpu providers? whoa even fedora does not support that yet
[23:52] <penguin42> RAOF: Nope, doesn't work on 12.10
[23:52] <penguin42> RAOF: xrandr sees both cards but won't let you enable the external vga
[23:52] <RAOF> penguin42: What part? The offloading bit should (and, indeed, does here) work.
[23:53] <blami> xrandr --listproviders causes Segmentation fault ...
[23:53] <penguin42> RAOF: ok, what do you mean by offloading and how would I know it's working
[23:54] <RAOF> penguin42: Run DRI_PRIME=1 glxinfo; check that the renderer string is nouveau.
[23:54] <RAOF> Then you can run whatever apps you want with DRI_PRIME=1 set, and they'll run on your nvidia.
[23:55] <penguin42> RAOF: OK, but I don't think I can get it to bring up the external display except in nouveau mode; I think it listed both providers in xrandr but wouldn't let me turn the external one on
[23:55] <RAOF> Ok. I've not tested that, as my T420s died tragically.
[23:56]  * penguin42 hates to think
[23:56] <penguin42> RAOF: I believe it's expected behaviour on 12.10, xrandr knows it's there but won't allow it to be enabled
[23:57] <blami> penguin42: correct. I'm not sure but sinks code has not been even written yet. This only ofloads gpu and in somehow magical combination of Xorg and kernel drivers it probably works
[23:57] <RAOF> The sinks code should be there; it's essentially the same as displaylink support, which (apparently) works.
[23:57] <blami> penguin42: but to see outputs of all cards present and mux them in single xrandr configuration is definitely not possible yet
[23:58] <blami> RAOF: for displaylink maybe
[23:59] <blami> RAOF: only thing presented so far by redhat was offloading of gpu intensive operations from displaylink device (which actually still managed "displaying" of output) to intel gpu (which managed "calculations" only)