"This was an OS-focused project where I ...

"This was an O.S-focused project where I ...

Audio by Paper2Audio

"This was an O.S-focused project where I built a Linux-based mouse gesture system. The basic idea was to allow users to perform common actions using mouse gestures instead of keyboard shortcuts.**

**I divided the project into two parts. The first part is a Linux kernel module, which receives mouse input through Linux's input subsystem. I used a simple state machine with three states — Normal, Ready and Recording — so that mouse movements are recorded only when the user has activated gesture mode and started a gesture.

> **While recording, I collect the mouse movement and represent it as a sequence of points. Once the user finishes the gesture, I use simple geometric rules to classify it as a swipe, circle or zig-zag. For example, a swipe is mainly identified using displacement and direction, a circle using whether the path closes back near its starting point, and a zig-zag using repeated changes in direction. I also added noise filtering so small accidental movements don't get recognized as gestures.

> **After recognizing the gesture, the kernel module communicates the result to a user-space program through a character device. The user-space program waits for a gesture using a blocking read. I used a wait queue so that the process sleeps when there is no gesture instead of continuously checking and wasting CPU. Once it receives a gesture, it creates an isolated child process to execute the corresponding desktop action.**

> **So the main O.S concepts I worked with were kernel and user space, input handling, state machines, character devices, blocking I/O, wait queues, process creation and communication between kernel and user space."**

You need to visualize this:

Mouse

↓

Linux Input Subsystem

↓

Kernel Module

↓

"Should I record this?"

↓

State Machine

Normal to Ready to Recording

↓

Mouse Points

↓

Gesture Recognition

↓

┌───────────

↓ ↓ ↓

Swipe Circle Zig-zag

↓

Character Device

/dev/gesture ctrl

↓

User-space Program

↓

Blocking Read

↓

Wait Queue wakes it

↓

fork() process

↓

Desktop Action

3. Why did you make it?

"What was the motivation?"**

> "I wanted to build something where I could apply O.S concepts to an actual system rather than only studying them theoretically. Mouse gestures gave me a simple use case where I could work with input events, kernel space, user space, processes and inter-process communication."

4. Why Linux kernel module?

> "I wanted to work at the operating-system level and receive input events through Linux's input subsystem. A kernel module gave me practical exposure to how Linux handles devices and how kernel code can communicate with user-space programs."

"Could you have done this entirely in user space?"

"Yes, a user-space implementation is possible. But the purpose of this project was to understand O.S concepts and Linux kernel interfaces, so I intentionally implemented the input-handling part as a kernel module."

# 5. What is the Linux Input Subsystem?

> "It's the Linux framework that provides a common way for the kernel to handle input devices such as keyboards and mice. Instead of my driver directly talking to the physical mouse hardware, it receives standardized input events through this subsystem."

> "What kind of events?"

"For the mouse, I mainly deal with relative movement events and button events. For example, mouse movement can be represented as changes in X and Y, while the right mouse button generates a button event."

6. Your state machine — very Important

Normal to Ready to Recording

Normal

Gesture mode isn't active.

Mouse movement

↓

Ignore for gesture recognition

Ready

Gesture mode has been activated.

Waiting for user to start gesture

Recording

User has started drawing.

Mouse movement

↓

Record points

After finishing:

Recording

↓

Recognize

↓

Ready

> "Why did you use a state machine?"

"Because the same mouse movement can mean different things depending on what the user is doing. I only want to record movement when the system is in the Recording state. The state machine makes those conditions explicit and prevents normal mouse movement from accidentally becoming a gesture.

What exactly are you recording?

You record the movement as points.

Imagine the mouse moves:

That's basically the **path of the gesture**.

You then analyze that path.

8. How do you recognize a Swipe?

Suppose:

(0, 0) to (100,10)

There is a large horizontal movement.

So:

X movement >> Y movement

That's a horizontal swipe."

Similarly:

```text

(0, 0)

|

|

↓

(10,100)

```

is mainly vertical.

Then direction determines:

9. How do you recognize a Circle?

The end of the path should come reasonably close to where it started.

end ≈ start

> "For a circle, I look at whether the path is sufficiently large and whether the endpoint comes close to the starting point, which indicates that the path is closed."

# 10. How do you recognize Zig-Zag?

The mouse repeatedly changes direction.

