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

Re: [Linux-fbdev-devel] Some questions

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

On Thu, 2003-03-06 at 03:43, James Simmons wrote:
> 
> > > I think you should only accept modes where the difference is a fraction
> > > of a character width or height.  A difference more than that and
> > > clear_margins() will not work correctly.  
> > > 
> > 
> > I apologize for my stupidity, fbdev does not know the font dimensions. 
> > I guess, we'll just need to really bring back fbset resizing.
> 
> I disagree that fbset is the solution to all things. The problem is 
> fbcon_resize is severally broken. The reality is that there are fixed mode 

fbcon_resize() is not that broken, it's only trying to do what it's
supposed to do.  It is indeed limited because it is trying to outguess
the low-level drivers on the best resolution for a window size.

However, the brokenness is really on the driver side.  They are unable
to change the video mode unless they are supplied with the correct
timing parameters where in fact they actually have the best knowledge on
how to calculate them.  

So the question:  Do we let fbcon spoonfeed the timings to fbdev, or do
we let the drivers calculate it for themselves?  I go for the latter, as
fbcon really should not have any business with hardware.

> resolutions (i.e. LCD displays). So fbcon has to adpat to this. What we 
> shoudl do is set the console mode fit slightly smaller than that the 
> actually resolution. The reason being is partially drawn fonts at the 

Yes, Geert's accel_clear_margin fix should help that.

Tony

Re: [Linux-fbdev-devel] Some questions

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

On Thu, 2003-03-06 at 03:02, James Simmons wrote:
> > 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.
> 
> ???? stty rows 128 cols 48 works for me. It should'nt calling con_resize 
> twice. 
> 

It does.  You probably won't notice it if the driver supports flexible
video mode changing.  For drivers that don't it will fail.  For
instance, if a driver supports 800x600 and 1024x768 only, and stty is
used to change the mode from 1024x768 to 800x600, it will be done like
this:

resize to 800x768 <--- because no mode matches this, resizing fails
resize to 800x600

If you don't believe me, do an strace stty cols 80 rows 30.

Tony

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

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

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

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

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

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

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

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

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  

Re: [Linux-fbdev-devel] Some questions

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

> Excuse me that I dare to comment on this as a total fbdev-rookie:

No problem. Its rare I take things personally. So I don't mind people 
critizing my work. You have to have a thick skin for this line of work.
 
> Please think about usability, too. Forcing people to fiddle with rows 
> and cols, requiring knowledge about font sizes and stuff is at least 
> inappropriate. Folks are used to think in resolutions, that's what they 
> understand, and that's what is most obvious. I can't imagine anyone 
> caring about the amount of rows or columns on a text screen.

Actually it is normal. Changing a console via stty has been around 
forever. When you ask what size is your VGA console you say 80x25. Now why 
is that. The main thing is people think of it as a text mode and second
you really can't change it or boot to to many different size resolutions.
Does this mean VGA console should be limited? NO!!! I plan to make vgacon 
some day changable in window size. So the final answer is:

Portablity. 

You could use stty or some other program using the tty layer to change the 
resolution on any type of hardware running any type of console driver. The 
next best thing is some day we can get ride of con_switch in the upper 
console layers. We can just use set_font and vc_resize on VT switching 
since that is all you are doing on vc_switching. 

P.S
   If you look at struct winsize you have a ws_xpixel and a ws_ypixel 
field. The question is now do we place the exact size of the screen in 
pixels or vc->font.width[height]*width[height]. So it is stty program 
that is limiting and not the tty layer. In theory you could write fbset to 
use the proper tty ioctl to do this.
 
> BTW: What happens currently if I instruct console to replace the current 
> font with a bigger one (if that's possible at run-time at all) ?

It should work.

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

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

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

Re: [Linux-fbdev-devel] Some questions

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

> > I should of but didn't because I knew driver would take teh path of lest 
> > resistance to port there drivers. TO much change would have made the 
> > current situtation much much worst. 
> 
> One could argue that changing stuff more or less constantly does not 
> make it any easier to keep up with a working driver.... :)

Well that was a policy change later on. At first the approach was small 
changes at a time. I was even converting each driver by myself. This upset 
some people. It was discussed the best solution would be to dump all the 
changes at one time and then let the driver maintainers deal with it. 
That is why the shift in what was going on.

Re: [Linux-fbdev-devel] Some questions

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

James Simmons wrote:
> I disagree that fbset is the solution to all things. The problem is 
> fbcon_resize is severally broken. The reality is that there are fixed mode 
> resolutions (i.e. LCD displays). So fbcon has to adpat to this. What we 
> shoudl do is set the console mode fit slightly smaller than that the 
> actually resolution. The reason being is partially drawn fonts at the 
> bottom of the screen would look bad. So clearing the margins also has to 
> be fixed. This way we clean up the screen for situtations where the 
> console screen size doesn't quite fit the resolution. This is what shoudl 
> be done. 

