nicholassouchu:kernelgraphicsinterface

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
nicholassouchu:kernelgraphicsinterface [2022/06/10 02:18] – Import KII content KubilayKocaknicholassouchu:kernelgraphicsinterface [2022/06/10 02:46] (current) – Finally, expand acronyms for page names KubilayKocak
Line 21: Line 21:
   * [[#kgim|Kernel Graphics Interface Module (KGIM)]]: Graphic driver framework   * [[#kgim|Kernel Graphics Interface Module (KGIM)]]: Graphic driver framework
   * [[#kii|KII Input System]]   * [[#kii|KII Input System]]
-    * input drivers ([[/KgiInput|KgiInput]]) +    * [[#kgiinput|KGI Input]] Drivers 
-    * keyboard / mouse multiplexing ([[/KgiFocus|KgiFocus]])+    * [[#kgifocus|KGI Focus]]: Keyboard & Mouse Multiplexing
     * keymap support (not yet)     * keymap support (not yet)
 +  * [[#kgimutex|KGI Mutex]] 
  
   * a console (KGC) with:   * a console (KGC) with:
Line 77: Line 78:
  
 Drivers using the %%KgimAPI%% are known as %%KgimDrivers%%. Drivers using the %%KgimAPI%% are known as %%KgimDrivers%%.
 +
 +=== KGIM Drivers ===
 +
 +A KGIM driver is the driver of a graphic board written for KGI and respecting the %%KgimAPI%%.
 +
 +KGIM drivers are broken down in several subsystems (or subdrivers) which are typically the components of a graphic display HW chain:
 +
 +  * chipset 
 +  * clock
 +  * ramdac 
 +  * monitor 
 +
 +The result of linking the compilation objects of the above subsystems gives you a %%KgimBoard%%. Currently, the glue-code between the subsystems is partly KGI API dependent for implementing a %%KgiDisplay%% and partly dependent of the operating system supposed to load the %%KgimBoard%% as a module.
 +
 +A KGIM board is not yet a Plugins because it is specific to the OS it was compiled for.
 +
 +Code which is system specific is isolated from the rest of the subsystems' code. This enables the compilation of the drivers in the same tree for any target OS. Also, KGI proposes a library of OS dependent routines for basic operations like mutexe management, delays, VM operations... The KGIM drivers use them instead of calling directly the OS API. These routines are part of the %%KgiAPI%%.
 +
 +In the %%FreeBSD%% implementation, the board entity is a full %%FreeBSD%% kld module device driver, respecting the newbus interface, connected to the PCI core and responsible for dispatching the %%FreeBSD%% resources to the KGIM underlying clock, ramdac and chipset drivers (as they exist in the Linux implementation). The board driver probe/attach routines detect the chipset, prepare the [[/KgiDisplay|KgiDisplay]] information and call the KGIM functions to powerup the %%KgimDrivers%%.
 +
 +When the board module is loaded into the %%FreeBSD%% kernel, the probe routine has already acknowledged the chipset existance. Consequently, during the attach call, when the KGI chipset driver is powered up, the pci_find() routine is a nop instruction. Later, resource reservation like irq_claim and check_region are converted into %%FreeBSD%% bus_resource() calls.
  
 ==== KII ==== ==== KII ====
Line 100: Line 122:
 /dev/sysmouse <------------+ /dev/sysmouse <------------+
 </code> </code>
 +
 +=== KGI Input ===
 +
 +A [[/KgiInput|KgiInput]] is basically anything capable of providing KII with events. [[/KgiInput|KgiInput]] are typically input drivers that convert HW events (mouse move, buttons, key-press...) into KII events.
 +
 +The [[/KgiInput|KgiInput]] must register itself to KII using the [[/KgiInputAPI]]. Once done, it may be polled by the KII engine or send itself events to KII.
 +
 +=== KGI Focus ===
 +
 +The [[/KgiFocus|KgiFocus]] is the central place in [[/KGI|KGI]] where [[/KgiInput|KgiInput]] are connected to [[/KgiDisplay|KgiDisplay]].
 +
 +When you hit a key on your keyboard, you want it to go to the console you are working on and application(s) running on that console should get the event delivered.
 +
 +Other applications running on other consoles should not get the event (for obvious security reasons).
 +
 +When you want to switch to another physical (dual-head) or virtual (also known as VTs) console, you press a key combination to switch and then want now your chars to be sent to the right console.
 +
 +In other words, you need the system manages the focus for you in a convenient, deterministic and safe manner.
 +
 +These connections are at the same time dynamic and static. Static because the relationship between
 +display and input instances is predefined. Dynamic because you can register any [[/KgiInput|KgiInput]] (ps/2, usb
 +mouse or keyboards) or [[/KgiDisplay|KgiDisplay]] to the [[/KgiFocus|KgiFocus]].
 +
 +So what is predefined relationship? Let's have a look at the following:
 +
 +<code>
 +device 0 on focus 0, display 0, console 0
 +device 1 on focus 0, display 0, console 1
 +device 2 on focus 0, display 1, console 2
 +device 3 on focus 0, display 1, console 3
 +device 4 on focus 0, display 1, console 4
 +device 5 on focus 0, display 1, console 5
 +device 6 on focus 0, display 1, console 6
 +device 7 on focus 0, display 1, console 7
 +device 8 on focus 0, display 1, console 8
 +device 9 on focus 0, display 1, console 9
 +device 10 on focus 0, display 1, console 10
 +device 11 on focus 0, display 1, console 11
 +device 12 on focus 1, display 2, console 0
 +device 13 on focus 1, display 2, console 1
 +device 14 on focus 1, display 2, console 2
 +device 15 on focus 1, display 2, console 3
 +device 16 on focus 1, display 2, console 4
 +device 17 on focus 1, display 2, console 5
 +device 18 on focus 1, display 2, console 6
 +device 19 on focus 1, display 2, console 7
 +device 20 on focus 1, display 2, console 8
 +device 21 on focus 1, display 2, console 9
 +device 22 on focus 1, display 2, console 10
 +device 23 on focus 1, display 2, console 11
 +</code>
 +
 +It presents the case of 2 keyboards (represented by 2 focuses) for which one has 3 screens.
 +Each focus can reach 12 consoles (typically what you get with a PC keyboard with F1..F12). Focus 1
 +is totally linked to display 2 (1 keyboard + 1 screen wired config) and
 +focus 1 can either control consoles 0 and 1 through display 0 and others through
 +display 1. It means that with focus 0, when you hit ALT+F1 you edit commands on display 0,
 +ALT-F3 : you edit on display 1, ALT-F1 you change VT on display 0 and ALT-F4 to ALT-F12 : you
 +switch to VTs on display 1.
 +
 +==== KGI Mutex ====
 +
 +Mutexes are the basic KGI execution control mechanism.
 +
 +The mutex API was originaly design on the basis of %%FreeBSD%% mutex(9) and condvar(9) implementations.
 +On %%FreeBSD%%, mutexes and convars are different objects. In the KGI implementation, I decided
 +to merge them. It is mutex centric e.g some events may be associated to a mutex. It's convenient
 +when you have a mutex locking a object, the events associated to the mutex are obviously
 +related to the object locked.
 +
 +For example, when a buffer is finished to execute, you want to own the buffer mutex when returning from
 +the waiting queue. That way you can proceed on the buffer immediatly after the wait. The downside
 +is that you must own the mutex before waiting...
 +
 +See the [[/KgiMutexAPI]] for detailed info.
  
 ===== KGI for FreeBSD (kgi4BSD) Project ===== ===== KGI for FreeBSD (kgi4BSD) Project =====
Line 135: Line 232:
 ===== Application Programming Interface ===== ===== Application Programming Interface =====
  
-The KGI API includes:+==== KGI Device API ====
  
-  * [[/KgiDeviceAPI]] +kgi_device_t
-  * [[/KgiInputAPI]] +
-  * [[/KgiDisplayAPI]]+
  
-The %%KgimAPI%% is part of [[/KGI|KGI]] but strictly speaking, it is a lower level API interfaced to KGI thanks to the [[/KgiDisplayAPI]].+  * The unique identifier of the device 
 + 
 +<code> 
 +kgi_u_t id; 
 +</code> 
 + 
 +  * The identifier of the [[/KgiDisplay|KgiDisplay]] the device interacts with 
 + 
 +<code> 
 +kgi_u_t dpy_id; 
 +</code> 
 + 
 +  * Various flags 
 + 
 +<code> 
 +kgi_device_flags_t flags; 
 +</code> 
 + 
 +  * Currently set mode for the device 
 + 
 +<code> 
 +kgi_mode_t *mode; 
 +</code> 
 + 
 +  * Per device instance private data 
 + 
 +<code> 
 +kgi_private_t priv; 
 +</code> 
 + 
 +The three methods of a KGI device are callbacks called by KGI on KGI events: 
 + 
 +  * When the device is mapped to its display 
 + 
 +<code> 
 +kgi_device_map_device_fn *MapDevice; 
 +</code> 
 + 
 +  * When the device is unmapped from its display 
 + 
 +<code> 
 +kgi_device_unmap_device_fn *UnmapDevice; 
 +</code> 
 + 
 +  * When a %%KiiEvent%% has to be delivered to the KGI device 
 + 
 +<code> 
 +kgi_device_handle_event_fn *HandleEvent; 
 +</code> 
 + 
 +==== KGI Input API ==== 
 + 
 +kii_input_t: 
 + 
 +  * The next input in the linked list 
 + 
 +<code> 
 +kii_input_t *next; 
 +</code> 
 + 
 +  * The focus we belong to 
 + 
 +<code> 
 +kii_u_t focus; 
 +</code> 
 + 
 +  * Unique input device ID 
 + 
 +<code> 
 +kii_u_t id; 
 +</code> 
 + 
 +  * Bit mask of generated events 
 + 
 +<code> 
 +kii_event_mask_t events; 
 +</code> 
 + 
 +  * Bit mask of events to report 
 + 
 +<code> 
 +kii_event_mask_t report; 
 +</code> 
 + 
 +  * Vendor and Model strings for info only 
 + 
 +<code> 
 +kii_ascii_t         vendor[KII_MAX_VENDOR_STRING]; 
 +kii_ascii_t         model[KII_MAX_MODEL_STRING]; 
 +</code> 
 + 
 +  * Method for executing a command specific to the input 
 + 
 +<code> 
 +int (*Command)(kii_input_t *, kii_u_t cmd, void *); 
 +</code> 
 + 
 +  * Method called to poll a 32bits scancode 
 + 
 +<code> 
 +int (*Poll)(kii_input_t *); 
 +</code> 
 + 
 +  * Method called to parse a 32bits scancode got by Poll method 
 + 
 +<code> 
 +void (*Parse)(kii_input_t *, kii_event_t *, int); 
 +</code> 
 + 
 +  * Private data of the input 
 + 
 +<code> 
 +kii_private_t         priv; 
 +</code> 
 + 
 +kii_register_input() 
 + 
 +kii_register_input() is typically called when a new input driver is loaded. 
 + 
 +<code> 
 +kii_error_t kii_register_input( 
 + 
 + /* Comment: the focus to register to */ 
 + kii_u_t focus, 
 + 
 + /* Comment: preinitialized data about the input to register */ 
 + kii_input_t *dev 
 +); 
 +</code> 
 + 
 +The return code is null (KII_EOK) on succes. Otherwise, the appropriate return code is given back. 
 + 
 +A typical registration of an input is like this: 
 + 
 +<code> 
 +snprintf(sc->kii_input.vendor, KII_MAX_VENDOR_STRING, "KII FreeBSD keyboard"); 
 +snprintf(sc->kii_input.model, KII_MAX_VENDOR_STRING, kbd->kb_name); 
 +sc->kii_input.events = KII_EM_KEY | KII_EM_RAW_DATA; 
 +sc->kii_input.report = KII_EM_KEY | KII_EM_RAW_DATA; 
 +sc->kii_input.priv.priv_ptr = sc; 
 +sc->kii_input.Poll = kbdriver_poll; 
 +sc->kii_input.Parse = kbdriver_parser; 
 + 
 +kii_error = kii_register_input((~0), &sc->kii_input); 
 +</code> 
 + 
 +In the above example, KII_INVALID_FOCUS is passed as focus id to let [[/KII]] auto register the input 
 +according to its capabilities e.g sc->kii_input.events. sc->kii_input.priv.priv_ptr is initialized with 
 +the software data pointer of the kbd device. 
 + 
 +kbdriver_parser() takes scancodes from the RAW output of a kbd and fills the event structure passed in. 
 +Event is only reported to [[/KII]] if the event type corresponds (e.g bit set) in sc->kii_input.report. 
 + 
 +Here is another example of registration: 
 + 
 +<code> 
 +snprintf(mouse->input.vendor, KII_MAX_VENDOR_STRING, "FreeBSD"); 
 +snprintf(mouse->input.model, KII_MAX_VENDOR_STRING,  "Syscons Emulation Mouse"); 
 + 
 +mouse->input.focus = KII_INVALID_FOCUS; 
 +mouse->input.id = KII_INVALID_DEVICE; 
 +mouse->input.events = KII_EM_POINTER & ~KII_EM_PTR_ABSOLUTE; 
 +mouse->input.report = KII_EM_PTR_RELATIVE | KII_EM_PTR_BUTTON; 
 +mouse->input.priv.priv_ptr = mouse; 
 + 
 +/* XXX Force registration to focus 0 */ 
 +if (!(error = kii_register_input(0, &mouse->input))) { 
 + make_dev(&scectl_cdevsw, SC_CONSOLECTL, 
 + UID_ROOT, GID_WHEEL, 0600, "consolectl"); 
 +} else { 
 + KRN_ERROR("Could not register sce_mouse"); 
 +} 
 +</code> 
 + 
 +The above registration comes from the scemul device provided by KII to %%FreeBSD%%. It emulates the 
 +/dev/consolectl interface to which the general purpose mouse daemon sends data on mouse events. 
 +This data is processed internally and sent back to userland by /dev/sysmouse or /dev/event. 
 + 
 +In this example, no Parser or Poll methods are set. Instead, scemul responds to the mouse 
 +daemon inputs by sending directly the event to KII. 
 + 
 +kii_unregister_input(): 
 + 
 +kii_unregister_input() is typically called when the module of an input driver is unloaded. 
 + 
 +<code> 
 +void kii_unregister_input( 
 + 
 + /* Comment: the input to unregister from its focus */ 
 + kii_input_t *dev 
 +); 
 +</code> 
 + 
 +==== KGI Display API ==== 
 + 
 +kgi_display_t 
 + 
 +Data of a KGI display are: 
 + 
 +  * KGI display revision 
 + 
 +<code> 
 +kgi_u_t revision; 
 +</code> 
 + 
 +  * Vendor and Model strings 
 + 
 +<code> 
 +kgi_ascii_t vendor[KGI_MAX_VENDOR_STRING]; 
 +kgi_ascii_t model[KGI_MAX_VENDOR_STRING]; 
 +</code> 
 + 
 +  * Flags about special capabilities 
 + 
 +<code> 
 +kgi_u32_t flags; 
 +</code> 
 + 
 +  * Size of the private mode data 
 + 
 +<code> 
 +kgi_u_t mode_size; 
 +</code> 
 + 
 +  * Current mode 
 + 
 +<code> 
 +kgi_mode_t *mode; 
 +</code> 
 + 
 +  * The display id 
 + 
 +<code> 
 +kgi_u_t id; 
 +</code> 
 + 
 +  * non-console device attached 
 + 
 +<code> 
 +kgi_u_t graphic; 
 +</code> 
 + 
 +  * Previous display in linked list 
 + 
 +<code> 
 +struct kgi_display_s *prev; 
 +</code> 
 + 
 +  * Device currently focused to the display 
 + 
 +<code> 
 +struct kgi_device_s *focus; 
 +</code> 
 + 
 +The methods of a KGI display are: 
 + 
 +<code> 
 +kgi_display_refcount_fn *IncRefcount; 
 +</code> 
 + 
 +<code> 
 +kgi_display_refcount_fn *DecRefcount; 
 +</code> 
 + 
 +<code> 
 +kgi_display_check_mode_fn *CheckMode; 
 +</code> 
 + 
 +<code> 
 +kgi_display_set_mode_fn *SetMode; 
 +</code> 
 + 
 +<code> 
 +kgi_display_set_mode_fn *UnsetMode; 
 +</code> 
 + 
 +<code> 
 +kgi_display_command_fn *Command; 
 +</code> 
 + 
 +kgi_register_display() 
 + 
 +A display must register itself to offer its services to the [[/KgiDevice|KgiDevice]]. 
 + 
 +<code> 
 +kgi_s_t kgi_register_display( 
 + 
 + /* Comment: the preinitialized display to register */ 
 + kgi_display_t *dpy, 
 + 
 + /* Comment: the suggested id for the display */ 
 + kgi_u_t id 
 +); 
 +</code> 
 + 
 +A registration typically occur when loading a display module. The display must be initialized 
 +before registration: at least one %%KgiImage%% must be defined and the display resources must 
 +be described. 
 + 
 +For example, for the %%FreeBSD%% native VESA display: 
 + 
 +<code> 
 +       dpy->revision = KGI_DISPLAY_REVISION; 
 +snprintf(dpy->vendor, KGI_MAX_VENDOR_STRING, "KGI FreeBSD"); 
 +snprintf(dpy->model, KGI_MAX_VENDOR_STRING, "dpysw"); 
 +</code> 
 + 
 +No specific flag and the display mode specific area is sizeof(vidsw_mode_t) long. 
 + 
 +<code> 
 +dpy->flags = 0; 
 +dpy->mode_size = sizeof(vidsw_mode_t); 
 +</code> 
 + 
 +with (dpm is mandatory here IIRC): 
 + 
 +<code> 
 +typedef struct vidsw_mode_s { 
 + 
 + kgi_dot_port_mode_t dpm; 
 + 
 + video_info_t mode_info; 
 + video_info_t oldmode_info; 
 + 
 +} vidsw_mode_t; 
 +</code> 
 + 
 +The display methods are then initialized with yet not device focused: 
 + 
 +<code> 
 +mode = &sc->mode; 
 + 
 +dpy->mode = mode; 
 +dpy->id = -1; 
 +dpy->graphic = 0; 
 +dpy->IncRefcount = dpysw_inc_refcount; 
 +dpy->DecRefcount = dpysw_dec_refcount; 
 + 
 +dpy->CheckMode = dpysw_check_mode; 
 +dpy->SetMode = dpysw_set_mode; 
 +dpy->UnsetMode = dpysw_unset_mode; 
 +dpy->Command = dpysw_display_command; 
 + 
 +dpy->focus = NULL; 
 +</code> 
 + 
 +<code> 
 +mode->revision = KGI_MODE_REVISION; 
 +mode->dev_mode = NULL; 
 +mode->images = 1; 
 +mode->img[0].out = NULL; 
 +mode->img[0].flags = KGI_IF_TEXT16; 
 +mode->img[0].virt.x = adp->va_info.vi_width; 
 +mode->img[0].virt.y = adp->va_info.vi_height; 
 +mode->img[0].size.x = adp->va_info.vi_width; 
 +mode->img[0].size.y = adp->va_info.vi_height; 
 +mode->img[0].frames = 1; 
 +mode->img[0].tluts = 0; 
 +mode->img[0].aluts = 0; 
 +mode->img[0].ilutm = 0; 
 +mode->img[0].alutm = 0; 
 +mode->img[0].fam = 0; 
 +mode->img[0].cam = 0; 
 +</code> 
 + 
 +The framebuffer resource is described that way: 
 + 
 +<code> 
 +fb->meta = dpy; 
 +fb->type = KGI_RT_MMIO_FRAME_BUFFER; 
 +fb->prot = KGI_PF_APP_RWS | KGI_PF_LIB_RWS | KGI_PF_DRV_RWS; 
 +fb->name = "Frame buffer"; 
 +fb->access = 8 + 16 + 32 + 64; 
 +fb->align = 8 + 16; 
 +fb->win.size = (kgi_size_t)adp->va_window_size; 
 +fb->win.virt = (kgi_virt_addr_t)adp->va_window; 
 +fb->win.bus = (kgi_bus_addr_t)0; 
 +fb->win.phys = (kgi_phys_addr_t)adp->va_mem_base; 
 +fb->size = (kgi_size_t)adp->va_mem_size; 
 +fb->offset = 0; 
 +fb->SetOffset = dpysw_set_offset; 
 +</code> 
 + 
 +kgi_unregister_display() 
 + 
 +<code> 
 +void    kgi_unregister_display( 
 + 
 + /* Comment: the display to unregister */ 
 + kgi_display_t *dpy 
 +); 
 +</code> 
 + 
 +kgi_display_registered() 
 + 
 +kgi_display_registered shall be used to know if a display id is already bound 
 +to a registered display. 
 + 
 +<code> 
 +kgi_s_t kgi_display_registered( 
 + 
 + /* Comment: the display id */ 
 + kgi_u_t id 
 +); 
 +</code> 
 + 
 +Returns KGI_EOK if bound, KGI_ENODEV otherwise. 
 + 
 +==== KGIM API ==== 
 + 
 +The %%KgimAPI%% is part of KGI but strictly speaking, it is a lower level API interfaced to KGI thanks to the [[/KgiDisplayAPI]]. 
 + 
 +==== KGI Mutex API ==== 
 + 
 +kgi_mutex_t 
 + 
 +The kgi_mutex_t is an opaque structure. One shall use it with the following methods and never 
 +access it directly. It is OS specific and its content, its size may vary from one platform to 
 +another. 
 + 
 +kgi_mutex_alloc() 
 + 
 +Allocate a mutex. mtx must be null. The return parameter is 0 (KGI_EOK) in case of success. 
 + 
 +If the mutex has to be owned in the context of event synchronisation 
 +mechanisms, the number of different events has to be specified, otherwise 
 +KGI_MUTEX_NOEVENT shall be passed. Anyway nb_event can't exceed the maximum number KGI_MUTEX_MAXEVENT. 
 + 
 +<code> 
 +kgi_u_t kgi_mutex_alloc( 
 + 
 + /* Comment: pointer to the mutex to initialize */ 
 + kgi_mutex_t *mtx, 
 + 
 + /* Comment: max number of events */ 
 + kgi_u_t nb_events 
 +</code> 
 + 
 +kgi_mutex_free() 
 + 
 +Free a mutex. The mutex must have be done before free. 
 +mtx is null when returning from this function. Memory allocated 
 +for event management is also freed. 
 + 
 +<code> 
 +void kgi_mutex_free( 
 + 
 + /* Comment: pointer to the mutex to free */ 
 + kgi_mutex_t *mtx 
 +); 
 +</code> 
 + 
 +kgi_mutex_init() 
 + 
 +Initialize a pre-allocated mutex. The name passed is used for debug etc. 
 + 
 +<code> 
 +void kgi_mutex_init( 
 + 
 + /* Comment: pointer to the mutex to initialize */ 
 + kgi_mutex_t *mtx, 
 + 
 + /* Comment: name of the mutex */ 
 + const char *name 
 +); 
 +</code> 
 + 
 +kgi_mutex_done() 
 + 
 +Release a mutex. Memory allocated for the mutex itself is not freed. 
 + 
 +<code> 
 +void kgi_mutex_done( 
 + 
 + /* Comment: pointer to the mutex to release */ 
 + kgi_mutex_t *mtx 
 +); 
 +</code> 
 + 
 +kgi_mutex_lock() 
 + 
 +Lock the mutex. If the mutex is not free, the thread is blocked. 
 + 
 +<code> 
 +void kgi_mutex_lock( 
 + 
 + /* Comment: pointer to the mutex to lock */ 
 + kgi_mutex_t *mtx 
 +); 
 +</code> 
 + 
 +kgi_mutex_unlock() 
 + 
 +Unlock the mutex previously locked. 
 + 
 +<code> 
 +void kgi_mutex_unlock( 
 + 
 + /* Comment: pointer to the mutex to unlock */ 
 + kgi_mutex_t *mtx 
 +); 
 +</code> 
 + 
 +kgi_mutex_wait() 
 + 
 +Wait on event e.g unlock the mutex and add the thread to the list of waiting 
 +threads on this event. When the thread is made runnable again, it owns the mutex. 
 + 
 +Important: the mutex must be already locked by the current running thread when calling 
 +kgi_mutex_wait(). 
 + 
 +Callers are responsible for managing the relationship between event ids and their 
 +signification. the event parameter can't exceed nb_events passed when the mutex was 
 +initialized. 
 + 
 +<code> 
 +void kgi_mutex_wait( 
 + 
 + /* Comment: pointer to the mutex hold */ 
 + kgi_mutex_t *mtx, 
 + 
 + /* Comment: the event to wait on */ 
 + kgi_u_t event 
 +); 
 +</code> 
 + 
 +kgi_mutex_signal() 
 + 
 +Wakeup threads waiting on an event to occur with mutex ownership. 
 +If unblock_all is TRUE then unblock all waiters otherwise only one. 
 + 
 +<code> 
 +void kgi_mutex_signal( 
 + 
 + /* Comment: pointer to the mutex processes are blocked on */ 
 + kgi_mutex_t *mtx, 
 + 
 + /* Comment: event to signal */ 
 + kgi_u_t event, 
 + 
 + /* Comment: 1 = unblock all processes waiting on the mutex, 0 = unblock only the next one */ 
 + int unblock_all 
 +); 
 +</code>
  
 ---- ----
  • nicholassouchu/kernelgraphicsinterface.1654827531.txt.gz
  • Last modified: 2022/06/10 02:18
  • by KubilayKocak