summary refs log tree commit diff stats
path: root/results/classifier/deepseek-2/reasoning/peripherals/1674
diff options
context:
space:
mode:
authorChristian Krinitsin <mail@krinitsin.com>2025-07-03 07:27:52 +0000
committerChristian Krinitsin <mail@krinitsin.com>2025-07-03 07:27:52 +0000
commitd0c85e36e4de67af628d54e9ab577cc3fad7796a (patch)
treef8f784b0f04343b90516a338d6df81df3a85dfa2 /results/classifier/deepseek-2/reasoning/peripherals/1674
parent7f4364274750eb8cb39a3e7493132fca1c01232e (diff)
downloademulator-bug-study-d0c85e36e4de67af628d54e9ab577cc3fad7796a.tar.gz
emulator-bug-study-d0c85e36e4de67af628d54e9ab577cc3fad7796a.zip
add deepseek and gemma results
Diffstat (limited to 'results/classifier/deepseek-2/reasoning/peripherals/1674')
-rw-r--r--results/classifier/deepseek-2/reasoning/peripherals/167419
1 files changed, 19 insertions, 0 deletions
diff --git a/results/classifier/deepseek-2/reasoning/peripherals/1674 b/results/classifier/deepseek-2/reasoning/peripherals/1674
new file mode 100644
index 00000000..9f74778f
--- /dev/null
+++ b/results/classifier/deepseek-2/reasoning/peripherals/1674
@@ -0,0 +1,19 @@
+<think>
+Okay, I'm looking at this bug report about QEMU where the arrow keys aren't working in the monitor when using nographic on Windows 11. Let me try to figure out what's going on and classify it correctly.
+
+First, the user mentioned that the problem occurs only when using the -nographic option on Windows. On Linux, it works fine. So something is different about how QEMU handles input in this specific setup.
+
+They provided steps to reproduce, which involve building from source but also checked pre-built binaries, so it's not a build issue. The key point is that arrow keys don't work when nographic is used, but they do work without it using the GTK console.
+
+Looking at additional info, they tried modifying code in qemu_chr_open_stdio() to enable more input modes. That change made the arrow keys functional. So this suggests an issue with how the terminal or input handling is set up in Windows builds of QEMU.
+
+They also mentioned that VT (Virtual Terminal) sequences were added via a commit but might not be enabled properly at runtime. Microsoft's documentation shows how to enable it, which wasn't being done. This explains why without enabling VT processing, certain key inputs aren't recognized.
+
+The bug seems related to the terminal handling in Windows, specifically how QEMU enables or processes virtual terminal sequences. The problem isn't with user-mode assembly translation but rather with how input is managed at a higher level.
+
+So, considering the categories: mistranslation is about source to IR mapping, which doesn't apply here. It's not an assembly lowering issue either. It falls under peripherals because it's related to input devices (keyboard) and their interaction with QEMU's console handling.
+
+Peripherals make sense because arrow keys are part of input hardware emulation in the emulator. The issue is that QEMU isn't correctly enabling the necessary settings on Windows to process these key presses, which affects the peripheral input handling.
+</think>
+
+peripherals
\ No newline at end of file