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

[Antonino D. <ad...@po...>]

On Wed, 2003-03-05 at 21:43, Sven Luther wrote:
> On Wed, Mar 05, 2003 at 08:46:52PM +0800, Antonino Daplas wrote:
> > On Wed, 2003-03-05 at 19:05, Sven Luther wrote:
> > > On Wed, Mar 05, 2003 at 04:26:04PM +0800, Antonino Daplas wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > I believe it's time to finalize what is needed/not needed for the
> > > > framebuffer framework:
> > > > 
> > > > 1. Text mode support?
> > > 
> > > Would this work also on arches which don't traditionnaly do text mode ?
> > > Like ppc for example. 
> > 
> > Yes, pixel-based drawing is still the default.  It's only for drivers
> > (matrox and sbus) where it might be needed.
> 
> And do you think there is a chance of standard vgacon working on a ppc
> board ? I have a pegasos powerpc/pop based board, and its OF use a x86
> emulator to boot the card into vga textmode. matroxfb is broken on it
> last i tried, and radeonfb was not uptodate in the kernel that was
> provided, and i there is problems with other fbdevs also, so it
> would be nice if it was possible to use vgacon on such hardware, until
> the fbdevs are fixed, but it is a bit hard to fix things without a
> working console.
> 
> > > > 2. console resizing using fbset (besides stty)?
> > > 
> > > What about dynamic multi-head support ?
> > > 
> > > > 7. Anything else?
> > > 
> > > Well, what is the exact status of mult-head and multi-seat ? It is
> > 
> > If you mean one card with multiple heads, that will need driver-specific
> > support. 
> 
> I thought that the new API, separating the fbcon layer from the fbdev
> drivers would add support for this more easily. I guess it would be easy
> for the Appian Jeronimo 2000 board, which has two permedia3 chips, and
> thus can be seen as two separate devices. Cards with two ramdacs per
> chip, like the G400, the later radeon's and most recent cards would need
> driver level support, that is understandable, but is all there for fbcon
> to take advantage of it ? What about multi-seat, with two full consoles,
> with mouse and keyboard for each ?
> 

This was one of the goals of the Ruby project, but I think it's mostly 
the input layer that got into the kernel. 

Fbcon needs to be cleaned up, a lot. It still implements the "current
console or foreground console" concept (only one console active at a
time).  Also, this is more of a job for linuxconsole than fbdev.  I may
be wrong though.

> > It does have one benefit though, the newer code should make it easier to
> > add an infrastructure on top of fbdev, such as xinerama-style support. 
> > But this will be in the future.
> 
> Mmm, I don't know if there is really a point to this, are there really
> all that much applications which do xinerama-like things on top of fbdev ?
> I rather thought that more higlevel userland apps would be doing this.
> like either xfree86 with chip-specific drivers or fbdev drivers, or
> directfb or something such.
> 

You're right, xinerama is mainly user-app.

Tony