> I explored the kernel sources dealing with the console emulation,
quoted text
> 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-...
  
quoted text
> 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.

quoted text
> 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.

quoted text
> 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.

quoted text
> 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.

quoted text
> 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.

quoted text
> 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.

quoted text
> 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

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/