Re: [PATCH 5/5] VT binding: Add new doc file describing the feature

Jon Smirl wrote:

On 6/11/06, Antonino A. Daplas [off-list ref] wrote:

quoted

Jon Smirl wrote:

quoted

On 6/10/06, Antonino A. Daplas [off-list ref] wrote:

quoted

My point is: 'Multiple active drivers feature' is a natural

consequence

quoted

quoted

of the evolution of the code, but the only way to take advantage of it
is if we provide a means for the user to use it.  And we are not
providing the means.

Maybe you're misunderstanding me. When I say "we are not providing the
means", I mean "we are definitely not going to provide the means", NOT,
"so we should be providing the means".

I thought about this for a day. The problem is that in-kernel,
single-user, multi-head is not on a good development path. That path
leads to in-kernel, multi-user support which is something I  don't
think we want to do. The current in-kernel, single-user, multi-head
feature is also only partially complete, it does not work on the
majority of VGA hardware in use today.

If you're talking about fbcon, it does work, and not just on the
minority. 

So the question is, what do you want to do about it? If you leave it
in place it complicates new work in the VT layer.  One result being the
complicated sysfs interface that you are building.

The VT subsystem happens to support single user, multi-head, period.
I did not add it, maybe Linus did, who knows. To use it though, besides
hacking the drivers, one needs to provide an interface for it. And I
have emphasized several times that I AM NOT going to provide one.

What I have done is to add a feature to enable us to unload the VT
drivers. If you are planning on replacing the current system with your
own, you will need this feature. So I'm doing you a favor.

You are forced into
doing more in-kernel work to support a feature that may not be on the
long term path.

Look, you're saying that I should only support one driver loaded at
one time.  And I'm doing it by not allowing the users to load more
than one driver at a time. To fully kill this feature, you need to
kill the source which happens to be the VT layer.

If you don't want the VT layer to support more than 1 drivers,
go ahead, rewrite the VT layer.

Another solution would be to build a small user space console system
and use it to drive the secondary heads. That would then allow the
feature to then be removed from the kernel. People would need to
change their scripts but the user level feature will still be there.

Again, go ahead.

This is an example of a case where evolutionary design gets into
trouble. Without knowing the high-level plan for the future of
multi-user, multi-head graphics support in Linux you don't know the
right way to solve this problem.

Nobody is stopping you from rewriting the entire graphics subsystem
from scratch.

You can be as revolutionary with your changes as you want, but you have
to respect one very important thing, kernel to userspace compatibility.

Tony