From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 0E975D806D1 for ; Wed, 10 Apr 2024 08:54:29 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=zIE7jQDyaJvX/DnEF9O/AUOThgDhZYpvida5/OsRL8I=; c=relaxed/simple; d=groups.io; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:Resent-From:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Disposition:Content-Transfer-Encoding; s=20240206; t=1712739268; v=1; b=ri5IPcU3xzM1samIsoycSIhqiGElJ4jrvOB0CgCdUWr/Mdg6DmPXeZEgutqzWpCwhtOClEFW a/QcGMBdHKJXCcQ3ME3oN1VRMHiCqcFrjSogpj/gqybRl4BwsCHon8pYEszGVtrBVFbu0d8tGx+ j2k21pW9ywRWeFIr80MBiB99FMEN5OgsElNAUlXpOIqGeQcRkmOqQAZW7UzUlp6UQ1L0mOkmzL2 EzMdFMrBYM2zIYnmVXQJ95HCYuTpyg7ZM6k7U9yBG+qfAm8RFC0ggYHUUJRSLUvFkB9xlKxnSBl MQMaYF+pDlo7pRoDmOTNZMbIocO9Ijcitf6qwPAE/4MBg== X-Received: by 127.0.0.2 with SMTP id yXa6YY7687511xpDl4YoXvUr; Wed, 10 Apr 2024 01:54:28 -0700 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.162178.1712739267920579422 for ; Wed, 10 Apr 2024 01:54:28 -0700 X-Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-618-PbHZOV3IMIu21yBBvlQdNQ-1; Wed, 10 Apr 2024 04:54:23 -0400 X-MC-Unique: PbHZOV3IMIu21yBBvlQdNQ-1 X-Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3BCC01C0514F; Wed, 10 Apr 2024 08:54:23 +0000 (UTC) X-Received: from sirius.home.kraxel.org (unknown [10.39.192.204]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F0B2B1C060A6; Wed, 10 Apr 2024 08:54:22 +0000 (UTC) X-Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id AE12618009BB; Wed, 10 Apr 2024 10:54:17 +0200 (CEST) Date: Wed, 10 Apr 2024 10:54:17 +0200 From: "Gerd Hoffmann" To: Pedro Falcato Cc: devel@edk2.groups.io, Phillip Tennen , Heinrich Schuchardt , Ard Biesheuvel , Jiewen Yao Subject: Re: [edk2-devel] [PATCH v2 1/1] OvmfPkg: OVMF supports USB mouses Message-ID: References: <20240406124154.17978-1-heinrich.schuchardt@canonical.com> <6do7bvuicrgx5w3tti6gaoevmswvndr6u27rihmu2c2fwtx7kj@osdsv4vkb2no> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Resent-Date: Wed, 10 Apr 2024 01:54:28 -0700 Resent-From: kraxel@redhat.com Reply-To: devel@edk2.groups.io,kraxel@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: fHnXtxzvb4VbC0eIM176TGa9x7686176AA= Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240206 header.b=ri5IPcU3; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none) On Tue, Apr 09, 2024 at 04:51:20PM +0100, Pedro Falcato wrote: > On Tue, Apr 9, 2024 at 12:56 PM Gerd Hoffmann 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/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-