LekKit

> Currently closing RVVM window cause instant shutdown that give no chance to gratefully shutdown guest and may cause data loss. Somewhat trying to improve on that to at least...

Status: If I2C HID has same keycodes as USB HID, and the HID_KEY_POWER will be properly handled by guests, this may be resolved soon (See #58). If that approach fails,...

> This should help: https://www.kernel.org/doc/Documentation/devicetree/bindings/power/reset/gpio-poweroff.txt A bit of research reveals this signals same KEY_POWER event to the guest through internal kernel facilities on Linux, I.e. not much different from pressing...

Seems that at some point HID_KEY_POWER hook was implemented in Arch RISC-V distro, so that a simple sequence of HID API calls shuts down the guest cleanly: ```c hid_keyboard_press(win->keyboard, HID_KEY_POWER);...

> That's not a good choice,though. Mapping HID_KEY_POWER to Ctrl+C in non-GUI will cause trouble to stdio terminal using mode, and for most times, terminal users can stop the program...

> That seems good. However, will it influence the use of Ctrl + A in the guest? (For example, use Ctrl+Shift+A to behave like Ctrl+A in the guest) Double Ctrl...

So according to `ic2-hid` implementation if `input_available()` is called twice, `read_report()` should be called twice by the I2C-HID controller by holding an interrupt until the report queue is drained -...

It is indeed a PLIC bug, `plic_scan_irqs()` should be called when setting interrupt priority non-zero (Tho we also need to figure out what CTX this IRQ should be forwarded to)....

I also want to redesign HID Device API somewhat. Instead of using report id queue, and relying on "read_report()` being called as many times as needed, why not queue complete...

> Queuing events may cause other problems like shock wave effect when events are enqueued faster than processed. Ring buffer has limited size so they will be dropped in such...