linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] Advice sought on approach.

[Geert U. <ge...@li...>]

On 5 Mar 2003, Alex Bennee wrote:
> On Wed, 2003-03-05 at 13:26, Antonino Daplas wrote:
> > On Wed, 2003-03-05 at 20:37, Alex Bennee wrote:
> > > Having read the fb-dev docs on www.linux-fbdev.org I'm a little confused
> > > as to what actually puts data into the framebuffer. Most of the
> > > framebuffer drivers just seem to deal with resolution and colourmap
> > > settings. Is this a case of having to re-implement the fbcon drivers as
> > > well to get what I want?
> > The pixels placed to the framebuffer are all done in the fbcon-cfb*.c
> > modules (if you use the generic functions).  This is for standard
> > character drawing.  The logo is drawn indepently (fbcon_show_logo in
> > fbcon.c).  User applications write directly to the framebuffer via the
> > mmap() function.
> 
> I think I understand now. When the fb_set_disp function is called I fill
> in the display struction with the console display operations. I've got
> two choices now:
> 
> 1. Create a new fbcon_cfb16 file which notes the changed areas before
> calling the generic function.
> 
> 2. Patch the current fbcon_cfb16 (with a CONFIG option) to add the
> change tracking facility in a more generic way.
> 
> I guess the question is is it worth doing 2 as a potential upstream
> patch? Or is this sort of thing so specialised I should just keep it all
> packed in my own fb driver?
> 
> I guess I can't easily implement user access via mmap without uploading
> the entire screen, which I'm not intending to do anyway because all I
> really need is the console support - at least for now.

If all you need is console support, please take a look at
drivers/video/newport_con.c, for the SGI Indy.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

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

Re: [Linux-fbdev-devel] Advice sought on approach.

[Alex B. <ker...@be...>]

On Wed, 2003-03-05 at 13:26, Antonino Daplas wrote:
> On Wed, 2003-03-05 at 20:37, Alex Bennee wrote:
> > Having read the fb-dev docs on www.linux-fbdev.org I'm a little confused
> > as to what actually puts data into the framebuffer. Most of the
> > framebuffer drivers just seem to deal with resolution and colourmap
> > settings. Is this a case of having to re-implement the fbcon drivers as
> > well to get what I want?
> The pixels placed to the framebuffer are all done in the fbcon-cfb*.c
> modules (if you use the generic functions).  This is for standard
> character drawing.  The logo is drawn indepently (fbcon_show_logo in
> fbcon.c).  User applications write directly to the framebuffer via the
> mmap() function.

I think I understand now. When the fb_set_disp function is called I fill
in the display struction with the console display operations. I've got
two choices now:

1. Create a new fbcon_cfb16 file which notes the changed areas before
calling the generic function.

2. Patch the current fbcon_cfb16 (with a CONFIG option) to add the
change tracking facility in a more generic way.

I guess the question is is it worth doing 2 as a potential upstream
patch? Or is this sort of thing so specialised I should just keep it all
packed in my own fb driver?

I guess I can't easily implement user access via mmap without uploading
the entire screen, which I'm not intending to do anyway because all I
really need is the console support - at least for now.

> > Are there any examples of drivers that have a similar architecture that
> > would be worth looking at? I've had a look at the vfb.c code but again
> > that seems too simplistic compared to what I'll need.
> 
> Search the archives for SED1335.  The author implemented a shadowed
> virtual framebuffer using system memory.  The contents of the virtual
> framebuffer are written to the data port periodically via a timer
> function.

I couldn't find anything in the mail archives but after some careful
googling I found this site (posted for reference):
ftp://ssv-embedded.de/ssv/products/trm916/sample/x86/linux/fbdev which
seems to be the one your refering to.

Thanks for the pointer, seeing the code made things a lot clearer :-)

-- 
Alex, homepage: http://www.bennee.com/~alex/

Bennett's Laws of Horticulture:
	(1) Houses are for people to live in.
	(2) Gardens are for plants to live in.
	(3) There is no such thing as a houseplant.

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

[Sven L. <lu...@dp...>]

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

Re: [Linux-fbdev-devel] Some questions

[Thomas W. <th...@wi...>]

Sorry, but I send mails faster than I can think sometimes:

 > - and probably is the reason for that vertical offset I see after this
 >  mode switch: The text area on the screen is shifted down by exactly 8
 > pixels - 600-592=8

