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
interrupt,
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 you'll
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
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 trivial
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 because that
--- 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 the
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
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
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 to do
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
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.
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
--- 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 started;
--- 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 ..
Alex Deucher
14 matches
Mail list logo
