Hi, [re-adding linux-fbdev, please make sure to reply-to-all] On Wed, 01 June 2011 Daniele Salvatore Albano <info@xxxxxxxxx> wrote: > From what i understand, technically i should hook registered > framebuffer and change the callback (info->fbdefio->deferred_io), > restoring it on module unloading to avoid the caos. > > In this way i could "catch" updates passed to the pagelist argument of > the deferred io callback, add them to an own list, and call the original > callback to let the driver to do the own work. Note that some framebuffer drivers might implement (lots) of private ioctls to implement (accelerated) drawing primitives. So unless you know the driver you are hooking onto all bets are open. > This is in the kernel from 2.6.20, so it should be on phone kernel. > > I've a couple more questions: > - i need to access the structure containing the list of registered > framebuffer device (struct fb_info *registered_fb[FB_MAX]), i've seen > that there is an export symbol on registered_fb so can i access that > directly/num_registered_fb? You can access it (as does fbcon) though that direct access may/will go away in the future as (since 2.6.39) now that array is protected by a mutex on fb core side (fbcon being indirectly fine through its synchronization via notification events, except when loading fbcon module) If you do access the list, write an function to do just that so there is no big rewrite needed to move your driver forward. > - i need to know when a framebuffer is registered, i've seen that there > is fb_register_client ... from what i see it seems that callback are > called on every event so from the callback itself i should check for > FB_EVENT_FB_REGISTERED, is this right? If you want to know when framebuffers get (un)registered (or get reconfigured) this is the way to go. > - (stupid question) do all fb modules implement deferred input/output? No, only a few selected ones implement deferred input/output, usually because the real framebuffer cannot be mapped into memory or the link to it is just dead slow so changes are pushed down to device at regular intervals. I'm wondering if you not better had to create a new framebuffer driver (based on virtual framebuffer) with fbdefio to push the changes to a backing framebuffer [the way fbcon draws console] (as well as whatever you use to stream to the remote system). This will make you lose any potential hardware acceleration but keep things simple. Though you would need ability to move software to your new framebuffer. Bruno -- 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