Or perhaps the fbcon_resize stuff does

1) either not take the penguin into account,

or

2) does this too early, namely before the call to check_var()?

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:th...@wi...            http://www.winischhofer.net/

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

[Geert U. <ge...@li...>]

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 -- ge...@li...

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

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

[Sven L. <lu...@dp...>]

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

Re: [Linux-fbdev-devel] Some questions

[Thomas W. <th...@wi...>]

Geert Uytterhoeven wrote:
>>Ideally, the driver should round up to the nearest mode it's capable
>>of.  The "fraction of a character dimensions" will be automatically
>>cleared by the "clear_margins" hook.
> 
> 
> But if I say e.g. `fbset 800x600-90', I do want a 90 Hz 800x600 mode, 
 > whatever the font may be.

Seems the fbdev people themselves aren't really happy with that stty 
solution...? :)

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:th...@wi...            http://www.winischhofer.net/

Re: [Linux-fbdev-devel] Some questions

[Thomas W. <th...@wi...>]

Further to my mail from a few minutes ago:

I wrote:
 > But I noticed another issue here:
 >
 > When switching to gfx mode during boot (ie as soon as the penguin
 > appears), the text console is aligned correctly at all edges, with all
 > lines visible.

 > But when "initial console" starts, the mode is again changed, and now
 > the last line of text is nearly invisible, its upper half appears at
 > the lower screen edge, the lower half is below the screen's edge. The
 > space between the penguin and the text is notably thicker.
 >
 > This can be recovered by switching to another VT and back. This makes
 > the penguin disappear, and restores the console dimensions/edges to
 > normal.

 > Interestingly, this only happens with 800x600; this mode is chosen
 > upon requesting 800x592 (because of the font size). At 1024x768,
 > everything is as it should.

I am almost sure that this has to do with the fact that I adapt var in 
my check_var from 800x592 to 800x600. Console (or whoever) seems to 
attempt to change the mode to its initially desired dimension on many 
occasions.

- This leads to the (unncessary) second mode switch during boot (when 
the "initial console" starts), assumingly because the xres does not 
match fontsize * rows,

- and probably is the reason for that vertical offset I see after this 
mode switch: The text area on the screen is shifted down by exactly 8 
pixels - 600-592=8

Any hints?

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:th...@wi...            http://www.winischhofer.net/

Re: [Linux-fbdev-devel] Some questions

[Geert U. <ge...@li...>]

On 5 Mar 2003, Antonino Daplas wrote:
> > 3) The resizing using stty is - how do I put this - slightly imperfect.
> > I don't know how you fbdev folks do it, but I am not used to think in
> > row/col categories, but *resolutions* instead. Apart from this - IMHO a
> > bit annoying - inconvenience, this method has further issues:
> > 
> > a) Calculating the desired mode resolution my simply multiplying the
> > rows/cols by the font size very often results in odd modes like 800x592.
> > This even when using a standard 8x16 font, not thinking of situations
> > where for instance 12x22 fonts are used. How is the low level driver
> > supposed to handle this?
> 
> Ideally, the driver should round up to the nearest mode it's capable
> of.  The "fraction of a character dimensions" will be automatically
> cleared by the "clear_margins" hook.

But if I say e.g. `fbset 800x600-90', I do want a 90 Hz 800x600 mode, whatever
the font may be.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: [Linux-fbdev-devel] Some questions

[Thomas W. <th...@wi...>]

Antonino Daplas wrote:
>>Can anybody confirm that this (ie both low level driver and fbcon in
>>kernel) is supposed to work in 2.5.63 (making it a bug in my sisfb
>>implementation)? Did I perhaps miss anything, like a kernel parameter to
>>activate fbcon or similar?
> 
> Yes, it it does work.

OK, now it works here, too. Seems my debug-printks during initialisation 
made the kernel go bananas. As soon as I removed them, it walks along...

But I noticed another issue here:

When switching to gfx mode during boot (ie as soon as the penguin 
appears), the text console is aligned correctly at all edges, with all 
lines visible.

But when "initial console" starts, the mode is again changed, and now 
the last line of text is nearly invisible, its upper half appears at the 
lower screen edge, the lower half is below the screen's edge. The space 
between the penguin and the text is notably thicker.