Excuse me that I dare to comment on this as a total fbdev-rookie:

Please think about usability, too. Forcing people to fiddle with rows 
and cols, requiring knowledge about font sizes and stuff is at least 
inappropriate. Folks are used to think in resolutions, that's what they 
understand, and that's what is most obvious. I can't imagine anyone 
caring about the amount of rows or columns on a text screen.

BTW: What happens currently if I instruct console to replace the current 
font with a bigger one (if that's possible at run-time at all) ?

Thomas

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

Re: [Linux-fbdev-devel] Some questions

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

James Simmons wrote:
>>>We should split the monitor programing stuff out from stuff like bpp etc.
>>>Now if you think about it we can do things like change the bpp without 
>>>having to redo the monitor programming. This is the flaw with the old and 
>>>even the new api. 
>>
>>You could have done that from the beginning. Just look at which fields have
>>changed and which haven't.
> 
> 
> I should of but didn't because I knew driver would take teh path of lest 
> resistance to port there drivers. TO much change would have made the 
> current situtation much much worst. 

One could argue that changing stuff more or less constantly does not 
make it any easier to keep up with a working driver.... :)

Thomas

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

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

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

On  5 Mar 03 at 20:22, James Simmons wrote:
>  
> >   And one (or two...) generic questions: why is not pseudo_palette
> > u32* pseudo_palette, or even directly u32 pseudo_palette[17] ?
> 
> pseudo_palette was originally designed to be a pointer to some kind of 
> data for color register programming. For example many PPC graphics cards 
> have a color register region. Now you could have that point to 
> pseudo_palette.  Note pseudo_palette is only visiable in fbmem.c for the 
> logo drawing code. Personally I liek to see that hidden.

cfbfillrect? cfbimageblit? Both use pseudo_palette, and both convert
it 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).
> 
> ??? Does your accel engine require these kinds of values?

Yes. It is 32bit engine, and so it wants 32bit value. And even if 
not, code doing

if (p->fix.visual == FB_VISUAL_TRUECOLOR ||
    p->fix.visual == FB_VISUAL_DIRECTCOLOR)
      fg = p->pseudo_palette[rect->color];
else
      fg = rect->color;

is horrible. Two conditional jumps on each rectangle. If you'll do
always lookup through pseudo_palette, not only that you get rid of
these jumps, you can also remove calls to pixel_to_pat32 (and accompanying
tables & lookups), as you do this expansion at set_var time,
instead of at blit/clear time.
                                            Best regards,
                                                Petr Vandrovec
                                                van...@vc...
                                                

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

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

> >   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*?

See other email.

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

Isn't that the job of setcolreg?

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

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

> 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. I have still dozen of changes in fbcon.c which I have
> to eliminate (mainly logo painting and cursor handling - for now
> I still use revc method, mainly because of I did not make into it yet).

I grabbed your latest patch and started to merge it with my latest work on 
the matrox driver. As soon as I'm done merging my matrox changes I will 
send you a patch right away.

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

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

pseudo_palette was originally designed to be a pointer to some kind of 
data for color register programming. For example many PPC graphics cards 
have a color register region. Now you could have that point to 
pseudo_palette.  Note pseudo_palette is only visiable in fbmem.c for the 
logo drawing code. Personally I liek to see that hidden.

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

??? Does your accel engine require these kinds of values?

Re: [Linux-fbdev-devel] Re: New logo code (fwd)

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

> > removed the hgafb logo code in the latest tree. It should use the standard 
> > logo code. Also how should we go about for personal logos. Companies might 
> > want to throw in there own thing which I have no issue with.
> 
> An option CONFIG_LOGO_USER, and a path CONFIG_LOGO_USER_PATH to a logo? Or
> multiple user-specific logos (one of each type)?

I like that idea.

Re: [Linux-fbdev-devel] Some questions

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

> > I think you should only accept modes where the difference is a fraction
> > of a character width or height.  A difference more than that and
> > clear_margins() will not work correctly.  
> > 
> 
> I apologize for my stupidity, fbdev does not know the font dimensions. 
> I guess, we'll just need to really bring back fbset resizing.

I disagree that fbset is the solution to all things. The problem is 
fbcon_resize is severally broken. The reality is that there are fixed mode 
resolutions (i.e. LCD displays). So fbcon has to adpat to this. What we 
shoudl do is set the console mode fit slightly smaller than that the 
actually resolution. The reason being is partially drawn fonts at the 
bottom of the screen would look bad. So clearing the margins also has to 
be fixed. This way we clean up the screen for situtations where the 
console screen size doesn't quite fit the resolution. This is what shoudl 
be done. 

