> > 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 just avoids
> all the interface design issues ("there are none" ;), but partly because
> everybody involved will have rather different goals. In particular, the
> XFree86 people would have as a goal to keep the differences to a
> user-space implementation minimal, so in that sense you really want to
> have an abstraction that doesn't hide the hardware AT ALL.
>
> NOTE! I'm not saying this is necessarily the best interface or a truly
> great idea. This is just throwing out my thought of the day. I'm nothing
> if not flexible - some people think I change my mind _too_ often ;)
>
> 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, so that we can tell user space that an interrupt happened
> without having to disable the interrupt until the event goes away)
> - serialization (ie a lock) and waiting for events ("engine idle" or
> "command queue less than half full")
> - DMA arbitration and setup.
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 anyways :-)
> Most of the rest (actual IO accesses etc) can be done outside the lowlevel
> crud, once you have the lock. This is also why DMA really _is_ special,
> since it's asynchronous: so it can and does happen independently of the
> lock. But normal synchronous programmed IO doesn't need any real help, and
> there's no point in forcing that into the low-level driver. All the users
> might as well do any direct IO directly.
>
> So the low-level driver wouldn't know about palettes or cursors or any
> "high-level" concepts like that. It would have a few locks to make sure
> that the users that try to access the things don't stop on each other,
> nothing more (maybe the locks themselves would be grouped into "palette
> lock" vs "cursor lock" vs "DMA engine lock" since hardware may be threaded
> enough to allow it, but the point is that the low-level driver wouldn't
> actually _do_ anything, it only allows others to do what they want without
> stomping on each others toes).
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 you
suggest? Would we really gain that much doing this for the case of IO
access only graphics hardware?
> > This looks like just an extension of the current DRI modules, and having
> > things like fbdev stack on top of them...
>
> Quite the reverse, I think. It would be a _shrink_ of the DRI modules.
:-)
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
