But we are rendering to draw fonts, clearing a area of the screen,copyarea.
If we are to have a universal solution it needs to OpenGL. Either that or
mode switching stays in the kernel.
Drawing fonts have _NOTING_ to do with mode switching ! Don't tell me
that you can't make the
On Mon, 10 May 2004, Alan Cox wrote:
On Llu, 2004-05-10 at 17:14, James Simmons wrote:
Speaking of bloat in the kernel. When will the crypto and TCP/IP stack be
moved to userspace. The networking code alone is over 17 megs in size.
Not on my box. Nothing like it. Although to answer that
On Mon, May 10, 2004 at 10:39:50PM +, Nicolas Souchu wrote:
Do apps manage their swap? No. I think the OS should be responsible for
placing the data (vertices, textures, commands) at the right/best place
for the HW 3D engine and the client should only fill virtual memory.
You are mixing things. Mode setting has nothing to do with rendering. OpenGL
is a rendering client. It produces commands sent to the low level kernel
driver and provides a 3D API, but it's not the only one. In this regard,
fbcon is a client too and XFree 2D accel is another one.
But we are
On Mon, May 10, 2004 at 05:14:04PM +0100, James Simmons wrote:
You are mixing things. Mode setting has nothing to do with rendering. OpenGL
is a rendering client. It produces commands sent to the low level kernel
driver and provides a 3D API, but it's not the only one. In this regard,
It's not just bloat, the network code is used millions of times per second. Mode
setting happens occaisonally.
The other problem is memory management. What is going to happen when fbdev
starts setting the mode for both heads? Who is going to mananage the VRAM when
the buffers get resized? OpenGL
I could be wrong, but is not allocating framebuffers and mmaping memory
diffrent than setting up framebuffers and configuring DACs?
--- Jon Smirl [EMAIL PROTECTED] wrote:
It's not just bloat, the network code is used millions of times per
second. Mode
setting happens occaisonally.
The
On Mon, May 10, 2004 at 07:28:37PM +0300, Ville Syrjälä wrote:
[...]
Rendering and mode switching are completely separate issues.
Indeed and I guess we can even use the VESA mode setting and the HW
engine of recent graphic boards concurrently.
The console system is responsible for modesetting
On Mon, May 10, 2004 at 11:29:40AM -0700, Jon Smirl wrote:
It's not just bloat, the network code is used millions of times per second. Mode
setting happens occaisonally.
But necessary some times. I think of oops and debugger.
The other problem is memory management. What is going to happen
It's not just bloat, the network code is used millions of times per second.
Mode setting happens occaisonally.
Using that logic then Sound cards shouldn't be in the kernel at all. I
never use my sound card continuely. I use it as a module. Would it be
acceptable if the mode setting was
On Mon, May 10, 2004 at 10:39:50PM +, Nicolas Souchu wrote:
Do apps manage their swap? No. I think the OS should be responsible for
placing the data (vertices, textures, commands) at the right/best place
for the HW 3D engine and the client should only fill virtual memory.
On Tue, 2004-05-11 at 02:14, James Simmons wrote:
You are mixing things. Mode setting has nothing to do with rendering. OpenGL
is a rendering client. It produces commands sent to the low level kernel
driver and provides a 3D API, but it's not the only one. In this regard,
fbcon is a client
1) Keep mode switching in the kernel. Merge DRI and fb together via
sysfs interface.
2) Ben suggestion that we mount userland inside the kernel during early
boot and use a userland library. If we would use a library then it MUST
be OpenGL. This would be the forced standard on
On Fri, 7 May 2004, Nicolas Souchu wrote:
On Thu, May 06, 2004 at 02:42:14PM -0700, Jon Smirl wrote:
BenH and others have made proposals for pushing the mode setting code into a
user space library in order to reduce kernel footprint and ease debugging. Most
of the code needed for this
On Thu, 6 May 2004, Jon Smirl wrote:
6) What about low memory embedded systems? mesa has an excellent implementation
of OpenGL-ES available for free. http://www.khronos.org/opengles/ It already
supports running out of a dumb framebuffer. OpenGL-ES is small enough that
Qualcomm is putting it
--- Nicolas Souchu [EMAIL PROTECTED] wrote:
A major topic that I missed in the original list was how to handle BSD. DRM
is under the BSD license and FB is GPL. If these two code bases are merged,
what are we going to do about BSD? I don't know the appropriate BSD lists
to post this to so
On Thu, May 06, 2004 at 11:16:39AM -0700, Jon Smirl wrote:
At the X Developers Conference there was a discussion of the issues around
framebuffer and DRI. Theodore Ts'o suggested that I write it up and post it for
discussion. I'm going to try and list all of the issues I've heard from all
On Thu, 6 May 2004, Jon Smirl wrote:
Another topic that I missed was, why did kgi fail and what can we do to avoid
repeating the same path this time around.
IIRC, the main reasons were:
- GGI wanted to do too much at once and was too intruisive (conclusion:
always advance in small steps,
On Thu, May 06, 2004 at 02:42:14PM -0700, Jon Smirl wrote:
--- Nicolas Souchu [EMAIL PROTECTED] wrote:
A major topic that I missed in the original list was how to handle BSD. DRM
is under the BSD license and FB is GPL. If these two code bases are merged,
what are we going to do about
--- James Simmons [EMAIL PROTECTED] wrote:
2) Ben suggestion that we mount userland inside the kernel during early
boot and use a userland library. If we would use a library then it MUST
be OpenGL. This would be the forced standard on all platforms. This
would mean Mesa would be
Around 17 o'clock on May 6, Jon Smirl wrote:
A proposal has been made that OpenGL be promoted as the primary base graphics
API on Linux. Then things like Cairo and the xserver be implemented on top of
OpenGL.
I respectfully disagree with this plan. OpenGL should be the sole API for
--- Keith Packard [EMAIL PROTECTED] wrote:
Around 17 o'clock on May 6, Jon Smirl wrote:
A proposal has been made that OpenGL be promoted as the primary base
graphics
API on Linux. Then things like Cairo and the xserver be implemented on top
of
OpenGL.
I respectfully disagree with
Another topic that I missed was, why did kgi fail and what can we do to avoid
repeating the same path this time around.
IIRC, the main reasons were:
- GGI wanted to do too much at once and was too intruisive (conclusion:
always advance in small steps, not big leaps):
o
But who cares? Do you really intend to keep a common BSD and Linux API/code base?
Offering both solutions under BSD and GPL would be good for suggesting correct
license usage in the embedded world. GPL is too often bypassed.
What about a dual license.
The big reason for merging is memory
24 matches
Mail list logo
