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

["Antonino A. Daplas" <adaplas@gmail.com>]

Jon Smirl wrote:
> On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> Jon Smirl wrote:
>> > On 6/10/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> >> > I see now that you can have tty0-7 assigned to a different console
>> >> > driver than tty8-63.
>> >> > Why do I want to do this?
>> >>
>> >> Multi-head.  I can have vgacon on the primary card for tty0-7,
>> >> fbcon on the secondary card for tty8-16.
>> >
>> > That's what I thought, I couldn't see any other reason. The kernel
>> > doesn't support input from multiple users so multihead can only be
>> > used by a single user.
>> >
>> > Does anyone use single user multihead on current systems? The kernel
>> > doesn't have code in it to initialize secondary VGA cards. What modern
>> > non-VGA hardware does this work on?
>>
>> matroxfb supports multihead and fbcon already has this feature for a
>> long time, ie you can bind /dev/fb0 to tty0-3 and /dev/fb1 to tty4-6.
>> And there are definite users because I happen to break this feature once
>> and I got rained with complaints :-)
> 
> Were those people using this: http://linuxconsole.sourceforge.net/
> Does that work anymore?

No, plain vanilla kernel support this feature. There are lots of
users using the single-user, multi-head feature of fbcon. I've been using it.
The developer of one of the cyber cards also use it.

The main goal of the linuxconsole people is true multiuser, multihead.
One user per card simultaneously.

> 
> This is single a single driver bound to the vt layer. Support for both
> fb0 and fb1 are provided by that single driver. So there may be some
> way to make this work.
> 

Yes, fbcon does intermediate between drivers, so it's not a problem.

>> > If this feature doesn't work on current hardware, could it be dropped?
>> > It would make binding to the vt system much simpler if only one driver
>> > could be bound at a time. Anything we do to make that system simpler
>> > would benefit everyone.
>>
>> You can't drop something that's already in the kernel and has users,
>> well,
>> the binding part at least. What we don't currently have is the
>> fine-grained
>> control and because of the reason's you mentioned, I said that it's
>> for the
>> future.
> 
> There are variations on 'drop' is it dropping if we provide an
> alternate way to achieve the same thing?

Yes, by not providing the user with the option to load and bind
multiple drivers at one time, we are essentially not supporting this
feature.  And that's not a problem. /sys/class/vtconsole/vtcon[x]/bind
handles wholesale binding and unbinding, ie, when you echo 1 > bind,
only that driver, and nothing else, becomes active.

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.

> 
> Does matroxfb know which VC number it is drawing too? If so, we could
> move the mapping between head and VC down to an attribute on the
> matroxfb driver. That would allow the general case of the VC layer
> binding to be simplified to opening a single driver.
> 
> That is not an attribute you want long term on the matroxfb driver,
> but all of this would get more cleanly sorted out when a user space
> implementation happens.

No, matroxfb and any other fbdev drivers has no knowledge whatsoever about
the console.

Tony