[00:04] <Sarvatt> jcristau: do you think the bad-fbdev-thats-mine.patch needed for intel KMS without an xorg.conf could be related to this? http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=52367847087206b92f18c40d356d36ab9ee89d39
[00:08] <Sarvatt> guess i could reboot into the ubuntu kernel with video=fbcon on the boot line and no xorg.conf to see if it gives the fbdev FatalError when fbcon is already loaded instead of possibly loaded at that point during startup
[00:40] <ripps> Hey, I'm on the Xorg-edgers radeon kms cd, and it works pretty good.
[00:41] <ripps> radeon 9600 pro works pretty nice in dri2 and kms. Performance isn't that bad
[00:41] <ripps> Although, I haven't tested video or flash yet...
[00:46] <ripps> Hmm, seems I spoke too soon, most things run fast, but small things, like resizing the users pane in pidgin is very slow.
[00:57] <ripps> I'm trying to do a ctrl-alt-backspace with some new options in my xorg.conf, but it won't work, even with dontzap --disable... did they change something in karmic?
[01:04] <ripps> playing a 720p video with xv and skiploopfilter=all seems to work pretty good
[01:42] <ripps> AccelDFS didn't improve things much, in fact, things might be a little be slower...
[01:43] <ripps> Flash seems decent with AccelDFS, but Xorg is now spiking between 40-80%  cpu
[01:45] <ripps> All and all, radeon dri2 kms is impressive, especially considering how young the code is, but there is still alot that needs to be done.
[09:36] <hyperair> Sarvatt: i noticed the memleak bug is marked as fix released. is it really?
[09:37] <hyperair> Sarvatt: i still see it, just that i'm able to last for maybe three quarters of a day now before my swap hits 100%
[09:45] <hyperair> ohoho, this is a commit that's on june 15!
[09:45] <hyperair> hurry up and fix the amd64 build already =p
[14:23] <apw> Sarvatt, bryce, do we have a kernel in the x-edgers PPA these days, and if so which one
[17:27] <bdmurray> bryce: bug 388032 has a patch attached.  Does arsenal look for patches at all?
[18:01] <apw> bryce, about?
[18:28] <bryce> apw: heya
[18:29] <bryce> bdmurray: I do have some patch-seeking code but it's unfinished and not automated yet
[18:29] <bryce> so far I just periodically do manual patch searches now and then
[18:31] <bryce> bdmurray: ah, actually I'd already seen that patch and have it in a ppa somewhere
[18:32] <apw> bryce, i just sent you an email on a new kms test kernel which is likely to blammo on you
[18:34] <bryce> bdmurray: yeah it's the xorg-server package in https://edge.launchpad.net/~bryceharrington/+archive/ppa
[18:34] <bryce> hmm, probably should move that into a separate ppa...
[18:35] <bdmurray> bryce: Okay, I wasn't sure since it was still New
[19:18] <Sarvatt> apw: the problem is that we cant put a kernel with radeon KMS enabled that is a higher version than ubuntu's in edgers yet because the userspace is completely incompatable and it isnt just opt-in being 2.6.30-9.10kms9
[19:18] <Sarvatt> we have karmic's kernel up for jaunty though
[19:20] <apw> Sarvatt, ahh.  i could disable it by default if that would help more
[19:20] <apw> be more useful
[19:20] <Sarvatt> i dont think its even disableable right now
[19:21] <Sarvatt> all or nothing yes or no option in staging that doesnt use the KMS code paths if you dont say yes from what i see
[19:22] <Sarvatt> have you seen that its in linus master now?
[19:29] <Sarvatt> its really complicated right now, tormods doing some testing to see how we can work it into there with the different combination of packages
[19:30] <Sarvatt> wish i had an older ati card lying around to test it on
[19:32] <bryce> Sarvatt: what do you have on hand?
[19:33] <Sarvatt> hd2400 pro is the only ati i have
[19:44] <Sarvatt> apw: by the way, you can pull in all of drm-intel-next and the latest radeon KMS stuff (as well as a bunch of drm fixes in general) from the drm-linus branch here if its any easier http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=summary
[19:45] <apw> Sarvatt, so thats going into .31?
[19:45] <Sarvatt> yeah it already is in linus' tree
[19:45] <apw> very nice
[19:47] <Sarvatt> i'm having some verrrry weird problems with 2.6.31 built 8 hours ago, a ton of segfaults starting up and touchpads arent working on 2 of my machines
[19:47] <apw> yeah taking pre -rc1 is often asking for pain
[19:49] <Sarvatt> i'll try out your pae kernel now to see if gem works
[19:50] <Sarvatt> which patch did you use? the one on patchwork needed some changes i havent seen posted up yet i thought
[20:51] <johanbr> tapping on ALPS touchpads doesn't work with the Karmic version of xserver-xorg-input-synaptics
[20:51] <johanbr> but it does work with 1.1.1~git20090510-1ubuntu1~wgrant2 from wgrant's ppa
[20:53] <johanbr> is this something you're aware of?
[20:53] <Sarvatt> does it work if you do synclient TapButton1=1 in terminal?
[20:54] <johanbr> something like that, yes, I don't remember exactly
[20:54] <johanbr> all the TapButton settings were 0 with the Karmic version
[20:54] <johanbr> but I could reset them with synclient
[20:58] <Sarvatt> look at the very last page of man synaptics, tapping is disabled on purpose on touchpads with more than one physical button which is a choice the driver developers made.  ubuntu has a patch that changes that to be enabled by default always which wasnt included in the karmic version by mistake but we really do need some way to enable it correctly in userspace before we drop that..
[21:01] <johanbr> if I'm reading the man page correctly, couldn't that setting be overridden in the fdi file?
[21:12] <Sarvatt> yep it can, dont really need the fdi stuff anymore since its all configurable at runtime without any of the shmconfig mess now. can you not enable tapping in gnome mouse settings? the checkbox works fine for me
[21:15] <johanbr> all the relevant settings there are enabled
[21:15] <Sarvatt> do you have a touchpad tab in the mouse settings?
[21:16] <johanbr> yep
[21:16] <Sarvatt> maybe you have to uncheck and check it again on the karmic driver for some strange reason?
[21:17] <johanbr> maybe
[21:17] <johanbr> I'm running the ppa version right now
[21:17] <Sarvatt> yeah its assuming tapping is enabled even if its not
[21:18] <Sarvatt> if i turn off tapping with synclient TapButton1=0 then open it it still has the tapping checkbox enabled
[21:19] <Sarvatt> and its not reenabling it if i toggle it
[21:19] <Sarvatt> so I guess it needs tapping enabled by default to even work
[21:21] <Sarvatt> with the tapping enabled patch if I uncheck the box it turns off tapping and turns it back on when i check it again, if i turn off tapping via synclient TapButton1=0 TapButton2=0 TapButton3=0 like the default synaptics driver has without the patch the checkbox does nothing
[21:22] <johanbr> so the gnome settings just affect how gnome interprets the X events?
[21:22] <johanbr> they don't actually change the driver settings?
[21:24] <Sarvatt> sounds like it
[21:24] <Sarvatt> have you installed gpointing-device-settings?
[21:28] <johanbr> yep
[21:29] <Sarvatt> if only it had a enable/disable tap option it'd be perfect
[21:30] <Sarvatt> it can disable tap and reenable tap fine, but theres no explicit option to turn on tap when its already off
[21:31] <Sarvatt> wonder if its been updated lately, i compiled this like 3 months ago
[21:33] <johanbr> setting the driver options sounds like a job for gnome-settings-daemon
[21:37] <Sarvatt> well it requires a synaptics driver > 1.0 and xserver 1.6 or newer to use the input properties, even jaunty didnt ship with the requirements there.. 
[21:38] <Sarvatt> wow they just added the touchpad tab upstream in gnome-settings-daemon 3 days ago?
[21:39] <johanbr> really? it was an out-of-tree patch before?
[21:39] <Sarvatt> i wonder if all of the userspace requiring tapping enabled by default like this would be a good enough reason for them to consider enabling it default upstream
[21:40] <Sarvatt> http://git.gnome.org/cgit/gnome-settings-daemon/commit/?id=4eb9bd09219afbb56f114a2d10bc585e24db803e
[21:40] <johanbr> http://bugzilla.gnome.org/show_bug.cgi?id=578444 blames Ubuntu for that
[21:41] <Sarvatt> looks like that one will work with synaptics right
[21:42] <johanbr> I think so
[21:44] <Sarvatt> well thats good news at least :)
[21:47] <johanbr> presumably this will be imported into Karmic (with the ubuntu-specific patch dropped)
[21:48] <Sarvatt> yeah soon as 2.27.4 comes out
[21:52] <johanbr> alright
[21:52] <johanbr> so I think I'll stick with the ppa driver until g-s-d 2.27.4 comes out and see if things start working then
[23:26] <Sarvatt> maybe it would be easier to just ship a custom fdi with xserver-xorg-input-synaptics in debian/ with the tap buttons enabled instead of patching the source to enable it by default there?
[23:56] <wgrant> Sarvatt: The issue with g-s-d is that it (IIRC) disables tapping by setting MaxTapTime, rather than setting the button map.