> > > > The fb_ops can only be called from fbcon or the fbdev userland interface. > > > > The fbcon calls should only happen when the VC is in KD_TEXT mode. Now > > > > with the DRM backend we have the advantage of creating a mapping seperate > > > > from the console mapping. A fb_open/fb_close could be used to cleaning up > > > > the userland mmap as well as handle the console pinning. We can supply > > > > your own fb_mmap hook. > > > > > > Again, the issue is not userspace but that fb_ops hooks can be called > > > from interrupt context etc. > > > > This should not happen. The VT layer is protected from calling in the > > interrupt context. TNor does fbcon call any fb_ops methods from a irq. > > E.g. printk? Sorry I have been sick. This is true when you are in KD_TEXT mode and using fbcon. Now while working on a graphical console yes you can have other hardware devices do a printk which can alter the state of of your graphics card. As for debugging a graphics driver you have to be very careful with your printks. Usually in that case I use two graphics cards in my system and map one to fbcon and test the other graphcis cards driver. P.S The fbdev api is such that it doesn't always require a permanent framebuffer mapping. This was done for the case of graphical hardware that lacks a directly accessable framebuffer. If you have accelerated fillrect,copyarea,and imageblit then you don't even the mapping except in the case of someone calling mmap on /dev/fbX. I noticed the nouveau drivers has a accelerated fbcon :-) -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
