[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dri-devel
Subject:    Re: [PATCH v4 2/8] drm/atomic: Add support for mouse hotspots
From:       Javier Martinez Canillas <javierm () redhat ! com>
Date:       2023-07-18 8:41:32
Message-ID: 87wmyxipc3.fsf () minerva ! mail-host-address-is-not-set
[Download RAW message or body]

Pekka Paalanen <ppaalanen@gmail.com> writes:

Hello folks,

> On Mon, 10 Jul 2023 10:46:56 -0700
> Michael Banack <banackm@vmware.com> wrote:
>
>> On 7/10/23 01:17, Pekka Paalanen wrote:
>> > On Fri, 7 Jul 2023 13:54:21 -0700
>> > Michael Banack <banackm@vmware.com> wrote:
>
> ...
>
>> >> So I guess I would vote for trying to include something to that effect
>> >> as context or explanation, but not try to strictly define how that works?  
>> > Yes, exactly.  
>> 
>> Okay, if we can keep the mouse/input stuff on the fuzzy side then I 
>> think we're on the same page.
>
> Very much of the fuzzy side, yes! All I am saying is that one cannot
> explain the hotspot property without saying anything about it being
> connected with input devices in some way. The very key I want to see
> documented is that all cursor-needing pointing input devices and all
> KMS cursor planes exposed to the guest OS are meant to be associated
> with the same single conceptual pointer. That is all.
>

So if I understand correctly Pekka doesn't have any issues with the actual
implementation and is just asking for better documentation ?

How can we move this series forward? Maybe we can land this set and add an
explanation / more verbose uAPI documentation as a follow-up patches ?

Or do you think that the everything must be merged together and another
revision be posted ? The sooner we could land this, the sooner that should
be able to drop virtio-gpu from the mutter atomic deny list, and be able
to use the damage handling work that has been done across the virt stack.

>
> Thanks,
> pq

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

[prev in list] [next in list] [prev in thread] [next in thread]