Re: New DRM driver model - gets rid of DRM() macros!
> > Still need someone with a Sparc machine to fix the ffb compile. I've got a cross compiler installed at home for just this purpose .. I'll work on it this evening.. 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: New DRM driver model - gets rid of DRM() macros!
I've found the problem with multiple drivers, it's in the mapping code. When drivers close their handles they are deleting permanent maps that don't belong to them. I'll fix it tomorrow. -- 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
Re: New DRM driver model - gets rid of DRM() macros!
Single card seems to be working currently. I still can't get multiple cards going yet. Second card tries to get the context without holding the lock and errors out. I'll keep working on it tonight and tomorrow. I'm past the obvious bug stage now and into the ones where I stare at it for five hours before I figure out what is wrong. Still need someone with a Sparc machine to fix the ffb compile. On Wed, 29 Sep 2004 00:10:18 +0100 (IST), Dave Airlie <[EMAIL PROTECTED]> wrote: > As with Ian, I'm trying to grab the time to review this over the next day > or two, I have one or two worries but as I haven't read over the code I'll > wait until I'm ready to dedicate some proper time to it .. -- 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
Re: compiling mach64 kernel module for 2.6.9-rc-mm4 kernel
Get the code from here: cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvs/dri co drm and build in the linux-2.6 directory. It looks like you are missing drm_sysfs.h which is is the CVS repository. I'm building mach64 from CVS on my machine without problems on current linus-bk. There files should be in the linux-2.6 directory: [EMAIL PROTECTED] linux-2.6]$ ls CVS drm_core.h drm_sysfs.h Makefile Makefile.kernel radeon_i2c.c radeon_i2c.h README [EMAIL PROTECTED] linux-2.6]$ Only the 2.4 DRM will build from linux directory, you have to use linux-2.6 On Wed, 29 Sep 2004 03:44:07 +0200, Micha Feigin <[EMAIL PROTECTED]> wrote: > I am trying to compile the mach64 drm kernel module for kernel > 2.6.9-rc2-mm4 from latest cvs as the code from the mach64 tree from > January is regrettably no longer compiling for me, too many changes to > the drm code in the kernel apparently (mostly problems with drmP.h). > > Anyway, I downloaded the latest cvs from freedesktop.org according to > the instructions on the site (it said something about a move of some of > the cvs code, but didn't seem related to drm). > > When I tried to compile it, it gave the following warnings about missing > symbols and then the driver won't load for the same reason: > > *** Warning: "mach64_sysfs_device_add" [/home/micha/dev/dri/new/drm/linux/mach64.ko] > undefined! > *** Warning: "remap_page_range" [/home/micha/dev/dri/new/drm/linux/mach64.ko] > undefined! > *** Warning: "mach64_sysfs_device_remove" > [/home/micha/dev/dri/new/drm/linux/mach64.ko] undefined! > *** Warning: "mach64_sysfs_create" [/home/micha/dev/dri/new/drm/linux/mach64.ko] > undefined! > *** Warning: "mach64_sysfs_destroy" [/home/micha/dev/dri/new/drm/linux/mach64.ko] > undefined! > > Is the tree supposed to compile now, which one if so and where am I > going wrong. If not, is there a tag/date thats known to work that I can > use (I could really use the little acceleration drm gives me for the > matlab work I do. Not much 3D, but enough to be intolerable without drm > support). > > 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 > -- 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
compiling mach64 kernel module for 2.6.9-rc-mm4 kernel
I am trying to compile the mach64 drm kernel module for kernel 2.6.9-rc2-mm4 from latest cvs as the code from the mach64 tree from January is regrettably no longer compiling for me, too many changes to the drm code in the kernel apparently (mostly problems with drmP.h). Anyway, I downloaded the latest cvs from freedesktop.org according to the instructions on the site (it said something about a move of some of the cvs code, but didn't seem related to drm). When I tried to compile it, it gave the following warnings about missing symbols and then the driver won't load for the same reason: *** Warning: "mach64_sysfs_device_add" [/home/micha/dev/dri/new/drm/linux/mach64.ko] undefined! *** Warning: "remap_page_range" [/home/micha/dev/dri/new/drm/linux/mach64.ko] undefined! *** Warning: "mach64_sysfs_device_remove" [/home/micha/dev/dri/new/drm/linux/mach64.ko] undefined! *** Warning: "mach64_sysfs_create" [/home/micha/dev/dri/new/drm/linux/mach64.ko] undefined! *** Warning: "mach64_sysfs_destroy" [/home/micha/dev/dri/new/drm/linux/mach64.ko] undefined! Is the tree supposed to compile now, which one if so and where am I going wrong. If not, is there a tag/date thats known to work that I can use (I could really use the little acceleration drm gives me for the matlab work I do. Not much 3D, but enough to be intolerable without drm support). 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-09-28 16:57 --- Looks good to me. -- 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-09-28 16:59 --- On second thought, the RADEONSetFBLocation() call should be moved before the #ifdef XF86DRI check. -- 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: New DRM driver model - gets rid of DRM() macros!
As with Ian, I'm trying to grab the time to review this over the next day
or two, I have one or two worries but as I haven't read over the code I'll
wait until I'm ready to dedicate some proper time to it ..
Dave.
On Tue, 28 Sep 2004, Jon Smirl wrote:
> I've checked two new directories into DRM CVS for Linux 2.6 -
> linux-core, shared-core. This code implements a new model for DRM
> where DRM is split into a core piece and personality modules that
> share the core. The major reason for doing this is that it allows me
> to remove all of the DRM() macros; something that is causing lot's of
> complaints from the Linux kernel people.
>
> cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvs/dri co drm
>
> The patch for this is quite large, 500K, and it will mess up the Linux
> 2.4/BSD DRM builds since it removes the DRM() macro. Instead of doing
> this as a patch I made the new CVS directories.
>
> I've checked radeon and r128 and they work. Everything else should
> work except ffb, please check the other drivers and let me know. I've
> probably made some typos with a edit this large.
>
> ffb should work in principle but since I don't own one or a Sparc
> machine so I can't compile the driver. I suspect ffb has compiler
> errors but the are easily fixed just by copying similar code from one
> of the working modules. Please send patches.
>
> The API between the core and personalities doesn't look to be all that
> huge. With work I'd guess that 10% of the entry points could be
> eliminated. After another year of development we might be able to
> specify a stable core API.
>
> What are everyone's thoughts on this? There is no technical reason it
> can't be implemented on Linux 2.4/BSD, although I don't see any reason
> to do it for 2.4.
>
> Any ideas on how to generate a unique identifier for the core? It
> probably should be regenerated by the Makefile whenever the core
> changes. Personalities would have to match the core identifier. This
> would stop people from loading binary modules that don't match the
> core.
>
> After sometime testing and fixing obvious problems I'll generate a
> patch for the 2.6 kernel and lkml.
>
> [EMAIL PROTECTED] linux-2.6]# lsmod | more
> Module Size Used by
> tdfx2816 0
> sis10176 0
> mga56704 0
> i915 16896 0
> via19428 0
> savage 3840 0
> r128 44672 0
> radeon 70272 0
> drm59684 8 tdfx,sis,mga,i915,via,savage,r128,radeon
>
> The core provides these entry points
>
> [EMAIL PROTECTED] linux-2.6]# grep EXPORT_SYMBOL *
> drm_bufs.c:EXPORT_SYMBOL(drm_order);
> drm_bufs.c:EXPORT_SYMBOL(drm_initmap);
> drm_dma.c:EXPORT_SYMBOL(drm_core_reclaim_buffers);
> drm_drv.c:EXPORT_SYMBOL(drm_cleanup_pci);
> drm_drv.c:EXPORT_SYMBOL(drm_init);
> drm_drv.c:EXPORT_SYMBOL(drm_exit);
> drm_drv.c:EXPORT_SYMBOL(drm_open);
> drm_drv.c:EXPORT_SYMBOL(drm_release);
> drm_drv.c:EXPORT_SYMBOL(drm_ioctl);
> drm_fops.c:EXPORT_SYMBOL(drm_flush);
> drm_fops.c:EXPORT_SYMBOL(drm_fasync);
> drm_init.c:EXPORT_SYMBOL(drm_flags);
> drm_irq.c:EXPORT_SYMBOL(drm_irq_uninstall);
> drm_irq.c:EXPORT_SYMBOL(drm_vbl_send_signals);
> drm_memory.c:EXPORT_SYMBOL(drm_calloc);
> drm_pci.c:EXPORT_SYMBOL(drm_pci_alloc);
> drm_pci.c:EXPORT_SYMBOL(drm_pci_free);
> drm_stub.c:EXPORT_SYMBOL(drm_probe);
> drm_vm.c:EXPORT_SYMBOL(drm_core_get_map_ofs);
> drm_vm.c:EXPORT_SYMBOL(drm_core_get_reg_ofs);
>
> Drivers provide these callbacks..
>
> struct drm_driver_fn {
>u32 driver_features;
>int dev_priv_size;
>int permanent_maps;
>drm_ioctl_desc_t *ioctls;
>int num_ioctls;
>int (*preinit)(struct drm_device *, unsigned long flags);
>void (*prerelease)(struct drm_device *, struct file *filp);
>void (*pretakedown)(struct drm_device *);
>int (*postcleanup)(struct drm_device *);
>int (*presetup)(struct drm_device *);
>int (*postsetup)(struct drm_device *);
>int (*dma_ioctl)( DRM_IOCTL_ARGS );
>/* these are opposites at the moment */
>int (*open_helper)(struct drm_device *, drm_file_t *);
>void (*free_filp_priv)(struct drm_device *, drm_file_t *);
>
>void (*release)(struct drm_device *, struct file *filp);
>void (*dma_ready)(struct drm_device *);
>int (*dma_quiescent)(struct drm_device *);
>int (*context_ctor)(struct drm_device *dev, int context);
>int (*context_dtor)(struct drm_device *dev, int context);
>int (*kernel_context_switch)(struct drm_device *dev, int old, int new);
>int (*kernel_context_switch_unlock)(struct drm_device *dev);
>int (*vblank_wait)(struct drm_device *dev, unsigned int *sequence);
> /* these have to be filled in */
>int (*postinit)(struct drm_device *, unsigned long flags);
>irqreturn_t (*irq_handler)( DRM_IRQ_ARGS );
>void (*irq_
[Bug 1461] missing textures in some games on r200
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=1461 --- Additional Comments From [EMAIL PROTECTED] 2004-09-28 15:57 --- Roland Scheidegger wrote: > Descent 3 works fine here with some hacked driver, unfortunately the changes > screw up some other games badly. Any chance you could attach a diff to play around with? -- 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: R300 driver update
Alex Deucher wrote: On Tue, 28 Sep 2004 16:28:45 +0200, Nicolai Haehnle <[EMAIL PROTECTED]> wrote: On Tuesday 28 September 2004 15:02, Vladimir Dergachev wrote: On Tue, 28 Sep 2004, Nicolai Haehnle wrote: Hi Nicolai, you can just rename the driver so it produces r300_dri.so - the 2d driver is in fact configured to tell DRI clients to use that binary. Well, it does produce r300_dri.so right now. The reason I am doing the work in an r300/ subdirectory is that development is going on in a different CVS repository, and I really don't fancy worrying about complicated merges with Mesa CVS (across file renames, at that!). Or maybe I somehow misunderstood what you meant? I think Nicolai has proven his competence as a coder, I think it'd be ok to give him mesa cvs access. it might be easier to develop in mesa cvs to keep synced up and such. Thoughts? I suppose you might want to wait till 6.2 is tagged. Fine by me. Daniel Stone can set you up with CVS-write permission. Just don't mess up the core/trunk code this week. -Brian --- 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 1461] missing textures in some games on r200
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=1461 --- Additional Comments From [EMAIL PROTECTED] 2004-09-28 14:54 --- Ok, I know why it doesn't work. Descent3 (didn't check HG2, just downloaded the Descent 3 demo) seems to always use projected textures - this does now work at all with the r200 driver, so all texture coordinates will be completely wrong. It's not that simple to fix otherwise I'd have fixed it a long time ago... Descent 3 works fine here with some hacked driver, unfortunately the changes screw up some other games badly. (Note that with the current driver you also won't get working shadow projectors in ut2k3/ut2k4 (can very easily be seen in dm-antalus, some trees should have large shadows), this is because of the same reason. With my hack you even get shadow projectors in ut2k4, but unfortunately you _only_ get the shadow textures correct in that game...). -- 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 960] rendering error - random textures used
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=960 --- Additional Comments From [EMAIL PROTECTED] 2004-09-28 13:47 --- Latest DRI/DRM CVS (Mesa 6.2) with Ian's fix solved it. -- 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: New DRM driver model - gets rid of DRM() macros!
On Tue, Sep 28, 2004 at 09:56:38AM -0700, Ian Romanick wrote: > Jon Smirl wrote: > [...] > >After sometime testing and fixing obvious problems I'll generate a > >patch for the 2.6 kernel and lkml. > > > >[EMAIL PROTECTED] linux-2.6]# lsmod | more > >Module Size Used by > >tdfx2816 0 > >sis10176 0 > >mga56704 0 > >i915 16896 0 > >via19428 0 > >savage 3840 0 > >r128 44672 0 > >radeon 70272 0 > >drm59684 8 tdfx,sis,mga,i915,via,savage,r128,radeon > > Anyone have a PCI card so that we can test actually using more than one > at a time? In the mean time, I think just having them all load at once > and one of them work is good enough. I have a radeon9200SE pci card, and a matrox G550 agp card. I can try when that 2.6 patch becomes available. Helge Hafting --- 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: R300 driver update
On Tue, 28 Sep 2004, Nicolai Haehnle wrote: On Tuesday 28 September 2004 15:02, Vladimir Dergachev wrote: On Tue, 28 Sep 2004, Nicolai Haehnle wrote: Hi Nicolai, you can just rename the driver so it produces r300_dri.so - the 2d driver is in fact configured to tell DRI clients to use that binary. Well, it does produce r300_dri.so right now. The reason I am doing the work in an r300/ subdirectory is that development is going on in a different CVS repository, and I really don't fancy worrying about complicated merges with Mesa CVS (across file renames, at that!). Or maybe I somehow misunderstood what you meant? It is I misunderstood what you meant - I thought you did not rename the driver. One very important feature of your driver is that allows to run with CP mode used for 2d operations and everything else done in software - this produces quite a speed up for most cards. This is useful for playing 2d games via Wine and for saving power on notebooks. Do I understand right that this (software fallback only) driver will have problems with regular X.org 6.8.1 ? If so it is unfortunate, or we could release a set of drivers for 6.8.1. On a more happy note, Clear doesn't lock up anymore, but the coordinate calculation seems to be all wrong. Cool ! Vladimir Dergachev cu, Nicolai --- 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: New DRM driver model - gets rid of DRM() macros!
On Tue, 28 Sep 2004 09:56:38 -0700, Ian Romanick <[EMAIL PROTECTED]> wrote: > Anyone have a PCI card so that we can test actually using more than one > at a time? In the mean time, I think just having them all load at once > and one of them work is good enough. It would be best if everyone tested each card individually right now, both PCI and AGP versions should work. I think I know of a couple places where it might break if multiple cards are used simultaneously. All static variables in the core are suspect and need to be individually checked. There are less than 20 so it shouldn't take too long. Of course any help with this is appreciated. Another thing that isn't written is splitting the module parameters between the core and personalities. I'll also switch syntax from 2.4 style to 2.6 style. When finished each module with have a debug=1 parameter and the core will also have a cards_limit which defaults to 16. This version also includes minor number reuse so hotplugging a card in/out won't exhaust the DRM minors. -- 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
Re: New DRM driver model - gets rid of DRM() macros!
Jon Smirl wrote: I /should/ be able to look at the code changes sometime this week. In the mean time, here are some initial comments... What are everyone's thoughts on this? There is no technical reason it can't be implemented on Linux 2.4/BSD, although I don't see any reason to do it for 2.4. I'm of two minds about this. On the one hand, I agree with you. 2.4 is in maintainence mode, and making a big change like this to the graphics driver system is outside that scope. On the other hand, if the 2.4 and the 2.6 code bases diverge too much, bugs fixed on the 2.6 side are less likely to be fixed on the 2.4 side. Moreover, with more divergence between the two, each gets less coverage. I could really go either way on it. Any ideas on how to generate a unique identifier for the core? It probably should be regenerated by the Makefile whenever the core changes. Personalities would have to match the core identifier. This would stop people from loading binary modules that don't match the core. I guess we'd want something like 'drm_core_version_'. Each layered driver would just have to reference the matching symbol. One neat thing about doing this is that we could theoretically make core modules that support multiple versions of the interal API and export a drm_core_version_* symbol for each. I have only one problem with this type of setup. If the user has a version mismatch, it's not trivially obvious why they aren't getting direct rendering. There are already a number of ways a user can get "stuck" like this, and this adds another one. It's not a new problem, but it is one that needs to be addressed. After sometime testing and fixing obvious problems I'll generate a patch for the 2.6 kernel and lkml. [EMAIL PROTECTED] linux-2.6]# lsmod | more Module Size Used by tdfx2816 0 sis10176 0 mga56704 0 i915 16896 0 via19428 0 savage 3840 0 r128 44672 0 radeon 70272 0 drm59684 8 tdfx,sis,mga,i915,via,savage,r128,radeon Anyone have a PCI card so that we can test actually using more than one at a time? In the mean time, I think just having them all load at once and one of them work is good enough. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ 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-09-28 09:31 --- Created an attachment (id=975) --> (https://freedesktop.org/bugzilla/attachment.cgi?id=975&action=view) This one-liner fixes suspend to disk. This one-liner fixes suspend to disk. Even works with 3D apps running. Please check and post whether there are any problems with this patch. -- 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: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 driver update
On Tue, 28 Sep 2004 16:28:45 +0200, Nicolai Haehnle <[EMAIL PROTECTED]> wrote: > On Tuesday 28 September 2004 15:02, Vladimir Dergachev wrote: > > On Tue, 28 Sep 2004, Nicolai Haehnle wrote: > > Hi Nicolai, you can just rename the driver so it produces r300_dri.so - > > the 2d driver is in fact configured to tell DRI clients to use that > > binary. > > Well, it does produce r300_dri.so right now. The reason I am doing the work > in an r300/ subdirectory is that development is going on in a different CVS > repository, and I really don't fancy worrying about complicated merges with > Mesa CVS (across file renames, at that!). Or maybe I somehow misunderstood > what you meant? I think Nicolai has proven his competence as a coder, I think it'd be ok to give him mesa cvs access. it might be easier to develop in mesa cvs to keep synced up and such. Thoughts? I suppose you might want to wait till 6.2 is tagged. Alex > > On a more happy note, Clear doesn't lock up anymore, but the coordinate > calculation seems to be all wrong. > > cu, > Nicolai > > > > --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
New DRM driver model - gets rid of DRM() macros!
I've checked two new directories into DRM CVS for Linux 2.6 -
linux-core, shared-core. This code implements a new model for DRM
where DRM is split into a core piece and personality modules that
share the core. The major reason for doing this is that it allows me
to remove all of the DRM() macros; something that is causing lot's of
complaints from the Linux kernel people.
cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvs/dri co drm
The patch for this is quite large, 500K, and it will mess up the Linux
2.4/BSD DRM builds since it removes the DRM() macro. Instead of doing
this as a patch I made the new CVS directories.
I've checked radeon and r128 and they work. Everything else should
work except ffb, please check the other drivers and let me know. I've
probably made some typos with a edit this large.
ffb should work in principle but since I don't own one or a Sparc
machine so I can't compile the driver. I suspect ffb has compiler
errors but the are easily fixed just by copying similar code from one
of the working modules. Please send patches.
The API between the core and personalities doesn't look to be all that
huge. With work I'd guess that 10% of the entry points could be
eliminated. After another year of development we might be able to
specify a stable core API.
What are everyone's thoughts on this? There is no technical reason it
can't be implemented on Linux 2.4/BSD, although I don't see any reason
to do it for 2.4.
Any ideas on how to generate a unique identifier for the core? It
probably should be regenerated by the Makefile whenever the core
changes. Personalities would have to match the core identifier. This
would stop people from loading binary modules that don't match the
core.
After sometime testing and fixing obvious problems I'll generate a
patch for the 2.6 kernel and lkml.
[EMAIL PROTECTED] linux-2.6]# lsmod | more
Module Size Used by
tdfx2816 0
sis10176 0
mga56704 0
i915 16896 0
via19428 0
savage 3840 0
r128 44672 0
radeon 70272 0
drm59684 8 tdfx,sis,mga,i915,via,savage,r128,radeon
The core provides these entry points
[EMAIL PROTECTED] linux-2.6]# grep EXPORT_SYMBOL *
drm_bufs.c:EXPORT_SYMBOL(drm_order);
drm_bufs.c:EXPORT_SYMBOL(drm_initmap);
drm_dma.c:EXPORT_SYMBOL(drm_core_reclaim_buffers);
drm_drv.c:EXPORT_SYMBOL(drm_cleanup_pci);
drm_drv.c:EXPORT_SYMBOL(drm_init);
drm_drv.c:EXPORT_SYMBOL(drm_exit);
drm_drv.c:EXPORT_SYMBOL(drm_open);
drm_drv.c:EXPORT_SYMBOL(drm_release);
drm_drv.c:EXPORT_SYMBOL(drm_ioctl);
drm_fops.c:EXPORT_SYMBOL(drm_flush);
drm_fops.c:EXPORT_SYMBOL(drm_fasync);
drm_init.c:EXPORT_SYMBOL(drm_flags);
drm_irq.c:EXPORT_SYMBOL(drm_irq_uninstall);
drm_irq.c:EXPORT_SYMBOL(drm_vbl_send_signals);
drm_memory.c:EXPORT_SYMBOL(drm_calloc);
drm_pci.c:EXPORT_SYMBOL(drm_pci_alloc);
drm_pci.c:EXPORT_SYMBOL(drm_pci_free);
drm_stub.c:EXPORT_SYMBOL(drm_probe);
drm_vm.c:EXPORT_SYMBOL(drm_core_get_map_ofs);
drm_vm.c:EXPORT_SYMBOL(drm_core_get_reg_ofs);
Drivers provide these callbacks..
struct drm_driver_fn {
u32 driver_features;
int dev_priv_size;
int permanent_maps;
drm_ioctl_desc_t *ioctls;
int num_ioctls;
int (*preinit)(struct drm_device *, unsigned long flags);
void (*prerelease)(struct drm_device *, struct file *filp);
void (*pretakedown)(struct drm_device *);
int (*postcleanup)(struct drm_device *);
int (*presetup)(struct drm_device *);
int (*postsetup)(struct drm_device *);
int (*dma_ioctl)( DRM_IOCTL_ARGS );
/* these are opposites at the moment */
int (*open_helper)(struct drm_device *, drm_file_t *);
void (*free_filp_priv)(struct drm_device *, drm_file_t *);
void (*release)(struct drm_device *, struct file *filp);
void (*dma_ready)(struct drm_device *);
int (*dma_quiescent)(struct drm_device *);
int (*context_ctor)(struct drm_device *dev, int context);
int (*context_dtor)(struct drm_device *dev, int context);
int (*kernel_context_switch)(struct drm_device *dev, int old, int new);
int (*kernel_context_switch_unlock)(struct drm_device *dev);
int (*vblank_wait)(struct drm_device *dev, unsigned int *sequence);
/* these have to be filled in */
int (*postinit)(struct drm_device *, unsigned long flags);
irqreturn_t (*irq_handler)( DRM_IRQ_ARGS );
void (*irq_preinstall)(struct drm_device *dev);
void (*irq_postinstall)(struct drm_device *dev);
void (*irq_uninstall)(struct drm_device *dev);
void (*reclaim_buffers)(struct file *filp);
unsigned long (*get_map_ofs)(drm_map_t *map);
unsigned long (*get_reg_ofs)(struct drm_device *dev);
void (*set_version)(struct drm_device *dev, drm_set_version_t *sv);
int (*version)(drm_version_t *version);
};
--
Jon Smirl
[EM
Re: R300 driver update
On Tuesday 28 September 2004 15:02, Vladimir Dergachev wrote: > On Tue, 28 Sep 2004, Nicolai Haehnle wrote: > Hi Nicolai, you can just rename the driver so it produces r300_dri.so - > the 2d driver is in fact configured to tell DRI clients to use that > binary. Well, it does produce r300_dri.so right now. The reason I am doing the work in an r300/ subdirectory is that development is going on in a different CVS repository, and I really don't fancy worrying about complicated merges with Mesa CVS (across file renames, at that!). Or maybe I somehow misunderstood what you meant? On a more happy note, Clear doesn't lock up anymore, but the coordinate calculation seems to be all wrong. cu, Nicolai pgpF6IkHKYM9k.pgp Description: PGP signature
Re: R300 driver update
On Tue, 28 Sep 2004, Nicolai Haehnle wrote: Hi, I decided to commit what I have in terms of an R300 driver so far. You can find You can find it in th r300 project on SourceForge in the r300_driver module: cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/r300 checkout r300_driver As you can easily see I started with the R200 driver. Since I didn't know what to rip out and what to keep in at first, I decided to take the extra time and separate stuff out into Radeon generic and R200/R300 code. So in theory, the driver should still work on R200 hardware, although a) I couldn't tested this and b) it's not quite uptodate (about a week old). I have written state emission code which works, and I have started implementing hardware accelerated clear. Something does happen on the screen, but immediately afterwards I get a hard lockup for now. I'll let you know when the driver is more usable. cu, Nicolai Hi Nicolai, you can just rename the driver so it produces r300_dri.so - the 2d driver is in fact configured to tell DRI clients to use that binary. best Vladimir Dergachev --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: Where is the source for DRM 1.5?
Now I understand. Thanks for clearing this up. You might want to add this to your Wiki as a FAQ. I seen a number of people be confused on this matter, especial around VIA EPIA patchs. Barry > -Original Message- > From: Dave Airlie [mailto:[EMAIL PROTECTED] > Sent: 28 September 2004 11:38 > To: Barry Scott > Cc: [EMAIL PROTECTED] > Subject: RE: Where is the source for DRM 1.5? > > > > > Why 1.5, because the CLE266 XvMC driver needs that > > version. > > > > I'm looking for a stable version of the 1.5 interface to use with > > a 2.4.25 kernel. How do I get that source? Can I trust the head of > > CVS to have been tested enough for production use? > > Try using the DRM from Xorg6.8.1 release. > > 1.5 is only the VIA release number, every driver has its own version, so > we don't do stable release via our tree, only via Linus and Xorg... > > Dave. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
R300 driver update
Hi, I decided to commit what I have in terms of an R300 driver so far. You can find You can find it in th r300 project on SourceForge in the r300_driver module: cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/r300 checkout r300_driver As you can easily see I started with the R200 driver. Since I didn't know what to rip out and what to keep in at first, I decided to take the extra time and separate stuff out into Radeon generic and R200/R300 code. So in theory, the driver should still work on R200 hardware, although a) I couldn't tested this and b) it's not quite uptodate (about a week old). I have written state emission code which works, and I have started implementing hardware accelerated clear. Something does happen on the screen, but immediately afterwards I get a hard lockup for now. I'll let you know when the driver is more usable. cu, Nicolai pgpsE6JTPWXag.pgp Description: PGP signature
RE: Where is the source for DRM 1.5?
> Why 1.5, because the CLE266 XvMC driver needs that > version. > > I'm looking for a stable version of the 1.5 interface to use with > a 2.4.25 kernel. How do I get that source? Can I trust the head of > CVS to have been tested enough for production use? Try using the DRM from Xorg6.8.1 release. 1.5 is only the VIA release number, every driver has its own version, so we don't do stable release via our tree, only via Linus and Xorg... Dave. > > Before you suggest it I cannot use a 2.6 kernel. > > Barry > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Vladimir > > Dergachev > > Sent: 28 September 2004 01:59 > > To: Barry Scott > > Cc: [EMAIL PROTECTED] > > Subject: Re: Where is the source for DRM 1.5? > > > > > > > > > > On Mon, 27 Sep 2004, Barry Scott wrote: > > > > > I have failed to find a tar ball of CVS tag that names any > > > specific version of DRM. What did I miss? > > > > Normally, the latest version of DRM distributed with linux kernel source > > should be enough. > > > > Why are you looking for 1.5 ? (Also note that different drivers have > > different versions). > > > > best > > > > Vladimir Dergachev > > > > > > > > Barry > > > > > > > > > > > > --- > > > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > > > Project Admins to receive an Apple iPod Mini FREE for your judgement on > > > who ports your project to Linux PPC the best. Sponsored by IBM. > > > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > > > -- > > > ___ > > > Dri-devel mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > > > > > > > --- > > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > > Project Admins to receive an Apple iPod Mini FREE for your judgement on > > who ports your project to Linux PPC the best. Sponsored by IBM. > > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > > -- > > ___ > > Dri-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > > > > > --- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > -- > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- 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: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ 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-09-28 03:13 --- hi, the problem for me is very simple, I need acpi and suspend to disk. The workaround is a bad solution, but commenting out the line works for me, because I can use suspend and everything else works fine. The log, here you can see it for yourself: http://fallenangel.deathcon.de/xorg.log The log is from 4 days Uptime and I used 5 or more times Suspend to Disk. If there is a better solution or any chance I can help to fix this, just tell me. I would try patches, this shouldn't be a problem. -- 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: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: Where is the source for DRM 1.5?
You have no release numbering?!? Why 1.5, because the CLE266 XvMC driver needs that version. I'm looking for a stable version of the 1.5 interface to use with a 2.4.25 kernel. How do I get that source? Can I trust the head of CVS to have been tested enough for production use? Before you suggest it I cannot use a 2.6 kernel. Barry > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Vladimir > Dergachev > Sent: 28 September 2004 01:59 > To: Barry Scott > Cc: [EMAIL PROTECTED] > Subject: Re: Where is the source for DRM 1.5? > > > > > On Mon, 27 Sep 2004, Barry Scott wrote: > > > I have failed to find a tar ball of CVS tag that names any > > specific version of DRM. What did I miss? > > Normally, the latest version of DRM distributed with linux kernel source > should be enough. > > Why are you looking for 1.5 ? (Also note that different drivers have > different versions). > > best > > Vladimir Dergachev > > > > > Barry > > > > > > > > --- > > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > > Project Admins to receive an Apple iPod Mini FREE for your judgement on > > who ports your project to Linux PPC the best. Sponsored by IBM. > > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > > -- > > ___ > > Dri-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > > > --- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > -- > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > > --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
