[00:14] <pwnguin> i wasn't aware mpx was in jaunty
[00:15] <pwnguin> (or xorg main)
=== pwnguin_ is now known as pwnguin
[09:44] <bryce> tjaalton: posted debdiff for #308387.  solved the issue for me, but would appreciate if you took a look at it to assure it's the right change
[09:55] <tjaalton> bryce: I'd just modify debian/libdrm-dev.install :)
[09:55] <tjaalton> but the real question is, does -intel build against the kernel headers
[09:56] <tjaalton> the kernel needs db139d606ea25e0590373d5ce6bfc42ce317a61c from drm-next
[09:56] <tjaalton> fdo bug #19132
[09:56] <ubottu> Launchpad bug 19132 in gtk+2.0 "gtk 2.7.3 with cairo doesn't use font rendering settings" [Medium,Fix released] https://launchpad.net/bugs/19132
[09:56] <bryce> well there are some headers which don't conflict (which I left in the makefile).
[09:56] <tjaalton> bah, freedesktop bug 19132
[09:56] <ubottu> Freedesktop bug 19132 in Driver/intel "2.5.99.1 fails to build using drm headers from 2.6.28" [Blocker,Resolved: fixed] http://bugzilla.freedesktop.org/show_bug.cgi?id=19132
[09:57] <bryce> yeah, I didn't try building anything against it (this is an -ati box)
[09:58] <tjaalton> the goal is to get rid all of them I guess (from libdrm-dev)
[09:58] <tjaalton> only the userspace headers will remain (intel_bufmgr.h, xf86drm.h)
[09:58] <tjaalton> oh well, I'll mail the kernel list
[09:59] <bryce> fair enough; the remainder sounded like maybe obsolete cruft, but didn't want to drop without seeing someone state that explicitly
[09:59] <bryce> ok
[09:59] <tjaalton> btw, the new intel needs newer libdrm, but there are reports where X segfaults on start with it, so.. :/
[10:00] <bryce> dah, such unstable crap
[10:00] <bryce> I'm peeved...  I bought a dell mini 9 for my dad, and after playing with it with him for all of 4 hours, it locked up 3 times
[10:01] <tjaalton> :S
[10:01] <bryce> not sure exactly what is happening, but seems like a kernel lockup
[10:01] <bryce> the dell mini 9 is an i945 hardy setup, with the lpia kernel and a proprietary wireless driver
[10:02] <bryce> was really disappointed - if anything it ought to be a showcase of ubuntu/linux/open-source quality, and to have it locking up so much is really frustrating
[10:03] <tjaalton> yeah that sounds really bad
[10:05] <bryce> anyway
[10:05] <bryce> the system I'm trying to get up to jaunty is one I plan to switch to as my main desktop
[10:07] <bryce> usually I've kept my main desktop to the last released Ubuntu for stability, but I figured I need to dog food more :-)
[10:08] <tjaalton> hehe
[10:08] <tjaalton> my desktop is still intrepid, because of the nvidia blob..
[10:08] <bryce> I had some graphics problems with it before, so was using it just as a build box, but I managed to get those all squared away this week
[10:08] <tjaalton> you probably heard the news about r6/7xx drm stuff?-)
[10:08] <bryce> oh yeah
[10:09] <bryce> and nvidia's new video accel stuff
[10:09] <bryce> vdpau or whatever
[10:09] <tjaalton> so within a month the docs should be out and some sort of a DRI driver too..
[10:10] <tjaalton> I wonder if other drivers will pick vdpau..
[10:10] <bryce> do -ati and -radeonhd both use the same dri driver in mesa?
[10:10] <tjaalton> yes, AIUI
[10:10] <bryce> cool
[10:11] <bryce> tjaalton: vdpau ain't open source
[10:11] <tjaalton> hmm
[10:11] <bryce> and sounds like both Intel and ATI have competing technology solutions for multi-mpeg accel support, so...
[10:12] <bryce> I think again we're going to get into this annoying situation of having a great proprietary solution for -nvidia, and a less great but open source solution from intel
[10:12] <tjaalton> I believe there was an announcement on xorg@ about vdpau
[10:12] <bryce> from nvidia?
[10:13] <tjaalton> yes
[10:14] <tjaalton> a couple of months back
[10:14] <bryce> ah; not spotting it in my mail archive
[10:14] <tjaalton> me neither, but I'll look closer
[10:16] <bryce> anyway, sounds like there'll be fragmentation on the video acceleration front to look forward to this next year or so
[10:16] <tjaalton> here: http://lists.freedesktop.org/archives/xorg/2008-November/040279.html
[10:17] <tjaalton> so the API is free
[10:17] <bryce> heh
[10:18] <tjaalton> yes, too bad that now that nvidia has published vdpau, the other vendors still keep on working on their own stuff..
[10:18] <tjaalton> NIH ftw!
[10:19] <bryce> publishing the API != free
[10:19] <bryce> Microsoft publishes many API's for application developers to use...
[10:20] <tjaalton> well the copyright notice on the headers does sound like it's free..
[10:21] <tjaalton> I'd like to hear what the other vendors think of it..
[10:21] <tjaalton> nothing on the list or IRC so far
[10:21]  * bryce nods
[10:24] <bryce> I guess what I mean is that publishing the API is akin to putting the table of contents of a book on a website
[10:24] <bryce> you couldn't then claim that the book was "available for download from the web"
[10:25] <bryce> similarly, to really call an API "Free", I'd expect the reference implementation to also be published under a free-ish license
[10:25] <pwnguin> more importantly, a set of closed drivers conforming to an API will sustain a far slower the rate of change 
[10:27] <bryce> switching systems... bbiab
[10:59] <bryce> erf, I can only get -vesa booted.  wtf
[11:10] <tjaalton> jaunty?
[11:14] <bryce> yep
[11:15] <bryce> retesting -ati, brb
[11:19] <bryce> no go
[11:20] <bryce> ah well, tomorrow's project
[11:24] <tseliot> BTW the id of my NVIDIA card (02E2) is no longer in /usr/share/xserver-xorg/pci/nv.ids or anywhere in /usr/share/xserver-xorg/pci/ (in Intrepid)
[11:25] <tjaalton> so nv doesn't support it
[11:27] <tseliot> tjaalton: but it's a geforce 7300 and it was supported
[11:27] <tseliot> and should be supported by nv too
[11:27] <tjaalton> maybe the .ids parsing code is buggy then
[11:27] <tseliot> yes, that was my 1st guess
[11:28] <tjaalton> improvements welcome :)
[11:29] <tseliot> tjaalton: where's the code? In the source package of nv?
[11:29] <tjaalton> yes
[11:30] <tjaalton> there's a patch which modifies a Makefile
[11:30] <tjaalton> to generate the file
[11:30] <tseliot> ok, I think I've played with something similar before (for nvidia)
[11:31] <tjaalton> -nv is a special case because it lists id's in a couple of functions
[11:32] <tseliot> ok
[11:32] <tjaalton> so it's possible that the parser is buggy
[11:34] <tseliot> the ID is missing from the source file. Other ids for 7300 cards are provided but mine
[11:34] <tseliot> a patch should fix it
[11:35] <tjaalton> so forcing the driver works?
[11:35] <tjaalton> IIRC mvo had a similar case
[11:36] <tjaalton> where the driver didn't list the id, but works if forced
[11:37] <tseliot> it used to work. I'll test it and if it works, I'll give you a patch
[13:52] <marijus> hello, how to check if kms is running properly?
[13:55] <tjaalton> it isn't, period :)
[13:57] <marijus> ok... :) anyway... a happy new year!
[13:58] <tjaalton> unless you're running experimental code from upstream..
[13:58] <marijus> i do...
[13:58] <tjaalton> ok then
[15:00] <tseliot> tjaalton: nv works if I force it in the xorg.conf. Shall I give you debdiffs for intrepid and jaunty? Also I'll contact Aaron Plattner
[15:03] <tjaalton> jaunty is enough, doubt that intrepid will be updated
[15:08] <tseliot> ok
[15:08] <tseliot> BTW did you remove that fedora patch from X? The one which caused corruptions on KDE?
[15:12] <tjaalton> done in git
[15:12] <tjaalton> but I can't build a source package and upload because some xquartz binaries have been changed, and dpkg-buildpackage barfs because of it
[15:18] <tseliot> ouch
[15:21] <tjaalton> so either have to wait for next beta or remove xquartz from the git branch
[15:21] <tjaalton> since it's osx-specific anyway