"I count meaningful changes in direction. If the path repeatedly reverses direction beyond a threshold, I classify it as a zig-zag."

11. Why noise filtering?

Imagine the user is trying to draw a circle but their hand moves slightly:

Those tiny movements shouldn't become a gesture.

So you ignore movements that are too small.

> "Mouse input naturally contains small unintended movements, so I used thresholds to ignore insignificant movements and reduce false positives."

> "How does the kernel communicate with user space?"

> "I expose the recognized gesture through a character device, `/dev/gesture ctrl`. The user-space daemon opens that device and reads the gesture from it."

> "What is a character device?"

"It's a Linux device interface that provides a file-like way for user-space programs to communicate with a device or kernel component. In my project, I use it as the interface between the kernel module and the user-space daemon."

13. What is a daemon?

> "A daemon is a program that runs in the background. My gesture daemon waits for recognized gestures and performs the corresponding action."

"Why not put that code inside the kernel?"

> "Because actions such as launching applications or interacting with the desktop are user-space responsibilities. I wanted the kernel module to handle low-level input and the user-space program to handle application-level actions."

Blocking read — your strongest O.S concept

Imagine your daemon is waiting.

Bad approach:

Any gesture?

No.

That's polling.

It wastes CPU.

instead

Daemon

↓

"I have nothing to do."

↓

Sleep 😴

Gesture arrives

↓

Wake up

↓

Read gesture

↓

Perform action

> "Why blocking read?"

"Because gestures don't happen continuously. Instead of repeatedly polling the device and wasting CPU, the daemon blocks when there is no gesture and wakes up when the kernel has data."

What is a wait queue?

The wait queue is what allows the process to sleep while waiting for a gesture. When the kernel detects a new gesture, it wakes the process so the blocked read can continue."

Think:

Wait Queue = Waiting Room

No gesture to sleep in waiting room

Gesture to wake up

