Handling of Input Device in Computer Graphics
A device through which a user can give data, information, or control signals to a computer is known as an input device. A computer Central Processing Unit (CPU) accepts and processes data to generate the output. For example, light pen, keyboard, etc. are examples of event-driven- input -devices.
Handling of event-driven devices: Handling event-driven devices can be conducted in two ways-
- Begin by entering a polling loop, which checks the device’s status until an event is signaled. When an event happens, the loop is exited with the event’s results. In High-Level Languages, reading a terminal input is frequently handled in this manner. One drawback of this technique is that the CPU is frequently idle while waiting for something to happen.
- Allowing interrupts, which are transmitted by the device when an event occurs, is another option. By using the interrupt mechanism, the processor is free to carry out some other operations while it is waiting for an event to take place.
Input Device Handling Algorithms: The system serves as an interface between the device-dependent user programs and the available device. The insides of interface procedures will vary depending on the device, while the outsides that users see will remain consistent. This is fantastic for the users, but it is challenging for us because we cannot simply provide an algorithm.
Consider the various types of procedures that can be used to handle input devices. Let’s consider the classes of devices.
When pressed, a button is an event-driven device that sends an interrupt. It only conveys the fact that it has been pressed as information.
It is typified by pen. It is an event-driven device that selects some portion of the display.
For the keyboard simulation, the internal form of the routines is subsequently altered from that of the general case. This is because of the 2 factors. First, input from the keyboard via high-level language appears to be sampled, rather than the event-driven mechanism.
A locator is a sampled device that returns the coordinates of some position.
A valuator is a sampled device and very similar to the locator but it returns only one value. It might be a dual or knob which can be set by the user.
Let’s presume that each device has the means to enable or disable it and will simplify this procedure by generating a flag for each class, rather than enabling and disabling individual devices. The flags(set or unset) define whether or not a specific class is enabled. To make it easier to specify the classes, give them numerical names.
1. Routine to enable the Button class:
BEGIN If Class = 1 Then BEGIN // Perform all the operations needed to permit // input from the button devices Button <-- True END; If Class = 2 Then BEGIN // Perform all the operations needed to permit // input from the pick devices Pick <-- True END; If Class = 3 Then BEGIN // Perform all the operations needed to permit // input from the keyboard Keyboard <-- True END; If Class = 4 Then BEGIN // Perform all the operations needed to permit // input from the Loactor devices Loactor <-- True END; If Class = 5 Then BEGIN // Perform all the operations needed to permit // input from the valuator devices Valuator <-- True END; AND so on . . . RETURN; END;
2. Routine to disable the Button class:
BEGIN If Class = 1 Then BEGIN // Perform all the operations needed to prohibit // input from the button devices Button <-- False END; If Class = 2 Then BEGIN // Perform all the operations needed to prohibit // input from the pick devices Pick <-- False END; If Class = 3 Then BEGIN // Perform all the operations needed to prohibit // input from the keyboard Keyboard <-- False END; If Class = 4 Then BEGIN // Perform all the operations needed to prohibit // input from the Loactor devices Loactor <-- False END; If Class = 5 Then BEGIN // Perform all the operations needed to prohibit // input from the valuator devices Valuator <-- False END; And so on . . . RETURN; END;
To disable routine takes a class number as an input and performs whatever operations are required to logically switch off this class of device and change the appropriate device flag to false. Similarly, the enable routine takes a class number, executes the required operations to logically turn on the devices, and sets the relevant device flag to true.
3. Routine for disabling all the Input Devices:
BEGIN For Class = 1 to 5 Do disable button(Class); // calling routine 2 Above RETURN; END;
For Handling Events: An interrupt is generated by an event-driven device. The processor stops its current work whenever an interrupt occurs. The processor executes the interrupt service routine for the device that generated the interrupt. After servicing the device, the processor resumes its old work.
Here, assume a single event queue, but there can be multiple queues. The meaning of providing a service(by CPU) is to identify the interrupt-causing device and get input data from it. After fetching this information, it is stored in the event queue.
Queue works in a first-in-first-out manner. Each element of the queue represents a user action or an event. In the queue, insertion is done at the rear end and deletion is done from the front.
1. Algorithm For Processing Input Device Interrupt:
BEGIN Disable Physical Interrupt; Save Status Of CPU ; Identify Interrupt Causing Device; If the device is logically enabled, Then BEGIN If event from a string Input Devivce, Then BEGIN Get the input string; // Add string to the queue, Described in // the next algorithm ADD_STRING_Q(STRING, DATA); END Else BEGIN Get the data from the device; // Add string to the queue, Described in // the next algorithm ADD_EVENT_Q(CLASS, NUMBER, DATA); END END Restore the status of processor; Renable the physical Interrupt; RETURN END
2. Algorithm For Adding Event To Queue:
This algorithm uses the function-
ADD_EVENT_Q(CLASS, NUMBER, DATA)
BEGIN If Qrear = Qsize, Then Qrear <- 1 Else Qrear <- Qrear + 1; If Qfront = Qrear, Then Return error - " Event Queue - overflow" // Add class of the input device to the event // queue class array at rear position EVENT_QC[Qrear] <- Class; // Add the number of the input device to the // event queue number array at rear position EVENT_QN[Qrear] <- Number; // Add data from the input device to the event // queue data array at rear position EVENT_QD[Qrear] <- Data; If QFront <- 0, Then QFront <- 1; RETURN ; END;
In the string queue, each new string is added to the array of the strings. Upon reaching the end of the array, get back to the front position. The following function is used-
BEGIN If SQrear = SQsize, Then SQrear <- 1 Else SQrear <- SQrear + 1 // Add String from the input device to the // String queue data array at rear position STRING_Q[SQrear] <- String; Data <- SQrear RETURN; END;
If no event occurs or no interrupt is generated and the queues remain empty.