Normally, video hardware has a region of memory ( i.e., the frame
buffer) that you can write to to affect the image on a screen.
Instead of using an actual piece of hardware's frame buffer, vfb.c
just vmallocs a chunk of memory to write to. If an actual application
such as X or Qt were to use this frame buffer, the output images would
be drawn in this memory instead of to a screen.
So does this mean X (or) any graphical application "always" accesses the VFB in linux to write data and then the chunk of memory is written to the h/w FB and then displayed on the console? (In this case the h/w FB is completely hidden from apps??)
> 2) How are the operations defined in "vfb.c" requested. Because there dosent
> seem to be any ioctl's which can be requested to invoke these operations? So
> basically what is the entry point into the driver ?
You define the operations as functions and then set up a struct fb_ops
to point to them. In vfb.c this struct is called vfb_ops. vfb_ops is
passed to register_framebuffer in the struct fb_info that is returned
by framebuffer_alloc. All of this business happens in the probe
routine vfb_probe. This routine is called by the driver subsystem.
The driver subsystem learns about this and other routines from the
driver_register call in the init function. Note that the framebuffer
subsystem will choose which /dev/fbX is associated with your driver.
Well, from the source I see that driver_register() essentially calls bus_add_driver(), which attaches the driver to a matching device by walking thru' the list of devices on the bus bus(CMIIW).
But my question was, can the apps like "X" directly request operations which are defined in vfb_ops ? Because there are no ioctls() that can be called from __user_space__ to invoke any of these operations on the vfb device.
I am comparing this(FB driver) with a char driver like the "serial.c" to see the differences between the design of the drivers for diff. types of char devices.For eg., in a serial port driver , you have a bunch of ioctl() commands using which an user app like the "stty" command can use to set/get various properties and invoke driver operations. How abt the case of the VFB ? Will "X" need to manipulate any property of the VFB like change colour map or dynamically change screen resolution ? If so how does it talk to the driver ? (Pls. execuse my limited knowledge in this area! )
a long way...will take it anytime...thnx
--
"There are 10 people in the world - those who understand binary and those who dont !"