This can be recovered by switching to another VT and back. This makes 
the penguin disappear, and restores the console dimensions/edges to normal.

Interestingly, this only happens with 800x600; this mode is chosen upon 
requesting 800x592 (because of the font size). At 1024x768, everything 
is as it should.

>>However, I could not manage to gain a graphical console if sisfb is a
>>module, but fbcon is in the kernel. Is this combination supposed to
>>work? If so, how?
> 
> No, fbcon will not load unless there's at least one registered fbdev.
> So, you must compile sisfb statically too.

Then this should definitely go into the kernel config rules, I guess :)

>>a) Calculating the desired mode resolution my simply multiplying the
>>rows/cols by the font size very often results in odd modes like 800x592.
>>This even when using a standard 8x16 font, not thinking of situations
>>where for instance 12x22 fonts are used. How is the low level driver
>>supposed to handle this?
> 
> Ideally, the driver should round up to the nearest mode it's capable
> of.  The "fraction of a character dimensions" will be automatically
> cleared by the "clear_margins" hook.

OK, that's exactly what I do now. I currently tend to the assumption 
that this mode should be larger than the requested one...?

>>To temporarily overcome this, I implemented a somewhat fuzzy mode
>>identification routine, searching for modes with resolutions within a
>>range of [desired res] - [desired res + 16]. But I can't imagine this
>>being the Real Thing.
> 
> Yes, that's the Real Thing :-)  fbcon_resize has a "fuzzy mode" too --
> it won't do an fb_set_var() if the change in dimensions is only a
> fraction of a character's dimension.

Ack. Is 16 fuzzy enough, what do you think?

> Right, using stty to change the window size assumes that the fbdev
> driver has an algorithm to calculate modelines based on xres and yres
> independently.  This is probably a bit of work for most driver authors.

Well, not as much work as more a lack of definition. If the user 
specified a default of 800x600-75 I can't simply assume he also wants 
1024x768-75.

> There's new code in fbmon.c (fb_find_mode and fb_validate_mode) that
> should ease code writing if you have a VESA GTF compliant monitor.  You
> can use that if you want as long as the display's operating limits are
> known (info->monspecs).

Well, this assumes that the user always want the best refresh rate, 
which is not desired in all cases.

> Another solution is to reimplement resizing by fbset.  The code is not
> very difficult and can be added if most people want it.

Awaiting public demand :)

> Yes, this is a limitation of stty.  It calls con_resize twice (one for
> row and another for cols, depending on the order of the options) so it
> will not work if the driver only supports a fixed set of modes.  Another
> reason to bring back fbset resizing.

Think so, too. That's a really stupid behavior otherwise, since it 
involves two mode changes, with one really undesired mode on the way.

> Scrolling mode is now determined by fbcon.  If var->accel_flag is
> nonzero, scrolling is ypan, otherwise, it's yredraw.  It's because ypan
> requres a lot of block copy which is slow when done by software.
> 
> I still believe though that scrolling should be determined by the
> driver, not fbcon.

Well, what should I do now?

The rivafb only forces y panning (ie sets yres_virtual to maximum) if 
yres_virtual is -1. This is never the case, as default var is constantly 
reused and I nowhere saw that any of the res_virtuals was set to -1.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:th...@wi...            http://www.winischhofer.net/

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

[Geert U. <ge...@li...>]

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 -- ge...@li...

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

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

[Sven L. <lu...@dp...>]

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

Re: [Linux-fbdev-devel] Advice sought on approach.

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

On Wed, 2003-03-05 at 20:37, Alex Bennee wrote:
> Hi,
> 
> I'm writting a framebuffer driver for an embedded system that has a
> overlayed video display (TV picture + Overlayed text). To do this I have
> to keep track of both the main pixel memory and a mask that the hardware
> uses to display things. This is also compilcated by the fact I can't
> access this memory directly, it is done through a small addr/data port
> on the hardware so obviosuly I want to minimise the amount of data I
> push through this (by doing it only when required).
> 
> Having read the fb-dev docs on www.linux-fbdev.org I'm a little confused
> as to what actually puts data into the framebuffer. Most of the
> framebuffer drivers just seem to deal with resolution and colourmap
> settings. Is this a case of having to re-implement the fbcon drivers as
> well to get what I want?
> 

