Prev: sound/isa/gus: Remove dead CONFIG_SND_DEBUG_ROM
Next: Support MCP89 hdmi audio
From: Mattia Jona-Lasinio on 3 Aug 2010 08:30
I explored the kernel sources dealing with the console emulation,
framebuffer support and console drivers. I do realize that if we want to fix
all layers in a clean way there is a lot of work to do.

But before going any further I'd like to know some preliminary things.
We are talking about a massive rewrite of code, also including a redesign
of the console layer and (at least) the VGA driver (vgacon) and framebuffer
driver (fbcon), not just a couple of patches to throw in. Do we have the will
to do this job? I mean, I personally do but I don't want to spend time and
effort in something that will be eventually rejected.
Linux has a console system, so we are not in a hurry and we can
think about it. So the main question: how do we proceed?

In case we want to fix this, we should discuss about the design and
implementation
to follow. Presently the struct vc_data contains a lot of information
common to the driver and the
console layers. We should split this struct in order to have a more
transparent interface
between the two parts. Ideally the driver should not know anything
about the console
implementation and the members of the vc_data and it should only take care about
displaying the right thing at the right place.
The vt_struct should represent a physical device, like a monitor or a
LCD display.
Every vt_struct can have one or more vc_data associated to it. All
available vt_struct
are physically refreshed but for every vt_struct, only the currently
visible vc_data on that struct is
actually updated. The others are just "software updated". I don't know
if all this is
the same idea that James was suggesting.

We should avoid fixed size vectors of pointers to these structs by
making them elements
of linked lists.

I agree on the mapping between vc and vt but I'd like to make the
number of vc per vt
an option to be passed at boot time or when init is launched (for
instance), not a
compile time option.

I totally agree that all this must be somewhat separated from the tty
layer, to have
a console without a tty driver, or at least a very light one.

What do you think?

Coming back to LCD-Linux, I will write a module to make it use the
present framework,
basically deactivating the terminal emulation and a bunch of other things, but
keeping the virtual display. Let's see the result ;)

BTW, I currently use lcd-linux with a 4x40 LCD display
which has two controllers onboard. The possibility to drive displays
with more than one
(up to 7) controller onboard is a feature of the present hd44780 driver.

Greetings

Mattia


On Thu, Jul 29, 2010 at 8:39 PM, James Simmons <jsimmons(a)infradead.org> wrote:
>
>> > 3) Invert the VT layer. Currently the console/printk driver is on top of
>> > � �the tty layer. It would be nice to be able to only use a very light
>> > � �weight vt printk without the VT tty on top for embedded platforms.
>>
>> No. printk hits console drivers why may or may not be frame buffer
>> interfaces. Has done for a very long time. Keith Packard has also been
>> doing stuff with crash time oops displays etc over an X display.
>
> Correct. What I mean is have the ability to just register the console
> driver but not the tty driver.
>
>> > 4) Seperate out the VT emulation layer. Related to 3.
>>
>> Separate from what ?
>
> We can still have a basic tty layer without the control characters, think
> do_con_trol in vt.c, junk compiled into the kernel. Make it a options for
> userland to do the vt100 emulation.
>
>> > 5) Multiple independent VT support. Which brings up the question what
>> > � �should the mapping of VCs to a VT look like.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: James Simmons on 4 Aug 2010 10:40

> I explored the kernel sources dealing with the console emulation,
> framebuffer support and console drivers. I do realize that if we want to fix
> all layers in a clean way there is a lot of work to do.

Yes, but the good news is I have been here before. The good news is that
the console code has been abstracted out of most low level drivers so it
makes life much easier this time around. Also today we are starting to
have a greater amount of hardware that can do multi-seat. Another project
dealing with these same issues is

http://plugable.com/2009/11/16/setting-up-usb-multiseat-with-displaylink-on-linux-gdm-up-to-2-20/

> But before going any further I'd like to know some preliminary things.
> We are talking about a massive rewrite of code, also including a redesign
> of the console layer and (at least) the VGA driver (vgacon) and framebuffer
> driver (fbcon), not just a couple of patches to throw in. Do we have the will
> to do this job? I mean, I personally do but I don't want to spend time and
> effort in something that will be eventually rejected.
> Linux has a console system, so we are not in a hurry and we can
> think about it. So the main question: how do we proceed?

Like before. Bit by bit to avoid massive code drops that could break lots
of things. Do certain select changes and push them to Andrew Mortons -mm
tree for wide testing. If we have a successful run then push it main stream.
While in the -mm tree we start the next round of changes. Once the
previous batch from the -mm tree is pushed main stream then push the next
batch of changes.

> In case we want to fix this, we should discuss about the design and
> implementation
> to follow. Presently the struct vc_data contains a lot of information
> common to the driver and the
> console layers. We should split this struct in order to have a more
> transparent interface
> between the two parts. Ideally the driver should not know anything
> about the console
> implementation and the members of the vc_data and it should only take care about
> displaying the right thing at the right place.
> The vt_struct should represent a physical device, like a monitor or a
> LCD display.
> Every vt_struct can have one or more vc_data associated to it. All
> available vt_struct
> are physically refreshed but for every vt_struct, only the currently
> visible vc_data on that struct is
> actually updated. The others are just "software updated". I don't know
> if all this is
> the same idea that James was suggesting.

Yes. That is exactly what I had before.

> We should avoid fixed size vectors of pointers to these structs by
> making them elements
> of linked lists.

I think for our case idrs whould be better.

> I agree on the mapping between vc and vt but I'd like to make the
> number of vc per vt
> an option to be passed at boot time or when init is launched (for
> instance), not a
> compile time option.

I had it as a module option. Now ioctl VT_GETSTATE has a problem with more
tha 16 VCs. So original I made 16 the limitation of VCs per VT.

> I totally agree that all this must be somewhat separated from the tty
> layer, to have
> a console without a tty driver, or at least a very light one.
>
> What do you think?

We pretty much have the same goals.

> Coming back to LCD-Linux, I will write a module to make it use the
> present framework,
> basically deactivating the terminal emulation and a bunch of other things, but
> keeping the virtual display. Let's see the result ;)

Excellent. Let me see the work once your done.

> BTW, I currently use lcd-linux with a 4x40 LCD display
> which has two controllers onboard. The possibility to drive displays
> with more than one
> (up to 7) controller onboard is a feature of the present hd44780 driver.

I can discuss with you off line about getting a hold of one of these
boards.

Okay. I have sync my console git tree up to linus latest tree. I started
last night on the first pass of the console changes. Mostly code cleanup
to make the second round of changes easier to deal with. I will commit
them in the next few days after some testing of course. I will send out a
email once I haev done the commit.

http://git.infradead.org/users/jsimmons/linuxconsole-2.6.git

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: sound/isa/gus: Remove dead CONFIG_SND_DEBUG_ROM
Next: Support MCP89 hdmi audio