=== ScottK2 is now known as ScottK
tjaaltonRAOF: I suppose we want xserver 1.10.4 for oneiric?06:38
tjaaltonstill at
RAOFtjaalton: Yup.06:38
RAOFIt's one of my TODOs, but don't let that stop you from doing it :)06:39
tjaaltonheh, ok. I'll probably merge it then06:39
tjaaltonwe need to upstream patch 503, unless it's in master06:40
tjaaltonuh no, patch 50406:40
RAOFWhich one's 504?06:40
tjaaltonthe wacom-jumping-to-0,006:41
tjaaltonfix for that06:41
RAOFAh, that one.06:41
RAOFDidn't Chase already send that upstream?06:41
tjaaltonnot sure it's upstream yet, I ran off for my vacation when it was done06:41
tjaaltonwell couldn't find it on the list, but that doesn't prove anything :)06:42
RAOFOr is it part of the neverending-stream-of-multitouch?06:42
tjaaltonhum, could be, actually06:43
tjaaltonyeah, rings a bell now06:44
RAOFBecause it wasn't an issue on an upstream Xserver.06:44
tjaaltonand that's why it's numbered as 5xx06:45
=== thade_w is now known as Alexia_Death_
rodrigo_I have 2 computers connected to a monitor, and only on my oneiric box, the monitor loses the signal randomly, and so displays nothing09:00
rodrigo_xorg or kernel driver?09:01
tjaaltondepends on the driver09:01
brycehrodrigo_, if a KMS driver, then kernel09:02
tjaaltonthe hw and then the driver :)09:02
rodrigo_it's the nvidia driver09:02
tjaaltonwell, it's the same blob then09:03
rodrigo_so, anything I can do to fix it?09:03
tjaaltonfile a bug and assign to tseliot :)09:04
brycehno, do a bit more experimentation first09:04
bryceh"loses signal randomly" is so generic as to be worthless as a bug report ;-)09:05
rodrigo_yeah, what log files should I look at?09:06
brycehcharacterize 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 anything09:06
brycehdmesg or /var/log/Xorg.0.log09:06
brycehhowever for this type of problem they almost never have anythingn useful09:06
brycehthere'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 worthwhile09:07
bryceh_then_ file a bug itemizing your findings, and assign to tseliot, and he can approach NVIDIA about it09:08
tjaaltonwell if the other machine is on nvidia too then it's a regression in the driver09:08
tjaaltonif not, then all bets are off09:08
brycehguess could be a fault in the kvm or whatever he's using to connect the monitor09:09
brycehnot-enough-info ;-)09:09
rodrigo_hmm, nvidia-settings shows the temperature of the GPU, 80+ÂșC, is that ok, isn't it too hot?09:10
rodrigo_the other computer doesn't use nvidia driver09:11
brycehrodrigo_, sounds like item #1 for your research journal ;-)09:11
bryceh(no, I don't think it's too hot, but worth study; an overheated gpu can cause power downs)09:12
rodrigo_hmm, it's happened in the last few days, when temperatures are quite high here, might be this indeed09:13
tseliotrodrigo_: 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 back09:16
brycehheya tseliot! :-)09:16
tseliotrodrigo_: can you try with nouveau and see if you can reproduce the issue?09:17
tseliothi bryceh09:17
mgariepyHello, 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:23
tseliotSarvatt: I think what mgariepy reported affects sandybridge13:29
Prf_JakobSo 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 work23:10
Prf_Jakobdriver here being the kms kernel driver.23:10
RAOFPrf_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:15
Prf_JakobWorks like a charm on 11.04 for me, so I'm a bit suprised to see it go away.23:16
Prf_Jakob(at least with vmwgfx).23:17
Prf_JakobWhile you are here, who is responsible for the DRI udev rules?23:18
RAOFTo which udev rules are you referring?23:19
RAOFDo you mean /lib/udev/rules.d/78-graphics-card.rules ?23:20
RAOFWhich sets up PRIMARY_DEVICE_FOR_DISPLAY, or something else?23:20
Prf_JakobThe ones that sets up permissions on the nodes.23:20
Prf_Jakob/dev/dri/card0 and the rest23:21
Prf_JakobThe 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_JakobCurrently I just hacked to to 0666 which isn't particular secure.23:23
RAOFTwo 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
RAOFThey're both in the udev package.23:24
Prf_Jakobok thanks I'll take a look23:25
RAOFSo, 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
RAOFSince 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:25
Prf_JakobI 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_JakobOkay, forgot to clarify, this is not a problem for the upstream driver. Only the standalone one we have on the side.23:26
Prf_JakobWhich is drm+ttm+vmwgfx in a seperate repository.23:27
Prf_JakobWe had to support a rather wide range of kernels, it was just easier to a standalone version.23:28
RAOFThen 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_JakobAh thanks!23:28
Prf_JakobFor how long as that been the case?23:28
Prf_JakobI know the old rules we got worked around 9.10 ish.23:28
RAOFI think the video group stuff has been possible forever; I'm less sure of the udev-acl.23:29
Prf_JakobYeah I don't recognize that.23:29
RAOFOh, 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
RAOFI think udev-acl has been around for at least a couple of releases.23:30
=== yofel_ is now known as yofel

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!