Re: xorg 6.9.0 and DRI
On Mon, 2006-02-20 at 23:52 -0500, Brian Victor wrote: % LIBGL_DEBUG=verbose glxinfo name of display: :0.0 libGL: XF86DRIGetClientDriverName: 4.0.4 r128 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r128_dri.so libGL error: dlopen /usr/X11R6/lib/modules/dri/r128_dri.so failed (/usr/X11R6/lib/modules/dri/r128_dri.so: undefined symbol: _glapi_add_dispatch) What does dpkg -S $(ldd $(which glxinfo)|grep libGL.so|cut -c16-|cut -d' ' -f1) say? -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: mouseemu 0.15 not working at all?
no output indeed. so do i understand you correctly? because of that, some other application steals the events which therefor cannot be processed by mouseemu? any ideas which applications that might be? No, that's not what I said. Usually mouseemu 'steals' the events. mouseemu not getting any events at all does point to the kernel as likely culprit, IMHO. Regarding other apps receiving events, see my suggestion to search /proc for any occurrences of 'event' files. Any process opening some event device will have a file /proc/pid/fd/event%d showing in /proc. To see which events are processed by the kernel, load the evbug module and watch /var/log/debug Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: location of iptables data
According to Michael Tautschnig, on Tue, 21 Feb 2006 07:13:02 +0100, so the kernel now has its own method of retaining iptables rules? Not really, or did you think of iptables-save/iptables-restore as the method of the kernel? Regards, Michael firestarter does store a config file in etc/firestarter, and load the rules at startup. it might be what you're looking for... -- Cedric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
2.6.16-rc* problems
Hi everyone, i am writing on an 14 ibook, mid-late 2005. Here is my /proc/cpuinfo processor : 0 cpu : 7447A, altivec supported clock : 666.666000MHz revision: 0.2 (pvr 8003 0102) bogomips: 36.73 timebase: 18432000 machine : PowerBook6,5 motherboard : PowerBook6,5 MacRISC3 Power Macintosh detected as : 287 (iBook G4) pmac flags : 001b L2 cache: 512K unified pmac-generation : NewWorld I am trying to compile linux 2.6.16-rc4 but i get a lot of errors. First: radeon graphic acceleration does not work anymore with the following error (from dmesg) [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held [drm:drm_unlock] *ERROR* Process 3653 using kernel context 0 (process 3653 is X) but the card is there: :00:10.0 VGA compatible controller: ATI Technologies Inc M9+ 5C63 [Radeon Mobility 9200 (AGP)] (rev 01) during boot i have the following lines in dmesg [drm] Initialized drm 1.0.1 20051102 [drm] Initialized radeon 1.21.0 20051229 on minor 0 so i suppose that drm IS working. Second: I cannot get the sound to work (kernel options are the same in 2.6.15.4 and with that kernel everything works) i get: electricmove:/home/uovobw# alsamixer alsamixer: function snd_ctl_open failed for default: No such device but the sound card is there since - even if not actually listed in lspci - i can hear sound.Music, games, eveything that has sounds works, but i cannot acces the card. also during boot i get: Audio jack unplugged, enabling speakers. input: dmasound beeper as /class/input/input4 AE-Init snapper mixer PowerMac Snapper DMA sound driver rev 016 installed Core driver edition 01.06 : PowerMac Built-in Sound driver edition 00.07 and this makes me think that alsa is working. But then: Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04 08:57:20 2006 UTC). snd: can't request rsrc 0 (Sound Control: 0x8001:80010fff) ALSA device list: No soundcards found. Third: Another strange thing happens to the bcm43xx driver for my airport extreme. The driver compiles from cvs with no problems, the module loads and the driver works,but i get TWO devices: eth1 and eth2. I should only have (like with 2.6.15.4) only eth0 (ethernet) and eth1 (wireless). The situation now is: eth0 no wireless extensions. eth1 IEEE 802.11b/g ESSID:off/any Nickname:Broadcom 4306 Mode:Monitor Frequency=2.422 GHz Access Point: Invalid Bit Rate:54 Mb/s Tx-Power=15 dBm RTS thr:off Fragment thr:off Encryption key:off eth2 no wireless extensions. Sometimes at boot eth2 is working and sometimes it's eth1.I could not figure out where is the difference. With 2.6.15.4 the eth2 interface did never show up. Here is my lsmod electricmove:/home/uovobw# lsmod Module Size Used by sbp2 26244 0 scsi_mod 125128 1 sbp2 eth139423428 0 ehci_hcd 39208 0 bcm43xx 437684 0 ieee80211softmac 32640 1 bcm43xx ohci_hcd 25572 0 ieee80211 40456 2 bcm43xx,ieee80211softmac ieee80211_crypt 7104 1 ieee80211 Any help would be appreciated. Thank you and sorry for the huge post. Bye -- Andrea Lusuardi aka UoVoBW Registered Linux User #364578 http://uovobw.homelinux.org There's no place I can be Since I found Serenity But you can't take the sky from me -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.16-rc* problems
On Tue, 2006-02-21 at 11:55 +0100, Andrea Lusuardi - UoVoBW wrote: [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held [drm:drm_unlock] *ERROR* Process 3653 using kernel context 0 (process 3653 is X) This is usually just a symptom of the DRI initialization failing, check the server log. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: GCC 4.1 in experimental / GCC for etch
Hi! Matthias Klose a écrit : The GCC (GNU compiler collection) 4.1 release candidate 1 can be found in experimental. Porters, please make sure that the package is built and uploaded (if it's not built by the experimental buildd). Please check that the symbols exported in the 4.1 libraries are a superset of those exported in the 4.0 libraries (these are libgcc1 (except m68k and hppa), libstdc++6, libffi4, libobjc1, libmudflap0). The proposed GCC plan for etch consists of: - uploading GCC 4.0.3 to unstable (this release is expected shortly after the GCC 4.1.0 release), let 4.0.3 migrate to testing. The GCC website seems to be down currently, could you please tell us when the release are expected? - uploading GCC 4.1 to unstable for those architectures which do not have ABI problems (these should be all, but should be validated). Nice! - Once the 4.1 packages are migrated to testing, make 4.1 the default compiler for i386, amd64, powerpc. These are the architectures, which are considred primary (linux) architectures by GCC upstream. For the other Debian architectures, the GCC port maintainers and the Debian port maintainers should make the call, if and when the default GCC is changed. I think you could also make 4.1 the default one for kfreebsd-i386. They are very few differences with the linux version, and the testsuite shows good results. - Make gij-4.1/gcj-4.1 the default for all architectures. - Stop building compiler packages from the GCC 3.3 source; the only packages built will be libstdc++5 (and libgcc1 on hppa/m68k). AFAIK the 2.4 kernels in Debian are built with gcc-3.3. What are the plans wrt to them? - Stop building compilers from GCC 3.4.x, namely gobjc-3.4, gnat-3.4 and g++-3.4 (it looks like we can go without g++-3.4 for the etch release). Still build gpc-3.4, g77-3.4 and gcc-3.4, as g77 cannot be found anymore in 4.x releases. Currently three architectures are still using gcc 3.4 to build the glibc, namely m68k, hppa and powerpc. For powerpc, it seems we can make the switch to at least gcc 4.0. There is currently a problem of locales, but not sure it is related to gcc-4.0. For hppa, the glibc builds well with gcc 4.0, but create problem with python/perl. It still has to be investigated. For m68k, the glibc does not build, gcc 4.0 segfault on system.c. It looks like gcc 4.1 fixes the problem, but the resulting glibc has not been tested. I think compilers are critical for the glibc, so we will have to coordinate the changes. Aurélien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 in experimental / GCC for etch
On Tue, Feb 21, 2006 at 11:34:55AM +0100, Aurelien Jarno wrote: - Once the 4.1 packages are migrated to testing, make 4.1 the default compiler for i386, amd64, powerpc. These are the architectures, which are considred primary (linux) architectures by GCC upstream. For the other Debian architectures, the GCC port maintainers and the Debian port maintainers should make the call, if and when the default GCC is changed. I think you could also make 4.1 the default one for kfreebsd-i386. They are very few differences with the linux version, and the testsuite shows good results. Agreed, but.. (see below) - Stop building compilers from GCC 3.4.x, namely gobjc-3.4, gnat-3.4 and g++-3.4 (it looks like we can go without g++-3.4 for the etch release). Still build gpc-3.4, g77-3.4 and gcc-3.4, as g77 cannot be found anymore in 4.x releases. Currently three architectures are still using gcc 3.4 to build the glibc, namely m68k, hppa and powerpc. Building kfreebsd-5 (and kfreebsd-6, etc) requires gcc-3.4 as well. Note that upstream only supports their own fork of gcc-3.4 to build the kernel, and I'm not aware of any plans to update it short-term. So AFAIK no problem on our side to make gcc-4.1 the default, as long as gcc-3.4 is still present. -- Robert Millan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xorg 6.9.0 and DRI
On Tue, Feb 21, 2006 at 10:42:00AM +0100, Michel D�nzer wrote: On Mon, 2006-02-20 at 23:52 -0500, Brian Victor wrote: % LIBGL_DEBUG=verbose glxinfo name of display: :0.0 libGL: XF86DRIGetClientDriverName: 4.0.4 r128 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r128_dri.so libGL error: dlopen /usr/X11R6/lib/modules/dri/r128_dri.so failed (/usr/X11R6/lib/modules/dri/r128_dri.so: undefined symbol: _glapi_add_dispatch) What does dpkg -S $(ldd $(which glxinfo)|grep libGL.so|cut -c16-|cut -d' ' -f1) say? % dpkg -S $(ldd $(which glxinfo)|grep libGL.so|cut -c16-|cut -d' ' -f1) xlibmesa-gl: /usr/X11R6/lib/libGL.so.1 -- Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xorg 6.9.0 and DRI
On Tue, 2006-02-21 at 08:25 -0500, Brian Victor wrote: % dpkg -S $(ldd $(which glxinfo)|grep libGL.so|cut -c16-|cut -d' ' -f1) xlibmesa-gl: /usr/X11R6/lib/libGL.so.1 Hmm, that looks fine... no idea what's up. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: mouseemu 0.15 not working at all?
no output indeed. so do i understand you correctly? because of that, some other application steals the events which therefor cannot be processed by mouseemu? any ideas which applications that might be? No, that's not what I said. Usually mouseemu 'steals' the events. mouseemu not getting any events at all does point to the kernel as likely culprit, IMHO. so what should be activated in the kernel in addition to CONFIG_INPUT_UINPUT=[y|m] (the only option i found that was necessary). Regarding other apps receiving events, see my suggestion to search /proc for any occurrences of 'event' files. Any process opening some event device will have a file /proc/pid/fd/event%d showing in /proc. ls /proc/*/fd does not show any event%d files only symlinks in earlier postings in debian-powerpc, i have found something like /proc/input/devices. the input directory does not exist on my mac. To see which events are processed by the kernel, load the evbug module and watch /var/log/debug ok, moving the mouse produces something like ... event. dev: adb3:3.01/input, type: 2, code: 1, value -1 mouse-click ... event. dev: adb3:3.01/input, type: 1, code: 272, value 0 event. dev: adb3:3.01/input, type: 0, code: 0, value 0 pressing ctrl ... event. dev: adb2:2.c4/input, type: 1, code: 29, value 0 event. dev: adb3:3.01/input, type: 0, code: 0, value 0 michael -- Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Newbie Debian Etch PPC Yaboot Install Problems.
Hi again, I installed Debian (Etch) PPC (I think this is considered to be testing). At the end of the install, I got the following message: Yaboot didn't install. You will need to boot manually with the /boot/vmlinux kernel on partition /dev/sda3 and root=/dev/sda3 passed on as a kernel argument. Since an Ubuntu yaboot kicks in at startup, I pressed L and then at the boot prompt, I wrote: /boot/vmlinux /dev/sda3 root=/dev/sda3 This didn't work as I got the following error: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) S, what do I do to boot into the Debian system for the first time and how do I resolve the yaboot issue permanently? Cheers, Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu 0.15 not working at all?
No, that's not what I said. Usually mouseemu 'steals' the events. mouseemu not getting any events at all does point to the kernel as likely culprit, IMHO. so what should be activated in the kernel in addition to CONFIG_INPUT_UINPUT=[y|m] (the only option i found that was necessary). CONFIG_INPUT_EVDEV, obviously. Regarding other apps receiving events, see my suggestion to search /proc for any occurrences of 'event' files. Any process opening some event device will have a file /proc/pid/fd/event%d showing in /proc. ls /proc/*/fd does not show any event%d files only symlinks Just great. If you stop for a moment and examine any arbitrary process's fd directory you'll notice it's always symlinks. s/file/entry/ above if you like. Now which are the processes that have symlinks containing 'event' in their fd set? in earlier postings in debian-powerpc, i have found something like /proc/input/devices. the input directory does not exist on my mac. To see which events are processed by the kernel, load the evbug module and watch /var/log/debug ok, moving the mouse produces something like ... event. dev: adb3:3.01/input, type: 2, code: 1, value -1 So far so good. In theory, the output should change somewhat after starting mouseemu - all the adb3:3.01/input stuff should be replaced by NULL, for instance (that's mouseemu's virtual keyboard and mouse injecting the events back into the system). (Note that you can figure out the event codes for the emulation keys from the evbug output when mouseemu is not running - just to double check your configuration.) If the output does not change after starting mouseemu, something in the device open code of mouseemu fails (I doubt it, though). Look through the debug log to find the spot where the evbug module loads - it reports all registered event devices with name and device name. You should find all keyboard, mouse and button devices listed there, plus a few odd ones. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
AmigaOne PPC Linux: Problems with Interrupts
Hi,
I encountered some problems with Linux PPC on the AmigaOne. As you can see
in the /proc/interrupts output below, the AmigaOne has a i8259 PIC (no
OpenPIC). The first problem is, that the interrupts 7 and 10 are shown as
Edge triggered, but they're set to Level in the u-boot (firmware)
preferences. I'm not sure, if u-boot setups the interrupts, therefore I
added this code to the platform PCI initialisation code (copied from
prep_pci.c):
void __init
amigaone_pcibios_fixup(void)
{
/* IRQ 7 is level triggered. */
unsigned char irq_edge_mask_lo = 0x80;
/* IRQ, 9, 10, 11 is level triggered. */
unsigned char irq_edge_mask_hi = 0x07;
outb(inb(0x04d0)|irq_edge_mask_lo, 0x4d0); /* primary 8259 */
outb(inb(0x04d1)|irq_edge_mask_hi, 0x4d1); /* cascaded 8259 */
}
Unortunately this didn't help and the interrupts seem to be still edge
triggered.
/proc/interrupts:
CPU0
1:189 i8259 Edge i8042
2: 0 i8259 Edge 82c59 secondary cascade
5: 0 i8259 Edge uhci_hcd, uhci_hcd
7:546 i8259 Edge eth0
10: 0 i8259 Edge EMU10K1
12: 8217 i8259 Edge i8042
14: 19597 i8259 Edge ide0
15: 18951 i8259 Edge ide1
BAD: 2
The other issue are the 2 BAD interrupts shown above. Does this have to do
something with the edge or level triggered mode or is it a interrupt
routing problem?
Thanks!
Gerhard
Other infos:
/proc/ioports
-00bf : PCI host bridge
-001f : dma1
0020-0021 : 8259 (master)
0040-005f : timer
0060-006f : i8042
0080-008f : dma page reg
00a0-00a1 : 8259 (slave)
00c0-00df : dma2
0170-0177 : ide1
01f0-01f7 : ide0
0278-027a : parport2
02f8-02ff : serial
0376-0376 : ide1
0378-037a : parport0
03bc-03be : parport1
03c0-03df : vga+
03e8-03ef : serial
03f6-03f6 : ide0
03f8-03ff : serial
04d0-04d1 : 8259 edge control
2000-2fff : PCI Bus #01
2000-20ff : :01:00.0
cc00-cc0f : :00:07.1
cc00-cc07 : ide0
cc08-cc0f : ide1
00802000-0080207f : :00:06.0
00802000-0080207f : :00:06.0
00802080-0080209f : :00:07.2
00802080-0080209f : uhci_hcd
008020a0-008020bf : :00:07.3
008020a0-008020bf : uhci_hcd
00802100-008021ff : :00:07.5
00802200-00802203 : :00:07.5
00802204-00802207 : :00:07.5
00802300-008023ff : :00:07.6
00802400-0080241f : :00:09.0
00802400-0080241f : EMU10K1
00802420-00802427 : :00:09.1
00802420-00802427 : emu10k1-gp
--
10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu 0.15 not working at all?
No, that's not what I said. Usually mouseemu 'steals' the events. mouseemu not getting any events at all does point to the kernel as likely culprit, IMHO. so what should be activated in the kernel in addition to CONFIG_INPUT_UINPUT=[y|m] (the only option i found that was necessary). CONFIG_INPUT_EVDEV, obviously. no. i just looked it up. that's also activated. Regarding other apps receiving events, see my suggestion to search /proc for any occurrences of 'event' files. Any process opening some event device will have a file /proc/pid/fd/event%d showing in /proc. ls /proc/*/fd does not show any event%d files only symlinks Just great. If you stop for a moment and examine any arbitrary process's fd directory you'll notice it's always symlinks. s/file/entry/ above if you like. Now which are the processes that have symlinks containing 'event' in their fd set? again: none. there is not entry/file that contains the string 'event' in earlier postings in debian-powerpc, i have found something like /proc/input/devices. the input directory does not exist on my mac. To see which events are processed by the kernel, load the evbug module and watch /var/log/debug ok, moving the mouse produces something like ... event. dev: adb3:3.01/input, type: 2, code: 1, value -1 So far so good. In theory, the output should change somewhat after starting mouseemu - all the adb3:3.01/input stuff should be replaced by NULL, for instance (that's mouseemu's virtual keyboard and mouse injecting the events back into the system). jup. /var/log/debug logs exactly two different lines: connected device: mouseemu virtual keyboard, NULL connected device: mouseemu virtual mouse, NULL afterwards (mouseemu still running) i have again the adb3:301/input lines for mouse-movement. (...) Look through the debug log to find the spot where the evbug module loads - it reports all registered event devices with name and device name. You should find all keyboard, mouse and button devices listed there, plus a few odd ones. i have compiled evbug directly into the kernel, so no module. i have looked up the /var/log/debug log from beginning of the last startup of my mac. the first evbug entries are: evbug.c: connected device: adb keyboard, adb2:2.c4/input evbug.c: connected device: adb powerbook buttons, adb7:7.1f/input evbug.c: connected device: adb mouse, adb3:3.01/input (...) evbug.c: connected device: dmasound beeper, macio/input0 (...) evbug.c: connected device: hid 05ac:1000, usb-001:10:1a.0-1/input0 evbug.c: connected device: hid 05ac:1000, usb-001:10:1a.0-1/input1 after that mainly the event-entries mentioned earlier are logged michael -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-PPC powerbook laptop support.
Joerg Maier wrote: on my 12 swsusp only works when using no initrd. No patch for the kernel is necessary in my case, only use the swsusp that is in vanilla already ( i think it is swsusp2). If it is a vanilla kernel then it uses the old swsusp, not swsusp2. But since the swsusp in the kernel has been improved recently, it is not really old. Which kernel patch do you use magnus? At the moment I don't use any patch, because swsusp also works fine for me, it has only the small advantage, that I don't need to apply the patch. swsusp2 works for me just without any difference. You can get the swsusp2 patch from http://www.suspend2.net/ cu, Magnum -- Carl Magnus Rosenbaum M.A. Tel: 089 - 700 666 26 Administration - Programmierung - Weiterbildung Fax: 089 - 700 666 86 http://cmr.forestfactory.de/ Mobil: 0163 - 700 666 2 PGP Fingerprint: DEBC 3C99 EF1D 74F0 D4C7 EFF5 C268 3690 0EA1 7641 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Baterry problems
Hi, I used to charge my laptop when I have little battery on it. The thing is that now it just won't charge. If I turn it off and plug the cable to charge the powerbook it starts charging, but when I boot linux it suddenly stops doing this. Any ideas when I can check this? I know that AC Charger works, as soon it boot Linux it just stops charging the laptop. thaks for your time. Orlando. -- --- Javier O. Ramírez Martínez Key fingerprint = E7D8 22DC 5B71 72DC A06A 61F4 D823 35ED 2E67 CFB2 linux.mty.itesm.mx/~oramirez
Re: xorg 6.9.0 and DRI
On Tue, 2006-02-21 at 14:29 +0100, Michel Dänzer wrote: On Tue, 2006-02-21 at 08:25 -0500, Brian Victor wrote: % dpkg -S $(ldd $(which glxinfo)|grep libGL.so|cut -c16-|cut -d' ' -f1) xlibmesa-gl: /usr/X11R6/lib/libGL.so.1 Hmm, that looks fine... no idea what's up. For my radeon 9600 I need libgl1-mesa-glx and not xlibmesa-gl -- Yves-Alexis Perez signature.asc Description: This is a digitally signed message part
Re: xorg 6.9.0 and DRI
On Tue, 2006-02-21 at 21:34 +0100, Yves-Alexis Perez wrote:
On Tue, 2006-02-21 at 14:29 +0100, Michel Dänzer wrote:
On Tue, 2006-02-21 at 08:25 -0500, Brian Victor wrote:
% dpkg -S $(ldd $(which glxinfo)|grep libGL.so|cut -c16-|cut -d' ' -f1)
xlibmesa-gl: /usr/X11R6/lib/libGL.so.1
Hmm, that looks fine... no idea what's up.
For my radeon 9600 I need libgl1-mesa-glx and not xlibmesa-gl
That's because xlibmesa-dri doesn't have the r300 driver. It doesn't
explain why xlibmesa-{gl,dri} aren't working for him, but
libgl1-mesa-{glx,dri} might be worth a try anyway.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: xorg 6.9.0 and DRI
On Wed, Feb 22, 2006 at 01:33:25AM +0100, Michel D�nzer wrote:
On Tue, 2006-02-21 at 21:34 +0100, Yves-Alexis Perez wrote:
On Tue, 2006-02-21 at 14:29 +0100, Michel Dänzer wrote:
On Tue, 2006-02-21 at 08:25 -0500, Brian Victor wrote:
% dpkg -S $(ldd $(which glxinfo)|grep libGL.so|cut -c16-|cut -d' ' -f1)
xlibmesa-gl: /usr/X11R6/lib/libGL.so.1
Hmm, that looks fine... no idea what's up.
For my radeon 9600 I need libgl1-mesa-glx and not xlibmesa-gl
That's because xlibmesa-dri doesn't have the r300 driver. It doesn't
explain why xlibmesa-{gl,dri} aren't working for him, but
libgl1-mesa-{glx,dri} might be worth a try anyway.
Well, I'm not sure how it happened, but it looks like my libGL.so.1
wasn't the right copy. Maybe I did something wacky when I compiled a
prerelease of Xorg, but regardless, I moved that out of the way and DRI
seems to be working now. Thanks for your help!
--
Brian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
