1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, so I have this bug report about SDL2 in QEMU where the absolute mouse mode is broken. Let me try to understand what's going on here.
The user mentions that absolute mouse mode was working fine before a specific commit (30aa105640b0a2a541744b6584d57c9a4b86debd), but after that, it broke. They also talk about relative mouse mode not working in stretched displays with certain controllers and cursor data passed through the host UI backend.
First, I need to figure out if this is a user-mode or system-mode issue. User-mode bugs usually involve issues that users encounter while using the application, like graphical glitches, input problems, etc., without requiring deep kernel-level access. System-mode issues are more about hardware interactions, device drivers, or lower-level OS functionalities.
In this case, the problem revolves around how SDL2 handles mouse modes in QEMU, which is a user-space application. SDL2 is a library used for handling graphics, sound, and input across multiple platforms—it's part of user-mode software. The issue here seems to be with how events are processed within QEMU when using SDL2 as the display backend.
The bug report mentions that scaling relative motions isn't straightforward and that an attempt to fix it broke absolute mode. This points towards an issue in the application logic—how QEMU or SDL2 processes mouse input data, scales it, and updates the cursor position.
Since there's no mention of kernel modules, device drivers, or low-level OS interactions beyond what a user-mode application would handle (like using(SDL2)), this seems to be within the realm of user-mode. It doesn't involve direct hardware access or system-level privileges but rather how the application is processing input events.
So, putting it all together, I think this bug falls under 'user' because it's related to how a user-space application handles its inputs and display scaling.
</think>
user
|