Re: [PATCH] new radeon memory map fixes
Xorg driver patch: http://gate.crashing.org/~benh/radeon-memmap-7.0-2.diff DRM patch: http://gate.crashing.org/~benh/radeon-memmap-drm-1.diff Ok, DRM patch is busted, it breaks an assumption done by the DRM that AGP is always appended to the framebuffer in card space which is no longer the case. I'll need to do a bit more fixing there. New patch soon hopefully. Ben. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5710] DRI libs relocation problems on hardened systems
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=5710 --- Additional Comments From [EMAIL PROTECTED] 2006-01-26 20:37 --- The mesa take 2 patch from bug 4197 fixes the issue. DRI now works here. Thanks. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Adding new R300 PCIID
Hi,
I have a Dell R300 of some sort. Its PCI ID was not in
drm_pciids.h
so I added: (didn't know so added both heads listing)
{0x1002, 0x5b60, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R300}, \
{0x1002, 0x5b70, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R300}, \
Cards lspci -vvn output:
:01:00.0 0300: 1002:5b60
Subsystem: 1002:0402
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR-
Interrupt: pin A routed to IRQ 16
Region 0: Memory at d000 (32-bit, prefetchable) [size=128M]
Region 1: I/O ports at dc00 [size=256]
Region 2: Memory at dfde (32-bit, non-prefetchable) [size=64K]
Expansion ROM at dfe0 [disabled] [size=128K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] #10 [0001]
Capabilities: [80] Message Signalled Interrupts: 64bit+
Queue=0/0 Enable-
Address: Data:
:01:00.1 0380: 1002:5b70
Subsystem: 1002:0403
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 0, Cache Line Size: 0x10 (64 bytes)
Region 0: Memory at dfdf (32-bit, non-prefetchable) [size=64K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] #10 [0001]
and lspci -v output (for some strings)
:01:00.0 VGA compatible controller: ATI Technologies Inc RV370
5B60 [Radeon X300 (PCIE)] (prog-if 00 [VGA])
Subsystem: ATI Technologies Inc: Unknown device 0402
Flags: fast devsel, IRQ 16
Memory at d000 (32-bit, prefetchable) [size=128M]
I/O ports at dc00 [size=256]
Memory at dfde (32-bit, non-prefetchable) [size=64K]
Expansion ROM at dfe0 [disabled] [size=128K]
Capabilities: [50] Power Management version 2
Capabilities: [58] #10 [0001]
Capabilities: [80] Message Signalled Interrupts: 64bit+
Queue=0/0 Enable-
:01:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE]
Subsystem: ATI Technologies Inc: Unknown device 0403
Flags: bus master, fast devsel, latency 0
Memory at dfdf (32-bit, non-prefetchable) [size=64K]
Capabilities: [50] Power Management version 2
Capabilities: [58] #10 [0001]
I am trying to get dual head to work properly. Maybe someone can help.
I don't want clone or mergefb i want two independant screens.
But I only get those two modes.
Here is my current configs incarnation:
Section Device
Identifier ATI R300 1
Driver radeon
# Option MonitorLayout TMDS, TMDS
Option DDCModeTRUE
BusID PCI:1:0:0
Screen 0
EndSection
Section Device
Identifier ATI R300 2
Driver radeon
Option DDCModeTRUE
BusID PCI:1:0:0
Screen 1
EndSection
usual screen and monitor sections, and screen 2 set RightOf screen 1
in layout section. This gives me a clone screen on 2 that the mouse
can not get on.
If anyone is interested in helping I can give logs, full config etc.
Thank you
Thorben
PS I am not on the list, please CC me
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5737] New: Textrel in radeon_dri.so prevents useful modules for hardened systems
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=5737 Summary: Textrel in radeon_dri.so prevents useful modules for hardened systems Product: DRI Version: DRI CVS Platform: PC OS/Version: Linux Status: NEW Severity: minor Priority: P2 Component: DRM modules AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] That's the story. The symptom is an unrecognized symbol drm_cleanup_pci when loading drm.ko or radeon.ko. BTW I am nothing to do with pax, grsecurity, or any of it - simply a user. As radeon_dri.so is precompiled, I have no opportunity to tweak or patch it. Bugs 4197/5710 refer and explain, although the file under discussion is libGL.so The systems is a Hardened Linux From Scratch from December 05 Versions are: DRI common-* from Xorg-6.9.0 with the mesa patch attached to bug 4197; radeon-20060125. The alternatives are 1. do without or 2. Weaken system security. If forced to choose, I will do without. Users of hardened systems are neither as version conscious or as demanding as gamers. Any chance of a snapshot to compile on a hardened system? I'll gladly sign an nda if required. If not, what cards can be supported in a textrel free way? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Savage IX/Thinkpad T20: Lockup with DMA
Hello DRI developers, on my ThinkPad T20, I experience Lockups with either type of DMA, be it Vertex DMA or AGP texture access. With Option DmaMode None and Option AGPMode 2 glxgears runs perfectly, as does glxinfo, whereas ppracer locks up the system at start (supposedly because of using AGP texturing). If I add Option BusType PCI, everything works as expected. I am using: X Window System Version 6.9.0 (Debian 6.9.0.dfsg.1-2 20060106075605 David Nusinow [EMAIL PROTECTED]) common-20060124-linux.i386.tar.bz2 savage-20060124-linux.i386.tar.bz2 kernel 2.6.15-rc4 (is this a problem?) Thanks for your work, Michael Karcher --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Marbleblast + r300
On 1/26/06, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Marbleblast, a game from GarageGames, seems to have an issue with the r300 driver... The game crashes when it goes to start a new level. It crashes with: drmRadeonCmdBuffer: -22 (exiting) drmRadeonCmdBuffer: -22 (exiting) dmesg shows: [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed range check (reg=4540 sz=3) [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed This likely due to an old drm, Aapo added a new reg lately to fix texture upload issue. Thus you need a new drm which accept to program this reg. best, Jerome Glisse --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Marbleblast + r300
On Thursday 26 January 2006 08:41, Jerome Glisse wrote: On 1/26/06, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Marbleblast, a game from GarageGames, seems to have an issue with the r300 driver... The game crashes when it goes to start a new level. It crashes with: drmRadeonCmdBuffer: -22 (exiting) drmRadeonCmdBuffer: -22 (exiting) dmesg shows: [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed range check (reg=4540 sz=3) [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed This likely due to an old drm, Aapo added a new reg lately to fix texture upload issue. Thus you need a new drm which accept to program this reg. best, Jerome Glisse How new of a DRM do I need? :-) This is what I have that isn't working: [drm] Initialized drm 1.0.1 20051102 [drm] Initialized radeon 1.22.0 20060120 on minor 0: PCI device 1002:5e4b (ATI Technologies Inc) Adam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Marbleblast + r300
On 1/26/06, Adam K Kirchhoff [EMAIL PROTECTED] wrote: How new of a DRM do I need? :-) This is what I have that isn't working: [drm] Initialized drm 1.0.1 20051102 [drm] Initialized radeon 1.22.0 20060120 on minor 0: PCI device 1002:5e4b (ATI Technologies Inc) Somethings you check after 21/01/2006 or 01/21/2006 (depends on how you like to see date written :)), i haven't acces to a machine with it or cvs right now so i can't tell you exact number. If you got somethings more recent then there is effectively an issue... best, Jerome Glisse --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
r300 - problem with fragment program
Hi, I've been trying to run project xenocide(projectxenocide.com), but at the start of it there's a ps20 shader which always causes a crash. Setting USE_ARB_F_P == 0 in r300_context.c makes the program run. I'm using current mesa and drm(1.2) The error I get is: drmRadeonCmdBuffer: -22 (exiting) And in dmesg: [drm:r300_emit_carefully_checked_packet0] *ERROR* Cannot emit more than 64 values at a time (reg=4c00 sz=68) [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed Is 64 values a hardware limit? Boris Peterbarg --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 - problem with fragment program
On 1/26/06, Boris Peterbarg [EMAIL PROTECTED] wrote: Hi, I've been trying to run project xenocide(projectxenocide.com), but at the start of it there's a ps20 shader which always causes a crash. Setting USE_ARB_F_P == 0 in r300_context.c makes the program run. I'm using current mesa and drm(1.2) The error I get is: drmRadeonCmdBuffer: -22 (exiting) And in dmesg: [drm:r300_emit_carefully_checked_packet0] *ERROR* Cannot emit more than 64 values at a time (reg=4c00 sz=68) [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed Is 64 values a hardware limit? Seems that the ps20 shader reach the hardware limit. Does fglrx works with this ? This might be due to the traduction of the program which isn't optimal. I guess we can save few more instructions and go from 68 to 64. Btw coud you try with USE_ARB_F_P == 1 and setting if (1) Dump.. in r300_fragprog.c (at bottom of the file). best, Jerome Glisse --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Savage IX/Thinkpad T20: red/blue stereo in xmakemol doesn't work
Hello developers, The red/blue stereo rendering of xmakemol doesn't work with savage hardware acceleration, but looks fine without (LIBGL_ALWAYS_INDIRECT=1). This is true for the current DRI snapshot as well as for an older snapshot from about August of last year. Do you need further information for debugging this problem? Screenshots are on http://www.physik.fu-berlin.de/~karcher/good.png (software rendered) and http://www.physik.fu-berlin.de/~karcher/bad.png (hardware rendered). Michael Karcher --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Marbleblast + r300
On Thu, 26 Jan 2006 14:41:45 +0100 Jerome Glisse [EMAIL PROTECTED] wrote: On 1/26/06, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Marbleblast, a game from GarageGames, seems to have an issue with the r300 driver... The game crashes when it goes to start a new level. It crashes with: drmRadeonCmdBuffer: -22 (exiting) drmRadeonCmdBuffer: -22 (exiting) dmesg shows: [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed range check (reg=4540 sz=3) [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed This likely due to an old drm, Aapo added a new reg lately to fix texture upload issue. Thus you need a new drm which accept to program this reg. Problem here was that offset(=0x0) from a disabled tmu were sent to drm. multiarb with unit 0 disabled and unit 1 enabled triggered this same problem. This should be fixed in cvs now. -- Aapo Tahkola --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Marbleblast + r300
On Thu, 26 Jan 2006 18:06:25 + Aapo Tahkola [EMAIL PROTECTED] wrote: On Thu, 26 Jan 2006 14:41:45 +0100 Jerome Glisse [EMAIL PROTECTED] wrote: On 1/26/06, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Marbleblast, a game from GarageGames, seems to have an issue with the r300 driver... The game crashes when it goes to start a new level. It crashes with: drmRadeonCmdBuffer: -22 (exiting) drmRadeonCmdBuffer: -22 (exiting) dmesg shows: [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed range check (reg=4540 sz=3) [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed This likely due to an old drm, Aapo added a new reg lately to fix texture upload issue. Thus you need a new drm which accept to program this reg. Problem here was that offset(=0x0) from a disabled tmu were sent to drm. multiarb with unit 0 disabled and unit 1 enabled triggered this same problem. This should be fixed in cvs now. Forgot to mention that I had to disable GL_TEXTURE_LOD_BIAS_EXT because it directly touches state atoms. Does anyone have any ideas on how to make that appear in struct r300_tex_obj ? Secondly, some Marbleblast levels seem to trigger assertion in texenvprogram.c:619 . -- Aapo Tahkola --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Adding new R300 PCIID
On 1/26/06, TJ [EMAIL PROTECTED] wrote:
Hi,
I have a Dell R300 of some sort. Its PCI ID was not in
drm_pciids.h
so I added: (didn't know so added both heads listing)
{0x1002, 0x5b60, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R300}, \
{0x1002, 0x5b70, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R300}, \
you don't need the secondary id. also the drm isn't necessary for
dualhead and won't actually be used in what you are trying to do.
Cards lspci -vvn output:
:01:00.0 0300: 1002:5b60
Subsystem: 1002:0402
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR-
Interrupt: pin A routed to IRQ 16
Region 0: Memory at d000 (32-bit, prefetchable) [size=128M]
Region 1: I/O ports at dc00 [size=256]
Region 2: Memory at dfde (32-bit, non-prefetchable) [size=64K]
Expansion ROM at dfe0 [disabled] [size=128K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] #10 [0001]
Capabilities: [80] Message Signalled Interrupts: 64bit+
Queue=0/0 Enable-
Address: Data:
:01:00.1 0380: 1002:5b70
Subsystem: 1002:0403
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 0, Cache Line Size: 0x10 (64 bytes)
Region 0: Memory at dfdf (32-bit, non-prefetchable) [size=64K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] #10 [0001]
and lspci -v output (for some strings)
:01:00.0 VGA compatible controller: ATI Technologies Inc RV370
5B60 [Radeon X300 (PCIE)] (prog-if 00 [VGA])
Subsystem: ATI Technologies Inc: Unknown device 0402
Flags: fast devsel, IRQ 16
Memory at d000 (32-bit, prefetchable) [size=128M]
I/O ports at dc00 [size=256]
Memory at dfde (32-bit, non-prefetchable) [size=64K]
Expansion ROM at dfe0 [disabled] [size=128K]
Capabilities: [50] Power Management version 2
Capabilities: [58] #10 [0001]
Capabilities: [80] Message Signalled Interrupts: 64bit+
Queue=0/0 Enable-
:01:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE]
Subsystem: ATI Technologies Inc: Unknown device 0403
Flags: bus master, fast devsel, latency 0
Memory at dfdf (32-bit, non-prefetchable) [size=64K]
Capabilities: [50] Power Management version 2
Capabilities: [58] #10 [0001]
you can ignore the :01:00.1 id.
I am trying to get dual head to work properly. Maybe someone can help.
I don't want clone or mergefb i want two independant screens.
But I only get those two modes.
Here is my current configs incarnation:
this is more of an x server issues than DRI related. In fact the DRI
won't even work with two independant screens on a dualhead card.
Section Device
Identifier ATI R300 1
Driver radeon
# Option MonitorLayout TMDS, TMDS
Option DDCModeTRUE
BusID PCI:1:0:0
Screen 0
EndSection
Section Device
Identifier ATI R300 2
Driver radeon
Option DDCModeTRUE
BusID PCI:1:0:0
Screen 1
EndSection
usual screen and monitor sections, and screen 2 set RightOf screen 1
in layout section. This gives me a clone screen on 2 that the mouse
can not get on.
If anyone is interested in helping I can give logs, full config etc.
can you post your full log and config somewhere?
Alex
Thank you
Thorben
PS I am not on the list, please CC me
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage IX/Thinkpad T20: Lockup with DMA
Am Donnerstag, den 26.01.2006, 13:46 +0100 schrieb Michael Karcher: Hello DRI developers, on my ThinkPad T20, I experience Lockups with either type of DMA, be it Vertex DMA or AGP texture access. With Option DmaMode None and Option AGPMode 2 glxgears runs perfectly, as does glxinfo, whereas ppracer locks up the system at start (supposedly because of using AGP texturing). If I add Option BusType PCI, everything works as expected. Did you suspend/resume the notebook? There was a problem with AGP after resume that can be worked around by using BusType PCI. I suspected that the bug was actually in the VIA AGP driver, not in the Savage driver. I never got around to looking into it in detail though. Am Donnerstag, den 26.01.2006, 14:46 +0100 schrieb Michael Karcher: Hello developers, The red/blue stereo rendering of xmakemol doesn't work with savage hardware acceleration, but looks fine without (LIBGL_ALWAYS_INDIRECT=1). This is true for the current DRI snapshot as well as for an older snapshot from about August of last year. Do you need further information for debugging this problem? Screenshots are on http://www.physik.fu-berlin.de/~karcher/good.png (software rendered) and http://www.physik.fu-berlin.de/~karcher/bad.png (hardware rendered). No one has been working on the Savage 3D driver in a while. Your odds of getting someone to look into this problem are fairly low ATM. Sorry. Feel free to open a bug in the freedesktop.org bugzilla. Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 - problem with fragment program
Jerome Glisse wrote: On 1/26/06, Boris Peterbarg [EMAIL PROTECTED] wrote: Hi, I've been trying to run project xenocide(projectxenocide.com), but at the start of it there's a ps20 shader which always causes a crash. Setting USE_ARB_F_P == 0 in r300_context.c makes the program run. I'm using current mesa and drm(1.2) The error I get is: drmRadeonCmdBuffer: -22 (exiting) And in dmesg: [drm:r300_emit_carefully_checked_packet0] *ERROR* Cannot emit more than 64 values at a time (reg=4c00 sz=68) [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed Is 64 values a hardware limit? Seems that the ps20 shader reach the hardware limit. Does fglrx works with this ? This might be due to the traduction of the program which isn't optimal. I guess we can save few more instructions and go from 68 to 64. Btw coud you try with USE_ARB_F_P == 1 and setting if (1) Dump.. in r300_fragprog.c (at bottom of the file). fglrx halts even with glxinfo here for some reason (linux 2.6.15.1, xorg 2.6.9) I've attached the dump with USE_ARB_F_P == 1. Boris Peterbarg dump.tar.gz Description: GNU Zip compressed data
Re: r300 - problem with fragment program
Boris Peterbarg wrote: fglrx halts even with glxinfo here for some reason (linux 2.6.15.1, xorg 2.6.9) I've attached the dump with USE_ARB_F_P == 1. Oops, should've been xorg 6.9.0 Boris Peterbarg Boris Peterbarg --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: OT: fglrx linux 2.6.16.1
This is somewhat off-topic but I figured I'd mention it anyway... Boris Peterbarg wrote: fglrx halts even with glxinfo here for some reason (linux 2.6.15.1, xorg 2.6.9) I've attached the dump with USE_ARB_F_P == 1. Oops, should've been xorg 6.9.0 I discovered the same problem this morning on my Athlon64 box using the 64-bit drivers with xorg 6.8.2. It appears to be something with fglrx and 2.6.15.1... even with the latest fglrx drivers it hangs, and dmesg shows a number of kernel stack traces... but when I switched back to a 2.6.14.4 kernel everything was fine again. - Brian __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage IX/Thinkpad T20: Lockup with DMA
On 1/26/06, Michael Karcher [EMAIL PROTECTED] wrote: Hello DRI developers, on my ThinkPad T20, I experience Lockups with either type of DMA, be it Vertex DMA or AGP texture access. With Option DmaMode None and Option AGPMode 2 glxgears runs perfectly, as does glxinfo, whereas ppracer locks up the system at start (supposedly because of using AGP texturing). If I add Option BusType PCI, everything works as expected. I am using: X Window System Version 6.9.0 (Debian 6.9.0.dfsg.1-2 20060106075605 David Nusinow [EMAIL PROTECTED]) common-20060124-linux.i386.tar.bz2 savage-20060124-linux.i386.tar.bz2 kernel 2.6.15-rc4 (is this a problem?) Thanks for your work, Michael Karcher It's a known problem with savage based thinkpads and AGP. I was never able to track it down. you might try messing with the shadowstatus option. I want to say that may be related, but it's been a while since I looked into it. Alex --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5737] Textrel in radeon_dri.so prevents useful modules for hardened systems
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=5737 --- Additional Comments From [EMAIL PROTECTED] 2006-01-27 05:33 --- radeon_dri.so isn't precompiled if you're building from source, not sure what you're talking about RE nda etc.. It's built during the Mesa build in src/mesa/drivers/dri/radeon/. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage IX/Thinkpad T20: Lockup with DMA
Am Donnerstag, den 26.01.2006, 12:06 -0500 schrieb Felix Kühling: Am Donnerstag, den 26.01.2006, 13:46 +0100 schrieb Michael Karcher: Hello DRI developers, on my ThinkPad T20, I experience Lockups with either type of DMA, be it Vertex DMA or AGP texture access. With Option DmaMode None and Option AGPMode 2 glxgears runs perfectly, as does glxinfo, whereas ppracer locks up the system at start (supposedly because of using AGP texturing). If I add Option BusType PCI, everything works as expected. Did you suspend/resume the notebook? There was a problem with AGP after resume that can be worked around by using BusType PCI. I suspected that the bug was actually in the VIA AGP driver, not in the Savage driver. I never got around to looking into it in detail though. Am Donnerstag, den 26.01.2006, 14:46 +0100 schrieb Michael Karcher: Hello developers, The red/blue stereo rendering of xmakemol doesn't work with savage hardware acceleration, but looks fine without (LIBGL_ALWAYS_INDIRECT=1). This is true for the current DRI snapshot as well as for an older snapshot from about August of last year. Do you need further information for debugging this problem? Screenshots are on http://www.physik.fu-berlin.de/~karcher/good.png (software rendered) and http://www.physik.fu-berlin.de/~karcher/bad.png (hardware rendered). No one has been working on the Savage 3D driver in a while. Your odds of getting someone to look into this problem are fairly low ATM. Sorry. Feel free to open a bug in the freedesktop.org bugzilla. Correcting myself. There have been updates to the Savage driver after I stopped working on it by Ian Romanick, Brian Paul and Eric Anholt and maybe others. Sorry folks, I appreciate your work! Is anyone going to look into this xmakemol issue? Regards, Felix Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage IX/Thinkpad T20: Lockup with DMA
Felix Kühling wrote: Am Donnerstag, den 26.01.2006, 12:06 -0500 schrieb Felix Kühling: Am Donnerstag, den 26.01.2006, 13:46 +0100 schrieb Michael Karcher: Hello DRI developers, on my ThinkPad T20, I experience Lockups with either type of DMA, be it Vertex DMA or AGP texture access. With Option DmaMode None and Option AGPMode 2 glxgears runs perfectly, as does glxinfo, whereas ppracer locks up the system at start (supposedly because of using AGP texturing). If I add Option BusType PCI, everything works as expected. Did you suspend/resume the notebook? There was a problem with AGP after resume that can be worked around by using BusType PCI. I suspected that the bug was actually in the VIA AGP driver, not in the Savage driver. I never got around to looking into it in detail though. Am Donnerstag, den 26.01.2006, 14:46 +0100 schrieb Michael Karcher: Hello developers, The red/blue stereo rendering of xmakemol doesn't work with savage hardware acceleration, but looks fine without (LIBGL_ALWAYS_INDIRECT=1). This is true for the current DRI snapshot as well as for an older snapshot from about August of last year. Do you need further information for debugging this problem? Screenshots are on http://www.physik.fu-berlin.de/~karcher/good.png (software rendered) and http://www.physik.fu-berlin.de/~karcher/bad.png (hardware rendered). No one has been working on the Savage 3D driver in a while. Your odds of getting someone to look into this problem are fairly low ATM. Sorry. Feel free to open a bug in the freedesktop.org bugzilla. Correcting myself. There have been updates to the Savage driver after I stopped working on it by Ian Romanick, Brian Paul and Eric Anholt and maybe others. Sorry folks, I appreciate your work! Is anyone going to look into this xmakemol issue? I took a quick look at xmakemol. The first thing I'd check is if the driver code for glColorMask is operating properly. For red/blue stereo, the scene is rendered twice, first with glColorMask(T,F,F,T), then glColorMask(F,F,T,T). I don't have a Savage card to test anything myself. Looks like the driver's ColorMask code depends on the card model. Which card are you using? BTW, the author of xmakemol needs to be taught how to use function prototypes. Put them in a header file; don't repeat the prototype inside each and every function it's used in! -Brian --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage IX/Thinkpad T20: Lockup with DMA
Am Donnerstag, den 26.01.2006, 12:06 -0500 schrieb Felix Kühling: on my ThinkPad T20, I experience Lockups with either type of DMA, be it Vertex DMA or AGP texture access. With Option DmaMode None and Option AGPMode 2 glxgears runs perfectly, as does glxinfo, whereas ppracer locks up the system at start (supposedly because of using AGP texturing). If I add Option BusType PCI, everything works as expected. Did you suspend/resume the notebook? There was a problem with AGP after resume that can be worked around by using BusType PCI. I suspected that the bug was actually in the VIA AGP driver, not in the Savage driver. I never got around to looking into it in detail though. I know about these problems. The driver from mid of last year had these problems: With AGPMode 1, I had serious problems, with AGPMode 2, everything worked fine until the first suspend, with BusType PCI, everything worked fine. The current snapshot crashes on BusType PCI without DmaMode None. It surely is not a VIA AGP problem, my chipset is a i440BX. But the agpgart backend drivers are all quite like to each other, so i would expect common bugs. Michael Karcher --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage IX/Thinkpad T20: Lockup with DMA
Am Donnerstag, den 26.01.2006, 14:05 -0700 schrieb Brian Paul: I don't have a Savage card to test anything myself. Looks like the driver's ColorMask code depends on the card model. Which card are you using? As the subject says, it is a Savage IX built into a Thinkpad T20. I probably should add that I am using 16bpp, which makes bitmask errors possible. Michael Karcher PS: Brian, sorry for the private copy. I didn't pay enough attention. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
offtopic: r200 lockups and context switches
Hello All,Sorry for possible offtopic, but I have a question related to Radeon 9250 card lockups. I am doing an experimental research project on graphics engine resource management based on the r200 driver. I have modified the drm implementation so that all the commands sent to the ring on behalf of a process are being queued in the kernel (xxx_RING macros redefinition), and when a user-level process emits state it marks it in the command buffer so that DRM side can distinguish it from other commands. Then, I have a kernel thread which takes commands from client queues and dispatches them to the GPU. When it detects a radeon_cp_cmdbuf coming from a different client than before, it emits the necessary state the corresponding client relies upon (just like in r200_dri.so does, but in kernel). I tried to optimize context switches by 'remembering' what has been sent last to the GPU for every hardware state 'atom' in the scheduler thread, and when it comes to context switch, sending only the atoms that actually differ. However, it resulted in quite frequent lockups (4 windows with an app drawing 1 spinning triangles lock it up after ten seconds) compared to the version which emits full state every time which is quite more robust. Which 'atoms' are necessary to emit every time even if exactly the same command sequence was emitted for this atom by the previous client? The lockups I am experiencing are real hardware lockups, because I debugged ring head tail position and it does not change. Is it possible to detect hardware lockup and reset hardware automatically, by the way? I've read that Longhorn display drivers for existing hardware are capable of something like that. Once again, sorry for offtopic.Thank you.Mikhail Bautin
Re: offtopic: r200 lockups and context switches
On 1/26/06, Michael Bautin [EMAIL PROTECTED] wrote: Hello All, Sorry for possible offtopic, but I have a question related to Radeon 9250 card lockups. I am doing an experimental research project on graphics engine resource management based on the r200 driver. I have modified the drm implementation so that all the commands sent to the ring on behalf of a process are being queued in the kernel (xxx_RING macros redefinition), and when a user-level process emits state it marks it in the command buffer so that DRM side can distinguish it from other commands. Then, I have a kernel thread which takes commands from client queues and dispatches them to the GPU. When it detects a radeon_cp_cmdbuf coming from a different client than before, it emits the necessary state the corresponding client relies upon (just like in r200_dri.so does, but in kernel). I tried to optimize context switches by 'remembering' what has been sent last to the GPU for every hardware state 'atom' in the scheduler thread, and when it comes to context switch, sending only the atoms that actually differ. However, it resulted in quite frequent lockups (4 windows with an app drawing 1 spinning triangles lock it up after ten seconds) compared to the version which emits full state every time which is quite more robust. Which 'atoms' are necessary to emit every time even if exactly the same command sequence was emitted for this atom by the previous client? this sounds like the state atom ordering bug. Apparently radeon hardware is particular about the ordering of atoms in some cases. Unfortunately there doesn't seem to be a general rule for what this is. Alex The lockups I am experiencing are real hardware lockups, because I debugged ring head tail position and it does not change. Is it possible to detect hardware lockup and reset hardware automatically, by the way? I've read that Longhorn display drivers for existing hardware are capable of something like that. Once again, sorry for offtopic. Thank you. Mikhail Bautin --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage IX/Thinkpad T20: Lockup with DMA
Am Donnerstag, den 26.01.2006, 14:05 -0700 schrieb Brian Paul: Felix Kühling wrote: Am Donnerstag, den 26.01.2006, 12:06 -0500 schrieb Felix Kühling: Am Donnerstag, den 26.01.2006, 13:46 +0100 schrieb Michael Karcher: Hello DRI developers, on my ThinkPad T20, I experience Lockups with either type of DMA, be it Vertex DMA or AGP texture access. With Option DmaMode None and Option AGPMode 2 glxgears runs perfectly, as does glxinfo, whereas ppracer locks up the system at start (supposedly because of using AGP texturing). If I add Option BusType PCI, everything works as expected. Did you suspend/resume the notebook? There was a problem with AGP after resume that can be worked around by using BusType PCI. I suspected that the bug was actually in the VIA AGP driver, not in the Savage driver. I never got around to looking into it in detail though. Am Donnerstag, den 26.01.2006, 14:46 +0100 schrieb Michael Karcher: Hello developers, The red/blue stereo rendering of xmakemol doesn't work with savage hardware acceleration, but looks fine without (LIBGL_ALWAYS_INDIRECT=1). This is true for the current DRI snapshot as well as for an older snapshot from about August of last year. Do you need further information for debugging this problem? Screenshots are on http://www.physik.fu-berlin.de/~karcher/good.png (software rendered) and http://www.physik.fu-berlin.de/~karcher/bad.png (hardware rendered). No one has been working on the Savage 3D driver in a while. Your odds of getting someone to look into this problem are fairly low ATM. Sorry. Feel free to open a bug in the freedesktop.org bugzilla. Correcting myself. There have been updates to the Savage driver after I stopped working on it by Ian Romanick, Brian Paul and Eric Anholt and maybe others. Sorry folks, I appreciate your work! Is anyone going to look into this xmakemol issue? I took a quick look at xmakemol. The first thing I'd check is if the driver code for glColorMask is operating properly. For red/blue stereo, the scene is rendered twice, first with glColorMask(T,F,F,T), then glColorMask(F,F,T,T). I took a brief look to refresh my memory. The difference between Savage3D-based and Savage4-based cards is that Savage4 can disable all drawing in the case glColorMask(F,F,F,F). Maybe useful if you want to render only to the Z-buffer. But I'm not even sure that would work correctly. In all other cases that are not glColorMask(T,T,T,T) the driver will fallback to software. The code looks correct to me but I don't think I ever tested it thoroughly. I don't have a Savage card to test anything myself. Me neither. Looks like the driver's ColorMask code depends on the card model. Which card are you using? Micheal is using a Savage3D-based card. Regards, Felix BTW, the author of xmakemol needs to be taught how to use function prototypes. Put them in a header file; don't repeat the prototype inside each and every function it's used in! -Brian -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes
On Thu, 2006-01-26 at 10:43 +1100, Benjamin Herrenschmidt wrote: Xorg driver patch: http://gate.crashing.org/~benh/radeon-memmap-7.0-2.diff DRM patch: http://gate.crashing.org/~benh/radeon-memmap-drm-1.diff The DRM patch had issues. Here's a new version that fixes them though it would be useful to test it with earlier userland DRI (for the DRM patch to have any effect, though, it must be run with a patches X driver as well). A reminder too: If you experience X segfaults with the patch, please try a server rebuilt with the fix for backtraces I mentioned in a previous email. AFAIK, Gentoo latest has it, other distros still have to catch up. Thanks ! http://gate.crashing.org/~benh/radeon-memmap-drm-3.diff Ben. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: offtopic: r200 lockups and context switches
Michael Bautin wrote: The lockups I am experiencing are real hardware lockups, because I debugged ring head tail position and it does not change. Is it possible to detect hardware lockup and reset hardware automatically, by the way? I've read that Longhorn display drivers for existing hardware are capable of something like that. Yes, this is possible. Catalyst driver does that since some time. As you've noted, if the ring doesn't advance the chip has locked up. You can then reset it, though you will lose pretty much all state (?). This would actually be a nice thing to have. There once was a similar patch floating around, though it wasn't actually for that problem, instead intended to kill apps which never release the lock (and it just happens that the lock is often held when the chip has locked up and the app is waiting for buffers). Roland --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Announce] DRIconf 0.9.0 released
Hi DRI users, It is my pleasure to announce a new release of DRIconf, version 0.9.0 of the DRI configuration applet. The source and installation instructions can be found on the project homepage at http://dri.freedesktop.org/wiki/DriConf. Note that updated pre-packaged versions for Linux distributions are not available yet. This version introduces a completely redesigned user interface that is intended to be both simpler and more intuitive. If the old user interface resembled the GNOME configuration editor then the new one looks and feels much more like a configuration applet. Thus the big change in the version number. !!! WARNING !!! The new code changes the structure of your configuration file in order to be able to represent it in the simplified user interface. In general that should not change the effect of the configuration file. But that code has not been widely tested yet. So if you can't afford to loose your settings please make a backup copy of your configuration file first (~/.drirc). Please report any problems you find on one of these mailing lists. Include a copy of the original configuration file in the report so that I can reproduce and investigate the problem. Unfortunately the amount of changes in the user interface means that the translations (except the German one) aren't up-to-date. I hope I will be able wrap up another release in a few weeks with updated translations. I wouldn't mind adding a few new ones at the same time. If you'd like to translate DRIconf to your language, just follow the instructions at the top of the Makefile that is included in the source tarball. Distribution packagers may want to take a look at this release. But I suggest to wait for the next version that will include updated translations (unless I have to make a bug-fix release sooner than that). Best regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
