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

66
kernel/drivers/usb/hid/usb_hid.c
View file

@ -196,6 +196,41 @@ keyboard_report(struct hid *h, const uchar *rep, int len)
// Mouse
// ---------------------------------------------------------------------------
// QEMU's usb-tablet, and absolute pointers generally.
//
// Report: one byte of buttons, then X and Y as 16-bit little-endian values
// over the device's logical range, then a wheel byte. The range is 0..0x7fff
// and is *not* read from the report descriptor -- parsing one is a real piece
// of work, and this decodes exactly the fixed layout the tablet declares.
// A device whose report is a different length is left alone rather than
// guessed at.
//
// Scaling happens here because this is the only place that knows the logical
// range; everything above deals in pixels.
#define TABLET_LOGICAL_MAX 0x7fff
static void
tablet_report(struct hid *h, const uchar *rep, int len)
{
(void)h;
if(len < 5)
return;
int rawx = rep[1] | (rep[2] << 8);
int rawy = rep[3] | (rep[4] << 8);
int w = (int)vga_get_width();
int h_px = (int)vga_get_height();
if(w <= 0) w = 800;
if(h_px <= 0) h_px = 600;
// Scale in 64-bit-free arithmetic: 0x7fff * 4096 still fits in an int.
int x = (int)(((long long)rawx * (w - 1)) / TABLET_LOGICAL_MAX);
int y = (int)(((long long)rawy * (h_px - 1)) / TABLET_LOGICAL_MAX);
mouse_set_abs(x, y, rep[0] & 0x07);
}
static void
mouse_report(struct hid *h, const uchar *rep, int len)
{
@ -224,7 +259,9 @@ hid_complete(struct usb_dev *dev, void *buf, int len)
if(h == 0)
return;
if(h->proto == USB_HID_PROTO_KEYBOARD)
if(h->proto == USB_HID_PROTO_TABLET)
tablet_report(h, buf, len);
else if(h->proto == USB_HID_PROTO_KEYBOARD)
keyboard_report(h, buf, len);
else
mouse_report(h, buf, len);
@ -259,11 +296,20 @@ hid_probe(struct usb_dev *dev)
if(h == 0)
return -1;
// A HID device that claims no boot protocol is taken to be an absolute
// pointer -- in practice a tablet, which is what a VM offers so that its
// cursor and the host's can agree. It must not be asked for boot protocol:
// it has none, the request fails, and refusing on that basis is what kept
// usb-tablet from binding at all.
if(proto != USB_HID_PROTO_KEYBOARD && proto != USB_HID_PROTO_MOUSE)
proto = USB_HID_PROTO_TABLET;
// Ask for the fixed layout explicitly. A device that supports the boot
// subclass still starts in report protocol, so without this the reports
// arrive in whatever shape its report descriptor declares -- which we have
// not read and cannot interpret.
if(hid_request(dev, USB_HID_SET_PROTOCOL, USB_HID_PROTOCOL_BOOT) < 0){
if(proto != USB_HID_PROTO_TABLET &&
hid_request(dev, USB_HID_SET_PROTOCOL, USB_HID_PROTOCOL_BOOT) < 0){
cprintf("usb-hid: SET_PROTOCOL(boot) refused\n");
return -1;
}
@ -288,17 +334,25 @@ hid_probe(struct usb_dev *dev)
cprintf("usb-hid: %s on slot %d, endpoint 0x%x every %d ms\n",
proto == USB_HID_PROTO_KEYBOARD ? "keyboard" :
proto == USB_HID_PROTO_MOUSE ? "mouse" : "device",
proto == USB_HID_PROTO_MOUSE ? "mouse" :
proto == USB_HID_PROTO_TABLET ? "tablet (absolute)" : "device",
dev->slot, dev->intr_in.bEndpointAddress, dev->intr_in.bInterval);
return 0;
}
// Boot subclass only. A HID device that does not claim it needs its report
// descriptor parsed, and we would have nothing useful to do with it.
// Any HID interface, not just the boot subclass.
//
// It was boot-only, on the reasoning that a device without boot protocol needs
// its report descriptor parsed and there would be nothing useful to do with it.
// That is right in general and wrong for the one device that matters here:
// usb-tablet declares subclass 0, so it was refused at the door -- and its
// report layout is fixed and known, so there is something useful to do with it
// after all. hid_probe decides what a given interface actually is; anything it
// cannot make sense of is still declined there.
const struct usb_driver usb_hid_driver = {
.name = "usb-hid",
.class = USB_CLASS_HID,
.subclass = USB_HID_SUBCLASS_BOOT,
.subclass = 0xFF,
.protocol = 0xFF,
.devclass = DEVCLASS_INPUT,
.probe = hid_probe,