So we will have a repeat of the exact same code snipplet in all the
drivers ? I thought the new API was about having all the common code in
common and not duplicated in all the drivers. Could we have at least a
gen_disable_vga function or something such that we could call ?
> registers (crtc, attr, seq, gfx, misc). Usage is pretty
Well, i need to disable the vga output in seq, more exactly bit 3
called "enable VGA display", need to be reset.
> much uniform across all hardware. Any registers past those indices are
> considered extended registers and usage is hardware specific. In
> graphics mode, you will probably use both the standard and the extended
> registers, and disabling the VGA mode/enabling graphics mode is most
> probably in one of the extended registers.
Err, it is seq, called VGAControlRegister, so it is beyond the
standard seq registers (seq to seq), right ?
> > > Because James wrote the fb framework to be very modular, then you must
> > > be careful to save/restore the initial video state when loading or
> > > unloading. Theoretically, a driver should load, but not go to graphics
> > > mode immediately. Only upon a call to xxxfb_set_par() should the driver
> > > do so. Before going to graphics mode, that's were you save the initial
> > > state. Have a reference count or something to keep track of the number
> > > of users, and when this reference count becomes zero, restore the
> > > initial state. You should be able to do this by hooking these routines
> > > in fb_open() and fb_release().
> > Mmm, what about interaction with X ? X also does a save/restore of the
> > previous (text) mode, when a X driver is _not_ fbdev aware, it will
> > save/restore the things twice, right ?
> Not twice just the current mode it was in when X launched, although it
> always assumes text mode. Same thing for fbdev, it should only restore
Well, but fbdev will save its state and X will save it again, so the
saving done in the X driver is not all that important, and i could
ignore it at first if i already have an fbdev.
Does this also apply to vesafb ?
> the state when reference count becomes zero. If the framebuffer console
> is loaded, the reference count will never be zero unless it is
> unloaded. If the framebuffer console is not loaded, the only time you
> will save and restore the state is when some fb-based application
> attempts to open/close /dev/fbx.
> > > The one I submitted (and a revised one I'm going to submit soon) should
> > > be able to restore the VGA text/graphics mode. Complement this with
> > > your hardware's extended state save and restore routines and you should
> > > be able to load/use/unload your driver repeatedly :-).
> > Ok, i will try.
> This is optional though. You can still adopt the 2.4 method of always
> setting the video mode. Just take note that fbdev can be loaded without
> fbcon, and if you get into graphics mode without fbcon, you just messed
> up your user's console. I think this can be avoided by munging the
> configuration file (ie, always depend on fbcon and make your module
> unsafe to unload).
Anyway, i need to play with it some and experiment before i can do more
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/