Re: [Linux-fbdev-devel] Some questions

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

> Do you remember how modes were set before the existence of fbset? I guess not
> :-)

before my time.

> A driver could support up to 31 modes (cfr. the old minors). You changed mode
> by touch'ing the /dev/fb0my_favorite_mode special device that corresponded to
> the mode you wanted.

Yuck!!!!
 
> > userland database I often couldn't change video modes after booting. 
> 
> Ugh, those are serious driver bugs....

So the arrgument that fbset is the solution to all problems is bogus IMO.

> > We should split the monitor programing stuff out from stuff like bpp etc.
> > Now if you think about it we can do things like change the bpp without 
> > having to redo the monitor programming. This is the flaw with the old and 
> > even the new api. 
> 
> You could have done that from the beginning. Just look at which fields have
> changed and which haven't.

I should of but didn't because I knew driver would take teh path of lest 
resistance to port there drivers. TO much change would have made the 
current situtation much much worst. 

Re: [Linux-fbdev-devel] Some questions

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

> Indeed, accel_clear_margins() calculates the margins as
> 
>     unsigned int cw = vc->vc_font.width;
>     unsigned int ch = vc->vc_font.height;
>     unsigned int rw = info->var.xres % cw;
>     unsigned int bh = info->var.yres % ch;
> 
> However, if it would use
> 
>     unsigned int rw = info->var.xres - (vc->vc_cols*cw);
>     unsigned int bh = info->var.yres - (vc->vc_rows*ch);
> 
> it would work with higher differences, too. And it would be a bit faster
> (multiply and subtract vs. modulo).

Applied.

Re: [Linux-fbdev-devel] Some questions

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

On Wed, 5 Mar 2003, James Simmons wrote:
> On a personal note. Many fbdev drivers in 2.4.X where also broken in that 
> only the boot mode worked. This is where the fbset mode database in 
> userland hack came in (/etc/fb.modes). This is horriable. Even with that 

Do you remember how modes were set before the existence of fbset? I guess not
:-)

A driver could support up to 31 modes (cfr. the old minors). You changed mode
by touch'ing the /dev/fb0my_favorite_mode special device that corresponded to
the mode you wanted.

> userland database I often couldn't change video modes after booting. 

Ugh, those are serious driver bugs....

> We should split the monitor programing stuff out from stuff like bpp etc.
> Now if you think about it we can do things like change the bpp without 
> having to redo the monitor programming. This is the flaw with the old and 
> even the new api. 

You could have done that from the beginning. Just look at which fields have
changed and which haven't.

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

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

> > I think that might be one reason for what I see :)
> 
> http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
> 
> Note that there is still a bug in fbcon_resize().
> 
> 1.  in fbcon_resize(), p->vrows must be updated unconditionally

Applied in latest patch.
 
> 2.  fbcon_resize() in fbcon_switch() must be moved higher up the code,
> preferably before the scroll_phys_max calculation.

Do you have a patch?

Re: [Linux-fbdev-devel] Some questions

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

> > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
> 
> Note that this patch is dated Feb 20. In the mean time James applied at least
> your accel_putcs() optimizations and my logo updates.

Please note I just release a new patch. Please try it out.

Re: [Linux-fbdev-devel] Some questions

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

> > Well, this assumes that the user always want the best refresh rate, 
> > which is not desired in all cases.
> > 
> 
> fb_get_mode() accepts 4 flags.  Maximum refresh rate, hscan-driven,
> vrefresh-driven and dotclock-driven calculations.  It's flexible enough,
> but of course not as flexible as specifying your own modeline.

Things like pixclock rates can be changes by fbset and fbcon still 
sees these changes. stty is for the basic changes and fbset for advance 
changes. 

On a personal note. Many fbdev drivers in 2.4.X where also broken in that 
only the boot mode worked. This is where the fbset mode database in 
userland hack came in (/etc/fb.modes). This is horriable. Even with that 
userland database I often couldn't change video modes after booting. 

We should split the monitor programing stuff out from stuff like bpp etc.
Now if you think about it we can do things like change the bpp without 
having to redo the monitor programming. This is the flaw with the old and 
even the new api. 
 

Re: [Linux-fbdev-devel] Some questions

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

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

I fixed this in my latest patch. You can use con2fb again!!!!!!

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

Applied.

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

:-( 

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

???? stty rows 128 cols 48 works for me. It should'nt calling con_resize 
twice. 

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

Scrolling needs alot of work. I plan to fix that.

Re: [Linux-fbdev-devel] Some questions

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

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

Please try your driver with the patch I post and tell me what problems you 
still have. Most of those shoudl have been fixes now.

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

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

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

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

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

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

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

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

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

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

That requires massive surgery for the console layer. 

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

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

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

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