Feature Freeze?

Feature Freeze?

[Antonino Daplas]

Hi,

I believe it's time to finalize what is needed/not needed for the
framebuffer framework:

1. Text mode support?

2. console resizing using fbset (besides stty)?

3. support for unloading of fbcon if modular?

4. driver specified placement of buffers - for putcs method?

5. flexible logo placement/overlayed logo?

6. generic console display rotation?

7. Anything else?

8. feature freeze deadline?

If you think any of the above is essential, useful, bloat, etc, please
say so.  If you think there are features in the present code that needs
to be removed, make it known.

Tony




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Feature Freeze?

[Geert Uytterhoeven]

On 5 Mar 2003, Antonino Daplas wrote:
> I believe it's time to finalize what is needed/not needed for the
> framebuffer framework:

> 1. Text mode support?

Required by at least davem and petr

> 2. console resizing using fbset (besides stty)?

Nice, if it's not too much work.

> 3. support for unloading of fbcon if modular?
> 4. driver specified placement of buffers - for putcs method?
> 5. flexible logo placement/overlayed logo?
> 6. generic console display rotation?

Low priority, IMHO.

> 7. Anything else?

0. Update all drivers

Absolutely required

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Feature Freeze?

[Sven Luther]

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. 

> 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
supposed to work, but i did not (yet) experience it myself, mainly
because non of my graphic cards are yet supported. One point i would
like to see addressed is the ability to share one framebuffer and have
both heads be separate viewports into this same framebuffer. This
means setting a framebuffer with a stride equal to the sum of both's
head resolution and having each head display a subset of it. This would
also include having one head be a mirror of the other and other such
things. This feature and resizing may cause problems though.

> 8. feature freeze deadline?

This would be for fbdev deature freeze, right, not for the drivers ?