```

Why forked processes?

Your resume explicitly says:

actions executed in isolated forked processes."

I didn't want execution of a desktop action to interfere with the main daemon. So the daemon creates a child process for the action. The parent can continue waiting for the next gesture while the child handles the action."

What is `fork()`?

fork() creates a new process by duplicating the calling process."

What happens after fork?

Daemon

|

fork()

/

Parent Child

| |

keep waiting action

Why not create a thread?

Say:

> "A process gives stronger isolation because it has its own address space. For a small M.V.P, using a separate process was a simple way to isolate action execution from the main daemon."

> "Would you use this architecture in production?

Say: "This was an M.V.P intended primarily to demonstrate O.S concepts. For production, I would improve things like device permissions, synchronization around shared buffers, more precise input-device matching, and configurable gesture thresholds."

Your limitations

Fixed gestures

Only:

Swipe

Circle

Zig-zag

Fixed thresholds

Different users might make gestures differently.

Basic recognition

It uses rules rather than M.L.

Say:

"For an M.V.P, I chose deterministic geometric rules because they are simple, lightweight and easy to debug."

What O.S concepts can you say you learned?

This is important because your resume says O.S Design.

Say:

"The project helped me connect several O.S concepts to an actual system: kernel space versus user space, device drivers, input events, character devices, blocking I/O, wait queues, process creation, and communication between kernel and user space."

# 21. Your O.S fundamentals map

| Your Project | O.S Concept |

| ---------------------- | ------------------------------- |

| Kernel module | Kernel space |

| Mouse input | Device/input handling |

| Input handler | Event-driven programming |

| Normal/Ready/Recording | State machine |

| `/dev/gesture ctrl` | Character device |

| Daemon | User-space process |

| `read()` | System call / I/O |

| Blocking read | Blocking I/O |

| Wait queue | Process synchronization/waiting |

| `fork()` | Process creation |

| Child process | Process isolation |

| `copy_to user()` | Kernel ↔ user memory |

| `printk()` | Kernel logging |

| `dmesg` | Kernel debugging |

# 22. If they ask "What happens when you run the project?"

Give this:

"First the kernel module is loaded. It registers with the Linux input subsystem and creates the character device. Then the user-space daemon starts and opens that device. The daemon waits for gesture data.

When I activate gesture mode and draw a gesture, the kernel receives the mouse events, records the path and recognizes the gesture. It makes the result available through the character device and wakes the daemon. The daemon reads the gesture and creates a child process to perform the corresponding action."

If they ask "Why is this an O.S project?"

Say:

"Because the main focus wasn't the mouse gesture itself. The gesture was the use case through which I worked with O.S-level concepts—device input, kernel modules, kernel-user-space communication, blocking I/O, waiting mechanisms and process creation."

If they ask "What was your biggest learning?"

Say:

> "My biggest learning was understanding the boundary between kernel space and user space. Before this project, I mostly understood O.S concepts theoretically. Here I actually had to decide which functionality belongs in the kernel and which belongs in user space, and then use a controlled interface between them."

If they ask "What was the challenging part?"

Use Star—but only here.

Situation

"Initially, normal mouse movement could easily be confused with an intentional gesture."

Task

"I needed to distinguish meaningful gestures from small accidental movements."

Action

"I introduced a recording state, movement thresholds, noise filtering and simple geometric checks for each gesture."

Result

> "This made the recognition more predictable for the predefined gestures."

If they ask "Why didn't you use machine learning?"

"Because the goal was primarily to learn O.S and low-level concepts, and the gesture set was small. A deterministic approach was simpler, lightweight and easier to debug. If I expanded the system to support many custom gestures or different users, I would consider a learning-based approach."

If they ask "What would you improve?"

Say exactly this:

> "Since this was an M.V.P, I'd improve three things. First, I'd make the device permissions more secure instead of using broad permissions. Second, I'd add proper synchronization around shared data between the input side and the reader. Third, I'd make the gesture thresholds configurable or adaptive so different users can use the system comfortably."

arm-specific question

> **"How is this relevant to arm?"**

Say:

"The project isn't arm-specific, but it gave me experience with C and Linux at a lower level—kernel modules, device interfaces, input handling, processes and kernel-user-space communication. Those are relevant concepts for software running on arm-based Linux systems. If I moved this to an arm Linux board, I would need to build the kernel module for the target arm architecture and kernel."

If they ask "Did you actually understand the kernel code?"

Say:

> "Yes, at the level of understanding the architecture and the O.S concepts involved. I wouldn't claim that I understand every Linux kernel A.P.I internally, but I understand why each major component is there and how the data flows from the input event to the user-space action."

My Mouse Gestures project was an O.S-focused Linux project. The idea was to allow users to perform common desktop actions using mouse gestures instead of keyboard shortcuts.

I built a kernel module that receives mouse input through Linux's input subsystem. I used a simple state machine with Normal, Ready and Recording states. When gesture mode is active and the user starts a gesture, I record the mouse movement as a sequence of points.

After the gesture finishes, I use simple geometric rules to classify it as a swipe, circle or zig-zag. For swipes I mainly look at displacement and direction, for circles I check whether the path closes near its starting point, and for zig-zags I look at repeated direction changes. I also use thresholds to filter out small accidental movements.

The kernel then communicates the recognized gesture to a user-space daemon through a character device. The daemon performs a blocking read, and a wait queue allows it to sleep when there is no gesture and wake up when one arrives. The daemon then creates a child process to execute the corresponding desktop action.

For me, the important part of this project was not just recognizing gestures, but applying O.S fundamentals practically—kernel versus user space, device input, character devices, blocking I/O, wait queues, process creation and communication between kernel and user space. Since this was an M.V.P, there are areas I'd improve for production, such as synchronization, device permissions and adaptive thresholds."

Problem

↓

Kernel module

↓

Input subsystem

↓

State machine

↓

Record points

↓

Recognize gesture

↓

Character device

↓

Daemon

↓

Blocking read + wait queue

↓

fork

↓

Action

Kernel module

→ My code running inside the Linux kernel.

Input subsystem

→ Linux's common framework for mouse/keyboard input.

State machine

→ Different states control what the program should do.

Character device

→ File-like interface for communication with the kernel.

Daemon

→ Background user-space program.

Blocking read

→ Program sleeps until data is available.

Wait queue

→ Mechanism that lets the sleeping process wake when data arrives.

Kernel Space

↓

Input events

↓

Gesture detection

User Space

↓

Daemon

↓

Desktop action

> **"The kernel handles the low-level input; the user-space program handles the high-level action."**

The strongest impression you can give is:

> *"I may not know every kernel implementation detail yet, but I understand what I built, why I designed it this way, and I understand the O.S concepts behind it."*

You have reached the end of the text.