Re: what is the CVS tag of 2.6.15 in-kernel DRM?
> > Current cvs does not build as part of kernel. There are > major changes since in-kernel version. I want to > build in kernel space by kernel make together with other > drivers. Get current CVS, don't worry about the kernel, you don't want to bother > > 20050718 snapshot is close and builds after some small > fixes in mach64_drv.c but dma buffers fail to allocate. > > Perhaps someone has a snapshot date? Well consider I'm the drm maintainer for the Linux kernel, and I said no such things exists, I believe I'd listen to me... my merge process for DRM CVS to kernel, is simple stable patches go straight away, bigger ones stew in CVS until I'm happy they don't break anything too badly.. so there isn't a real direct parallel version of DRM CVS and the kernel also DRM CVS has proper PCI device support which we can't merge to the kernel for other reasons... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5142] Using FlightGear and Open Radeon Driver causes GLXUnsupportedPrivateRequest error in Xorg
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=5142 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|dri-|[EMAIL PROTECTED] |[EMAIL PROTECTED] | URL||http://mail.flightgear.org/p ||ipermail/flightgear- ||users/2005- ||November/012990.html Severity|normal |major Component|Drivers/DRI/r300|Driver/Radeon Priority|P2 |P1 Product|Mesa|xorg Summary|flightgear flightsimulator |Using FlightGear and Open |unusable with r300 and some |Radeon Driver causes |other radeon|GLXUnsupportedPrivateRequest ||error in Xorg Version|CVS |CVS_head --- Additional Comments From [EMAIL PROTECTED] 2005-11-27 14:31 --- This problem is plaguing quite a few ATI users. We launch FlightGear, and got a GLXUnsupportedPrivateRequest errors while FlightGear is still displaying the Splash Screen. Qutie a few developers have looked into this issue at FlightGear, and none is able to come up with a solution within FlightGear/SimGear. Some people think it is a driver problem. However, I have never got a crash like this when I was still using XFree (before I made a switch to Xorg). Therefore, I think this error is more Xorg related. Please see the attached gdb's output for more information. Here are some discussions on the Devel-List that may help: http://mail.flightgear.org/pipermail/flightgear-devel/2005-November/040030.html http://mail.flightgear.org/pipermail/flightgear-devel/2005-November/040855.html -- 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5142] flightgear flightsimulator unusable with r300 and some other radeon
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=5142 --- Additional Comments From [EMAIL PROTECTED] 2005-11-27 14:21 --- Created an attachment (id=3915) --> (https://bugs.freedesktop.org/attachment.cgi?id=3915&action=view) Outputs obtained from gdb -- 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: front/back buffer offsets in DRM
Am Samstag, den 26.11.2005, 10:47 -0700 schrieb Brian Paul: > Aapo Tahkola wrote: > > On Fri, 25 Nov 2005 16:16:48 -0700 > > Brian Paul <[EMAIL PROTECTED]> wrote: > > > > > >>I've been playing around with the EGL r200 driver. Digging through > >>the framebuffer allocation code I've found a few problems. > >> > >>In order to support pbuffers and framebuffer objects we need to be > >>able to work with color/depth/stencil buffers are various locations in > >>video memory. > >> > >>The current code sets the front/back/depth buffer offsets and pitches > >>once in the radeon_do_init_cp() function and there's no way to change > >>them thereafter. > >> > >>It looks like the only code that uses this information is the glClear > >>and SwapBuffers-related code in radeon_cp_dispatch_clear(), > >>radeon_cp_dispatch_swap() and radeon_cp_dispatch_flip(). And the code > >>that enables/disables color tiling. > >> > >>Could someone more familiar with the code comment on what it would > >>take to fix the code so that color/depth buffers at arbitrary > >>locations can be used? > >> > >>I'd probably do away with the front/back_offset/pitch fields entirely > >>and pass the offset/pitch values as parameters to the ioctls. I'd > >>also write the code so there's no distinction between front/back color > >>buffers. > > > > > > Whats the point of doing these operations in DRM anyway? > > Personally I would just pull out as much code from there as possible. > > I was wondering about that too. There may be some reason for doing > those things in the kernel, but I don't know of any. At least on some hardware buffer clearing and swapping is done by the 2D engine. Instead of exposing the necessary functionality through some generic blit or fill ioctls, specific clear and swap operations were implemented. The fact that the Xserver provides the offsets and pitches adds some sense of security by preventing untrusted clients from overwriting random memory. I believe it should be possible to replace clear and swap ioctls with generic blit and fill ioctls that do some range checking on their arguments. > > -Brian > 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://ads.osdn.com/?ad_idv37&alloc_id865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: what is the CVS tag of 2.6.15 in-kernel DRM?
charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sunday 27 November 2005 01:09, Dave Airlie wrote: > > I like to upgrade mach64 driver for inclusion in kernel > > and pull relevant version from cvs. > > There isn't one.. just fix the mach64 in CVS to be secure > and it will magically get merged to the kernel at some > point after that when I've had it reviewed to check it is > secure.. > > Dave. Current cvs does not build as part of kernel. There are major changes since in-kernel version. I want to build in kernel space by kernel make together with other drivers. 20050718 snapshot is close and builds after some small fixes in mach64_drv.c but dma buffers fail to allocate. Perhaps someone has a snapshot date? Michael --- 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Where to get a mach64 datasheet?
> I like to upgrade mach64 driver for inclusion in kernel and > desire a datasheet. You'll need to get ATI to give you it, off late ATI have been ignoring most requests from individual developers Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: what is the CVS tag of 2.6.15 in-kernel DRM?
> I like to upgrade mach64 driver for inclusion in kernel and > pull relevant version from cvs. There isn't one.. just fix the mach64 in CVS to be secure and it will magically get merged to the kernel at some point after that when I've had it reviewed to check it is secure.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Mach64 still not in kernel tree
On Wednesday 23 November 2005 18:32, Alan Cox wrote: > On Mer, 2005-11-23 at 11:46 -0500, Adam Jackson wrote: > > On Wednesday 23 November 2005 07:48, Michael Frank wrote: > > > Testing 2.6.15-rc2 in-kernel DRM, why still no > > > mach64 support which works fine for me from > > > snapshots/cvs? > > > > Because it's still insecure. > > Michael - If you've got a Mach64 and you want it > mainstream you need to add code which validates the > command stream passed to the chip is valid. There is code > like this in the VIA driver and the Mach64 needs > something similar to verify you aren't doing things like > DMAing patches into the kernel with the graphics card but > only using commands that are "safe". > Thank you Alan, I had a look at the via driver and will work on the mach64 driver. Michael --- 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Where to get a mach64 datasheet?
I like to upgrade mach64 driver for inclusion in kernel and desire a datasheet. Thanks Michael --- 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
what is the CVS tag of 2.6.15 in-kernel DRM?
I like to upgrade mach64 driver for inclusion in kernel and pull relevant version from cvs. Thanks Michael --- 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: front/back buffer offsets in DRM
Aapo Tahkola wrote: On Fri, 25 Nov 2005 16:16:48 -0700 Brian Paul <[EMAIL PROTECTED]> wrote: I've been playing around with the EGL r200 driver. Digging through the framebuffer allocation code I've found a few problems. In order to support pbuffers and framebuffer objects we need to be able to work with color/depth/stencil buffers are various locations in video memory. The current code sets the front/back/depth buffer offsets and pitches once in the radeon_do_init_cp() function and there's no way to change them thereafter. It looks like the only code that uses this information is the glClear and SwapBuffers-related code in radeon_cp_dispatch_clear(), radeon_cp_dispatch_swap() and radeon_cp_dispatch_flip(). And the code that enables/disables color tiling. Could someone more familiar with the code comment on what it would take to fix the code so that color/depth buffers at arbitrary locations can be used? I'd probably do away with the front/back_offset/pitch fields entirely and pass the offset/pitch values as parameters to the ioctls. I'd also write the code so there's no distinction between front/back color buffers. Whats the point of doing these operations in DRM anyway? Personally I would just pull out as much code from there as possible. I was wondering about that too. There may be some reason for doing those things in the kernel, but I don't know of any. -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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5172] New: Pointer paints the screen in 2d
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=5172 Summary: Pointer paints the screen in 2d Product: DRI Version: XOrg CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DRM modules AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] The Pointer paints the screen when i use it, glxgears works ok, glxinfo report directrendering: yes. I used driconf to change some configuration, but i do not find someone better. I edit too xorg.con and try add and/or modify some savage drive option without good end. Only error i get is: Nov 26 15:16:07 localhost kernel: mtrr: 0x9000,0x800 overlaps existing 0x9000,0x200 Nov 26 15:16:07 localhost kernel: mtrr: base(0x9200) is not aligned on a size(0x500) boundary In the dmesg -- 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5171] Memleak in xf86drmHash.c::HashHash()
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=5171 --- Additional Comments From [EMAIL PROTECTED] 2005-11-27 00:07 --- Created an attachment (id=3913) --> (https://bugs.freedesktop.org/attachment.cgi?id=3913&action=view) Patch to fix the memleak -- 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 5171] New: Memleak in xf86drmHash.c::HashHash()
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=5171 Summary: Memleak in xf86drmHash.c::HashHash() Product: DRI Version: DRI CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: libdrm AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] HashHash() leaks memory in the init code block. Memory is allocated by calling drmRandomCreate(), but drmRandomDestroy() isn't called. -- 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4087] indirect GLX crashs Xserver / in libGLcore.so ?
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=4087 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2005-11-26 23:59 --- It looks like the patch made it only into mesa-cvs, but not into xorg-cvs tree. -- 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4087] indirect GLX crashs Xserver / in libGLcore.so ?
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=4087 --- Additional Comments From [EMAIL PROTECTED] 2005-11-26 23:56 --- Created an attachment (id=3912) --> (https://bugs.freedesktop.org/attachment.cgi?id=3912&action=view) mesa_ctx_patch.txt -- 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: front/back buffer offsets in DRM
On Fri, 25 Nov 2005 16:16:48 -0700 Brian Paul <[EMAIL PROTECTED]> wrote: > > I've been playing around with the EGL r200 driver. Digging through > the framebuffer allocation code I've found a few problems. > > In order to support pbuffers and framebuffer objects we need to be > able to work with color/depth/stencil buffers are various locations in > video memory. > > The current code sets the front/back/depth buffer offsets and pitches > once in the radeon_do_init_cp() function and there's no way to change > them thereafter. > > It looks like the only code that uses this information is the glClear > and SwapBuffers-related code in radeon_cp_dispatch_clear(), > radeon_cp_dispatch_swap() and radeon_cp_dispatch_flip(). And the code > that enables/disables color tiling. > > Could someone more familiar with the code comment on what it would > take to fix the code so that color/depth buffers at arbitrary > locations can be used? > > I'd probably do away with the front/back_offset/pitch fields entirely > and pass the offset/pitch values as parameters to the ioctls. I'd > also write the code so there's no distinction between front/back color > buffers. Whats the point of doing these operations in DRM anyway? Personally I would just pull out as much code from there as possible. -- 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
