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
Mike Mestnik wrote:
Let me start of by saying I think you are on the right track and all of
your ideas look good.
--- David Bronaugh [EMAIL PROTECTED] wrote:
Mike Mestnik wrote:
This is vary good.
- To accomidate mergedfb the number of FBs should be allowed to be 0.
How does
Mike Mestnik wrote:
This is vary good.
- To accomidate mergedfb the number of FBs should be allowed to be 0.
How does mergedfb work internally? I don't know.
Alternatively to this, maybe the best way to do this would be to specify
a double-width mode (eg 2048x768) and an extra feature
Let me start of by saying I think you are on the right track and all of
your ideas look good.
--- David Bronaugh [EMAIL PROTECTED] wrote:
Mike Mestnik wrote:
This is vary good.
- To accomidate mergedfb the number of FBs should be allowed to be 0.
How does mergedfb work internally? I
David Bronaugh wrote:
Anyhow... to recap the ideas thus far:
I'm going to elaborate considerably at this point, probably dragging in
lots of stuff no one wants to see in here, etc -- all to try and figure
out what's wanted/needed. The following is about the mode setter itself.
One weird
--- David Bronaugh [EMAIL PROTECTED] wrote:
- Format of messages might be something like device identifier,
resx, resy, colour depth, refresh (optional), extra_params (optional)
Did you talk at all about memory mngmt? For instance when setting a mode
is it needed to have a frame buffer or
Egbert Eich wrote:
David Bronaugh writes:
Egbert Eich wrote:
I don't think you want to call user mode code from inside the kernel.
The kernel could take a passive role and use the mode that a userland
program tells it is set. If all the kernel needs is a linear freambuffer
of size x * y
Mike Mestnik wrote:
--- David Bronaugh [EMAIL PROTECTED] wrote:
- Format of messages might be something like device identifier,
resx, resy, colour depth, refresh (optional), extra_params (optional)
Did you talk at all about memory mngmt? For instance when setting a mode
is it needed
This is vary good.
- To accomidate mergedfb the number of FBs should be allowed to be 0.
- Sharing of FBs should be allowed, for heads on the same card.
- There is no way to ?change?(read as specify) the size of a FB.
- Allocating the second/... FB may be difficult,
- Have mem free as
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
Sottek, Matthew J writes:
Boy, I haven't really been following this too closely, but surely this
sort of thing can be resolved with an extension mechanism or api
versioning?
An extension mechanism is fine for eventually extending the basic
functionality, but a driver writer should
David Bronaugh writes:
Egbert Eich wrote:
I don't think you want to call user mode code from inside the kernel.
The kernel could take a passive role and use the mode that a userland
program tells it is set. If all the kernel needs is a linear freambuffer
of size x * y and depth d
On Maw, 2004-05-11 at 19:48, Egbert Eich wrote:
For the text console to be usable you possibly want to be able to
1. move the fb start address for scrolling
2. to do some basik 2D accel for fast text drawing
Also your framebuffer may not be completely linear.
In which case bank switch is
On Maw, 2004-05-11 at 19:48, Egbert Eich wrote:
For the text console to be usable you possibly want to be able to
1. move the fb start address for scrolling
2. to do some basik 2D accel for fast text drawing
I thought about this a bit more. Let me propose a different viewpoint as
a result.
I thought about this a bit more. Let me propose a different viewpoint
as
a result. That viewpoint is that there is no reason for any
acceleration. Scroll at most.
If the video mode switching is done right and apps can handle graphics
nicely then you need a kernel mode text console at boot, but
Alan Cox writes:
In which case bank switch is needed. Its actually not clear you need
2D accel. Its *nice* but not essential. Its becoming more and more the
case that console mode is the debug/boot interface for a device.
OK.
(I'n not talking about
VGA banking, but it seems like
--- 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
Sottek, Matthew J writes:
I agree. I think we are on the same page. A minimal set of features
is
all that would be part of the defined mode setting API. It is just a
question of if some of the multi-head concepts are generic enough to
be part of that defined set.
That's exactly the
Sottek, Matthew J wrote:
Sottek, Matthew J writes:
I agree. I think we are on the same page. A minimal set of features
is
all that would be part of the defined mode setting API. It is just a
question of if some of the multi-head concepts are generic enough to
be part of that defined set.
That's
Boy, I haven't really been following this too closely, but surely this
sort of thing can be resolved with an extension mechanism or api
versioning?
An extension mechanism is fine for eventually extending the basic
functionality, but a driver writer should not have to wait for consensus
to add
Alan Cox writes:
On Gwe, 2004-05-07 at 21:59, 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
David Bronaugh writes:
Egbert Eich wrote:
I don't only want to see mode selection in user land but also mode
programming.
I keep reiterating the reasons:
1. Mode programming for a number of chips needs to be done thru the BIOS.
Unless one wants to stick a complete x86 emulator
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
Sottek, Matthew J writes:
I agree. I think we are on the same page. A minimal set of features is
all that would be part of the defined mode setting API. It is just a
question of if some of the multi-head concepts are generic enough to
be part of that defined set.
That's exactly the
Around 11 o'clock on May 10, Egbert Eich wrote:
Therefore any application on top of the driver should be prepared that
video mode parameters it cares about (like fb location, fb stride, fb
size, resolution, depth (?) may change underneath its feet.
X can handle any size/location changes, but
Jon Smirl writes:
--- Egbert Eich [EMAIL PROTECTED] wrote:
I fear that we will get a very Linux-centric view on device drivers.
This will leave us with device drivers for Linux and a different ones
Tell me the right non-Linux lists and I will post there too. There have been
Alan Cox writes:
On Iau, 2004-05-06 at 09:39, Egbert Eich wrote:
Furthermore I'd argue that as little as necessary should live in the
kernel space. One thing that - in my opinion - should *not* live in
there is mode detection and initialization.
There is a need to handle some mode
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
Egbert Eich wrote:
I don't only want to see mode selection in user land but also mode
programming.
I keep reiterating the reasons:
1. Mode programming for a number of chips needs to be done thru the BIOS.
Unless one wants to stick a complete x86 emulator into the kernel
this needs to be done
David Bronaugh wrote:
You could simply pass something like this (using an arbitrary text
format) to userspace:
radeon:1024x768
and have it set the best-match mode. The 'radeon' part, of course,
would make sure that the wrong code wasn't used. Likewise, the
userspace program could be fed any
On Llu, 2004-05-10 at 12:46, Egbert Eich wrote:
Yes, we will most likely need OS dependent non-chipset specific wrappers,
but those are cheap to do - a lot cheaper than code dealing directly
with chipset quirks.
Well the minimal kernel side stuff required to make hot plug work
is going to be
Keith Packard writes:
Around 16 o'clock on May 6, Sottek, Matthew J wrote:
1) If the mode setting can be removed from the X server then we can
leverage that module for whatever graphics system is required. Some
times we need an X server, some times we need something more like a
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
On Iau, 2004-05-06 at 09:39, Egbert Eich wrote:
Furthermore I'd argue that as little as necessary should live in the
kernel space. One thing that - in my opinion - should *not* live in
there is mode detection and initialization.
There is a need to handle some mode setup/init in the kernel
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.
Moving mode setting from the Xsever does not necessarily mean it has
to go into the kernel.
I agree. The thing I am worried about (just speaking about the mode
setting
part here) is that we end up with 2 defined APIs. One for the mode
setting,
done as a user library, and another for the kernel
Sottek, Matthew J writes:
I for one have been waiting to see much of the graphics driver moved to
the kernel as well. From a vendor perspective there is quite a lot to be
gained.
1) If the mode setting can be removed from the X server then we can
leverage that module for whatever
Jon Smirl writes:
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
--- Egbert Eich [EMAIL PROTECTED] wrote:
I fear that we will get a very Linux-centric view on device drivers.
This will leave us with device drivers for Linux and a different ones
Tell me the right non-Linux lists and I will post there too. There have been
significant complaints from the Linux
--- Egbert Eich [EMAIL PROTECTED] wrote:
Jon Smirl writes:
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
--- Egbert Eich [EMAIL PROTECTED] wrote:
Jon Smirl writes:
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
Alex Deucher writes:
We also have to consider the trade off between the interfaces a modern
graphics driver needs verses maintianing multi-platform availability.
If linux merges the FB/DRM drivers and moves certain things to the
kernel, there is nothing stopping other OS kernel
I for one have been waiting to see much of the graphics driver moved to
the kernel as well. From a vendor perspective there is quite a lot to be
gained.
1) If the mode setting can be removed from the X server then we can
leverage that module for whatever graphics system is required. Some
times
Around 16 o'clock on May 6, Sottek, Matthew J wrote:
1) If the mode setting can be removed from the X server then we can
leverage that module for whatever graphics system is required. Some
times we need an X server, some times we need something more like a
framebuffer. Putting this in one
1) If the mode setting can be removed from the X server then we can
leverage that module for whatever graphics system is required. Some
times we need an X server, some times we need something more like a
framebuffer. Putting this in one place is a must.
'one place' appears to mean a common
Around 18 o'clock on May 6, Sottek, Matthew J wrote:
I would contend that it is perhaps just a long held fear that mode setting
is too big and complex for the kernel.
With a library API instead of a kernel API, each driver author can choose
precisely where the split belongs.
I think you
Is there a document describing how memory management is handled for the overall
AGP/VRAM space? I've found where texture memory is handled, but who is
allocating space for framebuffers on multi-head cards?
If we were to redo the memory management code to support mesa-solo (ie no X
present) what
--- Jon Smirl [EMAIL PROTECTED] wrote:
Is there a document describing how memory management is handled for
the overall
AGP/VRAM space? I've found where texture memory is handled, but who
is
allocating space for framebuffers on multi-head cards?
Right now the framebuffer is managed in the
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 for the next round
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
On Wed, 5 May 2004, 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
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
96 matches
Mail list logo
