Mike Mestnik wrote:
--- Jon Smirl <[EMAIL PROTECTED]> wrote:
There are two types of VTs - text and graphical. It is only practical to
have a
single graphical VT because of the complexity of state swapping a
graphical VT
at VT swap.
Right now we can all-ready run X on multiple VTs and with DRI-reini
Vladimir Dergachev wrote:
A command buffer interface (either mmap()'d buffers or buffers copied
using standardized ioctls) with a common command set might be a
general approach working on all architectures -- not all card drivers
would need to implement all command opcodes, a capability ioctl ca
Keith Whitwell wrote:
Holger Waechtler wrote:
Keith Whitwell wrote:
I don't think this needs to be that complex. We only need a few
working functions in the kernel:
* identification (In particular unique identifier to pass via X to
apps
so they can find the head again)
*
Keith Whitwell wrote:
I don't think this needs to be that complex. We only need a few
working functions in the kernel:
* identification (In particular unique identifier to pass via X to apps
so they can find the head again)
* event reporting (i.e. IRQs and anything else that is relevant)
Jon Smirl wrote:
--- Holger Waechtler <[EMAIL PROTECTED]> wrote:
Why does VT switch have to be in the kernel? I can have multiple xterms
logged
in as different users without kernel support. Why can't VT switching be
implemented as if I was switching between multiple fullscreen xterms
Jon Smirl wrote:
--- Alan Cox <[EMAIL PROTECTED]> wrote:
On Maw, 2004-05-18 at 21:14, Jon Smirl wrote:
So you don't have any problem with pulling VT support out of the kernel?
You need the code to handle video context switches. You also need vt's
because you have multiple security contexts on the P
Ville Syrjälä wrote:
On Fri, May 14, 2004 at 11:40:04AM -0700, Jon Smirl wrote:
--- Ville Syrjälä <[EMAIL PROTECTED]> wrote:
I said OpenGL is the only accelerated API available on Linux. Can you name
another?
DirectFB.
Does DirectFB work on anything beside Matrox now?
It works on any card with a w
Jon Smirl wrote:
--- Alan Cox <[EMAIL PROTECTED]> wrote:
argument for _good_ console support becomes that after boot you run a
graphical user space console app built with OpenGL, antialiased true
When I proposed this a couple of months back both you and Linus called me
insane. I need to go find
Ian Romanick wrote:
Holger Waechtler wrote:
Jon Smirl wrote:
Sharing graphics contexts is not the same thing as allowing two
completely
different device drivers access to the hardware on VT swap. Two
different device
drivers may have completely different contents in all of the
registers, CP
Jon Smirl wrote:
Sharing graphics contexts is not the same thing as allowing two completely
different device drivers access to the hardware on VT swap. Two different device
drivers may have completely different contents in all of the registers, CP
running or not, VRAM and AGP space. With two device
Jon Smirl wrote:
Can you run grub or lilo on these machines?
The equivalent loader is called MILO for SPARC and Yaboot for PowerPC.
The BIOS equivalent is called OpenFirmware and provides a helper API for
mode setting and graphics card initialisation.
There are comments in the drivers which mark
Holger Waechtler wrote:
Jon Smirl wrote:
Can you run grub or lilo on these machines?
The equivalent loader is called MILO for SPARC and Yaboot for PowerPC.
oops -- the SPARC image loader was called SILO. MILO was the mini image
loader for Alpha.
sorry for confusion,
Holger
Alan Cox wrote:
On Iau, 2004-05-06 at 20:57, Jon Smirl wrote:
Simple example, DRM starts GPU coprocessor running. VT swap happens. New user
stops coprocessor. VT swap back to DRM. Now DRM thinks it left the coprocessor
running but that's not true now. DRM and FB conflict when FB is using the
copro
13 matches
Mail list logo
