=== ScottK2 is now known as ScottK
[06:38] <tjaalton> RAOF: I suppose we want xserver 1.10.4 for oneiric?
[06:38] <tjaalton> still at 1.10.2.902
[06:38] <RAOF> tjaalton: Yup.
[06:39] <RAOF> It's one of my TODOs, but don't let that stop you from doing it :)
[06:39] <tjaalton> heh, ok. I'll probably merge it then
[06:40] <tjaalton> we need to upstream patch 503, unless it's in master
[06:40] <tjaalton> uh no, patch 504
[06:40] <RAOF> Which one's 504?
[06:41] <tjaalton> the wacom-jumping-to-0,0
[06:41] <tjaalton> fix for that
[06:41] <RAOF> Ah, that one.
[06:41] <RAOF> Didn't Chase already send that upstream?
[06:41] <tjaalton> not sure it's upstream yet, I ran off for my vacation when it was done
[06:42] <tjaalton> well couldn't find it on the list, but that doesn't prove anything :)
[06:42] <RAOF> Or is it part of the neverending-stream-of-multitouch?
[06:43] <tjaalton> hum, could be, actually
[06:44] <tjaalton> yeah, rings a bell now
[06:44] <RAOF> Because it wasn't an issue on an upstream Xserver.
[06:45] <tjaalton> right
[06:45] <tjaalton> and that's why it's numbered as 5xx
[06:45] <tjaalton> duh
[06:45] <RAOF> :)
=== thade_w is now known as Alexia_Death_
[09:00] <rodrigo_> hi
[09:00] <rodrigo_> I have 2 computers connected to a monitor, and only on my oneiric box, the monitor loses the signal randomly, and so displays nothing
[09:01] <rodrigo_> xorg or kernel driver?
[09:01] <tjaalton> depends on the driver
[09:02] <tjaalton> um
[09:02] <bryceh> rodrigo_, if a KMS driver, then kernel
[09:02] <tjaalton> the hw and then the driver :)
[09:02] <rodrigo_> it's the nvidia driver
[09:03] <tjaalton> well, it's the same blob then
[09:03] <rodrigo_> so, anything I can do to fix it?
[09:04] <tjaalton> file a bug and assign to tseliot :)
[09:04] <bryceh> no, do a bit more experimentation first
[09:05] <bryceh> "loses signal randomly" is so generic as to be worthless as a bug report ;-)
[09:06] <rodrigo_> yeah, what log files should I look at?
[09:06] <bryceh> characterize the problem.  Eliminate the other computer from the equation.  Identify if it's a regression and if so, when did it start.  Experiment with ways to reproduce it.  Change out monitor and/or video card.
[09:06] <rodrigo_> .xsession-errors doesn't seem to contain anything
[09:06] <rodrigo_> ok
[09:06] <bryceh> dmesg or /var/log/Xorg.0.log
[09:06] <bryceh> however for this type of problem they almost never have anythingn useful
[09:07] <bryceh> there's also a nvidia configuration tool; dunno if it has any settings of use but at least make a pass through it and test anything that looks worthwhile
[09:07] <rodrigo_> ok
[09:08] <bryceh> _then_ file a bug itemizing your findings, and assign to tseliot, and he can approach NVIDIA about it
[09:08] <tjaalton> well if the other machine is on nvidia too then it's a regression in the driver
[09:08] <tjaalton> if not, then all bets are off
[09:09] <bryceh> guess could be a fault in the kvm or whatever he's using to connect the monitor
[09:09] <bryceh> not-enough-info ;-)
[09:10] <rodrigo_> hmm, nvidia-settings shows the temperature of the GPU, 80+ºC, is that ok, isn't it too hot?
[09:11] <rodrigo_> the other computer doesn't use nvidia driver
[09:11] <bryceh> rodrigo_, sounds like item #1 for your research journal ;-)
[09:11] <rodrigo_> :)
[09:12] <bryceh> (no, I don't think it's too hot, but worth study; an overheated gpu can cause power downs)
[09:13] <rodrigo_> hmm, it's happened in the last few days, when temperatures are quite high here, might be this indeed
[09:16] <tseliot> rodrigo_: something similar always happens to me (no matter what graphics card I use) and I have to press the scan button of my monitor to get my 2nd pc screen back
[09:16] <bryceh> heya tseliot! :-)
[09:17] <tseliot> rodrigo_: can you try with nouveau and see if you can reproduce the issue?
[09:17] <tseliot> hi bryceh
[13:23] <mgariepy> Hello, i updated the bug lp:#785280 concerning the transparency problem with intel driver and remote Xorg server, someone have identified the first problematic commit. Can someone take a look at this ?
[13:29] <tseliot> Sarvatt: I think what mgariepy reported affects sandybridge
[23:10] <Prf_Jakob> So on 11.10 alpha how do I stop the framebuffer console so I can reload my driver? "echo 0 | sudo dd of=/sys/class/vtconsole/vtcon[0-1]/bind" doesn't seem to work
[23:10] <Prf_Jakob> driver here being the kms kernel driver.
[23:15] <RAOF> Prf_Jakob: Hm.  I've never managed to get that to work myself, but I've not tried terribly hard; a reboot is fast enough to make it not worth the hassle for me.
[23:16] <Prf_Jakob> Works like a charm on 11.04 for me, so I'm a bit suprised to see it go away.
[23:17] <Prf_Jakob> (at least with vmwgfx).
[23:18] <Prf_Jakob> While you are here, who is responsible for the DRI udev rules?
[23:19] <RAOF> To which udev rules are you referring?
[23:20] <RAOF> Do you mean /lib/udev/rules.d/78-graphics-card.rules ?
[23:20] <RAOF> Which sets up PRIMARY_DEVICE_FOR_DISPLAY, or something else?
[23:20] <Prf_Jakob> The ones that sets up permissions on the nodes.
[23:21] <Prf_Jakob> /dev/dri/card0 and the rest
[23:23] <Prf_Jakob> The standalone driver we have doesn't register the nodes as "drm" class but instead they get the class of "vmwgfx", so we need to install our own rules to get the correct permissions on the nodes.
[23:23] <Prf_Jakob> Currently I just hacked to to 0666 which isn't particular secure.
[23:24] <RAOF> Two places - 50-default-udev.rules sets the "video" group on everything in the drm class, and 70-udev-acl.rules sets up the "console user gets ACL" bits, again for drm class.
[23:24] <RAOF> They're both in the udev package.
[23:25] <Prf_Jakob> ok thanks I'll take a look
[23:25] <RAOF> So, either register the nodes as "drm", throw in a new udev rule, or file a bug against udev asking for vmwgfx to be handled like that.
[23:25] <RAOF> Since that's in the upstream kernel, I'd guess that the ultimately-correct option would be either register-as-drm, or for those standard udev rules to be updated for vmwgfx.
[23:26] <Prf_Jakob> I don't think we can register them as drm because they get the class name from the module name (and we have baked in a copy of drm into the standalone repo).
[23:26] <Prf_Jakob> Okay, forgot to clarify, this is not a problem for the upstream driver. Only the standalone one we have on the side.
[23:27] <RAOF> Ah.
[23:27] <Prf_Jakob> Which is drm+ttm+vmwgfx in a seperate repository.
[23:28] <Prf_Jakob> We had to support a rather wide range of kernels, it was just easier to a standalone version.
[23:28] <RAOF> Then ship a udev rule with it; the relevant magic is SUBSYSTEM=="drm", KERNEL=="card*", TAG+="udev-acl" for the ConsoleKit integration, and SUBSYSTEM=="drm",		GROUP="video" for the (legacy) video grouping.
[23:28] <Prf_Jakob> Ah thanks!
[23:28] <Prf_Jakob> For how long as that been the case?
[23:28] <Prf_Jakob> I know the old rules we got worked around 9.10 ish.
[23:29] <RAOF> I think the video group stuff has been possible forever; I'm less sure of the udev-acl.
[23:29] <Prf_Jakob> Yeah I don't recognize that.
[23:30] <RAOF> Oh, and the rule with the udev-acl tag needs to be executed before the 70-udev-acl.rules rule, which means install at 69 or below.
[23:30] <Prf_Jakob> ok
[23:30] <RAOF> I think udev-acl has been around for at least a couple of releases.
[23:30] <Prf_Jakob> right
=== yofel_ is now known as yofel