Re: [Linux-fbdev-devel] fbdev tree pulled into Linus tree

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

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