The pixels placed to the framebuffer are all done in the fbcon-cfb*.c
modules (if you use the generic functions).  This is for standard
character drawing.  The logo is drawn indepently (fbcon_show_logo in
fbcon.c).  User applications write directly to the framebuffer via the
mmap() function.

> Are there any examples of drivers that have a similar architecture that
> would be worth looking at? I've had a look at the vfb.c code but again
> that seems too simplistic compared to what I'll need.

Search the archives for SED1335.  The author implemented a shadowed
virtual framebuffer using system memory.  The contents of the virtual
framebuffer are written to the data port periodically via a timer
function.

> 
> Final question, the docs refer to 2.2. Is this because under 2.4
> framebuffer drivers are not fundamentally differnt?

Yes.

Tony

Re: [Linux-fbdev-devel] Some questions

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

On Wed, 2003-03-05 at 20:18, Thomas Winischhofer wrote:
> I am currently porting the SiS framebuffer driver to the - more or less
> - new API. Better late than never :)
> 
> Anyway, during this, I noticed some issues: (I am using stock 2.5.63 for
> development, no fbdev patches)
> 
> 1) Sisfb currently does not work if compiled statically into the kernel.
> (It works as a module if fbcon is a module, too). If sisfb and fbcon are
> the kernel, the mode switch occures but the only thing I see is a white
> rectangle at the left egde of the screen, vertically centered, with some
> flashing grey dots. I almost looks like text mode output while in
> graphics mode, or - better - if fbcon assumes a font size of 1 pixel.
> Finally, it seems to oops, but I can't say that for sure because I don't
> see anything (and I unfortunately don't have a serial console available).
> 
> Can anybody confirm that this (ie both low level driver and fbcon in
> kernel) is supposed to work in 2.5.63 (making it a bug in my sisfb
> implementation)? Did I perhaps miss anything, like a kernel parameter to
> activate fbcon or similar?

Yes, it it does work.

> 
> 2) If both sisfb and fbcon are modules, everything works s supposed when
> first modprobing sisfb and then fbcon. Upon modprobing fbcon, the mode
> switch occures and I see a graphical console (with a white rectangle of
> the size of the previous console size which vanishes upon pressing enter).

Ideally, fbdev should only change the video mode on the first fb_open()
or fb_set_par() and restore the state on the last fb_close().  This is
so you can load fbdev without having a framebuffer console.  If memory
serves me correctly, that's how sisfb in 2.4 works?.

> 
> However, I could not manage to gain a graphical console if sisfb is a
> module, but fbcon is in the kernel. Is this combination supposed to
> work? If so, how?

No, fbcon will not load unless there's at least one registered fbdev.
So, you must compile sisfb statically too.

> 
> 3) The resizing using stty is - how do I put this - slightly imperfect.
> I don't know how you fbdev folks do it, but I am not used to think in
> row/col categories, but *resolutions* instead. Apart from this - IMHO a
> bit annoying - inconvenience, this method has further issues:
> 
> a) Calculating the desired mode resolution my simply multiplying the
> rows/cols by the font size very often results in odd modes like 800x592.
> This even when using a standard 8x16 font, not thinking of situations
> where for instance 12x22 fonts are used. How is the low level driver
> supposed to handle this?

Ideally, the driver should round up to the nearest mode it's capable
of.  The "fraction of a character dimensions" will be automatically
cleared by the "clear_margins" hook.

> 
> To temporarily overcome this, I implemented a somewhat fuzzy mode
> identification routine, searching for modes with resolutions within a
> range of [desired res] - [desired res + 16]. But I can't imagine this
> being the Real Thing.

Yes, that's the Real Thing :-)  fbcon_resize has a "fuzzy mode" too --
it won't do an fb_set_var() if the change in dimensions is only a
fraction of a character's dimension.

> 
> b) The call to fb_set_var() inside fbcon_resize() is checked for errors,
> but not the call to fbcon_resize() from within fbcon_switch(). This
> leads to catastrophic drawing errors if the requested mode is not
> supported by the low level driver.

Yes, it's a bug.  I think I submitted a patch to fix that, but I'm not
sure if James applied it to his tree.

> 
> c) fbcon_resize() only changes var.xres and var.yres, leaving everything
> else - var.pixclock, for instance - alone. fb_set_var() just calles the
> driver's check_var() routine and then set_par(). How is the low level
> driver supposed to behave in this situation, especially considering the
> unchanged pixclock?
> 

