Jon Smirl wrote:
I attached the slides from my kernel summit presentation. The major
change is that Linus does not want a new VT state. Instead we should
open a new VT, switch it to VT_GRAPHICS, and then refuse to
acknowledge VT swap requests. Dave Airlie did another presentation on
mode setting and suspend/resume.
The simple overview: goal is to get rid of the current VT swap system
but replace it with something that looks just like it. To do this the
console is split into two halves.
1) kernel console - it is as simple as possible and always guaranteed
to work. It is simpler than current fbconsole. It automatically uses
whatever mode is set on the monitor. There is only one kernel console
- no VTs.
2) user console - implements your normal VTs. Fully accelerated,
supports Unicode, etc.
No one was really against restructuring the consoles. There was
support for a console that always works even when something like X is
running.
I am really interested in this, and want to help (with code, once
architectural issues are solved). But there is a question:
How should applications that currently rely upon a kernel VT system being
present (e.g. Xorg, MPlayer, SDL) be modified? (I mean, is there any proposed
API for hunting for a free userspace VC?)
--
Alexander E. Patrakov
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
On 7/28/05, Alexander E. Patrakov [off-list ref] wrote:
Jon Smirl wrote:
quoted
I attached the slides from my kernel summit presentation. The major
change is that Linus does not want a new VT state. Instead we should
open a new VT, switch it to VT_GRAPHICS, and then refuse to
acknowledge VT swap requests. Dave Airlie did another presentation on
mode setting and suspend/resume.
The simple overview: goal is to get rid of the current VT swap system
but replace it with something that looks just like it. To do this the
console is split into two halves.
1) kernel console - it is as simple as possible and always guaranteed
to work. It is simpler than current fbconsole. It automatically uses
whatever mode is set on the monitor. There is only one kernel console
- no VTs.
2) user console - implements your normal VTs. Fully accelerated,
supports Unicode, etc.
No one was really against restructuring the consoles. There was
support for a console that always works even when something like X is
running.
I am really interested in this, and want to help (with code, once
architectural issues are solved). But there is a question:
How should applications that currently rely upon a kernel VT system being
present (e.g. Xorg, MPlayer, SDL) be modified? (I mean, is there any proposed
API for hunting for a free userspace VC?)
It depends on how the app is implemented. If the app directly messes
with the hardware it will have to be significantly changed. For
example there is a new Xserver under development that plays by the new
rules. The old Xorg server will not work once you enter the new state.
This is probably true for SDL too.
The main goal of the new system is to weed out old apps that directly
mess with the hardware. These apps will need to be rewritten to work
in the new model. The fbdev, DRM and OpenGL/EGL APIs will be available
in the new system.
Standalone SDL would easily port to OpenGL/EGL. EGL is an OpenGL
extension that allows mode setting and screen control. Using
OpenGL/EGL will hide the changes from you.
The new system allows two users, each logged on to a separate head of
a single card. You can't running an old app that messes with the
hardware in this case. The old app would kill both users.
This is a complicated change in the VT system. It will probably be
several years before everything is transitioned.
--
Alexander E. Patrakov
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
On 7/28/05, Alexander E. Patrakov [off-list ref] wrote:
Jon Smirl wrote:
quoted
I attached the slides from my kernel summit presentation. The major
change is that Linus does not want a new VT state. Instead we should
open a new VT, switch it to VT_GRAPHICS, and then refuse to
acknowledge VT swap requests. Dave Airlie did another presentation on
mode setting and suspend/resume.
The simple overview: goal is to get rid of the current VT swap system
but replace it with something that looks just like it. To do this the
console is split into two halves.
1) kernel console - it is as simple as possible and always guaranteed
to work. It is simpler than current fbconsole. It automatically uses
whatever mode is set on the monitor. There is only one kernel console
- no VTs.
2) user console - implements your normal VTs. Fully accelerated,
supports Unicode, etc.
No one was really against restructuring the consoles. There was
support for a console that always works even when something like X is
running.
I am really interested in this, and want to help (with code, once
architectural issues are solved). But there is a question:
How should applications that currently rely upon a kernel VT system being
present (e.g. Xorg, MPlayer, SDL) be modified? (I mean, is there any proposed
API for hunting for a free userspace VC?)
If you are really interested the first place to help is getting the
new Xegl Xserver working. It is discussed on the xorg, dri-devel and
dri-egl mailing lists at freedesktop.org.
We probably won't start working on the other console pieces until the
Xserver is ready. Without the Xserver it is hard to do anything in the
new environment.
--
Alexander E. Patrakov
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf