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

Jon Smirl
2006-06-11T20:59:15Z

On 6/11/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> Jon Smirl wrote:
> > On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> >> My point is: 'Multiple active drivers feature' is a natural consequence
> >> 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.

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. You are forced into
doing more in-kernel work to support a feature that may not be on the
long term path.

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.

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.

--
Jon Smirl
jonsmirl@gmail.com