From: Jon Smirl <jonsmirl@gmail.com>
To: Brian Paul <brian.paul@tungstengraphics.com>
Cc: Xserver development <xorg@freedesktop.org>,
fbdev <linux-fbdev-devel@lists.sourceforge.net>,
DRI-EGL <dri-egl@lists.freedesktop.org>
Subject: Re: EGL_MESA_screen_surface proposal
Date: Tue, 15 Mar 2005 11:28:33 -0500 [thread overview]
Message-ID: <9e4733910503150828ecf5a1b@mail.gmail.com> (raw)
In-Reply-To: <4236FC79.5000909@tungstengraphics.com>
I cc'd this onto the other lists to get more opinions. Maybe we can
turn this into a workable concept.
On Tue, 15 Mar 2005 08:17:13 -0700, Brian Paul
<brian.paul@tungstengraphics.com> wrote:
> Perhaps the eglShowSurface() and eglScreenMode() functions should be
> combined so the new surface and new display mode can be validated
> together. That way, the undefined state between setting the new
> surface and new mode can be avoided.
In one of the other threads (on x.org&fbdev) people are arguing that
mode setting and surface selection should not be combined. I think
their concern comes from mode setting code is in fbdev and their
allocation code is somewhere else.
The problem is that fbdev doesn't have a memory manager so it has no
concept of where the surfaces are. It relies on some other piece of
software manage the surfaces. Maybe we should teach fbdev about the
concept of surfaces.
Initially the radeonfb dev driver would only know about two surfaces,
one for each head. Name them default. Setting the mode on either head
would have an implied parameter surface=default. surface=default is a
special case since the surface type is mutable into what ever the mode
requires.
fbdev could then be extended to have a plugable API for enumerating
surfaces. DRM would add other surfaces to this list each with a name.
Now you can set the mode and specific surface=my_new_surface. If the
mode and surface are incompatible you get an error.
Another twist would be to set the mode just by specificing the surface
name. That would cause a mode to be picked that can display the
surface.
--
Jon Smirl
jonsmirl@gmail.com
next parent reply other threads:[~2005-03-15 16:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4236F0A8.4000004@tungstengraphics.com>
[not found] ` <9e47339105031507064a68630f@mail.gmail.com>
[not found] ` <4236FC79.5000909@tungstengraphics.com>
2005-03-15 16:28 ` Jon Smirl [this message]
2005-03-15 16:36 ` EGL_MESA_screen_surface proposal Michel Danzer
2005-03-16 4:30 ` Jon Smirl
2005-03-16 4:44 ` Vladimir Dergachev
2005-03-16 15:04 ` Brian Paul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9e4733910503150828ecf5a1b@mail.gmail.com \
--to=jonsmirl@gmail.com \
--cc=brian.paul@tungstengraphics.com \
--cc=dri-egl@lists.freedesktop.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=xorg@freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).