> -----Original Message-----
> From: Ryan Underwood [mailto:[EMAIL PROTECTED]
> Sent: 14 June 2004 05:40
> To: [EMAIL PROTECTED]
> Cc: Jon Smirl; Alan Cox; Eric Anholt; Alex Deucher; DRI Devel;
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [Xorg] DRI merging
>
>
> On Sun, Jun 13, 2004 at 08:47:37PM +0100, Matt Sealey wrote:
> >
> > Having a capable accelerated 2D and 3D architecture, something
> > like DirectFB but at more of a "core" and "commercial" level
> > would benefit everyone. Building a single DDX driver to
> > interface with this would simplify support for X - no drivers
> > in the X tree but one! "Console Framebuffers" could be built
> > on top of the same low-level graphics API. In the end losing
> > the 4-driver system for each card would both simplify and
> > optimise the Linux graphics experience.
> [..]
>
> > We need a low-level "kernel" graphics API (much like Windows
> > has, although Windows favours microkernels with high-level
> > kernel functionality, rather than monolithic kernels with
> > user-level functionality.. the two philosophies are at odds)
> > which can perform and accelerate the expected functionality of
> > everything from router to PDA, past desktop to display of
> > remote-served apps.
>
> Careful. I think it is wise to consider the difference between what
> needs to be in the kernel, versus what is convenient to have an API for.
We need something to abstract all the stuff required by 2D and 3D
APIs - be it an X client, or OpenGL, or Qtopia, without having
3 different sets of drivers (one for each).
While I like the idea that Jon has about using OpenGL as the API
for basing X on top of, and while it does have some really quite
good 2D functionality (mainly blitting..) I would consider it
overkill for a lot of devices.
I would plead that we implement Jon's ideas if we have a decent
low-end alternative that is better than a flat framebuffer with
simple BitBlt acceleration :)
> For instance, it is possible to have a mode setting API without it being
> in the kernel -- just have a library that talks to a trusted userspace
> arbiter.
That's fine by me. I guess what we need is a kernelspace HAL that talks
to cards which does a lot better than just mode setting, providing a
big expanse of memory to write to, given the acceleration functionality
of most graphics cards. Simple things like scaled or filtered blits,
drawing simple primitives like lines and rectangles. Then we need some
userspace thing so that if we have hardware that doesn't have a
Radeon 9800 attached to it, we can still get decent graphics performance
and don't have to run a 32MB ROM for X or use Xvesa to try and eke
reduced space and better performance out of it than the fbdev driver
(I love in the man page it says:
Xvesa records the current BIOS mode when it starts and restores that
mode on termination; if the video card has been reprogrammed by another
application, the display will almost certainly be trashed. The alternative
of saving and restoring the complete video card state has proven unreliable
on most video cards.
.. solve it easily by making a decent 2D driver that serves more than X,
and targetting X at it, and making it respect DRI? VESA is a nice
thing as a rule but it doesn't cooperate very well :)
> I just mashed this down so its probably half baked. Any thoughts?
I half-baked agree with you! I am just looking for an accelerated
2D API that isn't permanently in testing and isn't X. The best
place for it, in my opinion, is where DRI and DRM sit now, and
while using OpenGL as the basis for display is a cool idea, not
every Linux device has decent 3D nor requires it, and the
framebuffer device currently "sucks".
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
