[05:31] <mac_v> anyone know if there is a bug regarding segfaults or X crashes with ntfs partitions , when viewing image or video files
[05:31] <mac_v> ?
[05:32] <mac_v> I'm facing crashes , with the karmic packages in ATI...
[09:53] <hyperair> say, what libraries do i need for direct rendering to work with 32-bit programs on x64?
[09:56] <jcristau> libGL.
[09:56] <jcristau> and a dri driver
[11:30] <hyperair> jcristau: alright, i'll go break an x86 deb out for testing then.
[11:33] <tjaalton> hyperair: ia32-libs isn't enough?
[11:33] <hyperair> tjaalton: wine's segfaulting.
[11:33] <hyperair> 18:06:45 <stringfellow> the segfault is caused by http://bugs.freedesktop.org/show_bug.cgi?id=23335, but you really don't want to use indirect rendering in
[11:33] <hyperair> that.
[11:34] <hyperair> i submitted a patch upstream to wine to do a null pointer check
[11:34] <hyperair> but that doesn't solve the lesser problem that is not having dri
[11:34] <tjaalton> ok
[11:46] <hyperair> trace:wgl:X11DRV_WineGL_InitOpenglInfo Direct rendering enabled: False
[11:46] <hyperair> bah!
[11:46] <hyperair> it still doesn't work.
[11:46]  * hyperair scratches head
[12:06] <hyperair> tjaalton: okay, it's not my fault, and it's not the fault of mismatched libraries either
[12:06] <hyperair> libGL error: dlopen /usr/lib/dri/i965_dri.so failed (/usr/lib/dri/i965_dri.so: wrong ELF class: ELFCLASS64)
[12:06] <hyperair> libGL error: unable to load driver: i965_dri.so
[12:06] <hyperair> libGL error: driver pointer missing
[12:06]  * hyperair groan
[12:06] <hyperair> ia32-libs is broken.
[12:22] <mtc> in karmic, I see xserver-xorg-video-radeon an ubuntu core-developers maintained package, and used by default, whereas xserver-xorg-video-radeonhd is community maintained
[12:24] <mtc> my understanding is that the radeonhd driver will be a better the better driver for the modern AMD-ATI graphic cards (R500 / R600)
[12:29] <mtc> any insights why radeonhd was not chosen to be used by default?  seems a shame not to use a driver with the advanced features, especially as new users are immediately prompted to use the binary-only fglrx at their first login.
[12:33] <tjaalton> mtc: -radeon supports more cnips
[12:33] <tjaalton> chips
[12:34] <tjaalton> older ones too
[12:34] <mtc> sure that is true, but there are many other xorg drivers that support only a few cards
[12:34] <tjaalton> and it's maintained by ati, and -radeonhd is mainly a suse project
[12:37] <mtc> shoot, when was the last time you saw a 3dfx Voodoo graphics card, and that is a ubuntu developer maintained xorg driver package
[12:38] <tjaalton> why is that relevant?
[12:38] <mtc> you had said the -radeonhd was more card specific than the -radeon driver
[12:39] <tjaalton> and?
[12:39] <tjaalton> r3xx isn't uncommon
[12:39] <mvo> mtc: there is a wiki page at xorg  http://wiki.x.org/wiki/RadeonFeature that shows the support for the chips side-by-side
[12:40] <mvo> (RHD is the column for the radeonhd)
[12:40] <mtc> am pointing out that there are other drivers that are specific, which are still ubuntu developer maintained, and the voodoo are less common than the radeon R500 and R600 chipsets
[12:40] <mvo> that indicates that -ati covers the same HW as -radeonhd, sometimes even more complete
[12:41] <tjaalton> mtc: I already explained why -ati/radeon is the chosen one
[12:41] <mtc> mvo - interesting - I had not looked at that feature chart in a while, indeed the -radeon driver appears more complete
[12:42] <mvo> mtc: -ati did a big leap forward whenthe atombios docs got released IIRC 
[12:42] <tjaalton> there are too many drivers anyway, no point in following one that's more or less created for political reason
[12:42] <tjaalton> +s
[12:42]  * mvo should point out that he is not a expert in this area though
[12:43] <mtc> my understanding is the -radeon driver would not have the R500 / R600 chipset features, but that feature chart seems to indicate otherwise
[12:43] <tjaalton> but it's there for people to use if they like
[12:43] <tjaalton> like I said
[12:43] <tjaalton> it supports all the chips that are released
[12:43] <tjaalton> at least in git
[13:16] <mtc> well, nice to see the radeon drivers better supported in karmic... thanks for your thoughts on the subject of radeonhd
[13:17] <mtc> looks like there is an issue with DRI however - the Xorg log shows an error due to /usr/lib/dri/r600_dri.so file being missing
[13:19] <tjaalton> the newer ones don't have accelerated 3d-support yet
[13:19] <tjaalton> meaning r6xx ->
[13:35] <mtc> tjaalton: where do those dri libraries come from?  who can I expect to see a release of r600_dri.so ?
[13:37] <mtc> tjaalton: nevermind, found more information at freedesktop.org
[13:37] <tseliot> I disabled the r600 3d driver because it wasn't mature enough and it required a kernel patch which didn't make it on time. It should be ok in Lucid
[13:39] <mtc> thanks for your insights
[21:54] <jbarnes> wow karmic shuts down fast
[21:54] <jbarnes> so nice
[22:05] <bryce__> jbarnes, :-)
[22:52] <tormod> yeah I am not at all impressed by boot speed (I have a "normal" HD") but the shutdown kicks ass
[22:52] <tormod> almost like MacOS9 :)
[22:55] <tormod> albert23, your -intel crash fix (good job!) is now in jaunty xorg-edgers
[22:56] <albert23> tormod: I thought jaunty didn't have the crash?
[22:57] <tormod> albert23, I think I saw some jaunty reports, I was hoping it was this :)
[22:58] <albert23> tormod: it was straight 2.9.0 in jaunty before?
[22:59] <tormod> albert23, no it was the karmic one backported, so straight + one patch
[22:59] <tormod> albert23, I got some reports in private email on -intel crashing since a recent mesa update
[23:00] <albert23> Yeah, the mesa crash I have seen
[23:01] <albert23> tormod: I thought the crash was introduced in "uxa: Refactor create Picture for pixman format"
[23:01] <tormod> and there was someone on phoronix with a crash also
[23:01] <tormod> I told them to file bugs, I didn't look into it
[23:13]  * albert23 still thinks that crash was not in 2.9.0 Karmic is safe :-)