Changes between Version 6 and Version 7 of fbf_device_api

Timestamp:

Jan 22, 2020, 4:51:57 PM (4 years ago)

Author:

alain

Comment:

--

fbf_device_api

@@ -28 +28 @@
 It must be called by a local thread.
 
-== __C) User API__ ==
+== __C) "User" API__ ==
 
 All functions defined in this ''user'' API do NOT use the the FBF device waiting queue, the associated device thread and the FBF IRQ, as the client thread does NOT deschedules,
 
-=== C.1) dev_fbf_get_config() ===
+'''C.1) dev_fbf_get_config()'''
 
 This function implements the ''fbf_get_config()'' syscall. It returns the FBF number of lines, the number of pixels per line, and the pixel encoding type. It can be called by a client thread running in any cluster.
 It does not access the hardware, as the size and type have been registered in the chdev descriptor extension by the dev_fbf_init() function.
 
-=== C.2) dev_fbf_create_window() ===
+'''C.2) dev_fbf_create_window()'''
 
 This blocking function implements the ''fbf_create_window()'' sys-call. It registers a new window in the windows_tbl[] array, and in the windows list, rooted in FBF device descriptor. It registers in the reference VSL an ANON vseg, that will be mapped in local cluster. The window index <wid> is dynamically allocated. The owner process is the calling process. The FBF window is defined by the <nlines>, <npixels>, <l_min>, <p_min> arguments. The created vseg base address in user space is returned in the <user_base> argument. It can be called by any thread running in any cluster.
@@ -43 +43 @@
 As the vseg associated to the window is not directly  mapped to the frame buffer, the owner process can read and write in the window buffer without syscall. As for any other vseg, the physical memory is allocated on demand, at each page fault. 
 
-=== C.3) dev_fbf_refresh_window() ===
+'''C.3) dev_fbf_refresh_window()'''
 
 This blocking function implements the ''fbf_refresh_window()'' sys-call. It allows the owner process to signal the windows manager that some lines of a window identified by the <wid>, <line_min>, and <line_max> arguments have been modified, and must be refreshed in the FBF. It scans all the registered FBF windows to respect the overlap order defined by the windows xlist. It can be called by any thread running in any cluster.
 
-=== C.4) dev_fbf_move_window() ===
+'''C.4) dev_fbf_move_window()'''
 
 This blocking function implements the ''fbf_move_window()'' sys-call. It moves a window identified by the <wid> argument to a new position in the FBF, defined by the <l_min> and <p_min> arguments. It can be called by any thread running in any cluster.
 
-=== C.5) dev_fbf_resize_window() ===
+'''C.5) dev_fbf_resize_window()'''
 
 This blocking function implements the ''fbf_resize_window()'' syscall. It changes the <width> and <height> of a window identified by the <wid> argument. It updates the size of the associated vseg, but does not change the vseg "base". When the new window buffer is larger than the existing one, this buffer is 0 filled. It can be called by any thread running in any cluster.
 
-=== C.6) dev_fbf_delete_window() ===
+'''C.6) dev_fbf_delete_window()'''
 
 This function implements the ''fbf_delete_window()'' sys-call to delete a FBF window. It releases all memory allocated for the window buffer and for the window descriptor. It can be called by any thread running in any cluster.
 
-=== C.7) dev_fbf_move_data() ===
+'''C.7) dev_fbf_move_data()'''
 
 This function implements the deprecated ''fbf_read()'' and ''fbf_write()'' sys-calls. This function allows an user application to directly access the Frame Buffer, without using any intermediate window. It calls directly the driver to synchronously move <npixels> between an user <buffer> and the FBF, starting at a given <offset> in the FBF. The transfer direction is defined by the <is_write> argument.
 
-
-== __ D) Driver API__ ==
+== __ D) "Driver" API__ ==
 
 The FBF device defines defines four command types to access the FBF driver(s) :