RedBear-OS

vasilito/RedBear-OS

Fork 0

Commit Graph

Author	SHA1	Message	Date
Red Bear OS	5276fcb739	usbhidd: P5 slice 1 — consumer key (media key) support Add support for HID Consumer page (usage page 0x0C) as key events. Cross-referenced with Linux 7.1 drivers/hid/hid-input.c consumer usage mapping. Changes: send_key_event() now handles usage_page 0x0C with a concrete mapping table: 0x00E2 → scancode 0xF0 (Mute) 0x00E9 → scancode 0xF1 (Volume Up) 0x00EA → scancode 0xF2 (Volume Down) 0x00B0 → scancode 0xF3 (Play) 0x00B1 → scancode 0xF4 (Pause) 0x00B3 → scancode 0xF5 (Next Track) 0x00B4 → scancode 0xF6 (Previous Track) 0x00B5 → scancode 0xF7 (Stop) 0x00CD → scancode 0xF3 (Play/Pause) 0x0183 → scancode 0xF8 (AL Config) 0x018A → scancode 0xF9 (Email) 0x0192 → scancode 0xFA (Calculator) 0x0194 → scancode 0xFB (My Computer) 0x0221 → scancode 0xFC (Search) 0x0223 → scancode 0xFD (Home) Event loop now dispatches usage_page 0x0C to send_key_event, treating it identically to keyboard key press/release. OrbKeyEvent.scancode is u8, so we use the 0xF0-0xFF vendor-key block instead of the full Linux evdev encoding (0xC0000 \| usage). Cross-reference: Linux 7.1 - drivers/hid/hid-input.c: hidinput_configure_usage() - include/uapi/linux/input-event-codes.h: KEY_VOLUMEUP, etc. This means USB keyboards with media keys (Volume, Mute, Play/Pause, Next/Previous Track) will now produce scancodes the display server can map to media actions.	2026-07-07 12:11:12 +03:00
Red Bear OS	de9d1f495f	base: ps2d/inputd — add startup info logs for boot diagnostics Both daemons previously produced no Info-level output on successful start, making it impossible to confirm from the boot log whether ps2d and inputd were actually alive. The kernel serial log shows no [INFO] ps2d: or [INFO] inputd: lines during normal boot, leading operators to assume the input stack was dead when in fact it was working. This adds two log::info!() calls: - ps2d main.rs: after daemon.ready(), log that ps2d has registered its ProducerHandle and is listening on serio/0 (keyboard) and serio/1 (mouse). - inputd main.rs: after setup_logging, log that inputd has registered scheme:input and is waiting for handles. These are emitted only on the successful startup path; existing .error!()/.warn!() calls continue to surface real failures. No behavior change; no functional effect on input handling.	2026-06-30 02:23:30 +03:00
Red Bear OS	dd08b76a39	Red Bear OS base baseline from 0.1.0 pre-patched archive	2026-06-27 09:21:43 +03:00

Author

SHA1

Message

Date

Red Bear OS

5276fcb739

usbhidd: P5 slice 1 — consumer key (media key) support

Add support for HID Consumer page (usage page 0x0C) as key events.
Cross-referenced with Linux 7.1 drivers/hid/hid-input.c consumer
usage mapping.

Changes:
  send_key_event() now handles usage_page 0x0C with a concrete
  mapping table:

    0x00E2 → scancode 0xF0  (Mute)
    0x00E9 → scancode 0xF1  (Volume Up)
    0x00EA → scancode 0xF2  (Volume Down)
    0x00B0 → scancode 0xF3  (Play)
    0x00B1 → scancode 0xF4  (Pause)
    0x00B3 → scancode 0xF5  (Next Track)
    0x00B4 → scancode 0xF6  (Previous Track)
    0x00B5 → scancode 0xF7  (Stop)
    0x00CD → scancode 0xF3  (Play/Pause)
    0x0183 → scancode 0xF8  (AL Config)
    0x018A → scancode 0xF9  (Email)
    0x0192 → scancode 0xFA  (Calculator)
    0x0194 → scancode 0xFB  (My Computer)
    0x0221 → scancode 0xFC  (Search)
    0x0223 → scancode 0xFD  (Home)

  Event loop now dispatches usage_page 0x0C to send_key_event,
  treating it identically to keyboard key press/release.

  OrbKeyEvent.scancode is u8, so we use the 0xF0-0xFF vendor-key
  block instead of the full Linux evdev encoding (0xC0000 | usage).

Cross-reference: Linux 7.1
  - drivers/hid/hid-input.c: hidinput_configure_usage()
  - include/uapi/linux/input-event-codes.h: KEY_VOLUMEUP, etc.

This means USB keyboards with media keys (Volume, Mute, Play/Pause,
Next/Previous Track) will now produce scancodes the display server
can map to media actions.

2026-07-07 12:11:12 +03:00

Red Bear OS

de9d1f495f

base: ps2d/inputd — add startup info logs for boot diagnostics

Both daemons previously produced no Info-level output on successful start,
making it impossible to confirm from the boot log whether ps2d and inputd
were actually alive. The kernel serial log shows no [INFO] ps2d: or [INFO]
inputd: lines during normal boot, leading operators to assume the input
stack was dead when in fact it was working.

This adds two log::info!() calls:

- ps2d main.rs: after daemon.ready(), log that ps2d has registered
  its ProducerHandle and is listening on serio/0 (keyboard) and
  serio/1 (mouse).

- inputd main.rs: after setup_logging, log that inputd has registered
  scheme:input and is waiting for handles.

These are emitted only on the successful startup path; existing
.error!()/.warn!() calls continue to surface real failures. No behavior
change; no functional effect on input handling.

2026-06-30 02:23:30 +03:00

Red Bear OS

dd08b76a39

Red Bear OS base baseline from 0.1.0 pre-patched archive

2026-06-27 09:21:43 +03:00

3 Commits