From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755350AbcEaGzW (ORCPT ); Tue, 31 May 2016 02:55:22 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:33068 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752345AbcEaGzT (ORCPT ); Tue, 31 May 2016 02:55:19 -0400 MIME-Version: 1.0 X-Originating-IP: [2a02:168:56b5:0:ac27:b86c:7764:9429] In-Reply-To: <1464676160.5978.24.camel@redhat.com> References: <1427213239-8775-1-git-send-email-kraxel@redhat.com> <20150324165057.GN1349@phenom.ffwll.local> <1427718227.3372.33.camel@nilsson.home.kraxel.org> <20150330144927.GN23521@phenom.ffwll.local> <1464335302.10663.10.camel@redhat.com> <20160527090313.GX27098@phenom.ffwll.local> <1464616236.5179.41.camel@redhat.com> <20160530144755.GK27098@phenom.ffwll.local> <1464676160.5978.24.camel@redhat.com> Date: Tue, 31 May 2016 08:55:17 +0200 X-Google-Sender-Auth: RcgptVwpaxFpfR3L_AV2ug0yvwI Message-ID: Subject: Re: [PATCH] Add virtio gpu driver. From: Daniel Vetter To: Gerd Hoffmann Cc: virtio-dev@lists.oasis-open.org, "Michael S. Tsirkin" , "open list:ABI/API" , Rusty Russell , open list , "open list:DRM DRIVERS" , "open list:VIRTIO CORE, NET..." , Dave Airlie Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 31, 2016 at 8:29 AM, Gerd Hoffmann wrote: >> but it also means that >> atomic userspace can't use hotspots before we add properties to fbs. And >> doing that is a bit tricky since drm_framebuffer objects are meant to be >> invariant - this assumption is deeply in-grained into the code all over >> the place, everything just compares pointers when semantically it means to >> compare the entire fb (including backing storage pointer/offsets and >> everything). > > Hmm, the hotspot location for a given cursor image is invariant too, so > I don't think that would be a big issue. > > I'd expect userspace define a bunch of cursors, then switch between them > (instead of defining a single cursor, then constantly updating it). Agreed, conceptually it would be a really nice fit to put the hotspot into the invariant drm_framebuffer. I just meant to say that you need to add a bit of new uapi to make it happen, since we can't reuse our existing get/set_prop functions (since those only change props after the object is created). And we also can't use our existing ioctls to enumerate properties of an object (since chicken-egg: you want the list of properties before creating a new framebuffer, so can't use that framebuffer to enumerate them). But really not a big concern. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch