On 22/01/07, Joshua Netterfield <[EMAIL PROTECTED]> wrote:
sure, I'm not sure how much it will help you. Hardware graphics (DRI) works. It's Xinerama. When I don't disable it manually on a library by library (or program by program) basis (normally in the config.h file). glxinfo.log has glxinfo's responce .config is .config I have the default CXXFLAGS Just in case you want it, Xorg.0.log has the X log file. If it isn't obious, don't spend to much time on it... DRI works with SDL and that's what's really important. Thanks alot! On 1/21/07, michael lang < [EMAIL PROTECTED]> wrote: > > > > On 20/01/07, Joshua Netterfield < [EMAIL PROTECTED] > wrote: > > > > Hey guys. I fixed my problem with SDL... but not the real problem. I > > traced it back to Xinerama. > > > > Now, after editing SDL code, SDL works, but FLTK and WINE don't any > > ideas on how to fix the X code? Anyone else have similar problems? > > > > -- > > When the minority decides.... > > ...the majority is oppressed > > > > When the majority decides.... > > ...the minority is oppressed > > > > -- > > http://linuxfromscratch.org/mailman/listinfo/blfs-support > > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > > Unsubscribe: See the above information page > > > > > Can you perhaps supply a glxinfo log? Although (of what I suspect) > having no DRM shouldn't particularly crash your system, it might. You might > want to add your .config of your kernel and (if any) your C(XX)FLAGS too. > > -- > http://linuxfromscratch.org/mailman/listinfo/blfs-support > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page > > -- When the minority decides.... ...the majority is oppressed When the majority decides.... ...the minority is oppressed -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
So I finally got around to checking this, I found some interesting things in the xorg.log, but they may just be useless. first: (II) Primary Device is: PCI 03:00:0 (--) Assigning device section with no busID to primary device (WW) RADEON: No matching Device section for instance (BusID PCI:3:0:1) found Doesn't look harmful, but perhaps your udev isn't configured correctly? The device does get loaded though (WW) System lacks support for changing MTRRs You might want to add support for MTRR in your kernel if you have a pentium(pro) II or newer(assuming from your graphics card, you must have a rather new CPU too) next time you compile it. It supposedly gives 2.5 times speed increase for image writing. drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device or address) drmOpenDevice: open result is -1, (No such device or address) drmOpenDevice: Open failed drmOpenByBusid: Searching for BusID pci:0000:03:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci:0000:03:00.0 Same as before, is your udev configured correctly? Or is it just some weird PCI-E thing... (II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DDC:ddc2" removed. (II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DDC:ddc2" removed. (II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DDC:ddc2" removed. (II) RADEON(0): DDC Type: 2, Detected Type: 0 Now this strikes me as weird, but I have no idea what it does. Just want to point it out, for who knows what happens if you mess with it
-- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
