Re: [Linux-fbdev-devel] Feature Freeze?

[James S. <jsi...@in...>]

> And do you think there is a chance of standard vgacon working on a ppc
> board ? 

I have done some work on vgacon but it needs alot of work. Vgacon is also 
broken on many platforms. I personally liek to see vgacon independent of 
the BIOS and more portable. I'm working on this.

> I thought that the new API, separating the fbcon layer from the fbdev
> drivers would add support for this more easily. 

You can. I did this because there are embedded devices coming out with two 
framebuffers. They open like a book and they have two touchscreens but no 
keybaords. Here VTs make no sense. So you can compile in input support for 
the touchscreen and just fbdev support. Then just write your app. 

> What about multi-seat, with two full consoles,
> with mouse and keyboard for each ?

That requires massive surgery for the console layer. 

> I thought that one of the reasons of the
> rewrite was to provide easier multi-head and multi-seat support though.

Its is for the long run. The changes required for this where huge. You had 
to have one input api. A clean console independent fbdev api. Then you can 
touch the core console code. When 2.7/3.1 comes around we can add the new 
console code in. Not much work there then. 

> What i think would be nice is to be able to separate the framebuffer
> setup (where we write to) from the dac/dp output to the monitors, and
> when we outport this to the higher level apps, we export them
> separatedly. This way X drivers can use one huge framebuffer, with DRI
> enabled to render on the framebuffer, and enable arbitrary setting of
> viewports into this framebuffer, with eventual scaling or other such
> stuff. And fbcon could then easily use two viewports into the same
> framebuffer to do dual-head/dual-seat. Overlays (for cursor and/or video)
> would be linked to the monitor outputs and not the framebuffer.
> 
> But maybe it is too late for this, good ideas for 2.7.x/3.1.x or
> whatever it will be named though, together with a framebuffer/agp memory
> management scheme which would be common to DRI, fbdev and X, and would
> reside in the drm module.

Next developement cycle. This is huge amount of work as well.