Right, using stty to change the window size assumes that the fbdev
driver has an algorithm to calculate modelines based on xres and yres
independently.  This is probably a bit of work for most driver authors. 
There's new code in fbmon.c (fb_find_mode and fb_validate_mode) that
should ease code writing if you have a VESA GTF compliant monitor.  You
can use that if you want as long as the display's operating limits are
known (info->monspecs).

Another solution is to reimplement resizing by fbset.  The code is not
very difficult and can be added if most people want it.

> d) Starting with a mode of 1024x768 and resizing to 800x600 using stty
> works after all (see a)), but only if I execute stty twice. The desired
> mode the low level driver receives at the first attempt is 800x768.
> Could this be related to an outdated or buggy stty, calling the console
> code twice if rows and cols are specified at the same time...?

Yes, this is a limitation of stty.  It calls con_resize twice (one for
row and another for cols, depending on the order of the options) so it
will not work if the driver only supports a fixed set of modes.  Another
reason to bring back fbset resizing.

> 
> 3) About y panning: In the 2.4 version of sisfb, I simply forced the
> console to do y panning (unless positively disabled by the user) by
> "patching" yres_virtual to the maximum, depending on the available video
> memory. I am allowed to do that with the 2.5 API? (The rivafb code makes
> be believe so...)

Scrolling mode is now determined by fbcon.  If var->accel_flag is
nonzero, scrolling is ypan, otherwise, it's yredraw.  It's because ypan
requres a lot of block copy which is slow when done by software.

I still believe though that scrolling should be determined by the
driver, not fbcon.

Tony 

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

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

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

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

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

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

[Linux-fbdev-devel] Advice sought on approach.

[Alex B. <ker...@be...>]

Hi,

I'm writting a framebuffer driver for an embedded system that has a
overlayed video display (TV picture + Overlayed text). To do this I have
to keep track of both the main pixel memory and a mask that the hardware
uses to display things. This is also compilcated by the fact I can't
access this memory directly, it is done through a small addr/data port
on the hardware so obviosuly I want to minimise the amount of data I
push through this (by doing it only when required).

Having read the fb-dev docs on www.linux-fbdev.org I'm a little confused
as to what actually puts data into the framebuffer. Most of the
framebuffer drivers just seem to deal with resolution and colourmap
settings. Is this a case of having to re-implement the fbcon drivers as
well to get what I want?

Are there any examples of drivers that have a similar architecture that
would be worth looking at? I've had a look at the vfb.c code but again
that seems too simplistic compared to what I'll need.

Final question, the docs refer to 2.2. Is this because under 2.4
framebuffer drivers are not fundamentally differnt?


-- 
Alex, homepage: http://www.bennee.com/~alex/

Any sufficiently advanced bug is indistinguishable from a feature.
		-- Rich Kulawiec

[Linux-fbdev-devel] Some questions

[Thomas W. <th...@wi...>]

I am currently porting the SiS framebuffer driver to the - more or less
- new API. Better late than never :)

Anyway, during this, I noticed some issues: (I am using stock 2.5.63 for
development, no fbdev patches)

1) Sisfb currently does not work if compiled statically into the kernel.
(It works as a module if fbcon is a module, too). If sisfb and fbcon are
the kernel, the mode switch occures but the only thing I see is a white
rectangle at the left egde of the screen, vertically centered, with some
flashing grey dots. I almost looks like text mode output while in
graphics mode, or - better - if fbcon assumes a font size of 1 pixel.
Finally, it seems to oops, but I can't say that for sure because I don't
see anything (and I unfortunately don't have a serial console available).

Can anybody confirm that this (ie both low level driver and fbcon in
kernel) is supposed to work in 2.5.63 (making it a bug in my sisfb
implementation)? Did I perhaps miss anything, like a kernel parameter to
activate fbcon or similar?

2) If both sisfb and fbcon are modules, everything works s supposed when
first modprobing sisfb and then fbcon. Upon modprobing fbcon, the mode
switch occures and I see a graphical console (with a white rectangle of
the size of the previous console size which vanishes upon pressing enter).

However, I could not manage to gain a graphical console if sisfb is a
module, but fbcon is in the kernel. Is this combination supposed to
work? If so, how?

