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-

1. 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.
2. 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.

1. Button-
   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.
2. Pick-
    It is typified by pen. It is an event-driven device that selects some portion of the display.
3. Keyboard-
   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.
4. Locator-
   A locator is a sampled device that returns the coordinates of some position.
5. Valuator-
   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 Locator devices
        Locator <-- 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 Locator devices
        Locator <-- 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 Device, 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-

ADD_STRING_Q(STRING, DATA)

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.