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

5
include/defs.h
View file

@ -196,6 +196,11 @@ int input_ioctl(struct inode*, int request, addr_t arg);
int input_grab(int dev, int on);
int input_is_grabbed(int dev);
void input_report(int dev, int type, int code, int value);
// An absolute pointing device (usb-tablet). Coordinates are already in screen
// pixels; see input_mouse_abs in kernel/dev/input.c for why this is separate
// from the relative path.
void input_mouse_abs(int x, int y, int buttons);
void mouse_set_abs(int x, int y, int buttons);
void input_sync(int dev);
int input_ready(int dev);
void input_ps2_scancode(int raw, int e0);

6
include/input.h
View file

@ -39,6 +39,12 @@ struct input_event {
#define SYN_REPORT 0
// Relative axes.
// Absolute axes, for a pointing device that reports where it *is* rather than
// how far it moved -- a tablet, a touchscreen, or a VM's absolute pointer.
// Same numbering as Linux, because /dev/input/eventN claims to speak evdev.
#define ABS_X 0x00
#define ABS_Y 0x01
#define REL_X 0x00
#define REL_Y 0x01
#define REL_WHEEL 0x08

5
include/usb.h
View file

@ -49,6 +49,11 @@
#define USB_HID_SUBCLASS_BOOT 0x01
#define USB_HID_PROTO_KEYBOARD 0x01
#define USB_HID_PROTO_MOUSE 0x02
// Not a USB value: bInterfaceProtocol has no code for "absolute pointer".
// A HID device that claims neither boot protocol is treated as a tablet, which
// is what a VM offers so its cursor and the guest's can agree. Kept out of the
// 0x00-0x02 range the specification defines so it cannot collide.
#define USB_HID_PROTO_TABLET 0x80
// Bus speeds.
//