[Dri-devel] Re: 3D for SMI WAS: Re: XrandR

2003-10-28 Thread Alex Deucher
--- Robert Woerle <[EMAIL PROTECTED]> wrote: > Hi > > I am now in contact with Keith packard and checked out his latest > stuff .. > it looks promising since there is already a SMI Server there .. > unfortunately it crashes when i use the hw acceleration ...without it > > works .. > > > > Ale

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

2003-10-28 Thread Jon Smirl
--- Philip Brown <[EMAIL PROTECTED]> wrote: > On Tue, Oct 28, 2003 at 02:09:40PM -0800, Jon Smirl wrote: > > Another possible solution to the boot time problem would be to write a > > disposable device driver. The disposable driver would set the mode/EDID and > run > > the console until user mode s

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

2003-10-28 Thread Philip Brown
On Tue, Oct 28, 2003 at 02:09:40PM -0800, Jon Smirl wrote: > Another possible solution to the boot time problem would be to write a > disposable device driver. The disposable driver would set the mode/EDID and run > the console until user mode started; then self destruct. that doesnt sound very a

[Dri-devel] Combined vblank-waiting and buffer swapping

2003-10-28 Thread Felix Kühling
Hi list, I've been thinking about ways to implement a combined "wait for vblank and buffer swap" operation. But somehow I can't get the pieces together partly because I have a pretty vague understanding what the hardware does or can do on a low level. First a short summary of the problem. Current

Re: [Dri-devel] Selecting texture formats (was Re: CVS Update: xc (branch: trunk))

2003-10-28 Thread Ian Romanick
Felix Kühling wrote: The thought of making a generic texture format selection routine had occured to me, too. But it seemed to be too much hardware dependent and I didn't feel like spending much thought on a general solution. Your suggestion is quite general but I'm not sure it would be worth the

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

2003-10-28 Thread Linus Torvalds
On Tue, 28 Oct 2003, James Simmons wrote: > >This is good design for DMA based graphics cards. Unfortunely at present > maybe one fbdev driver actaully uses DMA (i810fb). Almost all fbdev drivers > use IO access :-( Sure we could convert as many as possible to DMA, which I was > planning t

Re: [Dri-devel] Selecting texture formats (was Re: CVS Update: xc (branch: trunk))

2003-10-28 Thread Felix Kühling
The thought of making a generic texture format selection routine had occured to me, too. But it seemed to be too much hardware dependent and I didn't feel like spending much thought on a general solution. Your suggestion is quite general but I'm not sure it would be worth the effort. The glTexIma

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

2003-10-28 Thread Benjamin Herrenschmidt
On Wed, 2003-10-29 at 09:09, Jon Smirl wrote: > Do we really want arbitration between multiple things (FB, X, DRI, etc) all > trying to control the video hardware at a register level? This is like writing > a multitaking system for device drivers. > > Or do we want a single device driver with mul

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

2003-10-28 Thread Jon Smirl
--- Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > The problem is the same. DMA or not DMA, what we want is arbitration. > > When fbdev sets up a mode, the X server mustn't blast 2D engine (either > using PIO or sending DMA commands) etc... So that "arbitration" module > will have to provide

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

2003-10-28 Thread Benjamin Herrenschmidt
>Unfortunely most fbdev drivers set the hardware in IO access mode. Plus > some of the devices lack any kind of DMA support. In this case seperating > out the parts of the driver that program the "high level" stuff leaves > almost nothing left. Would it still be wise to seperate it out as y

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

2003-10-28 Thread James Simmons
> > I see your point about fbdev not beeing the proper interface here. > > > > But then, what would be the relationchip between that low level stuff > > and fbdev ? > > My suggestion, as a starting point, is to really think very rudimentary at > first. A truly _minimal_ thing. Minimal partly bec

[Dri-devel] Re: Multiple drivers for same hardware:, was: DRM and pci_driver conversion

2003-10-28 Thread James Simmons
> Since they have to co-operate some way on the resources _anyway_, they'll > just need to work it out amongst themselves. > > One common case is to have a "arbitration driver" that tends to do the > actual low-level accesses and is one level of abstraction over the > hardware (papers over trivi

Re: [Dri-devel] [PATCH] driconf for pygtk2

2003-10-28 Thread Felix Kühling
Thanks for the patch. This is perfect timing. I worked on a first gtk2 release last weekend and uploaded it a few minutes ago ;-). I had a brief look at your patch. It looks like the first round of changes I made myself. My current version goes a lot further using new gtk2 features like stock icons

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

2003-10-28 Thread Ingo Oeser
On Monday 27 October 2003 16:43, Jeff Garzik wrote: > On Mon, Oct 27, 2003 at 04:37:30PM +0200, Ingo Oeser wrote: > > On Saturday 25 October 2003 21:17, Jeff Garzik wrote: > > > Graphics processors are growing more general, too -- moving towards > > > generic vector/data processing engines. I bet

Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion

2003-10-28 Thread Philip Brown
On Mon, Oct 27, 2003 at 06:13:32PM -0800, Linus Torvalds wrote: >.. > So the thing should really just have > - discovery and attach/detach > - interrupt event notification (and it can't just be "an interrupt >happened" - the interrupt driver actually has to know enough to ACK the >inter