<div dir="ltr"><div dir="ltr"><div>Your points seem reasonable</div><div><br></div><div>I hope DXE driver is only protocol decoder with some</div><div>interrupt/threads support and it should not occupy entire USB</div><div>bus only for mouse, so storage and kbd should keep working.<br></div><div><br></div><div>Linux USB driver supports everything but its too big (needs</div><div>complex class parser) and tightly integrated with many things</div><div>in kernel so pulling just "mouse driver" out doesn't look simple</div><div><br></div><div>I think it's ok to have minimalistic driver assuming</div><div>a known mouse protocol and no complex class</div><div>parsing even if it doesn't support every mouse but</div><div>most of them.<br></div><div><br></div><div>Clover is user "friendly" bootloader with GUI and mouse,</div><div>mainly intended to appear nice for apple users,<br></div><div>comes with free source (so we can see how USB is done)</div><div>and can boot normal linux or windows, no apples required.<br></div><div><br></div><div>True one could first boot linux and have every USB mouse</div><div>supported, then run oberon exe. One drawback is</div><div>linux shutdown is always recommeded before powering off</div><div>or there could be filesystem issues on next boot.<br></div><div><br></div><div>oberon is more poweroff-resistant than linux so I'd find acceptable</div><div>buying supported mouse to run oberong on average uefi PC</div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Nov 6, 2022 at 10:44 PM Michael Schierl <<a href="mailto:schierlm@gmx.de">schierlm@gmx.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
Am 06.11.2022 schrieb D EMARD:<br>
> I can try to search some simple uefi source example that<br>
> supports USB mouse.<br>
<br>
Ther is EFI_SIMPLE_POINTER_PROTOCOL which is available in gnu-efi as<br>
well as in EDK2.<br>
<br>
<<a href="https://github.com/rhboot/gnu-efi/blob/master/inc/efipoint.h" rel="noreferrer" target="_blank">https://github.com/rhboot/gnu-efi/blob/master/inc/efipoint.h</a>><br>
<br>
And yes, the protocol is really simple. Which does not guarantee that it<br>
works on your machine :)<br>
<br>
I have read some blogs that for<br>
> uefi PS/2 mouse/kbd is easier than USB and laptops internally<br>
> hjave PS/2 kbd and touchpad.<br>
<br>
It all depends on what drivers are included in your motherboard<br>
firmware. And while the embedded controller of my notebook emulates a<br>
PS/2 keyboard, the touchpad is not emulated at all (neither as a PS/2<br>
mouse nor an USB HID device). So for OSes that do not have native<br>
support for Elantech touchpads, no mouse for me... And also not in UEFI.<br>
<br>
> I tried free memtest86 binary, it works with USB mouse support<br>
<br>
Good for you :)<br>
<br>
Maybe I should buy a new notebook at some point (it is almost 10 years old).<br>
<br>
> EDK2 has something that looks like usb mouse driver support<br>
<br>
The USB mouse drivers in Tianocore EDK2 only support two mouse buttons.<br>
See <a href="https://bsdio.com/edk2/docs/master/_usb_mouse_8c_source.html" rel="noreferrer" target="_blank">https://bsdio.com/edk2/docs/master/_usb_mouse_8c_source.html</a> line<br>
828ff. But on the bright side, they should support interclicks just fine.<br>
<br>
> I think EFI Clover bootloader is compiled with EDK2 and it has<br>
> mouse support.<br>
<br>
Clover, that was that bootloader for Macs/Haskintoshes? To be honest,<br>
the variety of different hardware on Macs (even on Hackintoshes) is a<br>
fraction of that you find on a PC.<br>
<br>
> For gnu-efi there seems to exist some low-level USB support,<br>
> I think there is USB class protocol and user should decode mouse<br>
> protocol.<br>
<br>
While it is possible for boot service applications to take over the USB<br>
host controller, I am not sure whether that is a good idea. You'd at<br>
least have to make sure that the device the user booted from was not<br>
connected to that same host controller, or you'd have to implement all<br>
the USB Mass Storage and filesystem stuff on your own. And while the<br>
alternative would be to load a custom Dxe for your USB device and leave<br>
the host controller under the control of UEFI boot services, I don't<br>
know if you can load a custom Dxe for USB mice (supporting more buttons)<br>
if your system firmware already includes one (that supports only two of<br>
them).<br>
<br>
> I did some low-level USB 3-btn and wheel mouse support on FPGA<br>
> using lowlevel class support. Most mouses have same data structure<br>
> like logitech, it reports few bytes for each event move or click.<br>
> so most logitech mouses work, and approx 50% other<br>
> models have data structure same as logitech.<br>
<br>
To be honest, when you start to reimplement drivers at that level, why<br>
not just use the drivers (USB keyboard/mouse/storage) of e.g. Linux or<br>
A2 and let it run on EFI framebuffer?<br>
<br>
I believe there is a Linux hosted version for every Oberon variant in<br>
existence.<br>
<br>
<br>
UEFI boot services makes sense to be independent of hardware (so you can<br>
play GRUB invaders on any device that has a keyboard, screen and UEFI).<br>
Once you need to write hardware specific drivers, I'd prefer to<br>
piggyback on some existing OS that has implemented everything for it.<br>
Unless you consider it a challenge to run it without any<br>
Linux/Windows/A2 in between.<br>
<br>
<br>
Regards,<br>
<br>
<br>
Michael<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
</blockquote></div></div>