BTW, i will no more be able to work on pm3fb, since i just recently
noticed that my nice AGP8 supporting motherboard doesn't accept my
Appian Jeronimo 2000 board. :(((

Friendly,

Sven Luther


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Feature Freeze?

[Antonino Daplas]

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.

> 
> > 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. 
 
> supposed to work, but i did not (yet) experience it myself, mainly
> because non of my graphic cards are yet supported. One point i would
> like to see addressed is the ability to share one framebuffer and have
> both heads be separate viewports into this same framebuffer. This
> means setting a framebuffer with a stride equal to the sum of both's
> head resolution and having each head display a subset of it. This would
> also include having one head be a mirror of the other and other such
> things. This feature and resizing may cause problems though.
> 

Because of the massive rewrite, there wasn't really enough time to add
major feature sets to the framework.  Most of the effort was spent on
bug fixing, cleaning up, and speeding up the code (to justify the
rewrite). 

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.

> > 8. feature freeze deadline?
> 
> This would be for fbdev deature freeze, right, not for the drivers ?
> 

Yes, to give people time to port their drivers.

> BTW, i will no more be able to work on pm3fb, since i just recently
> noticed that my nice AGP8 supporting motherboard doesn't accept my
> Appian Jeronimo 2000 board. :(((
> 

That's too bad :-(

Tony




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Feature Freeze?

[Antonino Daplas]

On Wed, 2003-03-05 at 17:57, Geert Uytterhoeven wrote:
> On 5 Mar 2003, Antonino Daplas wrote:
> > I believe it's time to finalize what is needed/not needed for the
> > framebuffer framework:
> 
> > 1. Text mode support?
> 
> Required by at least davem and petr
> 
> > 2. console resizing using fbset (besides stty)?
> 
> Nice, if it's not too much work.

Adding this shouldn't be too hard.

> 
> > 3. support for unloading of fbcon if modular?

So we just make fbcon permanently loaded unconditionally?  The current
code allows 'rmmod fbcon', but it will freeze the system.

> 0. Update all drivers
> 
> Absolutely required

Yes, which is why we need a feature freeze, so we can spend the rest of
the period on driver updating and bug fixing.

Tony



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Feature Freeze?

[Sven Luther]

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 ?

> > supposed to work, but i did not (yet) experience it myself, mainly
> > because non of my graphic cards are yet supported. One point i would
> > like to see addressed is the ability to share one framebuffer and have
> > both heads be separate viewports into this same framebuffer. This
> > means setting a framebuffer with a stride equal to the sum of both's
> > head resolution and having each head display a subset of it. This would
> > also include having one head be a mirror of the other and other such
> > things. This feature and resizing may cause problems though.
> > 
> 
> Because of the massive rewrite, there wasn't really enough time to add
> major feature sets to the framework.  Most of the effort was spent on
> bug fixing, cleaning up, and speeding up the code (to justify the
> rewrite). 

There is discution about this currently in the DRI/xfree86 mailing list,
and i am facing this also in my xfree86 driver. Maybe for the next
developpment cycle then. I thought that one of the reasons of the
rewrite was to provide easier multi-head and multi-seat support 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.

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.

> > > 8. feature freeze deadline?
> > 
> > This would be for fbdev deature freeze, right, not for the drivers ?
> > 
> 
> Yes, to give people time to port their drivers.

:)))

> > BTW, i will no more be able to work on pm3fb, since i just recently
> > noticed that my nice AGP8 supporting motherboard doesn't accept my
> > Appian Jeronimo 2000 board. :(((
> 
> That's too bad :-(

I will see if i get another board someday, but it will not be in the
immediate future. And it refused to even boot in the pegasos board.

Friendly,

Sven Luther


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Feature Freeze?

[Geert Uytterhoeven]

On Wed, 5 Mar 2003, 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:
> > > > 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.

If your BIOS initializes your graphics card to VGA text mode, vgacon should
work. The same is true for vga16fb.

Vga16fb works on the S3 in my LongTrail, iff I first run a BIOS emulator to
initialize the card to textmode. Never tried vgacon, since the BIOS emulator is
a userspace program and vga16fb can be modular.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Feature Freeze?

[Sven Luther]

On Wed, Mar 05, 2003 at 03:04:57PM +0100, Geert Uytterhoeven wrote:
> On Wed, 5 Mar 2003, 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:
> > > > > 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.
> 
> If your BIOS initializes your graphics card to VGA text mode, vgacon should
> work. The same is true for vga16fb.

It is just a configuration thingy then ? 

> Vga16fb works on the S3 in my LongTrail, iff I first run a BIOS emulator to
> initialize the card to textmode. Never tried vgacon, since the BIOS emulator is
> a userspace program and vga16fb can be modular.

Mmm, but since the emulator is run in OF, this would be ok ?

Do you think that vesafb would work also ?

Friendly,

Sven Luther


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Feature Freeze?

[Geert Uytterhoeven]

On Wed, 5 Mar 2003, Sven Luther wrote:
> On Wed, Mar 05, 2003 at 03:04:57PM +0100, Geert Uytterhoeven wrote:
> > On Wed, 5 Mar 2003, 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:
> > > > > > 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.
> > 
> > If your BIOS initializes your graphics card to VGA text mode, vgacon should
> > work. The same is true for vga16fb.
> 
> It is just a configuration thingy then ? 

Yes. Enable vgacon, and see what happens...

> > Vga16fb works on the S3 in my LongTrail, iff I first run a BIOS emulator to
> > initialize the card to textmode. Never tried vgacon, since the BIOS emulator is
> > a userspace program and vga16fb can be modular.
> 
> Mmm, but since the emulator is run in OF, this would be ok ?

Yes.

> Do you think that vesafb would work also ?

Vesafb requires the boot loader to make BIOS calls before the kernel is
launched. Can you do that from U-Boot (that's your firmware, right)?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Feature Freeze?

[Sven Luther]

On Wed, Mar 05, 2003 at 03:23:36PM +0100, Geert Uytterhoeven wrote:
> On Wed, 5 Mar 2003, Sven Luther wrote:
> > On Wed, Mar 05, 2003 at 03:04:57PM +0100, Geert Uytterhoeven wrote:
> > > On Wed, 5 Mar 2003, 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:
> > > > > > > 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.
> > > 
> > > If your BIOS initializes your graphics card to VGA text mode, vgacon should
> > > work. The same is true for vga16fb.
> > 
> > It is just a configuration thingy then ? 
> 
> Yes. Enable vgacon, and see what happens...

Ok, i will try again once i get the board back, but i think i remember
that i tried it already, and nothing happened.

> > > Vga16fb works on the S3 in my LongTrail, iff I first run a BIOS emulator to
> > > initialize the card to textmode. Never tried vgacon, since the BIOS emulator is
> > > a userspace program and vga16fb can be modular.
> > 
> > Mmm, but since the emulator is run in OF, this would be ok ?
> 
> Yes.
> 
> > Do you think that vesafb would work also ?
> 
> Vesafb requires the boot loader to make BIOS calls before the kernel is
> launched. Can you do that from U-Boot (that's your firmware, right)?

No, it uses smartfirmware. I will have to look into this more, i am not
all that familiar with OF, and the docs i found are not all that easy to
get into.

Friendly,

Sven Luther


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Feature Freeze?

[Antonino Daplas]

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



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Feature Freeze?

[Sven Luther]

On Wed, Mar 05, 2003 at 10:46:37PM +0800, Antonino Daplas wrote:
> > 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.

Mmm, do you know who is working on linuxconsole, and what their plan are ?

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

:)))

Friendly,

Sven Luther


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Feature Freeze?

[Antonino Daplas]

On Wed, 2003-03-05 at 22:49, Sven Luther wrote:
> On Wed, Mar 05, 2003 at 10:46:37PM +0800, Antonino Daplas wrote:
> > > 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.
> 
> Mmm, do you know who is working on linuxconsole, and what their plan are ?

James also. I think the site is http://linuxconsole.sourceforge.net.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Feature Freeze?

[James Simmons]

> 1. Text mode support?

We should remove it. Fbcon is to much bloat for text mode hardware. The 
only driver that does support a text mode matrox. Sparcs do not support 
text mode except for promcon. The issue was was a misunderstanding on teh 
flexiablity of imageblit. The name image blit stirs up this idea of the 
function has to be a place a image in buffer and send it on it way. This 
is not the case. Take a look at cg6.c. Fancy tricks are still possible. 
 
> 2. console resizing using fbset (besides stty)?

Fbcon needs alot of work on this. In theory it shoudl be smart enought to 
handle the small details. 

> 3. support for unloading of fbcon if modular?

It can be done. I used fbcon modular with MDA text mode. I can test the 
fbcon driver. The issue is if we have more than one vga card whcih vga to 
graphics card mapping. 
 
> 4. driver specified placement of buffers - for putcs method?

Working on this. I think it is possible to merge the tileblit stuff with 
the new buffer code.

> 5. flexible logo placement/overlayed logo?

Not so important. More important is fixing fbcon to work with the logo 
code. You can't compile it right now.

> 6. generic console display rotation?

Not so important right now. I removed the poll stuff. using signals is 
better.
 
> 7. Anything else?

The cursor code needs cleanup and documentation. 
 
> 8. feature freeze deadline?

We are very near this. IMO we have two things to work on. The buffer stuff 
and cleaning up the cursor code.



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Feature Freeze?

[James Simmons]

> > 1. Text mode support?
> 
> Required by at least davem and petr

Just Petr. I'm working to seperate the text code out into a matroxcon.c 
file. Needs alot more work tho.

> > 2. console resizing using fbset (besides stty)?
> 
> Nice, if it's not too much work.

:-( I hope to improve fbcon to handle this.
 
> 0. Update all drivers
> 
> Absolutely required

Its getting there. Drivers not ported are:

68328fb.c
S3triofb.c
amifb.c
atafb.c
clgenfb.c
cyber2000fb.c
cyberfb.c
imsttfb.c    <- I have a nearly done driver. The old driver doesn't work 
		on ix86. I tried it. Oh wells.
leofb.c
pm2fb.c
pm3fb.c
pvr2fb.c
retz3fb.c
sun3fb.c
valkyriefb.c
virgefb.c


Many of these drivers have been in state of code rotte for a long time :-( 



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Feature Freeze?

[James Simmons]

> > 2. console resizing using fbset (besides stty)?
> 
> What about dynamic multi-head support ?

Next developement series.

> > 8. feature freeze deadline?
> 
> This would be for fbdev deature freeze, right, not for the drivers ?

Correct. It pretty much is done. The only thing left to do IMO is cursor 
cleanup and docs and more buffer handling stuff.



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Feature Freeze?

[James Simmons]

> So we just make fbcon permanently loaded unconditionally?  The current
> code allows 'rmmod fbcon', but it will freeze the system.

Because no other console takes over. This is not a easy problem to solve.
Which driver takes over when we switch from one console driver to 
another.

> > Absolutely required
> 
> Yes, which is why we need a feature freeze, so we can spend the rest of
> the period on driver updating and bug fixing.

I think we pretty much are there.



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Feature Freeze?

[James Simmons]

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

Only matrox has true text mode. Well also so did vga16fb but we have 
vgacon. 

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

So little time. Also I did this so eventually when the DRI/fbdev merger 
happens it will make life easier for all of us.




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Feature Freeze?

[Geert Uytterhoeven]

On Wed, 5 Mar 2003, James Simmons wrote:
> > 0. Update all drivers
> > 
> > Absolutely required
> 
> Its getting there. Drivers not ported are:
> 
> 68328fb.c
> S3triofb.c
> amifb.c

You can consider amifb done. I haven't sent it in yet, because I have a few
more cleanups to do.

> atafb.c

This one is tricky, since it needs new copyrect/fillrect/imageblit code for
Atari-style interleaved bitplanes. But since Atari is in a bad shape anyway
it's not that important.

> clgenfb.c
> cyber2000fb.c
> cyberfb.c
> imsttfb.c    <- I have a nearly done driver. The old driver doesn't work 
> 		on ix86. I tried it. Oh wells.
> leofb.c

Davem will probably take care of leofb.

> pm2fb.c
> pm3fb.c
> pvr2fb.c
> retz3fb.c
> sun3fb.c

Sun3fb will probably be replaced with the sbuslib stuff Davem wrote for SPARC.

> valkyriefb.c
> virgefb.c

The others cannot be that difficult to port. Most of them are unaccelerated
cfb-style cards.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Feature Freeze?

[James Simmons]

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

Also the new fbdev api was apart of ruby. So all the low level changes 
went in. The upper console layer stuff didn't. This will be for the next 
developement 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.

Correct. This is more of a console thing. I do want to fix up fbcon now 
but only for bug fixes.




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Feature Freeze?

[James Simmons]

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




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Feature Freeze?

[James Simmons]

> > > 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.
> > 
> > Mmm, do you know who is working on linuxconsole, and what their plan are ?
> 
> James also. I think the site is http://linuxconsole.sourceforge.net.

Its me. I have been so busy with fbdev tho I haven't worked on the console 
project. Plus other events in my life (joblessness) has been keeping me 
busy doing other things. I have the old ruby code that worked. So it is a 
matter of porting it over to 2.6 when it comes out. I have been keeping it 
up to date pretty much (2.5.59). 



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Feature Freeze?

[James Simmons]

> On Wed, Mar 05, 2003 at 06:34:45PM +0000, James Simmons wrote:
> > 
> > imsttfb.c    <- I have a nearly done driver. The old driver doesn't work 
> > 		on ix86. I tried it. Oh wells.
> 
> Is this patch in the bk/main patch ? If not, could you send it to me for
> testing purposes? I have some problems under 2.4 and i haven't tried 2.5
> on ppc yet.

I just placed it into the BK repository. I will soon be making a new 
patch. I have a bunch of new changes including some fb_pixmap cleanups.
Fbdev developement has picked up some steam the last few days.




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Feature Freeze?

[Antonino Daplas]

On Thu, 2003-03-06 at 02:37, James Simmons wrote:
> 
> > So we just make fbcon permanently loaded unconditionally?  The current
> > code allows 'rmmod fbcon', but it will freeze the system.
> 
> Because no other console takes over. This is not a easy problem to solve.
> Which driver takes over when we switch from one console driver to 
> another.

I have already a working fbcon module unloading code in my local copy. 
The way it works is like this.  

1. If take_over_console() is called with the "default" flag clear, it
behaves as usual.  It takes only a subset of console numbers but
"conswitchp" still points to the console driver that was loaded at boot
time.

2. If take_over_console() is called with the "default" flag set, it will
replace "conswitchp", but the original value of "conswitchp" is saved.

3.  If take_over_console() with the "default" flag set is called again,
it will fail.  It's not logical to just overwrite "conswitchp" over and
over again.

4. If give_up_console() is called and if the previous
take_over_console() did not overwrite "conswitchp", it proceeds as
usual.

5. If give_up_console() is called and if the previous
take_over_console() overwrote "conswitchp", give_up_console() will also
call take_over_console() but using the saved "conswitchp".

I can then load fbdev and fbcon as modules.  If I "rmmod fbcon", I get
back again to vgacon/dummycon/whatever.  I can then load and unload
different fbdev's and load fbcon at will.

If I want to load mdacon, it will still work on top of fbcon, because
mdacon calls take_over_console() with the "default" flag cleared.

If you need to load other console drivers, then fbcon must be unloaded
first.  This is because the rest of the console drivers call
take_over_console() with the "default" flag set.

I can already load/unload fbcon using vga16fb, rivafb or i810fb as the
backend at will.  Drivers that wish to allow fbcon unloading can define
the xxxfb_release() method.  They can choose to save/restore the state
(if they have a vga core and running as primary), or just define the
xxfb_release method as a dummy (if no vga core or running as secondary).

What do you think?  Any suggestions to improve this (multiple console
drivers for instance)? I would rather have the above, or disallow
unloading, than having the whole console system freeze on me.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Feature Freeze?

[Antonino Daplas]

On Thu, 2003-03-06 at 02:34, James Simmons wrote:
> 
> > > 1. Text mode support?
> > 
> > Required by at least davem and petr
> 
> Just Petr. I'm working to seperate the text code out into a matroxcon.c 
> file. Needs alot more work tho.
> 
> > > 2. console resizing using fbset (besides stty)?
> > 
> > Nice, if it's not too much work.
> 
> :-( I hope to improve fbcon to handle this.
>  

If you're really against using fbset to resize the console, then the
first step is to protect the console from the "dangers" of fbset. 
Secondly, we can have fbcon_resize() validate the mode instead of just
blindly calling fb_set_var().  If it's not valid, then it can also fetch
a working mode for it.  The user can then fine tune the timings using
fbset afterwards.


So, do we allow fbcon to handle mode validating and fetching, or do we
just leave all this to fbdev? At least let's bring out some ideas on how
to go about doing this.  Having a working idea, even if dumb, should
interest other developers in contributing. 

Tony  



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Feature Freeze?

[Antonino Daplas]

On Thu, 2003-03-06 at 02:29, James Simmons wrote:
> 
> > 1. Text mode support?
> 
> We should remove it. Fbcon is to much bloat for text mode hardware. The 
> only driver that does support a text mode matrox. Sparcs do not support 
> text mode except for promcon. The issue was was a misunderstanding on teh 
> flexiablity of imageblit. The name image blit stirs up this idea of the 
> function has to be a place a image in buffer and send it on it way. This 
> is not the case. Take a look at cg6.c. Fancy tricks are still possible. 

If you are to add tileblitting, text mode will be inherently supported.

>  
> > 2. console resizing using fbset (besides stty)?
> 
> Fbcon needs alot of work on this. In theory it shoudl be smart enought to 
> handle the small details. 
> 

Any ideas on how to do this?  I have one in my other mail.

> > 3. support for unloading of fbcon if modular?
> 
> It can be done. I used fbcon modular with MDA text mode. I can test the 
> fbcon driver. The issue is if we have more than one vga card whcih vga to 
> graphics card mapping. 
>  

See my other mail for a proposal on this.

> > 4. driver specified placement of buffers - for putcs method?
> 
> Working on this. I think it is possible to merge the tileblit stuff with 
> the new buffer code.

I have to check your newest patch.

> 
> > 5. flexible logo placement/overlayed logo?
> 
> Not so important. More important is fixing fbcon to work with the logo 
> code. You can't compile it right now.
> 
> > 6. generic console display rotation?
> 
> Not so important right now. I removed the poll stuff. using signals is 
> better.

Yes, I think so too.

>  
> > 7. Anything else?
> 
> The cursor code needs cleanup and documentation. 

I already have stuff in my tree where fbcon allocates cursor resources
per device.  So there's no more static declarations in accel_cursor (and
accel_putcs).  I can submit that if you want.

I also added some locking code for accel_cursor, as well as accel_putcs,
just in case thread-safety is indeed an issue.

I'm also starting to clean up fbcon_cursor and the vbl_handler. 
Ideally, they should also be allocated per device so multi-seat can be
made possible.  It's low-priority right now.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Feature Freeze?

[Carlo E. Prelz]

	Subject: Re: [Linux-fbdev-devel] Feature Freeze?
	Date: gio, mar 06, 2003 at 09:18:07 +0800

Quoting Antonino Daplas (adaplas@pol.net):

> > > > 2. console resizing using fbset (besides stty)?
> > > 
> > > Nice, if it's not too much work.
> > 
> > :-( I hope to improve fbcon to handle this.
> >  
> 
> If you're really against using fbset to resize the console, then the
> first step is to protect the console from the "dangers" of fbset. 
> Secondly, we can have fbcon_resize() validate the mode instead of just
> blindly calling fb_set_var().  If it's not valid, then it can also fetch
> a working mode for it.  The user can then fine tune the timings using
> fbset afterwards.
> 
> 
> So, do we allow fbcon to handle mode validating and fetching, or do we
> just leave all this to fbdev? At least let's bring out some ideas on how
> to go about doing this.  Having a working idea, even if dumb, should
> interest other developers in contributing. 

I see there currently is much activity on the list. I would like to
present the point of view of a heavy framebuffer user: I write
multimedia code for artists, and I generally generate video via the
framebuffer layer, and trusted old matrox cards (from the Millennium
II to the G550). The general process is:

- open the framebuffer unit
- FBIOGET_VSCREENINFO
- change the appropriate values in fb_var_screeninfo
- FBIOPUT_VSCREENINFO
- mmap
- happily write pixels to the memory area

This, multiplied for all the video heads that I use within the same
program (up to 5 per PC, up to now, *including* the console screen -
in this case I control the machine from a network connection).

I am especially in need to change the BPP value (often using 16BPP
mode), and in a couple of occasions (the latest 2 weeks ago) I had to
feed the output of old G200's to large monitors who are only capable
of TV resolution. This means setting the framebuffer to 768x576 (PAL)
and *interlaced*. The framebuffer model that still survives in 2.4
allows me to obtain all this. 

I am not much familiar with all the terminology that is used for the
new layer. Actually, this framebuffer revolution is what keeps me from
enjoying (!) the kernel bleeding edge, as I used to do since almost 10
years ago. 

Can I poll the list's huge knowledge to find out if and how I can
obtain the same result with the new layer?

Thanks a lot in advance...

Carlo 

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Feature Freeze?

[Antonino Daplas]

On Thu, 2003-03-06 at 15:03, Carlo E. Prelz wrote:
> I see there currently is much activity on the list. I would like to
> present the point of view of a heavy framebuffer user: I write
> multimedia code for artists, and I generally generate video via the
> framebuffer layer, and trusted old matrox cards (from the Millennium
> II to the G550). The general process is:
> 
> - open the framebuffer unit
> - FBIOGET_VSCREENINFO
> - change the appropriate values in fb_var_screeninfo
> - FBIOPUT_VSCREENINFO
> - mmap
> - happily write pixels to the memory area

All of the above should still work with the 2.5.  Care was taken to
prevent user application breakage. 

> 
> This, multiplied for all the video heads that I use within the same
> program (up to 5 per PC, up to now, *including* the console screen -
> in this case I control the machine from a network connection).
> 
> I am especially in need to change the BPP value (often using 16BPP
> mode), and in a couple of occasions (the latest 2 weeks ago) I had to
> feed the output of old G200's to large monitors who are only capable
> of TV resolution. This means setting the framebuffer to 768x576 (PAL)
> and *interlaced*. The framebuffer model that still survives in 2.4
> allows me to obtain all this. 

You can still do it for the 2.5, except that the matroxfb is not ported
yet.

> 
> I am not much familiar with all the terminology that is used for the
> new layer. Actually, this framebuffer revolution is what keeps me from
> enjoying (!) the kernel bleeding edge, as I used to do since almost 10
> years ago. 
> 
> Can I poll the list's huge knowledge to find out if and how I can
> obtain the same result with the new layer?
> 

You still can, in general, use the framebuffer as you would use it in
the 2.2.- 2.4 versions.  The main difference is console window
resizing.  As you probably know, in 2.4, resizing was done through the
fbdev layer and then the information is transmitted to the console.  In
2.5, it is currently the opposite way, from the console to fbdev.  The
only application that I know of that is able to do that is stty, which
in its current incarnation has very limited capability.  However, you
can still use fbset to change other parameters (color depth,
acceleration, etc), anything that will not affect the window size.

So the debate really is, should fbset support for console resizing be
reimplemented? Or should console resizing through stty be made more
powerful, at least to create a video mode that is usable, and then just
use fbset later on to fine tune the new video mode? The former is easy,
the latter is saner but more difficult to code.

The matroxfb on the other hand, is the most complicated fb driver
around, so it is perfectly understandable that rewriting the driver for
the 2.5 will take some time.  Temporarily, you can use Petr's patches
until it is ported over to 2.5.  

ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.63.gz


The new layer may not produce something tangible in terms of user
experience (except perhaps for a faster console), but it should pave the
way for better things in the future.

Tony




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Feature Freeze?

[James Simmons]

> I have already a working fbcon module unloading code in my local copy. 
> The way it works is like this.  
> 
> 1. If take_over_console() is called with the "default" flag clear, it
> behaves as usual.  It takes only a subset of console numbers but
> "conswitchp" still points to the console driver that was loaded at boot
> time.
> 
> 2. If take_over_console() is called with the "default" flag set, it will
> replace "conswitchp", but the original value of "conswitchp" is saved.
> 
> 3.  If take_over_console() with the "default" flag set is called again,
> it will fail.  It's not logical to just overwrite "conswitchp" over and
> over again.
> 
> 4. If give_up_console() is called and if the previous
> take_over_console() did not overwrite "conswitchp", it proceeds as
> usual.
> 
> 5. If give_up_console() is called and if the previous
> take_over_console() overwrote "conswitchp", give_up_console() will also
> call take_over_console() but using the saved "conswitchp".
> 
> I can then load fbdev and fbcon as modules.  If I "rmmod fbcon", I get
> back again to vgacon/dummycon/whatever.  I can then load and unload
> different fbdev's and load fbcon at will.
> 
> If I want to load mdacon, it will still work on top of fbcon, because
> mdacon calls take_over_console() with the "default" flag cleared.
> 
> If you need to load other console drivers, then fbcon must be unloaded
> first.  This is because the rest of the console drivers call
> take_over_console() with the "default" flag set.
> 
> I can already load/unload fbcon using vga16fb, rivafb or i810fb as the
> backend at will.  Drivers that wish to allow fbcon unloading can define
> the xxxfb_release() method.  They can choose to save/restore the state
> (if they have a vga core and running as primary), or just define the
> xxfb_release method as a dummy (if no vga core or running as secondary).
> 
> What do you think?  Any suggestions to improve this (multiple console
> drivers for instance)? I would rather have the above, or disallow
> unloading, than having the whole console system freeze on me.

Send me the patch. I like to have this support. As for multiple console 
support. Well that will just be nasty. Nothing we can do about it.



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Feature Freeze?

[James Simmons]

> Secondly, we can have fbcon_resize() validate the mode instead of just
> blindly calling fb_set_var().  If it's not valid, then it can also fetch
> a working mode for it.  The user can then fine tune the timings using
> fbset afterwards.

But fb_set_var does call teh check_var routine. That is why a fb_set_var 
in fbcon_resize instead of just calling the set_par routine. 

> So, do we allow fbcon to handle mode validating and fetching, or do we
> just leave all this to fbdev? At least let's bring out some ideas on how
> to go about doing this.  Having a working idea, even if dumb, should
> interest other developers in contributing. 

That should be done by the low level driver not fbcon.



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Feature Freeze?

[James Simmons]

> If you are to add tileblitting, text mode will be inherently supported.

If I do all three tileblitting functions. Personally I think we just need 
tileblit. 
 
> > > 2. console resizing using fbset (besides stty)?
> > 
> > Fbcon needs alot of work on this. In theory it shoudl be smart enought to 
> > handle the small details. 
> > 
> 
> Any ideas on how to do this?  I have one in my other mail.

I think it is coming together quite well this last week.

> > > 3. support for unloading of fbcon if modular?
> > 
> > It can be done. I used fbcon modular with MDA text mode. I can test the 
> > fbcon driver. The issue is if we have more than one vga card whcih vga to 
> > graphics card mapping. 
> >  
> 
> See my other mail for a proposal on this.

I will give it a try.

> > > 4. driver specified placement of buffers - for putcs method?
> > 
> > Working on this. I think it is possible to merge the tileblit stuff with 
> > the new buffer code.
> 
> I have to check your newest patch.

Its in the BK tree. 

> > Not so important. More important is fixing fbcon to work with the logo 
> > code. You can't compile it right now.

It works now. It doesn't compile tho if you disable the logo code and havd 
fbcon set.

> > > 6. generic console display rotation?
> > 
> > Not so important right now. I removed the poll stuff. using signals is 
> > better.
> 
> Yes, I think so too.

Actaully the way the pixmap code came out I think we can implement the 
rotation stuff via the pixmap hooks.

> I already have stuff in my tree where fbcon allocates cursor resources
> per device.  So there's no more static declarations in accel_cursor (and
> accel_putcs).  I can submit that if you want.

I seen it. I added parts. I'm going to use the upper console layer to get 
ride of the static variables for the cursor stuff.

> I also added some locking code for accel_cursor, as well as accel_putcs,
> just in case thread-safety is indeed an issue.

Added to BK tree already.

> I'm also starting to clean up fbcon_cursor and the vbl_handler. 
> Ideally, they should also be allocated per device so multi-seat can be
> made possible.  It's low-priority right now.

I seen that. The VBL handlers should be removed from fbcon.c and placed in
there respected drivers. I think that each driver should register its own 
VBL handler. Then inside the handler update the cursor. This way all we 
need is a timer for each display that blinks the cursor. 



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en