[Dri-devel] mach64-0-0-7-branch status
Okay the last few fixes make tuxracer and glxgears work again, so the new branch should be as useable as the old one, I think there are still a few cleanups in the native vertex code (using macros for a few things), and then a texmem converison might be in order. But it's good enough for me to get on with some real work on my laptop :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New DRM design (was ATI I2C, MONID)
I've been getting a lot of mail about this both on and off list. First off, very little code has been written, this is just a design concept. One thing is clear there are two consoles involved. One is the system console that receives printk's, the second is your garden variety command line terminal session. I'd like to explore pushing this second type into user space. One advantage to doing that would be the ability use 3-4 PCI graphics cards to set up a multiuser system. You could even have separate command line sessions on each display head. Implementing a system for displaying printk's to the screen has to cope with another type of problem caused by a xserver that is hardware compositing the entire screen on every vertical retrace. Without coordination anything you write to screen will be gone 1/60th of second later. Full screen games have the same problem. The bigger goal here is that I'm exploring a system that would shut down all direct user space access to the graphics hardware. The graphics hardware would be protected by a single device driver and a user space library is used for accessing it. This type of design accomodates graphics hardware where the VRAM is not visible to the bus. SGI machines already have this and there may be more chips like this in the future. It also stops the free for all where every app is programming the graphics hardware from user space. I've had several discussion now about how to handle printk's in an environment like this. The best one so far is for the graphics driver to hold a log of the printk's it has received. When a new one is received the driver suspends whoever is writing to screen, possibly by letting them continure to write to the back buffer and stopping screen swaps. It then formats the front buffer and paints in it's log of printk's. Note that the front buffer will already be set up for display in the current mode. Formatting and painting is something that can be done at interrupt time. The system would then stay in this state, updating for more printk's, until some kind of input was received (sysreq?). The printk's would also be sent off to some normal command line console where you could look at them and run programs if the system remains stable. One hole in this is what happens if a printk occurs in the middle of a mode switch? or if the display is in a suspended state? This will require some research. Getting the display out of suspend may not be achievable at interrupt time. These aren't new holes, they're there right now for the current console. The above scheme does provide the new feature of making the printks appear while xserver or a game is running. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New DRI driver interface (Re: CVS Update: xc (branch: driinterface-0-0-3-branch))
Ian Romanick wrote: 1. Commit some minor changes to the r200 driver to use the new interfaces. This will go in Mesa trunk, but will be guarded by #ifdef. This is needed because the code calls some functions in dri_util.c that only exist in the branch. Done. Tomorrow I may do some clean-up on this code and make similar changes to the MGA driver. It will all depend on whether or not I have a chance to get to it. :( 2. Finish adding at least rudimentary server-side fbconfig support to the 0-0-3 branch. Looking at my 0-0-2 tree, which I haven't touched since November, it looks like most of the work has actually been done. That should allow us to enable GLX_SGIX_fbconfig in any driver that uses the new interfaces (i.e., r200 initially). Done. GLX_OML_swap_method is also enabled. There are some comments about this in the r200_screen.c. 3. After some testing and "cool down" period, merge the branch into the trunk. I expect this to happen fairly quickly. In-progress. Please test this branch! :) Would it be possible to make the R200 nightly snapshot come from the branch instead (or in addition to) the trunk? I'd like to merge to the trunk next Thursday (19-Feb-2004). In order to feel comfortable doing that, I'd like to hear about people actually using the branch, even if they don't use the new functionality. 4. Create a driinterface-0-0-4-branch. The purpose of this branch will be to implement GLX protocol and indirect rendering support for pbuffers. *LOTS* of work will need to be done to the driver to enable pbuffers, so that won't be part of this branch. Once this is done, the client library and server will be able to advertise GLX 1.3 (for indirect rendering anyway). Anyone know of any good, simple pbuffers tests? :) --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: about Xfree86 with DRI and Mesa
On Wed, 2004-02-11 at 13:50, Felix Kühling wrote: > On Tue, 10 Feb 2004 23:51:58 + > Sérgio Monteiro Basto <[EMAIL PROTECTED]> wrote: > > > On Tue, 2004-02-10 at 22:38, Sérgio Monteiro Basto wrote: > > > On Tue, 2004-02-10 at 13:27, Felix Kühling wrote: > > > > > > > > I realize that xc/extras/Mesa is almost the same source of Mesa-5.0.2 > > > > > with just a few modifications, my question is, have you make any change > > > > > in this code ? > > > > > or can I update Mesa verison with last version of Mesa-5.0.2 ? > > > > > > I think, can be not Mesa-5.0.2 (last version) but one Mesa-5.0.2cvs > > version. > > And thinking better, the question is, if we have any code thats depends > > on Mesa-5.0.2 code or for example should be no problem if I update Mesa > > to 6.0 > > First of all, we didn't modify Mesa to make it work with the driver. But > the interface between Mesa and the 3D driver changes slightly with every > new Mesa version. Therefore upgrading Mesa would require some updates in > the driver as well. ok > At some point we're going to move the savage driver > to Mesa CVS, so it'll use the very latest Mesa development code, like > all the other drivers do by now. ATM, I think we can live with some Mesa > bugs. Let's get the driver in shape first. I'd like to make it work with > SavageMX/IX chips first. I am thinking about this bug on Mesa3d (that can visible on rubik cube screen saver), because at some point I had the exactly the some bug on my wishgl.sf.net project and could be just a configuration of GL, I will try found or remember what is the problem at the time and I will inform you. > After that we'll need to redesign the kernel > driver in order to improve security and allow IRQ handling. After that I > believe we can move to Mesa CVS. > > That's my conservative plan. Rationale: As long as the 3D driver and the > kernel driver change a lot we should keep them in the same CVS > repository in order to minimize the risk of incompatibilities and > version mismatches. I'm not going to do proper versioning with forward > and backward compatibility with this experimental code. > > > > > Thanks > > > > -- > > Sérgio M. B. > > > > Regards, > Felix > > P.S.: Sorry for bouncing this thread back and forth between dri-users > and dri-devel. This mail is really about development issues. no problem thanks -- Sérgio M. B. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: GATOS and DRI merge
On Thu, 2004-02-12 at 00:26, Hod McWuff wrote: > On Wed, 2004-02-11 at 17:28, Michel DÃnzer wrote: > > By the way, where can I find a three-way merge tool? ;) I like meld, for example. > I've found Gatos-related changes in radeon_cp.c, radeon_drv.h, and > radeon_state.c. I've reimplemented what changes I could find... They're mostly superfluous AFAICT. Again, the DRM in current DRI CVS should basically work with the GATOS 2D driver, that one just needs to set up things similarly to how the 2D driver in DRI CVS does. > > The DRM and 3D driver in current DRI CVS should theoretically be able to > > work with their 2D driver. Its aperture setup may have to be changed > > slightly though. > > The one in 2.6.2 works with 2D (after faking the version number) Faking the version number is obviously a bad idea. The GATOS 2D driver should work with the 1.10.0 radeon DRM with the changes described above. The GATOS 3D driver only works with the old GATOS DRM and 2D driver, but the 3D driver in current DRI CVS should work with anything, or at least fail gracefully. > 2.6.2-update.patch merges current DRI CVS into the 2.6.2 tree BTW, AFAIK the DRM in the -mm kernel tree is already fairly up to date. Some of the stuff in DRI CVS is only needed for compatibility with older kernels etc. -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New DRM design (was ATI I2C, MONID)
On Maw, 2004-02-10 at 00:30, Jon Smirl wrote: > There are lots of solutions to this: > 1) queue the printk's Not a solution. The box crashed, game over, where is my data > 2) add an in-kernel path for write to console that cooperates with the normal > user space one Ditto > 3) if you know you are going to be debugging code like this, use an alternative > solution like the serial port or a second video card running framebuffer., Makes life hard for 99.9% of the debugging people > You can't see a kernel oops from an interrupt when running XWindows any way. Untrue if you are running a suitable console. One thing you can get out of this with kernel side mode switching is *more* ability to get back into a sane mode and dump data. (BTW there is a patch to use int10 16bit emulation hacks to drop back into 16 bit mode on oops and bios clear to display the crash) > I'm sure an expert kernel hacker can come up with 10 more solutions. Let's work > together to try and solve these problems. Why the hell do you want console in user space anyway ? If the console layers are built properly then it comes for free near enough Your bottom layer is a PCI bus driver that spots cards and handles them appearing and leaving, and deals with command queues, describing resource types and which are safe to access. It also handles revocation and hotplug event paths. It might do some or all the mode switching but as Ben pointed out to me hotplug can handle that in some situations. It should also export a description of the frame buffer memory layout, palette and the like. (Akin to what DGA exports basically). It may also offer some minimal accelerations for use by the fb driver but primarily it wants to export the descriptions and the command engines. On top of that you can load a frame buffer driver, unaccelerated and not hard to deal with. The kernel console code is pretty decent there although it too lacks hotplug paths, even though the tty layer above it is quite happy. It also lacks multi-console and/or you can load a DRI module which uses the queue interfaces to provide direct render service and/or X server render services It all starts to look much like DirectFB, and I think there is some wheel redesigning going on around here that perhaps should be avoided by looking at directfb in detail too as a basis for the final thing --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [ dri-Bugs-893194 ] Radeon locks up with complex GL apps
Am Dienstag, 10. Februar 2004 23:48 schrieb Dieter Nützel: > Am Dienstag, 10. Februar 2004 14:19 schrieb Roland Scheidegger: > > Dieter Nützel wrote: > > > Am Dienstag, 10. Februar 2004 08:45 schrieb Email Archive: > > >> On Mon, 2004-02-09 at 20:55, Michel Dänzer wrote: > > >>> [ Following up to the dri-devel mailing list, we aren't really > > >>> using the sf.net bug tracker anymore but rather the kernel and > > >>> XFree86 bugzillas ] > > >>> > > >>> On Mon, 2004-02-09 at 04:55, SourceForge.net wrote: > > I just ported the latest CVS drm-kernel code into the 2.6.2 > > vanilla kernel. > > >>> > > >>> Do you have a patch for us to look at? > > >> > > >> Yes, I think I posted it to the SourceForge bug tracker. It's down > > >> right now, or I'd be including a bug ID #. > > >> > > >>> Does the same problem occur if you just build the DRM from DRI > > >>> CVS? > > >> > > >> It won't compile. Aside from a small number of API changes, the > > >> Makefile.linux is *severely* broken about include directories under > > >> 2.6. > > > > > > I use only 2.6.x. There is No problem with DRI CVS (DRM). > > > > > > But some apps hang the graphics card (hard). > > > > > > UT2003 Citadel after some (<= 3) seconds. But _very_ smooth with S3TC > > > and Roland's hardware TCL patch. > > Some additional notes. > > It was your code (patch) with Mesa, GLX from last week. > Not with latest Mesa and GLX code (Brian, Ian). OK, update after the api_arrayelt.c fix. > It locks in Citadel during _first_ mouse move (immediately). It happens in "Capture the Flag" -> Citadel. I can move in all other demos with cursor keys _and_ mouse, except Citadel. When I move (I haven't hit the fire button) with the cursor keys all is right, too. But when I got the mouse in my hand and do the first _little_ move it hangs. > I could move around not play "Bombing Run" (Egypt) "Temple of Anubis"...;-) > for about 15 minutes. > My girlfriend and I watched the GREAT textures mirrors and halls...;-) > > Now, with your patch r200_newlight-2.diff and latest (?) Mesa code the > "behavior" is the same, but some textures (the mirrors, multi textures?) > are broken in "Bombing Run" (Egypt). All textures are RIGHT after the api_arrayelt.c fix. > > That's not good. There is nothing (both in the S3TC patch as well as in > > the changed lighting code) which could make lockups disappear. Using > > compressed textures shouldn't change anything (except the textures are > > smaller so less texture swapping is needed which might mean there are > > more free dma buffers available). The lighting changes did avoid some > > TCL fallback with materials between begin/end (and it looks like the > > fallback doesn't always work correctly, though I don't think it causes > > lockups), but in the latest patch (submitted to cvs yesterday) it's back > > in (as removing it wasn't correct and sometimes caused obvious rendering > > errors, it still awaits a proper fix). The patch still avoids a tcl > > fallback when using two-sided materials, but that really shouldn't have > > caused lockups... > > Maybe the broken textures? See above. > > Meaning if the lockups have disappeared in UT2003, they are likely to > > reappear somewhere else. > > That said, I just tried to reproduce the lockups, but I can't even get > > ut2003 (demo 2206) to start here, it crashes even before the nvidia logo > > appears (seems to segfault and then be stuck waiting for a signal, > > killall -9 will just get rid of it fine). > > Now, it sigfault immediately like yours... All fixed, except the hang. > > I can only hope it's not > > caused by the lighting changes I've commited yesterday (though I've no > > idea how these changes could cause that) - maybe some of the > > experimental code I've got here causes it. No ;-) Only "problem" is some slowdown in the big halls and "outside" of "Temple of Anubis". Any comments, Andreas? TMU36 missing? Any updates? Cheers, Dieter --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: GATOS and DRI merge
On Wed, 2004-02-11 at 08:20, Hod McWuff wrote: > > That's not what I meant - I mean, what big things have happened in the > *DRI* tree since the Gatos fork. I need an idea of that to be able to > sort gatos-related changes from simple base-version differences. Once you have found the common ancestor of the DRI and GATOS code, a three way merge tool should be helpful. > So, right now my focus is to isolate what the Gatos folks did to get the > kernel module to work with their XFree driver. They changed the locations of the framebuffer and GART apertures to the same places as in their 2D driver, don't know if they changed anything else. The DRM and 3D driver in current DRI CVS should theoretically be able to work with their 2D driver. Its aperture setup may have to be changed slightly though. -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] PCI gart: possible fix?
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2004-02-11 at 21:26, Alex Deucher wrote:
> > I was looking through the the databooks regarding PCI gart and I
> > noticed that r128, radeon, and r200 all do PCI gart the same way.
> that
> > said, I also noticed that PCI GART is limited to 4 MB of system
> memory
> > when used with a PCI card and 32 MB when used with an AGP card.
>
> Where did you see that?
It's in the r128 DDK software development guide, page 2-23.
>
> > I haven't yet looked at the gart code in the radeon driver, but
> perhaps
> > it is trying to use more than 4 MB of system memory
>
> The default is 8 MB for both AGP and PCI GART.
>
> > and that is causing the slow down.
>
> Perhaps, but I'd rather expect different symptoms, and it used to
> work
> fine for me on older chips. Easy enough to find out though:
>
> Option "AGPSize" "4"
Yeah, it's just a guess. I'm not familiar with the code, nor do I have
a PCI card to test with.
>
> ("GARTSize" is an alias in newer radeon drivers)
>
> > it may also explain why PCI gart seems to "work" on AGP cards and
> older
> > radeons, but not on newer PCI ones.
>
> >From what I remember, mostly AGP cards used to be problematic
> traditionally, and only on x86. PCI cards being problematic is a
> recent
> trend.
Yeah. As I recall it seems like mostly r200 PCI cards.
Alex
>
>
> --
> Earthling Michel Dänzer | Debian (powerpc), X and DRI
> developer
> Libre software enthusiast|
> http://svcs.affero.net/rm.php?r=daenzer
>
>
__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 1169] DRI works on X initiation, but fails later
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=1169 [EMAIL PROTECTED] changed: What|Removed |Added CC|[EMAIL PROTECTED] | --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 16:43 --- What I saw was texturing no longer working after a while, not direct rendering in general. Besides, if the X server log says direct rendering is disabled, then I don't see how it can work. Please attach the X server log and the output of LIBGL_DEBUG=verbose glxinfo, preferably once for when it's working and once for when it's not. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] PCI gart: possible fix?
On Wed, 2004-02-11 at 21:26, Alex Deucher wrote:
> I was looking through the the databooks regarding PCI gart and I
> noticed that r128, radeon, and r200 all do PCI gart the same way. that
> said, I also noticed that PCI GART is limited to 4 MB of system memory
> when used with a PCI card and 32 MB when used with an AGP card.
Where did you see that?
> I haven't yet looked at the gart code in the radeon driver, but perhaps
> it is trying to use more than 4 MB of system memory
The default is 8 MB for both AGP and PCI GART.
> and that is causing the slow down.
Perhaps, but I'd rather expect different symptoms, and it used to work
fine for me on older chips. Easy enough to find out though:
Option "AGPSize" "4"
("GARTSize" is an alias in newer radeon drivers)
> it may also explain why PCI gart seems to "work" on AGP cards and older
> radeons, but not on newer PCI ones.
>From what I remember, mostly AGP cards used to be problematic
traditionally, and only on x86. PCI cards being problematic is a recent
trend.
--
Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] PCI gart: possible fix?
I was looking through the the databooks regarding PCI gart and I noticed that r128, radeon, and r200 all do PCI gart the same way. that said, I also noticed that PCI GART is limited to 4 MB of system memory when used with a PCI card and 32 MB when used with an AGP card. I haven't yet looked at the gart code in the radeon driver, but perhaps it is trying to use more than 4 MB of system memory and that is causing the slow down. it may also explain why PCI gart seems to "work" on AGP cards and older radeons, but not on newer PCI ones. On the other hand perhaps the driver already takes care of this... I haven't checked. Just a thought... Alex __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] GATOS and DRI merge
--- Jon Smirl <[EMAIL PROTECTED]> wrote:
> There are two mainpieces to this that I know of, maybe more.
>
> 1) The tuner
> 2) video overlays
>
> xserver may render video overlays pointless. Once we get hardware
> compositing
> going you should be able to rebuild the entire screen on every TV
> frame. You may
> want to review what is happening with xserver before spending a lot
> of time on
> overlays. How does this play with the current state of XV?
There are some nice features in the Gatos Xv support (RGB overlays,
de-interlacing, capture/tuner support) that would be useful in the
general xfree86 driver. The radeon overlay also has alpha blending
capabilites. I wrote a patch for radeon that GATOS accepted. I was
waiting for 4.4 to be released to add the patch to xfree86. It will
really be useful once visuals with an alpha value are supported in the
server. You can adjust the alpha value of the overlay and the graphics
layer. you can do some cool hacks with it now.
patch is here:
http://www.botchco.com/alex/radeon/Xv/xv_alpha/
>
> Don't the All-in-wonder boards use the bt8x8 tuner chips? Any idea
> why the BT
> driver in drivers/media/video won't work for the ATI cards? I have
> the docs for
> the AIW but they're in RTF, I'm downloading OpenOffice right now. It
> might be
> easier to just fix the existing BT driver to work on the ATI cards.
Most use the ati theater chip for the capture and decoding, and then a
regular tuner for tuning in RF signals. i2c IS used. see gatos
radeon_video.c.
>
> I see also that there are drivers for the remote control and TV
> output. TV out
> probably has to be intergrated into the X driver. Remote control
> should work
> standalone.
Probably input should move to the linux input layer.
Alex
>
>
>
>
> --- Hod McWuff <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, 2004-02-10 at 17:44, Jon Smirl wrote:
> > > Did GATOS make changes to the DRM drivers?
> > >
> >
> > Yes, for a while I was tracking its CVS and rebuilding often. I had
> > 3D and video working together just fine under 2.4. Gentoo Linux
> even
> > went as far as making a drm-kernel ebuild that patched for gatos.
> >
> > :pserver:[EMAIL PROTECTED]:/cvsroot/gatos
> >
> > module drm-kernel
> >
> > > Is it using I2C to get to the TV tuner on ATI cards?
> >
> > No. I2C, so far as I know, isn't involved at all.
> >
> > >
> > > What else get changed in the Xfree drivers?
> >
> > They have an ati.2 module (same CVSROOT) that you xmkmf against a
> > compiled XFree tree, then make ; make install, that provides access
> to
> > the tuner and v4l playback (MPEG acceleration). A separate kernel
> module
> > is required for video capture.
> >
> > The ati.2 module replaces
> > /usr/X11R6/lib/modules/drivers/{ati,atimisc,r128,radeon}_drv.o
> >
> > and adds
> >
>
/usr/X11R6/lib/modules/multimedia/{bt829,fil236,msp3430,saa7114,tda8425,tda9850,tda9886,theatre}_drv.o
> >
> >
> >
> > >
> > > --- Hod McWuff <[EMAIL PROTECTED]> wrote:
> > > >
> > > > OK, onward and upward... I'm starting to investigate what it
> would take
> > > > to merge the GATOS functionality into the current DRI. I'm sure
> the
> > > > XFree side is going to be a pain in the ass, but I'm starting
> with the
> > > > kernel modules.
> > > >
> > > > The first discrepancy I need cleared up is about driver
> support. The
> > > > current DRI source seems to have drivers for:
> > > > i810,i830,mga,r128,radeon,sis,tdfx
> > > >
> > > > Some are split between multiple files, some are in a single
> file.
> > > > If there's a document somewhere saying what files have what,
> then it'd
> > > > help to see it.
> > > >
> > > > The kernel copy also has a 'ffb' driver, which I'm assuming
> until
> > > > someone tells me otherwise is an out of date hack.
> > > >
> > > > The Gatos copy has the same drivers as the DRI source, but all
> split
> > > > amongst many files. I have a feeling the gamma and SIS drivers
> in this
> > > > copy are screwed totally anyway - in fact probably only the
> radeon and
> > > > r128 drivers from Gatos are relevant anyway, plus any changes
> in the
> > > > drm_* files.
> > > >
> > > > So, to summarize, I need to know *roughly* what's changed since
> the
> > > > Gatos folks forked, in terms of what-moved-where and an idea of
> any
> > > > structural changes. I can read the different sources and figure
> out the
> > > > code changes myself, but I need to know what I'm looking for.
> > > >
> > > > It would seem the best approach is to merge their changes -
> > > > conceptually, one by one - into the current DRI sources.
> > > >
> > > >
__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.ecl
[Dri-devel] Re: about Xfree86 with DRI and Mesa
On Tue, 10 Feb 2004 23:51:58 + Sérgio Monteiro Basto <[EMAIL PROTECTED]> wrote: > On Tue, 2004-02-10 at 22:38, Sérgio Monteiro Basto wrote: > > On Tue, 2004-02-10 at 13:27, Felix Kühling wrote: > > > > > > I realize that xc/extras/Mesa is almost the same source of Mesa-5.0.2 > > > > with just a few modifications, my question is, have you make any change > > > > in this code ? > > > > or can I update Mesa verison with last version of Mesa-5.0.2 ? > > > > I think, can be not Mesa-5.0.2 (last version) but one Mesa-5.0.2cvs > version. > And thinking better, the question is, if we have any code thats depends > on Mesa-5.0.2 code or for example should be no problem is I update Mesa > to 6.0 First of all, we didn't modify Mesa to make it work with the driver. But the interface between Mesa and the 3D driver changes slightly with every new Mesa version. Therefore upgrading Mesa would require some updates in the driver as well. At some point we're going to move the savage driver to Mesa CVS, so it'll use the very latest Mesa development code, like all the other drivers do by now. ATM, I think we can live with some Mesa bugs. Let's get the driver in shape first. I'd like to make it work with SavageMX/IX chips first. After that we'll need to redesign the kernel driver in order to improve security and allow IRQ handling. After that I believe we can move to Mesa CVS. That's my conservative plan. Rationale: As long as the 3D driver and the kernel driver change a lot we should keep them in the same CVS repository in order to minimize the risk of incompatibilities and version mismatches. I'm not going to do proper versioning with forward and backward compatibility with this experimental code. > > Thanks > > -- > Sérgio M. B. > Regards, Felix P.S.: Sorry for bouncing this thread back and forth between dri-users and dri-devel. This mail is really about development issues. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] GATOS and DRI merge
On Tue, 2004-02-10 at 17:44, Jon Smirl wrote:
> Did GATOS make changes to the DRM drivers?
>
Yes, for a while I was tracking its CVS and rebuilding often. I had
3D and video working together just fine under 2.4. Gentoo Linux even
went as far as making a drm-kernel ebuild that patched for gatos.
:pserver:[EMAIL PROTECTED]:/cvsroot/gatos
module drm-kernel
> Is it using I2C to get to the TV tuner on ATI cards?
No. I2C, so far as I know, isn't involved at all.
>
> What else get changed in the Xfree drivers?
They have an ati.2 module (same CVSROOT) that you xmkmf against a
compiled XFree tree, then make ; make install, that provides access to
the tuner and v4l playback (MPEG acceleration). A separate kernel module
is required for video capture.
The ati.2 module replaces
/usr/X11R6/lib/modules/drivers/{ati,atimisc,r128,radeon}_drv.o
and adds
/usr/X11R6/lib/modules/multimedia/{bt829,fil236,msp3430,saa7114,tda8425,tda9850,tda9886,theatre}_drv.o
>
> --- Hod McWuff <[EMAIL PROTECTED]> wrote:
> >
> > OK, onward and upward... I'm starting to investigate what it would take
> > to merge the GATOS functionality into the current DRI. I'm sure the
> > XFree side is going to be a pain in the ass, but I'm starting with the
> > kernel modules.
> >
> > The first discrepancy I need cleared up is about driver support. The
> > current DRI source seems to have drivers for:
> > i810,i830,mga,r128,radeon,sis,tdfx
> >
> > Some are split between multiple files, some are in a single file.
> > If there's a document somewhere saying what files have what, then it'd
> > help to see it.
> >
> > The kernel copy also has a 'ffb' driver, which I'm assuming until
> > someone tells me otherwise is an out of date hack.
> >
> > The Gatos copy has the same drivers as the DRI source, but all split
> > amongst many files. I have a feeling the gamma and SIS drivers in this
> > copy are screwed totally anyway - in fact probably only the radeon and
> > r128 drivers from Gatos are relevant anyway, plus any changes in the
> > drm_* files.
> >
> > So, to summarize, I need to know *roughly* what's changed since the
> > Gatos folks forked, in terms of what-moved-where and an idea of any
> > structural changes. I can read the different sources and figure out the
> > code changes myself, but I need to know what I'm looking for.
> >
> > It would seem the best approach is to merge their changes -
> > conceptually, one by one - into the current DRI sources.
> >
> >
> >
> >
> > ---
> > The SF.Net email is sponsored by EclipseCon 2004
> > Premiere Conference on Open Tools Development and Integration
> > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> > http://www.eclipsecon.org/osdn
> > --
> > ___
> > Dri-devel mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/dri-devel
>
>
> =
> Jon Smirl
> [EMAIL PROTECTED]
>
> __
> Do you Yahoo!?
> Yahoo! Finance: Get your refund fast by filing online.
> http://taxes.yahoo.com/filing.html
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: GATOS and DRI merge
On Wed, 2004-02-11 at 01:41, Mike A. Harris wrote: > On Tue, 10 Feb 2004, Hod McWuff wrote: > > >So, to summarize, I need to know *roughly* what's changed since the > >Gatos folks forked, in terms of what-moved-where and an idea of any > >structural changes. I can read the different sources and figure out the > >code changes myself, but I need to know what I'm looking for. > > Presumeably the best way to find out what the GATOS developer(s) > changed, would be to ask them. ;o) That's not what I meant - I mean, what big things have happened in the *DRI* tree since the Gatos fork. I need an idea of that to be able to sort gatos-related changes from simple base-version differences. > > >It would seem the best approach is to merge their changes - > >conceptually, one by one - into the current DRI sources. > > That sounds sane, however some of it may require a bit of > discussion to iron out issues. For example, anything that might > break ABI would be a no-go. If I recall correctly, in the past > there were ABI changing differences, however I have no idea if > that is the case nowadays. At this stage I'm mainly concerned with the kernel module. I've gotten some mixed results so far - including a blind copy of the radeon* files from the gatos version into a copy of the latest DRI sources hand-merged into the 2.6.2 build tree. That one actually runs tuxracer well, but locks the console (not the machine) after about 2 seconds. So, right now my focus is to isolate what the Gatos folks did to get the kernel module to work with their XFree driver. It did under 2.4. The challenge is, the development from ancient->recent, ancient->2.6-compatible, and ancient->gatos-compatible all happened separately, and may have been partially (haphazardly?) merged. > > That said, it would indeed be nice to have GATOS efforts work out > of the box with one single unified driver set. > Darn right. At the moment I'll settle for getting a 2.6.2 kernel module that handles ati.2 drivers on top of XFree 4.3.0... of course the next phase would be to merge the changes in the XFree driver. I suspect that's where many of the incompatibilities will be. I haven't found any changed constants between any of the forks, only changes to #ifdef/#if, minor internal data type and semantic changes, and large blocks of code moving around and morphing somewhat. It's those large blocks I'm trying to understand now. By the way, there are some apparently trivial changes present only in the 2.6.2 copy - apparently someone has added ia-64/x86-64 to a few arch sensitive defines. One of my next few posts will include a patch against the DRI copy of the relevant files. It should be pretty short. I'm trying to take this a step at a time, and the one after that is to merge the DRI kernel driver changes back into my 2.6.2 tree for smoother test building. If y'all like I'll send along a copy of that patch too. Once I get there, and complete the analysis of the gatos changes, I'll write a third patch to merge *that* into 2.6.2 and test the hell out of it. Given the previous merging, that patch should apply to the DRI tree after changing a few of the pathnames in the diff. Once again, the A/V features depend solely on the XFree-level Gatos changes. They work even with no DRM loaded at all. If I can get partial or intermittent 3D to work, via brute hacking at that, then it stands to reason further tweaking of the kernel module will get me to solid 3D performance. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
