Re: 3D not working after software suspend/resume
Bill Gou wrote: after a software suspend/resume cycle, running glxgears emits the following error msgs and quits: libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x23 libGL warning: 3D driver claims to not support visual 0x26 libGL warning: 3D driver claims to not support visual 0x27 intelWaitIrq: drmI830IrqWait: -16 The kernel also logged the following message: [drm:i915_wait_irq] *ERROR* i915_wait_irq: EBUSY -- rec: 972815 emitted: 972834 I'm running Xorg 6.8.1 with i915-20041008 snapshot. My video card is an Intel 855GM, below is the lspci -v output I'll add a Me too here. I830 CGC, Panasonic Toughbook R1. I don't get the libGL warnings; when I run glxgears, I see the first frame and then it stalls; after about 2-3s, the window closes and it says: intelWaitIrq: drmI830IrqWait: -16 Nonetheless, a definite improvement with i915 driver from before (suspend and resume with i830 DRI would suspend fine, but resume would lead to a hung machine after X restarted). David Bronaugh --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [rfc] VIA dri and security.
Thomas Hellström wrote: Hi! Sorry for the double posting. This is a thing that needs to be discussed in both communities. The via DRM has started it's journey into the linus kernel, but the 3D driver / DDX still suffers from a security flaw: When the MMIO area is exported read-write it is assumed possible for a dri client to manipulate registers to blit otherwise protected areas of the system memory to video memory. It is the DDX that tells the DRM whether to export the MMIO area read-only or read-write. The OpenGL 3D driver unichrome_dri.so currently needs write access to this area, until someone fixes it up to use register writing ioctls now present in the via drm. The obvious fix is for the DDX to tell DRM to export the MMIO area as read-only. In this way a normal user would get a segfault when trying to run accelerated OpenGL, while it would work as root. This sort of thing has been discussed in the past, going all the way back to UtahGLX, which had a root-only direct rendering system of sorts. The trouble with doing this, and this was well established in UtahGLX, is that if you make a high-performance path available only to root, you get people running as root when they ordinarily wouldn't do so in order to access that performance path. Specifically, you're encouraging people to run binary-only games toys with full superuser permissions. This is actually worse than a DRM model with theoretical insecurities - under that model a program would have to be cleverly crafted to expose and exploit the insecurity. Under this run games as root model, all of a sudden games have to be cleverly crafted and audited to *avoid* exposing insecurities... Nobody has done a security audit on q3 that would allow you to feel comfortable running it as root, to my knowledge... Keith --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [rfc] VIA dri and security.
Hi, Keith! Thomas Hellström wrote: Hi! Sorry for the double posting. This is a thing that needs to be discussed in both communities. The via DRM has started it's journey into the linus kernel, but the 3D driver / DDX still suffers from a security flaw: When the MMIO area is exported read-write it is assumed possible for a dri client to manipulate registers to blit otherwise protected areas of the system memory to video memory. It is the DDX that tells the DRM whether to export the MMIO area read-only or read-write. The OpenGL 3D driver unichrome_dri.so currently needs write access to this area, until someone fixes it up to use register writing ioctls now present in the via drm. The obvious fix is for the DDX to tell DRM to export the MMIO area as read-only. In this way a normal user would get a segfault when trying to run accelerated OpenGL, while it would work as root. This sort of thing has been discussed in the past, going all the way back to UtahGLX, which had a root-only direct rendering system of sorts. The trouble with doing this, and this was well established in UtahGLX, is that if you make a high-performance path available only to root, you get people running as root when they ordinarily wouldn't do so in order to access that performance path. Specifically, you're encouraging people to run binary-only games toys with full superuser permissions. This is actually worse than a DRM model with theoretical insecurities - under that model a program would have to be cleverly crafted to expose and exploit the insecurity. Under this run games as root model, all of a sudden games have to be cleverly crafted and audited to *avoid* exposing insecurities... Nobody has done a security audit on q3 that would allow you to feel comfortable running it as root, to my knowledge... Keith Agreed. So what is your actual suggestion? Export read-write as default or, as proposed, export read-write when AllowInsecureDRI is enabled in the X server config? Regards Thomas. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [rfc] VIA dri and security.
Thomas Hellström wrote: Hi, Keith! Thomas Hellström wrote: Hi! Sorry for the double posting. This is a thing that needs to be discussed in both communities. The via DRM has started it's journey into the linus kernel, but the 3D driver / DDX still suffers from a security flaw: When the MMIO area is exported read-write it is assumed possible for a dri client to manipulate registers to blit otherwise protected areas of the system memory to video memory. It is the DDX that tells the DRM whether to export the MMIO area read-only or read-write. The OpenGL 3D driver unichrome_dri.so currently needs write access to this area, until someone fixes it up to use register writing ioctls now present in the via drm. The obvious fix is for the DDX to tell DRM to export the MMIO area as read-only. In this way a normal user would get a segfault when trying to run accelerated OpenGL, while it would work as root. This sort of thing has been discussed in the past, going all the way back to UtahGLX, which had a root-only direct rendering system of sorts. The trouble with doing this, and this was well established in UtahGLX, is that if you make a high-performance path available only to root, you get people running as root when they ordinarily wouldn't do so in order to access that performance path. Specifically, you're encouraging people to run binary-only games toys with full superuser permissions. This is actually worse than a DRM model with theoretical insecurities - under that model a program would have to be cleverly crafted to expose and exploit the insecurity. Under this run games as root model, all of a sudden games have to be cleverly crafted and audited to *avoid* exposing insecurities... Nobody has done a security audit on q3 that would allow you to feel comfortable running it as root, to my knowledge... Keith Agreed. So what is your actual suggestion? Export read-write as default or, as proposed, export read-write when AllowInsecureDRI is enabled in the X server config? To tell the truth, I wasn't making one. If I were to though, it would follow on from the above fairly directly: - Don't allow any situation where root clients have better access to hardware than non-root clients. So, to my mind that would mean 1) Don't export insecure registers read-write, and 2) Don't distribute anything until there exists a working non-root 3d driver. That way there would be no incentive to run insecure programs as root. It's clear that this circumstance wasn't considered by the original DRM designers, or there would be a way to create mappings that are private to the X server, so that not even root clients would be able to use them. Note that this isn't about restricting the ability of root processes to damage the system, but rather about removing an incentive to run insecure programs as root. Keith --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Code status (Was: New DRM driver model - gets rid of DRM() macros!)
On Wed, Oct 06, 2004 at 05:51:41PM -0400, Jon Smirl wrote: For debug info: insmod ./drm.ko drm_opts=debug:on insmod ./radeon.ko drm_opts=debug:on I haven't fully writen the code for the new parameters yet. When it is finished the message will disappear. Make sure you don't have any old DRM drivers loaded by accident or compiled into your kernel. If you do the symbols will be all messed up and who know where the code will jump. Sometimes the drm/radeon pair will still load even if an old version is in memory. Try a sequence like this: [EMAIL PROTECTED] linux-core]# insmod ./drm.ko drm_opts=debug:on [EMAIL PROTECTED] linux-core]# insmod ./radeon.ko drm_opts=debug:on [EMAIL PROTECTED] linux-core]# rmmod radeon [EMAIL PROTECTED] linux-core]# insmod ./radeon.ko drm_opts=debug:on [EMAIL PROTECTED] linux-core]# rmmod radeon [EMAIL PROTECTED] linux-core]# insmod ./radeon.ko drm_opts=debug:on [EMAIL PROTECTED] linux-core]# rmmod radeon [EMAIL PROTECTED] linux-core]# insmod ./radeon.ko drm_opts=debug:on [EMAIL PROTECTED] linux-core]# rmmod radeon [EMAIL PROTECTED] linux-core]# insmod ./radeon.ko drm_opts=debug:on [EMAIL PROTECTED] linux-core]# rmmod radeon [EMAIL PROTECTED] linux-core]# rmmod drm [EMAIL PROTECTED] linux-core]# This runs for me without errors. This still fails on me. I've checked on another machine, with the same kernel but different hardware and kernel configuration, and it does works fint. I don't suppose any processor-specific assembly was added to the *-core, so I'm inclined towards any conflict with this machine kernel's configuration. FYI it's an AMD K6. I'll try to backtrack in the *-core to determine when the problem happened. Any other hints to hunt this bug down? José Fonseca --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 Projective texturing and texgen
On Sun, 10 Oct 2004 23:27:38 +0200, Dieter Nützel [EMAIL PROTECTED] wrote: ì GREAT progress. DOOM3 is working with TCL, little to dark, but...;-) Celestia 'Earth'-'ISS' have light in the windows, now. But some flickering on the sun paddels left. Quake3 quake3.x86 and quake3-smp-x86 do NOT exit clean anylonger. Not with Quit menu or typing in the console. UT2003 Some broken textures on the walls and floors (Temple of Anubis). 'shock rifle' is OK 'Exit' dito. progs/demos fcntl: Invalid argument fcntl: Invalid argument Backtrace: [ 1] ./Core.so [0x40a0978a] [ 2] [0xe420] Signal: SIGSEGV [segmentation fault] Aborting. [1]Speicherschutzverletzung ut2003_demo UT2004 Working. I've seen no corrupted textures. 'shock rifle' is OK 'Exit' dito. progs/demos ut2004demo [1] 18163 progs/demos Signal: SIGSEGV [segmentation fault] Aborting. Crash information will be saved to your logfile. [1]Exitcode 1ut2004demo Developer Backtrace: Log: [ 1] ./ut2004-bin [0x869e38c] Log: [ 2] [0xe420] Log: Unreal Call Stack: USDLClient::Destroy - UObject::ConditionalDestroy - DispatchDestroy - DispatchDestroys - UObject::PurgeGarbage - UObject::StaticExit - appPreExit Exit: Exiting. Log: FileManager: Reading 0 GByte 0 MByte 0 KByte 0 Bytes from HD took 0.00 seconds (0.00 reading, 0.00 seeking). Log: FileManager: 0.00 seconds spent with misc. duties Uninitialized: Name subsystem shut down Uninitialized: Allocation checking disabled Uninitialized: Log file closed, Sun Oct 10 23:22:43 2004 Good night! -Dieter --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel You mean Shock Rifle is ok without dbg = 0x6; or you mean with it? Bye --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 3D not working after software suspend/resume
On Mon, 11 Oct 2004 11:44:52 +0800, Bill Gou [EMAIL PROTECTED] wrote: after a software suspend/resume cycle, running glxgears emits the following error msgs and quits: With the semi-exception of the radeon driver, none of the 3d drivers support suspend/resume. Alex libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x23 libGL warning: 3D driver claims to not support visual 0x26 libGL warning: 3D driver claims to not support visual 0x27 intelWaitIrq: drmI830IrqWait: -16 The kernel also logged the following message: [drm:i915_wait_irq] *ERROR* i915_wait_irq: EBUSY -- rec: 972815 emitted: 972834 I'm running Xorg 6.8.1 with i915-20041008 snapshot. My video card is an Intel 855GM, below is the lspci -v output # lspci -v 00:00.0 Host bridge: Intel Corp. 82852/855GM Host Bridge (rev 02) Flags: bus master, fast devsel, latency 0 Memory at unassigned (32-bit, prefetchable) Capabilities: [40] #09 [a105] 00:00.1 System peripheral: Intel Corp. 855GM/GME GMCH Memory I/O Control Registers (rev 02) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, fast devsel, latency 0 00:00.3 System peripheral: Intel Corp. 855GM/GME GMCH Configuration Process Registers (rev 02) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, fast devsel, latency 0 00:02.0 VGA compatible controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) (prog-if 00 [VGA]) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, fast devsel, latency 0, IRQ 10 Memory at b000 (32-bit, prefetchable) [size=128M] Memory at f000 (32-bit, non-prefetchable) [size=512K] I/O ports at e000 [size=8] Capabilities: [d0] Power Management version 1 00:02.1 Display controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: fast devsel Memory at 2000 (32-bit, prefetchable) [disabled] [size=128M] Memory at 1e00 (32-bit, non-prefetchable) [disabled] [size=512K] Capabilities: [d0] Power Management version 1 00:1d.0 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #1 (rev 03) (prog-if 00 [UHCI]) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, medium devsel, latency 0, IRQ 10 I/O ports at 1200 [size=32] 00:1d.2 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #3 (rev 03) (prog-if 00 [UHCI]) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at 1700 [size=32] 00:1d.7 USB Controller: Intel Corp. 82801DB (ICH4) USB2 EHCI Controller (rev 03) (prog-if 20 [EHCI]) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, medium devsel, latency 0, IRQ 11 Memory at f008 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] #0a [2080] 00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 83) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 I/O behind bridge: c000-dfff Memory behind bridge: e000-efff Prefetchable memory behind bridge: a000-afff 00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 03) Flags: bus master, medium devsel, latency 0 00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage Controller (rev 03) (prog-if 8a [Master SecP PriP]) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at unassigned I/O ports at unassigned I/O ports at unassigned I/O ports at unassigned I/O ports at 1100 [size=16] Memory at 1e08 (32-bit, non-prefetchable) [size=1K] 00:1f.3 SMBus: Intel Corp. 82801DB/DBM (ICH4) SMBus Controller (rev 03) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: medium devsel, IRQ 6 I/O ports at 1400 [size=32] 00:1f.5 Multimedia audio controller: Intel Corp. 82801DB (ICH4) AC'97 Audio Controller (rev 03) Subsystem: Toshiba America Info Systems: Unknown device ff10 Flags: bus master, medium devsel, latency 0, IRQ 6 I/O ports at e100 [size=256] I/O ports at e200 [size=64] Memory at f0080400 (32-bit, non-prefetchable) [size=512] Memory at f0080600 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 00:1f.6 Modem: Intel
Re: [rfc] VIA dri and security.
On Llu, 2004-10-11 at 09:42, Thomas Hellstrm wrote: So what is your actual suggestion? Export read-write as default or, as proposed, export read-write when AllowInsecureDRI is enabled in the X server config? AllowInsecureDRI is less secure than forcing users to run things as root or fix the code. And we want that code in kernel and causing pain in order to make people fix it 8) If I setuid an app then it depends if that one app is trojanned. If I have AllowInsecureDRI then any trojanned or hostile app gets you. What I think you do want to avoid would be something like DRI is faster as root, which sends all the wrong signals. Alan --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Code status (Was: New DRM driver model - gets rid of DRM() macros!)
On Mon, 11 Oct 2004 11:56:27 +0100, José Fonseca [EMAIL PROTECTED] wrote: I've checked on another machine, with the same kernel but different hardware and kernel configuration, and it does works fint. I don't suppose any processor-specific assembly was added to the *-core, so I'm inclined towards any conflict with this machine kernel's configuration. FYI it's an AMD K6. I'll try to backtrack in the *-core to determine when the problem happened. Any other hints to hunt this bug down? What does dmesg say? There should be some debugging data in the log. drm loads right? which personality is failing? -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Weekly IRC meeting reminder
This is just a friendly reminder that the weekly dri-devel IRC meeting will be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or 5:00PM EDT or 2:00PM PDT, if you prefer). Time zone conversion available at: http://www.timezoneconverter.com/cgi-bin/tzc.tzc Logs of previous IRC meetings are available at: http://dri.sourceforge.net/IRC-logs/ --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Building the DRI: shader/arbprogparse.c:3630: stray '\240' in program
Hi, I've got an error while building the DRI. It happens when I want to build the Mesa 3D drivers for Linux (I'm following this page: http://dri.sourceforge.net/cgi-bin/moin.cgi/Building). [EMAIL PROTECTED]:~/Downloads/DRI/Mesa$ make linux-dri-x86 snip gcc -c -I../../include -I../../src/mesa -I../../src/mesa/main -I../../src/mesa/glapi -I../../src/mesa/mat h -I../../src/mesa/tnl -I../../src/mesa/shader -I../../src/mesa/swrast -I../../src/mesa/swrast_setup -DDR I_NEW_INTERFACE_ONLY -Wall -g -O -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -std=c99 -ffa st-math -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS - DUSE_EXTERNAL_DXTN_LIB=1 -I/usr/X11R6/include -I/usr/X11R6/include/X11/extensions shader/arbprogparse.c - o shader/arbprogparse.o shader/arbprogparse.c: In function `parse_arb_program': shader/arbprogparse.c:3630: stray '\240' in program shader/arbprogparse.c:3630: stray '\240' in program shader/arbprogparse.c:3630: stray '\240' in program shader/arbprogparse.c:3630: stray '\240' in program shader/arbprogparse.c:3630: stray '\240' in program shader/arbprogparse.c:3630: stray '\240' in program shader/arbprogparse.c:3630: stray '\240' in program shader/arbprogparse.c:3630: stray '\240' in program shader/arbprogparse.c:3630: stray '\240' in program shader/arbprogparse.c:3630: stray '\240' in program shader/arbprogparse.c:3630: stray '\240' in program shader/arbprogparse.c:3630: stray '\240' in program shader/arbprogparse.c:3630: stray '\240' in program make[4]: *** [shader/arbprogparse.o] Error 1 make[4]: Leaving directory `/home/steven/Downloads/DRI/Mesa/src/mesa' make[3]: *** [default] Error 2 make[3]: Leaving directory `/home/steven/Downloads/DRI/Mesa/src/mesa' make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/home/steven/Downloads/DRI/Mesa/src' make[1]: *** [default] Error 1 make[1]: Leaving directory `/home/steven/Downloads/DRI/Mesa' make: *** [linux-dri-x86] Error 2 My system: Pentium 4 2.4 GHZ, ATI Radeon 9200, 512 MB RAM on Slackware 9.0, I'm using the 2.6.2 kernel and XFree86 4.3. Any ideas what I should try? I've already googled on the stray '\240' error: \240 is (presumably) a character invisible in your favorite editor (mine is emacs FYI) and tried to retype line 3630 but no positive result :-(. Everything is from CVS... Thanks, Steven Btw, shaders/arbprogram_syn.h needs a blank line at the end (gives a warning during compile time) --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Building the DRI: shader/arbprogparse.c:3630: stray '\240' in program
shader/arbprogparse.c:3630: stray '\240' in program I think this stems from the line #define ARB_DRAW_BUFFERS ï0x80 around line 175-ish. It looks like, at least in the CVS browsing, that there is a bunch of odd crap between the end of ..._BUFFERS and 0x80. Karl --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] sis: use unsigned 1-bit fields
Hi,
1-bit fields should be unsigned (i.e., no sign bit).
Sparse also complains about them, as in:
drivers/char/drm/sis_ds.h:88:12: warning: dubious one-bit signed bitfield
drivers/char/drm/sis_ds.h:89:16: warning: dubious one-bit signed bitfield
Is current linux-2.6.9-bk tree anything close to DRM CVS?
Maybe this has already been fixed...
Thanks,
--
~Randy
Make 1-bit fields be unsigned (no sign bit :).
sparse complains about them:
drivers/char/drm/sis_ds.h:88:12: warning: dubious one-bit signed bitfield
drivers/char/drm/sis_ds.h:89:16: warning: dubious one-bit signed bitfield
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
diffstat:=
drivers/char/drm/sis_ds.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -Naurp ./drivers/char/drm/sis_ds.h~sis_bits ./drivers/char/drm/sis_ds.h
--- ./drivers/char/drm/sis_ds.h~sis_bits 2004-08-13 22:36:57.0 -0700
+++ ./drivers/char/drm/sis_ds.h 2004-10-11 07:59:31.861263400 -0700
@@ -85,8 +85,8 @@ struct mem_block_t {
struct mem_block_t *heap;
int ofs,size;
int align;
- int free:1;
- int reserved:1;
+ unsigned int free:1;
+ unsigned int reserved:1;
};
typedef struct mem_block_t TMemBlock;
typedef struct mem_block_t *PMemBlock;
Re: kern/60474: Temporary fix for DRM support for Radeon 9200
On Fri, 8 Oct 2004, Eric Anholt wrote: On Fri, 2004-10-08 at 11:17, Mikhail Teterin wrote: Hi, Eric! Can this be assigned back to you? I have another pair of PCI IDs, BTW, and I am sure, there are people with shiny new Radeon-9800 out there too... Yours, This is not a bug. The DRM does not support r300-series hardware. Among other things, trying to initialize it with r100 or r200 microcode will probably make it explode in your face. Now, if this was part of an attempt at getting http://r300.sf.net/ stuff working on FreeBSD, that'd be another thing :) http://r300.sf.net/ already works on BSD. You just need to pass an option to r300_demo to find the BSD analog of /dev/dri/card0 (see README). Ok, I rebuilt my xorg-server port with the ati.patch.3. Now, when it starts up, it automatically loads the radeon.ko and then says: [...] (WW) RADEON(0): Direct rendering support is highly experimental for Radeon 9500/ 9700 and newer cards drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: Open failed drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: Open failed drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 13, (OK) drmGetBusid returned '' (II) RADEON(0): [drm] loaded kernel module for radeon driver (II) RADEON(0): [drm] created radeon driver at busid PCI:1:0:0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc6ba6000 (II) RADEON(0): [drm] mapped SAREA 0xc6ba6000 to 0x28492000 (II) RADEON(0): [drm] framebuffer handle = 0xe000 (II) RADEON(0): [drm] added 1 reserved context for kernel (EE) RADEON(0): [dri] RADEONDRIScreenInit failed because of a version mismatch. [dri] radeon.o kernel module version is 1.11.0 but version 1.11.1 or newer is needed. [dri] Disabling DRI. [...] Is there a patch for FreeBSD's /sys/dev/drm somewhere? Thanks! -mi --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1220] Garbage screen after resume from suspend to disk
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://freedesktop.org/bugzilla/show_bug.cgi?id=1220 --- Additional Comments From [EMAIL PROTECTED] 2004-10-11 13:05 --- *** Bug 1591 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://freedesktop.org/bugzilla/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: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 Projective texturing and texgen
Am Montag, 11. Oktober 2004 14:36 schrieb Marcello Maggioni: On Sun, 10 Oct 2004 23:27:38 +0200, Dieter Nützel [EMAIL PROTECTED] wrote: UT2003 Some broken textures on the walls and floors (Temple of Anubis). 'shock rifle' is OK 'Exit' dito. - Exit IS broken. UT2004 Working. I've seen no corrupted textures. 'shock rifle' is OK 'Exit' dito. - Exit IS broken. [MUCH TOFU deleted] !!! You mean Shock Rifle is ok without dbg = 0x6; or you mean with it? dbg = 0x06; (!!!) is standard (and _included_ in r200-projtex-6.diff);-))) -Dieter --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 Projective texturing and texgen
On Mon, 11 Oct 2004 22:12:25 +0200, Dieter Nützel [EMAIL PROTECTED] wrote: Am Montag, 11. Oktober 2004 14:36 schrieb Marcello Maggioni: On Sun, 10 Oct 2004 23:27:38 +0200, Dieter Nützel [EMAIL PROTECTED] wrote: UT2003 Some broken textures on the walls and floors (Temple of Anubis). 'shock rifle' is OK 'Exit' dito. - Exit IS broken. UT2004 Working. I've seen no corrupted textures. 'shock rifle' is OK 'Exit' dito. - Exit IS broken. [MUCH TOFU deleted] !!! You mean Shock Rifle is ok without dbg = 0x6; or you mean with it? dbg = 0x06; (!!!) is standard (and _included_ in r200-projtex-6.diff);-))) -Dieter Ah , ok , thanks :) --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1220] Garbage screen after resume from suspend to disk
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://freedesktop.org/bugzilla/show_bug.cgi?id=1220 --- Additional Comments From [EMAIL PROTECTED] 2004-10-11 13:39 --- can anyone of the developer confirm me, that this was patched in CVS, I don't want to leech the whole CVS tree because of one file. The web CVS has also a bug, so I can't watch it there. -- Configure bugmail: https://freedesktop.org/bugzilla/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: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1220] Garbage screen after resume from suspend to disk
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://freedesktop.org/bugzilla/show_bug.cgi?id=1220 --- Additional Comments From [EMAIL PROTECTED] 2004-10-11 14:04 --- The patch is still not commited to CVS. Therefore this bugreport is still open. -- Configure bugmail: https://freedesktop.org/bugzilla/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: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: Building the DRI: shader/arbprogparse.c:3630: stray '\240' in program
On Mon, 11 Oct 2004 14:54:07 -0400 (EDT) Karl Rasche [EMAIL PROTECTED] wrote: shader/arbprogparse.c:3630: stray '\240' in program I think this stems from the line #define ARB_DRAW_BUFFERS ï0x80 around line 175-ish. It looks like, at least in the CVS browsing, that there is a bunch of odd crap between the end of ..._BUFFERS and 0x80. I committed a fix. Hexdump showed a series of 20 a0 20 a0 ... between _BUFFERS and 0x80. 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: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
i915 DRM
Hey, I was poking through the code for i915 DRM, trying to find the source of the resume failure. It looks like the i915_resume function can't be called by anything -- am I wrong about this? If I'm right, how should it be enabled? Regardless, I have some doubts about the allocation made using pci_alloc_consistent in the init function surviving over a suspend. The impression I got from asking people was that a DMA mapping such as that would -not- survive a suspend cycle. Info / feedback welcome :) David Bronaugh --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Undefined symbols in recent DRM
On Sun, 10 Oct 2004 22:19:18 -0400
Adam Jackson [EMAIL PROTECTED] wrote:
On Sunday 10 October 2004 17:45, Felix Kühling wrote:
On Sun, 10 Oct 2004 22:01:30 +0200 David [EMAIL PROTECTED] wrote:
[snip]
They are forwards compatible but not backwards compatible. 4.4 modules
will work on 6.8, but 6.8 modules won't work on 4.4. So yes, we need
to build an Xorg server snapshot.
- ajax
I don't want to reinstall my whole box every year, so I must find a way
to test current snapshots on XFree86 or give up with testing.
The new snapshots instructions (Xorg binary, etc...) are giving me this:
Adam, can you comment this? How much besides the Xorg server binary is
needed in order to get this working? Is it realistic to make Xorg work
in a XFree86 installation with only a few binary replacements? How soon
is any such thing going to break again?
Looks like we also need libextmod and libxtt. And the unresolved symbols
in the savage driver module look like it requires some newer libxaa and
libfb modules than the XFree86 ones. Anything else? I guess we could add
any new xorg modules to the common snapshots.
The server binary and all of ${PROJECTROOT}/lib/modules should be sufficient.
Note that that's pretty much equivalent to upgrading to Xorg.
I've uploaded a Xorg-modules.tar.bz2 to the snapshots/extras dir. It
contains all (strip -g) modules except the ones included in the binary
snapshots (libGLcore.a, libglx.a, libdri.a, all 2D and 3D drivers).
David, could you give it a try? Proceed as follows:
uninstall common and card-specifc snapshots
cd /usr/X11R6/lib
mv modules modules.backup
tar -tjf ~/Xorg-modules.tar.bz2
reinstall common and card-specific snapshots
If this works I'll update the snapshot installation instructions and add
a README.Xorg in the extras dir.
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: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i915 DRM
I was poking through the code for i915 DRM, trying to find the source of the resume failure. It looks like the i915_resume function can't be called by anything -- am I wrong about this? If I'm right, how should it be enabled? I think Keith will have to answer this one .. there was a suspicious HAVE_PM define in the i915 headers that lead me to believe perhaps errantly that TG might have a modified framework for some of this stuff... or were starting one... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [rfc] VIA dri and security.
AllowInsecureDRI is less secure than forcing users to run things as root or fix the code. And we want that code in kernel and causing pain in order to make people fix it 8) I'm really with Keiths don't let them do anything until someone fixes it .. makes life easier.. I don't think having in the mainline will force people to fix it any quicker, anyone capable of fixing it is probably on this list, (and in the via case on the unichrome one ..).. I've just thought of another issue with the validation (and I haven't reviewed the via code throughly...) but for the mach64 the problem was that after the validation the buffers were still mapped into the user application so it could modify them after validation if it was sufficently sneaky enough... for the mach64 the idea was to allocate a pool of private buffers using pci interfaces and use those to pass command streams after verification.. the user app wouldn't be able to map these... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: kern/60474: Temporary fix for DRM support for Radeon 9200
(II) RADEON(0): [drm] added 1 reserved context for kernel (EE) RADEON(0): [dri] RADEONDRIScreenInit failed because of a version mismatch. [dri] radeon.o kernel module version is 1.11.0 but version 1.11.1 or newer is needed. [dri] Disabling DRI. [...] Is there a patch for FreeBSD's /sys/dev/drm somewhere? Thanks! You need the drm patch from r300.sf.net - just bump the patch level number to make it pass version check. Note that the patch applies to drm/shared and is thus propagated to BSD. Also, the newer Jon's work already has the patch applied, you might try adapting this to BSD. best Vladimir Dergachev -mi --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Building the DRI: drm/linux-2.6/radeon_i2c.c:41: `VGA_DDC_CLK_OUT_EN' undeclared
Hi, me again :) I've reached some further steps now (thanks Karl and Felix), but I've run into a new error (well, 4 actually). [EMAIL PROTECTED]:/home/steven/Downloads/DRI/drm/linux-2.6# make LINUXDIR=/usr/src/linux-2.6.2 DRM_MODULES=r200 radeon snip /home/steven/Downloads/DRI/drm/linux-2.6/radeon_i2c.c: In function `gpio_setscl': /home/steven/Downloads/DRI/drm/linux-2.6/radeon_i2c.c:41: `VGA_DDC_CLK_OUT_EN' undeclared (first use in this function) /home/steven/Downloads/DRI/drm/linux-2.6/radeon_i2c.c:41: (Each undeclared identifier is reported only once /home/steven/Downloads/DRI/drm/linux-2.6/radeon_i2c.c:41: for each function it appears in.) /home/steven/Downloads/DRI/drm/linux-2.6/radeon_i2c.c: In function `gpio_setsda': /home/steven/Downloads/DRI/drm/linux-2.6/radeon_i2c.c:55: `VGA_DDC_DATA_OUT_EN' undeclared (first use in this function) /home/steven/Downloads/DRI/drm/linux-2.6/radeon_i2c.c: In function `gpio_getscl': /home/steven/Downloads/DRI/drm/linux-2.6/radeon_i2c.c:71: `VGA_DDC_CLK_INPUT' undeclared (first use in this function) /home/steven/Downloads/DRI/drm/linux-2.6/radeon_i2c.c: In function `gpio_getsda': /home/steven/Downloads/DRI/drm/linux-2.6/radeon_i2c.c:82: `VGA_DDC_DATA_INPUT' undeclared (first use in this function) make[2]: *** [/home/steven/Downloads/DRI/drm/linux-2.6/radeon_i2c.o] Error 1 make[1]: *** [/home/steven/Downloads/DRI/drm/linux-2.6] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.2' make: *** [modules] Error 2 It's probably some header file or something like that which isn't used/found to declare variables. What are the adaptions I have to make? Thanks, Steven --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1220] Garbage screen after resume from suspend to disk
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://freedesktop.org/bugzilla/show_bug.cgi?id=1220 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-10-11 17:57 --- fixed now in CVS. CVSROOT:/cvs/xorg Module name:xc Changes by: [EMAIL PROTECTED] 04/10/11 16:20:26 Log message: - fix resume on radeons (bug 1220) [...] Modified files: [...] xc/programs/Xserver/hw/xfree86/drivers/ati/: radeon_driver.c [...] Revision Changes Path [...] 1.23+1 -0 xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c [...] -- Configure bugmail: https://freedesktop.org/bugzilla/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: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Building the DRI: drm/linux-2.6/radeon_i2c.c:41: `VGA_DDC_CLK_OUT_EN' undeclared
VGA_DDC_CLK_OUT_EN is defined in linux/include/video/radeon.h It should be part of the normal kernel build environment. -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Serious issues with Rage128 on PowerPC
I was trying to test the latest version of my ReadPixels work to make sure I didn't break anything on big-endian. However, it seems someone beat me to it in the Rage128 driver. :) In a nutshell, I can get one frame of gears, and then the 3D engine is toast. After that frame is drawn, gears is at 100% and X is unresponsive. When I kill gears, everything goes back to semi-normal. If I run another 3D program, I get an empty (just a frame!) window. Looking at the output from R128_DEBUG=all, it appears to be stuck in r128EmitHwStateLocked. That single frame of gears is also wrong. The colors are pinks and purples. I suspect this may just be a byte-ordering problem. I notice that the driver wants to use BGRA for primary color, but I suspect the hardware really wants ARGB. Ditto for secondary color / fog. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM - per head data structure
I just split out heads as a separate data structure from drm_device. I
gave this a couple of hours of testing in different configurations but
I may have missed something. Please let me know.
I probably haven't figured out all of the variables that need to be
moved from drm_device to drm_head. If anyone is interested check out
drmP.h and tell me other candidates to be moved. At least I have the
basic structure split out, moving individual variables is easy.
The three main structures:
drm_driver - one per class of cards
drm_device - one for each physical card
drm_head - one for each head on a card
Heads need to track:
minor number
proc entry - one per card or per head?
sysfs entry
For framebuffer merge they also need:
legal mode list
current mode
location of scanout buffer
size of buffer
Merging DRM and fbdev is much more complicated than I though it was.
Neither fbdev or current DRM data structures are set up for multi-head
support. Both drivers need significant rework to support multihead.
Take for example struct fb_info, half of these variable are needed for
each head and half need to be only one per card.
struct fb_info {
int node; -per card
int flags; -per card
struct fb_var_screeninfo var; -per head
struct fb_fix_screeninfo fix; -per card
struct fb_monspecs monspecs; -per head
struct fb_cursor cursor; -per head
struct work_struct queue; -per card
struct timer_list cursor_timer; -per card
struct fb_pixmap pixmap; -per card
struct fb_pixmap sprite; -per card
struct fb_cmap cmap; -per head
struct list_head modelist; -per head
struct fb_ops *fbops; -per card
char __iomem *screen_base; -per head
unsigned long screen_size; -per head
int currcon; -per head
void *pseudo_palette; -per head
u32 state; -per card
};
--
Jon Smirl
[EMAIL PROTECTED]
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1220] Garbage screen after resume from suspend to disk
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://freedesktop.org/bugzilla/show_bug.cgi?id=1220 --- Additional Comments From [EMAIL PROTECTED] 2004-10-11 21:17 --- This really ought to be applied to the stable/6.8 branch as well. I would have done it myself, but I'm not sure which branch it needs to go on. -- Configure bugmail: https://freedesktop.org/bugzilla/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: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Serious issues with Rage128 on PowerPC
On Mon, 2004-10-11 at 18:37 -0700, Ian Romanick wrote: I was trying to test the latest version of my ReadPixels work to make sure I didn't break anything on big-endian. However, it seems someone beat me to it in the Rage128 driver. :) In a nutshell, I can get one frame of gears, and then the 3D engine is toast. After that frame is drawn, gears is at 100% and X is unresponsive. When I kill gears, everything goes back to semi-normal. If I run another 3D program, I get an empty (just a frame!) window. Looking at the output from R128_DEBUG=all, it appears to be stuck in r128EmitHwStateLocked. Please provide a little more context - machine type (G4 I guess? Which model exactly?), AGP/PCI, versions of kernel/DRM/X, ... That single frame of gears is also wrong. The colors are pinks and purples. I suspect this may just be a byte-ordering problem. I notice that the driver wants to use BGRA for primary color, but I suspect the hardware really wants ARGB. Ditto for secondary color / fog. Yeah, there are endianness issues to work out in t_vertex. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 Projective texturing and texgen
On Mon, 2004-10-11 at 13:12, Dieter Nützel wrote: Am Montag, 11. Oktober 2004 14:36 schrieb Marcello Maggioni: On Sun, 10 Oct 2004 23:27:38 +0200, Dieter Nützel [EMAIL PROTECTED] wrote: UT2003 Some broken textures on the walls and floors (Temple of Anubis). 'shock rifle' is OK 'Exit' dito. - Exit IS broken. UT2004 Working. I've seen no corrupted textures. 'shock rifle' is OK 'Exit' dito. - Exit IS broken. [MUCH TOFU deleted] !!! You mean Shock Rifle is ok without dbg = 0x6; or you mean with it? dbg = 0x06; (!!!) is standard (and _included_ in r200-projtex-6.diff);-))) Those two exit errors (which also happen in quake3) are due to my broken hack to disable vtxformat. My next step with this is to figure out what exactly to do to vtxformat to make things happy again (and hopefully swtcl projtex, too). -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
