fbdev tree pulled into Linus tree

fbdev tree pulled into Linus tree

[Petr Vandrovec]

Hello James,
  besides that the beast does not compile because of
the use of p->type instead of info->fix.type in the logo code,
what's the reason for having next_line, next_plane
(and maybe other too - can_soft_blank, inverse, yscroll) 
in the display struct, if you moved rest of the values 
into fix. So now I maintain half of state in per-display 
structs, and half in the per-fbdev structure? Nigthmare.
Can you create some ('tmp' or 'par' or whatever) structure
and hold them in fb_info too?

  Also because of you moved these type/line_length and
other into the fix, there is no point in having dispsw
in the display struct: these functions must not be invoked
on the fbdev with con != fbcon.currcon now because of
part of state exists only for foreground console now. So
move them into per-fb_info structure too, and handle 
con != fbcon.currcon in generic code (if not done already).

  Then it will be clear what is really per-VT structure
which should be maintained by upper layer, and what is
fbdev bussiness. And while you'll move dispsw pointer, change
it to the embeded structure. It will make life easier to
atafb and matroxfb at least, as they like to modify fb_ops
according to the hardware they find, and currently they
modify structure global to the driver.

  That's all for now, I'll see what will happen after reboot. 
Expect first public matroxfb updates tomorrow.
					Best regards,
						Petr Vandrovec

P.S.: I do not have your new email address here at home,
and you are neither in MAINTAINERS nor in the CREDITS,
I hope that the address I randomly choosed from the credits
in fbdev files will work.


-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31

Re: fbdev tree pulled into Linus tree

[Geert Uytterhoeven]

On Wed, 14 Aug 2002, Petr Vandrovec wrote:
> fbdev bussiness. And while you'll move dispsw pointer, change
> it to the embeded structure. It will make life easier to
> atafb and matroxfb at least, as they like to modify fb_ops
> according to the hardware they find, and currently they
> modify structure global to the driver.

Yes, this can cause problems on machines with multiple graphics cards of the
same family, but using different acceleration features. That's why I made the
dispsw structs const, to make sure you copy them before modifying them. But now
e.g. atyfb doesn't compile anymore due to `assignment discards qualifiers from
pointer target type'.

> P.S.: I do not have your new email address here at home,
> and you are neither in MAINTAINERS nor in the CREDITS,
> I hope that the address I randomly choosed from the credits
> in fbdev files will work.

Fortunately you've picked the right one ;-)

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: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31

Re: fbdev tree pulled into Linus tree

[James Simmons]

> Hello James,
>   besides that the beast does not compile because of
> the use of p->type instead of info->fix.type in the logo code,
> what's the reason for having next_line, next_plane

I believe that is for ilbm support. I plan to have those go away soon.

> (and maybe other too - can_soft_blank, inverse, yscroll)
> in the display struct, if you moved rest of the values
> into fix.

That stuff will be cleaned up soon. My next set of changes will be big.

> So now I maintain half of state in per-display
> structs, and half in the per-fbdev structure? Nigthmare.
> Can you create some ('tmp' or 'par' or whatever) structure
> and hold them in fb_info too?

This is for the next set of changes. I'm working on them right now.

>   Also because of you moved these type/line_length and
> other into the fix, there is no point in having dispsw
> in the display struct: these functions must not be invoked
> on the fbdev with con != fbcon.currcon now because of
> part of state exists only for foreground console now. So
> move them into per-fb_info structure too, and handle
> con != fbcon.currcon in generic code (if not done already).

Working on it.

>   Then it will be clear what is really per-VT structure
> which should be maintained by upper layer, and what is
> fbdev bussiness. And while you'll move dispsw pointer, change
> it to the embeded structure. It will make life easier to
> atafb and matroxfb at least, as they like to modify fb_ops
> according to the hardware they find, and currently they
> modify structure global to the driver.

As the new cfb* functions mature I can get ride of dispsw and use the
accel pointer directly.

> P.S.: I do not have your new email address here at home,
> and you are neither in MAINTAINERS nor in the CREDITS,
> I hope that the address I randomly choosed from the credits
> in fbdev files will work.

I'm in MAINTAINERS and CREDITS in BK now.



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390