3) The resizing using stty is - how do I put this - slightly imperfect.
I don't know how you fbdev folks do it, but I am not used to think in
row/col categories, but *resolutions* instead. Apart from this - IMHO a
bit annoying - inconvenience, this method has further issues:

a) Calculating the desired mode resolution my simply multiplying the
rows/cols by the font size very often results in odd modes like 800x592.
This even when using a standard 8x16 font, not thinking of situations
where for instance 12x22 fonts are used. How is the low level driver
supposed to handle this?

To temporarily overcome this, I implemented a somewhat fuzzy mode
identification routine, searching for modes with resolutions within a
range of [desired res] - [desired res + 16]. But I can't imagine this
being the Real Thing.

b) The call to fb_set_var() inside fbcon_resize() is checked for errors,
but not the call to fbcon_resize() from within fbcon_switch(). This
leads to catastrophic drawing errors if the requested mode is not
supported by the low level driver.

c) fbcon_resize() only changes var.xres and var.yres, leaving everything
else - var.pixclock, for instance - alone. fb_set_var() just calles the
driver's check_var() routine and then set_par(). How is the low level
driver supposed to behave in this situation, especially considering the
unchanged pixclock?

d) Starting with a mode of 1024x768 and resizing to 800x600 using stty
works after all (see a)), but only if I execute stty twice. The desired
mode the low level driver receives at the first attempt is 800x768.
Could this be related to an outdated or buggy stty, calling the console
code twice if rows and cols are specified at the same time...?

3) About y panning: In the 2.4 version of sisfb, I simply forced the
console to do y panning (unless positively disabled by the user) by
"patching" yres_virtual to the maximum, depending on the available video
memory. I am allowed to do that with the 2.5 API? (The rivafb code makes
be believe so...)

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:th...@wi...            http://www.winischhofer.net/

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

[Sven L. <lu...@dp...>]

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

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

[Geert U. <ge...@li...>]

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 -- ge...@li...

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

[Linux-fbdev-devel] Feature Freeze?

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

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

Re: [Linux-fbdev-devel] Re: FBdev updates.

[Petr V. <van...@vc...>]

On Tue, Mar 04, 2003 at 10:29:06PM +0100, Jurriaan wrote:
> > text mode.
> 
> There is a regression here: I boot my kernel like this:
> 
> kernel /boot/vmlinuz-2563matrox root=/dev/hda7 video=matrox:vesa:0x11E,fv:80,sgram hdc=scsi apm=smp apm=power-off nosmp=1
> 
> I see a continuous strip of alternating blocks, of sub-character size,
> at the extreme right end of my screen. The colors seem linked to the
> color of the line with the cursor in some way.
> 
> After leaving XFRee, a piece of chbg's background picture is shown for a
> short while, then the blocks return.

Reproduced. Try this (untested) (it is against clean tree, so you'll 
get some line offsets if you had applied my matroxfb patch). Or set 
xres to odd value, even values do not work...
							Petr Vandrovec


--- linux/drivers/video/console/fbcon.c	2003-03-03 18:42:37.000000000 +0100
+++ linux/drivers/video/console/fbcon.c	2003-03-04 22:44:05.000000000 +0100
@@ -456,7 +456,7 @@
 	region.color = attr_bgcol_ec(p, vc);
 	region.rop = ROP_COPY;
 
