| === cpg|away is now known as cpg | ||
| === cpg is now known as cpg|away | ||
| === cpg|away is now known as cpg | ||
| === frogman is now known as mthaddon | ||
| garpy | v | 09:18 |
|---|---|---|
| === rsalveti_ is now known as rsalveti | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === cpg is now known as cpg|away | ||
| === yofel_ is now known as yofel | ||
| kermit_ | hello! Does anybody maybe know where /usr/libexec/colord resides in Ubuntu? | 16:28 |
| mlankhorst | ~$ dpkg-query -S colord | 16:29 |
| mlankhorst | afk | 16:29 |
| 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:35 |
| kermit_ | mlankhorst: tnx. I'm guessing it will be /usr/lib/x86_64-linux-gnu/colord then. | 16:36 |
| === tkamppeter_ is now known as tkamppeter | ||
| 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:24 |
| cjwatson | Though I'd have thought it would be a broken thing to do to rely on the path of something in libexecdir ... | 18:25 |
| cjwatson | The path is in the D-Bus system-services configuration for org.freedesktop.ColorManager | 18:27 |
| 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:28 |
| 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:31 |
| cjwatson | I'm just warning you not to hardcode that path in any scripts you distribute. | 18:32 |
| 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:35 |
| ubottu | Gnome bug 690349 in Color "Selected color profile won't stay applied" [Normal,Needinfo] | 18:35 |
| cjwatson | OK | 18:43 |
| === TerminX_ is now known as TerminX | ||
| 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. | 19:51 |
| === SudoKing is now known as SudoKing[A] | ||
| === SudoKing[A] is now known as SudoKing | ||
| === Tonio_ is now known as Tonio_aw | ||
| tjaalton | infinity: hmm ok, i do use that though, but will try harder | 21:35 |
| === cpg|away is now known as cpg | ||
| 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:26 |
| blami | infinity: (when on intel only ofc as it is optimus system) | 22:27 |
| infinity | blami: Hrm. I'll have to look for that BIOS setting. | 22:58 |
| infinity | tjaalton: Did you see the above? | 22:58 |
| blami | infinity: on thinkpads its in security/virtualization | 22:59 |
| RAOF | infinity: Intel has long had problems with the interaction between vt-d and other features (most recently, rc6) | 23:03 |
| 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:04 |
| 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:05 |
| blami | RAOF: also I believe only minority of software uses vt-d, right? | 23:06 |
| 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:07 |
| 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:09 |
| blami | RAOF: but I'm not sure if it's already part of kernel drivers and userspace, it's pretty new I think | 23:10 |
| * 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:11 |
| 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:13 |
| blami | :) | 23:14 |
| 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:21 |
| blami | infinity: is it intel only or optimus (just curious) | 23:22 |
| infinity | Optimus, but I run it in Intel-only mode. | 23:23 |
| 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:25 |
| 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:26 |
| infinity | s/the/that/ | 23:27 |
| penguin42 | infinity: Is the 420 Intel only? | 23:31 |
| blami | penguin42: it depends | 23:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| blami | penguin42: :) | 23:39 |
| blami | *30 line situation is better as they decided to hardwire only to intel card | 23:40 |
| blami | but they definitely killed the keyboard so I bought as much t420's as I could :) | 23:41 |
| penguin42 | blami: The big escape key on the 520 is kind of nice for us vi users :-) | 23:44 |
| blami | yep :) | 23:45 |
| blami | penguin42: I really mourn about next/prev pages around arrows | 23:45 |
| 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:46 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| * 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:56 |
| 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:57 |
| blami | RAOF: for displaylink maybe | 23:58 |
| 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) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!