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-reinit
These seem to be good requierments of any conclusion that is reached.
1. On the fly context switching.
1a. Even if the GART is %100 full for the new/old context.
1b. Even if the VideoRam is %100 full for the new/old context.
1c. Even if the Card(s) are locked for exlusive use.
1d. Even if add
On Gwe, 2004-05-21 at 17:48, Jon Smirl 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.
Could have fooled me. I can switch between multiple DRI using X servers
and
Alan Cox wrote:
On Gwe, 2004-05-21 at 17:48, Jon Smirl 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.
Could have fooled me. I can switch between multiple DRI using X
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Alan Cox wrote:
On Gwe, 2004-05-21 at 17:48, Jon Smirl 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.
Michel Dnzer wrote:
On Sat, 2004-05-22 at 01:45, 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
Can the GART apperture be moved physicaly? I don't think a logical move
would be much help.
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Michel Dänzer wrote:
On Sat, 2004-05-22 at 01:45, Mike Mestnik wrote:
--- Jon Smirl [EMAIL PROTECTED] wrote:
There are two types of VTs - text and
Yes the GART swap, if it needs to be done with memcpys, should be posponed
untill the user has SOME type of interface. Thats the important thing,
allowing the user to interact is above hardware based rendering.
I never liked the way GLapps froze when they where not on the current VT.
I think the
Yes the GART swap, if it needs to be done with memcpys, should be posponed
untill the user has SOME type of interface. Thats the important thing,
allowing the user to interact is above hardware based rendering.
I never liked the way GLapps froze when they where not on the current VT.
I think the
Well, X11 protocol was designed rather well.
kind of overkill for this purpose, not? A command set that allows using the
opcodes easily to jump directly into the verification function table and if
the request is allowed into the function table that contains the i/o
programming routines might
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)
* event
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
On Mer, 2004-05-19 at 20:49, Jon Smirl wrote:
A rep from the SELinux group was at the Xdev conference. They are starting a
project to verify X server.
Verifying the X server isnt practical. Its large and its reliant on
hardware behaviour for hardware where nobody has documentation and where
the
On Iau, 2004-05-20 at 01:55, Jon Smirl wrote:
It's not going to allow multiple login prompts on different VTs on the same
head.
In which case its completely useless. You might want to get away from a
kernel virtualisation of video services but you just can't do it. You
can pull a *lot* of the
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.
How about this for a new way to look at the problem?
Current text VTs call into the kernel and ask it to draw on the video
--- 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-reinit can
run GL
On Sat, 2004-05-22 at 01:45, 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
1. Add a device independent version. Device independent code could be
written that would test the version number the same way device dependent code
does today. The drawback is that in order to advertise version X.N
functionality, you also have to adverteise version [1.1, 1.N-1]
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)
* mode setting
*
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
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)
* event reporting (i.e. IRQs and
Everything else is best done as device-specific with the true API
belonging in user-space.
Comments ?
Just to say that bitblt covers a lot of ground; ie. there's lots of varieties
of blits with quite a few parameters - are you talking about just a simple
copy within a single framebuffer, or
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 can return a bitfield
of
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 PC
--- 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? I
guess I
don't see
--- Holger Waechtler [EMAIL PROTECTED] wrote:
hmmm, it's not clear to me how this concept would allow real multiple
user logins at the same time like it is common -- you can rum multiple
X11 instances on multiple VTs and every new user is able to hit SAK
without killing other user's
Jon Smirl wrote:
--- Alan Cox [EMAIL PROTECTED] wrote:
s/OpenGL/Some drawing library/ - providing its using the kernel
interfaces we don't care what. (eg the bogl console driver is very
small, the opengl one would probably be rather larger and nicer)
I wasn't thinking that the kernel interface was
--- Ian Romanick [EMAIL PROTECTED] wrote:
IMO, this is a long standing problem with the DRM. The main issue is
that there's only one version number associated with each DRM module.
What's needed is a device independent version and a device dependent
version. In a sense, it needs something
On Mer, 2004-05-19 at 01:35, Jon Smirl 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? I guess I
don't see why
On Maw, 2004-05-18 at 23:27, Keith Packard wrote:
No thoughts to supporting multiple sets of VTs, one per physical device
then?
That would be nice but how much of that needs to be kernel side. Not a
lot I suspect.
---
This SF.Net email is
--- Alan Cox [EMAIL PROTECTED] wrote:
On Mer, 2004-05-19 at 01:35, Jon Smirl 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
On Mer, 2004-05-19 at 20:30, Jon Smirl wrote:
xserver draws each app into it's own pbuffer. The individual apps don't have
access to the main framebuffer. A properly designed xserver should be free from
the screen scraping attack too. The DRM module will have to make sure you can't
read
A rep from the SELinux group was at the Xdev conference. They are starting a
project to verify X server.
--- Alan Cox [EMAIL PROTECTED] wrote:
On Mer, 2004-05-19 at 20:30, Jon Smirl wrote:
xserver draws each app into it's own pbuffer. The individual apps don't have
access to the main
On Wed, 2004-05-19 at 11:25, Ian Romanick wrote:
Jon Smirl wrote:
--- Alan Cox [EMAIL PROTECTED] wrote:
s/OpenGL/Some drawing library/ - providing its using the kernel
interfaces we don't care what. (eg the bogl console driver is very
small, the opengl one would probably be rather larger
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? I
guess I
--- Holger Waechtler [EMAIL PROTECTED] wrote:
hmmm, it's not clear to me how this concept would allow real multiple
user logins at the same time like it is common -- you can rum multiple
X11 instances on multiple VTs and every new user is able to hit SAK
without killing other user's
--- Alan Cox [EMAIL PROTECTED] wrote:
On Maw, 2004-05-18 at 01:13, Jon Smirl wrote:
1) Boot console. This is implement via BIOS support. It is used to printk a
processor initialization failure or failure to find initramfs. Some embedded
systems might have to build one of these into the
On Maw, 2004-05-18 at 21:14, Jon Smirl wrote:
I was thinking ptmx/pty, or do you want to use tty? With ptmx/pty you can get
rid of the tty devices.
You need the tty devices for the boot/kernel console and the code
specifc to them is tiny. For the usermode one its clearly ptmx/pty
I wasn't
Around 19 o'clock on May 18, Alan Cox wrote:
VT switch is easy however. DRI+X already handles that, and we never have
two people using the VT at once. Its one device, multiple handles only
one currently active - like many other drivers
No thoughts to supporting multiple sets of VTs, one per
On Iau, 2004-05-13 at 01:58, 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
--- Alan Cox [EMAIL PROTECTED] wrote:
On Iau, 2004-05-13 at 01:58, 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
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
--- 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 those posts.
This
Jon Smirl writes:
Can you run grub or lilo on these machines?
Also, these is no rule saying a device driver can't have several tables of _init
register values that can be used to set the mode on a primary monitor at boot. I
would just like to see all of the code that does DDC decoding
Also, these is no rule saying a device driver can't have several tables of _init
register values that can be used to set the mode on a primary monitor at boot. I
would just like to see all of the code that does DDC decoding and modeline
computations moved to user space. When you add up that
On Sul, 2004-05-09 at 17:45, Jon Smirl wrote:
Also, these is no rule saying a device driver can't have several tables of _init
register values that can be used to set the mode on a primary monitor at boot. I
would just like to see all of the code that does DDC decoding and modeline
Can you run grub or lilo on these machines?
Also, these is no rule saying a device driver can't have several tables of _init
register values that can be used to set the mode on a primary monitor at boot. I
would just like to see all of the code that does DDC decoding and modeline
computations
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
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
Egbert Eich wrote:
However chipset probing/display device probing and mode setting isn't
required to live in kernel space. Portability and system stability
arguments speak against it. In fact only Apple MAC users seem to
advocate this idea to be able to an initial video mode on their
systems.
Jon Smirl wrote:
I'm putting together a document for Kernel Summit that describes the issues
around graphics device drivers. The kernel developers are currently making first
pass comments on it. As soon as I fold their comments in I'll post it to
fb-dev, dri-dev and wherever else is appropriate
--- Ian Romanick [EMAIL PROTECTED] wrote:
That's not entirely true. I made a proposal last February (search the
dri-devel archives for texmem-0-0-2) that used a combination of
in-kernel and user-space. Basically, the memory management mechanism is
implemented in-kernel, but the policy is
Jon Smirl wrote:
--- Ian Romanick [EMAIL PROTECTED] wrote:
That's not entirely true. I made a proposal last February (search the
dri-devel archives for texmem-0-0-2) that used a combination of
in-kernel and user-space. Basically, the memory management mechanism is
implemented in-kernel, but
53 matches
Mail list logo
