pwnguin | i wasn't aware mpx was in jaunty | 00:14 |
---|---|---|
pwnguin | (or xorg main) | 00:15 |
=== pwnguin_ is now known as pwnguin | ||
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:44 |
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:55 |
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:56 |
bryce | yeah, I didn't try building anything against it (this is an -ati box) | 09:57 |
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:58 |
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.. :/ | 09:59 |
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:00 |
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:01 |
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:02 |
tjaalton | yeah that sounds really bad | 10:03 |
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:05 |
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:07 |
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:08 |
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:09 |
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:10 |
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:11 |
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:12 |
tjaalton | yes | 10:13 |
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:14 |
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:16 |
tjaalton | so the API is free | 10:17 |
bryce | heh | 10:17 |
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:18 |
bryce | publishing the API != free | 10:19 |
bryce | Microsoft publishes many API's for application developers to use... | 10:19 |
tjaalton | well the copyright notice on the headers does sound like it's free.. | 10:20 |
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:21 | |
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:24 |
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:25 |
bryce | switching systems... bbiab | 10:27 |
bryce | erf, I can only get -vesa booted. wtf | 10:59 |
tjaalton | jaunty? | 11:10 |
bryce | yep | 11:14 |
bryce | retesting -ati, brb | 11:15 |
bryce | no go | 11:19 |
bryce | ah well, tomorrow's project | 11:20 |
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:24 |
tjaalton | so nv doesn't support it | 11:25 |
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:27 |
tjaalton | improvements welcome :) | 11:28 |
tseliot | tjaalton: where's the code? In the source package of nv? | 11:29 |
tjaalton | yes | 11:29 |
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:30 |
tjaalton | -nv is a special case because it lists id's in a couple of functions | 11:31 |
tseliot | ok | 11:32 |
tjaalton | so it's possible that the parser is buggy | 11:32 |
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:34 |
tjaalton | so forcing the driver works? | 11:35 |
tjaalton | IIRC mvo had a similar case | 11:35 |
tjaalton | where the driver didn't list the id, but works if forced | 11:36 |
tseliot | it used to work. I'll test it and if it works, I'll give you a patch | 11:37 |
marijus | hello, how to check if kms is running properly? | 13:52 |
tjaalton | it isn't, period :) | 13:55 |
marijus | ok... :) anyway... a happy new year! | 13:57 |
tjaalton | unless you're running experimental code from upstream.. | 13:58 |
marijus | i do... | 13:58 |
tjaalton | ok then | 13:58 |
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:00 |
tjaalton | jaunty is enough, doubt that intrepid will be updated | 15:03 |
tseliot | ok | 15:08 |
tseliot | BTW did you remove that fedora patch from X? The one which caused corruptions on KDE? | 15:08 |
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:12 |
tseliot | ouch | 15:18 |
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 | 15:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!