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