From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753255AbdJLTpt (ORCPT ); Thu, 12 Oct 2017 15:45:49 -0400 Received: from mail-wm0-f52.google.com ([74.125.82.52]:46088 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752308AbdJLTps (ORCPT ); Thu, 12 Oct 2017 15:45:48 -0400 X-Google-Smtp-Source: AOwi7QAInC8ZXYLQUU9NLRnAXht3ZO1kBY42yL1dDotw4+IDhQmhASOYPdR/6DCsSPXgm6wnP01OLw== Date: Thu, 12 Oct 2017 21:45:43 +0200 From: Daniel Vetter To: Keith Packard , linux-kernel@vger.kernel.org, Dave Airlie , dri-devel@lists.freedesktop.org Subject: Re: [PATCH 2/6] drm: Allow render nodes to query display objects Message-ID: <20171012194543.vpsaxt4xitv4muz6@phenom.ffwll.local> Mail-Followup-To: Keith Packard , linux-kernel@vger.kernel.org, Dave Airlie , dri-devel@lists.freedesktop.org References: <20171011004831.9624-1-keithp@keithp.com> <20171011004831.9624-3-keithp@keithp.com> <20171012184117.s6qrcpubd6wfm5wl@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171012184117.s6qrcpubd6wfm5wl@phenom.ffwll.local> X-Operating-System: Linux phenom 4.12.0-1-amd64 User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 12, 2017 at 08:41:17PM +0200, Daniel Vetter wrote: > Hi Keith, > > On Tue, Oct 10, 2017 at 05:48:27PM -0700, Keith Packard wrote: > > This allows an application to discover what display resources are > > available before requesting a lease from the X server. > > > > Signed-off-by: Keith Packard > > For reasons I've kidna stopped reviewing these patches. I don't really > agree with the details of the lease uapi as implemented. But that's > nothing that can't be fixed with a few flags, and leases always need an > explicit opt-in from the compositor now, so still possible to do > reasonable architecture on top in the future. Worst case we fake just the > parts that X needs from this version of leases, we've done that kind of > stuff in the past. > > This here otoh is an uapi change that we can't ever undo or contain, > because as soon as we allow anyone to read kms state they will do so. And > do so in lots of very interesting and abusive ways. E.g. there's already > apps who try to second-guess the vblank timings with the vblank ioctl > (which accidentally works everywhere, not just on the master), and ofc get > it wrong, except for the case the developer tested on. Or without > uevent/udev events you can't do efficient output probing, which means > we'll see endless amounts of polling (we had to stop giving accurate data > in the sysfs interface already, for exactly this reasons, because someone > thought polling outputs once per second was a smart idea). > > So given the huge possibilities of abuse, do we really, really need all > this, and is there not any way to create a bit of protocol to pass the > relevant data from X to clients? From your presentation is sounded like > current xrandr is (almost) there ... One more that came up on irc after discussion why this is needed: The userspace side using this won't work on split gpus where the render node has 0 displays, and hence where you really need to query the compositor anyway. Like I predicted, we expose this, everyone will abuse it in slightly broken ways :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch