On Tue, Apr 09, 2024 at 04:51:20PM +0100, Pedro Falcato wrote:
> On Tue, Apr 9, 2024 at 12:56 PM Gerd Hoffmann <kra...@redhat.com> wrote:
> >
> > On Mon, Apr 08, 2024 at 08:53:10AM +0100, Phillip Tennen wrote:
> > > Hi, thank you for taking a look at the patch!
> > >
> > > This patch can be verified to be working with this app (which was the
> > > motivation for submitting this):
> > > https://github.com/codyd51/uefirc/releases/tag/1.0.1.
> >
> > Quoting https://github.com/codyd51/uefirc:
> >
> > Q: Should I use this?
> > A: This should not exist.
> >
> > Well. This certainly one of the more interesting ways to have some fun
> > and improve your rust coding skills. But a justification to include a
> > mouse driver by default which is not used by anything else? IMHO it
> > isn't.
>
> Maybe some better reasons:
>
> 1) It has been conspicuously missing from OVMF. I've heard N questions
> over the years (on the #osdev IRC, etc) regarding their mouse code not
> working on OVMF, whereas you'd see that protocol in other normal
> platforms
Those other platforms often have a funky setup application which (unlike
UiApp) actually support using the mouse.
So, I'm still wondering what applications people want use the mouse for?
> For sure, UsbMouseDxe isn't #1 on my most desired EFI modules list
> (e.g I'd love to eventually be able to consume Ext4Dxe from OVMF,
> where it'd actually be useful, if I can ever ditch edk2-platforms),
> but I don't really see the harm in doing it.
UsbMouseDxe is IMHO the least useful driver.
We have:
- Ps2MouseDxe, exposing EFI_SIMPLE_POINTER_PROTOCOL, and
- UsbMouseDxe, exposing EFI_SIMPLE_POINTER_PROTOCOL too, and
- UsbMouseAbsolutePointerDxe, exposing EFI_ABSOLUTE_POINTER_PROTOCOL.
On the qemu side a ps/2 mouse is always present. Working with a
relative pointer device in a virtual machine isn't very smooth though,
which why qemu offers absolute pointer devices as alternative
(usb-tablet, virtio-tablet).
So a typical configuration (on x64, aa64 is a different story) is to
have a ps/2 mouse and an usb tablet. qemu will start in relative
pointer mode and send events to the mouse. As soon as the guest
activates the tablet (typically when the linux kernel loads the usb hid
drivers) qemu switches into absolute pointer mode and sends events to
the tablet.
Linux applications don't have to worry about relative vs. absolute
pointer mode. The display server (x11/wayland) will deal with that for
them, they get the pointer position already translated to screen
coordinates.
That is not the case for efi applications though. If they want work
with both relative and absolute pointing devices they have to implement
both protocols.
Now the tricky part here is that efi applications implementing only
EFI_SIMPLE_POINTER_PROTOCOL will *not* work in case
UsbMouseAbsolutePointerDxe included in the firmware image. Loading the
driver will activate absolute pointer mode and qemu will route events
to the tablet not the mouse ...
> There's an argument in giving people a full-fledged UEFI
> implementation of most protocols. OVMF is *the* platform in mainline
> edk2 after all :)
If we do that we IMHO should
(a) add a config option for that (similar to the rarely used scsi
drivers),
(b) update all ovmf variants consistently, and
(c) include both ps/2 and usb mouse drivers.
Not sure whenever it is a good idea to include
UsbMouseAbsolutePointerDxe.
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117584): https://edk2.groups.io/g/devel/message/117584
Mute This Topic: https://groups.io/mt/105365480/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
