nexoniarz/SchOS
nexoniarz/SchOS
Watch
1
0
Fork
You've already forked SchOS
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions

usb-hid: bind an absolute pointer, and plumb EV_ABS through

Browse source 
Groundwork for usb-tablet, which is the fix for the guest cursor and the
host's never being in the same place: a PS/2 mouse reports how far it
moved, two pointers accumulating deltas independently drift apart, and no
amount of care in the compositor can make them agree. An absolute device
reports where it is, so they coincide by construction.

  - the HID driver no longer matches the boot subclass only. usb-tablet
    declares subclass 0 and was refused at the door; hid_probe decides
    what an interface actually is, and still declines what it cannot make
    sense of.
  - a non-boot HID interface is taken to be an absolute pointer and is
    not asked for boot protocol, which it does not have -- that request
    failing is what stopped it binding.
  - tablet_report decodes the fixed 6-byte layout (buttons, 16-bit X,
    16-bit Y, wheel) and scales the logical range to pixels there,
    because it is the only place that knows the range.
  - input_mouse_abs reports EV_ABS/ABS_X/ABS_Y so a reader can tell an
    absolute position from a delta, and mouse_set_abs places the pointer
    rather than nudging it.
  - Schcom treats EV_ABS as authoritative and EV_REL as a nudge.

The device binds and identifies correctly: "usb-hid: tablet (absolute) on
slot 1, endpoint 0x81 every 4 ms".

It is NOT finished, and QEMU_INPUT is empty by default because of it. No
reports have yet been observed arriving on the tablet's interrupt
endpoint, so making it the default pointer would trade a cursor that
drifts for one that does not move at all. Opt in with

  make qemu QEMU_INPUT='-device qemu-xhci,id=xhci -device usb-tablet,bus=xhci.0'

Next step is to find out why nothing arrives: whether the first transfer
is queued but never completes, whether a completion needs re-arming for
this endpoint, or whether QEMU is not routing motion to the tablet at all
(`info mice`).

bootcheck 108 [ok], schcom-test passes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Nexoniarz 2026-08-10 18:27:01 +02:00
commit 8b7b8df74f
9 changed files with 174 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

27
kernel/dev/input.c
View file

@ -368,6 +368,33 @@ input_key(int usage, int down)
// One mouse report: relative motion plus the current button state. `buttons`
// is a bitmask in the order both PS/2 and HID boot protocol use -- left,
// right, middle -- which is why neither caller has to reorder it.
// An absolute pointer: where it is, not how far it moved.
//
// A relative device can never agree with the host's cursor inside a VM -- the
// two accumulate independently and drift apart, which is exactly the symptom
// usb-tablet exists to remove. Reported as EV_ABS so a reader can tell the
// difference and treat the value as authoritative rather than as a delta.
void
input_mouse_abs(int x, int y, int buttons)
{
static int last;
static int lastx = -1, lasty = -1;
static const int btncode[3] = { BTN_LEFT, BTN_RIGHT, BTN_MIDDLE };
int i;
if(x != lastx){ input_report(INPUT_MOUSE, EV_ABS, ABS_X, x); lastx = x; }
if(y != lasty){ input_report(INPUT_MOUSE, EV_ABS, ABS_Y, y); lasty = y; }
for(i = 0; i < 3; i++){
int now = (buttons >> i) & 1, was = (last >> i) & 1;
if(now != was)
input_report(INPUT_MOUSE, EV_KEY, btncode[i], now);
}
last = buttons;
input_report(INPUT_MOUSE, EV_SYN, SYN_REPORT, 0);
}
void
input_mouse(int dx, int dy, int buttons)
{