-	if (rw & !bottom_only) {
+	if (rw && !bottom_only) {
 		region.dx = info->var.xoffset + rs;
 		region.dy = 0;
 		region.width = rw;

Re: [Linux-fbdev-devel] Re: FBdev updates.

[Jurriaan <thu...@xs...>]

From: Petr Vandrovec <van...@vc...>
Date: Mon, Mar 03, 2003 at 09:35:00PM +0100
> On Fri, Feb 21, 2003 at 08:24:17AM +0800, Antonino Daplas wrote:
> > On Fri, 2003-02-21 at 02:29, Petr Vandrovec wrote:
> > > 
> > > I was for five weeks in U.S., so I did not do anything with
> > > matroxfb during that time. I plan to use fillrect and copyrect
> > > from generic code (although it means unnecessary multiply on
> > > generic side, and division in matroxfb, but well, if we gave
> > > up on reasonable speed for fbdev long ago...). But I simply
> > > want loadfont and putcs hooks for character painting. And if 
> > > fbdev maintainer does not want to give me them, well, then 
> > > matroxfb and fbdev are not compatible.
> > 
> > Petr,
> > 
> > I submitted the Tile Blitting patch to James some time ago, it has
> > tilefill, tilecopy and tileblit hooks.  These hooks should eliminate the
> > "multiply in fbcon, divide in driver" bottleneck.
> >
> > It should result in the same behavior as you would expect in the the 2.4
> > API, so you can use text mode with your matroxfb driver.  These same
> > hooks will also help optimize drawing if we need to use fonts like
> > 12x22.
> 
> Hi,
>   while waiting on these updates I updated matroxfb a bit
> (ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.5.63.gz),
> so that it now uses fb_* for cfb modes, and putcs/... hooks for
> text mode.

There is a regression here: I boot my kernel like this:

kernel /boot/vmlinuz-2563matrox root=/dev/hda7 video=matrox:vesa:0x11E,fv:80,sgram hdc=scsi apm=smp apm=power-off nosmp=1

and have the following .config:

CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_AGP=y
CONFIG_AGP_VIA=y
CONFIG_DRM=y
CONFIG_DRM_MGA=y
CONFIG_RAW_DRIVER=y
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_PCI_CONSOLE=y
CONFIG_FBCON_ADVANCED=y
CONFIG_FONT_SUN12x22=y
CONFIG_FONTS=y
CONFIG_FB_MATROX=y
CONFIG_FB_MATROX_G450=y
CONFIG_FB_MATROX_G100=y
CONFIG_FB_MATROX_I2C=y
CONFIG_FB_MATROX_MAVEN=y
CONFIG_FBCON_CFB8=y
CONFIG_FBCON_CFB16=y
CONFIG_FBCON_CFB24=y
CONFIG_FBCON_CFB32=y
CONFIG_FBCON_ACCEL=y

matroxfb: Matrox G400 (AGP) detected
matroxfb: MTRR's turned on
matroxfb: 1600x1200x16bpp (virtual: 1600x5241)
matroxfb: framebuffer at 0xD4000000, mapped to 0xe0805000, size 33554432
Console: switching to colour frame buffer device 133x54
fb0: MATROX VGA frame buffer device
pty: 256 Unix98 ptys configured
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected VIA Apollo Pro 266T chipset
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: AGP aperture is 64M @ 0xd0000000
[drm] Initialized mga 3.1.0 20021029 on minor 0

I see a continuous strip of alternating blocks, of sub-character size,
at the extreme right end of my screen. The colors seem linked to the
color of the line with the cursor in some way.

After leaving XFRee, a piece of chbg's background picture is shown for a
short while, then the blocks return.

Kind regards,
Jurriaan


-- 
But the threat of disapproval had terrified me
No more my soul will I reveal
	Wargasm - Chameleon
GNU/Linux 2.5.63 SMP/ReiserFS 1x2793 bogomips load av: 1.18 0.46 0.17

Re: [Linux-fbdev-devel] Re: FBdev updates.

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

On Tue, 2003-03-04 at 04:35, Petr Vandrovec wrote:

>   My main concern now is 12x22 font... Accelerator setup
> is so costly for each separate painted character that for 8bpp 
> accelerated version is even slower than unaccelerated one :-(
> (and almost twice as slow when compared with 2.4.x).

I submitted a patch to James, which he already applied to his tree, that
addresses this problem.  It conglomerates the series of bitmaps into 1,
so only one fb_imageblit is necessary.  It should give faster painting
than the original 2.5.x code, hopefully faster than 2.4.x code, but
slower than 8x16 painting because of the additional packing.

> 
>   And one (or two...) generic questions: why is not pseudo_palette
> u32* pseudo_palette, or even directly u32 pseudo_palette[17] ?

Yes, all drivers should treat the pseudo_palette as u32* anyway, so why
not change pseudo-palette from void* to u32*?

> And why we do not fill this pseudo_palette with
> i * 0x01010101U for 8bpp pseudocolor and i * 0x11111111U for 4bpp
> pseudocolor? This allowed me to remove couple of switches and tests
> from acceleration fastpaths (and from cfb_imageblit and cfb_fillrect,
> but I did not changed these two in my benchmarks below).

I also agree for a different reason.  Cards with unconventional formats
(such as monochrome at 8 bpp - 0 for black , 0xff for white) will not
work with the current code.

Tony