Re: fb_info, fb_fix_screeninfo : questions

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

> 1) is it legit to extend fb_info ? i.e. using another
> struc xxfb_info w/ a fb_info field first, and using
> that in place of regular fb_info (like it's done
> in 2.4 and in the ruby atyfb)

  No. I haven't worked on the atyfb driver so the current structure will
change for that driver. For hardware specific stuff you want to create a
xxx_par structure. You have two advantages to this. One is it allows the
fbcon layer to only have to worry about struct fb_info. Otherwise we have
to do all kinds of casting in the upper console layer. Second is the
xxx_par structure could be used in other subsystems (DRI). That is why I
call the structs xxx_par instead of xxxfb_par.

So you want to make a xxx_par strucure. Fill it in with default values and
then do a info->par = par in xxxfb_init. When we go to set the video mode
via fb_set_var in check_var we do NOT change xxx_par. We only see if the
hardware can support the purposed state. It is in set_par where we set the
video mode.

> 2) where is filled fb_fix_screeninfo ? skeletonfb
> doesn't mention it. I believe it's in _set_par,
> but I'd like to be sure.

Yes it is. Only only want to change the fix field when a video mode
actually changes. Otherwise userland will get really confussed.

> 3) are the optional functions (_ioctl, _fill_rect...)
>  replaced by NULL or by the cfb_ or fb_ generic
> in the _ops struct ?

If the function is required then you must fill in that fb_ops field, even
if it uses the generic functions. If not required then it is safe to have
it has a NULL field. These functions are tested for NULL pointers.