From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0144CC10DCE for ; Wed, 18 Mar 2020 14:39:44 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C722C20773 for ; Wed, 18 Mar 2020 14:39:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="QOCwsmwS" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C722C20773 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3DD2C6E909; Wed, 18 Mar 2020 14:39:43 +0000 (UTC) X-Greylist: delayed 689 seconds by postgrey-1.36 at gabe; Wed, 18 Mar 2020 14:39:42 UTC Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [63.128.21.74]) by gabe.freedesktop.org (Postfix) with ESMTPS id A591C6E909 for ; Wed, 18 Mar 2020 14:39:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1584542381; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XRM8NdcIdGtf/SL52VHf2bgCF9o0LkDOwhyQ8u8kC9s=; b=QOCwsmwSOyPEEpnzVOF0e+IiLsp8cxDCktcgex3utDC28AUS1NGKtcPjMkkwSo6PBRONM5 bL5aaKXIX6pzBIXNPL4VzSDvq3HPpeYIxaKQG62BokDXGAdtg4xBSoWVKPQXZMbQCEGEki Bp3wP1fhMbvA9N1nIfFediQxpereyCo= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-264-9Wu5TekhPMCfVhIMV6gLIA-1; Wed, 18 Mar 2020 10:39:35 -0400 X-MC-Unique: 9Wu5TekhPMCfVhIMV6gLIA-1 Received: by mail-wr1-f72.google.com with SMTP id t10so6141608wrp.15 for ; Wed, 18 Mar 2020 07:39:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XRM8NdcIdGtf/SL52VHf2bgCF9o0LkDOwhyQ8u8kC9s=; b=VyxI7fdLYRDy3YtEOt0JuvFIapkbtPovVcx9onyNhtmkNt1hMWSCOS/MXQFQm8FSrH YVSfFjsBq9BRz9fTv34fYz0k+DmCpYV7/21fWup8CBvYjC4MD60O0FjCC6SN24WknPtr q7v5uF5LNhj97kwYzJK0b9tMvp5vMy6aA1dijaAfGTIt/tuK/EpGy5KXBMMlfhVzd8YG tIRNWv8aOLw+krIwl9+GB9dqcbY3PUGbPvfAk5NugR6lzfmWqz29ozTgxQcYYQO1yJfI QHXTMB1+OYWlMl73100U/Xr7lY2H3bukMl1IxotVoXYfnhiR4WhI0eACs8i4dzMecAeH 0vug== X-Gm-Message-State: ANhLgQ09Qim6xJXw5Ft+EngDlByv2O3mv716oJORL8C51ddk2ooXdtlD lp/BkGCMg66Ce5HCL4xhnGIh8+TxVJ5mb7IV3sPE+jC+YXjWvmi9jTx/EldiQG/Ibd7QLZGaf1A AM+kbI5lGDLKfyGIDISz5V1MXKf25 X-Received: by 2002:a5d:640e:: with SMTP id z14mr6446551wru.204.1584542374308; Wed, 18 Mar 2020 07:39:34 -0700 (PDT) X-Google-Smtp-Source: ADFU+vs6/kcZs3B7qyZ+68fC83VKurz68SU5FrjwEUllAUZfoH4tV37VL+U1IHBAM+/zVtEHmyR+Jw== X-Received: by 2002:a5d:640e:: with SMTP id z14mr6446500wru.204.1584542373590; Wed, 18 Mar 2020 07:39:33 -0700 (PDT) Received: from x1.localdomain (2001-1c00-0c0c-fe00-fc7e-fd47-85c1-1ab3.cable.dynamic.v6.ziggo.nl. [2001:1c00:c0c:fe00:fc7e:fd47:85c1:1ab3]) by smtp.gmail.com with ESMTPSA id b5sm9381285wrj.1.2020.03.18.07.39.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Mar 2020 07:39:33 -0700 (PDT) Subject: Re: Atomic KMS API lacks the ability to set cursor hot-spot coordinates From: Hans de Goede To: "dri-devel@lists.freedesktop.org" References: <9d86bbe4-70cf-273d-4d61-aec06011d441@redhat.com> Message-ID: Date: Wed, 18 Mar 2020 15:39:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <9d86bbe4-70cf-273d-4d61-aec06011d441@redhat.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?Q?Jonas_=c3=85dahl?= Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi, On 3/18/20 3:28 PM, Hans de Goede wrote: > Hi All, > > I'm not sure if $subject was a conscious design decision, or an oversight, > but that does not really matter. > > ATM the Atomic KMS API lacks the ability to set cursor hot-spot > coordinates. Mutter (and Weston) have tried to emulate this by shifting > the coordinates for where to draw the cursor by the hotspot-coordinates > and always using 0x0 for the hotspot. > > But this breaks the so called "seamless mouse mode" for virtual-machines > and there really is no way to fix this but to allow passing the proper > hotspot coordinates to the virtual gfx-card. > > Seamless-mode consists of 2 parts: > > 1) Letting the VM-viewer window-system draw the cursor as it normally > would draw it. > > 2) Giving absolute coordinates of the mouse to the VM by e.g. emulating > an USB drawing tablet. These coordinates come from translating the > coordinates where the VM-viewer window-system is drawing the cursor > to an absolute position using the top left corner of the view as 0x0 > and the bottom right corner as max-abs-x,max-abs-y. > > 2) Means that any coordinates the window-system inside the VM passes to This should be: "1) Means that ..." > the VM's gfx-card for where to draw the cursor are basically totally > ignored to avoid lag / flicker (and to not have to grab the cursor / > confine it to the VM-viewer window and to not have to warp the > pointer). > > This means that the offset added to the coordinates by e.g. mutter to > emulate the hotspot are ignored. For Seamless mouse mode to keep working > properly the window-system inside the VM need to pass the VM's gfx-card > the correct hotspot when setting the cursor. Which currently is not > possible when restricting oneself to the atomic APIs. > > Also see: https://gitlab.gnome.org/GNOME/mutter/issues/1094 > Where this is currently being tracked from the mutter side. Mutter > internally has both atomic and legacy paths. The plan for now is to > push the hotspot-emulation by shifting coordinates thing into the > atomic path, fixing seamless mouse mode when running in legacy mode, > combined with blacklisting vboxvideo, vmwgfx, qxl and cirrus from > using atomic mode. > > This is of course a workaround, eventually we would like to see > the atomic API extended to allow passing the cursor hot spot. > > I'm not really familiar enough with the atomic API to come up with > an API design for this, but if there are suggestions on how this > should look like from the uAPI side then I can take a shot at > implementing this (and hooking it up in mutter's atomic code > paths to test it). Correction, I misunderstood the mutter devs that mutter already has support for atomic, this support is in the works, but not yet there yet. The internal mutter API has been reworked to closer resemble the atomic APIs and that introduced the hotspot emulation and broke seamless mouse mode in VMs. Mutter does eventually want to switch to using the atomic APIs and then this will become a real problem. This does mean that testing any UAPI extension we come up with for this will be harder then I thought. Regards, Hans > p.s. > > Before people start discussing how the VM / VM-viewer is broken here and > the VM needs to be fixed. Seamless mouse mode exists for at least a > decade and has worked fine during this entire decade. It also works > fine when using the legacy (non atomic) DRM_IOCTL_MODE_CURSOR2 ioctl; > > Also this problem reproduces with 2 completely independent VM code-bases, > it has been seen on both qemu-kvm VMs and on VirtualBox VMs and I would > not be surprised if other hypervisors are also affected. > > And on the API consumer side this problem has been triggered by both > mutter and Weston. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel