Re: [Dri-devel] Three concepts for changing the way video works in Linux

2004-03-15 Thread Alan Cox
On Sul, 2004-03-14 at 20:00, Jon Smirl wrote: > However, I am saying that we need a blend between framebuffer and DRM. Not DRM > bolted on top of framebuffer. You keep imposing policy in the mid layer. How do you know whether you need a blend or not - its card specific. Some cards have 2D/3D sepe

Re: [Dri-devel] Three concepts for changing the way video works in Linux

2004-03-14 Thread Jon Smirl
In previous discussions I never said OpenGL in the kernel, I only said DRM in the kernel. Item four was a very brief recap that left out a lot of detail. The kernel console uses a direct entry point into the DRM driver. This direct entry point has enough state to display no matter what is happening

Re: [Dri-devel] Three concepts for changing the way video works in Linux

2004-03-14 Thread Alan Cox
On Sul, 2004-03-14 at 02:50, Jon Smirl wrote: > 1) Use SysReq to get to kernel console. In this model the kernel console is > always active, it's just hidden. Hit SysReq and it appears. Hit an oops or panic > and it will appear too. The video driver has enough state information to make > this conso

Re: [Dri-devel] Three concepts for changing the way video works in Linux

2004-03-13 Thread Keith Packard
Around 18 o'clock on Mar 13, Jon Smirl wrote: > This is true. Software Mesa can completely emulate everything and just use a > dumb framebuffer for output. The DRM driver for a dumb framebuffer is pretty > simple to write. For the smallest possible system restrict yourself to > OpenGL-ES, statica