[00:02] <bryceh> I'm going to update -ati to a newer snapshot; anyone know of any glaring issues in the -ati we have in -edgers currently?  Else I'll snag that snapshot for lucid.
[00:07] <ScislaC> bryceh: Does this have all of the info you need for a decent report? https://bugs.edge.launchpad.net/ubuntu/+source/xf86-input-wacom/+bug/511844 (I'm not asking you to fix my bug, I'm asking about the quality of the report)
[00:07] <ubottu> Ubuntu bug 511844 in xf86-input-wacom "Wacom Tablet is only recognized on first plug" [Undecided,New]
[00:08] <ScislaC> wasn't expecting that, you guys think of everything :)
[00:13] <bryceh> ScislaC, maybe also syslog... like boot with it plugged in, capture that syslog to the bug report, then unplug it, note whatever new stuff shows in the log, then plug it in again, and get that as well
[00:13] <bryceh> ScislaC, this may be a general usb hotplug issue unrelated to X, it's probably a kernel issue, but the syslog output would (hopefully) be informative of what is going on
[00:14] <bryceh> another thing which might be of interest is to look at the output of lsusb for the three configurations as well
[00:14] <bryceh> in theory the first and third cases should have identical lsusb output
[00:15] <ScislaC> bryceh: wrt general hotplug, would a wireless usb mouse with a usb receiver suffice to test?
[00:16] <bryceh> I don't know, try it
[00:16] <ScislaC> I did and it has no issues on multiple plugs
[00:16] <bryceh> but from what I've seen the usb issues can be hardware-specific
[00:16] <ScislaC> ahhh
[00:16] <bryceh> e.g. I have a keyboard with a similar usb issue, but a usb mouse connected to the same port works fine
[00:16] <bryceh> and on another machine it's vice versa
[00:17] <bryceh> (and varies depending on what kernel I boot into)
[00:18] <ScislaC> bryceh: you're not giving me confidence that any amount of information I provide will help to make the bug report any more useful ;)
[00:23] <bryceh> ScislaC, it would only be false confidence I could supply in any case; my bet is it's not an X bug but rather a kernel issue
[00:24]  * ScislaC shakes his fist at the kernel
[00:26] <Sarvatt> regarding ati - none that I know of bryce, just alot of fixes people were having to use edgers to get and thats why I was recommending it.
[00:26] <bryceh> Sarvatt, great - know of particular bugs the xorg-edgers version solves?
[00:27] <Sarvatt> not LP bugs I'm afraid, lets see if any stand out :)
[00:28]  * bryceh looks too
[00:30] <ScislaC> bbiab... going to collect that syslog and lsusb info
[00:31] <Sarvatt> <Sarvatt> [22:16:55] might be a good time to update ati soon, quite alot of bug fixes in the past 2 months on master like signifigant speedups for r600 2D, low memory EXA fixes (and fixing NoAccel to work with KMS), a ton of dpms/incorrect resolution fixes, and a fix for a VT problem I've seen people having
[00:31] <Sarvatt> (some symptoms to help narrow it down)
[00:31] <bryceh> thanks
[00:37] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/494672
[00:37] <Sarvatt> fixed
[00:37] <ubottu> Ubuntu bug 494672 in xserver-xorg-video-ati "[Radeon Xpress 200M] VT switch freezes X" [Undecided,Confirmed]
[00:37] <Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=3a30210d50b27f8772fc5045133940246764fce9
[00:38] <Sarvatt> possibly of course
[00:38] <bryceh> lp 333377 fixed too
[00:38] <ubottu> Launchpad bug 333377 in xserver-xorg-driver-ati "[RS480] HP Dv8000 laptop suspends but does not resume" [Unknown,Fix released] https://launchpad.net/bugs/333377
[00:39] <bryceh> lp 487204 is fixed by mesa 7.7
[00:39] <ubottu> Launchpad bug 487204 in xserver-xorg-driver-ati "radeon_lock.c:65: radeonGetLock: „drawable != ((void *)0)” Assertion" [Unknown,Fix released] https://launchpad.net/bugs/487204
[00:40] <bryceh> ditto 500607 I guess
[00:43] <RAOF> Argh.  I *always* miss xutils-dev when building nouveau orig.tar.gzs.  Where does it go?!
[00:45] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/511520  -- already fixed, exact same version that was in the archives :D
[00:45] <ubottu> Ubuntu bug 511520 in xserver-xorg-video-ati "Ubuntu Karmic: DVI output not working with radeon 4350" [Undecided,Fix released]
[00:45] <Sarvatt> what do you mean RAOF? I have 7.5+2 in edgers because we need the newer xorg macros
[00:46] <bryceh> 465958 -> heh, not an -ati bug, how'd that get here
[00:46] <bryceh> lp 465958 -> heh, not an -ati bug, how'd that get here
[00:46] <ubottu> Launchpad bug 465958 in x11-xserver-utils "effect of xmodmap ~/.Xmodmap " [Undecided,Incomplete] https://launchpad.net/bugs/465958
[00:46] <Sarvatt> oh it doesnt get added to your debian/control? I'm not sure, it works fine with auto-xorg-git
[00:47] <RAOF> Sarvatt: Building the nouveau original tarballs requires that I have xutils-dev installed, because I autoreconf to build the tarball.
[00:47] <RAOF> Sarvatt: And each time I go to do that it seems that xutils-dev has been uninstalled...
[00:47] <Sarvatt> oh you install it with apt-get build-dep and it gets autoremoved later? do you use aptitide/synaptic?
[00:48] <Sarvatt> do you get it installed via apt-get build-dep I mean
[00:48] <RAOF> I don't know.  It's possible that I just reinstall frequenly enough that I seem to always be missing xutils-dev :)
[00:49] <RAOF> Or maybe it's my multiple laptops.
[00:57] <Sarvatt> huh, this bug is confusing
[00:57] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/507000
[00:57] <ubottu> Ubuntu bug 507000 in xserver-xorg-video-ati "2.6.32-10 xserver-xorg hang ati radeon mobility 7500" [Undecided,New]
[00:57] <Sarvatt> hes crashing with the kernel that enables KMS globally, but his logs show it trying to use XAA
[00:58] <Sarvatt> is there still a force XAA patch in the ubuntu -ati?
[00:59] <Sarvatt> he has no xorg.conf
[01:00] <Sarvatt> ahhh
[01:00] <Sarvatt> he got hit with the xserver trashing libdri/libglx.so during the alternatives switch a few weeks ago
[01:01] <bryceh> ah
[01:02] <bryceh> yeah close that bug and ask him to retest and reopen if it's still an issue
[01:02] <Sarvatt> doing that now
[01:02] <bryceh> hrm, I see my automatic xorg bug repackager has been a bit too aggressive at refiling bugs against -ati
[01:05] <ScislaC> bryceh: bug updated with that info, thank you for telling me what might be of use :)
[01:09] <bryceh> I bet lp 493057 is fixed from the r6xx performance improvements
[01:09] <ubottu> Launchpad bug 493057 in xserver-xorg-video-ati "in top Xorg CPU usage is always 23+ with frequent spikes to 60+ and sometimes higher" [Undecided,Confirmed] https://launchpad.net/bugs/493057
[01:10] <Sarvatt> so many incorrect resolution in X bugs on ati that could possibly be fixed now
[01:11] <Sarvatt> dont think so Bryce, thats a x1600 and the huge 2D speed improvement was only R600
[01:11] <bryceh> ah right
[01:11] <Sarvatt> 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc M56P [Radeon Mobility X1600] [1002:71c5]
[01:11] <bryceh> x1600 is an R5xx
[01:18] <bryceh> Sarvatt, btw if you run into bug reports which you know have been fixed by upstream code (e.g. a fix is confirmed in xorg-edgers packages), then if you mark the bug report Fix Committed, that clues us for the changelog in when we update the package
[01:18] <bryceh> ok, uploading new -ati
[02:10] <Sarvatt> huh, your logs are confusing ScislaC, that XorgLog.gz shows hotplug working, that syslog looks fine too
[02:11] <ScislaC> Sarvatt: I know... that's why I'm especially confused...
[02:13] <Sarvatt> is that all over the same boot?
[02:13] <ScislaC> Sarvatt: given that I don't know how things work internally, is there anything in particular that would make the pen not work after the tablet is replugged? (I don't know if it ties the pen to a device id of sorts on first use)
[02:15] <ScislaC> Yep, I followed bryce's instruction on how to do it. Booted w/ tablet plugged in, captured syslog, unplugged, grabbed change from syslog, replugged, grabbed change from syslog again (I did attempt to use the pen on the three times, it worked for the first only)
[02:20] <Sarvatt> first time as in before you unplugged it the first time? because it looks like it loaded right on boot and the first unplug/replug at least
[02:21] <Sarvatt> maybe try rmmod wacom after you unplug before you plug it in again to see if its any different?
[02:24] <Sarvatt> it looks like the kernel sides working though, maybe watching what happens with sudo udevadm monitor might be interesting?
[02:24]  * Sarvatt isn't sure
[02:29] <Sarvatt> have you ever had that kind of issue with any other usb devices on that system?
[02:34] <Sarvatt> did you try plugging it in and such before the wacom driver got updated? curious if it was having the same problem with evdev
[02:36] <Sarvatt> i tried my 2 tablets on 4 systems now and hotplugging works fine multiple times on them all :(
[02:41] <RAOF> I'm scared and confused.  Why does my 2.6.32-10-generic initramfs have a nouveau kernel module?
[02:44] <Sarvatt> installed it with dkms ever? it installs to the latest 2 kernels
[02:44] <RAOF> Ah, I probably just hadn't rebuilt the initramfs after removing dkms.
[02:45] <RAOF> Man we pack the kitchen sink into our initramfs.
[02:45] <Sarvatt> especially now with plymouth!
[02:45] <Sarvatt> pango and such
[02:46] <RAOF> There are probably *some* kernel modules that don't end up in there... :)
[02:47] <Sarvatt> i dread anything calling update-initramfs because it takes a good 5-10 minutes here :D
[02:47] <johanbr> pango?! yikes...
[02:48] <johanbr> at least it's better after dpkg triggers were implemented
[02:48] <Sarvatt> i have it set to rebuild all every time
[02:48] <RAOF> And you've got every kernel since Warty installed?
[02:49] <Sarvatt> nah i build my own weekly and forget to remove them until it annoys me enough, removing just one takes forever
[02:50] <Sarvatt> rebuilds all initrd's twice and calls update-grub twice.. silly kernel-package hooks
[02:51] <RAOF> Gah.  Why does the nouveau DDX think l-b-m-n's kernel module doesn't have KMS enabled?
[02:51] <Sarvatt> stopped doing that though and am just living with having to remount my SD every resume, wish the ubuntu kernels had mmc unsafe resume enabled
[02:52] <Sarvatt> weird it should *only* have kms by now?
[02:52] <RAOF> Yes.
[02:52] <RAOF> Also, that's why X isn't starting; the UMS code just isn't there.
[02:53] <RAOF> It's mis-detecting KMS.
[02:53] <RAOF> At least I get a 210x65 console to debug from.
[02:54] <Sarvatt> did you build it against lucid's libdrm 2.4.17? i thought the ddx needed a post 2.4.17 update to even build anymore
[02:56] <Sarvatt> could something be screwy with the lbm-* module renaming?
[02:57] <RAOF> I built it against xorg-edgers 2.4.17+git20101020
[02:57] <RAOF> You're right, it does need to be built against > 2.4.17.
[02:57] <RAOF> I'm just checking how it checks for kms.
[02:58] <bryceh> ouch, it needs a git snapshot of libdrm?
[02:58] <bryceh> hope we can cherrypick what it needs
[02:59] <RAOF> I'd be surprised if we couldn't; I'm fairly sure it's just #defines in the nouveau headers again.
[03:00] <Sarvatt> cant cherrypick i dont think because it adds a new symbol
[03:01] <Sarvatt> well could and define that symbol in libdrm-nouveau1.shlibs I guess, i'm slow
[03:01] <RAOF> We've done that before.
[03:04] <Sarvatt> whats the error in Xorg.0.log? [drm] KMS not enabled?
[03:04] <ScislaC> Sarvatt: Yes, first time as in before it was unplugged. I've never had issues like this on this system, and it worked as expected in Karmic. I will try your suggestions after I eat. :)
[03:08] <Sarvatt> ahh i better get off the pc, wife wants to watch a few house episodes before we pass out :D will try the nouveau stuff out tomorrow, i'll try making NVPciProbe() always assume KMS is enabled and see if it works that way too
[03:12] <RAOF> I *think* the problem is that we've renamed the drm directory under /sys/stuff to lbm-drm.
[03:28] <RAOF> Well, dropping the KMS check makes everything work nicely.
[10:12] <tseliot> bryceh: are you around?
=== seb128_ is now known as seb128
[14:18] <Cobalt> Hello. Does anyone know if Xorg Edgers has a IRC channel?
[14:20] <tseliot> you can ask here
[14:21] <tseliot> Cobalt: maybe ask Sarvatt and RAOF
[14:22] <Cobalt> tseliot: Thanks.
=== Sinnerman is now known as Cobalt
[14:26] <Cobalt> Sarvatt, RAOF: It's regarding a change made to the Intel Xorg driver after xserver-xorg-video-intel_2%3a2.9.1~git-0ubuntu0tormod_i386.deb. I noticed there's a bug filed for this on Launchpad: #502663. I'm having the exact same problem, with the latest packages (from 20100127). Is there any information I can supply that might help fix this issue?
[14:27] <Cobalt> That is, any package made after that one causes a crash, back to the log-in screen. It always crashes, but the amount of time it takes to do that varies.
[15:47] <Sarvatt> [drm:i915_gem_object_bind_to_gtt] *ERROR* Invalid object alignment requested 4096
[15:47] <Sarvatt> thats the error you get?
[15:47] <Sarvatt> I have gotten that at one point before but only on the 2.6.31 kernel, it didn't happen on the 2.6.32 kernel
[15:48] <Cobalt> Sarvatt: It is, I just wrote an entry in the bug report.
[15:49] <Sarvatt> can you try with a mainline kernel? I recommend 2.6.32.6 http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32.6/
[15:49] <Cobalt> I am on 2.6.31-18-generic. I ought to look into how to upgrade to .32, test that and report back.
[15:50] <Cobalt> Sarvatt: I'm going out right now, I'll do that when I get back.
[15:50] <Cobalt> How different is the mainline kernel from the -generic Ubuntu one, do you know?
[15:50] <Sarvatt> I have to run too, if you dont have any luck with it I'll see it in the irc logs though and come back when I can :)
[15:51] <Cobalt> Sarvatt: No worries, this is a lot better than no interaction at all. Thanks for the pointers.
[15:51] <Sarvatt> its basically the newest upstream kernel with the karmic kernel configuration
[15:51] <Sarvatt> upstream stable kernel that is
[15:57] <Cobalt> That's nice. I'm definitely getting it. Hope that solves some the nasty bluetooth pairing issues I've been having with my aluminium Mac keyboard at the same time.
[15:58] <Cobalt> It's downloading, I'll install and test after I get back. Laters. And thanks again.
=== yofel_ is now known as yofel
=== Amaranth_ is now known as Amaranth
[19:00] <ScislaC> Sarvatt: So, I did the couple of things you recommended last night (rmmod wacom & udevadm monitor), everything looked fine. I even tried a dummy test to have the tablet plugged in, NOT use the pen, and then on replug to test if the pen works... nope, it truly will only work on the first plug only.
[19:09] <bryceh> ScislaC, :-(
[19:12] <ScislaC> bryceh: Yeah... it is SO strange. As mentioned, with the X stuff from Karmic (because that is the one piece I held off on upgrading), it all worked as expected.
[19:13] <ScislaC> brb
[19:17] <ScislaC> yay for a newer ati driver :)
[19:28] <bryceh> ScislaC, did it solve any issues for you?
[19:35] <ScislaC> bryceh: the transition from plymouth to gdm looks less scary (before the whole screen was corrupted, this last start was only about 25% of it). I haven't done much more yet to know.
[19:35] <bryceh> ok
[19:36] <bryceh> ScislaC, if you post bugs about those issues, sub me to them and also include a photo
[19:37] <ScislaC> bryceh: ok... I will reboot in a bit with my camera available. There is also interruption of plymouth on shutdown that I don't know if it's known or expected right now.
[19:42] <tjaalton> ScislaC: try with a 2.6.33-rc package
[19:43] <tjaalton> it's likely something in the kernel drm driver, since it's using kms anyway
[19:43] <ScislaC> tjaalton: is there a ppa I should use?
[19:43] <tjaalton> ScislaC: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33-rc5/
[19:44] <ScislaC> brb :)
[19:44]  * bryceh waves to tjaalton
[19:45] <tjaalton> hi bryceh, nice nick :)
[19:59] <ScislaC> tjaalton: No plymouth at all with that kernel... also no wacom action either (I had to test)
[20:02] <tjaalton> ScislaC: you have to boot it with the kernel option to turn kms on
[20:02] <tjaalton> can't remember what it was
[20:05] <tjaalton> option radeon modeset=1
[20:06] <tjaalton> radeon.modeset=1 on the kernel cmdline
[20:06] <tjaalton> sauna ->
=== Sinnerman is now known as Cobalt
[20:45] <ScislaC> tjaalton: when you say kernel cmdline, would that be the line in grub?
[20:47] <ScislaC> well, that's what I'll try... brb
[20:58] <ScislaC> tjaalton: I had no plymouth on boot, but it showed up on shutdown.
[21:14] <tjaalton> ScislaC: do you have kms on boot, better vt's etc?
[21:14] <ScislaC> vt's?
[21:14] <tjaalton> virtual terminal
[21:14] <tjaalton> c-a-fN
[21:15] <ScislaC> I added radeon.modeset=1 in grub... I'm back in my 32 kernel at the moment (it seemed that video acceleration wasn't working for me in 33)
[21:15] <tjaalton> ok
[21:16] <ScislaC> I will test again in a bit to see about the vt's though 
[21:57] <RAOF> bryceh: Oh, I do have something I'd like a pointer towards - how to make nouveau the first autoprobed driver in X.
[21:58] <tjaalton> see what the nvidia/fglrx patches do
[21:58] <tjaalton> though they are disabled
[21:58] <bryceh> right
[21:58] <RAOF> In the xorg-server package?
[21:58] <tjaalton> yes
[21:58] <bryceh> RAOF, yes
[21:58] <bryceh> basically there's a case statement that selects a driver by chip manufacturer id
[21:59] <bryceh> so look for the line with "nv" and change it to "nouveau"
[21:59] <RAOF> We're in a bit of a bind with the combination of nouveau (a) not being a part of the base kernel and (b) not working *at all* when its kernel module isn't available, so I think the best way to reliably get to X is to have it try to autoload nouveau, then fall back on nv (then VESA, or whatever).
[21:59] <tjaalton> rather put it above nv
[21:59] <bryceh> actually what we really want is to try "nouveau" first and then "nv" if it's unavailable
[21:59] <bryceh> however I'm not sure that fallback function will work
[22:00] <tjaalton> it works if nouveau fails to init
[22:00] <RAOF> I'll have a look & give it a try.
[22:00] <jcristau> does it only work if probe fails, or also if preinit fails?
[22:01] <tjaalton> at least when the driver doesn't support the chip
[22:02] <tjaalton> not sure what stage that is
[22:03] <RAOF> nouveau fails fairly early in the init when its kernel module is unavailable
[22:03] <RAOF> I can test it out & see.
[22:12] <RAOF> *After* I bisect the kernel to work out when suspending started to work again in 2.6.33
[22:15] <tjaalton> gimp crashes when wacom is unplugged, nice
[22:16] <tjaalton> on karmic though, don't know about lucid
[22:28] <Sarvatt> tjaalton: pretty sure thats fixed in xserver 1.7, i had the same issue all during karmic and it didnt happen with the early pre-1.7 releases
[22:39] <tjaalton> Sarvatt: ok, good
[22:46] <Cobalt> Sarvatt: Using the mainline kernel you gave me a link to fails to load proper ath5k modules, get no wifi, and hence can't test for the most usual test case and reproduce the crash (ie, opening pages in Firefox). As an aside, apparmor profiles also fail to load, and /proc/mount fails to mount as well.
=== ripps is now known as ripps|sleep